AI 让代码变便宜了，但工程变贵了

上周我让 Claude Code 重构一个模块，它 8 分钟交了份完美的 PR——类型对、测试过、命名规范。

我花了 45 分钟才敢合。

不是因为代码有问题。是因为我不确定它改动的三个文件会不会影响另外两个它没碰的文件。

这件事让我意识到一个正在发生的经济学翻转：代码变便宜了，但工程变贵了。## "代码免费"之后暴露了什么

Honeycomb 的 CTO Charity Majors 最近写了一篇文章，标题是《AI Demands More Engineering Discipline, Not Less》。她说：

代码行从被珍视、复用、精心维护和仔细打磨，到几乎一夜之间变成可随意丢弃、随时重新生成的东西。

当"写代码"不再是瓶颈，真正的瓶颈就暴露了。

普林斯顿的 Arvind Narayanan 研究了软件工程师为什么没被取代，他发现三个 AI 干不了的事：决定构建什么（需求定义、边界划定、方案选型）、验证交付物（确认它真的对了，而不是"看起来对了"）、以及对代码库和业务的深层理解。

AI 加速了中间那段"把想法变成代码"的过程，但两头没动。两头是最贵的。

哪些成本在飙升

决策成本

以前写一个功能要一周，错了就错了，反正也就浪费一周。现在 Agent 10 分钟给你三个方案，每个都能跑。选哪个？

代码越便宜，你做出错误决策的速度越快，积累的方向性错误越多。

验证成本

Narayanan 的研究里有个被忽略的发现：开发者花时间最多的两件事是"开会"和"调试"，不是写代码。AI 把写代码的时间压缩了，但调试时间反而可能增加——因为你在调别人写的代码，而这个"别人"每次上下文都不一样。

以前写一个 bug，你大概知道它藏在哪，因为代码是你亲手一行行敲的。现在 Agent 生成 500 行，出了问题你得从头读起——读一段你不熟悉的、风格可能跟上次不一样的代码。

测试全绿不等于你理解了它在做什么。理解这件事没法自动化。

一致性成本

Agent 每次会话都是无状态的。它不记得上次为什么这样设计，不知道你的命名规范在第三次 refactor 时改过。你让它改文件 A，它不知道文件 B 有个隐含依赖。

你以为配了 CLAUDE.md 它就会遵守。实际上——

关联 ≠ 加载 ≠ 读到 ≠ 遵守。

"我配了一个文件"和"这个文件真的影响了模型决策"之间隔着四道关卡，每道都可能悄悄漏掉。代码越多，保持系统一致性的成本越高。

基础设施成本

以前你一个人写代码，脑子就是最好的 CI。现在你管着一个 Agent 团队，7×24 帮你写。你需要测试套件、类型系统、明确的规范文档、可观测性——否则你既不知道它改坏了什么，也不知道生产环境什么时候炸。

llama.cpp 的作者 Georgi Gerganov 每天用本地模型干活，但他第一件事是搭 harness——系统提示词、约束文件、审查流程。不是因为模型不够强，是因为模型越强，没有护栏越危险。

独立开发者该怎么投资

时间有限，不可能什么都搭。按杠杆率排序：

测试最优先。不是为了"代码质量"这个抽象概念，是为了让你敢让 Agent 改代码。没有测试，Agent 每次改完你都要人肉 review 全量变更，比你自己写还慢。有了测试，改完跑一遍，绿了就合。

然后是规范文档。你写一次，Agent 每次会话都能读到。一次性投入、无限次复用。但写了不等于生效，你需要验证它确实被加载、被遵守。

再然后是类型系统和 Linter，让错误在编译期被拦住。Agent 写的代码量越大，静态检查的价值越高。

最后是可观测性。至少知道线上出了什么问题。当你的部署频率因为 Agent 而翻倍时，你需要一个比"用户来投诉"更快的反馈渠道。

代码免费了。决策、验证、一致性——这些"工程"的活儿，一分钱都没便宜。反而因为代码量暴增，变得更贵了。

所以我现在评估一个项目的健康度，不看它每周合多少 PR，看它合完之后有多少次要回滚。