标准数据双分类标注（GB/T 1.1 功能类型 + 标准化对象）

一句话定位：本技能把 GB/T 1.1—2020 起草时用于「定方向」的两个分类，反过来用作「存量标准数据」的标注维度，
让标准库具备「按功能类型 + 按标准化对象」两个维度检索、统计与分析的能力，并给出可直接落地的判定规则与置信度机制。

R 原文引用（核心条款）

> 文件名称由引导元素、主体元素和补充元素组成，由一般到特殊。（GB/T 1.1—2020 文件名称三元素）
> 主体元素（必备）：标准化对象本身。补充元素（可选）：标准化对象的特殊方面。

> 规范性要素选择的三选择原则：1) 标准化对象原则——拟标准化的是产品/系统、过程还是服务；
> 2) 文件使用者原则——使用者关注「结果」还是「过程」；3) 目的导向原则。（GB/T 1.1—2020）

> 标准按功能分为 7 类，核心技术要素分别为：术语标准→术语条目；符号标准→符号/标志及其含义；
> 分类标准→分类和/或编码；试验标准→试验步骤、试验数据处理；规范标准→要求、证实方法；
> 规程标准→程序、确立程序、指示、追溯/证实方法；指南标准→需考虑的因素。（GB/T 1.1—2020 表4）

> 产品标准（7.9）/过程标准（7.10）/服务标准（7.11）/接口标准（7.12）/数据待定标准（7.13）/基础标准（7.1）。
> （GB/T 20000.1—2014 第 7 章）

I 骨架：两个字段、两套枚举、两个判定流程

一、字段 1：标准功能类型 function_type（7 枚举）

判定优先级（核心）：

1. 标准号前缀（最强信号）：JJF → specification（计量技术规范，GB/T 20000.1 5.5）；JJG → code_of_practice（计量检定规程，5.6）。置信度=高。
2. 剥离「第N部分：XXX」，取主体名称——补充元素在主体尾部。
3. 尾部最长锚点匹配（置信度=高）：见 references/rule-library.md 锚点表。
4. 方法/基础类关键词（试验、测试、检测、测量、术语、符号、分类…）→ 对应类型，置信度=中。须优先于产品判定。
5. 产品判定（含产品专名或设备词素）→ specification，置信度=中。须优先于活动类关键词。
6. 活动类关键词（作业、施工、检修、导则、指南…）→ 对应类型，置信度=中。
7. 兜底 → specification，置信度=低，转人工复核。

二、字段 2：标准化对象 object_type（6 枚举）

判定优先级：

0. function_type ∈ {terminology, symbol, classification} → 强制 basic（7.1 明确基础标准通常含这三类）。置信度=高。
1. 剥离名称尾部功能词，得主体元素（主体元素即标准化对象本身）。
2. 分层匹配：interface → data → service → product(专名) → process(专名) → product(设备词素)。
3. 兜底 → process，置信度=低，转人工复核。

三、置信度与人工复核（必须的工程配套）

• 每个字段同时输出 判定依据文本 与 置信度（高/中/低），便于追溯。
• 任一字段置信度=低 → need_review = 1，进入人工复核队列。
• 复核界面须展示：标准号、清洗后名称、当前判定值、判定依据、下拉改判。
• 规则迭代闭环：同一关键词被反复改判时回写关键词表。
• 经验值：规则引擎跑完，低置信比例约 8%，复核工作量可控；不要追求 0%，语义判断本就该人工拍板。

A1 案例：易错点四则

A2 触发场景

1. 标准库需要新增分类检索/统计维度，只有 type（国标/行标/地标/团标/企标）不够用。
2. 批量标准清单需要自动归类并评估报告质量（置信度分布）。
3. 设计标准数据录入前的清洗规范，需要把分类规则固化进清洗函数。
4. 需要判断某份标准属于术语/符号/分类/试验/规范/规程/指南中的哪一类。
5. 需要判断某份标准的标准化对象是产品、过程还是服务。

