AI Coding Agent 时代：代码越便宜，约束越贵

代码不再昂贵了，那什么变贵了？

　　二十多年前，Linus在Linux邮件列表上留下一句话：

Talk is cheap. Show me the code.

　　这句话后来几乎成了程序员圈最常被引用的"行规"：嘴上说没用，代码才是真章。

　　但在AI普及的今天，这个前提正在悄悄变化。不是代码不重要了，而是写出一段代码这件事，正在变得越来越便宜。

真正变便宜的，到底是什么？

　　过去，一个功能从想法变成代码，最大的瓶颈往往是人力：谁来写、写多久、熟不熟悉框架、会不会踩API的坑。今天，这一层成本被大幅压低了。你描述一个需求，Agent可以很快生成路由、服务、数据库访问、测试样例，甚至帮你改掉一轮报错。

　　所以很多人开始说：

代码免费了。

　　这句话有传播力，但也很容易误导。

　　因为真正变便宜的，不是"软件"本身，而是代码文本的生成成本。更准确地说，是代码生产的边际成本塌陷了。

　　但另一部分成本，并没有随之消失：

代码是不是符合真实需求？
边界是不是清楚？
异常路径有没有处理？
安全风险有没有暴露？
测试能不能证明它没有破坏旧逻辑？
半年后另一个人，或者另一个Agent，还敢不敢继续改？

　　这些成本没有因为AI会写代码而自动下降。在我看来，某些情况下，它们反而变得更贵。当代码生产的边际成本趋向于零，‘确定性’便成了系统中最昂贵的资产。

"代码免费"这句话，只讲了一半

　　为什么说更贵？因为代码生成速度越快，错误扩散的速度也越快。

　　PR产出越容易，验证、Review、测试、维护的压力就越大。过去一个工程师一天只能写几百行，坏结构扩散得慢，资深同学还能在Review里拦一拦。今天Agent一次可以生成过去几天的工作量，如果前面没有足够清晰的边界和约束，技术债也会以同样的速度被放大。

　　只讲"代码免费"这一半，很容易得出一个危险结论：

软件工程过时了。

　　但把另一半补上，结论恰好相反：

　　AI没有让软件工程过时，它让软件工程的杠杆变陡了。

那么，真正贵的是什么？

　　当代码生成的成本下降，真正变贵的是那些决定代码是否值得存在的东西：架构判断、模块边界、接口契约、不变量表达、测试体系、依赖规则、Review标准、上线后的反馈闭环。

　　这些东西过去看起来像"好工程师的额外讲究"，今天正在变成Agent能不能稳定产出的前置条件。

　　换句话说，Agent不是让工程基本功失效了，而是把工程基本功的收益放大了。

　　写代码的人按回车键的频率变高了，但让代码变得可信的那些工作，并没有自动发生。

　　所以，AI时代真正昂贵的，不是"写出代码"，而是：

　　让代码在长期演进中依然可靠。

　　如果说过去的口号是：

Talk is cheap. Show me the code.

　　那么今天更应该改成：

Code is cheap. Show me your constraints.

同一个Claude，两份代码库，输出为什么会分裂？

　　上一章讲了一个判断：代码生成变便宜了，但让代码长期可信、可维护、可演进的约束系统变贵了。我们看一个最小化的对照样例。

对照样例

　　我准备了两份功能等价的小项目，都是"用户注册 + 登录"。

　　两份项目跑起来的行为一模一样：注册一个用户、登录、登出，没有任何区别。区别只在代码组织方式。

　　版本A的目录结构很简单：

project_a/
├── app.py
├── helpers.py
└── requirements.txt

　　版本B的目录结构更明确：

project_b/
├── AGENTS.md
├── api/
│   └── auth_routes.py
├── application/
│   └── auth_service.py
├── domain/
│   └── user.py
├── infrastructure/
│   ├── password_hasher.py
│   └── user_repository.py
└── tests/
    └── test_auth.py

　　这里要特别说明一点：版本A不是"烂代码示范"。这种项目结构在原型设计和Demo上，比版本B更合理，因为短平快，功能不夸层。

　　版本A的问题不在于代码丑，而在于结构太扁平。

　　版本B的区别也不是"目录更多"，而是它把几个关键约束显式化了：

路由入口放在 api/
业务编排放在 application/
领域对象放在 domain/
密码hash、用户存储等外部实现放在 infrastructure/
测试放在 tests/
AGENTS.md 说明项目的分层规则和变更约定

　　然后我把同一个任务丢给Claude Code：

给注册流程加上忘记密码功能。

　　这时，两份代码库给Agent的"暗示"完全不同。

图1.版本A新加一个功能“给注册流程加上忘记密码功能”

