Files

T

539d10f80f feat: 合并 pre-mcp-discovery 分支能力到 main（服务发现保持生产） (#391 )

将 test/pre-mcp-discovery 分支上多位同学的能力改动整体合入 main，
服务发现端点保持生产 https://mcp.dingtalk.com，未携带分支上的预发改动。

主要内容：
- 修雨域（chat / report / todo / contact / mail）对齐 wukong 基线 (#355)
- DWS 内容生产能力增强 (#387)、文档导出与 OA 对齐 (#362 #388 #390)
- envelope 注册 cli.Aliases 为 cobra aliases、命令结构与 JSON 解析优化
- skills 多包同步 wukong 对齐内容（attendance/calendar/minutes/oa/sheet 等）
- product/oa 进一步对齐 wukong

排除项：未携带 566b4e1（test: point service discovery to pre-mcp.dingtalk.com）；
以下 4 个常量保持生产：skill_command.go / auth/endpoints.go / cli/loader.go / market/registry.go。

Co-authored-by: john <32427341+wqyenjoy@users.noreply.github.com>
Co-authored-by: wxianfeng <wang.fl1429@gmail.com>

2026-06-02 21:04:12 +08:00

7.9 KiB

Raw Permalink Blame History

文档知识

lite recipe 见 SKILL.md 速查表。

Recipe	行动指南（固定路线）
write-doc	0. 阅读 doc-create-workflow.md 的 §前置必读 + §关键词速查表，锁定文档类型和起稿路径：决策型/含对比的知识沉淀型/用户要求美观 → JSONML 起稿（`.json`）；执行型/说明型 → Markdown 起稿（`.md`） 1. 按选定路径执行 doc-create-workflow.md（JSONML 路径有骨架范例可直接复制修改） 2. `doc create --content-file /tmp/<name>.json --content-format jsonml`（或 `.md` + `--content-format markdown`） 3. 大内容默认依赖 DWS 自动分片；只有 `CONTENT_TRUNCATED`、部分写入失败或回读发现缺失时，才按 workflow 的恢复流程手工补片 4. 回读校验（必须）：所有写入完成后，执行 `doc read --node <nodeId>`，校验关键标题/段落/表格是否完整写入
search-docs-and-share	1. `doc search --query "<关键词>"` → 取 `nodeId` + 标题建索引（不读全文） 2. `doc read --node <nodeId>`（追问按需，最多 2 篇）
create-knowledge-base	1. 创建知识库空间取 `WS_ID` 2. `doc create --name "<文档名>" --workspace <WS_ID>` → 取 `nodeId` 3. `doc list --workspace <WS_ID>` 确认
migrate-doc	1. `doc read --node <源nodeId>` → 取正文并写入临时文件 `<tmp>.md` 2. `doc create --name "<文档名>" --folder <DOC_FOLDER_NODE_ID> --content-file <tmp>.md` → 取新 `nodeId`（`--folder` 只传文档文件夹 nodeId / alidocs 文件夹 URL，不传数字 dentryId；正文 <200KB 单步到位） 2a. 若正文 >200KB：必须先向用户提示截断风险（详见下方「分块 append 截断风险提示」），用户确认后再执行：`doc create --name "<文档名>" --folder <DOC_FOLDER_NODE_ID>` → `nodeId` → 按段落切片 → 每片 `doc update --node <nodeId> --content-file <part> --mode append` 3. 回读校验：`doc read --node <nodeId>` 校验内容完整性
update-doc-section	1. `doc search --query "<关键词>"` → 取 `nodeId` 2. 形态选择（按 doc-update-workflow.md §1.3 优先级）：目标段落含 callout / 分栏 / 颜色 / @人 / 附件 / 嵌套结构 → 走 `jsonml-node-edit`；纯文本替换且确认无富结构 → 继续本 recipe 3. `doc read --node <nodeId>` 定位目标章节 4. `doc update --node <nodeId> --content "<替换内容>" --mode overwrite` 5. 回读校验：`doc read --node <nodeId>` 确认 overwrite 未被降级为 append、内容完整无截断 overwrite 须用户确认；完整改写流程见 doc-update-workflow.md
rewrite-doc	1. 阅读并执行 doc-update-workflow.md：先看 §1.3 编辑形态优先级（JSONML 首选），再按 §3 速查表选路径，跳 §4 对应小节执行 2. 单块改写 / 含富结构 → §4.4 路径 B；多处保真改写或改 root → §4.4 路径 A；纯文本骨架重写 → §4.5 markdown 3. 整篇 overwrite 前必须按 workflow §4.5 向用户提示风险并等待确认 4. 回读校验（必须）：按 workflow §6 的校验要点逐项核查；@人、附件、图片等保真要素必须原样保留适用场景：用户提供已有 nodeId/链接，需要改写、润色、章节补充、段落形态转换、整篇重写
doc-to-message	1. `doc read --node <nodeId>` → 取正文（大文档只摘要+链接） 2. `contact user search --query "<姓名>"` → 取 `openDingTalkId`（推荐）；或 `chat search --query "<群名>"` → 取 `openConversationId` 3. `chat message send --open-dingtalk-id <openDingTalkId> --text "<内容>"`（推荐）或 `--group <openConversationId> --text "<内容>"` 发送。仅当无法获取 openDingTalkId 时才用 `--user <userId>`（备选）
lossless-doc-edit	1. `doc read --node <nodeId> --content-format jsonml --output /tmp/doc.json` → 获取完整 JSONML 结构（输出含 `revision`，并发敏感时记下来；默认改写不需要） 2. 解析 JSON 文件，修改 `jsonml` 数组中的目标节点（节点结构参见 doc-jsonml-schema.md） 3. 将修改后的内容写回临时文件 `/tmp/doc_modified.json`，格式为 `{"jsonml": [...]}` 4. `doc update --node <nodeId> --content-file /tmp/doc_modified.json --content-format jsonml --mode overwrite`（默认不做并发检查；担心多 agent 同时改时加 `--revision <第 1 步拿到的 N>` 触发并发检查，版本不一致返回 `VersionConflict` 时回到第 1 步重读重写） 5. 回读校验：`doc read --node <nodeId> --content-format jsonml` 确认写入成功适用场景：保留样式、精准插入特定节点类型、改属性不动文本；普通文本编辑仍优先用 markdown 模式。完整 JSONML 改写流程见 doc-update-workflow.md §4.4
jsonml-node-edit	1. `doc block list --node <nodeId> --content-format jsonml` → 获取 JSONML 节点列表（含 uuid） 2. 根据 uuid 定位目标节点 3. `doc block list --node <nodeId> --content-format jsonml --block-id <uuid>` → 读取完整子树 4. 修改 JSONML 节点内容（节点结构参见 doc-jsonml-schema.md，可复制范例见 doc-jsonml-cookbook.md） 5. `doc block update --node <nodeId> --block-id <uuid> --content-format jsonml --element '<修改后的 JSONML>'` → 写回适用场景：只改一个 block 的结构/样式，无需全文回写；写入端默认 normalize（自动补 uuid、裸字符串包成 canonical 文本），可用 `--no-fix-jsonml` 关闭全部修复；`--fix-jsonml` 额外启用 JSON 语法修复（推荐 agent 调用）

分块 append 截断风险提示

触发条件

当内容总大小 超过 200KB，需要拆分为多片通过 doc update --mode append 分块写入时，必须在执行前向用户发出截断风险提示，等待用户确认后再继续。

提示话术（参考模板）

注意: 内容较长（约 {size}），需要分 {n} 片写入。分块 append 存在以下风险：

部分片段可能写入失败但返回 success，导致文档内容截断或缺失

片段之间的表格、代码块等跨块元素可能被截断破坏

写入顺序异常可能导致段落错乱

建议：写入完成后我会回读校验文档完整性。是否继续？

执行规范

提示时机：在执行第一片 append 之前提示，而非写入过程中
分片原则：按段落/标题边界切分，禁止在表格、代码块、列表内部截断
逐片校验（推荐）：每写入一片后记录已写入的最后一个标题/段落标记，供最终回读时比对
最终回读（必须）：所有片段写入完成后，执行 doc read --node <nodeId> 回读全文，逐片比对关键标记是否完整（详见下方「doc update 回读校验规范」）
失败处理：若回读发现缺失片段，向用户报告具体缺失位置，建议针对缺失部分单独重试 append

doc update 回读校验规范

所有 doc update（含 overwrite 和 append）执行后都必须回读校验——返回 success=true 不等于内容真的写入完整。

完整规范（静默失败场景、校验流程、异常处理路径、"先清空再重建"命令样板）见 doc-update-workflow.md §6「回读验收」。

最小流程：

dws doc update --node <nodeId> --content-file /tmp/new-content.md --mode overwrite
dws doc read --node <nodeId>   # 校验关键标题、段落首句、表格、@人、附件

禁止在未回读的情况下向用户报告「已完成」。

7.9 KiB Raw Permalink Blame History Unescape Escape