@chantezy/mcp-product-design 0.1.11 → 0.1.13

package/README.md

@@ -11,6 +11,7 @@
 | `interaction-design-eval` | 交互设计量化评估与职级匹配 |
 | `interaction-spec` | 交互说明文档生成 |
 | `prd-generator` | PRD 需求文档生成 |
+| `prd-lint` | PRD 逻辑评审与跨文档冲突检测 |
 
 ## MCP 工具
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chantezy/mcp-product-design",
-  "version": "0.1.11",
+  "version": "0.1.13",
   "description": "Product design skills MCP server - structured design workflow tools for AI agents",
   "type": "module",
   "main": "./dist/index.js",

package/skills/interaction-design-eval/README.md

@@ -4,10 +4,18 @@
 
 ## 适用场景
 
-- 上传设计方案文档、原型说明、PRD 交互部分，进行专业评审打分
+- 上传设计方案文档、交互方案说明、原型流程说明，进行专业评审打分
 - 设计师职级评估、成长值评估、能力匹配度盘点
 - 团队内设计方案横向对比
 
+## 不适用场景（改用 prd-lint）
+
+- 检查 PRD / 需求文档的逻辑是否自洽、流程是否有断点
+- 排查文档内的规则冲突，或与线上需求库的跨文档冲突
+- 只要「问题清单 + 严重度分级」、明确不要分数
+
+判别锚点是**输出形态**：要分数、评分表、成长值 → 本 skill；只要问题清单和严重度 → prd-lint。两个 skill 都会输出问题清单，这是最容易混淆的地方，靠「是否产出分数」区分。
+
 ## 评估体系
 
 ### 10 大评估维度

package/skills/interaction-design-eval/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: interaction-design-eval
-description: 对交互设计/产品方案文档进行专业、量化的评审打分,同时评估方案及设计师本人的职级岗位匹配度。当用户上传设计方案文档、原型说明、PRD交互部分,并要求"评估"、"打分"、"测评"、"评审"该方案时,必须使用本skill。即使用户只说"帮我看看这个方案怎么样"或"这个设计有没有问题",只要附带的是交互/产品设计类文档,也应触发本skill,而不是给出泛泛的主观评价。也适用于"职级评估""成长值评估""能力匹配度"相关的设计师能力盘点场景。输出固定为10维度评分表+职级评估分(成长值)+逐维度问题清单+原文引用+优化建议。
-trigger: 当用户需要评估/打分/评审交互设计方案、测评设计质量、或做设计师职级能力盘点时使用
+description: 对交互设计方案文档做量化的质量评分，并同步评估设计师本人的职级与成长值匹配度。当用户要求给设计方案打分、量化测评设计质量、问「这个方案能打几分」，或对某位设计师做职级评估、成长值评估、能力盘点时使用。典型输入是交互方案说明、设计稿标注、原型流程说明等交互/产品设计类文档；输出固定为 10 维度评分表（5 分制 × 权重）＋职级成长值比例＋逐维度问题清单＋原文引用＋优化建议。
+trigger: 当用户需要给交互设计方案打分、量化测评设计质量，或做设计师职级与成长值评估时使用
 ---
 
 # 交互设计方案专业评估
@@ -10,6 +10,8 @@ trigger: 当用户需要评估/打分/评审交互设计方案、测评设计质
 
 你是一位资深交互设计专家，需要对用户提供的设计方案文档进行专业评估。请从「上下文内容表达」出发进行打分，并给出具体、可执行的改进建议。评估须客观、精准、有依据，所有结论必须基于文档原文。
 
+> **边界**：本 skill 的产出是「分数」。若用户要的是 PRD 逻辑体检、规则冲突排查、跨文档比对，或只要问题清单不要分数，应改用 `prd-lint`——不要拿本 skill 的评分标准去评 PRD 的逻辑完备性。
+
 ## 二、输入素材
 
 用户提供的设计方案文档

package/skills/prd-lint/README.md

