做 AI 编程的开发者终于有了对抗“黑箱”的实操指南——这套工作流让人类不再是旁观者，而是真正理解代码的参与者。建议用 Claude Code 的团队直接拿它改造自己的结对编程流程。
Claude Code 核心开发者 @trq212 分享了一套高价值的「人机结对编程中的理解验证」工作流，旨在解决 AI 编程中人类沦为“审批按钮”的问题。该工作流要求 AI 扮演“高效且睿智的教师”，在每一步增量教学后，让用户复述、补缺口、通过测验，确保人类对问题、方案和影响有可复述、可辩护的掌握。核心包括三条理解轴（问题域、方案域、语境域）和八步操作流程，强调深度理解优先于速度。这套方法在 Anthropic 内部被推崇，能对抗智能体黑箱、外化隐性知识、实现可审计的学习。
Claude Code 核心开发者 @trq212 分享了一段高价值「人机结对编程中的 “理解验证” 工作流」 通过这份工作流 Skill，让 Coding Agent 结束工作时，人类对问题、方案...
Claude Code 核心开发者 @trq212 分享了一段高价值「人机结对编程中的 “理解验证” 工作流」 通过这份工作流 Skill，让 Coding Agent 结束工作时，人类对问题、方案和影响都有可复述、可辩护的掌握，一起拆解看看。 gist.github.com/ThariqS/1389dc… 核心定位：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。 · 会话可拉长：这是刻意的——深度理解优先于速度。 Thariq @trq212 been asking others at Anthropic how they stay in the loop with Claude and fully understand the work being done this is one of my favorites from Suzanne: 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 236 📊 1 ⚡