需求池与决策分

入口：/roadmap（管理员菜单「需求池」）。提需求/报 Bug 的统一入口，全流程闭环。

提交与 AI 质检

• 提交字段：类型（💡需求 / 🐛Bug）、所属应用（管理后台/前台客户端/各机器人项目）、功能模块、标题、补充说明、截图（最多 3 张）。
• 提交后自动调 LLM 质检。质检回答的不是「这条写得好不好」，而是「现在能不能直接开工」，产出三样东西：
  • 阻塞问题（blocking_questions）：不回答就没法动手写第一行代码的问题。每条都指明补哪个字段 + 一个能直接回答的问句 + 为什么卡在这。空清单 = 没有阻塞。
  • 拆分建议（split_suggestion）：这条是不是混装了多个「能独立上线、独立验收」的能力。是的话给出拆开后的每一条。
  • 可抢救判定（salvageable）：补充之后有没有可能成为一条有效需求。

为什么我现在会被打回

只有一种情况会被直接关闭并扣分：需求没有实质内容（只有一两个词、纯情绪吐槽、测试字符串、与业务无关）。

写得潦草、少了细节、把两件事写在一起 —— 这些不扣分，会被放进「待补充」，等你补完再自动重新质检。 判断「没内容」和「写得差」的是模型的 salvageable 字段，不是质量分：写得差 ≠ 没内容， 一个描述潦草但真实存在的 Bug 永远不该被关掉。

处置三条（唯一口径，代码在 functions/api/_requirement-review.js 的 decideDisposition）

质检结论	去向	决策分
salvageable = false（无实质内容）	直接关闭	-5
有阻塞问题 / 建议拆分	待补充（needs_info）	不变
都没有	开放池（open）	不变

2026-08-16 之前不是这样：质量分 high/medium/low 三档，但 high 和 medium 一样进开放池， low 直接关闭扣分。于是「需要补充后才能开发」这句结论在系统里没有任何行为后果 —— 结论写进 ai_analysis 躺着，提出人不会回来看，界面也没有回填入口。 真实案例：那条「出图工作台增加上传参考图数量」质检明确写了「参考图作为背景图的具体逻辑未说明」， 照样进池躺着，真要开发时还得回头问提出人。AI 审了等于没审。

待补充（needs_info）怎么走完

1. 进入待补充时三通道通知提出人：站内铃铛 + 飞书卡片 + 邮件，正文就是那份问题清单。
2. 提出人在需求池「待补充」tab 点「去补充」，逐条回答（不用重写整个需求），也可以顺手补截图。
3. 提交后自动重新质检：通过了就进开放池；还有没说清楚的，问题清单会被换成新的一份。
4. 有拆分建议时可以一键拆成多条：每条继承原需求的应用/模块/部门/提出人/截图，各自重新质检， 原来那条关闭并留痕（不扣分，拆分是照着建议做的）。
5. 第 3 天再提醒一次，满 7 天未补自动关闭并扣 5 分（关闭后随时可以重新提一条）。 周期与「7 天使用检查」同一个口径，别再引入第三个数字。 巡检实现：Worker 每分钟敲 POST /api/feedback-info-sweep（判断、扣分、通知都在 Pages 侧）。

流转与管理

• 状态：开放 / 待补充 → 进行中 → 已完成 / 已关闭；五个 tab 分页展示。
• 管理操作：追加备注、设置分类（部门 + 负责人）、优先级 P0（紧急）-P3（低）、指派负责人。
• 标记完成时可关联「埋点 key」（功能对应的菜单/按钮埋点），作为 7 天使用检查的依据；不选则不参与检查。
• 完成/关闭时三通道通知提出人：站内铃铛 + 飞书进度卡片 + 邮件。
• 已完成需求带使用判定徽标：观察期（完成未满 7 天）/ 在用 / 已下线。

提交之后谁来干（2026-09-05）

进开放池不等于有人看见。缺的是「通知到被指派人 + agent 能读池子」，不是再加一张群卡片。

1. 提交当下：飞书 requirement-submit 群文本（原有）+ 站内铃铛推给被指派人（有 assignee 才推）。
2. 质检通过进开放池：再推一次铃铛「可以开工」+ 飞书进度卡（project-progress）。
3. agent 认领：cs 舰队走 GET /api/agent-data?table=feedbacks&eq_status=open，改状态用 POST update（只允许 status/assignee/notes 等白名单列）。后台小美抽屉只读，不能改单。
4. 巡查看板：daily-ops 的「需求池」段读的是这张 feedbacks 表，不是 GitLab issue。hym-admin 没有在用 issue 看板，GitLab 同步只是单向导入，不当真源。

决策分规则（v1.5.0 上线，2026-08-16 修订待补充相关条目）

• 每人初始 100 分，下限 0、不设上限，由系统自动变更，任何人不可手工改。
• +5：需求完成后 7 天内有人使用（判定数据源：全站埋点 menu_usage）。 提出人和负责人各得一份——提的人和做的人各占一半功劳；负责人为空或与提出人同一人时不重复加。
• -15：完成后 7 天无人使用 → 功能自动标记「已下线」，站内通知提出人（扣分原因）和负责人（提醒移除代码）。 只扣提出人，不扣负责人——需求不是负责人挑的，罚接活的人会让没人愿意认领。
• +10：提的 Bug 被标记完成（= 经复现确认且已修）。提出人和负责人各得一份，规则同上。 Bug 走这条、不走上面的 7 天使用检查——Bug 修好了不产生新埋点，用「有没有人用」判它没意义。
• -5：提交的需求无实质内容被 AI 自动关闭，或进入待补充后 7 天没有任何回应。 ⚠️ 只是写得不细、缺细节、混装了两件事 —— 不扣分，走待补充。 补充是正常流程不是惩罚；把这两种情况用同一个扣分动作对待，结果就是不擅长写文档的同事干脆不提了。
• 低于 60 分暂不能提需求（提交按钮禁用 + 后端拦截），多使用已上线功能、验收在用需求可回分。提 Bug 不受此限制。
• 查看：自己的分数和加减分流水在「个人资料」；管理员可在「后台账户」看全员分数。
• 需求池顶部会显示自己的当前决策分。