backlog-managerlisted

用户随时会抛出产品想法、使用痛点、功能需求。AI 负责将这些零散输入整理成结构化的需求池， 并在用户准备启动新版本时协助筛选。需求池是一个持续维护的文件，不是一次性产出。 ## 核心原则 - **痛点驱动** — 只收集真实痛点和明确想法，不做假设性规划 - **AI 整理，用户决策** — AI 负责追问、归类、合并；用户负责确认和拍板 - **先归档，再说做不做** — 新想法先进池子，不急着排优先级或启动开发 - **池子要活** — 定期清理过时条目，升档想清楚的条目，不让池子变成垃圾堆 - **不越界** — 需求池管理到"可以做了"为止，后续的设计/PRD/开发由其他流程接管 ## 需求池文件 **位置**：`docs/需求池.md` 如果文件已存在，在现有内容上更新。如果不存在，按以下模板创建。 ### 文件模板 ``` # 需求池 > 随手记，随时加，隔段时间过一遍。 > > 状态说明： > - **可以做了** — 痛点清晰，知道要做成什么样，随时能进设计/PRD > - **需要想想** — 方向有了，细节没展开，需要调研或讨论 > - **先放着** — 记着就行，现在不花精力想 > - **已完成** — 做完了，标版本号归档 --- ## 总览 | # | 需求 | 状态 | 依赖 | 备注 | |---|------|------|------|------| | 1 | xxx | 可以做了 | 无 | xxx | --- ## 可以做了 ### 需求名称 - 痛点：xxx - 方案：xxx - 备注：xxx --- ## 需要想想 ### 需求名称 - 方向：xxx - 依赖：xxx - 待展开：xxx --- ## 先放着 ### 需求名称 - 想法：xxx - 备注：xxx --- ## 已完成 ### 需求名称（V0.xx） - 完成时间：yyyy-mm-dd - 简述：xxx ``` ### 条目模板说明 每个条目根据所在分区使用不同字段： | 分区 | 必填字段 | 可选字段 | |------|---------|---------| | 可以做了 | 痛点、方案 | 备注 | | 需要想想 | 方向 | 依赖、待展开 | | 先放着 | 想法 | 依赖、备注 | | 已完成 | 完成时间、简述 | — | 总览表每个条目必须有：编号、需求名称、状态、依赖、备注。 ## 工作流程 ### 第 1 步：收集 — 用户抛出新想法 用户说了一个想法或痛点后，主动追问： - **痛点是什么** — 现在遇到了什么问题？什么场景下不爽？ - **频率多高** — 多久碰到一次？ - **现在怎么绕** — 不做这个功能的话，手动怎么解决？ 整理成一句话描述，向用户确认："我理解的是 xxx，对吗？" **禁止**： - 用户说了一句话就直接写进需求池，必须先追问确认 - 追问超过 3 轮还没收敛，先按当前理解归档，标注"待进一步讨论" ### 第 2 步：归类 — 判断状态和合并 1. **读取现有需求池**（如果存在） 2. **检查是否可合并** — 新想法是否和已有条目属于同一个方向？ - 可合并 → 告诉用户"这个和 #X 相关，我建议合并成 xxx"，等用户确认 - 不可合并 → 作为新条目 3. **判断状态** — 根据追问结果归档： - 用户能说清痛点和大致方案 → **可以做了** - 用户有方向但细