@@ -0,0 +1,110 @@
+# PRD Lint 逻辑评审 Skill
+
+检查 PRD 逻辑合理性与内部一致性，并对比线上需求库检测跨文档冲突。**只输出问题清单，不修改文档。**
+
+## 功能
+
+对一份 PRD 做「逻辑体检」，回答四个问题：
+
+- **对得上吗** — 功能方案是否真的解决了需求背景里提出的问题
+- **断了吗** — 流程、状态、分支是否完整，有没有没写完的地方
+- **打架吗** — 文档内部是否存在互相冲突的规则、数值或表述
+- **跟线上矛盾吗** — 与需求库中已有的线上功能规则是否冲突
+
+## 使用场景
+
+当用户请求以下内容时触发：
+
+- "帮我检查这个 PRD 逻辑有没有问题"
+- "这份需求有没有冲突的地方"
+- "功能跟需求背景对得上吗"
+- "新需求跟线上已有功能会不会打架"
+- "开发评审前帮我自查一下"
+- 任何 PRD 合理性校验、一致性核对的请求
+
+## 不适用场景（改用 interaction-design-eval）
+
+- 给交互设计方案打分、量化测评方案质量
+- 设计师职级评估、成长值评估、能力匹配度盘点
+
+本 skill 的输出里不会出现任何分数或评分表。如果用户要的是「这个方案能打几分」「评级多少」，请改用 interaction-design-eval。
+
+## 使用方法
+
+给出 PRD 的 4399doc 链接，或直接粘贴正文：
+
+```
+帮我 lint 一下这份 PRD：http://note.4399doc.com/prd?note_id=xxx&group_id=xxx
+```
+
+```
+检查这份需求有没有逻辑冲突（随后粘贴正文）
+```
+
+## 评估维度
+
+| 维度 | 内容 | 是否必查 |
+|---|---|---|
+| A 可追溯性 | 功能与需求背景的双向对应 | 必查 |
+| B 逻辑完整性 | 流程闭环、状态覆盖、分支穷尽、角色权限 | 必查 |
+| C 一致性 | 文档内部规则、术语、数值、口径冲突 | 必查 |
+| D 落地质量 | 验收标准、埋点、依赖项、非功能需求 | 附加项（文档未写则不评估） |
+| E 跨文档一致性 | 与线上需求库已有规则的冲突 | 默认执行 |
+
+## 目录结构
+
+```
+prd-lint/
+├── SKILL.md                        # 技能主文件
+├── references/
+│   ├── checklist.md                # A/B/C/D 四维完整检查清单
+│   ├── cross-doc-search.md         # E 维跨文档比对流程
+│   └── output-template.md          # 输出结构与示例
+└── README.md                       # 本文件
+```
+
+## 工作流程
+
+1. **获取文档** — 通过 4399doc 链接（note MCP）读取，或接收粘贴正文
+2. **结构化拆解** — 拆成问题、目标、功能、规则、状态五张清单
+3. **文档内校验** — 按 A / B / C / D 四个维度逐项对照 `references/checklist.md`
+4. **跨文档比对** — 检索线上需求库，按版本收敛出基准文档后逐条比对规则
+5. **输出清单** — 按维度分组，每条标注严重度、原文定位与依据来源
+
+## 严重度分级
+
+| 级别 | 含义 |
+|---|---|
+| 阻塞 | 会导致开发无法实现、按文档实现后与需求目标相悖，或与线上规则直接矛盾 |
+| 高风险 | 会导致返工、上线后出现用户可见问题，或不同人理解不一致 |
+| 建议 | 表达不清、粒度不足、可读性问题，不影响正确落地 |
+
+## 输出示例
+
+```
+# PRD Lint｜高级筛选与混合搜索
+
+检查项 34 项 · 发现问题 7 项（阻塞 2 / 高风险 3 / 建议 2）
+
+## C. 一致性
+### [阻塞] 筛选规则与搜索规则的命中优先级缺失
+
+- 位置：3.2 筛选逻辑 / 4.1 混合搜索
+- 问题：两处规则均可能作用于同一结果集，未定义二者同时生效时谁先执行
+- 建议：补充仲裁规则，或明确二者互斥
+
+## E. 跨文档一致性
+### [高风险] 筛选条件的多选能力与线上 [2.7.3] 版本相反
+
+- 依据：[2.7.3] 搜索页样式调整（更新于 2026-09-17）
+  http://note.4399doc.com/prd?note_id=2522a09e47b1a4d8701b208c&group_id=975189ff4d9aa1642cd7d1aa
+- 线上规则：云文档类型为多选且含「所有类型」
+- 新 PRD 规则：筛选条件为单选
+```
+
+## 设计要点
+
+- **D 维度为附加项** —— 验收标准、埋点、依赖项不一定每份文档都有，缺失时不视为问题
+- **E 维度取最新版本** —— 线上规则会持续迭代，按「标题版本号降序 → 更新时间降序」收敛基准文档
+- **依据必须可溯源** —— E 维度每条结论附文档标题、更新时间与链接；拿不到链接时只输出标题
+- **区分冲突与变更** —— 新 PRD 主动声明「变更 / 升级 / 替代」线上规则的不算冲突

