🎯
VibeCoding 的核心不是“更快写代码”
它的目标是把复杂需求拆成一连串可讨论、可决策、可验证的小问题，让 AI 在真正开始编码前就和你对齐：需求边界是什么、有哪些约束、哪里需要人类拍板、最终文档需要详细到什么程度。这样做前期更慢，但后期更少返工。
阅读提示
这页聚焦 VibeCoding 的方法骨架：工作流、检查清单、微决策和泛化案例。更适合先把复杂需求讲清楚，再进入实现，而不是一上来就让 AI 直接开写。
一、什么时候要从 AskUserQuestion 升级到 VibeCoding
| 情况 | 只用问答是否够用 | 更推荐的做法 |
|---|---|---|
| 需求边界清楚、改动点少 | 通常够用 | 直接用 `AskUserQuestion` 补齐遗漏后开做 |
| 需求模糊、约束多、方案不唯一 | 往往不够 | 切到 VibeCoding，把问题逐轮问清楚 |
| 跨系统、跨角色、需要大量人类拍板 | 不够 | 先出文档、流程图、决策记录，再写代码 |
| 医学 / 生信等高准确性项目 | 常常不够 | 把术语、合规、质控、可追溯要求写进方案文档 |
可直接用的复杂度识别标准
- 需求模糊度高：一开始只有方向，没有稳定方案
- 涉及多个系统：需要跨模块或跨服务协调
- 约束条件相互制约：性能、安全、体验、成本不能同时拉满
- 需要大量人类决策：AI 无法自动替你承担责任
- 技术路线不唯一：必须做取舍，而不是照抄现成方案
二、VibeCoding 的 7 步工作流
1. 输入需求
先把模糊想法结构化，形成 500–1000 字的需求草稿和初步方案。
2. 多角度评审
让不同模型分别复述需求、查代码、提技术方案，并提出需要你决策的问题。
3. 追问与决策
逐个回答问题，继续追问“还有什么没考虑到”，直到没有新的关键问题。
4. 可视化沟通
要求 AI 产出表格、流程图、ASCII 原型图，降低歧义与误解。
5. 汇总成文档
由最会“说人话”的模型主笔，把需求、技术方案、边界条件和文件清单一次写清楚。
6. 交叉复审
把完整文档交给其他模型再审，继续补漏，直到无法提出有效新意见。
7. 再进入编码
这时再写代码，目标是“一次写对”，而不是“写完再返工”。
三、把“微决策”写进流程，而不是一次性押注
VibeCoding 的关键不是单次长提示词，而是多轮微决策：每一轮只解决几个真正需要拍板的问题。方案不是预先拍脑袋定死的，而是在讨论中逐渐浮现出来的。
请先不要写代码，按复杂需求澄清流程来： 1. 用你的话复述我的需求，并指出仍然模糊的地方 2. 列出所有关键约束、边界条件和潜在冲突 3. 提出需要我拍板的问题，按优先级排序 4. 能用表格、流程图、ASCII 原型图表达的，尽量可视化 5. 在所有关键问题确认前，不要进入实现阶段 6. 当你认为方案已经收敛时，再输出详细实施文档
四、文档标准：详细到“任何人看都没有歧义”
- 需求描述：用户场景、目标、限制条件、验收标准
- 技术方案：架构、数据流、关键状态机、失败路径
- 代码改动清单：哪些文件要改、为什么改、关键改法是什么
- 测试方案：单测、集成测试、E2E、边界条件验证
- 决策记录：哪些点是人类拍板的，为什么这样定
五、泛化后的案例框架
这一类案例最有代表性的难点，是用户体验、安全防滥用、业务成本三者互相牵制，不能只盯一边。你可以把任何复杂需求先抽象成这样的冲突结构，再决定实现顺序。
你可以把任何复杂需求先重写成这种格式
- 用户目标：希望获得更顺滑的体验 - 系统目标：必须控制滥用风险和资源消耗 - 约束条件：不能显著增加成本，不能明显拉低转化 - 关键冲突：体验 / 安全 / 成本 三者互相制约 - 结论：没有现成答案时，不要急着编码，先进入多轮方案澄清
六、医学 / 生信项目为什么更适合这样做
- 医学场景：术语、合规、隐私、可追溯要求高，不能接受“差不多能跑”。
- 生信场景：参数多、管线长、可重复性要求高，任何前期模糊都会在后面放大。
- 共同点：都适合在实现前把问题、假设、边界条件和质量门槛写进文档。