阅读提示
这页适合当成交付前检查表：先确认需求与方案是否无歧义，再看 Memory 模板、工具选择和最小交付门槛。它不是工具推荐榜，而是一套可迁移的交付框架。
一、你最终应该交付什么
- 一份无歧义的需求与技术方案文档
- 需求对照表、流程图、必要时的 ASCII 原型图
- 需要改动的代码文件清单与关键修改示例
- 测试策略：单测、集成、E2E 和边界验证
- 关键决策记录：哪些是人拍板的、为什么这样定
二、可复用的 Memory 条目模板
【标题】复杂需求处理 SOP 【适用场景】 - 需求模糊、约束多、方案不唯一 - 跨系统协调 - 高准确性、高风险项目 【工作流】 1. 结构化输入需求 2. 多模型独立评审 3. 多轮问题回答与微决策 4. 输出表格 / 流程图 / 原型图 5. 汇总成无歧义文档 6. 交叉评审直到没有新意见 7. 再进入编码 【成功标准】 - 关键问题全部回答 - 文档完整无歧义 - 其他模型无法再提出有效新意见 - 代码实现无需大返工
【标题】复杂需求识别标准 1. 需求模糊度高 2. 涉及多个系统 3. 约束相互制约 4. 需要多次人类决策 5. 技术路线不唯一 满足 2 项以上时，优先进入 VibeCoding，而不是直接写代码。
三、需求分析阶段检查清单
[ ] 已把原始想法结构化为可读需求 [ ] 已列出目标、约束、边界条件 [ ] 已分别让不同模型评审需求 [ ] 已收集所有需要人类决策的问题 [ ] 已完成至少数轮追问与回答 [ ] 已用表格 / 流程图降低歧义 [ ] 已确认没有明显遗漏的问题
四、规划与文档阶段检查清单
[ ] 已生成完整 Markdown 文档 [ ] 文档包含需求描述、技术方案、流程图、文件改动清单 [ ] 文档详细到第三方也能照着实现 [ ] 已完成至少一轮交叉复审 [ ] 已处理所有复审意见 [ ] 其余模型已无法提出关键新问题
五、代码实现前的最小交付门槛
- 需求场景、约束、异常分支都已写清楚
- 关键状态流转可以通过图示解释
- 测试路径明确，不会靠“手点试试”混过去
- 复杂术语、领域规则、合规要求已被显式写入
- 如果是医学 / 生信项目，额外补充术语标准、质控与可重复性要求
六、工具角色建议
如果你是在搭自己的工作流，不必执着某个具体产品名；重点是看工具在链路中扮演的角色：
- 语音输入工具：适合快速把模糊想法说出来
- 结构化文档工具：适合整理表格、流程图和方案版本
- 多模型评审组合：适合从不同角度补漏
- E2E 自动化验证工具：适合在实现后快速跑通关键路径
七、一个更适合站内复用的最小提示词
这是一个复杂需求，请不要直接写代码。 先帮我完成以下工作： 1. 复述需求并指出歧义 2. 列出约束条件与边界场景 3. 提出需要我拍板的问题，并按优先级排序 4. 用表格或流程图整理方案 5. 等我确认后，再输出详细实施文档 6. 在文档获得复审通过前，不进入编码