何时使用
当一项法规/监管规则发生变更,需要回答「它触及我们哪些内部制度、与现行制度之间存在什么差距」时使用。典型触发:用户说「把这条法规和我们的制度做差距比对」「这条规则影响哪个制度」「做一次合规缺口分析」,或上游的法规监测环节交来一条实质性变更条目。
不该用的边界:
- 不负责起草制度修订文本——本技能只识别「需要改什么」,实际撰写交给制度起草环节或人工。
- 不对模糊监管条款做权威定性——若条文可作两种解读,明确指出并标注交由法务/外部律师裁断,不替决策者拍板。
- 输入是 ANPR/RFI 等「征求意见、尚无强制要求」的预规则时,不做完整差距闭环,改走预定位分析分支(见步骤)。
步骤
- 载入制度库索引(制度清单、存放位置、责任人/Owner)。索引为空或仍为占位符时,按「注意事项」中的降级处理。
- 核验规则状态(先验后比,见下)。
- 逐条提取新规要求。
- 把每条要求映射到现行制度。
- 对命中的制度做差距比对;对无命中的要求单列为「缺制度」缺口。
- 汇总输出:摘要表 + 逐条详细差距 + 新增制度建议 + 无差距项。
指令
第 0 步:比对前先核验规则是否生效
比对前确认规则确实在施行。以下为「可能未生效」的红旗信号:
- 适用/合规日期已过去超过 30 天,但无法确认未被延期;
- 规则发布已超过 12 个月;
- 属于政治争议较大的终局规则(大型立法常被诉讼挑战)。
遇红旗时,通过研究类 MCP、网络检索(若启用)或官方公报/登记册核查:延期、暂缓执行、禁制令、撤销提案、判决撤销、修订等情况。能核实且确认在施行则继续;若无工具可核实,在正文标题上方、任何内容之前置顶以下横幅:
⚠️ 规则状态未核实——无法确认该规则当前是否生效。终局规则在发布后常被暂缓、禁止、延期或撤销。在你于官方登记册或外部律师处确认状态之前,不要把下文任何合规日期当作有约束力的截止日。
输出中每个截止日都打标:[按已发布规则—状态未核实]。向下游交接缺口时标记 status_verified: false,避免仅凭发布日期被误归入「逾期」桶。
第 1 步:提取新增/变更的要求
- 不静默补全:变更文本残缺或含糊、且索引来源拿不到完整规则时,停下来发问,不要用网络检索或模型记忆悄悄补齐。给出选项:粘贴全文 / 指向权威原文 / 检索网络(结果打
[网络检索—待核实],依赖前须对照发证机构核对)/ 就此停止。由律师决定是否接受低置信来源,Claude 不替其决定。 - 来源标注:每条引用(法规引文、交叉引用、制度摘录)都标来源:原始来源/制度库/MCP 标
[<监管机构或研究工具>];网络检索标[网络检索—待核实];模型记忆标[模型知识—待核实];用户粘贴标[用户提供]。带「待核实」者优先核查,输出中绝不删除或合并标签。
逐条列出离散的新增或变更要求,要具体——「强化披露要求」不算要求;「须在流程 Z 节点以 Y 格式披露 X」才算:
| # | 要求 | 生效日 | 引文 |
|---|---|---|---|
| 1 | [具体要求] | [日期] | [条款] |
第 2 步:映射到制度
每条要求找最接近的现行制度:直接命中(制度明确覆盖该主题)/ 间接命中(覆盖相关主题,本条是新子议题)/ 无命中(无制度涉及——缺口是「制度不存在」)。
第 3 步:比对(对直接/间接命中逐条做)
### 要求 [N]:[名称]
**新规要求:** [要求]
**我方制度([名称],更新于 [日期])规定:**
> "[相关摘录]"
**差距:** [无—已覆盖 | 部分—覆盖 X 未覆盖 Y | 完全—制度矛盾或未涉及]
**所需变更:** [具体到「补一段关于 X 的内容」,而非笼统「更新制度」]
**制度责任人:** [取自索引]
第 4 步:无命中缺口(单列)
### 需新增制度
要求 [N]:[要求]
无现有制度覆盖。选项:
- 起草新制度(建议责任人:最接近主题的 Owner)
- 并入现有 [相关制度] 作为新章节
- 判定无需制度(一次性合规,非持续性)
按输入类型分支
- 预规则分支(ANPR/RFI,无强制要求):不做完整差距闭环,改出「预定位分析」——点名终局规则出台后可能需改的制度、是否值得提交意见函、意见截止日与意见决策责任人。不对 ANPR 逐条产出「无差距」行,用一段话点明未来敞口及触及的制度。
- 否定结论分支(提取的每条都对「该制度」无差距):不做逐条全文分析,压缩成一段:说明该法规似不要求改 [制度],并指出它真正触及的是 [其他制度],建议对那些制度重跑。否定结论命中错目标是「路由问题」,不是合规分析。
- 差距分支(至少有一条对目标制度构成差距):按上面格式做逐条全文分析。
范围完整性
若用户要求把某制度章节/要求/类别排除出比对:照做(用户掌控范围),但要响亮且永久地标记,并置于标题上方、带到每个下游产物:
⚠️ 范围限制:应用户要求排除 [X] 章节。本比对不反映完整制度,被排除区域内的缺口未被识别。
向下游缺口跟踪交接时附上同一横幅原文,并说明排除的含义(如「排除供应商管理意味着比对会显示『无制度涉及供应商管理』——比直接暴露缺口更糟」)。建立在未披露范围排除之上的合规产物,在举证程序中形同隐瞒——这道标记区分了「我们限定了审查范围」与「我们藏了问题」。
示例
输出骨架:
## 制度差距分析:[法规名]
**法规:** [名称、链接] **生效:** [日期] **提取要求数:** [N]
### 结论先行
[需在 [日期] 前处理 N 个缺口——前三:X、Y、Z]
### 摘要
| # | 要求 | 受影响制度 | 差距 | 责任人 |
|---|------|-----------|------|--------|
| 1 | [简述] | [制度名或「无」] | 无/部分/完全 | [姓名] |
### 详细差距
[第 3 步各要求块]
### 需新增制度
[第 4 步,如有]
### 无差距要求
[列表——便于了解已覆盖范围]
---
**依赖前请核验引文。** 上述法规引文与制度引用为 AI 生成、未对照原始来源核查。行动前请对照权威研究平台或发证机构网站确认条文准确性、生效日与当前状态。AI 生成的监管引文有时被臆造、误引或过时;每条要求上的来源标签显示其出处,带「待核实」者风险更高、应先核查。
注意事项
- 制度库为空时:默认把每条要求标为「无制度命中」,并在输出追加提示——若实际已有制度,请先补入制度库再重跑比对。
- 匹配制度缺责任人时:摘要中 Owner 留空,并追加提示请补齐,以便下游缺口跟踪可正确路由。制度库已填全且责任人齐备时,不要在输出里提配置的事。
- 交接:每个「部分」或「完全」差距都转为带责任人与截止日的跟踪项,移交缺口跟踪环节。
- 结尾给出「下一步决策树」(起草 X / 升级上报 / 补充事实 / 观望 / 其他),由律师选择,而非替其锁定。
互见
- fact-checking:核验 AI 生成的监管引文是否被臆造、误引或过时。
- first-principles-thinking:拆解模糊监管条文、判定一条要求是否真正构成新义务。
本条采编自 anthropics/claude-for-legal(Apache-2.0)。