@hupan56/wlkj 3.4.2 → 3.4.4

package/templates/qoder/commands/wl-prd.md

@@ -1,371 +1,87 @@
----
-name: wl-prd
-description: "需求: 完整(13章,新功能) / 快速(6章,小改动) / 评审(检查质量)。默认根据描述自动判断。"
-argument-hint: "[完整|快速|评审] [需求描述]  可选: 参考:<insight报告路径>"
-auto-approve: true
-allowed-tools: [Read, Glob, Grep, Bash, Write, Edit]
----
-
-# /wl-prd - 需求工序站
-
-User input: $ARGUMENTS
-
-> **写需求 / 评审需求，一个命令搞定。**
-> 模块契约：`.qoder/contracts/prd.md`
-
-## 🔧 工具优先级（宿主能力 × 知识层分工）
-| 步骤 | 用谁 | 原因 |
-|------|------|------|
-| 搜文件内容 | **Qoder Grep/Read** | 精确搜代码，原生更快 |
-| 取业务上下文 | **MCP context_pack** | 语义聚合8段(代码+API+字段+Wiki+PRD) |
-| 取团队记忆 | **MCP get_learnings** | 引擎积累的业务规则 |
-| 查真表结构 | **MCP query_schema** | 数据库真实列名 |
-| 生成 PRD 正文 | **Qoder AI** | 宿主 AI 比我们调 qwen-plus 更强 |
-| 写文件 | **Qoder Write** | 原生文件操作 |
-
-## 🚨 工具接口铁律（见 tool_guide · 会话已注入精简版）
-
-**单一信源** `.qoder/scripts/tool_guide.md`（SessionStart 已注入精简版：repo_root 定位 / 三套名 wlkj·kg·MCP 互通 / 中文歧义词提炼 / 优先级口诀）。需完整三套名映射表或歧义词清单时 Read 它。
-**两条红线常记**：① 三套名字都认（`search`/`semantic`/`context`），别因"未知子命令"慌张；② 禁 `find data/code` / `grep -r` 找模块——那是知识层 search 的活，手动做=思考链跑飞；只有 search 换词仍返 0 或已定位到具体文件时才 Grep/Read。
-
-## 🧠 Planning Agent（完整模式强制前置 · 非建议）
-
-> ⚠️ **完整模式必须先 Planning 再生成**（不再是"建议"）。
-> Planning 拆出 13 章计划 → 逐章生成有骨架不漏章；跳过 Planning 直接写易漏章节（真实反面：海外考勤 PRD 只写 1 章就交差）。
-
-### 强制流程（完整模式取完上下文后第一步）
-1. 取完上下文（context_pack）后，**先出 Planning**：把 13 章拆成计划（每章要点 + 引用哪条 MCP 知识命中）
-2. Planning 通过 → 逐章生成，每章参考 MCP 知识上下文
-3. 全部完成 → 调 MCP submit_return 回流平台
-
-### 降级（宿主无 Planning Agent 模式）
-手动按 13 章模板（`templates/prd-full-template.md`）逐章列要点，列完再写正文——等价于手动 Planning，**不跳过拆章这一步**。
-
-> 快速模式（6 章）不强制 Planning——章节少，直接 prd-quick agent 3 步出。
-
-## 🚦 路由（看第一个词或描述特征）
-
-### 🔴 命令优先铁律（最重要，先读）
-**只要用户打了 `/wl-prd`，就必须产出 PRD，绝不跨命令跑去别处。**
-哪怕描述含"报错/无法提交/bug/异常"这类词（如"养护计划无法提交，时间报错"——这是要为修复写需求），也走本命令出 PRD，**不准**跑去 `/wl-test`（测试）/ `/wl-code`（直接改码）/ 排查。
-- 用户要写需求 → 本命令（不管描述像 bug 还是新功能）
-- 用户要直接改代码 → 那是 `/wl-code`，但前提是用户打的是 `/wl-code`
-- 判断不准 → 问一句，不要擅自换命令
-
-| 用户说 | 模式 | 走哪个 |
-|--------|------|--------|
-| "完整""深度""正经需求" 或 描述含"新模块/新业务/新流程" | **完整** | prd-full-template（13 章）|
-| "快速""小改动""加个""改下" 或 加字段/按钮/文案/导出 | **快速** | prd-quick-template（6 章）|
-| "评审""检查""质量""合格吗" | **评审** | 7 项 checklist + EVA 评分 |
-| 判断不了 | **问一句**："是完整需求(新功能)还是小改动(加字段/按钮)？" |
-
-### 默认规则
-- 没说模式 + 描述像新功能 → 默认**完整**
-- 没说模式 + 描述像小改动 → 默认**快速**
-- 给了 PRD 文件路径 → **评审**
-
----
-
-## 🔧 仓库根定位（完整档/快速档共用，进任何模式前先跑这一条）
-
-> QoderWork 桌面端 cwd 不在仓库根（在 `.qoderwork/workspace/xxx`），相对路径
-> `.qoder/scripts/...` **必然失败**（真实踩坑：连续 2 条命令报错浪费一轮）。
-> 进模式前**必须先定位仓库根**。Mac 只有 python3，两个都试：
-
-```bash
-R=$(python ~/.qoderwork/repo_root.py 2>/dev/null || python3 ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
-PY=$(python --version >/dev/null 2>&1 && echo python || echo python3)
-```
-> 后续所有 `$PY "$R/.qoder/scripts/..."` 都用这两个变量。**不准自己编 `cd /d` / 裸相对路径**。
-
----
-
-## 完整模式（13 章 PRD）
-
-**新模块/新业务/新流程用这个。** 支持衔接 insight：`参考:<报告路径>`
-
-> **宿主 sub-agent 激活**：QoderWork 支持 sub-agent 时，完整模式可 dispatch 到 **`prd-reference`** agent（`.qoder/agents/prd-reference.md`）——它承担"现状分析"（定位文件 + 总结现状怎么做/已知限制）+ 参考现有数据生成 PRD+原型，10 点质检内置。dispatch prompt 传 platform + 需求 + 开发者名。生成前先过上方 🧠 Planning 强制前置。不支持 sub-agent 则按下文手动取上下文流程。
-
-**铁律：平台必问。** 先问：
-```
-这个需求是针对哪个平台？
-1. Web 管理端 (fywl-ui)
-2. APP 移动端 (Carmg-H5)
-3. 两端都要
-请选择 (1/2/3):
-```
-
-### 取上下文（context_pack Fast Path 为主 + rag_search/context_360 兜底 — 语义召回最全，接地写 PRD）
-
-**写 PRD 前必做的知识预取：Fast Path 用 context_pack 一次取全（代码+API+字段+风格+相关PRD），替代 rag_search+context_360 两次往返；再叠 ask_corpus（业务流程）+ get_learnings（之前学到的）+ query_schema（真库表结构）。不要只靠 search_code 关键词。**
-
-```python
-from capability import resolve
-cap = resolve()
-# ⓪ req_trace 查同需求历史画像（防重复造轮子）：有 REQ-ID 时先查这个需求已有哪些 PRD/代码/表
-if <有 REQ-ID>:
-    cap.mcp.call("req_trace", {"req_id": "<REQ-ID>"})  # 返回 PRD+代码+表+测试，避免重复写已有功能
-# ⓪b find_similar_prds 找相似历史需求（防重复造轮子，跨项目）：无 REQ-ID 也能查
-#    输入需求描述 → 语义最相似的 top-K 历史需求(commit-mined)，看是否已有人做过类似功能
-#    返回 sim_label(高度相似/相关/弱相关)+借鉴的代码实体名；高度相似的先看再决定是否重写
-similar = cap.mcp.call("find_similar_prds", {"query": "<需求描述>", "top_k": 5})
-# 若两条需求高度相似，可 diff_requirements 对比它们 touched_entities 差异（共有/独有代码+Jaccard）
-# ① context_pack Fast Path（1 次往返取全上下文：代码+API+字段+风格+相关PRD）
-#    等价于 rag_search + context_360 合并，轮次减半（原 5 次 → 3 次）
-pack = cap.mcp.call("context_pack", {"query": "<业务词或需求描述>", "project_id": "<项目UUID>"})
-# ①b 召回不够（缺某类/命中为空）时单独补 rag_search 一次（语义召回兜底，fallback）
-if not pack.get("items"):
-    rag = cap.mcp.call("rag_search", {"query": "<业务词或需求描述>", "top_k": 10})
-# ①c 仍需某核心业务对象的完整关联（代码+页面+字段+API）时，补 context_360（fallback）
-if <需要某符号的全上下文>:
-    ctx = cap.mcp.call("context_360", {"symbol": "<核心业务对象>"})
-# ② 有"业务流程整体怎么运转"的疑问时，补 ask_corpus 拿 GraphRAG 答案
-flow = cap.mcp.call("ask_corpus", {"q": "<业务词>的业务流程是什么", "top_k": 3})
-# ③ get_learnings 查之前学到的业务规则/偏好（反哺：上次踩的坑这次别犯）
-learnings = cap.mcp.call("get_learnings", {"project_id": "<项目UUID>", "limit": 10})
-# ④ query_schema 查真实数据库表结构（引擎自己的 MySQL MCP，拿到的真表回流平台）
-#    推断涉及哪些表（从 pack 命中里找表名），查真结构
-schema = cap.mcp.call("query_schema", {"table": "<表名>"})  # 引擎 qoder-mysql 工具
-# 查到后把真表结构回流平台（learn 写回，平台数据库知识就有了真实数据）
-if schema and schema.get("columns"):
-    cap.mcp.call("learn", {"project_id":"<项目UUID>", "category":"rule",
-        "pattern": f"数据库表<表名>结构: {json.dumps(schema.get('columns',[]), ensure_ascii=False)[:500]}",
-        "source": "wlkj/wl-prd+mysql"})
-# PRD 里的字段表优先用 query_schema 查到的真实列（最接地），其次用 context_pack 召回的代码字段
-```
-# 写 PRD 时参考 learnings 里的规则/偏好/决策，在相关章节体现
-```
-等价 CLI（脚本兜底）：
-```bash
-# ★ 有 REQ-ID 用 ctx-cache：PRD→spec→code 链路同 REQ 复用上下文（T1.3，省 2 次往返）
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" ctx-cache <REQ-ID> <业务词> --platform <web|app>
-# 无 REQ-ID / 首次取：普通 context
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" context <业务词> --platform <web|app>
-# PRD/spec 改动后失效该 REQ 缓存重来：
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" ctx-cache <REQ-ID> --clear
-```
-- 第 4 段 = 历史 PRD（防重复）
-- 第 5 段 = 相关 API
-- 第 8 段 = 数据库表结构+真实字段
-- 涉及枚举字段时额外调 `cap.mcp.call("query_distinct")`
-
-### 🎯 接地铁律（写 PRD 必须遵守）
-
-**用 rag_search 召回的知识写 PRD，每条功能/字段都要有 rag_search 命中的来源，不编造。**
-- PRD 里写的每个字段名 → 必须在 rag_search/context_360 结果里能找到（或来自 query_schema 真实表结构）
-- PRD 里写的每个 API → 必须在召回结果里有对应端点
-- 召回不到的字段/API → 标注"新增（待评估）"，不要假装已存在
-- 业务流程描述 → 优先采纳 ask_corpus 的 GraphRAG 回答（有全局视角），再用 rag_search 的事实补充
-
-### 产出
-- PRD: `workspace/members/{dev}/drafts/REQ-{YYYY}-{NNN}-{标题}.md`（13 章）
-- 原型（**可选**，见下「原型要不要画」）: `workspace/members/{dev}/drafts/prototype-{feature}.html`
-- 第一行必须带 `@contract` 头（platform/req-id/mode/acceptance/prototype）
-
-### 原型要不要画？（融入批量确认）
-
-**默认建议**（用户可一键改）：
-- 纯规则/接口/定时/参数/计算类 → **不画**（如"出交车点检固定为总部全局规则"）
-- 含页面/菜单/表单/弹窗/详情/向导/看板/大屏 → **画**
-- 加字段/按钮/文案/导出 → **不画**
-- 混合（页面+规则）→ 只画页面那部分
-
-**两端都画时**：默认只画主端一份，用户明确要求才画 2 份。
-
-**不画时**：PRD 第 11 章写 `无（{原因}，经用户确认豁免）` + `@contract` 头标 `prototype: none`；
-eval 自动跳过 A2（满分从 100 降到 70，照样 PASS）；`/wl-design` `/wl-code` 据此跳过原型环节。
-
-### 质量门禁
-```bash
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" eval <prd.md> [原型.html]
-```
-≥ 80% 才 PASS。完整模板见 `.qoder/templates/prd-full-template.md`。
-
-### 业务保真打分（接真命令产物 · BF1/BF2）
-
-> EVA 结构分(章齐)≠业务保真。PRD 出来后打业务保真分：产物是不是真 ICS 业务（真表/真写法）。
-```python
-from capability import resolve
-cap = resolve()
-# BF1 schema保真(提的表是真 ICS 业务表) + BF2 内容保真(LLM-judge vs 真 PRD, 是不是 ICS 写法非通用文)
-r = cap.mcp.call("bf_score", {"kind": "prd", "content": "<PRD 正文>", "feature": "<业务主题如 保险>"})
-# → BF1_schema.score(目标≥0.85) + BF2_content.score(目标≥4/5)
-```
-- BF1 低 → PRD 提了编造/非 ICS 表 → 补真表（query_schema/db_tables）。
-- BF2 低 → 内容是通用产品文非 ICS 写法 → 参考 rag_search(kind=prd) 真 PRD 范本重写。
-- 原型保真（BF3 组件/BF4 颜色）：`cap.mcp.call("bf_score", {"kind":"proto","content":"<原型 HTML>"})` → 用真 fywl-ui 设计系统核。
-
----
-
-## 快速模式（6 章 Mini-PRD）
-
-**加字段/加按钮/改文案/加导出等零星需求专用。** 极速，不走 EVA。
-
-> **宿主 sub-agent 激活**：QoderWork 支持 sub-agent 时，dispatch 到 **`prd-quick`** agent（`.qoder/agents/prd-quick.md`）——3 步极速（取上下文→生成 PRD+原型→一句话确认），≤5 轮工具调用，跳过 EVA。dispatch prompt 传 platform + 需求 + 开发者名。不支持则按下文手动流程。
-
-**平台必问**（同上）。
-
-### 取上下文（RAG 语义预取，禁止串行 search）
-
-**优先 rag_search（语义召回最全）+ prefetch，不要只靠逐个 search_code 关键词。**
-
-```python
-from capability import resolve
-cap = resolve()
-# ① rag_search 一次语义召回：代码/字段/API/Wiki 全拿到（按相关度排序）
-rag = cap.mcp.call("rag_search", {"query": "<需求描述>", "top_k": 8})
-```
-等价 CLI：
-```bash
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" prefetch "<需求描述>" --platform <p>
-```
-prefetch/rag_search 一次返回代码/字段/API/Wiki/历史 PRD。**之后不要逐个 search/find/grep 查词**（会变 6+ 次串行往返，轮次爆炸根因）。不够才补调一次。
-
-**接地铁律（同完整模式）**：6 章里写的每个字段/API 必须在 rag_search 召回结果里有来源，召不到的标"新增（待评估）"，不编造。
-
-### 产出
-- Mini-PRD: `workspace/members/{dev}/drafts/REQ-{YYYY}-{NNN}-{标题}.md`（6 章）
-- **6 章缺一不可（铁律）**：功能入口 / 需求背景 / 需求说明 / 影响范围 / 验收标准 / 不在本次范围
-  > 🚫 **禁止只写 1-2 章就交差**（真实反面教材：海外考勤 PRD 只写了"功能入口"一段就停，6 章缺 5 章 → 残废品）。
-  > 即使是 bug 修复，也要写全 6 章（需求背景=bug 现象、需求说明=修复方案、验收标准=修复后行为）。
-  > 不涉及的章节写"不涉及"或一句话说明，**标题必须保留，不许整章省略**。Stop hook 会检测缺章并阻断。
-- 模板见 `.qoder/templates/prd-quick-template.md`
-
----
-
-## 评审模式（7 项 checklist + EVA）
-
-**检查 PRD 完整性与质量。**
-
-### 流程
-1. 不给文件 → 列出最近的 PRD 让用户选
-2. 7 项 checklist 评审（★ 宿主支持 Agent 并行时，派 7 个 subagent 各审一项并发跑，合并 ✓/✗；不支持则串行逐项）：
-   - 验收标准是否可测
-   - 字段是否引用了真实数据库字段
-   - 影响范围是否评估
-   - 非功能性需求是否覆盖
-   - 接口/异常是否与现有系统自洽
-   - 是否有重复造轮子（查 req_trace / search_prd）
-   - 原型与 PRD 是否一致
-3. 跑 EVA 评分：`$PY "$R/.qoder/scripts/orchestration/wlkj.py" eval <prd.md>`（wlkj.py eval 内部映射 validation/metrics/eval_prd.py）
-4. 输出：总分 + 7 项 ✓/✗ + 改进建议
-
----
-
-## 埋点
-
-PRD 生成/评审后自动记录到 learning（eval_prd.py 已内置）。
-
-**评审模式额外**：给出 PASS/FAIL 结论后立即记一条 `review_done`（可用性指标 F2 评审级数据唯一来源，不埋则该级永远为 0）：
-```bash
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" learn record review_done "{\"prd\": \"<被评审PRD名>\", \"verdict\": \"PASS|FAIL\"}"
-```
-埋点失败不阻塞，但能埋一定要埋。
-
----
-
-## 📤 发禅道（PRD 写完后的衔接，完整/快速档都问）
-
-PRD 产出后，**主动问一句**（不要默默结束）：
-```
-PRD 已写好: <路径>
-要发到禅道吗？(发禅道 = 建禅道需求 + 可选关联计划/版本)
-```
-
-### 用户说"发" → 交互式逐项确认（不要一次性全问，按需）
-
-用禅道 MCP 现查现选（QoderWork: `qw_mcp_call`）：
-
-**① 选产品（必选）**
-- `list_products()` → 列出现有产品 → 让用户选 product_id
-- 禅道需求必须挂产品，没产品发不了
-
-**② 关联计划？（可选，问一句）**
-```
-要关联到计划(迭代)吗？(可跳过)
-```
-- 用户要 → `list_plans(product_id=<上一步选的>)` → 选 plan_id
-- 跳过 → 不传 plan
-
-**③ 挂版本？（可选，问一句）**
-```
-要纳入某个版本(build)吗？(可跳过)
-```
-- 用户要 → `list_builds(project_id=N)` → 选 build_id（⚠️ builds 按项目维度查最常见，禅道无"全量版本"端点）
-- 跳过 → 不传 build
-
-**④ 执行发布**
-```bash
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" req <REQ-ID> 发布 \
-    --product=<①> [--plan=<②>] [--build=<③>] --confirm
-```
-- 默认先 dry-run 预览，用户确认后再 `--confirm` 真发
-- 真发后禅道建好需求，PRD 末尾自动回写 `<!-- zentao: story=ID -->` 留痕
-
-> **禅道 story ID 回流平台**：建完禅道需求后，把 story ID 通过平台 MCP learn 工具写回：
-> ```python
-> cap.mcp.call("learn", {"project_id":"<项目UUID>","category":"decision",
->     "pattern": f"PRD<{标题}> 已发禅道: story=#{story_id} product={product_id}",
->     "source": "wlkj/wl-prd+zentao"})
-> ```
-> 这样平台知道这个 PRD 对应禅道哪个需求（跨系统关联）。
-
-> 用户说"不发" → 不勉强，PRD 留本地，后续可随时 `/wl-req <REQ-ID> 发布`。
-> 直连禅道 HTTP（脚本内部），AI 只触发一次，几乎不耗 token。
-
----
-
-## 🔄 回流平台（PRD 写完即执行，别漏）
-
-**铁律：PRD 落地后必须回流平台**（否则平台 AI回流 Tab 永远空，知识层↔引擎断裂）。
-回流走平台 MCP 写工具（`create_prd` / `submit_return`），失败不影响主流程。
-
-PRD 写完后跑这一条（用前面定的 `$PY` / `$R` 变量）：
-```bash
-$PY "$R/.qoder/scripts/orchestration/wlkj.py" return prd <PRD文件路径> "<PRD标题>" --platform <web|app>
-```
-- 内部优先调 `cap.mcp.call("create_prd", {title, content_md})` 写 PRD 表 + 首版本；
-- 失败再 `submit_return` 写 returns 待审核；最后 HTTP 兜底（读 mcp_config.json 的 return_endpoint）。
-- 全程 try/except，回流失败 PRD 仍在本地，主流程不阻塞。
-
-> 等价的 MCP 直调写法（脚本不可用时的兜底）：
-> `cap.mcp.call("create_prd", {"title": "<标题>", "content_md": "<完整PRD正文>", "status": "planning"})`
-> 或 `cap.mcp.call("submit_return", {"title":"...", "return_type":"prd", "source":"/wl-prd", "content_preview":"...", "content_full":"..."})`
-
-回流成功后输出一行：`✅ [回流] via=create_prd/submit_return <message>`。
-
-## 🧠 学习沉淀（PRD 写完即执行，反哺下次）
-
-**铁律：写 PRD 过程中学到的业务规则/决策/用户偏好，必须调 `learn` 写回平台**（平台 learning_patterns 积累，下次引擎受益——越用越聪明）。
-
-写完 PRD 后，把学到的关键认知调 learn 写回：
-```python
-cap.mcp.call("learn", {
-    "project_id": "<项目UUID>",
-    "category": "rule",          # rule=业务规则 / preference=用户偏好 / decision=决策 / pitfall=踩坑
-    "pattern": "<学到的内容，如：车辆保养需关联驾驶员和车辆，按里程+时间双触发>",
-    "source": "wlkj/wl-prd",
-})
-```
-- 每次至少写 1 条（最关键的业务规则或决策）。
-- 多条可多次调用。
-- 全程 try/except，失败不阻塞主流程。
-
-输出：`✅ [学习] 沉淀 N 条认知到平台`。
-
-## 📊 工作流轨迹回写（若本次是被平台触发的）
-
-如果本次 /wl-prd 是平台 trigger 派来的（有 triggerId），执行完后回填轨迹：
-```python
-# 通过 PATCH /api/projects/{pid}/trigger/workflow/{triggerId} 回填
-# body: {status: "success", output_summary: "生成了<标题>PRD", knowledge_used: [...], mcp_tools_called: [...], duration_sec: N}
-```
-- knowledge_used：rag_search/search 命中的关键实体 id 列表
-- mcp_tools_called：本次调过的 MCP 工具名（rag_search/context_360/create_prd/learn 等）
-- 让平台"引擎活动看板"能看到本次执行全貌（取了什么知识→产出什么→学了什么）
-- try/except 不阻塞。
-
-## 下一步
-- PRD 定稿 → `/wl-task create <标题>` 落成任务（带 REQ-ID 衔接）+ 发禅道
-- 开工前 → `/wl-spec` 生成开发 Spec → 确认后 `/wl-code` 实现
-- 完整链：prd → task → spec → code → test → commit → task finish（双通飞轮）
+---
+name: wl-prd
+description: "需求: 完整(13章,新功能) / 快速(6章,小改动) / 评审(检查质量)。默认根据描述自动判断。"
+argument-hint: "[完整|快速|评审] [需求描述]"
+auto-approve: true
+allowed-tools: [Read, Glob, Grep, Bash, Write, Edit]
+---
+
+# /wl-prd - 需求工序站
+
+User input: $ARGUMENTS
+
+## 🚨 铁律：MCP工具优先，禁止跑本地脚本
+
+**所有知识查询走 MCP 工具（云平台），绝不跑 wlkj.py kg/context 等本地脚本。**
+本地 kg.duckdb 是空的（共识：全走平台）。跑本地脚本 = 空结果 = 浪费时间。
+
+**直接用这些 MCP 工具（工具名必须和下表完全一致）：**
+
+| 要什么 | 工具名 | 参数 |
+|---|---|---|
+| 全上下文(代码+API+字段+PRD) | context_pack | {keyword, platform} |
+| 代码搜索 | search_code | {keyword, platform} |
+| 语义检索(业务流程/概念) | rag_search | {query, top_k} |
+| 全局业务流程问答 | graphrag_ask | {q, top_k} |
+| 影响分析 | get_impact | {entity, depth} |
+| 功能画像 | feature_profile | {feature} |
+| 表字段搜索 | search_field | {field} |
+| 真表结构 | schema_link | {concept} |
+| 设计系统 | get_design_system | {platform} |
+| 需求串联 | aggregate_requirement | {req_key} |
+
+> QoderWork: `mcp__qoder-knowledge-graph__<工具名>` 参数用JSON
+> Qoder IDE: `cap.mcp.call("<工具名>", {参数})`
+
+## 模式判断
+- "调整/修改/加个/改为/配置" → 快速档(6章)
+- "新功能/新模块/新流程" → 完整档(13章)
+- 用户说了APP/Web → 不用问平台；没说→问一次
+
+---
+
+## 快速档（3步出PRD）
+
+### Step 1: 取上下文（1次context_pack）
+
+调 context_pack：{keyword: "<需求核心词>", platform: "<app|web>"}
+返回空时补 search_code 一次（换关键词）。
+
+### Step 2: 写6章PRD
+
+## 1. 需求背景
+## 2. 功能说明（改动点+现状对比）
+## 3. 数据/字段（真表真列，来自context_pack/search_field）
+## 4. 验收标准（3-5条可测条件）
+## 5. 影响范围
+## 6. 不在本次范围
+
+### Step 3: 回流（可选）
+submit_return 或 Write 写文件。
+
+---
+
+## 完整档（13章PRD）
+
+### Step 1: 取上下文（并行，不要串行）
+1. context_pack — 代码+API+字段+PRD
+2. semantic_search — 业务流程
+3. search_field — 真实表结构
+
+### Step 2: Planning（先拆章再写）
+13章拆计划（每章要点+引用哪条MCP知识），列完再写。
+
+### Step 3: 逐章写
+背景与目标/用户故事/功能范围/业务流程/功能入口与交互/数据表与字段/接口定义/非功能性需求/影响范围/风险与依赖/验收标准/里程碑/附录
+
+### Step 4: 回流
+submit_return + Write。
+
+---
+
+## 🚨 接地铁律（所有模式必须遵守）
+
+1. **溯源**：引用符号/表名/接口用真实原名（CostApplyController/base_asset），非中文描述
+2. **禁编**：不编造未在召回里出现的类名/表名/字段；召回不足标"待确认"
+3. **接地**：涉及数据表时先调search_field取真表；未召回禁编表名
+4. **完整**：产物详尽展开，不一行带过