--- name: project-backlog description: 项目待办管理器（两种模式）。【收集模式】接收任意混合输入 → 解析追加到「项目待办.md」文档，不立即执行；【处理模式】读取文档 → 前置决策收集 → 按优先级逐条路由执行 → 更新状态 → 批次报告。触发词：【收集】「有几个问题先记到待办」「加到项目待办」「先存到待办文档」「记录这些待办」；【处理】「处理项目待办」「按待办文档逐条修复」「开始处理待办文档」。⚠️ 触发词必须含「待办」关键词才激活，避免与 issue-tracker / bug-fix-loop 混淆。 --- # 项目待办管理器（project-backlog） > **核心原则：文档即状态，不依赖 AI 记忆。** > 任何输入先存文档；执行状态写在文档里；进程中断后可从文档恢复，不丢失。 --- ## 认知根 认知根：`_内部总控/认知结构/L1_系统性文档/系统架构思维维度/Skill体系设计原则_v1.0.md` 关联：「文档即状态」是本 Skill 的核心执行范式。 --- ## 待办文档规范（项目待办.md） **位置**：`项目群/[项目名]/产品经理/项目待办.md` （优先用 project-config.md 中的 PATH_待办 字段覆盖） **标准格式**： ```markdown # 项目待办 > 所有类型的输入先到这里。说「处理项目待办」可触发自动处理流程。 | ID | 类型 | 内容摘要 | 来源日期 | 优先级 | 状态 | |----|------|---------|---------|--------|------| | B-01 | Bug | [描述] | YYYY-MM-DD | P0/P1/P2 | 🔲 | | F-01 | Feature | [描述] | YYYY-MM-DD | — | 🔲 | | U-01 | UX | [描述] | YYYY-MM-DD | P1 | 🔲 | | P-01 | 原则 | [描述] | YYYY-MM-DD | — | 🔲 | | R-01 | 规范偏差 | [描述] | YYYY-MM-DD | — | 🔲 | | D-01 | 设计建议 | [描述] | YYYY-MM-DD | — | 🔲 | ``` **状态标记**：🔲 待处理 / 🔄 处理中 / ✅ 已完成 / ❌ 执行失败 / ⏸️ 搁置（待决策）/ 📬 已移交 **ID 前缀**：B=Bug / F=Feature / U=UX / P=原则 / R=规范偏差 / D=设计建议 + 两位流水号 **架构层标签（B-xx Bug 可选，AI 平台项目推荐填写）**： L0=部署模型 / L1=状态管理 / L2=并发模型 / L3=LLM调用 / L4=数据隔离 / L5=Agent框架 / L6=可观测 / L7=安全 / L8=性能 / L9=扩展 / FE=前端 示例：`B-01 | Bug | [L1] 更新认知显示构建中 | ...` --- ## 知识导航表（执行前读取） | 层级 | 文档 | 读取目的 | |------|------|---------| | D0 | `.cursor/project-config.md`（若存在）| 获取 PATH_待办 和 PATH_技术追踪台 | | ① | `_内部总控/元项目导航.md` | project-config 不存在时确认当前活跃项目 | --- ## 可用 Skill 速查表（P-2 生成激活命令时的唯一参考） > ⚠️ 生成激活命令时必须参考此表，不得凭记忆猜测触发词 | 待办类型 | 触发词（【X】格式）| 对应 Skill | 该 Skill 处理什么 | 前置条件 | |---------|-----------------|-----------|-----------------|---------| | **P-xx 原则类** | `【立原则】：[原则描述]` | engineering-principle-recorder | 新工程/执行原则录入到 Rule/Role Skill 执行层，并审计现有违规 | 无 | | **B-xx P0/P1 Bug**（需立即修复）| `【修复循环】` | bug-fix-loop-coordinator | 读技术追踪台，P0→P1 循环 TDD 修复，直至清零。⚠️ 需要 Bug 已在追踪台中（P-2-1 写入追踪台后再激活）| 技术追踪台已有条目 | | **B-xx P2 Bug**（仅记录）| `【记录问题】[Bug描述]` | issue-tracker | 拆分并记录到产品/技术追踪台，不立即修复 | 无 | | **F-xx Feature**（新功能需求）| `【协调者】：[需求描述 + 用户决策]` | role-产品开发协调者 | 判断任务类型并编排完整产品开发流水线（PM→关卡A→架构师→关卡B→开发→关卡C→DevOps）| 无 | | **U-xx UX 问题**（体验问题）| `【协调者】：[UX问题 + 用户决策]` | role-产品开发协调者 | 同上，协调者判断走产品修复还是前端/UI修复 | 无 | | **R-xx 规范偏差**（已有规范被违反）| `【规范修复】：[规范偏差描述]` | project-convention-resolver | 接收–分类–路由–验证；已知规范的偏差修复（与「立原则」的区别：这里处理已有规范的违反，不是立新规范）| 无 | | **D-xx 设计建议**（纳入迭代）| `【协调者】：评估设计建议：[描述]` | role-产品开发协调者 | 产品/技术层面评估并纳入开发计划 | 无 | | **D-xx 设计建议**（仅存档）| 无需激活 Skill，project-backlog 直接写入 | — | 直接追加到技术架构.md「设计建议存档」节 | 技术架构.md 已存在 | **B-xx P0/P1 Bug 的两步流程说明**： ``` P-2-1 生成激活命令时，Bug 条目额外执行两步（在生成【修复循环】命令之前）： Step A: Read [PATH_技术追踪台]（默认：技术架构师/技术问题追踪台.md） Step B: StrReplace 追加 issue 条目： | [日期] | [Bug描述] | P0/P1 | [复现步骤/文件] | 🔲 待修复 | （若追踪台不存在则先创建） 然后生成激活命令：【修复循环】 ``` --- ## 激活后：判断操作模式 ``` ⚠️ 首先判断触发的是哪种模式 收集模式信号： 消息含「待办」+「记录/存/先放着」等延迟动词 「加到项目待办」「先存到待办文档」「记录这些待办」 含编号列表 + 延迟信号词 → 收集模式 处理模式信号： 「处理项目待办」「按待办文档逐条」「处理待办文档里的」 → 处理模式 ⚠️ 必须含「待办」关键词才触发本 Skill（防止与 issue-tracker / bug-fix-loop 冲突） ⚠️ 两种模式同时出现（「记到待办然后马上处理」）→ 先完整执行收集（C-0~C-3），再询问是否立即处理 ⚠️ 不确定时 → 问用户：「您是要先记录到待办文档，还是立即开始处理？」 ``` --- ## 收集模式（COLLECT） ``` Step C-0 【确认待办文档路径】 ① Read: .cursor/project-config.md（若存在）→ 读 PATH_待办 ② 若无 config → Read: _内部总控/元项目导航.md → 识别当前项目 ③ 若仍不确定 → 问用户：「当前操作哪个项目？」 ⚠️ 禁止用 IDE 打开的文件推断项目（ide-context-guard 规则） 默认路径：项目群/[项目名]/产品经理/项目待办.md 若文件不存在 → 创建文件，写入标准表头（见上方规范） Step C-1 【解析输入为结构化条目】 逐条扫描用户消息中的独立意图： 对每个独立意图提炼： - 摘要：一句话（≤40字，说清「什么东西 + 什么问题」） - 类型（参考可用Skill速查表）： Bug = 有明确错误行为（系统报错/功能失效/数据错误） Feature = 新功能需求 UX = 体验/交互问题（不是 Bug，但影响使用感受） 原则 = 「以后都要」「这是原则」「系统应该怎样运行」 规范偏差= 「这不符合规范」「这违反了规范」（已有规范被违反） 设计建议= 架构思路/技术方向/产品建议（非强制需求） - 优先级（仅 Bug 类）：P0=阻塞 / P1=影响核心流 / P2=次要 ⚠️ 若解析出 0 条独立意图 → 不执行 C-2，输出： 「未识别到独立条目，请分条列出（如用编号或换行分隔）」→ 等待用户重新输入 宁多勿少：有疑问时保留条目；重复的意图合并为一条 Step C-2 【追加到待办文档】 Read: [PATH_待办]（先读，获取当前最大 ID 编号，确认表格完整） ⚠️ 若表格格式异常（缺表头/非标准列）→ 告知用户并先修复表头，不追加 StrReplace 在表格末尾追加新行（每条一行，ID 继续编号） Step C-3 【确认输出】 输出格式： 「✅ 已记录 N 条待办： [B-01/P1] 更新认知时显示「正在构建中」 [P-01] LLM 调用不截断上下文（原则） [B-02/P0] 对话历史消失 [R-01] 日志截断违反不截断原则（规范偏差） [F-01] 实时显示AI思考过程（新功能） [D-01] 状态管理按生命周期分层（设计建议） ... 文档路径：[PATH_待办] 说「处理项目待办」可触发自动处理流程。」 ``` --- ## 处理模式（PROCESS） ``` Step P-0 【读取待办文档 + 构建执行队列】 Read: [PATH_待办]（全文读取，不截断；若文件不存在 → 告知「待办文档不存在」→ 停止） 解析所有 🔲 条目（按 | 分隔的表格行）： ⚠️ 若解析失败（格式混乱）→ 输出原文片段，告知用户修复格式或重新用收集模式录入 ⚠️ 若无 🔲 条目 → 告知「当前没有待处理条目」→ 停止 按以下规则排序（数字小的先执行）： 第一轴：类型（最高优先） 1. P-xx 原则类 — 影响所有后续修复方向，必须最先处理 2. B-xx Bug 类 — 技术问题，按第二轴（架构层）细化排序 3. U-xx UX / F-xx Feature — 功能/体验问题，按架构层或产品决策排序 4. D-xx 设计建议 — 最低优先，通常只存档 第二轴（仅 B-xx Bug 类内部）：架构层（AI 平台项目） 若条目 ID 含架构层标签（如 [L1]）： L1（状态管理）> L2（并发）> L3（LLM调用）> L4（数据隔离）> L5（Agent框架）> FE（前端） 若无层标签：按 P0 > P1 > P2 排序（传统方式，兜底） 第三轴（同层内）：AI 确定/不确定 AI 确定（唯一明确修法）先执行 AI 不确定（需设计决策）在 P-1 前置决策中收集 同优先级按 ID 编号顺序 Step P-1 【前置决策收集（Feature/UX/设计建议类）】 扫描队列，找出需要用户判断的项： - F-xx Feature 类：有多种实现方案 → 询问方案选择 - U-xx UX 类：设计方向不明 → 询问期望体验 - D-xx 设计建议 → 询问「纳入当前迭代 / 下个迭代 / 仅存档」 ⚠️ 一次性集中提问，不分散： 「处理前需确认 N 个决策点： [F-01] 实时显示AI思考过程 → A: SSE 推送节点状态 B: 前端轮询 [D-01] 状态管理分层重构 → 纳入当前迭代 / 仅存档 请依次回答（如「A, 存档」）」 用户回答 → 记录决策到对话上下文 → 进入 P-2 某条用户说「跳过」或不回答 → 该条标记 ⏸️ 搁置，激活队列中排除 若全部为 A 类（原则/Bug，无需决策）→ 跳过 P-1 直接进 P-2 Step P-2 【生成激活队列并输出（不自行执行，交由专业 Skill）】 ⚠️ 核心设计原则：project-backlog 只负责「收集」和「排队」，不执行具体任务。 每条待办必须由对应的专业 Skill 正式激活后执行，才能保证： - D0 认知根读取（产品定义/技术架构等前置文档） - 完整的流程门控（关卡/测试/文档同步） - 正确的角色视角（后端开发 ≠ 测试工程师 ≠ 产品经理） ⚠️ project-backlog 自行执行 = 绕过所有规范 = 等于没有规范 Step P-2-1 为每条 🔲 条目生成对应的激活命令 （⚠️ 必须参照上方「可用 Skill 速查表」，不得凭记忆）： [P-xx 原则类] → 激活命令：「【立原则】：[原则精确描述]」 [B-xx P0/P1 Bug]（⚠️ 两步，先写追踪台再生成命令） Step A: Read [PATH_技术追踪台]（不存在则 Write 创建） Step B: StrReplace 追加 issue 行到追踪台 → 激活命令：「【修复循环】」 （bug-fix-loop-coordinator 会读追踪台，追踪台必须先有条目） [B-xx P2 Bug] → 激活命令：「【记录问题】：[Bug描述]」 （issue-tracker 仅写入追踪台，不触发修复） [F-xx Feature] → 激活命令：「【协调者】：[需求描述 + P-1中用户决策]」 （role-产品开发协调者 编排完整产品开发流水线） [U-xx UX 问题] → 激活命令：「【协调者】：[UX问题描述 + 用户决策]」 （同上，协调者判断走产品修复还是前端/UI修复路线） [R-xx 规范偏差] → 激活命令：「【规范修复】：[规范偏差描述]」 （project-convention-resolver 分类路由验证已有规范的违反） [D-xx 设计建议（用户决策：纳入迭代）] → 激活命令：「【协调者】：评估设计建议：[描述]」 [D-xx 设计建议（用户决策：仅存档）] → 无需激活其他 Skill → 直接：StrReplace 追加到技术架构.md「设计建议存档」节 → 状态直接改为 ✅（已存档） Step P-2-2 输出执行计划（仅展示，立即进入 P-2-3 执行）： 「📋 开始按优先级逐条执行（N 条）： 1. [P-01] 原则 → 激活 engineering-principle-recorder 2. [B-01/P0, B-02/P1] Bug → 写入追踪台 → 激活 bug-fix-loop-coordinator 3. [F-01] Feature → 激活 role-产品开发协调者 ... ⏸️ [D-01] 搁置（等待您决策） ──────────────────」 Step P-2-3 逐条完整执行（无需用户确认，自动推进）： ⚠️ 「完整执行」的定义（与 v1.0 的「按其步骤执行」本质不同）： Read [目标 SKILL.md] → 切换为对应角色视角 → 执行「激活后立即执行」序列中的 EVERY step，包括： · D0 认知根读取（所有 Read 操作，不跳过） · 知识导航表中列出的所有前置文档读取 · 每个 Step 的所有工具调用（Write/StrReplace/Shell/浏览器等） → 不简化、不跳步 → 与用户直接说「【X】：[内容]」触发的效果完全等同 对每条 🔲 条目，按排序顺序： ── P-xx 原则类 ── StrReplace 状态 → 🔄 Read: .cursor/skills/engineering-principle-recorder/SKILL.md 完整执行其所有 Step（含 Step 0 读元项目导航、Step 1 分类、Step 2-B/C/D 写入、Step 3 报告） 完成 → StrReplace 状态 → ✅ ── B-xx P0/P1 Bug ── StrReplace 状态 → 🔄 Read [PATH_技术追踪台]（不存在则 Write 创建） StrReplace 追加 issue 条目到追踪台 Read: .cursor/skills/bug-fix-loop-coordinator/SKILL.md 完整执行其所有 Step（含 Step 0 读追踪台、Step 1.5 读产品定义、循环修复等） ⚠️ Bug 修复完成后必须执行关卡C（不等用户，自动推进）： Read: .cursor/skills/role-测试工程师/SKILL.md 完整执行其所有 Step（含 D0、Step 0.4 基线建立、五类测试、Step 6.4 覆盖门禁、Step 6.6 写凭证） 关卡C通过 → StrReplace 状态 → ✅ 关卡C发现新 Bug → 写入追踪台 → 继续修复循环（不标 ✅，标 🔄 继续中） ── B-xx P2 Bug ── StrReplace 状态 → 🔄 Read: .cursor/skills/issue-tracker/SKILL.md 完整执行其所有 Step（澄清现象、分类、写入追踪台） 完成 → StrReplace 状态 → ✅（已记录） ── F-xx Feature / U-xx UX ── StrReplace 状态 → 🔄 Read: .cursor/skills/role-产品开发协调者/SKILL.md 完整执行其所有 Step（含任务类型判断、briefing生成、编排后续角色） 完成（协调者完成其briefing输出）→ StrReplace 状态 → 📬 已移交 ── R-xx 规范偏差 ── StrReplace 状态 → 🔄 Read: .cursor/skills/project-convention-resolver/SKILL.md 完整执行其所有 Step（接收-分类-路由-验证） 完成 → StrReplace 状态 → ✅ ── D-xx 仅存档 ── StrReplace 状态 → 🔄 Read: [项目路径]/技术架构师/技术架构.md（若存在） StrReplace 追加到「设计建议存档」节 StrReplace 状态 → ✅（已存档） 每条完成后输出进度：「✅ [ID] 已完成（N/Total）」→ 继续下一条 若某条执行失败 → StrReplace 状态 → ❌（原因）→ 继续下一条，不中止 Step P-3 【所有条目处理完成后的总结报告】 ⚠️ 此步骤在激活队列全部为非🔲状态时执行 Read: [PATH_待办]（读取最终状态） 输出格式： 「📊 待办处理完成 ────────────────────────────────────── ✅ 已完成：N 条 📬 已移交：M 条（等待对应 Skill 后续处理） ⏸️ 已搁置：K 条（需后续决策） ────────────────────────────────────── 详细记录见：[PATH_待办]」 ``` --- ## 常见失败模式 ``` 失败1：触发词「有几个问题」被 A1 产品开发域抢占 → 根因：消息含「问题/bug」特征被路由到协调者，本 Skill 不被激活 → 预防：用户需使用含「待办」的触发词；session-bootstrap 排除条件中已加「项目待办/待办文档」 失败2：执行目标 Skill 时走捷径（跳过 D0 读取或知识导航表） → 根因：AI 认为「我已经知道这个 Skill 做什么了」，省略了 Read 步骤 → 预防：P-2-3 明确「完整执行」定义——EVERY step，包括所有 Read 操作；看到跳步立即重新执行 失败3：处理模式中途停止（P-3 未执行） → 根因：某条引导过程中断，AI 以为任务结束 → 预防：P-3 是强制步骤；队列中有 🔲 条目时不能输出 P-3 失败3：Feature 移交后标 ✅（错误） → 根因：Feature 设计流程未完成，仅移交给协调者 → 预防：Feature/UX 移交后标 📬 已移交，不标 ✅ 失败4：零条可解析时写入空行 → 预防：C-1 后若 N=0，不执行 C-2，输出提示请用户分条列出 失败5：内部触发子 Skill 变成伪造用户消息（导致嵌套触发） → 根因：AI 发新用户消息包含触发词，再次命中 A1 路由 → 预防：P-2 明确「内部 dispatch：Read SKILL.md 按其步骤执行，禁止伪造用户触发句」 ``` --- ## 注意事项 - **收集不执行**：收集模式只写文档，不触发任何修复或设计流程 - **文档是状态**：所有状态写在 `项目待办.md`，AI 进程中断可从文档恢复 - **P2 Bug 只记录**：写入追踪台但不修复，控制批次执行范围 - **Feature 只移交**：Feature/UX 移交协调者后标 📬，等待协调者完整处理 - **触发词必须含「待办」**：防止与 issue-tracker / bug-fix-loop 的触发词冲突 --- ## 变更记录 ### v1.3 — 2026-03-25 — P-2 改为自动逐条完整执行（移除手动确认流程） **根因**：v1.1/v1.2 的「输出激活命令 → 等用户复制发送」设计过于保守，用户需要手动 复制粘贴每一条命令，体验极差。用户的正确预期是：一句「处理项目待办」→ 系统自动完整执行。 **关键洞察**： - v1.0 的问题是「完整执行」指令不明确，AI 走捷径跳步骤 - 解决方案不是「让用户手动触发每条」，而是「给出足够明确的完整执行指令」 - P-2-3 新增「完整执行」精确定义：EVERY step + 所有 Read 操作 + 所有工具调用 + 不跳步 **修改内容**： - 移除 P-2-4/P-2-5（手动确认和逐条引导流程） - P-2-2 改为展示执行计划（立即开始，无需确认） - P-2-3 改为「逐条完整执行」，含对每类 Skill 的精确执行指令 **备份路径**：`history/SKILL_v1.0_20260325_before_dispatch-fix.md` --- ### v1.2 — 2026-03-25 — 可用Skill速查表 + 规范偏差类型 + P-2-1 精确路由 **根因**：v1.1 的 P-2-1 激活命令映射基于推断，未核实真实 Skill 触发词和处理范围； 缺少规范偏差（R-xx）类型；B-xx Bug 未考虑「需先写追踪台再激活修复循环」的前置步骤。 **修改内容**： - 新增：「可用 Skill 速查表」章节（基于读取全部真实 SKILL.md 文件后整理） - 新增：R-xx 规范偏差类型（→ 【规范修复】/ project-convention-resolver） - 更新：C-1 类型分类加入「规范偏差」和更准确的类型描述 - 更新：P-2-1 路由为两步流程（B-xx P0/P1 先写追踪台，再生成【修复循环】命令） - 更新：D-xx 纳入迭代 → 【协调者】（原为【架构师】，协调者才是入口） **数据来源**：逐一读取 role-产品开发协调者/issue-tracker/bug-fix-loop-coordinator/ engineering-principle-recorder/role-测试工程师/role-产品经理/role-技术架构师/ role-前端开发/role-后端开发/role-AI工程师/role-DevOps/fixer/project-convention-resolver 的 SKILL.md 原始文件 **备份路径**：`history/SKILL_v1.0_20260325_before_dispatch-fix.md` --- ### v1.1 — 2026-03-25 — P-2 重构：内部dispatch → 激活队列输出 **根因**：v1.0 的 P-2「内部 dispatch」= AI 自己模仿 Skill 行为，跳过了 D0 读取、 文档守门、关卡等所有规范步骤，导致任何被「内部调用」的 Skill 实际上没有被真正执行。 Bug 修复没有读产品文档、功能需求没有走关卡、原则录入没有搜索违规——完全不符合规范。 **设计原则更新**： - project-backlog 只负责「收集」和「排队」，不执行具体任务 - 所有任务必须通过「激活队列 → 用户显式触发 → A0.5 正式激活对应 Skill」完成 - 这样每个 Skill 都能完整走 D0 读取 + 完整流程步骤 **修改内容**： - P-1：保留前置决策收集逻辑 - P-2：完全重写为「生成激活队列 + 输出 + 引导逐条执行」 - P-3：改为「队列全清空后的总结报告」 - 新增失败模式：AI 自行执行而非生成队列 **配套说明**： 通用设计原则（对所有 Skill 有效）： 「任何 Skill 不应尝试内部执行另一个 Skill，应输出显式激活命令交给 A0.5 处理」 **备份路径**：`history/SKILL_v1.0_20260325_before_dispatch-fix.md` --- ### v1.0 — 2026-03-24 — 初始创建（关卡A/B 修复后版本） **根因**：缺少前置收集层，混合输入被立即路由，意图遗漏且无法积累待办。 **关卡A 修复**： - P-1 标题修正为「Feature/UX/设计建议类」（非「B类」） - P-2「等待完成」改为「Read SKILL.md 按其步骤执行，完成后更新状态」 - Feature/UX 状态改为 📬 已移交（不标 ✅） - C-1 零条解析时不写文件 - 触发词新增「待办」作为必要关键词，与 issue-tracker 区分 **关卡B 修复**： - 触发词改为「处理项目待办/按待办文档逐条」（含「待办」强绑定，与 bug-fix-loop 区分） - 模式判断段明确「必须含待办关键词才激活」 - P-2 明确「内部 dispatch，禁止伪造用户触发句」 - role-menu + session-bootstrap 已在部署步骤中更新（见下方） **产品定义草稿**：`.cursor/skills/skill-designer/draft-project-backlog.md` **Level 3 集成型**：依赖 engineering-principle-recorder / bug-fix-loop-coordinator / role-产品开发协调者