package/skills/prd-lint/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: prd-lint
+description: 评审 PRD / 需求文档的逻辑合理性与内部一致性，并对比线上已有需求库检测跨文档规则冲突。当用户要求检查 PRD 是否合理、验证逻辑是否完整、找出需求或规则冲突、核对功能方案与需求背景是否对应、核对新需求与线上功能是否冲突，或做开发评审前的自查时使用。支持通过 4399doc 链接（note MCP）获取文档并检索需求库。输出为分维度问题清单与严重度分级（阻塞/高风险/建议），只定位问题，不打分、不评级。本 skill 只产出「问题＋严重度」，不产出任何分数。
+trigger: 当用户需要检查 PRD 逻辑是否合理、验证逻辑是否完整、排查需求或规则冲突、核对功能方案与需求背景是否对应、对比线上需求库检测跨文档冲突，或做开发评审前的自查时使用
+agent_created: true
+---
+
+# PRD Lint · 逻辑评审
+
+## 用途
+
+对一份 PRD 做「逻辑体检」，回答四个问题：
+
+1. **对得上吗** — 功能方案是否真的解决了需求背景里提出的问题
+2. **断了吗** — 流程、状态、分支是否完整，有没有没写完的地方
+3. **打架吗** — 文档内部是否存在互相冲突的规则、数值或表述
+4. **跟线上矛盾吗** — 与需求库中已有的线上功能规则是否存在冲突
+
+前三问在单份文档内部完成校验；第四问需要检索 4399doc 需求库做跨文档比对。
+
+## 何时使用
+
+- 用户给出 PRD 链接或正文，要求评审、检查、体检、找问题
+- 用户问「这个 PRD 逻辑有没有问题」「需求有没有冲突」「功能跟背景对得上吗」
+- 用户要求核对新需求与线上已有功能规则是否冲突
+- 开发评审、产品内部 review 前的预检自查
+
+不适用：撰写 PRD、改写 PRD、纯格式或错别字校对；给交互设计方案打分、量化测评方案质量、设计师职级或成长值评估也不适用，应改用 `interaction-design-eval`。本 skill 不产出任何分数。
+
+## 工作流
+
+### 第 1 步：获取文档
+
+首选从 4399doc 读取：
+
+- 调用 `mcp__note__fetch-note`，参数 `note_id` 为文档 ID；用户给的是链接时从 URL 中提取 ID
+- 只给了文档库 ID 时，先用 `mcp__note__list-notebook` 展开目录，再配合 `mcp__note__search-note` 定位目标文档
+
+若 MCP 不可用或读取失败，请用户直接粘贴正文。不要基于标题、目录名猜测文档内容。
+
+### 第 2 步：结构化拆解
+
+评审前先把文档拆成五张内部清单（不必全部输出）：
+
+| 清单 | 内容 | 编号 |
+|---|---|---|
+| 问题清单 | 背景 / 目标章节提到的用户问题、痛点 | P1、P2… |
+| 目标清单 | 期望达成的效果、指标 | G1、G2… |
+| 功能清单 | 所有功能点、方案描述 | F1、F2… |
+| 规则清单 | 业务规则、判定条件、优先级 | R1、R2… |
+| 状态与分支 | 界面状态、流程分支、异常路径 | S1、S2… |
+
+拆解质量决定评审质量。所有结论都必须能引用这些编号，避免输出泛泛而谈的判断。
+
+### 第 3 步：文档内校验（A / B / C / D）
+
+读取 `references/checklist.md`，按四个维度逐项校验：
+
+- **A 可追溯性、B 逻辑完整性、C 一致性——必查**
+- **D 落地质量——附加项**：仅当文档中已经写了相关内容时才校验其是否自洽。文档没有写验收标准、埋点、依赖项、非功能需求等，**不视为问题，不产出缺失类条目，也不提示补充**。
+
+### 第 4 步：跨文档比对（E 维度）
+
+读取 `references/cross-doc-search.md`，按其中流程检索线上需求库并做冲突检测。默认执行；用户明确要求跳过时（例如纯新增功能、无可对标文档）可省略。
+
+这一步的四条硬约束：
+
+- **时间必须最新** —— 线上功能规则会持续迭代，比对必须基于最新版本。同一功能存在多篇文档时，按「标题版本号降序 → 更新时间降序」收敛出基准文档
+- **依据必须可溯源** —— 每条结论附上依据文档的标题、更新时间、链接。链接取自 `search-note` 返回的 `detail_url`，或由 `note_id` + `group_id` 拼接；两者都拿不到时**只输出标题**，并提示用户自行在需求库检索
+- **检索不到就说明** —— 无相关文档时明确写「未检索到」，不用猜测填补，不拿无关文档凑数
+- **覆盖必须交代** —— 报告末尾输出「检索覆盖说明」，列出检索关键词、覆盖的文档库、命中文档数、收敛后的基准文档
+
+### 第 5 步：输出
+
+按 `references/output-template.md` 的格式输出分维度问题清单。核心要求：
+
+- 每条问题必须带**原文定位**（章节名或引用原句）；定位不到的不输出
+- 每条问题标注**严重度**：阻塞 / 高风险 / 建议
+- 「建议」字段要给出具体修改方向，禁止「建议完善」这类空话
+- 信息不足、存在多种合理解读的，放进「待确认」分区，只描述疑点，不判定为错误
+- 没有发现问题的维度写「未发现问题」，不得省略该维度
+
+## 严重度判定
+
+| 级别 | 判定标准 |
+|---|---|
+| 阻塞 | 会导致开发无法实现，或按文档实现后与需求目标相悖，或与线上规则直接矛盾 |
+| 高风险 | 会导致返工、上线后出现用户可见问题，或不同人理解不一致 |
+| 建议 | 表达不清、粒度不足、可读性问题，不影响正确落地 |
+
+## 约束
+
+- 只报告文档中**实际存在**的问题，不为凑数量制造条目；问题少不是缺陷
+- 跨文档结论必须标注依据来源与更新时间；无法溯源的不输出
+- 不评价需求的商业价值、优先级选择是否合理（除非文档内部自相矛盾）
+- 不重写 PRD，只定位问题并给出修改方向
+- 输出使用中文
+
+## 资源
+
+- `references/checklist.md` — A / B / C / D 四个维度的完整检查清单，含每项的判定方法与高频漏法。评审时逐项对照。
+- `references/cross-doc-search.md` — E 维度跨文档比对流程：关键词提取、文档库收敛、版本收敛规则、链接构造、冲突判定表。
+- `references/output-template.md` — 输出结构与单条问题写法，含严重度定义和示例。

