Vibe Coding 的工程化约束：AI 辅助开发如何兼顾速度与线上稳定性

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

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

一、核心矛盾

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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