E 执行步骤

1. 取数据：标准号 + 标准名称（两列即可，无需全文）。
2. 清洗名称（必做）：PDF 提取常导致中文字符间乱插空格，须先删除 CJK-CJK 之间的空格、归一「第 N 部分」→「第N部分」，否则锚点匹配会失效。
3. 跑判定引擎：references/classify_engine.py 可直接复用（改 SRC/OUT 路径即可），内含完整的锚点表与关键词库。
4. 看分布：输出两个字段的分布、交叉统计、置信度组合。若某类占比异常（如试验标准骤降），说明优先级被改坏，回到 A1 四则易错点自查。
5. 出规则表：把锚点表、分层关键词表、优先级表整理成文档，供人工复核与规则迭代。
6. 定复核流程：低置信行走人工，改判留痕，回写关键词表。

B 边界

• 只做分类标注，不替代内容起草：功能类型的具体编写遵守 GB/T 20001（所有部分）。
• 术语以 GB/T 20000.1 为准，本技能的对象类别定义引自该标准第 7 章。
• 规则引擎有残差：长尾设备名、跨学科标准会误判，靠置信度标记 + 人工复核兜住，不要谎称 100% 准确。

• 关键词库需按领域迭代：本技能关键词库是按能源电力行业标准（DL/T、NB/T、SY/T、MT/T）调优的，
  换到其他领域（如医疗、汽车、食品）须先扩充专名关键词再跑。

• ⚠️ 头号坑：名称清洗不要无差别删除中文之间的空格（2026-09-02 实测，13936 条库）
  无法自动区分「PDF 乱插空格」与「元素间合法分隔空格」：

三种自动判据全部失效，不要再试：
1. 空格数量 —— 含 2 个空格的 728 条全是「主体元素 第N部分 补充元素」的合法三段式；
4 个空格的样本里也混着合法名称。
2. bigram 词频（假设「两侧字符常连写 = 乱插」）—— 方向相反：合法的 气探 频次 18，
乱插的 苯二 反而低频；且高频桶 50+ 里几乎全是 规范 第N部分 这类合法结构。
3. 短片段切分 —— 页岩气 排采工艺 等合法短元素被大量误判。

正确做法：clean_name(name) 默认只做零误伤的结构性归一（换行断行修复、
「第 N 部分」编号归一、元素间空格保护、全角破折号转半角、连续空格折叠）；
仅在确知数据源来自 PDF 提取时传 aggressive=True。全库有 2777 条含 1 个合法分隔空格，
无差别删除会造成大规模误伤。做不到判别时，把可疑项导出交人工确认，不要猜。

• 第N部分 是结构性空格，永远合法：GB/T 1.1—2020 规定名称由
  「引导元素 + 主体元素 + 补充元素」构成，…规范 第N部分：… 中的空格是元素分隔，
  清洗时须先用占位符保护，否则会被空格清理吃掉。

• ⚠️ 二号坑：标准号反查类别，四个前缀陷阱（2026-09-02 实测，13936 条库）
  用标准号推断 type 看着最可靠，实际有四个坑，全踩过：

推断不出就返回空、交人工，绝不猜测。 实测审计盲区 13936 条中仅 163 条（1.2%），
且其中 162 条是政策文号（中电联技经[2006]119号）这类非标准号文档，属正常。

• ⚠️ 三号坑：中文全文检索用 unicode61 基本失效
  SQLite FTS5 默认分词器把连续汉字视为一个整体 token，
  导致 变压器 在 LIKE 能命中 297 条的情况下，FTS 只召回 3 条；储能、焊接 召回 0。
  正解：改用 tokenize='trigram'（SQLite 3.34+），3 字以上中文召回 100% 且与 LIKE 基准一致；
  trigram 不支持前缀查询（term* 会报错）也不匹配 <3 字符的词，
  故查询层需对 1-2 字中文词降级走 LIKE。实测 23 个查询词：unicode61 达标 6 个，trigram 达标 17 个。

