一次真实任务复盘：我的 AI 分身为什么第一轮「不听话」？
这是一篇问题发现型文章，会话用 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
# | symptom | severity | source |
1 | 第一轮未调 Skill 工具、无推理链 | high | user-feedback |
2 | 缺补跑/retroactive 模式指引 | medium | session-observation |
3 | Open Questions 缺优先级矩阵 | medium | session-observation |
4 | 诚实边界与 Next Steps 未联动 | low | session-observation |
5 | 推理链粒度不够（缺 Q 级决策） | medium | user-feedback |
五、升级排期
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 也是会偷懒的。
我从中得到的启发是：硬性要求很重要，约束也很重要。