在生产环境进行 vibe coding 的正确方式

"vibe coding" 这个词之所以流行，是因为它确实对应了一种真实体验：你给出一句目标，AI 很快铺开代码、补全结构、修掉一些明显错误，甚至连 README 和测试也一起生成。短时间内，推进感极强。

问题在于，很多人把这种"推进感"误当成了"系统已被正确理解"。在 demo、玩具项目、一次性脚本里，这个错觉成本不高；但一旦进入生产环境，错误理解、越权决策、隐式改动和审计缺失，就会从"提高效率"迅速变成"制造不确定性"。

我对生产环境里的 vibe coding 的判断很简单：

不要把 Claude、Cursor、Copilot 或任何 AI coding assistant，当成默认理解全部上下文的 senior engineer。

更准确的定位，是一个超高速实现器，或者一位需要被明确约束与持续 review 的 paired junior engineer。

这不是贬低模型能力，而是在工程上给它放到正确的位置。生产质量从来不是由"生成速度"决定的，而是由约束、分工、审计、变更边界和 review discipline 决定的。

本文想讨论的不是"该不该用 AI 写代码"，而是：在生产环境里，应该怎样用，才不至于把效率工具变成事故放大器。

为什么很多人一开始会用错 vibe coding

很多团队第一次用 AI coding assistant，常见路径是这样的：

先在一个小需求上试试；
发现产出很快，信心迅速上升；
开始把更大的任务直接丢给模型；
只要 tests pass，就默认改动"八九不离十"；
最后在某次跨模块变更、配置改动、边界条件遗漏里出问题。

之所以会用错，不是因为大家不懂工程，而是因为 AI 太容易制造一种"它好像已经懂了"的感觉。它的回答通常完整、流畅、自信，而且能生成大量"看起来合理"的内容。危险恰恰在这里：

模型最危险的地方，不是完全不会；

而是在未被授权的地方，擅自做出"看起来合理"的决定。

比如它可能：

顺手重构你没让它动的模块；
根据命名猜测业务语义；
为了"让代码更整洁"修改接口边界；
补上一个它以为合理、但你体系内并不成立的默认值；
为了让测试通过，改变实现而不是暴露问题。

这些行为在聊天窗口里看起来像"聪明"，在生产里则是越权。

很多人一开始用错 vibe coding，本质上是把"会写代码"误判成"能承担工程责任"。这两者不是一回事。写出能运行的代码，与对系统边界、风险承诺、兼容性责任、上线约束负责，中间隔着完整的软件工程流程。

生产环境里最常见的 5 类风险

1. 上下文幻觉：它并不知道你没说出的那部分

AI 不会天然理解你的架构演进史、线上故障教训、组织分工、灰度策略、兼容性约束。它只能基于你给出的上下文和训练中见过的模式补全"最像样"的答案。

风险表现通常包括：

错误理解模块职责；
假设某个字段可以废弃，实际上是历史兼容字段；
误把局部最优当成全局最优；
改动一个点，却破坏了另一条隐蔽调用链。

结论：在生产环境里，未说明的上下文，不应被默认理解。

2. 越权改动：改了你没授权它改的东西

很多 AI 助手有很强的"主动补齐倾向"。为了让结果更完整，它会顺手修改：

无关文件；
配置项；
类型定义；
公共函数签名；
日志、错误处理、依赖版本；
测试基线或 mock 行为。

这些改动单看可能都有道理，但它们超出了授权范围。生产环境最怕的不是明确的大改，而是夹带式改动：变更说明写的是 A，实际混入了 B、C、D。

结论：如果没有明确 scope，模型就会用自己的"合理性"填满空白。

3. tests pass 并不等于可以放心 merge

这是很容易被忽视的一点。测试通过，只能说明当前测试集覆盖到的行为没有被破坏；它不能证明：

需求被正确理解；
未覆盖路径没有风险；
兼容性没有问题；
性能、资源占用、并发行为符合预期；
运维约束、回滚策略、监控埋点都已满足。

更现实一点讲，AI 甚至可能为了"让测试通过"而改变测试本身，或者写出高度迎合当前测试而不具备真实稳健性的实现。

结论：tests pass 是合格信号之一，不是 merge 授权本身。

4. 审计困难：你不知道它为什么这样写

传统工程里，一个有经验的工程师会在设计讨论、commit message、review comment 里留下思路痕迹。AI 生成代码的问题在于：产出很快，但决策链条往往不透明。

风险在于：

