我不再评审智能体写的代码了
两周前，我改变了自己构建软件的方式。从那以后我合并了 562 个 PR，而且说实话，其中有四个晚上我是在山里徒步。
视频里我完整演示了现在的工作方式。下面是文字版配套内容：环境设置、提示词、数据，以及本周可以尝试的事情。
如果你还在逐行评审智能体写的每一行代码，这篇文章就是写给你的。
1、四行讲完整个工作流
- 设定意图。 和智能体一起做计划，直到你们就"要构建什么、为什么"达成一致。
- 设定护栏。 测试、CI 和评审机器人——智能体绕不过去的那种。
- 设定目标。 一个会话、一个协调者智能体、若干子智能体干活。
- 让它小步合并。 自动合并、feature flag、验证、重复。
2、发生了什么变化
过去几周模型发生了巨大变化，尤其是 Opus 5.5。要是在几周前，我不会建议任何人这样工作。我过去总觉得必须亲自检查产出：质量够好吗？这个该合并吗？
现在我认为，只要两件事设置得当，智能体就能自己跑完整个计划：正确的意图，以及正确的护栏来确保这个意图真的被达成。把这两件事做对，你就可以放手让它真正跑起来。
这项工作的大部分都落在 Sightline 上——我们在 Spare 的内部运营平台。我什么都先在那里试。
3、护栏才是真正的工作
AI 代码是非确定性的、有风险。但人类的代码同样是非确定性的，风险一模一样。我们构建了 SRE 体系来防止人犯错；现在我们需要同样的体系——而且要强化得多——来防止智能体犯错。
用和处理事故一样的无责文化：智能体犯了错，不要怪智能体。要问缺了哪条护栏，然后把它建起来。
这不意味着质量不再重要。智能体也会把事情搞砸。正因为如此，护栏才是工作本身。下面每个 Sightline PR 在合并前都要经历：
- 单元测试
- 端到端测试
- CI、Bugbot、Strix
- Mergify——上述任何一项不通过，PR 就进不了合并队列
所以只要东西进了队列，我就知道它没有绕过任何一个红色警报。
护栏自己也被守护着。我们让 Bugbot 持续要求补充更多测试。正是 CI 里这些反馈回路，让我们能跑这么快而不拿可用性去赌。而当有东西漏网时，我们不只修代码，我们修护栏。
4、工作流，一步一步
4.1 和智能体一起做计划
每次会话都以同样的方式开始。我打开 Claude，一起把计划敲定：怎么拆分、挑战是什么、风险是什么。我经常还要一个 UX 预览，这样在任何东西被构建之前，我就能看到它用起来是什么感觉。
我现在大部分时间都花在这里。我评审的是计划，不是代码。
4.2 设定目标，每次都用同一条提示词
计划对齐之后，我开一个会话并设定目标。以下是我逐字使用的提示词：
Accomplish the plan. Ship code using auto-merge. You're the coordinator. Don't do work directly. Use sub-agents for everything, and parallelize when possible.
4.3 保持协调者的上下文干净
"协调者"这一角色帮助很大。顶层智能体只持有计划和状态，所以上下文保持干净。重活由子智能体来干，随着计划推进，它们随取随用。
4.4 让它合并，小步地合并
我让它自己合并，而且说实话，相当安全。这些模型很谨慎，不想弄坏东西。你要求一切都加 feature flag，它们就会照做。因为能合并，它们就小步交付：发一个东西、在 staging 或生产环境跑端到端测试、确认它能用、再发下一个。多阶段部署，小步增量。
有点语出惊人：一个你在本地反复迭代的大 PR，最终可能比二十个各自通过了所有检查的小 PR 风险更大。
4.5 评审进度报告，而不是 diff
我回来找它要一份进度报告。智能体会生成一份 HTML 报告：完成了什么、下一步是什么、它需要我做什么。我评审的就是这个。
4.6 让它跑上好几天，同时跑好几个
这是我认为大多数人会错过的一点：让目标跑一整夜，需要的话跑上几天。我们的自定义角色（custom roles）目标跑了一天多。我定期查看、读报告、必要时推它一把，让它一直跑到真正达成目标。
我通常同时跑两三个、甚至四个目标，而且都是互不相关的功能，这样它们不会互相踩踏。正是这一点让我们能飞快地推进。
5、把问题问得更大
我们大多数人还是把这些工具当成一个非常快的工程师来用：实现这个 ticket、加这个接口。这行得通，但想得太小了。有了目标工作流，你可以设定高得多的意图、提出开放式问题，或者把一整个业务问题交给它，让它自己想清楚需要做什么。
- 目标不是*"加一个角色编辑器"，而是"让 Sightline 的权限在任何地方都和 Spare 的一样工作"*。
- 目标不是*"把 OKR 挪进一个包"，而是"把 Sightline 变成其他团队可以扩展的平台"*。
你可以把它推得更远：
- "我们的 CI 太慢了，让它快起来。" 就这么多。让它自己找出时间花在哪里并修掉。
- "我们某个企业客户的 PPVH 偏低。深入五天的数据，想想怎么优化。" 这是真正的业务问题，不是编码任务。
- "我们管理后台的前端 UX 不一致。找出这些不一致，帮我们消除掉。"
这些不是 ticket，而是结果（outcome）。如今的模型已经足够好，能接下一个结果、把它拆解，并朝着它干上一天甚至更久。
7、容量：token 成为瓶颈
一旦你这样工作，token 就成了瓶颈。个人套餐给的额度已经不够用，超额部分又贵得离谱。
我的做法是同时跑多个 Claude 账号，大约五个、每个 200 美元左右，用一个叫 Claude Swap 的工具在它们之间切换。它监视每个账号五小时和七天的用量，任一账号达到 90% 就自动切换，让一切在后台持续运行。
这并不完美。切换账号会丢失 Claude artifacts 和移动端 App 的远程控制之类的东西，我还得不停地在浏览器和手机上重新登录，很浪费时间。所以这周我在看一些不需要切换就能解决同一问题的工具：Paseo、Orca、Superset，还有其他几个。
8、这会走向哪里
我们的工作正在从"交付一个个功能"转向"构建让产品持续演进的系统"。我们设定意图，然后构建能朝该意图自我修复的系统。
我们已经在做了：修复我们 bug 的自动化、SRE 工作的自动化、做漏洞研究的智能体，以及自动修复那些安全风险的早期工作。接下来是发现质量问题、数据库与渲染性能问题、UI 不一致的系统，以及修复它们的智能体；找出测试覆盖缺口并补上测试的智能体。
不再是我们逐个弄清每件事，而是立起一套护栏，让系统不断自我修复、走向更好的状态。
9、本周可以尝试的三件事
- 在一个真实功能上停止检查代码。 从低风险的开始。随着信心建立，再在更大的东西上试。
- 给它一个问题，而不是一个 ticket。 看它能走多远。
- 看看你正在触碰的表面区域。 缺什么护栏能让智能体搞不坏？什么回路能自己把事情修好？
原文链接: I stopped reviewing my agents' code. Here's what I do instead.
汇智网翻译整理，转载请标明出处