如何正确使用Vibe Coding

别再把Vibe Coding当成“一句话生成产品”的魔法了，它真正改变的是你的精力分配方式

最近Vibe Coding在圈子里讨论度很高，有人视其为“重构软件工程”的银弹，也有人觉得不过是AI换了个好听的名字。经过一段时间的实践，我想分享一套被验证可落地的Vibe Coding工作流。

核心流程（五步法）

第一步：先写总需求文档

千万不要一上来就打开聊天框对AI说“帮我做个电商系统”。你需要先用自己熟悉的工具（Markdown、Notion、Word均可）写一份总需求文档，内容至少包括：

• 业务目标：这个系统要解决谁的什么问题
• 模块划分：大致拆分成几个相对独立的业务模块
• 业务边界：每个模块的职责范围，以及模块之间的交互边界

这一步不需要涉及技术选型、数据库设计、API定义，那是后面AI的事情。你要做的是把产品逻辑想清楚。

第二步：让AI高强度“挑刺”

把总需求文档丢给AI（建议用Claude或GPT-4o，并将思考能力开到最大），明确要求它只做一件事：挑刺。

你需要告诉AI重点关注两类问题：

过度约束

表现：需求中过早锁定了实现架构或技术细节，例如“用户登录必须用JWT”、“数据必须存MySQL”。
谁容易犯？老码农。因为习惯性地从实现角度写需求，而不是从体验角度。
后果：AI会“形式上满足”你的架构要求，但业务的健壮性、异常处理可能被糊弄过去。
改进方法：在需求文档中尽量用体验端语言描述，比如“用户登录后7天内无需重复登录”，而不是“使用JWT设置7天过期”。

考虑不周

表现：遗漏业务边界、极端情况、部署环境的特殊约束。例如“用户上传头像”没考虑文件大小/类型限制；“退款功能”没考虑订单已发货的情况。
谁容易犯？新手或纯业务背景的人。
好处：AI的批评中会提到很多你从未听过的概念——那些就是你接下来需要补齐的知识面。

这一步的心理门槛很高，很多人被AI批评几句就受不了了。请记住：AI骂的是你的需求文档，不是你的人格。沉住气，一条条看它的判断。

第三步：反思与迭代

对于AI提出的每条批评，你都需要做出判断：

• 它是不是想多了？（AI有时会过度谨慎）
• 它是不是真正指出了漏洞？

保留那些合理的意见，修改需求文档；忽略那些明显过度的担心。然后把新版文档再次扔给AI，重复第二步。

一直迭代到AI的批评对你来说已经不痛不痒——这意味着你和AI对问题域的理解已经对齐。

第四步：分模块拆解需求

总需求文档稳定后，为每个业务模块单独写一份模块需求文档。同样要包含该模块的职责、输入输出、边界、依赖关系。

注意：模块文档不要重复总需求中的全局性内容，专注该模块自身的业务逻辑即可。

第五步：分会话交给AI实现

将每个模块的需求文档单独开一个会话（全新的对话上下文）交给AI，让它完整实现该模块，并自己完善该模块的README。

需要在指令中明确两点：

• 拿不准的地方可以去参考总需求文档
• 但不要超出自己的责任边界（即不要擅自修改其他模块的逻辑或全局配置）

这样每个模块都有独立的上下文和实现者（AI），互不干扰，最后人工或写脚本集成即可。

Vibe Coding的真实本质

完成上面五步之后，你可能会意识到一件事：

Vibe Coding并没有减少你需要学习的东西。

你依然需要懂业务边界、需要知道“幂等性”是什么、需要理解分布式事务的代价、需要知道部署时环境变量的管理策略……AI批评中提到那些陌生概念，每一个都是你要去啃的资料。

它真正改变的是你的精力分配：

换句话说，Vibe Coding把你的角色从“编码员”推向了“真正的产品负责人”。那些指望什么都不懂、一句话就能做出产品的人，最终会发现AI生成的东西像“冬木圣杯”——万能但绝对歪曲你的原意。

一些补充建议

• 不要跳过写文档：直接在对话框里和AI边聊边改，短期看很快，长期会发现需求前后矛盾、模块互相踩脚。文档是唯一的事实来源。
• 把AI当成实习生：它的理解能力很强，但需要你给清楚边界和验收标准。让它自己写README是一个极好的“对齐验收标准”的方式。
• 保留人类最后的审核权：AI生成的代码依然可能出逻辑漏洞，尤其是涉及金钱、权限、数据一致性的地方，必须人工走查。

结语

Vibe Coding不是魔法，它是一面镜子——照出你对业务理解的深刻程度。你越能清晰地写出没有过度约束、又考虑周全的需求文档，AI输出的结果就越接近生产可用的代码。

反之，如果你连自己想做什么都说不清楚，AI只会给你一堆精致的、但完全没法用的东西。

祝你的Vibe之旅，从“跟AI吵架”变成“和AI共舞”。