🎁 福利专区全网大模型免费应用 + 新用户福利 + 注册活动入口,低成本玩转 AI

SOP同步核对 PerryLink/dsh-sop-sync-check

DeepSeek Harness
PerryLink27 天前有提交已提供中文文档扫描:未发现敏感能力

核对作业台账与PFMEA、控制计划的机械一致性

30/100
综合分
0
GitHub 星标
—
npm 周下载
—/5
用户评分

数据截至 2026/10/8 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。

安装命令 · 需先装 dsh CLI 引擎
dsh plugin --profile web add PerryLink/dsh-sop-sync-check
该包不可直接 npm 安装,改从 GitHub 源安装(明细见下方安装检查)

状态速览

判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态
信任档位:需留意
是什么
dsh 原生插件 · tool
装得上吗
实装验证未通过(unknown),装前请到仓库确认最近更新与 issue
L4 · 真实安装等级说明 →
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
活跃:最近一次提交在 27 天前
档位由哪些信号合成

本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。

验证判据与等级说明 →
⚠︎ 实装验证未通过(unknown · 2026/11/4) ——可能是验证环境差异,装前建议到 GitHub 仓库确认最近更新与 issue。
社区实装还没有人打卡 · 装过的第一个就是你
安全扫描自动 · 静态分析源码
v2.7.0
🟢 扫描:未发现敏感能力尚无人工评估
展开查看扫描说明与证据 ↓

静态扫描未发现敏感能力:最多只发网络请求、读取自身元数据或只读文件,未发现执行命令、文件写入或敏感信息读取。

扫描于 2026/11/3(1 天前) · 范围 入口闭包 + 发布文件清单 · 来源 GitHub 仓库

静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。

依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-package-manifest@deepseek-ai/dsh-tools@deepseek-ai/schemastery
给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个

功能亮点

  • 核对台账与控制计划一致性
  • 仅提示差异

作业规程(SOP)核对:依据IATF 16949/汽车行业核心工具手册。仅提示差异,不作出定性结论。

README

由 DeepSeek 最新模型翻译生成
dsh-sop-sync-check — 作业指导书台账与 PFMEA / 控制计划同步检查 dsh-sop-sync-check 读取一份作业指导书台账——产品表头加上每个工序一行——并检查这份台账与它引用的 PFMEA、控制计划在机械层面是否一致:每个工序行是否带规程编号、是否至少引用了 PFMEA 或控制计划、某行引用的版本是否与台账记录的该文档当前版本一致、写出的参数是否带公差、工序编号是否重复、表头是否写明产品、版本日期能否解析且不晚于检查日期。它不判断工艺参数是否正确、控制计划是否覆盖了每个失效模式、PFMEA 分析是否充分;跑不起来的检查会列进 skipped,而不是悄悄算通过。 它能回答什么 | 你的问题 | 它给出的答案 | | 某个工序行在 规程编号 列里没有规程编号。 | SS-001 会报出这一行:规则要求凡是带规程编号列的行都必须填,而且只查有没有填——不查这个规程是不是该工序该用的那个。如果材料里根本没有这一列,规则会报告自己不适用,而不是悄悄算通过。 | | 没人写下这份作业指导书属于哪份 PFMEA 或控制计划。 | SS-002 要求每一行的 PFMEA编号 和 控制计划编号 至少填一个。它只查是否至少引用了一个——不查引用得对不对,也不查它写的版本是不是当前版本;那个比对是 SS-003 的事。 | | 规程里还引用着上一版 PFMEA。
展开完整文档(README 剩余 1 节)
dsh-sop-sync-check — 作业指导书台账与 PFMEA / 控制计划同步检查

dsh-sop-sync-check 读取一份作业指导书台账——产品表头加上每个工序一行——并检查这份台账与它引用的 PFMEA、控制计划在机械层面是否一致:每个工序行是否带规程编号、是否至少引用了 PFMEA 或控制计划、某行引用的版本是否与台账记录的该文档当前版本一致、写出的参数是否带公差、工序编号是否重复、表头是否写明产品、版本日期能否解析且不晚于检查日期。它不判断工艺参数是否正确、控制计划是否覆盖了每个失效模式、PFMEA 分析是否充分;跑不起来的检查会列进 skipped,而不是悄悄算通过。

它能回答什么

