VibeStart

它解决的不是语法问题

第一次用 AI 做产品的人，最常见的姿势是丢一句 帮我做个网站 然后等结果。真正卡住的地方往往不在代码，而在对话方式：需求没被定义清楚、范围一路膨胀、改完一处又坏了另一处。VibeStart 的思路是把「怎么跟 AI 说话」当成一条有产出的流程来管理，而不是靠灵感发挥。

核心是五阶段闸门

工作流固定为 Empathize → Define → Ideate → Prototype → Test，每个阶段都有明确的进入条件和产出物，不允许跳级。

• Empathize / Define：动手前先完整解析用户上传的文档、图片和参考链接，用列表回述理解，再抛 5-7 个结构化追问；把回答收敛成一段 共识摘要，并标出 P0/P1/P2 优先级，防止范围蔓延。
• Ideate：列出 2-3 个可行方向，分别分析技术成本、用户体验和可维护性，并生成概念图、流程图或素材 demo 来验证共识，而不是直接开写。
• Prototype：按依赖顺序建 todo list，先跑通「首页 + 一个功能 + 能看到结果」的最小闭环，再叠加核心玩法、内容数据和视觉包装。PRD 不是一次性写完的文档，而是随对话轮次逐步生长的记录。
• Test：把「这里不太对」翻译成结构化反馈，分析改动会影响哪些模块，按依赖顺序执行修复并复验结果。

四条红线

技能会明确拒绝四类请求：模糊需求、跳过确认直接设计、没有可视化就编码、含糊的修改意见。对应的是新手最常见的六个坑：需求模糊、范围蔓延、完美主义、反馈模糊、跳过验证、换会话后丢失上下文。

适用边界

它负责的是流程与对话质量，不替代技术选型和具体实现。如果团队已经有清晰 PRD 和迭代节奏，收益有限；更适合从一句话起步、需要外部约束把想法逐步推到 MVP 的个人开发者。模板与流程图集中在 references/ 和 assets/ 下，可以直接照着改。