难以区分"按要求实现"与"模型自行发挥"；
reviewer 看到的是结果，不容易看到隐含假设；
后续维护者无法判断某段实现是否依赖偶然条件；
事故复盘时，很难追溯错误决策是在 prompt、模型推断还是人工 review 环节引入的。

结论：不具备可审计性的高速度，只会更快地产生技术债。

5. 责任错位：把 architecture authority 误交给模型

AI 很擅长实现、改写、补全、生成样板，也擅长根据既有模式继续推进。但它不应该天然拥有这些权力：

定义系统边界；
选择关键架构路线；
决定高风险迁移策略；
判断是否满足上线条件；
替团队做 trade-off。

如果把这些权力隐式交给模型，团队实际上是在把"工程责任"外包给一个没有真正责任主体的系统。

结论：AI 是加速器，不是架构授权者。

一套可执行的正确工作流

在生产环境里，比较稳妥的方式不是"把需求扔给 AI 然后等结果"，而是把 AI 纳入一个被约束的交付回路：

先 plan，再确认 scope，再分小块实现，再 review，再继续。

这个顺序看似保守，实际上是效率更高的。因为真正拖慢生产效率的，从来不是多花 10 分钟做 plan，而是上线前后反复返工、定位隐性改动、修补被误伤的边界。

第一步：先让 AI 做 plan，不要直接做实现

一上来就让模型改代码，通常是最容易失控的。更好的做法是先要求它：

复述目标；
列出已知信息与缺失信息；
明确影响范围；
提出分步计划；
标出高风险点和待确认项；
在未获授权前不改代码。

示例 Prompt：先做计划，不允许直接动手

text 复制代码

你现在不要写代码，也不要修改任何文件。

任务目标：
- 为现有服务增加 X 能力，用于 Y 场景。

请先输出：
1. 你对需求的理解
2. 需要确认的范围边界
3. 可能影响的模块/接口/配置
4. 建议的最小实现步骤（按小步拆分）
5. 每一步的风险点
6. 哪些地方你绝不能自行假设

约束：
- 不要创建额外 feature
- 不要重构无关代码
- 不要修改公共接口，除非我明确批准
- 不要碰部署、配置、依赖版本，除非我明确批准

这个动作的价值，在于你先检查它是不是"理解偏了"，而不是让偏差直接落成代码。

第二步：明确 scope，写出"允许改什么，不允许改什么"

生产环境使用 AI，最重要的不是 prompt 多华丽，而是边界写得够不够硬。

建议每次任务都显式给出：

Scope checklist

本次只允许修改哪些目录/文件？
本次是否允许改 schema / API / config / migration？
是否允许新增依赖？
是否允许修改测试？
是否允许重构已有代码？
输出是 patch、方案，还是完整实现？
哪些决策必须先停下来请示？

示例：scope control 模板

text 复制代码

本次任务授权范围：