图2.版本B新加功能“给注册流程加上忘记密码功能。”

版本A里，Claude Code更容易做什么？

　　在版本A里，所有东西都堆在一起。

　　app.py既是HTTP入口，又包含业务逻辑，还直接处理密码hash和用户存储。helpers.py看起来像一个通用工具箱，但里面到底应该放什么，没有明确边界。

　　这时Claude Code做"忘记密码"功能，最容易出现的是一组局部合理、整体危险的选择。

它可能会重新写一份密码hash逻辑。

　　因为现有hash逻辑散落在app.py里，没有形成一个明确的唯一入口。Agent能看到那段代码，但它未必能判断：这是不是团队约定的标准实现？能不能复用？有没有隐藏副作用？如果上下文不够清楚，重新写一份"看起来正确"的实现，反而是一个很自然的选择。

　　于是代码库里可能出现第二套密码处理逻辑。

　　单看新代码，它也许没错；但从系统角度看，密码策略开始分叉了。这是一个典型的需要引起警觉的信号：单点正确，全局错位。

它也可能把"重置令牌生成"塞进helpers.py。

　　因为没有更好的落点。helpers.py本来就像杂物筐，多放一个make_reset_token()看起来也合理。但这意味着以后任何人想理解"密码重置令牌是怎么生成、怎么过期、怎么校验的"，都要去杂物筐里翻。

它还可能把"发送重置邮件"直接写在路由函数里。

　　因为在版本A里，没有任何结构告诉它：外部副作用应该隔离在哪里，邮件发送应该通过什么接口注入，失败重试应该放在哪一层。最直接的做法就是：哪里需要，哪里调用。

　　这些选择的问题在于：每一个局部看起来都说得通，但合在一起会让代码库继续变扁、变散、变难改。

　　功能可能跑得起来，测试甚至也可能通过。但这个代码库每经过一次Agent之手，边界就更模糊一点。

版本B里，Claude Code更容易做什么？

　　版本B给Agent的提示完全不同。

　　它看到infrastructure/password_hasher.py，就更容易判断：这个项目里密码hash有一个明确入口。新增忘记密码功能时，它更可能复用这个模块，而不是重新写一套。

　　它看到application/auth_service.py里已经有register()、login()，也更容易延续同样的业务编排方式：接收输入、校验用户、调用hasher、调用repository、返回结果。

这不是凭空发明，而是延续已有形状。

　　它看到AGENTS.md里写着：

所有产生外部副作用的代码，例如发邮件、发短信、调用外部API，必须放在 infrastructure/ 下，并通过接口或依赖注入传给 application service。

　　那么它在实现邮件发送时，就更可能新建：

infrastructure/mailer.py

　　而不是把发送逻辑直接写进路由函数。

　　它看到tests/test_auth.py，也更容易顺手补上忘记密码相关测试。

　　这就是结构和约束的作用。

　　它不是保证Agent永远不犯错，但它会把Agent的选择空间缩小：

密码处理应该去哪里？
业务编排应该放哪一层？
外部副作用应该隔离到哪里？
新增功能应该补哪些测试？

　　这些问题，版本B已经提前给出了答案。

两个代码库给Agent的不是同一份上下文

图3.Claude Code看到的两个代码库

　　如图3所示，把两个项目的依赖结构画出来，差别会更直观。

　　版本A更像一团缠在一起的线球：app.py既是入口，又是业务，又是数据访问；helpers.py被到处import；新功能来了，只能继续往线球上绕一圈。

　　版本B则提供了更清楚的方向：api负责入口，application负责编排，domain放核心概念，infrastructure处理外部实现，tests承担行为验证。

　　更关键的是，版本B不只是"目录看起来更专业"。

　　它真正提供的是一组约束：哪些代码应该放哪里，哪些依赖方向是合法的，哪些能力应该复用，哪些行为需要测试证明。

　　同一个Claude，同一份任务，面对的其实不是同一个问题。

　　在版本A里，它面对的是一个开放空间：

"你看着办，放哪都行。"

　　在版本B里，它面对的是一个被剪枝过的空间：

"这个类型的问题，应该沿着这些边界解决。"

　　所以最后输出会分裂。

　　不是因为Claude在一个项目里聪明、在另一个项目里变笨，而是因为两份代码库给它的约束完全不同。

　　代码库不是Agent的背景板。

　　代码库本身就是Agent的示范、提示词和护栏。

　　结构越清楚，Agent越容易顺着结构继续生长；结构越混乱，Agent越容易把混乱复制并放大。

Agent看到的不是"你的项目"

　　很多人对AI编码工具有一个误解：以为Agent像一个老同事一样，真的"理解你的项目"。

