这是《超级个体的装备栈》系列的第二篇。如果你还没读过总纲 ，建议先读那篇——这篇的所有判断都建立在那篇提出的标准之上：一层装备的进步，是只帮你，还是同时帮你所有对手。
一个我以为是好消息的早晨
去年冬天有一段时间，我把自己的执行链路调到了一个当时觉得很得意的状态。
睡前把当天攒下的待办拆成十个左右的任务，每个任务一个独立的工作区，agent 在后台跑。第二天早上打开电脑，十个分支，十个 PR，附带十段写得挺像回事的变更说明。从任何一个「装备清单」的角度看，这都是模范配置：并行度拉满，人不在场也在产出，边际成本趋近于零。
然后我坐下来开始 review。
上午九点半开始，中午吃饭前审完了三个。其中一个改动看着没问题，但我花了四十分钟才确认它没有悄悄改掉一个我三个月前特意写成那样的边界处理。下午审完第五个的时候我已经不太想看了，第六第七个基本只扫了一眼 diff 行数和测试有没有过。第八个我直接合了。到晚上，还剩两个躺在那儿，我把它们拖回了 backlog。
那天晚上我做了一件很蠢的事：我又开了十个任务。因为我下意识觉得，早上收到十个 PR 是好消息，那明天收到十个也是好消息。
一周之后我算了一笔账。那一周我合并的代码量大概是过去的三倍，但真正上线、真正被用户碰到的功能，一个都没多。多出来的东西全部堆在 main 里，以「已完成」的形式存在，以「还没验证」的形式真实存在。而我那一周的主观感受是：极其忙碌、极其高效、极其疲惫。
这就是我想在这一篇里讲清楚的事。我把执行速度提上去了，然后发现什么都没变快。 不是工具不好用，是我把瓶颈搞错了。
先把这一层现在长什么样说清楚
任何关于生产层的讨论，如果不先区分「模型层」和「harness 层」，都会变成一场关于哪个模型更聪明的口水战——而那恰恰是最不值得讨论的部分。
模型层是推理能力本身：它能不能理解一个跨十几个文件的重构、能不能在一个陌生代码库里定位到正确的位置、上下文窗口多大、单位成本多少。这一层你完全无法施加影响。它由几家公司的训练进度决定，按版本号发布，同一时刻发给全世界所有人。
harness 层是模型怎么被接进你的仓库和你的工作流。这一层是有工程量的，而且工程量全部在你这边。
拿 Claude Code 的官方扩展分层做个具体的坐标系，它的层次划分大概是这样：CLAUDE.md（项目级规则文件）、Skills（可复用的技能包）、Code intelligence（LSP，让 agent 真正理解符号和引用而不是靠字符串匹配）、MCP（连外部工具和数据源）、Subagents（把子任务分派给独立上下文的子代理）、Agent teams（实验性的多 agent 协作）、Hooks（在生命周期节点上挂自己的脚本）、Plugins 与 Marketplaces（把上面这些打包分发）。
这套东西摆在一起，你会发现它们回答的其实是同一个问题：模型是通用的，你的仓库是特殊的，中间这段落差谁来补。
┌──────────────────────────────────┐
模型层 │ 推理能力 / 上下文窗口 / 单位成本 │ 完全外生
└──────────────────────────────────┘
▲
│ 同一批能力，同一时刻，发给每个人
│
┌────────────────────────────────┴────────────────────────────────┐
│ harness 层 —— 模型怎么被接进「你的」仓库和工作流 │
│ │
│ 规则文件 工具接口 子代理 钩子 分发 │
│ CLAUDE.md MCP Subagents Hooks Plugins │
└─────────────────────────────────────────────────────────────────┘
▲
│ 三种形态，区别只在「你在不在场」
│
┌──────────────┬─────────────────┴──────────┬──────────────────┐
│ 终端 agent │ 云端自治 agent │ IDE 内嵌 │
│ 你在场 │ 你不在场 │ 你逐行盯着 │
│ 随时打断 │ 跑完给你一个 PR │ 补全 / 局部改 │
└──────────────┴────────────────────────────┴──────────────────┘
底下那一行的三种形态值得多说两句，因为它们的差别不在功能，在你的注意力被消耗的方式。IDE 内嵌全程要你在场，质量下限高但并行度是 1；终端 agent 是当下多数人的主力，并行度取决于你能同时盯几个终端，实际上很少超过二三个。
云端自治是最诱人的那个。Claude Code 的 Routines（目前是 research preview）就是这个形态的典型：你把一份配置保存下来——prompt、目标仓库、需要的 connectors——它跑在 Anthropic 托管的云上，你合上笔记本它照跑不误。触发方式有三种：Scheduled（最小间隔一小时，支持 cron 表达式）、API（每个 routine 有独立的 /fire 端点和 bearer token）、以及 GitHub 事件触发。
这里有个细节我认为特别值得一个做工程的人停下来看一眼：routine 运行时是没有权限选择器、没有审批提示的。 这很好理解——你人都不在，弹窗给谁看。所以它的安全边界是靠别的方式画的：默认只允许 push 到 claude/ 前缀的分支。也就是说，它可以写代码、可以开分支、可以开 PR，但它碰不到你的 main。
另一个细节更漂亮。通过 API 触发时传进去的 text，会被包进一个 <routine-fire-payload> 块，并且被明确标注为不可信数据。这是一个非常清醒的设计：既然这个端点可以被任何拿到 token 的系统调用，那么调用者塞进来的内容就必须被当作外部输入对待，而不是当作你自己的指令。这是提示注入防御的教科书写法——把「谁在说话」和「说了什么」在结构上分开。
我把这个细节单拎出来不是为了夸某个产品，而是因为它揭示了这层装备真正的成熟度标志：当 agent 开始在你不在场的时候跑，安全模型就必须从「每一步问你」切换到「事先划好它能碰什么」。 这个切换比任何一次模型升级都更改变工作方式。
规则文件这件事，网上大量文章写错了
既然提到了 CLAUDE.md，我要在这里插一段纠错，因为这是我见过被写错次数最多的一个技术细节。
Claude Code 读 CLAUDE.md，不读 AGENTS.md。 官方文档写得很直白：“Claude Code reads CLAUDE.md, not AGENTS.md”。
但网上有大量文章——包括一些传播很广的中文译介——直接写「Claude Code 已支持 AGENTS.md 标准」。这是错的。如果你信了这句话，把项目规则只写在 AGENTS.md 里，然后疑惑为什么 agent 完全不遵守你定的规矩，答案就在这儿：它压根没读到。
官方给的桥接方案有两个，都很朴素：在 CLAUDE.md 里用 @AGENTS.md 把它 import 进来，或者干脆做个符号链接 ln -s AGENTS.md CLAUDE.md。两条路都能让一份规则同时服务多个工具。
AGENTS.md 的来历解释了这个误解为什么传播得这么广。它由 OpenAI 在 2025 年 8 月发布，2025 年 12 月 9 日捐给了新成立的 Agentic AI Foundation（AAIF，隶属 Linux Foundation），到 2025 年 12 月的官方口径，采用它的开源项目超过 6 万个。Linux Foundation 新闻稿里点名的原生支持工具包括 Amp、Codex、Cursor、Devin、Factory、Gemini CLI、GitHub Copilot、Jules、VS Code——名单长到让人自然而然默认「所有 agent 工具都支持」。但里面确实没有 Claude Code。
这件事的意义不止于纠一个错。 一个可以在三十秒内验证的事实，被反复转述成了相反的样子——你在这层投入的每一分注意力，都要先穿过这种噪音。这本身就是「这层不值得投入太多注意力」的一个实证理由。
官方还有一条我很认同的建议：CLAUDE.md 尽量控制在 200 行以内。 这条建议背后的道理，后面讲「规则前置」的时候我会展开——它不是为了省 token，是为了让规则真的被遵守。
工具接口和工单编排
MCP 在这套体系里的位置是「让 agent 能碰到代码之外的世界」。它在 2024 年 11 月首次开源，同样在 2025 年 12 月 9 日被 Anthropic 捐给了 AAIF。官方口径是已发布的 MCP server 超过 10,000 个（2025 年 12 月）。AAIF 的白金成员里有 AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAI；采纳这个协议的平台包括 Claude、Cursor、Microsoft Copilot、Gemini、VS Code、ChatGPT。
我列这一串不是为了展示生态繁荣，恰恰相反。两个原本属于不同公司的协议，在同一天被捐给同一个基金会，信号非常明确：接口层的竞争结束了。 结束竞争意味着它从「差异的来源」变成了「差异的背景」——任何人接入外部系统的能力，从此都是一样的。这正是总纲里说的「入场券」的标准形态。
再往上一层是工单驱动的编排，也就是「agent 直接从你的任务系统里领活」。Linear 的 agents 目录是观察这件事最清楚的窗口：目前可以直接 assign 的头部 agent 包括 Codex、Cursor、GitHub Copilot、Factory 的 Droids、Sentry Agent、Devin。你把一个 issue 指派给它们，它们会去干活，把进展写回 issue，最后开一个 PR。
但这里有个缺口值得点出来：Anthropic 官方给 Linear 的只是一个 MCP connector，归类在「AI clients」下面——它不能被 assign，没有事件触发，不会自己盯 inbox。 也就是说，你可以让 Claude 去读 Linear，但你没法把一个 Linear issue 丢给 Claude 让它自己跑。
这个缺口就是 Cyrus 这类开源项目存在的空间。它的自我定位写得很直接：“Your (Claude Code|Codex|Cursor|Gemini) powered (Linear|GitHub|GitLab|Slack) agent”。Apache-2.0 协议，大约 703 star，BYOK，可以完全自托管。机制是：监听被 assign 的 issue，为每个 issue 创建一个隔离的 git worktree，在里面跑 agent 会话，把活动流式回传到 Linear 或 GitHub，最后开 PR。
我特意把 worktree 那句加粗了，后面有一整节讲它——那是这一层里我认为最被低估的一件装备。
这一层的一切进步，都是同一时刻发给所有人的
现在把上面盘点的所有东西放回总纲那个问题里过一遍：模型升级、harness 变强、协议标准化、Linear 上多了一个可以 assign 的 agent——这里面有哪一样是只帮你、不帮你的对手的？
一样都没有。
模型升级是按版本号发布的公共事件。MCP 和 AGENTS.md 被捐给基金会之后，接入外部系统的能力对所有人一视同仁。Routines 这种云端自治，你能用，跟你做同一件事的人也能用，而且是同一天开始用。Cyrus 是 Apache-2.0 的开源项目，谁都能 clone。
这一层不存在任何形式的私有积累。你今天花两周把工具链调到极致，三个月后有人花两小时装个默认配置就到了你 80% 的位置——因为那两周里有一大半时间，是被踩坑、被过时教程、被前面那种「Claude Code 支持 AGENTS.md」的错误信息消耗掉的，而这些坑随生态成熟会自动消失，消失的收益全行业均分。
所以这一层的正确策略只有一句：配到够用，然后停手。
问题在于「够用」这个词太软了，软到每个人都能自我说服「我还没到够用」。所以我想给一组可操作的判据。
「够用」的五条判据
我自己在用的标准是这五条，全部满足就该停手，去看上一层。
第一，你有一份被真正遵守的项目级规则文件。 不是「我写了一个 CLAUDE.md」，是「agent 的产出确实符合里面写的规范」。判断方法很简单：翻一下最近十次 review 的评论，如果同一条意见出现了三次以上，说明这条规则要么没写进去，要么写了没被遵守。
第二，你有一条能在本地和 CI 上一键跑完的验证链路。 测试、lint、类型检查、构建，一个命令，退出码 0 或非 0。这条链路的意义不是「保证质量」，是给 agent 一个它自己能读懂的反馈信号。没有它，所有验证工作都会回流到你身上。这是五条里最重要的一条。
第三，你有隔离的执行环境。 一个任务一个工作区，agent 搞砸了不会污染你的主分支。
第四，你有一个任务入口。 Linear、GitHub Issues 还是一个 markdown 文件都行，关键是任务描述和验收标准有固定落点，而不是每次在对话框里现编。
第五，你的瓶颈已经不在「做得慢」上了。 这是终局判据。如果你诚实地问自己「这周为什么没交付更多」，答案不是「写得不够快」，而是「我审不过来」或「我不知道该做什么」——恭喜，这层的任务完成了。
反过来，有几个信号说明你过配了：每周花在调工具上的时间超过用工具的时间；能说出五个 agent 编排框架的区别，却说不出你上一个功能的用户是谁；CLAUDE.md 长到 500 行，而 agent 依然在犯里面明确禁止的错误。
最后这条，正好是官方那个「200 行以内」建议的真实含义。规则文件不是越长越好，因为它不是文档，是每次对话都要挤进上下文的常驻负载。 写到 500 行的时候，前面 200 行的权重就被稀释了，你实际上是在用增加规则的方式削弱规则。写规则文件的正确心态更接近写宪法而不是写手册：只写那些「违反了就必须打回」的硬约束，其余的交给测试去管。
真正的瓶颈是 review 带宽，不是执行带宽
执行带宽可以并行、可以复制、边际成本趋近于零。review 带宽长在一个人的脑子里，串行、不可复制、每天就那么多。这两件事扩张的方式完全不同，而生产层的所有装备都只作用于前者。
这是这篇文章的核心。
回到开头那个早晨。我夜里开十个 agent 的成本和开三个几乎一样——多开七个任务只是多敲七次命令。但我早上要读的东西变成了三倍多。这中间的不对称，是整个「并行 agent」叙事里被系统性掩盖的部分。
执行带宽 review 带宽
可并行 · 可复制 · 边际成本趋零 串行 · 不可复制 · 每天恒定
agent × 1 ─┐
agent × 2 ─┤
agent × 3 ─┤ ┌────────────┐
agent × 4 ─┼──► 10 个 PR ──────────► │ 你 │ ──► merge
... ─┤ └────────────┘
agent × 10 ─┘ ▲
│
你每天还是只有那几小时
而且是注意力质量最好的那几小时
有人会说：那我让 AI 帮我 review 不就行了。
这个想法我试过，也确实有用——AI review 能捞出低级错误、能查风格违规、能提醒你某个函数没处理空值。但它解决不了 review 里最贵的那部分。review 的成本不在「读懂这段代码做了什么」，在「判断这段代码该不该这么做」。
后面这件事需要的东西，agent 手上没有：这个模块三个月前为什么被写成现在这个别扭的样子、这个看起来多余的判断其实是在兜某个上游系统的 bug、这个抽象现在做了未来半年会变成负担、这个改动技术上正确但和产品方向不一致。这些信息不在代码里，也不在文档里，它们在你的记忆和判断里——那属于第三层。
所以你可以把 review 的机械部分外包出去，这确实能压缩单个 PR 的耗时，也确实应该做。但你压缩不掉判断部分，而判断部分恰恰随并行度线性增长。
更糟的是，review 带宽还有一个执行带宽没有的性质：它会疲劳，而且疲劳的表现形式是「看起来还在工作」。
写代码写累了，你会明显感觉到写不动，产出直接停。审代码审累了不会停——你会继续审，只是审得越来越浅。从第一个 PR 到第八个 PR，我逐行读、扫 diff、看行数、直接合，这个下滑过程中没有任何一刻我觉得自己「停止工作了」。review 带宽的耗尽是无声的。
一条我亲自走完的因果链
于是就有了下面这条链，我把它画出来是因为它有一个自加速的闭环，而那个闭环是真正致命的部分。
PR 堆积
│
▼
逐行读不完 ──► 降级成粗审（看 diff 行数、看测试过没过、看描述写得像不像话）
│
▼
「看着合理」的烂代码进 main
│
├──► 重复实现（agent 不知道三个月前有个同款函数）
├──► 抽象错位（每个 PR 局部最优，合起来没有形状）
└──► 隐性行为改变（边界条件被悄悄改掉，测试没覆盖）
│
▼
下一批 agent 读着这份已经变糟的 main 干活
│
▼
它的产出质量进一步下滑，需要更多 review
│
└────► 回到第一步，而且这次更堆积
关键在最后那个回环。你的代码库是 agent 的上下文。 一份混乱的 main 会让下一批 agent 产出更混乱的代码，因为它们会忠实地模仿现有的风格、复用现有的（错误的）抽象、跟随现有的（不一致的）命名。
这跟人类团队的技术债不太一样。人类团队里，一个有经验的工程师看到烂代码会皱眉、会绕开、会提出重构。agent 不会——它会把你代码库里的一切都当成合理的先例。 于是技术债不再只是「以后要还的钱」，它变成了「污染下一批产出的输入」，而且这不是能靠「等以后有空再重构」推迟的问题：「以后」的每一天，那份烂代码都在教下一批 agent 怎么写代码。
唯一有效的扩张手段是提高一次做对率
既然 review 带宽扩不了，唯一的出路是让每个 PR 需要的 review 更少。这不是省事，这是这一层唯一真正的杠杆。
假设你每天能认真 review 三个 PR。想每天合并六个，你有两条路：把 review 能力翻倍（做不到，前面论证过了），或者让六个 PR 里有三个不需要认真 review——它们的正确性由别的机制保证，你只需确认「机制生效了」。
第二条路是唯一可行的，而它要求的东西是一次做对率。
一次做对率上去之后，review 的性质会变。它从「逐行读代码，找出哪里错了」降级成「看测试和 PR 描述，确认这确实是我要的东西」。前者的成本随代码量增长，后者几乎是常数。这个降级，是并行 agent 唯一真正的解锁条件。
要做到这件事，有三件事必须在 agent 开跑之前做完。
把规则前置
绝大多数 review 意见是可以被预防的。你在 review 里写的每一条「这里应该用项目里已有的 X」「这个错误处理不符合我们的约定」，都说明有一条规则没有被前置。
所以我的做法是：发现自己在重复一条 review 意见时就停下来，把它写进规则文件，而不是写进 PR 评论。 写进评论只修好这一个 PR，写进规则文件修好未来所有 PR。
这件事的收益是复利的，但受制于前面那个约束：规则文件不能无限膨胀。我的取舍标准是三条：
- 能被测试自动检查的，不写进规则文件，写成测试。 测试是更强的约束，它不依赖 agent 的顺从性。
- 只在某个目录下成立的规则，不写进根目录的规则文件。 放到那个目录里去，或者写成一个 Skill 按需加载。
- 只写「违反了就必须打回」的硬约束。 「最好这样」「建议那样」这种软规则，在长上下文里的实际遵守率很低，写了只是让你自我感觉良好，同时稀释了硬规则的权重。
把验收标准写进工单
这条是我受益最大、也最容易被跳过的一条。
大多数人给 agent 的任务描述是这样的：「给用户设置页加一个导出数据的功能」。然后 agent 交回来一个东西，你 review 的时候才开始想「诶，导出应该是同步还是异步」「大数据量怎么办」「格式是什么」「要不要限流」。
你在 review 阶段想这些问题，就意味着 review 承担了本该属于需求定义的工作——而这部分是 review 里最贵的，它需要你完整地重建上下文。
正确的做法是把这些问题在工单里就回答掉。我现在的工单模板大概是这样：
- 目标：一句话说清要解决的问题（不是要写的代码）
- 不做什么：明确排除掉的范围，这条比「做什么」更能省 review 时间
- 验收标准：一组可以被逐条勾掉的判断句，最好每条都能对应一个测试
- 相关文件：告诉它该改哪儿、别碰哪儿
- 已知约束：那些「代码里看不出来但你必须知道」的东西
写这么一份工单要十五分钟。但它换回来的是：agent 的产出方向从一开始就是对的，我 review 的时候只需要逐条核对验收标准，而不是从零开始判断这东西对不对。
这里有个我一开始没想明白的点：写验收标准的过程，本身就是判断层的工作。也就是说，当你把生产层调到够用之后，你的时间不是被解放了，是被转移到了上一层。 这正是这个系列想说的事——第三篇会专门讲这个转移。
让 agent 自己跑到绿再开 PR
这条是三条里技术含量最低、收益最大的。
如果你的 repo 里有一条能自动跑的验证链路，并且你在规则文件里明确要求「所有测试通过之后才能开 PR」，agent 会自己进入一个循环：改代码、跑测试、看到红的、修、再跑，直到全绿。
这个循环的价值不在于「测试保证了质量」——测试保证不了多少质量，尤其是当测试本身也是 agent 写的时候。它的价值在于：它把一大类低级错误的发现成本，从「你的注意力」转移到了「机器时间」。 机器时间可以并行、可以复制、边际成本趋零，你的注意力不是。
这也是「测试」在这一层的地位被严重误判的地方。在传统语境里，写测试是一件为了可维护性做的、有点无聊的、经常被砍掉的工程实践。在 agent 语境里，测试是 agent 的感知器官。没有测试，agent 是个瞎子，它唯一的反馈来源是你；有了测试，它有了一个不消耗你注意力的自我校验回路。
这也解释了一个现象：为什么同样用 AI，有些人的效果远好于另一些人，而差距和用哪个模型基本无关。差距在 repo 上。一个有完整测试、清晰边界、快速反馈的 repo，agent 在里面能自我纠错到很远；一个没有测试、跑一次要五分钟、跑完还不知道对不对的 repo，agent 只能靠猜，猜完的验证责任全部落到你头上。
这一层真正的私有积累，不是你会用哪个工具，是你的 repo 有多适合 agent 干活。 这可能是生产层里唯一带一点资产性质的东西——因为它是你自己一点点建起来的，别人复制不走。
隔离是并行的前提
在没有隔离的情况下谈并行，是在谈灾难。
这条道理简单到有点无聊，但我见过太多人在这上面栽跟头，包括我自己。
如果十个 agent 都在同一个工作目录里干活：它们会互相覆盖对方改的文件；一个跑测试的时候另一个正在改代码，测试结果毫无意义；你 review 的时候分不清哪个改动属于哪个任务；某一个搞砸了，你没法单独回滚它。
正确的形态是 Cyrus 那个做法：一个 issue，一个 git worktree，一个分支，一个 PR。
git worktree 存在很多年了，绝大多数人从来没用过。它让你在同一个 repo 上同时 checkout 多个分支到不同目录，共享同一份 .git，但工作区完全独立。在 agent 时代之前，这个功能的使用场景很窄——一个人同时也就写一个分支。在 agent 时代它变成了基础设施。
my-repo/ ← 你自己在这儿，main 分支，随时可用
.worktrees/
├── issue-142/ ← agent A：claude/issue-142
├── issue-143/ ← agent B：claude/issue-143
├── issue-147/ ← agent C：claude/issue-147
└── issue-151/ ← agent D：claude/issue-151
四个 agent 同时跑，互不可见
每个跑完开一个 PR，你在 PR 层面串行审
任何一个搞砸了，rm -rf 那个目录，成本为零
这个结构有三个我很看重的性质。失败是廉价的——agent 把某个 worktree 搞得一团糟，删掉重来的成本是零，这极大地改变了心态：你可以放手让它试激进的方案，因为失败不传染。你的主工作区永远可用——你不需要在 agent 干活的时候「让开」，这听起来是小事，实际上是能不能真正并行的分水岭。review 的边界和任务的边界重合——一个 PR 对应一个 issue 对应一组明确的验收标准，这让 review 有可能从「读代码」降级成「核对标准」；如果一个 PR 里混了三个任务的改动，这个降级就不可能发生。
再回头看 Routines 那个「默认只能 push 到 claude/ 前缀分支」的设计，你会发现它和 worktree 是同一个思路的两个层面：不要试图让 agent 不犯错，要让它犯错的时候碰不到重要的东西。 这是这一层最值得内化的一条工程直觉。
现在说不好听的部分
前面所有关于「怎么把这层配好」的讨论，都建立在一个前提上：AI 生成的代码是可用的。这个前提在功能正确性上大体成立，在质量和安全性上，实证数据相当不好看。
我要在这里放几组数据。放它们不是为了唱衰——我自己每天重度使用这些工具，这个系列本身也是在这套工作流里写出来的。放它们是因为，这些数据恰好解释了前面几节为什么要那么强调 review、测试和隔离。 如果 AI 生成的代码天生可靠，那些工程就是多余的；正因为它不可靠，那些工程才是这一层的主装备而不是可选项。
安全性：越大的模型没有让代码更安全
Veracode 的 2025 GenAI Code Security Report 做了一个我认为设计得很好的实验：80 个编码任务，一百多个 LLM，覆盖 Java、Python、C#、JavaScript。
结果：45% 的代码样本未通过安全测试，引入了 OWASP Top 10 类别的漏洞。XSS（CWE-80）相关的样本里，86% 未能正确防御。Java 最差，失败率 72%。
但这份报告最有杀伤力的结论不是那些百分比，是这一句：模型写「功能正确」的代码越来越好，但写「安全」的代码没有改善，而且与模型规模无关。
这句话直接击穿了一个非常流行的辩解——「现在是有点问题，但下一代模型会解决」。数据说的是：这两条曲线是分开的，功能正确性那条在往上走，安全性那条是平的。它们不共享同一个改进机制，所以你不能假设后者会跟着前者一起改善。
我的理解是：功能正确性有明确的反馈信号——跑不跑得起来、测试过不过、用户报不报错，这些信号在训练数据里大量存在。安全性没有这个信号。一段有 XSS 漏洞的代码，在所有功能测试里都是绿的，看起来和安全的代码一模一样，它只在被攻击时才暴露，而那一刻通常不会以「代码 + 标注」的形式回到训练数据里。
所以安全性不会被模型规模自动解决，它只能被工程解决。 而工程手段就是那几样老东西：安全测试进 CI、依赖扫描、最小权限、代码审查里专门看输入边界。它们在 agent 时代不是变得不重要了，是变得更重要了——因为产出的代码量上去了，而每一行的安全期望值没变。
一个具体的案例
抽象数据不太有画面感，所以补一个具体的。
2025 年 3 月，开发者 Leo Acevedo 公开炫耀他的 SaaS 产品 EnrichLead 完全由 Cursor 生成，“zero hand-written code”。这条帖子病毒式传播之后，大约两天内产品就被攻破了：有人绕过订阅付费、篡改数据库数据、把 API key 跑爆。事后梳理出的缺陷是：没有认证、数据库直接暴露、没有速率限制、没有输入校验、密钥泄露在前端。
最值得玩味的是后面那一段：他尝试用 Cursor 修复，但 AI「不断弄坏其他部分的代码」。应用在一周内下线。
重点不在「AI 写的代码不安全」，在后半段。他之所以修不好，不是因为 AI 修不了单个漏洞（那些漏洞每一个都不难修），是因为他手上没有任何验证机制能告诉他「修完这个有没有弄坏别的」。没有测试，没有隔离，没有可回滚的边界，只能靠肉眼在一个自己从没读懂过的代码库里打补丁。
这正好是前面那三条的反面教材：规则没前置、验收标准不存在、没有能自我验证的测试。「zero hand-written code」不是问题所在，「zero verification」才是。
可维护性：一组要打折扣看的数据
GitClear 的《The Maintainability Gap》（2026 版）分析了 2023 到 2026 年间 6.23 亿次真实代码变更，结论包括：copy/paste 代码占比从 2022 年的 9.4% 升到 2026 年上半年的 15.7%；代表「正确重构」的移动代码从 21% 跌到 3.8%；块级重复度较 2023 年上升 81%；跨文件函数调用下降 35%。
翻译成人话就是：代码在变多，复用在变少，重构在消失。 agent 倾向于「就地写一份新的」而不是「找到已有的那份复用它」——这很好理解，写一份新的对它来说更简单、更不容易出错，而且它未必知道那份已有的存在。
这里必须加一句免责：GitClear 是一家卖代码分析工具的商业公司，它的产品价值恰恰建立在「代码质量正在恶化」这个叙事上。 明确的利益相关，数据要打折扣看。
不过方向性判断我倾向于认可，因为它和一个我能自己验证的现象吻合：在我自己的 repo 里，agent 确实反复写出功能重复的辅助函数，而这件事只有 review 时才看得出来——它在任何自动化检查里都是绿的。
团队层面：AI 放大团队，不修复团队
最后一组数据来自 DORA 2025 报告（dora.dev/dora-report-2025），样本是近 5000 名全球从业者，比前面几个都大。
基本盘：AI 采用率 90%（同比增长 14 个百分点）；每天与 AI 协作的中位数是 2 小时；超过 80% 的人自报生产力提升。
核心张力在这儿：AI 采用与交付吞吐量正相关，但与交付稳定性持续负相关。 也就是说，东西出得更多了，但变更失败率更高、返工更多。
DORA 的定性结论我认为是这几组数据里最有价值的一句：「AI 不修复团队，它放大团队。」 报告指出，价值真正的来源不是工具本身，而是周边的工程实践——自动化测试、版本控制成熟度、快速反馈回路。
这句话是我前面整个第五节论证的最强支撑，而且它把因果关系摆正了：不是「用了 AI 所以效果好」，是「本来就有好的工程实践，所以 AI 放大了它」。反过来，本来就没有测试、没有快速反馈、main 分支一团乱麻的项目，接入 AI 只会更快地烂掉。
这也解释了为什么「装备清单」这种东西天然是误导性的。 它列的是工具，而决定效果的是工具之外的那些东西——那些东西不在清单里，因为它们不能被购买、不能被安装、只能被建设。
关于速度本身，一个必要的补充
总纲 里已经详述过 METR 的研究，这里只取论证需要的部分。
2025 年 7 月那项研究（arXiv:2507.09089）：16 名开发者、246 个任务，都在自己熟悉的成熟开源项目上工作，随机分配「允许用 AI」和「禁止用 AI」。结果是允许用 AI 时耗时多了 19%，而这些开发者事前预测提速 24%、事后仍认为提速了 20%。
必须一并交代 METR 在 2026 年 2 月的后续更新，否则这个数字会被误用：第二轮实验规模大得多，结果转为「提速」，但 METR 自己认为信号不可靠——大量开发者拒绝参加，30% 到 50% 的参与者承认故意不提交那些 AI 能大幅加速的任务。他们的结论大意是：倾向于认为 2026 年初的开发者确实比 2025 年初被加速得更多，但证据很弱。
我把这个更新一并放进来，是因为不放的话「19%」会变成一个唱衰的口号。它不是。正确的读法是：这件事现在已经很难被干净地测量了。 而在一件无法被可靠测量、又能带来强烈主观加速感的事情上，你应该对所有具体的提效数字保持怀疑——包括你对自己的估计。
那这一层到底该怎么摆
整篇的判断可以收成一句话：生产层的目标不是「更快」，是「让快这件事不再是你的瓶颈」，然后立刻转身。
具体地说，我现在的优先级是这样：
- 先建验证链路，再建 agent 编排。 没有测试的并行 agent 是在给自己造技术债，而且是复利的那种。
- 先写规则和验收标准，再加并行度。 并行度的天花板是一次做对率，一次做对率不动，加并行度只是把 PR 堆得更高。
- 先做隔离，再谈自治。 让 agent 在你不在场的时候跑，前提是它跑砸了你什么都不会丢。
- 工具选型上不要追新。 这层的进步是公共品，你晚三个月接入一个新能力，损失约等于零；你花三个月追踪每一次更新，损失是三个月。
最后，也是最重要的一条：给这一层定一个注意力预算，超了就停。 我给自己定的是每周不超过两小时用于工具链的维护和探索。超过这个数，说明我在用「优化工具」来逃避「决定做什么」——后者难得多，也重要得多。
但产出如果不往上走，还是一次性的
回到总纲那个框架。四层不是并列的，是有方向的。
生产层的产出如果只停在「产品上线了」，它就是一次性的：赚一点钱，然后归零，下一个产品从头开始。你越是把这层调得高效，这种浪费就越大——因为你在更快地生产一次性的东西。
所以每一次生产层的产出，都应该同时留下三样东西：留在 repo 里的（那条被改进过的规则、那个补上的测试、那份理顺的目录结构，它们让下一次的一次做对率高一点点）；往上走到分发层的（这个东西是怎么做出来的、遇到什么问题、你的解法是什么——做的过程本身就是素材，不写下来就是白扔）；再往上到声誉层的（一次开源提交、一份被别人用上的工具，它们不产生直接收入，但决定了你下一个产品的冷启动成本）。
这三条管道如果不通，你就是那种「第四层强得离谱，但每次都从零开始」的人。我见过太多这样的人，也当过这样的人。这不是能力问题，是架构问题。
下一篇
有一句话我在写这篇的过程中反复想起来：当执行变得便宜，昂贵的东西不会消失，它只会换个地方待着。
这一篇讲的全部事情——review 带宽、一次做对率、验收标准、规则前置——最后都指向同一个方向。一旦你认真做这些事，你的时间会大量流向「想清楚要什么」，而不是「把它做出来」。写一份好工单要十五分钟，agent 执行只要三分钟。这个比例在两年前是反过来的。
这就是这个系列真正想说的那件事：生产层的成功，表现形式是判断层的成本暴露出来。
下一篇 讲第三层，判断层：需求闸门怎么守，验收标准到底该怎么写，以及最关键的——怎么把「判断」这件原本只存在于你脑子里的东西，外化成 agent 能反复读取的规则。那是这一层能从「个人能力」升级成「可复用资产」的唯一路径。
如果你读完这篇之后只记住一件事，我希望是这个：别再问「怎么让 agent 跑得更多」，开始问「怎么让每一个跑出来的东西，更不需要我」。
读者回响