SKILL.md 全文

Frontmatter

name	noah-p1-requirements_1.0.7
description	|

P1 · 需求分析与 PRD（P-Pipeline 节点一）

版本 v1.0.7（2026-07-16）。本版修复合并后相对 D1/D2 的能力回归（洪奎团队反馈）：①移植 D1/D2 生成脚本到 scripts/（HTML 带目录导航+蓝色标题、Word 正式稿，见 references/output-toolchain.md）；②PRD 章节补齐到 D2 十章口径（术语/范围/业务规则决策表/计算逻辑+≥3示例/风险管理/灰度验收/附录，全部[强制]）；③异常补偿时序图不可省；④重建 PRD↔原型联动（第6章嵌原型截图+三表、F 编号互引、本次页面调整说明）；⑤加回反面示例 + 生成后自检强制力；⑥功能清单标题限长。

v1.0.5/1.0.6 保留：2 节点结构（本节点=需求/PRD）；整合 D 线需求段（五模式/金融域规则/领域基线/FIN-001~006/DoR/变更回流）；全系统覆盖；知识库引用骨架；模板固化；分层目录工程化。

P 线核心目标 = 高质量需求；一切以需求质量与首次采纳率为准。后续迭代请递增版本号。

---

强制读取清单（三层加载 · 执行到对应步骤前必须先读取该文件）

本 SKILL.md 只写核心流程与红线摘要；细则在 references，用到才读，禁止凭记忆输出。

| 步骤 / 场景 | 必读文件 | |---|---| | 全程（红线）| references/execution-redlines.md（禁编造/专名锁定/问题闭环/BR→F/TBD） | | 模式判定（A金融/B轻量/C通用/D变更/E评审）| references/prd-modes.md | | 业务域基线加载（识别系统/术语）| references/systems-baseline.md、references/business-glossary.md | | 增量/非 0→1 需求 | references/knowledge-base-ref.md（知识库索引与引用规则） | | 体验与深度挖掘（尤其中后台/后端）| references/deep-probing.md | | 产出 BRD（业务侧材料/会议纪要）| references/brd-spec.md | | 产出 PRD | references/prd-spec.md + assets/prd-template.md | | 生成 HTML/Word（导航+蓝标题/正式稿）| references/output-toolchain.md + scripts/（prd/brd 生成器、md_to_html、html_to_docx）| | 金融核心域（账户/资金/交易/清算）| references/fin-domain-rules.md + references/fin-static-rules/（FIN-001~006）+ references/finance-compliance.md | | 团队自有模板 | assets/team-templates.md |

---

一、这个节点做什么

接收任何形式的原始需求输入，通过结构化对话，先产出结构化需求（供业务确认），再产出可交付开发的 PRD。

• 中间产物：场景说明 · 体验要求 · 功能清单（业务确认用）；材料驱动/复杂需求可先出 BRD（业务侧，见 references/brd-spec.md）
• 核心交付物：PRD（向下游 D 线开发交付；P2 输出 → D1 开发，PRD 须能直接对接开发评审）
• 原型/Demo 不在本节点，交 noah-p2-prototype-demo。

一·B、模式与领域能力（整合 D 线 D1/D2）

收到需求后先判定模式（含明确关键词直接进入，否则给菜单让用户选）——详见 references/prd-modes.md：

| 模式 | 适用 | |---|---| | A 金融 PRD | 账户/资金/交易/清算/合规核心域（注入 fin-domain-rules + FIN-001~006 + Trust Tier）| | B 轻量 Spec | 小改/参数/缺陷（Spec-Lite 直达开发，护栏不降级）| | C 通用 PRD | 内部工具/非金融/数据/AI 产品 | | D 变更回流 | 已有 BRD/PRD 增量修改（L1/L2/L3 分级，见 brd-spec §六）| | E 评审 DoR | 评审既有 PRD 就绪度（五维评分 + DoR 门禁）|

• 业务侧材料 → BRD：会议纪要/口述/邮件先梳理成 10 章 BRD（references/brd-spec.md），再进 PRD；简单/对客小需求可跳过 BRD。
• 业务域基线：模式 A/C 前置强制读 systems-baseline.md + business-glossary.md 识别系统与术语；增量需求叠加 knowledge-base-ref.md 检索。
• 金融护栏：金融核心域强制注入 fin-domain-rules.md（金融触点→章节映射）+ fin-static-rules/（禁浮点/分布式锁/幂等/超时/禁硬编码/服务端校验）+ 金融强审查维度（见 finance-compliance.md）。

---

二、执行流程

Step 0 · 定位（场景类型 + 需求类型）

判断不了主动问（一次最多 2 个）。

场景类型（决定输出侧重与规范来源）：对客 ToC / 中后台管理 / 对内职能 / 后端·纯逻辑无界面。 需求类型：0→1 新建 / 增量迭代。

中后台/后端场景的追问重点与规范占位见 references/deep-probing.md；对客 UI 侧重在节点二。

Step 1 · 接收输入 + 上下文加载

