无序 Vibe Coding 的隐性代价
你的团队快了 3 倍，然后呢？
你的工程团队引入了 AI 编码工具。PR 数量翻倍，feature 交付周期缩短，开发者说体验很好。季度汇报上，这是一个漂亮的故事。
六个月后，你可能面对的是另一个故事：一个没人能维护的代码库，一份越来越高的 AI API 账单，以及一群困惑的工程师 — 他们不理解为什么工具明明在变强，交付却在变慢。
这不是假设。这是无序使用 AI 编码工具的必然结局。
两种 AI 编码，本质不同
2025 年初，Andrej Karpathy 创造了 "vibe coding" 这个词：你给 AI 一个 prompt，接受它生成的所有代码，不看 diff，跑起来就行，报错了就把错误信息贴回去再试。人是 prompt DJ，不是工程师。
一年后，Karpathy 自己提出了 "agentic engineering" 来描述另一种工作方式：AI agent 做实现，人做架构师和 reviewer，每个 diff 都经过审查，测试覆盖是前提而非可选项。
这两种方式的区别不在于是否使用了 AI，而在于一个简单的问题：你是否在 review 代码？
Vibe coding 有它合理的使用场景 — 周末 hackathon、个人脚本、快速验证一个想法。在这些场景下，代码质量不重要，速度才重要。问题是，越来越多的团队把 vibe coding 的方式用在了生产系统上。管理层看到的是"产出速度提升了"，看不到的是产出质量正在以一种隐蔽的方式崩塌。
退化不是线性的，是指数的
这是本文最重要的论点，值得慢慢说。
AI agent 生成的代码中，必然夹带一些不符合预期的东西。注意，这里说的不是 bug — bug 会被测试或运行时捕获。更危险的是那些"不致命但不对"的东西：冗余的抽象层、违反项目架构约定的实现、因为 context 不足而选择的次优方案、没有人会写但 AI 觉得合理的 anti-pattern。
如果有人 review，这些问题会被逐一拦截。如果没有人 review，它们就留在了代码库里。
然后事情开始加速。
现代 AI 编码工具在工作时，会把代码库中的相关文件加载到上下文中作为参考。当那些"不致命但不对"的代码累积到一定程度，它们被 agent 纳入上下文的概率就越来越高。Agent 会以这些代码为范本，生成更多风格相似的代码。更多的低质量代码进入代码库，进一步提高了它们被未来 agent 引用的概率。
这是一个正反馈退化循环：低质量代码累积 → 进入 context 的概率上升 → agent 以此为范本 → 生成更多低质量代码 → 累积加速。
退化的速度不是线性的。它是指数的。
如果你的团队在用并行 agent 工作流 — 多个 agent 同时处理不同任务 — 这个效应还会被同时运行的 agent 数量进一步放大。50 个 agent 同时以被污染的 context 为基础工作，退化速度是单 agent 的数十倍。
用工厂来类比：这就像质检环节被取消后，生产线上的次品被当作原材料送回了生产线。
退化的第二重代价：Token 成本的恶性循环
代码质量退化的代价不只是"代码变难维护"。它还有一个管理层更容易感知的后果：AI 的使用成本在上升，而产出在下降。
当架构持续退化、代码库变得混乱，agent 在其中推进任何任务都会变得越来越艰难。它需要反复尝试不同的实现方案，需要重构和重写之前的代码才能让新功能跑通，需要查询大量相关文件来填充自己的上下文以理解当前系统的状态。每一次尝试、每一次查询都在消耗 token。
更糟糕的是，当上下文被大量低质量代码和重试过程占满，留给"真正有用的信息"的空间就被挤压了。Agent 对当前任务的理解能力在下降，产出质量进一步降低，又需要更多轮重试。
这形成了第二重恶性循环：架构退化 → agent 推进困难 → token 消耗上升 → 上下文被低效内容占满 → 产出质量下降 → 架构进一步退化。
最讽刺的结局是：引入 AI 编码工具的初衷是降本增效，而无序使用的结果是增本降效。管理层会看到 AI API 账单逐月攀升，但很可能把原因归结为"用量增长"，而不是"效率下降"。
为什么管理层特别容易踩这个坑
因为短期指标全是正面的。
PR 数量上升了。Feature 交付周期缩短了。开发者满意度调查显示大家很喜欢新工具。在季度回顾中，这些数字讲述的是一个成功故事。
退化的信号是滞后的。代码库的腐烂不会在写代码的时候暴露，它会在改需求的时候暴露、在系统扩展的时候暴露、在排查线上事故的时候暴露。而这些时刻可能在六个月甚至一年之后才到来。
Token 成本的上升趋势同样容易被误读。当团队规模不变但 AI 账单持续增长时，直觉反应是"我们在更多地使用 AI，这是好事"。很少有人会去追问：每个 feature 的 token 成本是在上升还是下降？如果是上升，为什么？
等到问题暴露时，重写的成本可能已经超过了之前省下的所有时间。
该怎么做
这不是一篇反 AI 的文章。AI 编码工具是真正的生产力杠杆，前提是用对。以下是管理层应该推动的几件事：
Review 不是可选项。 这是防止退化循环启动的唯一闸门。不需要每一行都人工审查，但架构决策、模块边界、接口设计必须有人把关。把 AI 生成的代码当作一个能力很强但不了解你项目历史的新人写的 PR — 你不会不 review 就合并一个新人的 PR。
Spec 先行。 在让 agent 动手之前，先把需求写清楚。模糊的 spec 在单 agent 环境下的代价是返工；在并行 agent 环境下的代价是 N 个方向各异的实现，合并时才发现互相矛盾。Spec 的质量直接决定了 agent 产出的质量上限。
测试先行（Red/Green TDD）。 Agent 会 game 测试 — 如果测试是在实现之后写的，agent 倾向于写出"验证实现恰好做了什么"的测试，而不是"验证实现应该做什么"的测试。先写测试、确认测试失败、再让 agent 实现，是目前最有效的质量防线。
投资架构。 好的架构约束了 agent 的解空间，让正确的做法成为最简单的做法。清晰的模块边界、明确的接口契约、一致的代码风格 — 这些在传统开发中是"最佳实践"，在 agent 时代是"基础设施"。而且好架构直接降低 token 消耗：agent 不需要反复试错和大量查询就能做出正确决策。
监控 token 效率，而非 token 总量。 每个 feature 的 token 成本趋势是代码库健康度的代理指标。如果这个数字在持续上升，说明 agent 在你的代码库中工作越来越吃力 — 这是架构退化的早期预警信号，比任何代码质量扫描工具都灵敏。
门槛没有降低，它升高了
每一次软件工程的抽象跃迁 — 从汇编到高级语言，从手写代码到框架，从单机到云 — 都让更多人能参与软件构建，同时让专业工程师的价值向更高层次迁移。AI 编码是这条弧线上的又一步。
机械性的编码工作正在被自动化。剩下的全是判断力：架构判断、质量判断、取舍判断。这些能力在 AI 时代不是变得不重要了，而是变成了唯一重要的事。
管理层的责任不是禁止 AI 工具 — 那是逆潮流而动。管理层的责任是确保团队在用 agentic engineering 而不是 vibe coding 来构建生产系统。区别只有一个问题：
有人在 review 吗？
如果答案是"没有"，你的代码库正在以你看不见的速度腐烂。而且速度在加快。