项目链条核对
项目全流程文件链条核对（按环节先后与金额口径核对链条自洽，仅提示差异，不作出定性结论）
这个插件核对什么
项目链条核对（dsh-pipeline-check）是一个面向质量制造场景的 DeepSeek Harness 核查插件。项目全流程文件链条核对（按环节先后与金额口径核对链条自洽，仅提示差异，不作出定性结论）
规则库 8 条规则，数量居中：既能覆盖这类材料的主要要素，又不会把无关项也拉进来。按依据类型拆开看：由原则推导 7 条、本机构配置 1 条。
核对方式
项目链条核对的检查手段集中在以下几类，都不依赖模型判断：。
插件不会替你查证。它只比较材料自身各处之间、以及材料与所引条款之间是否一致；材料里写错的事实，只要内部自洽，就查不出来。
这里没有算术核对——规则库处理的是齐备性、取值合法性与字段关系，不重算任何金额或数量。
它不作什么判断
共同约定只有一条——插件只做「指出不一致」，不做「下结论」。差异清单里每条都带规则编号、依据的文件与条款、以及差异落在材料里的位置。
结果里最高的严重度是「提示」。这不是保守，而是如实的：这些规则所对照的条文没有逐字文本，凭原则推导不足以支撑更强的结论。
另有 1 条规则的判据来自使用机构自己的配置项，不是国家标准。换机构使用前必须先替换这份配置，否则核对的是别人的口径。
每个没能跑起来的检查都会出现在跳过项里并附上原因——缺字段、缺配置、或规则要求的前置项不存在。所以「没有差异」和「没有检查」在结果里是两件分开陈述的事。
规则清单
| 规则 | 检查内容 | 严重度 | 依据类型 |
|---|---|---|---|
PC-001 | 项目台账应声明项目名称与编号 | 提示 | 由原则推导 |
PC-002 | 环节台账应填写环节名称与文件名称 | 提示 | 由原则推导 |
PC-003 | 环节顺序应与本机构配置的顺序一致 | 参考 | 本机构配置 |
PC-004 | 批复、签署与生效日期应可解析且先后成立 | 提示 | 由原则推导 |
PC-005 | 同一环节的文件编号不应重复登记 | 提示 | 由原则推导 |
PC-006 | 金额栏应为可解析的数值 | 提示 | 由原则推导 |
PC-007 | 台账文件名称不应残留未替换的占位符 | 提示 | 由原则推导 |
PC-008 | 环节序号不应在台账内重复 | 提示 | 由原则推导 |
严重度含义：提示（7 条）——差异成立，但条文未直接规定，或需人工判断后确认；参考（1 条）——只作提示，供人工复核，不构成任何结论。
依据类型含义：由原则推导（7 条）——未能取得逐字条文，依原则性条款推导，严重度上限为「提示」；本机构配置（1 条）——阈值或清单来自使用机构自身配置而非国家标准，严重度上限为「参考」。
依据的标准
| 依据 | 类型 | 引用该依据的规则数 |
|---|---|---|
| 本机构项目管理办法与投资管理制度（无国家标准） | 文件／标准 | 8 条 |
| 无统一标准 | 编号 | — |
编号、版本与效力说明
- 无统一标准（本条依据为台账可追溯性）
- 无统一标准（本条依据为链条齐备性）
- 无统一标准（本条依据为本机构配置的环节顺序表）
- 无统一标准（本条依据为日期自洽）
- 无统一标准（本条依据为台账唯一性）
- 无统一标准（本条依据为金额可比性）
- 无统一标准（本条依据为台账真实性）
这是引用取证记录中的完整编号与效力说明，含发布日期、实施日期、代替关系与强制性说明。规则库核对时对照的是这里列出的版本；若本单位执行的是其他版本，结论不直接适用。
以上文件是插件自己声明的核对依据。规则库中每条规则还单独记录了它对照的具体条款；条款文本能否逐字取得，见下一节。
引用取证状态
引用取证：这套规则库没有一条规则声称直接对照逐字条文——8 条规则全部属于「由原则推导」或「本机构配置」。因此也没有「条文未取得」的欠账需要标注：从一开始就没有引用条文原文。结果中的差异是原则层面的一致性提示。
规则引用的文件共 1 份，按引用规则数排列为：本机构项目管理办法与投资管理制度（无国家标准）（8 条）。同一份文件在不同规则中可能被引用于不同条款。
结果怎么读
本插件共 8 条规则，其中严重度最高的一档是「提示」，共 7 条：PC-001、PC-002、PC-004、PC-005、PC-006、PC-007、PC-008。这几条是清单里最需要先看的；其余条目按材料实际内容逐条判断即可。
还有 1 条规则属于「本机构配置」（PC-003）。这几条只有在配置被填写后才会执行；未配置时它们不会静默通过，而是列入跳过。
适用场景与同组插件
面向质量管理与工艺岗的体系文件核对：FMEA 分析表、PPAP 提交要素、SPC 控制图常数与过程能力、审核意见闭环。
同一职业分组「质量制造」下还有 7 个核查插件，分别是FMEA 表核对（dsh-fmea-table-check）、点评回复核对（dsh-ota-review-check）、PPAP 要素核对（dsh-ppap-check）、维修工单核对（dsh-repair-order-qc）、审稿回应核对（dsh-review-reply-check）、控制图常数核对（dsh-spc-gbt-adapter） 等。这类材料通常需要同时过几个插件：一个插件只覆盖它自己那份规则库声明过的范围，把几个插件的结果合起来看才是完整的一次复核。
发布渠道是 npm 包 dsh-pipeline-check，源码在 GitHub 的 PerryLink/dsh-pipeline-check，许可为 Apache-2.0。本页的规则清单直接取自仓库里的规则库文件（版本 2026.1），不是手写的介绍。
- FMEA 表核对
dsh-fmea-table-check—— FMEA 分析表要素齐备性与风险顺序数一致性核对 - 点评回复核对
dsh-ota-review-check—— 在线点评回复台账核对 - PPAP 要素核对
dsh-ppap-check—— PPAP 提交要素齐备性核对 - 维修工单核对
dsh-repair-order-qc—— 维修工单结算核对 - 审稿回应核对
dsh-review-reply-check—— 审稿意见逐条回应覆盖核对 - 控制图常数核对
dsh-spc-gbt-adapter—— 控制图常数与过程能力指数核对 - 质保索赔核对
dsh-warranty-calc—— 质保期与索赔金额核对
安装
安装命令对两个平台是同一个 dsh 子命令，只有随后确认安装结果的那一步按 shell 不同：
bash / sh
dsh plugin --profile default add dsh-pipeline-check
dsh --profile default --dump-config | grep 'dsh-pipeline-check'PowerShell
dsh plugin --profile default add dsh-pipeline-check
dsh --profile default --dump-config | Select-String 'dsh-pipeline-check'profile 名按实际情况替换。注意安装本身不会热加载——重开会话之后插件才生效。
完整文档
以上是 项目链条核对 的核对范围与依据。至于怎么把材料交给它、有哪些配置项可调、每条规则的参数与输出结构，在仓库文档里。
完整文档 → GitHub（PerryLink/dsh-pipeline-check）
不确定是否该用这个插件，先看按材料类型组织的对照表；同类插件则在质量制造分组下。 该用哪个核查插件 · 质量制造 · 全部核查插件