这是一篇问题发现型文章，会话用 ​​my-digital-human​​ 处理「standard-contract-face-auth 真实案例的剩余任务拆解」因为这个需求已经部分开发，我根据AI的相关反馈信息，来明确AI是否真实使用​​my-digital-human​​技能得出具体的需求开发结论。

前言

理论写得再好，真实会话里 Agent 也可能直接查代码、跳过 Skill 工具、不展示推理链。

本文以standard-contract-face-auth任务为案例，对比同一需求下「失败轮」与「成功轮」的差异，提炼三个关键发现：补跑/受限工作流缺乏决策指引、Open Questions 没有优先级框架、Next Steps 未区分「我能做的」与「需转交他人的」。

这是一篇问题发现型文章，会话用my-digital-human处理「standard-contract-face-auth 真实案例的剩余任务拆解」因为这个需求已经部分开发，我根据AI的相关反馈信息，来明确AI是否真实使用my-digital-human技能得出具体的需求开发结论。

一、两轮调用对比

第一轮（未走技能流程）

•输入：/my-digital-human 在当前分支下，帮我看下 standard-contract-face-auth 这个任务，我之前做到哪一步？

•实际：Agent 用 Bash/Read 查代码，没调 Skill 工具

•输出：事实对，但没有编码 DNA 视角、没有推理链、没有 Output Contract

•归类：Workflow 没执行，技能规则被绕过

第二轮（流程合规）

•输入：我希望你帮我跑一次 数字分身 这个技能...

•实际：调 Skill 工具 → 走步骤 1-5 → 按需加载decision-heuristics.md+dev-patterns.md→ 展示推理链 → 按 Output Contract 交付

•输出：结构化、能直接执行

•归类：流程合规

二、三个缺口

1. 补跑模式（retroactive / skipStage3Coding）没有决策指引

standard-contract-face-auth是补跑任务，工作流契约写死「不新增编码」。分析 （47h 失效重刷）时，grep 到guardSubmitWithFaceAuthExpiry已在 3 个页面使用，按「复用优先」和一致性，本页也该接。

冲突在这：增量迭代是技能默认规则，补跑契约限制范围。

改法：在references/decision-heuristics.md加「受限工作流决策」：

•补跑/retroactive 模式下不新增编码

•一致性需求记进下一轮 backlog

•显式标注「一致性 vs 范围边界」的权衡点

2. Open Questions 没有优先级矩阵

五个 Open Question，全靠人工拍优先级。

改法：在references/decision-heuristics.md加决策矩阵：

| 维度 | 权重 | 说明 | |------|------|------| | severity | 50% | blocking-deferred / non-blocking | | 责任方 | 30% | 前端自控 / 后端·产品·QA 依赖他人 | | 重构代价 | 20% | 低 / 中 / 高 | 优先级： - P0：blocking + 前端可控 + 低成本 → 立即做 - P1：一致性 + 前端可控 + 低成本 → 下一轮增量 - P2：non-blocking + 依赖他人 → 并行确认

3. Next Steps 没标责任方

Output Contract 的 Next Steps 列了行动项，但没区分「技能能直接做」和「要转交他人」，和「诚实边界」章节也没对上。

改法：Next Steps 加责任方字段：

•前端 → 技能可直接执行

•后端/产品/QA → 标「转交」，附交接话术

三、推理链示例（可进 examples.md）

Q4（47h 失效重刷）的决策过程：

输入：standard-contract-file 页面要不要接 guardSubmitWithFaceAuthExpiry？ ↓ 查技能规则： - 架构层 → 复杂流程抽象：跨页面共性上提 - 决策层 → 复用优先 - 反模式 → 先搜已有实现，不造轮子 ↓ 事实： - grep：guardSubmitWithFaceAuthExpiry 已在 3 个页面使用 - 抽象现成，接入成本低 ↓ 冲突： - 当前任务是补跑，契约「不新增编码」 - 增量迭代 vs 范围边界 ↓ 决策： - 短期：保持现状，不破坏补跑契约 - 长期：下一轮增量补做（P1 一致性） ↓ 输出：Q4 标 P1，建议 Q2/Q6 通过后再做

四、已记入 skill-issues.jsonl

五、升级排期

v2.3.1（短期）

•SKILL.md 顶部加提醒：slash command 触发后必须走步骤 1-5

•decision-heuristics.md加「受限工作流决策」

v2.4.0（中期）

•decision-heuristics.md加 Open Questions 优先级矩阵

•Output Contract 加「责任方」字段

v2.5.0（长期）

•examples.md补「补跑模式下的增量决策」示例

•新增 eval case：受限工作流处理

六、总结

这次会话说明两件事：

1. 触发技能 ≠ 执行技能

用户打了/my-digital-human，Agent 照样可以绕过 Skill 工具直接查代码。 输出事实没问题，但丢了编码 DNA、推理链和 Output Contract。技能要生效，得显式要求「跑数字分身流程」，并在 SKILL.md 顶部加硬提醒。

2. 规则齐全，边界场景缺指引

补跑任务（retroactive / skipStage3Coding）是最典型的例子：

技能默认「复用优先、增量迭代」，工作流契约写死「不新增编码」，两套规则撞在一起，Agent 只能临时判断。

Q4 的处理（短期不动、长期 P1 补做）是对的，但这类决策不该每次靠临场发挥，应该写进decision-heuristics.md。

三个缺口可以归纳成一句话：技能知道「怎么写好代码」，还不知道「在什么约束下该不该写」。补跑模式指引、Open Questions 优先级矩阵、Next Steps 责任方标注，都是在补这层判断。

任务侧：Q2/Q3/Q5/Q6 等人确认，Q4 等 Q2/Q6 通过后下一轮增量做。

技能侧：优先 v2.3.1（受限工作流决策 + 触发提醒），再 v2.4.0 补矩阵和责任方字段。

只有实践之后，才可以知道技能的问题，不试一次你永远发现不了AI 也是会偷懒的。

我从中得到的启发是：硬性要求很重要，约束也很重要。