regulatory-policy-diff git:20260529.efece30A

Immutable. This exact content is served forever at /api/v1/blob/46f2109937cb2cf8.

---
name: regulatory-policy-diff
description: 把某条具体的监管变化对照已索引的政策库做差异比对。在监管变化发生需要知道触及哪些政策、内规差异是什么时使用；用户说"对照我们政策做比对"、"哪条政策受影响"、"做内规差异分析"时，或 `regulatory-reg-feed-watcher`（监管动态监测）移交重要项时调用。
argument-hint: "[监管名，或粘贴监管文本/摘要]"
---

# /policy-diff

1. 读 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` → 政策库索引
2. 用下面的工作流
3. 从监管中抽取要求。匹配到已索引的政策
4. 输出：逐要求的内规差异分析，哪些政策要更新

---

## 事项上下文

**事项上下文**：核查实务层级 `profile.md` 中 `## 事项工作区`。如果 `启用` 是 `✗`（企业内部法务用户默认），跳过本段 —— 技能用实务层级上下文，事项机制不可见。如果启用且没有当前事项，问："这是哪个事项？跑 `regulatory-matter-workspace switch <slug>` 或说切到实务层级。"读当前事项的 `matter.md` 拿事项特定上下文和覆盖项。输出写到事项目录 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/matters/<matter-slug>/`。**绝不**读其他事项的文件，除非 `跨事项上下文` 是 `开启`。

---

## 用途

一条规章变了。你有政策。本技能找出变化触及哪些政策，以及"规章现在要求什么"和"政策说什么"之间的内规差异是什么。

## 读取上下文

`$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` → 政策库索引（政策、位置、归口部门、负责人，可选章节负责人）。

**注**：政策库**仅含公司内部政策制度**。外部法规（被比对的源）通过用户输入或 `regulatory-reg-feed-watcher`（监管动态监测）移交进入本技能，**不在**政策库内。

## 审查范围声明

如果用户要求把某个政策章节、要求或类别排除在比对之外：

1. 做 —— 用户掌握范围
2. 但**声明，醒目且永久**："⚠️ 审查范围限定：[X] 节按用户要求排除。本比对不反映完整政策。被排除区域中的内规差异**不**被识别。"放在标识上方，传到所有下游交付件
3. 把这个标记交给 `regulatory-gap-surfacer`（内规差异呈现）："本比对是范围限定的。不要把它当作完整合规图景。"在从本比对衍生的内规差异台账条目上原文携带审查范围限定声明
4. 注明排除意味着什么："排除供应商管理意味着比对会显示'无政策处理供应商管理' —— 这比显示这个内规差异**更糟糕**"

基于未披露的范围排除构建的合规交付件，在监管调查或诉讼证据开示中看起来像隐瞒。这个标记是"我们做了范围审查"和"我们藏了问题"的区别。

## 工作流

### 第 0 步：做比对之前先核实规则状态

对照政策做比对之前，确认规则**实际现行有效**。规则可能不现行有效的红色标记：

- 适用 / 合规日期超期 30 天以上但你没有未延后的确认
- 规则已超过 12 个月
- 规则是政治敏感的正式规章（重大规章经常被挑战）

看到红色标记时，核查（通过元典集成、公网搜索若启用、或国家法律法规数据库 / 部委公开栏目）以下情况：延期、暂缓、禁制令、撤回提案、被撤销、修订。如能核查且确认规则现行有效，继续。如不能核验（无工具连接），在标识**上方**、内容**之前**输出本横幅提示：

> `⚠️ 规则状态未核验 —— 我无法确认此规则当前是否现行有效。正式规章发布后经常被暂缓、被禁制、被延期或撤销。在你确认规则状态前（通过国家法律法规数据库 / 部委公开栏目 / 外部律师），不要把以下合规日期当作有约束力的。`

给输出中每个到期日打标：`[发布版规则中的到期日 — 状态未核验]`。

规则状态不确定性向下游传。把内规差异移交给 `regulatory-gap-surfacer`（内规差异呈现）时，标 `status_verified: false`，让它在已发布日期基础上不被路由到逾期档。