　　这句话只对了一半。

　　今天的Coding Agent确实很强。它可以读文件、搜调用链、改代码、运行测试，再根据报错修一轮。它不是一个只会原地吐代码的补全器。

　　但它也不是一个真正长期待在你团队里的工程师。

　　它不知道你们过去三年为什么这么设计，不知道某个模块背后踩过什么坑，也不知道团队里那些没有写下来的口头约定。

它能使用的，主要是三类东西：

一是当前被读进上下文的代码和文档。
二是它通过工具临时搜索、运行、分析得到的结果。
三是你显式告诉它的规则，比如AGENTS.md、ARCHITECTURE.md、测试失败信息、Review要求。

换句话说，Agent不是在"拥有你的项目"，而是在根据当下拿到的证据，临时拼出一个项目模型。

　　这个差别很重要。

　　人类工程师改代码时，脑子里有很多隐含背景：这个接口为什么不能动，这个模块以前出过什么事故，这个命名为什么看起来别扭但必须保留。

　　Agent比当年的新人更不容易拿到这些背景，除非你把它们写进它能看到的地方。

　　所以，真正重要的问题不是：

Agent会不会写代码？

　　而是：

它写代码时，能看到哪些约束？

代码库既是示范，也是约束

上一章里，我们看到同一个 Claude Code，面对两份结构不同的代码库，会产生完全不同的输出倾向。

原因在于，你给 Agent 的不是一个孤立任务，而是：

任务 + 当前代码库示范 + 当前文档规则 + 当前测试反馈。

测试告诉它“这样做有没有坏”，结构告诉它“这件事应该怎么做”。前者是反馈，后者是方向。

所以，代码库越清晰，Agent 越容易延续清晰；代码库越混乱，Agent 越容易复制混乱。

结构是对Agent的剪枝

　　"代码库是示范"只是第一层。

　　再往深一层看，模块、分层、契约，本质上是在缩小Agent的选择空间。

　　扁平结构对Agent说：

这里什么都能放，你看着办。

　　清晰结构对Agent说：

这个类型的问题，只能沿着这些边界解决。

　　比如同样是实现“发送密码重置邮件”，扁平项目会给 Agent 留下很多看似合理的选择：写进路由、塞进 helpers、另建 utils，或者直接在业务逻辑里调用 SMTP。

但结构清晰的项目，会提前告诉它：外部副作用应该隔离在 infrastructure，业务编排应该留在 application，路由只负责入口。

这时，Agent 不是不能自由发挥，而是自由发挥的范围被提前剪枝了。

　　这就是工程约束的价值。

　　它不是为了让代码看起来更高级，而是为了减少Agent的自由发挥空间。

　　在长期代码库里，自由发挥往往就是漂移的开始。

为什么扁平结构危险？

　　有人可能会说：

AI现在写代码挺漂亮啊。变量名不差，格式也整齐。我的老项目虽然结构扁平，但Agent生成的新代码单看也还不错，问题有那么大吗？

　　问题就在这里。

　　扁平结构最危险的地方，不是让代码立刻变烂，而是让代码慢慢失去骨架。

　　它会每次只偏一点。每次都能跑。每次都看起来合理。但几个月后，整个项目的骨架就散了，修改与阅读变的更困难。

　　这里面主要有两种变化。

第一种，是浅模块的繁殖。

　　一个文件本来已经做了五件事。Agent做新功能时，很容易再往里面加第六件。

　　因为从它看到的上下文看，这个文件本来就什么都装。

第二种，是分层的消失。

　　没有明确边界时，Agent会倾向于就近实现。

　　HTTP路由里顺手写业务规则。业务规则里顺手写SQL。SQL旁边顺手发邮件。发邮件失败后再顺手写重试。

　　每一步都很自然，但每一步都在把层次揉碎。

　　这种混合不会立刻制造线上事故，但它会制造一个更隐蔽的问题：下一次修改会更难。

　　因为Agent下次再进来时，看到的就是一个更混乱的范本。

　　它会继续模仿这个范本。

　　于是每一次"局部合理"的生成，都会变成一次"整体结构"的漂移。

　　过去这种漂移也存在。人类工程师也会就近塞代码，也会把工具类写成杂物筐。但过去代码写得慢，坏结构传播也慢，资深同学还能在Review里拦一拦。今天Agent把代码生成速度放大了，坏结构的传播速度也被一起放大了。

　　这才是"代码便宜"时代真正可怕的成本：

　　不是写错一段代码，而是让错误的结构以更高速度复制自己。

Agent到底是怎么"读"代码的？

　　可以把Agent想象成一个能力很强的临时演员。