允许：
- 修改 service/order/*
- 修改与本需求直接相关的单元测试
- 新增必要的内部私有函数

不允许：
- 修改公共 API 定义
- 修改数据库 schema
- 修改 CI/CD 配置
- 修改依赖版本
- 顺手重构无关模块
- 修改日志规范、错误码约定、监控埋点格式

如果你认为必须突破以上边界，先停止，并说明原因，不要自行决定。

这一步的核心思想是：宁可多做授权说明，也不要把"合理发挥空间"留给模型。

第三步：分小块实现，每一步都可 review、可回退

不要把一个中等需求一次性完整交给模型。正确方式是拆成几个能够独立验证的小块，例如：

只改数据结构；
只改核心逻辑；
只补测试；
只补文档和注释；
只处理监控或告警接入。

每一步都要求它输出：

改动摘要；
变更文件列表；
未改动但相关的风险点；
为什么这一步没有越界。

示例 Prompt：要求小步提交

text 复制代码

现在只做第一步：实现最小必要的数据流改动。

要求：
- 只修改我授权的文件
- 输出变更摘要
- 列出所有改动文件
- 说明每个改动的目的
- 不要继续做第二步
- 如果发现必须修改未授权文件，停止并说明

这种方式的好处不是"更慢"，而是让 review 成本变低。review 能做，质量才能守住。

第四步：review 不只看能不能跑，而要看是否越权、是否偷换决策

对 AI 产出的 review，不能只看语法和测试结果，要重点看它有没有偷偷替你做决定。

Review checklist

是否修改了未授权文件？
是否改变了接口语义？
是否引入了新的默认行为？
是否为了通过测试而规避真实问题？
是否更改了错误处理、重试、超时、日志级别？
是否改变了兼容性约束？
是否引入性能或并发风险？
commit/message/说明中是否完整披露了变更边界？

如果 reviewer 只看"看起来挺合理"，那等于把最后一道治理关口也让渡掉了。

第五步：通过后再继续下一块，而不是一次性放行

AI 适合高频迭代，不适合无边界放权。生产流程里，继续推进的前提，是上一步已经被人类明确确认。

一句话总结就是：

AI 负责加速实现，人类负责授权边界与最终判断。

Prompt / review / scope control 的实践模板

下面给几组更贴近实战的模板，可以直接改造后使用。

1. 计划阶段模板

text 复制代码

先不要写代码。

你要做的是：
- 复述需求
- 列出假设
- 标记不确定点
- 给出最小可执行方案
- 指出潜在风险和越权边界

如果某项信息缺失，请明确说"需要确认"，不要自行补全业务规则。

2. 实现阶段模板

text 复制代码

只实现以下范围：
- [明确列出允许修改的模块]

严格约束：
- 不新增依赖
- 不修改公共接口
- 不改 schema
- 不做重构
- 不改动无关测试

输出时请包含：
1. 改动文件列表
2. 每个文件的修改原因
3. 可能的副作用
4. 需要我人工确认的点

3. review 阶段模板

text 复制代码

请不要继续编码，只做自检审查。

检查以下问题：
- 是否有未授权改动
- 是否隐含改变了原有语义
- 是否引入新的默认行为
- 是否存在"为了通过测试而调整实现/测试"的情况
- 是否遗漏了监控、回滚、兼容性影响

请按"发现的问题 / 风险等级 / 建议处理"格式输出。

4. PR 前人工检查清单

改动范围是否与需求单一致
是否存在"顺手优化"但未授权的内容
测试通过是否覆盖关键业务路径
是否检查了配置、权限、超时、异常处理
是否考虑回滚方案
是否补充必要的日志与可观测性
是否由了解上下文的人完成 review
是否确认 AI 没有替团队做架构决定

什么时候适合用，什么时候不该放手给 AI

适合用 AI 加速的场景

如果边界清晰、局部封闭、验收标准明确，AI 往往很有效：

补样板代码、脚手架、接口适配层；
编写单元测试、测试数据、mock；
小范围重构中的机械性改写；
已有模式下的新模块实现；
文档、注释、变更说明整理；
查询、排查、阅读已有代码后给出局部修改建议。

这些场景的共同点是：人能清楚定义"对"和"错"，且影响面可控。

不该放手给 AI 的场景

以下场景不适合"你看着办"式的 vibe coding：

核心架构设计与关键 trade-off；
高风险迁移、数据修复、schema 调整；
安全、权限、认证、计费、风控等敏感逻辑；
涉及复杂分布式一致性、并发语义、性能瓶颈的改动；
线上故障中的紧急修复决策；
缺少清晰上下文、需求仍在摇摆的任务。

这些场景不是不能借助 AI，而是不能把它当成主决策者。它可以辅助分析、生成备选方案、整理排查思路，但授权必须更严格，人工判断必须更重。

一个更现实的定位：paired junior engineer，而不是 senior architect

我越来越倾向于用一个不那么夸张、但更接近现实的比喻来描述 AI coding assistant：

它更像一位速度极快、知识面很广、体力无限，但上下文感不稳定、边界感需要外部施加的 paired junior engineer。

这个定位很重要，因为它会直接影响团队如何设计协作方式：

你不会默认 junior engineer 理解所有历史包袱；
你不会让他自己决定架构边界；
你不会因为单元测试通过就跳过 code review；
你会把任务拆清楚，把边界讲明白，把 review 做扎实。

当团队按这个心智模型使用 AI 时，往往更安全，也更高效。因为 expectations 对了，治理动作才会跟上。

结语：AI 提升的是速度，不应该替代边界治理

生产环境不是比谁更快敲出代码，而是比谁能在可控风险下持续交付。AI coding assistant 的确能显著提高实现速度、减少机械劳动、加快迭代节奏，但它并不会自动替你承担上下文理解、边界控制、质量审计和上线责任。

真正决定结果的，依然是工程纪律：

有没有先做 plan；
有没有确认 scope；
有没有把任务拆小；
有没有严格 review；
有没有把"tests pass"和"可以 merge"区分开；
有没有防止模型在未授权处替你做决定。

如果一句话总结我对生产环境 vibe coding 的建议，那就是：

把 AI 当成高吞吐的实现助手，而不是天然可信的架构权威。
让它提速，但不要让它越界。

这样使用，AI 才更可能成为生产力工具；否则，它只是在更快地制造你以后必须亲自收拾的复杂性。