Vibe Coding 的工程化约束

背景：自年初以来，我在工作中较为深入地使用 AI 辅助日常开发，所涉项目均为公司的实际上线项目。期间与同事交流了不少思路，也取得了可观察的改进。因此我认为可以就这几个月的实践做一次阶段性总结。

本文讨论的对象不是具体工具，而是开发流程中的约束手段。

一、核心矛盾

当前的主要矛盾在于：AI 快速推进开发的过程中，代码的不可控性与线上项目稳定性之间的矛盾。

对一线开发者而言，线上项目的稳定性无疑最为重要，而稳定性受到开发过程中多个环节的影响。这些环节可以划分为开发、审核、测试与上线后的救火四个阶段。

另一个维度是开发速度。在 AI 辅助下，当前的开发速度与去年已不可同日而语，论坛中也不乏“不再阅读代码、直接交由 AI 完成全部实现”之类的说法。

但线上一旦出问题，开发者不仅要在家中紧急处理，还需要快速定位问题，并及时反馈给其他部门。若问题频繁出现，不仅 KPI 会受到影响，甚至可能因此失去工作。

这里需要说明一个例外：目前在中美两国，都已出现仅由一人把控方向与决策、由 AI 组成的开发集群协同推进的做法，且这类集群正在快速发展；前段时间在国内受到关注的“一人公司”也基于类似思路。该情形不在本文讨论范围内，尚待进一步观察。

因此在 AI 辅助之外，人类工程师如何把控开发质量、管理开发流程，是一个至关重要的工程问题。

二、工程化应对

1. 维护 AGENTS.md

该文件是各家 Agent 与开发者开始对话时的默认基础，用于指导 AI 快速理解项目结构，而不必重新通读代码。若其中关于项目结构的内容写得足够好，可以规避很多问题。

例如我在维护多年的项目中多次遇到的情况：某个模块已有标准化的调用方式，但在某次会话的修改过程中，AI 会漏掉这些既有规范，自行构造一套新代码来实现同样的功能。

我的实践经验是：当此类问题反复出现时，在 AGENTS.md 中明确该规范，往往是最简单有效的手段。

此外，我在开发过程中参考了 DeepSeek Harness 的 AGENTS.md，借鉴了其中不少实践经验，感谢其开源。

2. 开发者需要理解代码

这一部分可能存在争议，但我仍认为有必要写出来，因为其中涉及的并不只是技术问题。

很多人在工作中都会经历一个类似的考验，即对自己开发的模块了解到什么程度。无论是同事询问具体的实现细节，还是开会解决问题时需要快速给出大致结论，都取决于对模块的熟悉程度。

在我较为激进地使用 AI 推进项目的阶段，很多时候我对代码细节并不清楚，只能回答：“我去看一下代码，稍后答复。”

这在某些时候会显得不够专业，尤其是在线上出现问题、上级在工作群中询问情况、需要快速解答时——回答的快慢是一个明确的信号。若电脑就在手边，确实可以在几分钟内通过 AI 得到结果；但若身处会议室或没有电脑的场景，这件事就难以做到。

上面这些说法难免带有职场色彩，其核心观点是：如何从需求中筛选出可能出问题的核心逻辑，将其记在脑中，再交给 AI 实现。

我曾与芬兰工程师共同工作两年，他们对分段提交与模块开发的极致要求，确实影响了我对架构的思考。

分段提交在 AI 时代的价值在于：它能帮助我更快地熟悉代码。

具体而言，需要把自己当作审核员：先自行思考，再理解 AI 的实现，检查其中的问题或者学习其思路，最终决定修改还是同意这次提交。

这与我年初关于 AI 对程序员工作影响的判断是一致的。围棋领域已经完整经历了这一过程：AI 完全重塑了围棋的学习与训练方式。不过这属于题外话。

3. 流程化

接下来讨论一些更具体的问题，也是我在开发中实际遇到的。

首先是注释。我的注释均使用中文，因此无论是 GPT 还是 Opus ，都经常出现用混乱的中文撰写含义不明注释的情况；即使是 DeepSeek 也时常如此。

其次是规范失效：即使我在 AGENTS.md 中写明了针对某个问题的具体要求，AI 的实现仍然会偏离正轨。

第三是修改范围外溢：我只希望 AI 修改 A 模块，它却扩大了范围，一并改动了 B 模块，我检查后不得不还原这部分实现。

如果先把整个开发阶段拆分为若干节点，那么现在需要做的就是在每个节点内部再做细分。希望达到的目标是：在人工介入审核之前尽可能减少出错，避免浪费不必要的精力。

这一思路与前段时间某 AI 团队开发者提出的 Loop 思路一致，即在一个大任务中进行多轮循环检查。现实约束在于 token 消耗带来的成本。

排除成本因素，这套流程在我的实际开发中确实解决了上述几类问题。而且可以针对每一项必要的检查单独编写一套清晰规范，从而避免把全部内容都塞进 AGENTS.md 。

4. 单元测试

在 AI 时代之前，对中小公司的开发者而言，编写单元测试近乎奢侈；而在当前阶段，我认为它已经成为标配。

需要先承认一个现实：单元测试的代码我基本不看，但我认为其价值在于约束 AI 产出正确的代码。

这部分并无太多可写之处，但需要明确一个现实：即使单元测试全部通过，AI 的代码仍可能出问题。业务的变化快速而复杂，总会给项目带来新的挑战。

5. 多模型互审

由多个模型互相审核代码，无疑是更稳妥的方案，但同样涉及成本问题。而最奢侈的做法，当然是多个模型进行多轮审核与修改。

实际开发中我也是这样做的。由于各家模型往往只在自家的 Agent 软件中才能发挥更好的效果，开发者就需要扮演传话员的角色，每天在 Codex 与 Claude Code 之间复制结论，交由另一方评估与修改。

之所以没有自动化，主要原因在于成本；其次，在阅读它们发现的问题时，对个人而言也是学习的机会。对于竞态、线程安全这类不易发现的问题，AI 审核确实具有独特优势。

三、小结

以上内容都指向同一个核心矛盾：

AI 快速推进开发的过程中，代码的不可控性与线上项目稳定性之间的矛盾。

这些问题的共同根源在于：当前大模型的内部运行对人类而言是一个彻底的黑盒。我们无法对过程进行干预，只能从输入端与流程上进行工程化控制。

如何把一件不可控的事情尽可能做到可控，我认为是当前 AI 使用过程中需要逐步解决的问题。

这不仅对程序员构成挑战，对当前各行各业接触和使用 AI 的人群同样如此。

这或许是未来一段时间内的趋势。