meng shao@shao__meng · XAnthropic内部的「理解验证」工作流，把结对编程的认知摊到全程，用清单和测验逼你真正懂。做AI辅助开发又不想当审批按钮的，可以直接套用。
Anthropic 核心开发者分享了一套用于 Claude Code 的「理解验证」工作流。该工作流将 AI 定位为“高效且睿智的教师”，成功标准不仅是完成任务，更是确保人类对问题、方案及影响有可复述、可辩护的掌握。它通过增量教学、用户复述、清单+测验等方式，围绕问题域、方案域和语境域三条轴线展开，具体包含8个可执行步骤，强调在进入下一阶段前需确认用户已真正理解。此工作流旨在对抗长会话中人类易沦为“审批按钮”的“智能体黑箱”问题，强制沉淀决策上下文，实现可审计的深度理解。
Claude Code 核心开发者 @trq212 分享了一段高价值「人机结对编程中的 "理解验证" 工作流」
通过这份工作流 Skill，让 Coding Agent 结束工作时，人类对问题、方案和影响都有可复述、可辩护的掌握，一起拆解看看。 https：//gist.github.com/ThariqS/1389dcdff9eba4789887a2211370f06b
核心定位：AI 扮演「高效且睿智的教师」 成功标准不只是「任务完成」，更要看人类是否真正理解整场会话，与常见 agent 模式的差异： · 每步增量教学，过关才进入下一阶段 · 先让用户复述，再补缺口 · 清单 + 测验 + 演示理解 才算结束
三条理解轴（清单应覆盖） 1. 问题域 · 是什么问题 · 为何会出现（根因、历史、分支路径） · 曾有哪些取舍路线
2. 方案域 · 做了什么、为何这样解 · 设计决策与 trade-off · 边界情况与失败模式
3. 语境域 · 改动在系统/业务里意味着什么 · 会影响谁、什么流程、什么风险
反复追问 why → 更深层的 why，同时覆盖 what / how。强调：问题理解不到位，方案理解往往是假的。
操作流程（可执行的节拍） 1. 做完一小步 只推进一个可验收的小单元（例如：定位根因、选定方案、改一处逻辑），不要一口气跨多个阶段。 2. 先让用户复述 在进入下一步之前，请用户用自己的话说明：这一步在解决什么、为什么这样做、还有什么不确定。这是诊断，不是考试前的泄题。
3. 按缺口补课 根据复述找空洞：补动机、补业务逻辑、补边界与分支；可按需要切换抽象层级（例如 ELI5 / ELI14 /「像实习生那样讲」）。 4. 小范围验证 用开放题或多选题检查是否真懂；若用选择题，打乱正确选项顺序，且在用户提交答案之前不公布对错。
5. 过关才前进 同一阶段需在高层（为何要做）和低层（怎么做、边界在哪）都确认后，才进入下一阶段。 6. 同步更新清单 在 running 的 Markdown 里勾选或补充：问题 / 方案 / 语境三个维度下，用户应掌握的具体条目。
7. 必要时绑到真实材料 理解若依赖实现细节，贴相关代码片段，或一起用调试器走一遍，避免「听懂了但对着 diff 仍说不清」。 8. 收工条件 会话结束前，清单上的每一项都需用户表现出已掌握（能复述、能答题、能解释 trade-off），而不是由 agent 单方面总结一句「你应该懂了」。
设计意图（为啥在 Anthropic 内部被推崇） · 对抗「智能体黑箱」：长会话里人类容易变成审批按钮；增量确认把认知负荷摊到全程。 · 把 tacit knowledge 外显化：分支、否决方案、边缘 case 往往只存在于 agent 上下文里，清单强制沉淀。 · 可审计的学习：对团队负责人或后来的自己，「当时为什么这么改」有迹可循。 · 与产品风险对齐：懂 impact 才谈得上 responsible shipping，而不只是 merge。
实操要点（落地时注意） · 清单是活文档：随会话演进增删项，不是一次性大纲。 · 测验要变式：避免背答案；多选题需轮换正确选项位置。 · 层级要交替：同一主题在动机 <-> 实现 <-> 边界之间切换，防止只会背概念或只会跟 diff。 · 会话可拉长：这是刻意的--深度理解优先于速度。