代理写代码时代，软件团队还靠什么守住质量：四条务实的工程闸门

配套的评测同样值得看。团队用 Codex、Claude 等代理跑 200 个任务，落地约 1700 条基于 Playwright 和 AST 的断言：无引导时通过率 55%，装载技能包后 92%。这条数据的意义不在于分数本身，而在于它回答了一个此前含糊的问题——代理不是"不知道"这些平台能力，而是"知道名字但不用"。这是两种完全不同的失败模式：前者需要补知识，后者需要补约束。

换句话说，过去写进团队 wiki、藏在资深工程师脑子里、靠 code review 口口相传的那部分隐性知识，第一次有了可被机器批量消费的标准形态。对中小团队而言，这可能是短期内性价比最高的一次工程基建投入。

运行时收紧基线：工程确定性被重新定价

同期，运行时层面也在发生类似方向的调整。.NET 11 更新了最低硬件要求：在 x86/x64 上，三大平台的 JIT/AOT 基线从 x86-64-v1 提升到 x86-64-v2，Windows Arm64 侧要求 LSE 指令集，ReadyToRun 编译目标在 Windows 和 Linux 上进一步提升到 x86-64-v3（包含 AVX2、FMA、BMI2 等）。官方文档明确写着：.NET 11 在更老的硬件上将无法运行，并会给出"当前 CPU 缺少基线指令集"的提示。

这类变更表面上是兼容性收紧，实质上是把"运行环境的不确定性"显性化了。指令集基线决定的是：你的 JIT/AOT 路径在什么条件下可以确定性地跑出同样的性能。把它写死在文档里、写进部署检查项里，远好过在某个客户的旧服务器上偶发地慢十倍。

对工程团队的启示是通用的：把隐式假设显式化。代理特别喜欢"能用就行"的实现——它不会去追问这个进程在 32 位容器里会不会溢出、这个浮点数比较在边界上是否可靠、这个重试逻辑在网关超时后会怎样。人的职责，正在于持续把这些假设问出来、写进 CI 检查、写成可以自动失败的断言。

把质量闸门前移：代理时代，一个务实的交付流程

综合这两条线索，一个相对稳妥的做法已经浮出水面。它不反对用代理写代码——事实上完全不用代理的团队，如今在效率上很难竞争。真正需要重新设计的是交付流程里的几道闸门。

第一道是让代理先读约束，再写代码。把团队的架构约定、禁用的写法、必须使用的平台能力，整理成一份机器可读的项目约定文件，让它在生成之前就加载。这比事后 review 高效得多，因为拦截一个错误实现的成本，永远低于在生产环境里定位一个由它引发的故障。

第二道是把测试标准从"覆盖率"改成"场景清单"。人工维护一份面向真实用户的场景列表：空数据、弱网、重复提交、越权、版本不匹配、支付回调乱序。代理负责把这些场景实现成自动化用例，但清单本身由人定义。这条改造的价值在于，把"隐性的产品知识"重新变成了可执行资产，而不是指望模型从代码里反推出来。

第三道是给代理装上"遗留扫描"。无论是现成的开源方案还是自研规则，在 CI 里定期跑一遍，识别那些"能跑但明显不划算"的老写法。对存量项目而言，这类改造的投入产出比往往高得惊人——既减少了技术债，也在一定程度上缓解了"没人真正懂这套代码"的问题。

第四道是保留人工架构评审的最终决定权。代理擅长在既定边界内做实现，不擅长决定边界本身。哪些数据该进缓存、哪些接口将来需要版本化、哪些表结构一旦定下来就很难改——这些决定必须由懂业务连续性的人来做，而且要在数据模型定型之前做。

对做定制开发的团队来说，这四道闸门还有一个额外好处：它们沉淀下来的不只是代码，还有可复用的工程资产。下一个项目启动时，约束文件、场景清单、规则库都能直接复用——这是纯人力堆项目永远做不到的规模化。

结语

代理写代码这件事不会回退，也不应该回退。它把工程师从样板代码里解放出来，也让小团队第一次有了和大团队竞争的可能。但速度从来不是软件工程的目标，可维护性才是。

接下来的一年，真正会拉开团队差距的，不是谁用代理用得更狠，而是谁把工程约束建设得更扎实：当 AI 生成的代码从 55% 的通过率走向 92%，那个 92% 里装的是团队的知识；而当它只停在 55%，那个数字背后藏着的，就是下一次凌晨三点的告警。