meng shao@shao__meng

精选78

2026-06-02 08:55·31天前

精选理由

Anthropic内部的「理解验证」工作流，把结对编程的认知摊到全程，用清单和测验逼你真正懂。做AI辅助开发又不想当审批按钮的，可以直接套用。

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。 · 会话可拉长：这是刻意的--深度理解优先于速度。

meng shao@shao__meng · X

精选78导出 Markdown