package/skills/prd-lint/references/checklist.md

@@ -0,0 +1,223 @@
+# PRD 逻辑评审检查清单
+
+每个检查项包含：**检查什么** → **怎么判定** → **高频漏法**。
+
+A / B / C 三个维度必查。D 维度为附加项。
+
+---
+
+## A. 可追溯性（必查）
+
+核心问题是「功能方案是否真的对应需求背景里提出的问题」。必须**双向查**。
+
+### A1 正向映射：问题 → 功能
+
+- **检查**：问题清单（P\*）中的每一条，是否存在至少一个功能点（F\*）或规则（R\*）明确承接它
+- **判定**：找不到承接，按该问题是否为文档自述的核心目标，标「阻塞」或「高风险」
+- **高频漏法**：背景写了 3 个痛点，功能只覆盖 2 个；最后一句话带过的痛点没进功能清单
+
+### A2 反向反查：功能 → 问题
+
+- **检查**：功能清单（F\*）中的每一项，能否回答「它解决哪个 P\*」
+- **判定**：答不上来的功能，标「高风险」，问题描述为「无来源需求」
+- **高频漏法**：功能列表里突然出现的「顺便做一下」的能力
+
+### A3 目标与指标对应
+
+- **检查**：目标（G\*）是否对应到某个 P\*，且可量化、可判定
+- **判定**：不可量化的目标（如「提升使用体验」）标「建议」
+- **高频漏法**：目标章节与背景章节各说各话，二者无引用关系
+
+### A4 范围边界
+
+- **检查**：是否声明了本期不做什么
+- **判定**：没有范围声明时，仅在文档中出现了明显可能被误解为「已包含」的能力时才提示，不无条件要求补写
+
+### A5 优先级依据
+
+- **检查**：功能优先级是否来自目标或问题，而非只给 P0 / P1 标签而无理由
+- **判定**：无依据的优先级标记为「建议」
+
+---
+
+## B. 逻辑完整性（必查）
+
+核心问题是「流程、状态、分支有没有断点」。
+
+### B1 流程闭环
+
+- **检查**：主流程是否有明确起点、正常路径、结束态；是否存在只有入口没有出口的环节
+- **判定**：断点标「阻塞」
+
+### B2 状态覆盖
+
+- **检查**：每个界面或环节是否覆盖：首次空态、加载中、请求失败、无权限、超限（数量 / 长度 / 频率 / 额度）
+- **判定**：核心链路上的缺失标「高风险」，边缘状态标「建议」
+- **高频漏法**：只写主流程，不写空态与失败态——这是出现频率最高的漏法
+
+### B3 分支穷尽
+
+- **检查**：条件判断（if / else）是否闭合；是否存在「其余情况不处理」
+- **判定**：存在未覆盖分支且会影响结果时，标「高风险」
+
+### B4 操作可逆性
+
+- **检查**：删除、覆盖、退出等破坏性操作是否有二次确认或撤销；不可逆操作是否有说明
+- **判定**：不可逆且无确认，标「高风险」
+
+### B5 状态机穷尽
+
+- **检查**：若文档描述的对象存在多个状态，列出全部状态 + 迁移条件 + 触发方；检查有无未定义迁移
+- **判定**：未定义迁移会造成实现期歧义，标「阻塞」或「高风险」
+- **方法**：先列状态集合，再列迁移矩阵，空格即为缺口
+
+### B6 角色与权限
+
+- **检查**：每个角色在每处入口的可见范围与可执行操作是否都定义；越权路径是否说明
+- **判定**：缺失标「高风险」
+
+### B7 入口与端
+
+- **检查**：多端（Web / 移动 / 客户端）或多入口（列表页 / 搜索页 / 分享链接）是否都说明差异
+- **判定**：只描述一端而实现需要多端覆盖时，标「高风险」
+
+### B8 时序与并发
+
+- **检查**：存在先后依赖的操作是否说明顺序约束；并发编辑、重复提交如何处理
+- **判定**：缺失标「高风险」
+
+### B9 数据流向
+
+- **检查**：数据的来源、存储位置、消费方是否说明；展示值是否说明从何计算
+- **判定**：缺失标「建议」，仅在影响正确性时升级
+
+---
+
+## C. 一致性（必查）
+
+核心问题是「文档内部有没有互相打架」。冲突必须拆成下面几种分别查，否则会漏。
+
+### C1 功能间结果一致
+
+- **检查**：同一操作在不同功能、不同入口下的结果是否一致
+- **判定**：不一致标「阻塞」——它意味着实现时必须二选一
+- **方法**：找出所有会改变同一对象状态的入口，横向比对
+
+### C2 术语统一
+
+- **检查**：构建术语表——同一概念是否出现多个名称（一物多名）；同一名称是否有多种含义（一名多义）
+- **判定**：标「高风险」，术语混乱会直接导致开发理解偏差
+- **方法**：抽取文档中所有名词性关键词（功能名、字段名、对象名、状态名），两两比对
+
+### C3 规则冲突与仲裁
+
+- **检查**：规则清单（R\*）两两比对——是否存在条件重叠但结论不同的规则对；多条规则同时命中时谁优先是否明确
+- **判定**：**冲突且无优先级说明 = 最严重的漏点，标「阻塞」**
+- **说明**：这是出现频率最高的漏点，务必逐对检查，不要抽样
+
+### C4 数值一致性
+
+- **检查**：所有限制值（数量上限、字符长度、时效、超时、分页大小、默认值）在不同章节出现时是否一致
+- **判定**：不一致标「高风险」
+- **方法**：全文提取所有数字 + 单位 + 所在章节，分组比对
+
+### C5 数据口径
+
+- **检查**：单位、时区、精度、统计范围（是否含某类数据）、计算时点是否统一
+- **判定**：不一致标「高风险」
+
+### C6 文案与反馈一致
+
+- **检查**：同一状态在不同模块的提示文案、状态色、交互反馈是否一致
+- **判定**：标「建议」
+
+### C7 背景与方案自洽
+
+- **检查**：背景章节的描述与功能方案章节是否互相矛盾
+- **判定**：标「高风险」或「阻塞」
+- **示例**：背景写「用户不会使用复杂筛选」，方案却引入多层嵌套条件
+
+---
+
+## D. 落地质量（附加项）
+
+> **缺失不报。** 仅当文档已经写了这类内容时，才检查其是否自洽。文档未写验收标准、埋点、依赖项、非功能需求，不产出任何条目。
+
+### D1 验收标准可判定
+
+- **检查**：已写出的验收标准是否可测、可判定（有明确的通过条件）
+- **判定**：写了但不可判定，标「建议」
+
+### D2 分期与优先级
+
+- **检查**：已给出的 MVP / 后续划分是否与功能清单一致（有无功能既未进 MVP 也未进后续）
+- **判定**：不一致标「高风险」
+
+### D3 埋点与数据
+
+- **检查**：已定义的埋点事件、属性是否覆盖文档自述的目标指标（G\*）；口径是否与 C5 一致
+- **判定**：覆盖缺口标「建议」
+
+### D4 依赖项
+
+- **检查**：已列出的依赖（上游数据、其他团队、第三方能力）是否与功能描述匹配；有无功能依赖了未列出的能力
+- **判定**：标「高风险」
+
+### D5 非功能需求
+
+- **检查**：已写出的性能、兼容性、安全要求是否与功能描述冲突
+- **判定**：冲突标「高风险」
+
+---
+
+## E. 跨文档一致性（默认执行）
+
+> 详细检索流程见 `references/cross-doc-search.md`。本节只列检查项。
+
+核心问题是「新 PRD 的规则跟线上已有功能是否矛盾」。必须基于**最新版本**的线上文档判定，每条结论附依据文档的标题、更新时间与链接。
+
+### E1 规则结论冲突
+
+- **检查**：新 PRD 的规则与线上最新文档的规则结论是否相反
+- **判定**：**结论不同且新 PRD 未说明这是变更，标「阻塞」**
+- **说明**：新 PRD 主动声明「变更 / 升级 / 替代」线上规则的不算冲突，按 A 维度正常覆盖处理
+
+### E2 同一操作结果不一致
+
+- **检查**：同一操作在线上文档与新 PRD 中的结果（跳转去向、状态变化、提示文案）是否一致
+- **判定**：不一致标「阻塞」
+
+### E3 规则沿用未说明
+
+- **检查**：线上已有规则，新 PRD 涉及同一模块但未说明是沿用还是修改
+- **判定**：标「高风险」——开发无法判断是否要保留原逻辑
+
+### E4 命名与字段不一致
+
+- **检查**：新 PRD 使用的字段名、功能名与线上文档是否一致
+- **判定**：标「高风险」——容易导致开发理解为两个不同对象
+
+### E5 限制值不一致
+
+- **检查**：数量上限、字符长度、时效、默认值等与线上文档是否一致
+- **判定**：不一致且未说明，标「高风险」
+
+### E6 引用的线上规则已变更
+
+- **检查**：新 PRD 引用或依赖的线上规则，其最新版本是否已经发生变化
+- **判定**：标「高风险」——引用过期规则会导致实现与现网不符
+
+### E7 线上文档自身存在多版本矛盾
+
+- **检查**：同一功能的线上文档内部描述前后矛盾；或同功能多份文档结论不同
+- **判定**：标「高风险」，在报告中列出全部候选文档供用户判断
+
+---
+
+## 无法判断的情形
+
+以下情形归入「待确认」分区，**不判定为错误**：
+
+- 文档引用但未展开的外部规范、设计稿、接口文档
+- 一句话概述但明显由独立文档承载的模块
+- 表述存在多种合理解读，且无法从上下文排除