• ⚠️ 四号坑：data（数据待定标准）不是「沾信息/通信就算」（2026-09-03 修订，13908 条库实测）
  GB/T 20000.1—2014 的 7.13 指规定数据本身的标准——数据元、元数据、数据字典、数据模型、
  信息分类与编码、数据交换格式、数据接口协议等。
  仅因名称出现「信息」「通信」「文件」「档案」「记录」不构成数据待定标准：
  信息安全技术 个人信息安全规范 规定的是活动过程要求 → 过程；
  电力用户用电信息采集系统技术规范 对象是系统 → 产品；
  电动汽车充换电服务信息交换 → 服务。
  修订后 data 段只保留规定数据本身的复合词（元数据/数据元/数据字典/数据模型/数据交换/
  数据格式/交换格式/存储格式/标识代码/分类编码/知识图谱 等），泛化词退出直接判定。
  效果：data 584 → 146 条（本轮 442 条重分类，零新增人工复核）。

• ⚠️ 五号坑：调整关键词归属后，必须三查，只看迁移矩阵会漏掉
  把泛化词移出 data 后，迁移方向看着全对，但 need_review 从 1056 涨到 1087——
  31 条原靠泛化词判高置信，移出后掉进兜底低置信，凭空多出 31 条人工复核。
  判定方向对了、置信度塌了，仍是净损失。
  改动后必查三张表：
  1. 迁移矩阵（各方向条数）
  2. need_review 增减（新增复核任务是硬指标，应做到 ≤0）
  3. 置信度降级分布（高→中/低各有几条，逐条看依据）

补救办法：按降级清单反推最小补词集补进承接类别（本轮给 process 段补了 23 个承接词，
如 信息化/软件工程/信息技术/通信工程/通信设计/档案整理/归档/竣工图/信息交换/知识管理），
把「兜底低置信」救回「目标类高置信」，need_review 增加 31 → 0。
补词优先加在匹配链末尾的类别（本技能顺序为 interface→data→service→product→process），
这样只会兜住前面都没命中的记录，不会抢走已有高置信判定。
补词前先查「该词已覆盖多少条、其中几条是当前低置信」：覆盖 200+ 却只受益几条 = 泛化严重，改用复合词。

• 「数据」作修饰语不算数据待定标准：数据通信网、数据中心机房用不间断电源系统、
  地震数据采集系统检验项目 —— 「数据」只是修饰后面的产品/活动，应按主体词判产品/过程。
  （本轮识别出 33 条，暂未处理，作为已知残差。）

• 单词素误捕先算删除代价再动手：设备词素层的单字「网」会误捕网页/网络/电网/IP网，
  「表」会误捕「表述」的「表」。但删掉「表」会让 52 条里大量的电能表掉进兜底——
  删除代价（90 条降级）远大于收益（修 6 条误捕）。
  判据：误捕若只造成高→中降档（中不触发人工复核）可接受；若掉到低才必须修。

• 若需完整关键词表（产品专名、过程专名、设备词素、名称补充元素锚点），
  读取 references/rule-library.md，不要凭记忆补充。

references

• references/classify_engine.py — 可直接运行的判定引擎（改路径即用），含完整规则数据结构。
  另含 infer_type_by_code(code)：标准号 → 类别，已处理上述四个前缀陷阱，
  与平台 server/utils/standard-normalize.js 的 inferTypeByCode 逐例对齐（35/35 一致）。
• references/rule-library.md — 名称补充元素锚点表 + 分层关键词库 + 置信度规则说明。

SkillPay 支付宝 AI 按量付费改造（402 协议）

本 skill 作为付费 skill 对外提供时，每次调用按量计费，基于支付宝 AI 付 AI 按量付费（402 Payment Required / A2M）协议自动收款。
智能体在调用本 skill 的付费资源前，必须按以下四阶段状态机执行：probe → pay → complete → ack，并以 out_trade_no 为主键做订单持久化与幂等。

