代码又便宜了：AI 编程真正丢的可能是意图

代码又一次变便宜了。

上一次，是很多公司把开发工作送到海外。成本低，交付快，代码质量也未必差。这一次，是开发者把需求交给 AI。几句话，一个函数、一段脚本、一个小模块就出来了。

真正反常的地方在这里：代码越容易出现，团队越可能失去对代码的掌控。不是没人写代码，而是没人能清楚说出它为什么这样写、出了事该怎么改、谁为这段逻辑负责。

原文作者提到自己早年在 Toledo 一家叫 Heartland Information Services 的公司工作。Heartland 做医疗转录服务，客户包括美国大型医院。这个业务听起来不像前沿科技，但系统停机不是小事。医生、手术、病历流程都可能被卡住。

所以，软件维护不是抽象的“技术债”。在这种场景里，它会变成医院流程能不能继续跑。

旧账：离岸开发把知识放远了

早 2000 年代，离岸开发很合理。

创业公司要省钱，要更快交付。把一部分开发交给海外团队，经济账能算通。原文也没有把印度工程师写成低质量代名词，恰恰相反，他承认很多工程师非常优秀。

问题不在能力，而在上下文。

业务为什么这样设计，医院客户有哪些例外流程，哪个分支是为了绕过历史限制，哪个字段不能随便动。这些东西不总在代码里，也不总在文档里。它们散在会议、邮件、电话、老员工记忆和客户现场里。

离岸开发把这层知识切开了。知识仍然存在，只是变远了。

这张表里最要命的是最后一列。

外包时代，至少有一个人知道“当时为什么这么写”。他可能在德里，可能在班加罗尔，可能隔着时区和组织边界，但人还在，意图还在，只是很难够到。

AI 时代更冷。代码可以直接出现，格式漂亮，语法正确，局部测试也过。可它背后未必有一个完整的人类设计过程。团队拿到的是结果，不一定拿到了理由。

新风险：写得越快，读懂越贵

这篇文章不该被读成反 AI。

原文作者说得很清楚，他每天用 AI，效率确实提高。我也不赞成把这事写成“程序员要完了”。那种说法太省事，也太粗。

真正的问题是成本迁移。

以前贵的是把代码写出来。现在贵的是读懂它、修改它、证明它安全、在事故后找到责任链。

Joel Spolsky 很早说过一句话：读代码比写代码更难。放到 AI 编程里，这句话更硬了。机器把“写”压得更便宜，人类要承担的“读”反而更重。

工程现场会很快感到这件事。

凌晨线上故障时，值班的人要判断哪一行能改，哪一行不能碰。新人接手半年后，要知道某个奇怪分支背后的业务约束。技术负责人要决定，一段自动生成的核心逻辑能不能进主干，能不能上线，出了问题谁解释。

这些都不是代码风格问题，也不只是测试覆盖问题。

测试能证明一部分行为。它不能自动告诉你为什么存在这个行为。注释能提供线索，但注释也可能只是安慰剂。真正稀缺的是组织知识：谁理解这段逻辑，谁知道边界，谁能承担修改后果。

“天下熙熙，皆为利来。”AI 编程工具的繁荣当然有经济账。开发者更快，团队更省，厂商卖更多 token 和订阅。这都正常。

但工程管理不能只看生成量。只盯速度，就是把旧时代按代码行数考核的烂账换个外壳拿回来。

受影响的人：别再只问能不能生成

这件事最先影响两类人：工程负责人，以及正在重度使用 AI 编程工具的开发者。

对工程负责人来说，采购 AI 编程工具不能只看“能省多少开发时间”。更该看三件事：

• 生成代码能不能被审查、追踪和解释；
• 核心路径有没有人类 owner；
• 代码评审、架构记录、测试和回滚机制能不能跟上生成速度。

如果这些条件没补上，采购可以慢一点，试点范围也该收窄。先放在内部工具、低风险模块、可回滚场景里跑。不要一上来就把核心业务逻辑交给一堆没人能解释的生成结果。

对开发者来说，AI 不能只当“自动补全加强版”。每次接受一段生成代码，都要多问一句：我能不能向下一个接手的人解释它？

能解释，再合并。解释不了，就继续拆、改、补测试、写下设计取舍。别把 prompt 当设计文档，也别把“跑通了”当理解完成。

开发者工具厂商的分水岭也会变。

如果大家都能生成一堆“还不错”的代码，长期护城河就不会停在“帮你写更多”。真正值钱的工具，要帮团队理解已有代码：这段逻辑从哪来，依赖谁，改了会炸哪里，哪些决策是历史包袱，哪些注释只是摆设。

接下来最该观察的，不是哪家模型又能多写几行代码，而是工具能不能把生成过程变成可追责的工程过程。

比如：能不能保留设计意图，能不能把需求、代码、测试、变更记录串起来，能不能让 reviewer 快速看到风险点，能不能在半年后帮新人还原当时的判断。

离岸开发留下的教训不是“别外包”。AI 编程也不该被简化成“别用 AI”。

真正的教训是：别把理解当副产品。

外包把知识放远了，AI 可能让知识从一开始就没被生产出来。代码便宜，不等于软件便宜。软件的账，迟早会在维护现场结算。