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

> 关键不在于 AI 写没写代码，而在于有没有人审查、测试并能讲清它，Replit 删库事件就是证明。

原文: https://fdetimes.net/zh/analysis/vibe-coding-technical-debt-production/

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 的错误就不会波及真实数据。

**要点:** AI 带来的速度是一笔贷款，测试套件就是这笔贷款的抵押物。

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

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

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

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

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

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

**本周动手试试:**

- 找一个你曾让 AI 编写的原型，用静态安全扫描工具扫一遍，把 XSS 和注入类问题分别记录下来。
- 写一页“让 Agent 接触系统之前”的检查清单：开发和生产数据库是否分离、Agent 使用哪些凭据、如何回滚、哪些测试必须通过。
- 在 ITviec、TopDev 或 LinkedIn 上找 5 条提到 AI 编程工具的招聘启事，标出其中哪些同时要求测试、安全或生产运维经验。

## 信源

- [AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)

- [AI can write your code, but nearly half of it may be insecure](https://www.helpnetsecurity.com/2025/08/07/create-ai-code-security-risks/)

- [GitClear Reveals AI's Negative Impact On Code Quality](https://www.i-programmer.info/news/105-artificial-intelligence/17871-gitclear-reveals-ais-negative-impact-on-code-quality.html)

- [Replit AI agent snafu shot across the bow for vibe coding](https://www.techtarget.com/it-infrastructure/news/366627829/Replit-AI-agent-snafu-shot-across-the-bow-for-vibe-coding)

- [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

- [Not all AI-assisted programming is vibe coding (but vibe coding rocks)](https://simonwillison.net/2025/Mar/19/vibe-coding/)

- [Vibe engineering](https://simonwillison.net/2025/Oct/7/vibe-engineering/)