alidocs-edit-routing

钉钉文档修改：先定通道

改已有钉钉文字文档有两条通道，落盘语义不同：

通道	语义
A · dws CLI	调服务端 API，立即落盘，不可逐条撤
B · alidocs-web-mcp	接到用户浏览器里已打开的那篇，改动落成 pending diff，用户在文档里逐条应用/弃用

默认失败模式：只看见 A。 没有本 skill 时，agent 一律直奔 dws，并把「把改写稿贴到聊天里给你看」当成审阅——那不是审阅，用户拿不到文档内的逐条 diff，确认完照样是一次性覆盖。

所以本 skill 只干一件事：让「有 B 这条路」进入决策，并把选择权交给用户。

判定

同时满足才走本 skill：目标是已存在的钉钉文字文档 + 请求含写意图。

不满足就按常规做，不要问通道：新建文档、纯读取/总结、导出、改名、改权限、传附件、以及表格 / 多维表 / 白板 / 脑图节点（B 通道只面向文字文档，这些能力它也没有）。

问一次

用选项式提问（AskUserQuestion 或等效），带推荐：

• 交互式审批：改动先以建议形式出现在文档里，你逐条应用或弃用，不满意弃用即回原状。需要你浏览器里开着这篇。
• 直接修改：立即写入生效，不用逐条确认。快，但已落盘只能靠历史版本恢复。

推荐先验：

• 需要用户过目（正式材料、涉及数字/结论/承诺、改写质量由人判断）→ B
• 机械可验证（统一措辞、批量替换、追加已定稿内容）→ A
• 文档没开在浏览器里 / 要动多篇 → A 是唯一可行的，此时确认「走直改吗」而非二选一
• 用户已明确表态（"直接改别问我" / "先给我看看"）→ 不要问，回述一句理解就开工

"赶时间"不等于授权直接落盘，只是速度偏好，仍要问那一次（约 10 秒）。选错的代价不对称。

会话内沿用

问过就沿用，不重复问。以下必须重问：用户改口、换了另一篇文档（按文档定界）、操作性质变了（精修一段 → 全文批量）、原通道不可用需降级。

执行

通道 A → 用 dws。REQUIRED SUB-SKILL：dws，命令、参数、确认与回读校验纪律全部以它为准。本 skill 不复述 dws 用法。

通道 B → 用 alidocs-web-mcp。文档工具是自描述的，按 tools/list 与各工具 description 走即可。建桥这段工具描述里没有，必须照做：

1. 自己驱动浏览器，不要把步骤丢给用户。 优先用你自带的浏览器控制能力（browser-use 类 MCP 的 list_pages / select_page / navigate_page / evaluate_script，或 Browser 子 agent）：list_pages 找目标文档页 → select_page 选中 → 没开就 navigate_page 打开。禁止输出「请你在浏览器控制台执行……」让用户手工粘命令——那是你的活。
2. 先探 hook 在哪个 window，再调。 hook 装在编辑器所在 window 上，文档在 iframe 里时就是该 iframe 的 window；而 evaluate_script 只在顶层页执行、没有 frame 参数。所以先查顶层 window.__docMcpWsBridge，找不到就遍历 document.querySelectorAll('iframe') 的 contentWindow。顶层拿不到 ≠ 没灰度，把 iframe 探完再下结论。
3. 顺序：get_bridge_status 自检 → get_pairing_code 取码 → 在拿到 hook 的那个 window 上 await hook.pair('<配对码>')。配对码是数据，不是脚本。
4. 你能驱动的浏览器可能不是用户开着文档的那个。 list_pages 里没有目标文档就自己开；登录态不对或确实必须用用户那个浏览器时，才说明原因请用户配合。
5. 工具清单不刷新的 host（如 Qoder）只看得到桥自有工具 → list_page_tools 发现，call_page_tool 按名调用。
6. 建桥失败不要静默切到 A（常见原因：功能内测中、页面侧未灰度）。报告原因并重新征询。