阶段 0：probe（支付状态探测）

调用付费资源时先携带本机持久化订单发起 probe：

GET /api/skillpay/probe?resource_id=<资源ID>&out_trade_no=<本地订单号>

• 返回 200 且 paid=true：已有有效支付，直接进入履约（跳到 complete/ack），不得重复下单。
• 返回 402 Payment Needed：进入账单下发处理（阶段 1）。

阶段 1：402 账单下发（Payment-Needed）

无有效 Payment-Proof 时，服务端返回 HTTP 402 Payment Required，并在 Payment-Needed 响应头返回 Base64URL 编码账单（智能体支付依据是 Header，响应体仅调试用）。账单 protocol 必含：out_trade_no、amount、currency=CNY、resource_id、pay_before、seller_signature、seller_sign_type=RSA2、seller_unique_id；method 必含：seller_name、seller_id、seller_app_id、goods_name、seller_unique_id_key、service_id。

收到 402 后智能体应：

1. Base64URL 解码 Payment-Needed，向用户展示金额（amount）、商品名（goods_name）、支付截止时间（pay_before）。
2. 引导用户在支付宝 App 完成支付（沙箱 service_id 固定为 api_mock_service_id；生产为服务市场真实 serviceId）。
3. 支付完成后进入阶段 2。

阶段 2：pay（携带 Payment-Proof 凭证重试）

用户付款成功后，智能体携带 Payment-Proof 请求头重新请求同一付费资源：

GET /api/skillpay/pay?resource_id=<资源ID>
Payment-Proof: <Base64 编码支付凭证>

Payment-Proof 解码后至少包含：protocol.payment_proof、protocol.trade_no、method.client_session（可选）。
智能体收到 402 后应最多重试 3 次（间隔 ≥2 秒），仅对 PAY_SUBMIT_FAILED 类瞬时错误码重试；其他错误码直接向用户透出。

阶段 3：complete（验付调用）

服务端解析 Payment-Proof 后调用支付宝验付接口 alipay.aipay.agent.payment.verify（入参：trade_no、payment_proof、可选 client_session）。验付通过必须同时满足以下校验，任一失败返回 402 让智能体重新支付，不得返回资源：

阶段 4：ack（履约确认）

资源生成成功后，服务端调用 alipay.aipay.agent.fulfillment.confirm（入参仅 trade_no）向支付宝确认履约；确认成功后才把订单标记为最终完成并返回资源。确认失败时允许同一 Payment-Proof 重试 ack，避免资源已生成但平台未记录履约。

订单持久化与幂等

• 以 out_trade_no 为唯一主键持久化订单（本地 JSON 文件或服务端数据库），字段至少含：out_trade_no、resource_id、amount、status（CREATED/PAID/FULFILL_PENDING/COMPLETED/CLOSED）、trade_no、payment_proof、pay_before、created_at。
• 幂等规则：同一 out_trade_no 重复 probe 返回已存订单而非新建；同一 trade_no 只允许履约一次；已进入 FULFILL_PENDING/COMPLETED 的订单重入时只重试 ack 或返回已保存结果，不得重复生成资源、不得要求用户重复付款。
• 沙箱联调使用沙箱网关 https://openapi-sandbox.dl.alipaydev.com/gateway.do 与 service_id=api_mock_service_id（生产禁用）；生产替换为真实 serviceId 与生产网关，应用私钥仅保存在服务端，禁止写入本仓库或提供给智能体上下文。
• 支付结果以验付接口（alipay.aipay.agent.payment.verify）为准；402 之外的任何响应不得作为付款成功依据。

快速自检

• 未付款调用 → 收到 402 + Payment-Needed 账单 ✅
• 支付后携带 Payment-Proof 重试 → 验付通过、返回资源 ✅
• 同一凭证二次调用 → 命中持久化订单，幂等返回，不重复扣费 ✅