| 你的问题 | 它给出的答案 |
| 某个工序行在 规程编号 列里没有规程编号。 | SS-001 会报出这一行:规则要求凡是带规程编号列的行都必须填,而且只查有没有填——不查这个规程是不是该工序该用的那个。如果材料里根本没有这一列,规则会报告自己不适用,而不是悄悄算通过。 |
| 没人写下这份作业指导书属于哪份 PFMEA 或控制计划。 | SS-002 要求每一行的 PFMEA编号 和 控制计划编号 至少填一个。它只查是否至少引用了一个——不查引用得对不对,也不查它写的版本是不是当前版本;那个比对是 SS-003 的事。 |
| 规程里还引用着上一版 PFMEA。这会被抓到吗? | 会。SS-003 从专门的版本列读取版本,或从引用文本末尾的版本标记读取(PFMEA-2026-003 V2);标记需要明确的提示词,比如 V、VER、REV、版本 或 版次,所以文档编号末尾的数字绝不会被误当成版本。它会报出版本字符串与文档当前版本不一致的引用,而且只比对版本字符串——不判断引用应该指向哪个版本。既没有版本列、也读不出可识别的版本字符串时,它会把自己报进 skipped。 |
| 参数列填了,但 参数公差 列是空的。 | SS-004 会报出这一行——但只在参数列填了的时候才报,所以确实不带参数的工序不会被误标。它查的是公差列有没有填,不是参数和它的公差合不合理。 |
| 同一工序号出现在两行。 | SS-005 报告重复的工序号,并指出它第一次看到该编号的那一行;比较时忽略空白字符。重复通常意味着重复登记或工序号打错——哪一行正确仍需人工判断。如果根本没有工序号列,该规则会报告「不适用」,而不是直接通过。 |
| 修订日期写成 2026/3/8,且有一行的日期在下个月。 | SS-007 报告无法解析的修订日期,以及晚于检查日期的日期。它检查日期能否解析、是否晚于检查日期;不判断修订是否及时完成。 |

遵循的标准

本规则包未引用任何公开标准:核验过程未能从 IATF 16949 或汽车行业核心工具手册中取得逐字条款文本,因此每条规则的 basis 都明确写明这一点,每条都是 derived-from-principle,且没有任何一条高于 warn。这些检查实际依据的是台账自身写明的编号与修订——它写在自己列里的工序号、针对 PFMEA 或控制计划引用记录的修订、参数旁的公差、修订日期——相互比对。

| 文档 | 编号 | 引用它的规则 |
| IATF 16949/汽车行业核心工具手册 | 现行版本与条号本次未核实 | SS-001, SS-002, SS-003, SS-004, SS-005, SS-006, SS-007 |

边界: 本插件检查作业规程台账与PFMEA、控制计划之间在机械层面是否一致——编号是否记录、PFMEA 与控制计划是否被引用、规程引用的修订是否与文档当前修订一致、参数是否有公差、工序号是否唯一、台账是否写明产品、修订日期能否解析。它不判断工艺参数是否正确、控制计划是否覆盖每个失效模式、PFMEA 分析是否充分。那些是工艺工程师和质量工程师的判断。

⚠️ 在相信报告中的引用之前,请先读这段

本插件规则包里的每一条 excerpt 都明确写明:未取得条款文本。 该制度出自 IATF 16949 与汽车行业核心工具手册(APQP、PFMEA、控制计划)。核验环节无法从中取得逐字条款文本,因此规则包没有转述引文,而是直接在 excerpt 字段里说明这一缺口,并把诚实的推理写进 note。所以每条规则都是 warn 或 info,并有测试断言:没有任何规则声称拥有它并不具备的引文。拿到文本后,必须做两件事:把每条 excerpt 换成真实条款,并把 kind 提升为 direct。

SS-003 是最有价值的一条:规程仍在引用上一版 PFMEA 修订,是三份文档脱节最常见、也最危险的方式。它读取修订号的来源,要么是专用列,或引用文本末尾的版本标记(PFMEA-2026-003 V2)。它需要明确的提示词——V、VER、REV、版本、版次——这样文档编号末尾的数字才不会被误认成修订版本。两个来源都没有时,它会把自己记入 skipped。

兼容性

| 层面 | 状态 |
| Harness | 对等范围 >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0——已验证同时接受 0.2.0-rc.2 和 0.2.1-alpha.1。故意不声明 engines.dsh:它没有读取方,也无法拒绝宿主 |
| Node | ^22.19.0 || >=24.0.0 |
| 平台 | 全部(纯 ESM;无原生代码、无网络、无模型调用) |
| 工具模式 | 在 native、ptc 和 both 下都能用;要获得完整的作业指令集,请用 ptc |

它做什么

注册 sop_sync_check 工具。它读取一份作业指令登记表——产品表头加上每个工序一行——套用带版本的规则包,返回报告。

| 规则 | 检查项 | 严重级别 | 依据类型 |
| SS-001 | 每个工序都声明了规程编号 | warn | principle |
| SS-002 | 规程引用了它的 PFMEA 或控制计划 | warn | principle |
| SS-003 | 引用的修订版本与文档当前修订版本一致 | warn | principle |
| SS-004 | 声明的参数带有公差 | warn | principle |
| SS-005 | 工序号唯一 | warn | principle |
| SS-006 | 登记表写明了产品 | warn | principle |
| SS-007 | 修订日期能解析,且不在未来 | warn | principle |