• 全部接收输入；判断"谁在用 / 什么场景 / 核心诉求 / 有无参考"。
• 若为增量/非 0→1：先走 references/knowledge-base-ref.md——识别涉及的系统 → 检索知识库索引 → 加载命中片段；知识库未覆盖或缺失的，逐项列「上下文欠账」清单并提示补充，用户拿不到的标 [上下文缺失：xxx] 并说明对准确度的影响。

Step 2 · 场景说明

用户故事（作为 X，我希望 Y，以便 Z）+ 3–5 步核心用户旅程（文字）。

Step 3 · 体验/规则要求 + 深度挖掘

按场景类型调整；主动挖掘隐性需求（时序/条件联动、隐私脱敏、排序分组、跨系统调用、当期 vs 后置等）。详见 references/deep-probing.md。金融场景见 references/finance-compliance.md。

Step 4 · 功能清单（BR→F 单一信源）

每条：[P0/P1/P2] F-xx 功能名 — 描述（触发条件/边界）｜来源：BR-xx。P0 建议 5–8 条，>10 条主动提醒。P1 是 F 编号与角色定义的唯一信源。

标题限长：功能名 ≤ 16 字，长描述放"描述"列，避免清单标题过长不易阅读。

Step 5 · 功能清单业务确认（Gate）

功能清单必须先经业务方确认，再进入 PRD 产出/节点二。

Step 6 · 产出 PRD（本节点核心交付）

按 references/prd-spec.md 产出十章 + 附录。强制：

• 分步产出（先框架→确认模块顺序与依赖→逐模块生成）；
• 系统实现深度不可省：业务规则决策表、计算逻辑+≥3 示例（涉金额）、字段+接口清单、异常补偿时序图、风险管理章、术语、范围；
• PRD↔原型联动：第 6 章嵌入 P2 原型截图 + 字段/筛选/按钮三表，功能表带"对应原型页面"列，F 编号互引；迭代需求写"本次页面调整说明"；
• 输出前生成 Gate 自检表（prd-spec 第五节，逐项标 已完成/部分/未完成）；
• 生成 HTML/Word：用 scripts/（见 references/output-toolchain.md），HTML 带目录导航 + 蓝色标题。

模板见 assets/prd-template.md；有团队模板时用 assets/team-templates.md 注入。

Step 6.1 · 反面示例（生成前比对，命中即回退）

| 违规 | 正确 | |---|---| | 功能只写罗列、无系统实现方案/字段/接口 | 每模块写到开发可对接（决策表+计算示例+字段+接口）| | 涉金额但无计算公式与示例 | 必给公式 + step-by-step + ≥3 示例 | | 只有正常流程时序图 | 补异常补偿（超时/失败/回滚）时序图 | | 无风险管理章、无术语、无范围 | 十章齐全，条件章非空 | | PRD 与原型各自为政 | 第6章嵌原型截图+三表、F 编号互引 | | 直接手写 HTML 或无导航/蓝标题 | 用 scripts 生成，带目录导航+蓝色标题 |

可裁剪：纯逻辑/无界面需求 → Step 0–1 + 直接产 PRD，跳过原型/Demo（不进节点二）。P 线是循环：产出后与业务确认 → 收集问题 → 再跑（简单 2 轮，复杂 3–4 轮）。

---

三、执行红线（摘要 · 全文见 references/execution-redlines.md）

• R1 禁编造/幻觉：只分析输入出现过的角色/功能/分支；有判断空间的规则标 [TBD] 交人确认；输入已写明的条件不得遗漏。
• R2 专名锁定：渠道名/系统名/产品名/规则命名保持原文，不规范化改写。
• R3 问题闭环清单：每个追问记录状态（已确认/部分确认/待确认/暂不做/超出范围），输出前逐项闭环。
• R4 BR→F 单一信源：功能标业务来源 BR-xx，无来源不通过；F 编号全局唯一，P1 为信源。
• R5 TBD 纪律：仅真有未决才输出，禁凑数。

---

四、Gate（本节点完成标准）

• [ ] 场景类型与需求类型已确认
• [ ] 增量需求已走知识库检索或已标上下文欠账
• [ ] 用户旅程核心路径已描述；P0 功能已识别
• [ ] 功能清单已经业务方确认（R4：均有 F 编号 + BR 来源）
• [ ] 无编造、专名保持原文（R1/R2）；问题闭环清单无悬空（R3）
• [ ] PRD 已产出且通过 Gate 自检表：十章齐全（术语/范围/业务规则/风险管理/灰度）+ 计算逻辑≥3示例（涉金额）+ 端到端&异常补偿时序图 + 字段/接口 + 金融审查维度（见 prd-spec）
• [ ] PRD↔原型联动：第6章嵌原型截图+三表、F 编号互引、迭代含页面调整说明
• [ ] 已生成 HTML（目录导航+蓝色标题）/ Word（如需）；功能标题 ≤16 字
• [ ] 未解决 TBD ≤ 3 条且均为真实未决
• [ ] 金融合规场景已标注对应要求