AI 编程的隐性成本：在效率与失控之间找到平衡点
最近 Hacker News 上一篇「What AI Coding Costs You」引发了热烈讨论（277+ points），作者 Tom Wojcik 提出了一个很多开发者回避但必须面对的问题：AI 编程的效率提升是真实的，但那些不会出现在任何 dashboard 上的隐性成本，你算过吗？
一条频谱上的定位
Tom 画了一条很直观的频谱：最左端是纯人工编码，最右端是完美 AGI。我们每个人都在这条线上的某个位置，而这个位置每周都在右移。
问题在于：用 AI 太多和用 AI 太少，哪个风险更大？
这个问题的答案并不固定——它取决于你在做什么。写一个 CRUD 接口？AI 几乎可以全权代理。设计一个分布式系统的一致性模型？你最好自己想清楚。
Agent 时代的幻觉与现实
从 Copilot 的自动补全，到 Cursor 的上下文感知，再到如今各种 coding agent 承诺「一夜之间写完功能」——我们经历了从「AI 辅助人类编码」到「人类辅助 AI 编码」的范式转换。
但现实很骨感。很多开发者尝试 agent 模式后发现：
- Agent 犯大量小错误，每个都不致命，但累积起来调试成本惊人
- 陷入循环——修一个 bug 引入两个新 bug，然后继续修
- 幻觉依赖——引用根本不存在的库或 API
- 代码看起来对，但语义不对——最危险的那种错误
这些成本在你衡量「AI 帮我省了多少时间」时往往被忽略。你省了 30 分钟写代码的时间，但花了 2 小时 debug AI 写的代码——净亏 90 分钟。
真正的成本不在代码里
除了直接的调试成本，还有几个更隐蔽的代价：
1. 理解力退化
当 AI 帮你写了大部分代码，你对系统的理解会逐渐变浅。短期没问题，但当线上出了 AI 没见过的 bug 时，你发现自己对自己的代码库已经陌生了。
2. 审查疲劳
AI 生成代码需要 review，但人类天生不擅长审查大量「看起来正确」的代码。这和安检员连续看几小时 X 光片会漏检是一个道理。你的 review 质量会随着 AI 输出量的增加而下降。
3. 技术选型的惰性
AI 倾向于推荐它训练数据中最常见的方案，而不是最适合你场景的方案。久而久之，你的技术栈会向「AI 最熟悉的方案」收敛，而非「最优方案」。
找到你的平衡点
我的实践建议：
把 AI 当高级实习生，而不是高级工程师。 它能快速产出初稿，但你必须 review 每一行。不要因为它的输出「看起来专业」就降低审查标准。
区分「生成」和「决策」。 让 AI 帮你生成代码、写测试、处理模板化工作。但架构决策、性能关键路径、安全相关代码——这些必须是你自己的判断。
定期「裸写」。 每周花点时间不用 AI 辅助来写代码。保持手感，保持对代码的直觉。就像用导航的人偶尔也该看看地图，否则离了导航就迷路。
追踪真实的时间成本。 不只是「AI 帮我写了多快」，还要算上 debug、review、返工的时间。你可能会发现某些场景下 AI 其实在拖慢你。
写在最后
AI 编程工具正在以周为单位进化，今天的局限可能下个月就被突破。但「理解你在用什么、付出什么代价」这个原则不会变。最好的开发者不是用 AI 最多的，而是知道什么时候该用、什么时候该自己来的。
对了，如果你想体验不同 AI 模型在代码生成上的差异——比如 Claude 和 GPT 谁更擅长 debug、Gemini 处理长上下文时表现如何——可以试试 OfoxAI（ofox.ai），一个账号聚合了主流模型，切换对比非常方便。