氛围编程欠下的债，上线当天到期

2025 年 7 月，SaaStr 的 Jason Lemkin 在 Replit 上用氛围编程（vibe coding）写代码时，编程 Agent 删除了他的生产数据库。随后，这个 Agent 还错误地坚称无法回滚，最后才承认自己犯了“灾难性的判断错误”。

Replit 的应对说明了很多问题：它让开发数据库和生产数据库自动分离。这是一道非常基础的防护，此前却并不存在。问题更多出在流程上，而不是模型上，因为一次原型开发会话竟然可以直接动到真实系统。

对想成为前线部署工程师（FDE）的人来说，这个故事就是岗位说明。FDE 工作在演示与部署的交界处：一个写得飞快的原型，必须经受住真实数据、真实用户和真实后果的考验。

代码只在自己机器上跑的时候，氛围编程就像一笔无息贷款。代码进入生产环境的那天，利息就开始计算。

界线在于你是否理解代码

Simon Willison 引用了 Andrej Karpathy 最初的定义：氛围编程就是完全顺着感觉走，忘掉代码的存在。说到底，就是不在乎代码本身。

Willison 把界线划得很清楚。在他看来，如果代码由 AI 编写，但你已经审查过、测试过，而且能讲清楚，那就不再是氛围编程，而是软件开发。这个区分很有用，因为它把问题从“你用没用 AI？”变成了“有没有人为这段代码负责？”

所以，债务并不来自使用 Copilot 或 Claude，而是来自团队里没有人真正理解的代码：它们跳过了审查、测试和解释。如果你接手了客户用 AI 做出的原型，第一个问题应该是：哪些部分从来没有人审查过？

第一笔账是安全

Veracode 的《2025 年 GenAI 代码安全报告》发现，AI 生成的代码能跑通，但在 45% 的测试用例中存在安全漏洞。放到一个包含 20 个同类任务的原型上：按这个比例，大约 9 个任务带有漏洞，尽管 20 个任务全部能通过演示。

更糟的是，这个数字不会随时间自然下降。Veracode 的 CTO 表示，GenAI 模型几乎有一半时间会做出错误选择，而且情况并没有改善。更大的模型也不比小模型明显更安全。等下一代模型出来，不能算是计划。

按语言看，Java 的失败率最高：LLM 生成的 Java 代码在超过 70% 的情况下存在安全漏洞。另外，86% 的相关代码样本未能防御跨站脚本攻击（CWE-80）。

XSS 是一类经典漏洞，通常要等应用向真实用户开放才会暴露。这正是债务在上线当天到期的原因。

设想你在向客户演示一个反馈表单。会上大家输入的都是普通句子，表单运行完美。可一旦向成千上万的用户开放，只要有一个人输入一段脚本，漏洞就暴露了，因为会议室里从来没有人攻击过这个表单。

第二笔账来得更晚，而且不断上门

如果说安全是上线当天要付的款，那么维护就是之后持续数月的分期付款。上线只是首付，后面每个迭代都要还一期：每当有人得修改一段没人看得懂的代码。

GitClear 的分析显示，2024 年复制粘贴的代码行数超过了移动的代码行数。“移动”的代码行通常是重构留下的痕迹，即把逻辑归拢到一处。复制粘贴占上风时，同一段逻辑会散落在很多地方，每修一个 bug 都得在每一处各改一遍。

GitClear 还统计代码变动率（code churn），即写完不到两周就被回退或重写的代码行占比，并以此衡量低质量代码。这是 FDE 值得随身带着的指标：如果原型的大部分代码在真实使用的头两周就得重写，那么早期的速度只是借来的。

再加上 Replit 事件，这三类债务会在三个不同时刻到期，每一类都需要提前做不同的工作：

债务类型	演示时	何时到期	FDE 先做什么
安全	表单和 API 按预期工作	真实用户输入数据时，比如 XSS	运行安全扫描，仔细检查输入处理
维护	新功能加得飞快	后续迭代中，重复逻辑需要修改时	跟踪变动率，重构复制粘贴的代码
运维	Agent 运行顺畅	Agent 第一次接触真实数据时	隔离开发与生产环境，限制权限，保留回滚路径

变快的感觉靠得住吗？

更难回答的问题是：团队为什么一再借债？METR 针对 16 名经验丰富的开源开发者做了一项对照研究，发现他们使用 AI 工具时，完成任务的时间反而多了 19%。METR 后来指出，这一结果反映的是 2025 年初的情况，现已过时。

更耐人寻味的是开发者自己的看法：即使实际变慢了，他们仍然认为 AI 让自己快了 20%。

需要说明的是，METR 测量的是工作速度，而不是技术债或生产环境中运行的代码。所以这不是第四种债务，而是另一类风险：团队对自己的判断出现偏差。

不过，它有助于解释为什么上述债务很少被及早制止。对 FDE 来说，教训很实际：在断定 AI 让项目提速之前，先测量实际耗时，而不是问团队感觉如何。

用测试和防护措施提前还债

出路不是放弃 AI。Willison 在关于“氛围工程”（vibe engineering）的文章中提出，如果项目有一套扎实、全面、稳定的测试套件，智能体编程工具就能大幅提速。测试套件就是抵押物：有了它，这笔速度贷款才是安全的。

Replit 事件指向第二层防护：环境边界。Agent 需要在沙箱中工作，即使犯下最严重的错误也能撤销。对 Lemkin 来说，只要开发和生产数据库是分开的，Agent 的错误就不会波及真实数据。

如果你是 FDE，在客户那里接手了一个氛围编程做出的原型，优先顺序很明确。第一天，检查 Agent 和应用使用哪些凭据、能否访问生产环境、回滚如何进行。第一周，为主要流程补上测试，并在添加任何新功能之前运行一次安全扫描。

开发者该如何应对这笔债？

对于有两到八年经验的开发者，包括本刊创办时所面向的越南工程师，这正是脱颖而出的地方。谁都能让 AI 做出一个原型；难的是把原型送进生产环境，同时不留下漏洞、不让 Agent 接触真实数据、不让重复代码四处蔓延。

看招聘启事时，无论是在 ITviec、TopDev 这类越南招聘平台还是在 LinkedIn 上，都不要只看“熟练使用 AI 编程工具”这一行。留意那些同时要求测试、应用安全、CI/CD 或生产运维经验的岗位。这样写招聘启事的公司，很可能已经吃过这笔债的亏。

在简历上，把“使用 AI 提升效率”换成一个有你自己真实数字支撑的故事。例如：接手一个 AI 编写的原型，隔离了开发与生产环境，为主要流程编写了测试，修复了扫描中发现的 XSS 漏洞。面试时，要讲你拦下了哪些风险，而不只是你写代码有多快。

氛围编程会继续帮助团队更快地做出演示。但演示变成生产系统时，总得有人来还这笔债，而懂得在债务到期前还清的人，不愁没有工作。