需求来了，别急着丢给 AI：我的 Vibe Coding 全流程
约 2514 字大约 8 分钟
AIVibe Coding
2026-06-21
上一篇把自己数落了一顿：用了半年 vibe coding，业务脱节、基础弱化、连自己名下提交的代码都看不懂，差点把自己写废。写完我就在想，骂归骂，日子还得过，AI 还得用，问题从来不是要不要用 AI，而是怎么用。
同样是 vibe coding，「带着 AI 干活」和「交给 AI 干活」，是两份完全不同的工作。交给 AI 干，你就是流水线末端的质检员，扫一眼能跑就放行；带着 AI 干，全程的节奏、关键节点的拍板，始终都在自己手里。这篇就顺着日常需求的生命周期，从一个需求进门、到提测出门，将我现在跑的完整流程，总结成实战的经验展开来讲讲。
先跟产品把话说明白
首先第一步，其实发生在需求评审会中，这个阶段无论是不是 vibe coding，都一样重要。
我现在会主动跟产品提合理化建议：需求文档里，用例的交互效果请写清楚 —— 用户点完这个按钮，页面是跳转还是弹窗？加载中显示什么？失败了的兜底是什么？这些看着是小事，但一句「用户点击提交」背后，可能藏着十种交互细节。评审会上没掰扯清楚，开发到一半就得停下来等确认，这个来回沟通的成本，比写文档高多了。
产品一般也乐意配合，他们把文档写清楚一次，评审会上被挑战的次数就少一次，双向省事。前期多说一句话，后期少扯三天皮，这笔账谁算谁赚。
评审会上，别只接需求，要挑战需求
评审会上，我的角色不是「接活的」。
从业务背景出发，先问这个需求为什么要做、解决了谁的问题、不做会怎样，再评估合理性：这个功能跟现有流程有没有重叠？有没有更便捷的解决方案？有的需求拍脑袋要一个定时任务全表扫描，其实一个状态流转或者事件通知就能解决，数据量小的时候看不出差别，等表涨到几百万行，全表扫描就是埋给未来的一颗雷。
说白了，开发如果只负责把需求原样翻译成代码，这个岗位才是真的危险，因为「翻译」恰恰是 AI 最擅长的，人的价值得往上游走，参与到需求本身的塑造里去。
AI 出现之后，真正贬值的不是写代码的能力，是只会写代码、从来不问为什么的状态。
骨架自己搭，杂活让 AI 跑腿
需求定下来，轮到技术方案，我的原则就一条：核心设计必须自己来。
模块怎么拆、状态怎么流转、事务边界划在哪、异常怎么兜底，这些是方案的灵魂，AI 可以帮你生成文档模板、给 SQL 表结构出个初稿，但架构的判断不能外包。原因上一篇其实说透了 —— 方案设计的过程，恰恰是业务认知沉淀的过程，这一步也外包出去，后面审核 AI 代码的时候，你手里连张地图都没有。
然后是我觉得整个流程里性价比最高的一件事：根据业务流程，把流程图、数据流转图、状态流转图等画出来，对每个环节做到心里有数。
别嫌费时间，这张图后面要帮你干三次活，做到一图三用
- 第一用，方案评审的时候，图就是跟产品、测试沟通的语言，一张图比十页文档直观；
- 第二用，开发的时候把图连同方案一起喂给 AI，这是最好的提示词素材，比任何华丽的 prompt 模板都管用；
- 第三用，AI 写完代码，图就是审核的对照清单，逐个状态、逐条流转核对过去，漏没漏、错没错，一目了然。
把分歧消灭在写代码之前
方案出来，拉上产品、测试三方评审会对齐。
为什么非要三方坐在一起？因为改一行文档和改一堆代码，成本差着一个量级。
方案阶段的分歧，改的是图和文字；但是开发阶段的分歧，改的却是代码、测试用例，甚至可能连 AI 已经生成的产出都要推倒重来。测试在这个环节介入特别值：他们天然带着用例视角，边界场景、异常分支，很多你在方案里没想到的坑，他们一句话就给你点出来了。
跟 AI 把需求聊透，再放它开工
前面几步走完，才轮到 AI 登场。
我把这一步叫需求澄清。不是丢一句「帮我实现订单超时取消」就完事，而是把技术方案、状态流转图、表结构、项目里的约束，组织成 AI 能读懂的语言，完整地喂给它，然后让它干一件事：复述需求，并把没想清楚的地方提问出来。
这里有个意外的收获：AI 提出来的模糊点，往往就是方案里真的没想清楚的点。它问「订单超时的时候如果用户正在支付中，是取消还是等待？」，这是一个必要的过程，你也别嫌烦，如果澄清的问题产品没提、评审会上没聊到，现在暴露在写代码之前，是修正成本最低的时候。对齐到它没有疑问、你没有含糊，再放它开工。
对于复杂需求，尽量多次需求澄清
为什么尽可能多澄清几轮？还不是因为 AI 的原理摆在那：上下文窗口有限，一轮里它能装下、能关注到的信息就那么多；思考规划也有限，很难一轮就把边界、异常、并发这些交叉场景全部推演到位。
你把同一份需求丢给它两遍，问出来的问题都可能不一样。所以本质就是：多澄清一次，就多发现一批潜在问题，后续的沟通和返工成本就会少一分，工作中能花 token 解决的事，都不叫事。
从 0 到 1，对着图过堂
AI 交付的代码，我是从 0 到 1 过一遍的，不是扫一眼。
抓手就是方案阶段画的那张图。状态流转图当 checklist，逐个状态核对：该流转的都流转了吗？不该流转的有没有被多出来的一步捅穿？业务主流程走完，再走异常分支，去看看事务边界对不对、幂等有没有处理、并发场景会不会超卖。这些是业务正确性的底线，AI 大部分时候能写对，但它没有这次需求的上下文体感，偏偏这些地方最容易出幺蛾子。
为什么我现在审核得起、看得懂？因为方案是我设计的，图就在我脑子里。上一篇说「看不懂 AI 代码怎么把关」，答案其实不在 AI 身上，在方案阶段就已经写好了。
最后一公里：交叉评审、冒烟和提测
自己审完，我还会换个模型，让另一个 AI 以评审人的角色把代码再过一遍。
为什么要换模型？
同一个模型，自己生成的代码自己 review，天然容易「自我一致」，它写的时候觉得这么写对，回头看还是觉得对。换一个模型，重新读需求，等于找一个不同背景的同事来挑刺，视角、口味、知识盲区都不一样，挑出来的问题往往正好是原模型看不见的盲点。
它指出来的不合理之处，由人来判断要不要改、怎么改，改完再确认一轮。然后自己过冒烟测试：主流程、边界场景、异常场景，亲手点一遍。
都干净了，让 AI 起草提测报告，但有三样东西，我会亲自把关，绝不外包：
- 影响范围：这次改动到底动了哪些模块、波及哪些上下游
- 回滚预案：万一上线出问题，怎么退、退到哪
- 自测数据：每个验收点对应的实际执行结果
报告的排版可以让 AI 弄，内容可以让 AI 填，但这三样的准确性，签字的是我，责任就跑不掉。
带着干，不是交给干
再回头把整条流程捋一遍，AI 出现在每一个环节，甚至你出好的代码设计也可以交给 AI 来实现，但每个环节的拍板权，一步都没让出去：
| 环节 | AI 干的 | 我守的 |
|---|---|---|
| 需求评审 | — | 挑战合理性，向产品提合理化建议 |
| 技术方案 | 文档模板、SQL 表结构初稿 | 核心设计，三张图 |
| 开发 | 写代码的主力 | 需求澄清，聊透了对齐了再开工 |
| 审核 | 交叉评审挑刺 | 从 0 到 1 的最终把关 |
| 提测 | 报告起草 | 影响范围、回滚预案、自测数据 |
核心就一句话
交给 AI 干活，你只是一个质检员，而带着 AI 干活，你是操盘的人，方向盘拿回自己手里，AI 才是真正让你省力的那个副驾。
当然，这套流程还留着一个口子：怎么让 AI 写出来的代码更像自己的？代码风格的 Skill 怎么写、开发习惯与规范怎么沉淀、企业级项目层面的 Skill 怎么定义？这些是下一篇要展开的内容，也是这套流程的最后一块拼图，先到这。