AI 编程工具发布的时候，PPT 上永远只写一个数字：「提效 10 倍」。
没人写第二个数字：维护成本增加多少。
这周 Hacker News 上一篇文章火了——「我要回去手写代码了」（"I'm going back to writing code by hand"）。作者不是老古董，是一个用过各种 AI 编码工具后做出这个决定的开发者。帖子 121 分，51 条评论，评论区基本分成两派：一派说"终于有人讲真话了"，另一派说"你用错了工具"。
两边都有道理。
AI 写代码快，但维护别人的代码——哪怕是 AI 写的——从来不快
这个问题不是 2026 年才有的。软件工程界早就知道一个事实：读代码的时间远大于写代码的时间。AI 把这个不等式放大了。
当 Claude Code 或 Codex 能在 30 秒内生成 500 行代码时，你省下了写的时间。但三个月后，当这段代码出了 bug，你需要理解它为什么这么写、依赖了哪些隐式假设、改了某个变量会不会影响别的地方——这些时间一分都没省。
两个被忽略的成本
第一是审查成本。 AI 生成的代码看起来都对——语法正确、逻辑通顺、测试通过。但它可能引入了你不需要的抽象、过度设计的模式、或者一个只在特定边界条件下才会触发的 bug。审查 500 行 AI 代码的时间，可能比自己写 200 行还长。
第二是知识稀释成本。 如果你让 AI 写了核心业务逻辑，而你自己没逐行读过——那你的团队里就没有人真正"懂"这段代码。当问题出现时，没有人能凭直觉定位，只能从头读起。
但别急着扔掉 AI 工具
这篇 HN 帖子的评论区有一个高赞回复说得好："不是 AI 写代码有问题，是'无脑接受 AI 输出'有问题。"
AI 编码代理在以下场景确实是 10 倍提效：
- 样板代码（boilerplate）：CRUD 接口、数据模型定义、配置文件
- 已知模式的重构：把 callback 改成 async/await，把 class component 改成 hooks
- 测试生成：基于已有代码生成单元测试框架
- 文档和注释：给复杂函数补充文档
但在以下场景，你要保持警惕：
- 核心业务逻辑：这里每一个判断都有业务含义，AI 不理解你的业务
- 性能关键路径：AI 倾向于写"正确"的代码，不一定是"快"的代码
- 安全敏感代码：AI 可能遗漏边界条件检查，或者引入你不需要的依赖
一个实用的工作流
我在项目里的做法是：AI 生成，我审查；AI 建议，我决策。
让 Agent 写初稿，但每一行合并到主分支之前，我都要过一遍。不是逐行审，而是带着问题审：这段代码解决了什么问题？有没有更简单的写法？会不会在六个月后让接手的同事骂人？
如果答案是"不确定"，那就自己重写。
AI 编程的下一阶段
HN 评论区有人提到一个观点：真正的问题不是"AI 该不该写代码"，而是"我们还没建立起管理 AI 生成代码的工程纪律"。
代码 review 流程需要适应 AI 时代。也许未来的 PR 模板里需要加一个字段："这段代码有多少比例是 AI 生成的？你审查了哪些部分？"
也许 CI 流水线需要加入 AI 代码质量检测——不是检测"是不是 AI 写的"，而是检测"这段 AI 代码的可维护性如何"。
这些基础设施还没成熟。但迟早会有。
主要来源：