Anthropic 的做法分三步：Claude 先像真实用户一样把功能用一遍并自动修正，审查时参照写成文件的团队品味，最后人只看证据（录屏、截图、测试结果）决定能否合并。省掉的是读代码的时间，验证一步没少。
写代码已经不是难点，瓶颈转到了验证。过去 AI 开的 PR 排队等人逐行读；现在 Claude 先自己试用、自己修，把证据交出来，人只看证据。
泳道表示由谁负责。实线是对谈里明确讲到的流转，灰色虚线是为闭合流程补画的环节，青色虚线是 Addy 说的目标方向。可以跟一个 PR 逐步走一遍，也可以切到熄灯形态，看人从哪里退出。
人决定做什么，把活委派给 Claude。责任不随之转移：Addy 说就算是他让 Claude 去干的活，出了问题还是他负责、他去修。
视频 14:41 快问快答两人都主张在 PR 上标注由 AI 编写：知道是 AI 写的，就能决定额外加哪些约束和检查；对金融客户还关系到审计。Manish 认为至少未来 6–9 个月应该标。
视频 14:41关键是让 Claude 能像真实用户一样实际试用：跑端到端任务、在浏览器里打开检查、运行工具、做代码规范检查，凡能建立信心的检查都做。Anthropic 自己也在用它的代码审查产品，目标是把代码审查尽可能自动化。
视频 5:38大家都在谈品味和判断力，就把团队认定的最佳实践和品味写进共享的 CLAUDE.md、AGENTS.md 这类写给 AI 看的文件，智能体审代码时去查阅。
视频 5:38发现 bug 或功能缺口时，Hooks 会在任何编辑后自动运行，研读这次的 diff，形成一个尽快把 PR 改对的循环，再回到审查。
视频 5:38做浏览器里的界面，就要确认在浏览器里测过，最好附一段它点来点去的录屏；在意手机或桌面体验，就给这些设备上的截图或录屏。目标是让智能体提供尽可能多的验证证据。
视频 5:38人负责检查智能体给出的证据，而不是逐行读代码。看完录屏就有信心说这个能用。宝玉的补充：看录屏比读几百行代码快得多，但证据仍要自己看。
视频 5:38 · 帖子AI 开的 PR 何时能合并？Addy 的回答：有充分信心不会出问题，或已经尽可能把风险降下来。长期目标是验证足够可信，让改动自动合并。“证据不足打回修正”是本页为闭合流程补画的，对谈里没有明说。
视频 9:20 · 14:41Addy 认为模型质量已经不错（他举了 Opus 5.5），下一截提升主要来自验证，而且要讲具体：跟人说“验证一下”，对方下一句就会问“验证指什么”。
从头到尾模拟用户操作的自动化测试，验证整条使用路径能走通。
不写一个个具体例子，而是写一条必须成立的规则，让程序自动生成大量随机输入去验证。
通过截图对比检查界面有没有变样，覆盖单元测试看不到的显示问题。
视频 9:20。目标是有足够的信心让这些改动自动合并。
这是 Manish 从 Sonar 角度给的框架：零信任，在每个环节都验证。最下面一行是本页做的对照，标出每一层在图 1 的 Anthropic 流程里由哪个环节承担。
Addy 对软件工厂的定义是“把循环规模化”：让 AI 一遍遍地规划、编写、检查、上线。两种工厂的区别在于人站在哪里。
Addy 接触过的很多公司几个月前都在担心同一件事：放手让团队用智能体，冒出成百上千个，谁也不知道它们在碰哪些系统、读哪些数据，是否在往生产环境部署。
Addy 总结的企业三件大事：怎么控制、怎么分配权限、怎么用沙箱确保智能体不越界。
给智能体身份，记录它实际做了什么，才谈得上追踪和管控。
Sonar 的说法：不只是撞上护栏才拦，而是引导智能体沿既定路线走、不出沙箱。
PR 标注 AI 编写，便于加约束和审计。责任归属不变：谁发起，出了问题谁修。
视频 13:19 · 14:41
Addy 给技术负责人的建议是：推着团队想清楚验证具体指什么，现在的测试做到哪一步，离 AI 自己判断可以合并、你也放心还差什么（视频 14:41）。下面 8 项都来自对谈，勾上已经具备的。
先从最便宜的一步开始：要求 AI 交活时附上证据，从最容易出问题的界面做起（宝玉的建议）。
分档规则是本页根据对谈提炼的，不是 Addy 或 Manish 的原话；即使 8 项全具备，合并的标准仍是“有充分信心，或风险已尽量降低”。