　　它演技很好，反应很快，台词也能自己补。但它不知道昨天导演怎么改戏，也不知道这个角色前三季发生过什么。

　　它能演出什么，完全取决于你现在递给它的剧本、场记、人物小传和现场反馈。

　　对Coding Agent来说，这些"剧本"就是：

上下文窗口里的内容
当前打开过的文件
搜索到的代码片段
工具调用返回的信息
测试和命令行输出
项目文档和规则文件
你刚刚说过的要求

　　所以它的限制不是"看不懂代码"，而是：

　　它看到的永远是被选择、被压缩、被截取之后的项目现场。

第一，它的工作内存有限

　　上下文窗口就是Agent当下能使用的工作内存。

图4.Agent的工作内存

　　这块空间要同时容纳系统提示、工具定义、项目规则、对话历史、读过的源文件、搜索结果、命令输出、测试报错。

　　一个稍微复杂的任务跑久了，上下文很快就会拥挤。这时，Agent系统通常会清理旧工具输出、压缩历史内容，或者把前面的对话总结成摘要。这些机制能缓解问题，但不能消灭问题。

　　因为压缩一定会丢细节。

　　比如一个约束，对于返回值对象：

这个项目统一用Result类型，不要直接抛异常。

　　如果这条规则只是写在聊天里，而没有进入项目文档、测试、类型约束或lint规则，那么长任务跑到后半场，它就可能被弱化，甚至丢失。

　　所以，重要规则不要只说一遍。

　　要把它写进Agent每次都能看到的地方：

AGENTS.md
ARCHITECTURE.md
CONTRIBUTING.md

　　更好的是，把它变成可执行约束：

测试
lint
类型检查
CI gate
架构依赖扫描

　　文档能提醒Agent，测试和规则能拦住Agent。

第二，它没有天然的团队记忆

　　人类团队里有一种很便宜的资产，叫共享记忆。

"按之前说好的方案来。" "这块先别动，上次线上出过性能问题。" "这个接口要兼容某个特定老客户。"

　　这些话在团队里可能一句就懂。

　　但对Agent来说，这些都不是天然存在的。当然，Agent可以通过文件、提交记录、issue、PR、文档、记忆机制，拿到一部分"过去"。所以问题不是它绝对没有过去。问题是：

没有被写入可检索媒介的过去，对Agent来说就等于不存在。

你脑子里的约定，不是约定。
会议里说过但没落文档的规则，不是规则。
Review里反复提醒但没有测试兜底的习惯，不是习惯。

只有被写进代码、文档、测试、规则、CI、脚本里的东西，才会稳定地进入Agent的世界。

基本功的杠杆变陡了

前面讲的是 Agent 这一边：它能写出什么，很大程度上取决于它看到了什么结构、什么示范、什么约束。但这件事还有另一半，在人这一边。AI 让代码生成变快了，但它没有让工程判断变得不重要。恰恰相反，它把工程判断的杠杆放大了。

过去，同样两个工程师，一个模块边界清楚、接口契约稳定、命名一以贯之；另一个想到哪写到哪、功能能跑就先塞进去。短期看，差距可能没那么夸张。毕竟代码都是人慢慢写，问题也是慢慢积累，Review 还有机会拦一拦。但到了 Agent 时代，这个差距会被迅速放大。

对前者来说，Agent 是加速器。因为代码库已经有清晰边界，Agent 只要顺着已有结构继续补代码，出错空间就会小很多。对后者来说，Agent 可能是放大器。因为代码库本来就没有骨架，Agent 每次进来都面对一个开放空间：哪里都能写，怎么写都像有道理。它生成得越快，漂移也越快。

所以，同样是使用 AI，最后的结果可能完全不同。有的人用 Agent，把团队产能放大；有的人用 Agent，把技术债放大。AI 放大的不只是个人能力，更是系统惯性。好系统被放大，坏系统也被放大。过去，工程基本功决定你写出来的代码质量。今天，工程基本功还决定 Agent 会不会跟着你一起写歪。

Agent 时代，工程团队要补上的四件事

接下来，几件事的优先级会变高。

第一，文档默认存在

AGENTS.md、ARCHITECTURE.md、CONTRIBUTING.md 不再只是给新人看的，也是给 Agent 看的。

第二，边界前置

不要等 Agent 生成一堆代码后再靠 Review 纠偏。先定义分层、依赖方向、接口契约和不变量。

第三，规则可执行

文档能提醒 Agent，测试、lint、类型检查、CI 和架构扫描才能拦住 Agent。

第四，重新学习老基本功

真正升值的不是记 API、抠语法，而是抽象、命名、模块、契约、不变量和复杂度控制。

推荐订阅源

博客园_首页