在工作中，如何正确使用vibe coding来增效？

最近在工作里，大家都在讨论 vibe coding，工具也是百花齐放，cc，codex，trae。它确实提高了开发效率，但有时也会发现，明明生成的测试用例都通过了，但是交付后效果依然很差；变量名，项目结构完全没有按照规章来，太过发散；ai听不懂人话，需要多次返工，不仅没有增效，反而让leader觉得做事不仔细。

也就是说，很多人只是用起来了，而不是用好了。

真正把它用好，关键不在“让模型多写一点”，在于先想清楚边界。

第一，先分清需要处理的是“项目”还是“模块”。

如果只是一个边界清晰、输入输出明确的小模块，vibe coding 的效果通常很好，因为上下文相对稳定，模型更容易收敛到可用结果。但如果是完整项目，尤其涉及多服务协作、复杂依赖、历史包袱、技术债和长期演进，就不能把它当成一个单点代码生成器来看。这时候更需要 agent 具备全局视野，理解架构约束、上下游关系、数据流和非功能性要求，否则它很容易在局部最优里“写得很快、接得很差”。

在这种情况下，生成的项目代码往往是打补丁式的推进，无论是可维护性还是可阅读性，对于开发人员而言都可以说是一场灾难。

第二，prompt engineering 的重点不是“写得玄，写的多”，而是把约束讲清楚。

实际工作里，最有用的 prompt 往往包含四类信息：目标、范围、约束、验收标准。目标决定它做什么，范围决定它不做什么，约束决定技术路线不能越界，验收标准决定输出能不能直接进入下一步。比如要明确使用什么语言和框架、是否允许改动已有接口、需要兼容哪些历史逻辑、输出要到伪代码、可运行代码，还是测试用例级别。约束越清晰，结果波动越小，交付越可控。否则模型会不断“合理补全”，最后看似完整，实际偏题。

这也是为什么很多人vibe coding出来的，看似可用，但追溯到底层，发现全部都是内部逻辑，只是表面能跑，有demo，底层甚至可能是一个特大号json来做的数据演示，只为了告诉你，能跑了，但也仅此而已，距离实际可以交付的代码，还有相当一段距离。

第三，不能全面依赖 vibe coding。原因很现实。先说合规性，企业研发不是只看能不能跑起来，还要看代码来源、数据权限、安全规范、审计要求，以及是否泄露业务上下文。很多内容并不适合直接交给模型处理。再说 LLM 幻觉，它会在缺少信息时自信补齐，生成看起来合理、实际上错误的实现，尤其在接口细节、边界条件、隐式依赖和异常处理上最容易出问题。你越把它当“全自动工程师”，后期返工和风险就越大。

从开源库中直接扒取的代码，llm往往不会在乎其开源协议到底使用的是什么，如果是GPL，那对企业来说是完全不可接受的，并且反复的代码堆叠，导致最后很有可能成为"屎山代码"，而这也与我们增效的初衷背道而驰。

所以，vibe coding 更适合做“加速器”，而不是“决策者”。它可以帮助我们快速铺草稿、补样板、做重构建议、生成测试，但真正的架构判断、合规把关和结果验收，仍然要由人来负责。把它放在合适的位置，它会非常有价值；把它当成万能替代，代价往往会在后面补回来。

正所谓“命运的馈赠，早已在暗中标好了价格”。