安装

dsh plugin --profile <name> add dsh-sop-sync-check
dsh --profile <name> --dump-config | grep 'dsh-sop-sync-check'

配置

| 键 | 类型 | 默认值 | 说明 |
| rulesFile | string | rules/sop-sync-check.yaml | 规则包路径,相对于包根目录 |
| disabledRules | string[] | [] | 要停止运行的规则 id;每个都会出现在 skipped 里 |
| onlyRules | string[] | [] | 只运行这些规则 id;留空则运行全部规则 |
| skipNotes | string | "" | 追加到每个 skipped 原因后面的备注 |
| timeoutMs | number | 120000 | 协作式工具超时预算 |

值得了解的规则级参数:

- SS-003 的 referenceField / actualVersionField / sameVersionField——引用的修订版本和文档当前修订版本分别放在哪里。actualVersionField 接受列表;第一个非空候选生效,裸版本(V2)或带版本的引用(PFMEA-2026-003 V2)都可以。如果你的登记表把引用的修订版本放在单独一列,就在 sameVersionField 里写它的名字。
- SS-004 的 conditionField / requiredFields——哪一列触发要求,以及它需要什么。

素材格式

工具接受 JSON 或 YAML:

productNo: P-2026-001
productName: 前支架 rows:
- { 规程编号: WI-2026-018, 工序号: OP20, 工序名称: 精车外圆,
工艺参数: 主轴转速 1200 r/min, 参数公差: ±50 r/min, PFMEA编号: PFMEA-2026-003 V2, PFMEA现行版本: V2, 控制计划编号: CP-2026-003 V2, 控制计划现行版本: V2, 修订日期: 2026-03-08 }

列名匹配不区分大小写,并忽略空格、下划线和连字符;台账自身的列名会保留,所以每条发现都会指明它读取的是哪一列。日期可以写成 2026-03-08 或 2026-03-08 09:30。

规则来源

规则数据放在 rules/sop-sync-check.yaml。规则包的头部完整说明了引用缺口,每条规则的 note 又重复了与该规则相关的那部分。加载时的守卫通常会强制「摘录必须是至少八个字符的真实引文」,但它分不清引文和描述——所以这个规则包靠头部、每条规则的 note,以及一个测试来兜底,该测试断言每个 excerpt 都承认这个缺口。

故障排查

- SS-003 报告自己已跳过。 引用的修订版本和文档的当前修订版本都读不到。给台账加一列 PFMEA现行版本,或者把修订版本写进引用文本,如 V2。
- SS-003 没有触发,但我明知修订版本不同。 检查修订版本列是否解析成了当前版本:第一个非空候选列胜出,所以排在前面的一列过期数据会遮住后面那一列。
- SS-003 在一条没有修订版本的引用上触发。 这正是该检查的本意——一条不说自己处于哪个修订版本的引用无法比较。
- SS-004 在一个没有公差的过程上触发。 要么该参数确实有公差而它缺失了,要么该过程不带参数,参数列本应为空。
- 插件装上了,但工具始终不出现。 检查 main 是否解析到 lib/index.mjs,以及 pnpm run build 是否生成了它;main 写错会让加载器静默跳过入口。
- dsh plugin add 以不兼容为由拒绝该包。 peer 范围覆盖 0.1.x 和 0.2.x;如果你的运行时不在其中,显式授予豁免: dsh plugin --profile <name> allow-version dsh-sop-sync-check@0.1.0 --dsh-version <runtime> --accept-risk
- check 报告 manifest-peers 失败。 静态检查器比对的是一个硬编码的 peer 范围,它早于 0.2 系列。运行时会在安装时强制 peer 兼容性,所以声明的范围才是正确的;这是 dsh-plugin-dev 中一个已知的上游问题。

开发

pnpm install
pnpm run typecheck # tsc --noEmit
pnpm test # vitest, the shared table-plugin suite plus paired fixtures
pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts
node ../scripts/sync-shared.mjs dsh-sop-sync-check # refresh src/shared from ../src

该插件是纯数据的:src/model.ts 声明表结构,共享工具包提供读取器和检查引擎,规则包声明每一项检查。

许可证

Apache License 2.0 © 2026 dsh-sop-sync-check contributors。
预览分享卡片长什么样 ↓PerryLink/dsh-sop-sync-check
分享 · DeepSeek Harness Hub
PerryLink/dsh-sop-sync-check

核对作业台账与PFMEA、控制计划的机械一致性

这是你的仓库?认领条目

回到顶部