Vibe Coding 的80%陷阱：AI写码到生产环境的最后20%

AI 智能体现在能在几个小时内构建出一个可用的功能。第一次看到这一幕，感觉像是魔法。然后你把它部署上线，魔法就开始变得复杂了。

当代码“看起来完成”时，问题才刚开始

代码通常能跑起来——这正是问题所在。它看起来已经完成了，所以没人质疑它。以下是一些反复出现的问题：

• 硬编码的密钥：API 密钥最终出现在配置文件里或被提交到代码仓库中。
• 未知的依赖：智能体安装了你不熟悉的包，有时甚至是一些没有人在积极维护的包。
• 缺失的边缘情况：正常路径能工作，但用户实际会碰到的那个用例却不行。
• 没有测试：没有任何东西能证明代码确实做了你预期它做的事。

这些问题都不是经典意义上的 bug。它们是判断力的缺口——而这恰恰是 AI 生成代码最薄弱的地方。

“Vibe coding”一词由 Andrej Karpathy 于 2025 年初提出，指开发者凭直觉向 AI 描述需求、几乎不阅读生成代码就直接采纳的工作方式。它强调快速迭代与心流，但默认了一个危险假设：代码能跑就等于正确。与之相对的“智能体工程”（agentic engineering）更强调把 AI 智能体当作需要被管理的执行者，开发者负责定义任务边界、验证产出并承担后果。两者的核心差异不在工具，而在问责结构：前者把审查外包给了运气，后者把审查保留在人的环节。理解这一区分，有助于判断自己团队当前处在哪种模式，以及需要补齐哪些流程。

如何改变做法：五个关键动作

面对这些缺口，开发者需要从“让 AI 写代码”转向“对 AI 写的代码负责”。以下是五个可操作的建议：

1. 审查每一个依赖

如果无法解释某个包为什么出现在项目中，就移除它。依赖审查是防止供应链风险和未知行为的第一道防线。

2. 先写测试

让智能体针对你的测试来写代码，而不是反过来。测试先行不仅验证行为，也为 AI 的产出划定了明确的边界。

在发布前检查实际安装了哪些包：

供应链风险指项目引入的第三方包可能带来安全漏洞、恶意代码或不可控的维护状态。AI 智能体在安装依赖时往往优先选择“能跑通”的包，而非最主流、维护最活跃的包，这会让冷门或已废弃的包进入依赖树。审查依赖时，至少要确认包的维护频率、下载量、最近提交时间和已知漏洞公告；对无法说明用途的依赖直接移除。定期运行 `npm audit` 或 `pip-audit` 可以把已知漏洞暴露出来，但无法替代人工判断“这个包是否真的需要”。

测试先行（test-first）在 AI 辅助开发中有了新的含义：测试不再只是验证手段，而是约束 AI 行为的规格说明。当你先把预期行为写成可执行的测试，再把测试交给智能体，它就有了明确的通过标准，减少自由发挥带来的偏差。同时，测试也划定了审查范围——diff 只需要对照测试来读，而不是逐行猜测意图。对于边缘情况，先写测试能迫使开发者提前想清楚用户实际会碰到的路径，而不是等 AI 只实现正常路径后再补。
# 检查实际安装了什么
npm ls --depth=0
# 或
pip list

3. 保持任务足够小

一个智能体，一个明确的任务，一个可审查的 diff。巨大的 AI 生成拉取请求不会被真正审查——它们只会被批准。

4. 让密钥远离提示词和代码

从第一天起就使用环境变量。

# .env（永远不要提交这个文件）
API_KEY=your_key_here

const apiKey = process.env.API_KEY;

5. 像做代码审查一样阅读 diff

而不是像看魔术表演一样。

真正的转变：从写码到问责

无论我们称之为“vibe coding”还是“智能体工程”，所需技能正在发生变化。它不再主要是敲代码，而是指导、审查并对最终交付的代码负责。

AI 写的代码，责任在你。

这种责任转移意味着开发者需要建立新的工作习惯：在 AI 加速产出的同时，把审查、测试和依赖管理作为不可省略的环节。80% 的完成度可能只需要几小时，但最后 20% 的判断力工作，才是决定代码能否安全上生产的关键。

你的底线在哪里？

你在哪里划定 AI 写代码的边界？AI 智能体对你的代码库做过的最糟糕的事情是什么？欢迎在评论区分享你的故事。