package/skills/prd-lint/references/cross-doc-search.md

@@ -0,0 +1,145 @@
+# 跨文档比对：线上需求库检索与冲突检测
+
+用于 E 维度。目标是把待评审 PRD 的功能规则，跟**线上已有需求文档**里的规则做比对，找出跨文档冲突。
+
+## 核心原则
+
+1. **时间必须最新** —— 线上功能规则会持续迭代，比对必须基于最新版本。任何结论都要标注所依据文档的更新时间。
+2. **链接必须给全** —— 每条结论都附上依据文档的标题和链接；拿不到链接时只写标题，并提示用户自行查看。
+3. **宁缺毋滥** —— 检索不到相关文档时明确写「未检索到」，不要用猜测填补，也不要拿无关文档凑数。
+
+## 第 1 步：确定检索范围
+
+### 1.1 提取检索关键词
+
+从待评审 PRD 中提取 3-8 个功能关键词，覆盖四类：
+
+| 类型 | 说明 | 示例 |
+|---|---|---|
+| 功能模块名 | 文档自述的功能名 | 高级筛选、混合搜索 |
+| 关键对象名 | 功能作用的核心对象、字段 | 筛选条件、分享链接、文档路径 |
+| 产品 / 平台名 | 所在产品线 | 精卫 |
+| 关联动作 | 会改变状态的操作 | 保存、排序、跳转 |
+
+关键词**逐个独立检索**后取并集。不要用长句组合检索，会漏召回。
+
+### 1.2 确定文档库范围
+
+先调用 `mcp__note__list-group` 获取文档库列表，按产品线收敛候选库：
+
+- 优先使用该产品的**需求管理库**（如「精卫-需求管理」「精卫线上测试」）
+- 其次考虑同产品的项目管理库
+- 用检索结果中的 `group_name` 判断文档是否属于目标产品，不属于的直接剔除
+
+不要跨产品线混用规则。不同产品的同名功能默认无关联。
+
+## 第 2 步：检索
+
+对每个关键词调用 `mcp__note__search-note`。合并结果后剔除以下噪音文档：
+
+- 周报、月报、日报（标题含「周报」「月报」「日报」）
+- 交接文档、会议纪要、会话总结
+- 与目标功能无关的其他库内文档（按 `group_name` 判断）
+
+保留文档的标准是：**标题或高亮内容中出现目标功能的关键概念，且属于目标产品线**。
+
+## 第 3 步：版本收敛（关键步骤）
+
+同一功能往往存在多篇文档或多个版本，必须收敛到最新。
+
+### 判断依据
+
+| 依据 | 说明 |
+|---|---|
+| `updated` 字段 | 文档最后更新时间。**注意**：无关编辑（改错别字、补图）也会刷新该字段，不能单独作为版本依据 |
+| 标题版本号 | 如 `[2.7.3] 搜索页样式调整`。同功能多篇文档并存时，版本号高者优先 |
+| 文档内修订记录 | 若正文含「修订记录」「更新日志」章节，读取最后一次修订内容 |
+
+### 收敛规则
+
+1. **按功能聚类**：把检索结果按功能归组
+2. 组内按「版本号降序 → `updated` 降序」排序，取第一篇为**基准文档**
+3. 若组内版本号相同但 `updated` 不同，取 `updated` 较新者，并在输出中说明存在多个版本
+4. 若版本号无法比较，列出全部候选（按 `updated` 降序），标注「存在多个可能版本，已取最新」
+5. 若同一份文档内部就存在多版本描述（正文前后矛盾），一并作为 E 维度问题报出
+
+### 时效标注
+
+输出每条跨文档结论时，必须标注依据来源：
+
+```
+依据文档：[2.7.3] 搜索页样式调整（更新于 2026-09-17）
+http://note.4399doc.com/prd?note_id=2522a09e47b1a4d8701b208c&group_id=975189ff4d9aa1642cd7d1aa
+```
+
+若基准文档的 `updated` 距今超过 6 个月，追加提示：「该文档较久未更新，如线上已迭代请以现网实际为准」。
+
+## 第 4 步：提取与比对
+
+### 从线上文档提取
+
+用 `mcp__note__fetch-note` 读取基准文档全文，提取：
+
+- 功能规则（判定条件、生效范围、优先级）
+- 字段与命名
+- 限制值（数量、长度、时效、默认值）
+- 交互结果（点击去向、状态变化）
+- 权限与角色范围
+
+### 与新 PRD 比对
+
+逐条比对，按下表判定：
+
+| 情况 | 严重度 |
+|---|---|
+| 规则结论不同，且新 PRD 未说明这是变更 | 阻塞 |
+| 同一操作的结果不一致 | 阻塞 |
+| 线上已有规则，新 PRD 涉及同一模块但未说明是否沿用 | 高风险 |
+| 字段名、术语与线上文档不一致 | 高风险 |
+| 限制值不一致且未说明 | 高风险 |
+| 新 PRD 引用的线上规则，其最新版本已发生变化 | 高风险 |
+| 表述接近但无法确定是否同一条规则 | 待确认（不判错） |
+
+**判定要点**：新 PRD 主动声明「变更/升级/替代」线上规则的，不算冲突，按 A 维度（可追溯性）的正常覆盖处理。
+
+## 链接构造
+
+- `search-note` 直接返回 `detail_url`，可直接使用
+- `fetch-note` 只返回 `id` 与 `owner_id`（即 group_id），需自行拼接：
+
+```
+http://note.4399doc.com/prd?note_id={id}&group_id={owner_id}
+```
+
+- 若链接构造失败或工具未返回必要字段，**只输出文档标题**，并注明「请自行在需求库中检索该标题查看」。不要输出拼错或猜出来的链接。
+
+## 输出要求
+
+E 维度条目在通用格式基础上，额外附上依据来源：
+
+```
+### [阻塞] 筛选条件的多选能力与线上 [2.7.3] 版本相反
+- **位置**：新 PRD 3.2 筛选逻辑
+- **依据**：[2.7.3] 搜索页样式调整（更新于 2026-09-17）
+  http://note.4399doc.com/prd?note_id=2522a09e47b1a4d8701b208c&group_id=975189ff4d9aa1642cd7d1aa
+- **线上规则**：高级筛选项支持多条件组合，云文档类型为多选且含「所有类型」
+- **新 PRD 规则**：筛选条件为单选
+- **问题**：两处结论相反，新 PRD 未说明这是对线上规则的变更
+- **影响**：开发无法判断以哪份为准，可能覆盖线上已有能力
+- **建议**：明确标注是否变更线上规则；若为升级，补充与旧规则的兼容说明
+```
+
+## 检索覆盖说明（必须输出）
+
+在评审报告末尾追加本节，让用户能判断查全了没有：
+
+```
+## 检索覆盖说明
+- 检索关键词：高级筛选、混合搜索、筛选条件、精卫
+- 覆盖文档库：精卫-需求管理、精卫线上测试
+- 命中文档：12 篇 → 剔除周报/交接文档后 5 篇
+- 收敛为基准：2 篇
+  - [2.7.3] 搜索页样式调整（2026-09-17）
+  - [2.6.1] 全局搜索结果页（2026-05-08）
+- 未覆盖：[说明未能检索到的方向，或工具调用失败的记录]
+```

