①做了什么：两个层次
诚实区分——shortcut 分两层，价值定位不同，不混为一谈。
🔵 1:1 封装层 · 298 条
一个 shortcut ≡ 一个 MCP tool。把裸 dws mcp <svc> <tool> --json '{…}' 收敛成命名 flag，附校验/风险确认/Intent。
价值：DX 与 AI-agent 可发现性，不是新能力。
命名 flagrequired/enum 校验风险确认自然语言 Intentdry-run/format
🟣 真·智能层 · 68 条
照 lark-cli 范式的多步/编排/智能，不是 1:1。框架新增 CallMCPData（多步取数，对标 lark CallAPITyped）+ resolveUser（名→ID，对标 ResolveOpenIDsTyped）。
价值：这才是「shortcut 作为新能力」。
按名解析+消歧多工具编排失败回滚跨服务
②真·智能层 68 条明细（节选）
| shortcut | 多步/智能逻辑 | 验证 |
|---|
chat +dm --to <名> | 搜人→解析 userId→发单聊；多人消歧 | 真机 dry-run |
contact +lookup --name <名> | 搜人→解析→取完整资料 | ✅ 真机端到端 |
todo +assign --to <名> | 解析人→建待办并设执行人 | 真机 dry-run |
contact +org --name <名> | 解析人→取 deptId→查部门详情（3 步） | ✅ 真机端到端 |
contact +team --name <名> | 解析人→取部门→列部门成员 | 编译/挂载 |
calendar +free --who <名> | 解析人→查其时段忙闲 | ✅ 真机端到端 |
calendar +book [--with <名CSV>] | 建日程→按名加参与者→失败回滚删日程 | 真机 dry-run |
calendar +invite --event --with | 解析多人→加入已有日程 | 编译/挂载 |
calendar +suggest-time --with | 解析多人→推荐可开会时间 | 编译/挂载 |
calendar +today | 算今天范围→列我今天日程 | ✅ 真机端到端 |
calendar +next-event | 近 7 天→取最近一个日程 | 编译/挂载 |
calendar +reschedule --event | 查日程详情→改时间 | 编译/挂载 |
chat +send-to-group --group <群名> | 按群名搜群→消歧→发消息 | 编译/挂载 |
chat +group-members --group <群名> | 搜群→列群成员 | 编译/挂载 |
chat +broadcast --to <名CSV> | 多名逐一解析→群发单聊，失败汇总 | 编译/挂载 |
todo +todo-done --task <关键词> | 列我待办→按标题匹配→标完成 | 编译/挂载 |
todo +remind --task --at | 给自己建带提醒的待办 | 编译/挂载 |
minutes +latest-minutes | 列妙记→取最新一条详情 | 编译/挂载 |
minutes +action-items | 列妙记→取最新→取其待办 | 编译/挂载 |
wiki +wiki-new-doc --space <名> | 按名搜知识空间→建文档（跨 doc server 路由） | 编译/挂载 |
doc +doc-append --doc --content | 文档末尾追加文本 | 编译/挂载 |
doc +share-doc --to <名> --url | 解析人→把文档链接私信 TA（跨服务） | 编译/挂载 |
质量亮点（agent 严守 ground truth）：+send-to-group 纠正了「按群名搜群」的正确工具（search_groups 而非按成员昵称的 search_common_groups）；+wiki-new-doc 发现 create_file 在 doc server 并正确跨服务路由；+mail-to 因钉钉无 email 字段主动 skip 拒绝编造。
③测试验证（零副作用全量）
写/删命令不能真跑，用假 Caller 拦截——每条命令走完「解析→校验→确认→组装 MCP 调用」，捕获组装出的 (product,tool,params)，不真发网络。
| 验证项 | 范围 | 结果 |
|---|
go build ./... / gofmt / vet | 全仓 | ✅ 0 告警 |
| TestAllShortcutsAssemble | 全部 366 | ✅ 322 组装真实MCP · 44 自校验 · 0 失败/panic |
| TestAllToolLiteralsAreReal | tool 字面量 | ✅ 0 编造（比对 helper ground truth） |
| TestAllHaveIntent | 全部 366 | ✅ 每条均有自然语言描述 |
| TestNoDuplicateCommands | 全部 | ✅ 无重复 · 命名规范 |
| usage / userdef 单测 | 埋点/沉淀 | ✅ 全通过 |
| app 包全量回归 | internal/app | ✅ ~72s 通过（未破坏现有命令） |
| 智能层真机验证（9 批） | 只读/解析类 20+ 条 | ✅ 端到端返回真实数据、投影正确 |
| 真机抓修真实 bug | 合成测试盖不住的投影/解析偏差 | ✅ 修复 8 处（resolve-dept/at-me/group-members/free/today/suggest-time/unread-chats/dept-members） |
真机验证补齐了 assemble 测试的盲区：合成响应验证不了「防御式投影是否匹配真实响应结构」。9 批真机验证抓到并修复 8 处解析/投影偏差（如 +resolve-dept 漏了真实容器 key deptList、+at-me 未拍平嵌套、+today/+free 直吐冗长 raw）。少数命令（chat 会话消息读、minutes）因 org/PAT 权限受限无法真机跑通，组装链路仍由 assemble 测试覆盖。
④效果评估 GSB（vs lark-cli）
4.1 能力覆盖 GSB（按 dws 实际暴露的 MCP tool 数 = helper∪shortcut，非 shortcut 数）
| lark 服务 | lark | dws | dws | GSB | 说明 |
|---|
| im | 21 | chat | 95 | G | 群/消息/机器人更全 |
| mail | 21 | mail | 43 | G | 覆盖更广 |
| doc | 14 | doc | 34 | G | 块级读写更细 |
| minutes | 14 | minutes | 25 | G | 录音/说话人更全 |
| calendar | 12 | calendar | 24 | G | 会议室/ACL 更全 |
| contact | 2 | contact | 15 | G | 部门/角色/花名册更全 |
| wiki | 12 | wiki | 16 | G | 略优 |
| base | 87 | aitable | 79 | S | 持平；helper 仅 16，shortcut 补齐 +63（真 gap-fill） |
| task | 18 | todo | 20 | S | 持平 |
| drive | 26 | drive | 25 | S | 持平 |
| apps | 63 | devapp | 25 | B | helper 无 devapp，25 全由 shortcut 补，但仍少于 lark |
| sheets | 84 | sheet | 60 | B | 钉钉表格 MCP 较少；helper 已覆盖 |
| vc/okr/slides/markdown/whiteboard/note/event | 62 | — | 0 | B | 钉钉无对应能力，客观不可对齐 |
🟢 G 7 领域 · 🟡 S 3 领域 · 🔴 B（apps/sheets 少于 lark + 6 领域钉钉无能力）。base 的"持平"几乎全靠 shortcut gap-fill（helper 仅 16）。dws 独有：oa/attendance/report/ding/aisearch/live/devdoc。
4.2 组合/智能层 GSB（关键发现）
关键结论：lark 有 ~104 个组合(≥2 次 API)shortcut，但 lark 的组合性多源于飞书 REST API 太细粒度（要先查 spreadsheetToken→sheetId→再操作）；钉钉 MCP 是粗粒度的——一个 tool = 一个完整操作，所以 lark 的组合在钉钉这边大量塌缩成 1:1（已被封装层覆盖），或根本没有对应 tool。
| lark 组合来源 | 数量 | GSB | 钉钉现实 |
|---|
| sheets（先解析 sheetId） | 41 | S | 钉钉直接吃 token → 1:1 层已覆盖 |
| apps db-env/audit/log/trace | 17 | B | 钉钉无对应工具 |
| drive/doc/im（上传/媒体/搜索） | 23 | S | 多为钉钉 1:1 已覆盖 |
| calendar/contact/wiki/minutes/todo 编排 | ~10 | G | ✅ 已建为真·智能 shortcut（+book/+lookup/+org/+wiki-new-doc/+reschedule…） |
| okr/whiteboard/slides/vc | 11 | B | 钉钉无对应能力 |
→ 钉钉真正需要「组合」的场景（按名解析+多工具编排+跨服务），dws 已覆盖并额外做了 lark 没有的（+today/+broadcast/+share-doc/+action-items 等）。不盲目复刻 lark 的机械多步（在钉钉会成冗余假组合）。
⑤dws 差异化优势
复用生产级 MCP 通道（架构性）—— CallMCP 统一继承错误分类(auth/PAT/业务)、dry-run、--format/--jq/--fields；lark 每命令各自实现。
协作能力覆盖更全 —— chat 95/mail 43/doc 34/minutes 25（dws tool 覆盖）是 lark 对应 2–4 倍。
钉钉原生特有能力（lark 完全没有）—— 审批/日志/考勤/DING/企业智能搜索，75 条差异化封装。
真·智能编排（22 条） —— 按名解析+消歧、失败回滚、跨服务；resolveUser/CallMCPData 让新智能 shortcut 越写越快。
高频自动沉淀（P2 · lark 无此设计）
高频使用→埋点→suggest→add 写 YAML→运行时加载可用
工程质量 —— 假 Caller 拦截，366 条（含写/删）零副作用全量验证，可复跑回归。
一句话结论：dws 已把钉钉侧能对齐的都对齐（366 条 = 298 封装 + 68 智能 / 16 服务，1:1 层已去 213 条纯重复），即时协作显著优于 lark，拥有审批/考勤/DING 等原生差异化能力与「高频自动沉淀」独有闭环。lark 的组合优势多因飞书 API 细粒度、在钉钉粗粒度 MCP 下塌缩为 1:1（已覆盖），真正需编排的钉钉侧已建齐；受限项均为钉钉客观无对应能力，非工程遗漏。全部 366 条通过零副作用全量验证。