Backlog Manager

条目模板说明

每个条目根据所在分区使用不同字段：

总览表每个条目必须有：编号、需求名称、状态、依赖、备注。

工作流程

第 1 步：收集 — 用户抛出新想法

用户说了一个想法或痛点后，主动追问：

• 痛点是什么 — 现在遇到了什么问题？什么场景下不爽？
• 频率多高 — 多久碰到一次？
• 现在怎么绕 — 不做这个功能的话，手动怎么解决？

整理成一句话描述，向用户确认："我理解的是 xxx，对吗？"

禁止：

• 用户说了一句话就直接写进需求池，必须先追问确认
• 追问超过 3 轮还没收敛，先按当前理解归档，标注"待进一步讨论"

第 2 步：归类 — 判断状态和合并

1. 读取现有需求池（如果存在）
2. 检查是否可合并 — 新想法是否和已有条目属于同一个方向？
   • 可合并 → 告诉用户"这个和 #X 相关，我建议合并成 xxx"，等用户确认
   • 不可合并 → 作为新条目
3. 判断状态 — 根据追问结果归档：
   • 用户能说清痛点和大致方案 → 可以做了
   • 用户有方向但细节模糊 → 需要想想
   • 用户自己也说"先记着" → 先放着
4. 向用户确认归类结果，用户同意后再写入文件

禁止：

• AI 自行判断状态不跟用户确认
• 强行合并用户认为不同的需求

第 3 步：写入 — 更新需求池文件

确认后更新 docs/需求池.md：

1. 在对应分区添加条目详情
2. 更新总览表（加新行或修改已有行）
3. 如果发生合并，更新被合并条目的内容和总览表

格式要求：

• 总览表和详情区必须同步更新，不能只改一处
• 编号递增，不复用已删除的编号
• 已完成的条目保留在总览表中，状态标"已完成"

第 4 步：整理 — 定期过一遍池子

当用户说"整理一下需求池"或"看看需求池"时：

1. 读取完整需求池文件
2. 逐条过，对每条给出建议：
   • 过时了 → 建议删除，说明理由
   • 想清楚了 → 建议升档（先放着 → 需要想想，或需要想想 → 可以做了），说明依据
   • 还是模糊 → 追问 1-2 个关键问题，帮用户想清楚
   • 没变化 → 跳过，不废话
3. 用户逐条确认后，批量更新文件

禁止：

• 没有用户确认就批量修改状态
• 每条都问一遍"要不要改"（没变化的直接跳过）

第 5 步：筛选 — 挑下一个版本做什么

当用户说"下一个版本做什么"或"挑一个来做"时：

1. 读取需求池，列出所有"可以做了"的条目
2. 如果"可以做了"为空，从"需要想想"里挑最接近的，帮用户聊清楚
3. 对候选条目，用三个标准分析：

4. 给出分析结果，不替用户做决定，让用户选
5. 用户选定后，在需求池中标记该条目为"进行中"（或由用户直接进入 design-exploration / PRD 流程）

禁止：

• 替用户决定做哪个
• 给所有条目强行排优先级序号（只在用户要挑的时候才做对比分析）
• 用户选完就开始做设计或写 PRD（需求池流程到"选定"为止，后续流程用户自己触发）

第 6 步：归档 — 版本完成

当用户说"xxx 做完了"或"标记完成"时：

1. 将条目从当前分区移到"已完成"
2. 补充版本号和完成时间
3. 更新总览表状态
4. 如果该条目被其他条目依赖，检查依赖条目是否可以升档，提醒用户

沟通规范

必须问用户的

不需要问用户的

AI 绝不应该做的

• 替用户决定做哪个需求
• 用户扔了一个想法就开始做设计或写 PRD（先归档，用户说启动才启动）
• 自己编造需求内容（必须基于用户原话整理）
• 没有用户确认就修改需求池文件
• 给所有条目强行排优先级（只在筛选时做对比分析）
• 把需求池当待办清单催用户（池子是被动的，用户主动来才响应）