阶段 1：需求发现与产品定义

目标：在写第一行代码之前，把「做什么、为谁做、不做什么、怎么算成功」写清楚。单人小项目也要做，只是做轻量版。

输入 / 输出

• 输入：{{软件名称}} {{一句话描述}} {{目标用户}} {{核心功能}}
• 输出：① 1 页发现简报 ② PRD ③ Sprint 拆分 ④ GO/NO-GO 决定

1. 轻量发现（半天内完成，对应 Phase 0 的压缩版）

1. 竞品扫描：找 3–5 个同类软件，记录：基础必备功能（table stakes）、它们的短板、你能占据的一个差异点。
2. 用户痛点：列出 3 个以上有依据的痛点（社区帖子、评论、自身经历均可），每个标注来源。
3. 合规速查：是否涉及个人数据 / 儿童 / 医疗 / 金融？纯本地工具通常低风险，但只要联网或有遥测就要写进 PRD 的隐私章节。
4. 技术可行性：有没有绕不开的硬骨头（系统级 hook、驱动、特殊硬件）？先做 2 小时探针验证。

2. PRD（用 templates.md 的 PRD 模板，必含 8 节）

1. 问题陈述：一段话，用户的痛 + 现状为什么不行
2. 目标与成功指标：North Star 指标 1 个 + 辅助指标 2–3 个（桌面应用常见：7 日留存、周活跃打开次数、崩溃率 <0.5%）
3. 非目标：明确写出这个版本不做什么（防范围蔓延的护栏）
4. 用户画像与故事：1–2 个 persona，每个 3–5 条 "作为...我想要...以便..."
5. 方案概述：核心功能列表 + 每个功能的验收标准（可测量）
6. 技术考量：运行时候选、本地/联网、数据存放位置（提前想好 %APPDATA% 策略）
7. 发布计划：渠道、版本号规则、自动更新策略
8. 风险与回滚：最大的 3 个风险 + 应对

3. 优先级排序（RICE 打分）

对每个候选功能打分：Reach × Impact × Confidence ÷ Effort。

• MVP 只保留总分前 3–5 名；其余进 Later 列表。
• 每条功能必须能用一句话说出"砍掉它会怎样"——说不出就砍。

4. Sprint 拆分（按 {{时间线}} 切）

每周一个 sprint，每个 sprint 有：

• 明确交付物（可演示的东西，不是"调研中"）
• 验收标准
• 最后一周永远是「加固 + 打包 + 发布」，不排新功能

5. 质量门：GO/NO-GO 检查表

#	判据	证据	通过？
1	≥3 个有依据的用户痛点	发现简报	☐
2	差异点明确（不是"更好用的同类"）	竞品分析	☐
3	无阻塞性合规问题	合规速查	☐
4	技术硬骨头已探针验证	探针结果	☐
5	MVP 功能 ≤5 个且都有验收标准	PRD	☐
6	时间线里含独立的加固/发布周	Sprint 表	☐

• GO → 进入阶段 2（架构与选型）
• NO-GO / PIVOT → 记录原因，调整后重跑本阶段（发现阶段返工最便宜）

交接给阶段 2 的内容（原样传递，不要摘要）

- PRD 全文
- 竞品与差异点
- RICE 排序后的 MVP 功能列表
- 技术探针结论
- 关键约束（合规 / 性能预期 / 是否需要联网）