### 第 1 步：抽取新要求

**不擅自补充**：如果监管变化文本部分缺失或含糊且更完整的规则在索引出处不可得，停下来问。**不要**默默从公网搜索或模型知识补缺漏。说："我手头有 [拥有的]。要准确抽取要求我需要 [缺失的]。选项：（1）贴完整文本、（2）指我看一手出处、（3）公网搜索规则 —— 结果会标 `[网页检索 — 需核验]` 并应对照发布机关核验、（4）就此停。要哪个？"律师 / 法务决定是否接受低信度源；技能不替他们决定。

**来源归因**：给每个引用打标 —— 监管引用、任何交叉引用、任何政策摘录 —— 标明它来自哪里：对来自一手出处、政策库或 MCP 的项用 `[<监管或检索工具>]`（如 `[元典法规]`、`[国家法律法规数据库]`、`[部委公开栏目]`）；公网搜索拉的项用 `[网页检索 — 需核验]`；模型训练数据回忆的用 `[模型知识 — 需核验]`；用户粘贴的用 `[用户提供]`。标"需核验"的项造假风险高，应先核。**绝不**在输出中剥离或合并标签。

读监管变化。列出每条**离散**的新或变化的要求：

| # | 要求 | 生效 | 引用 |
|---|---|---|---|
| 1 | [要求什么] | [日期] | [节] |

具体。"加强信息披露要求"不是要求。"必须在 Y 格式下、在 Z 流程节点披露 X"才是要求。

### 第 2 步：映射到政策

对每条要求，哪份已索引政策**最接近**？

- **直接命中**：政策明确覆盖此话题
- **间接命中**：政策覆盖相关话题，这是个新子议题
- **无匹配**：无政策处理这事 —— 内规差异是"政策不存在"

**对命中的政策**：如果政策库填了章节负责人（可选第三层），尝试命中**具体章节**，那条内规差异的整改默认派给章节负责人。否则派给政策负责人。

### 第 3 步：比对

对每条直接 / 间接命中，读政策做比较：

```markdown
### 要求 [N]：[名]

**新规则要求**：[要求]

**我们的政策（[名]，最后更新 [日期]）说**：
> "[相关摘录]"

**内规差异**：[无 — 政策已覆盖 ｜ 部分 — 政策处理 X 但不处理 Y ｜ 完整 — 政策矛盾或不处理]

**所需变化**：[具体 —— "在 X 加一段"，不是"更新政策"]

**政策负责人**：[来自索引]
**整改负责人**：[默认 = 政策负责人；内规差异创建时可改派业务部门]
**章节负责人**（如适用，按命中章节）：[来自可选索引]
```

### 第 4 步：无匹配内规差异

无政策匹配的要求单独列出：

```markdown
### 新政策需要

要求 [N]：[要求]

无现有政策处理。选项：
- 起草新政策（建议归口：[处理最接近话题的部门]，负责人：[根据归口分配]）
- 加进现有 [相关政策]，作为新章节（章节负责人：[相关人]）
- 判定这事不需要政策（一次性合规，非持续性）
```

## 按监管输入类型分支

### 预规则分支（征求意见稿 / 行政指导 / 监管讲话 / 答记者问 / 窗口指导）

如果监管输入是征求意见稿或预规则形态（尚无强制要求），**不**跑完整内规差异闭环比对。改为产出**前置定位分析**：

- 命名最终规则发布后可能需要变化的政策（不是今天）
- 标记草案中的议题是否与公司实务以可能值得提交评议意见的方式相交
- 注评议截止日和团队评议决策负责人（从 profile.md 拿）
- **不**为预规则产出逐要求"无内规差异"行 —— 没有要求可比对。产出一段话，命名未来风险和它会触及的政策

**对中国特有的"非正式"层**（答记者问、监管讲话、窗口指导、约谈通报）：
- 强制标 `[非正式监管口径 — 无法律约束力 / 具实际执法导向 / 建议跟踪]`
- 产出**前置感知备忘**而非完整比对：写明监管表达了什么倾向、可能影响公司哪些政策、建议跟踪节奏
- **不**把它当作触发现行义务变化的信号