package/skills/prd-lint/references/output-template.md

@@ -0,0 +1,108 @@
+# 输出格式
+
+## 整体结构
+
+```
+# PRD 逻辑评审｜{文档名}
+
+评审时间 {日期} · 检查项 {N} 项 · 发现问题 {M} 项（阻塞 {a} / 高风险 {b} / 建议 {c}）
+
+## 结论速览
+{2-3 句：文档整体自洽程度如何，最需要优先处理的是什么}
+
+## A. 可追溯性
+{逐条列出，或写「未发现问题」}
+
+## B. 逻辑完整性
+{逐条列出，或写「未发现问题」}
+
+## C. 一致性
+{逐条列出，或写「未发现问题」}
+
+## D. 落地质量（附加项）
+{仅当文档已包含这类内容时输出；完全没有则整段省略}
+
+## E. 跨文档一致性
+{逐条列出，每条附依据文档的标题、更新时间、链接；未检索到则写「未检索到相关线上文档」}
+
+## 待确认
+{信息不足、无法判定的疑点，只描述疑点不判错}
+
+## 检索覆盖说明
+- 检索关键词：{列出}
+- 覆盖文档库：{列出}
+- 命中文档：{N} 篇 → 剔除噪音后 {M} 篇
+- 收敛为基准：{列出标题 + 更新时间，或写「无」}
+- 未覆盖：{说明未能检索到的方向，或工具调用失败记录}
+```
+
+## 单条问题的写法
+
+```
+### [阻塞] {一句话概括问题}
+- **位置**：{章节名 / 引用原句}
+- **问题**：{具体表现，必要时列出冲突双方}
+- **影响**：{会导致什么后果}
+- **建议**：{具体可执行的修改方向}
+```
+
+## 严重度定义
+
+| 级别 | 含义 |
+|---|---|
+| 阻塞 | 会导致开发无法实现，或按文档实现后与需求目标相悖 |
+| 高风险 | 会导致返工、上线后出现用户可见问题，或不同人理解不一致 |
+| 建议 | 表达不清、粒度不足、可读性问题，不影响正确落地 |
+
+## 硬性要求
+
+- 每条问题必须能定位到原文；定位不到的不输出
+- 「建议」字段禁止出现「建议完善」「建议补充说明」这类空话
+- 没有问题的维度写「未发现问题」，不得省略该维度
+- 不为凑数量制造条目，问题数量少不是缺陷
+- D 维度只检查文档已有内容，不产出缺失类条目
+- E 维度每条结论必须附依据文档的标题、更新时间与链接；无法溯源的不输出
+- E 维度的「检索覆盖说明」必须输出，不得省略，让用户能判断是否查全
+- 输出中文
+
+## 示例
+
+### [阻塞] 筛选规则与搜索规则的命中优先级缺失
+
+- **位置**：3.2 筛选逻辑 / 4.1 混合搜索
+- **问题**：两处规则均可能作用于同一结果集，文档未定义二者同时生效时谁先执行
+- **影响**：开发需自行拍板，两端实现可能不一致，结果集不可预期
+- **建议**：明确二者互斥，或补充仲裁规则（如「筛选条件作为搜索的前置过滤」）
+
+### [高风险] 背景痛点 P2「重复筛选成本高」无功能承接
+
+- **位置**：2.1 需求背景
+- **问题**：痛点已列出，但功能清单中无对应条目，目标章节亦未覆盖
+- **影响**：需求提出但未落地，或在后续迭代中被遗漏
+- **建议**：补充「筛选条件保存与复用」功能条目，或在范围声明中显式排除并说明原因
+
+### [高风险] 「筛选器」与「过滤器」两个名称指代同一对象
+
+- **位置**：3.2 筛选逻辑（用「筛选器」）/ 4.3 组件说明（用「过滤器」）
+- **问题**：同一概念出现两种命名，文档未说明二者关系
+- **影响**：开发可能按两个组件实现，或反复确认造成沟通成本
+- **建议**：统一术语，并在文档开头增加术语表
+
+### [阻塞] 筛选条件的多选能力与线上 [2.7.3] 版本相反
+
+- **位置**：3.2 筛选逻辑
+- **依据**：[2.7.3] 搜索页样式调整（更新于 2026-09-17）
+  `http://note.4399doc.com/prd?note_id=2522a09e47b1a4d8701b208c&group_id=975189ff4d9aa1642cd7d1aa`
+- **线上规则**：高级筛选项支持多条件组合，云文档类型为多选且含「所有类型」
+- **新 PRD 规则**：筛选条件为单选
+- **问题**：两处结论相反，新 PRD 未说明这是对线上规则的变更
+- **影响**：开发无法判断以哪份为准，可能覆盖线上已有能力
+- **建议**：明确标注是否变更线上规则；若为升级，补充与旧版本的兼容说明
+
+## 结论速览的写法
+
+结论速览只说三件事，不要复述后面的清单：
+
+1. 整体自洽程度（可直接进入评审 / 需先补齐关键逻辑 / 存在阻断性冲突）
+2. 最优先处理的问题（点名 1-2 条阻塞项）
+3. 是否影响排期（有无需要产品补充才能开工的部分）