### 负发现分支（正式规则 / 征求意见稿对照非目标政策做比对）

如果抽取的要求清单中每一条都是"对 [指定政策] 无内规差异"，**不**产出完整逐要求分析 —— 压缩成单短段：

```markdown
## 政策比对：[监管名] —— [政策名]

[监管] 看起来不要求 [政策名] 变化。[政策名]
§[X] 已覆盖 [Y]。本监管实际触及的政策是
[其他政策 1] 和 [其他政策 2] —— 重跑 `regulatory-policy-diff` 对照那些。

[下一周期 —— 如"下次年度政策复核"] 时复审，或 [触发 —— 如
"规则定稿或修订"] 时复审。
```

一段，一条建议，一条路由说明。**不要**对每条要求重复"无内规差异" —— 总表处理那个。负发现对错目标政策是路由问题，不是合规分析。

### 内规差异分支（正式规则 / 征求意见稿对照目标政策有至少一处内规差异）

按下方规范完整逐要求分析。详细比对格式留给真的发现内规差异的比对。

## 输出

```markdown
[工作秘密标识 —— 按 ## 谁在用这个插件 + shared/header-by-role.md 选定]

## 政策比对：[监管名]

**监管**：[名，链接]
**生效**：[日期]
**抽出要求数**：[N]

### 核心结论

[N 条内规差异在 [日期] 前需要行动 —— 前 3：X、Y、Z]

### 总表

| # | 要求 | 受影响政策 | 内规差异 | 政策负责人 | 整改负责人 |
|---|---|---|---|---|---|
| 1 | [短] | [政策名或"无"] | 无/部分/完整 | [姓名] | [姓名] |

### 详细比对

[第 3 步的每个要求块]

### 需要的新政策

[第 4 步的内容，如有]

### 无内规差异的要求

[清单 —— 知道什么已被覆盖也有用]

---

**依赖前请核验引用**。上述监管引用和政策引用由 AI 生成，未经一手出处核对。在依赖任何要求前，对照元典开放平台、贵所检索平台、或发布机关网站核实规则 —— 核准确性、生效日期、当前状态。AI 生成的监管引用有时虚构、误引或过时。每条要求上的源标签（例如 `[国家法律法规数据库]`、`[网页检索 — 需核验]`）显示引用来自哪里；标"需核验"的项造假风险更高，应先核。
```

## 配置依赖降级

本技能从 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` 读政策库索引。当索引为空或仍是 `[PLACEHOLDER]`：

- **政策库空**：默认把每条要求都标记为"无政策匹配"，并附："你的配置里政策库是空的，所以每条要求都被标记为新政策内规差异。如果你有政策处理这些要求，用 `regulatory-cold-start-interview --redo` 或改 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` 加，然后重跑比对。"
- **某条已匹配政策的负责人缺失**：总表中负责人格留空，并附："[清单] 的政策负责人未设。用 `regulatory-cold-start-interview --redo` 或改 `profile.md` 中的政策库给它们指派负责人，`regulatory-gap-surfacer`（内规差异呈现）才能路由。"

政策库填写且负责人已设时，**不说**关于配置的事。

## 移交

给 `regulatory-gap-surfacer`（内规差异呈现）：每条部分 / 完整内规差异成为带政策负责人 + 整改负责人 + 截止日的跟踪条目。

## 收尾决策树

按 `profile.md` 中 `## 输出` 的决策树收尾。把选项定制给本技能这次产出的内容 —— 五个默认分支（起草 X、上报、补充事实、观察等待、其他）是起点，不是锁死。决策树本身就是输出；律师 / 法务挑。

## 本技能不做的事

- 起草政策更新。它识别要更新什么；`regulatory-policy-redraft`（政策修订红线）（或人）来起草
- 终审解释含糊监管文本。如果规则有两种读法，说出来并标记给律师 / 法务