regulation-engine · 智能法规分析引擎

> 四件事：巡检发现 → 分析深挖 → 建库归档 → 维度切片横向拉通。

触发条件

用户意图涉及"法规""监管""合规"相关内容时激活本 skill。

能力模块

> 四模块关系：巡检发现 → 分析深挖 → 建库归档 → 维度切片横向拉通。前三个「纵向」按篇深挖，第四个「横向」跨篇切片。

调用路由

用户触发 → 读取 profile（profiles/<instance>/profile.md）
         → 判断意图：
            ├─ 巡检类 → engine/radar.md
            ├─ 分析类 → engine/analyzer.md（先执行 Step 0 分级）
            ├─ 建库类 → engine/library.md
            ├─ 维度切片类 → engine/matrix.md
            └─ 配置类 / 无 profile → 首次配置引导（见下文）

首次配置引导

当检测到 profiles/ 下无实例配置时，自动展示四功能开场白：

我可以帮你做四件事：

① 巡检 — 定时扫描监管网站，发现新法规自动推送
② 分析 — 拿到一篇法规，帮你逐条梳理 + 影响分析 + 制度解读
③ 建库 — 把分析好的法规组织成索引页，追踪全生命周期
④ 维度切片 — 把所有法规按某个合规主题拉在一起看

建议从②分析开始——拿一篇法规试试手，我会在过程中问你必要的配置。
或者告诉我你想做什么，我来引导。

各功能按需触发时再收集该功能所需的配置项，profile 逐轮补完，不再一次性连问 5 个问题。

> 快速批量配置：直接复制 profiles/_template.md 填写，跳过交互。

❗ 运行时分叉必须主动问询（强制，适用所有模块）

凡是 skill 里存在"模式 / 逻辑 / 方案"分叉的环节，运行时必须主动把选项摆出来、引导用户选择，不得擅自默认。

• 用户不会预先知道这些分叉的存在，"默认沉默选一个"等于替用户做了他不知情的决定。
• 分叉场景包括但不限于：
• 建库：索引页组织方式（方式A 按业务线 / 方式B 按效力层级 / 两者并存）
• 分析：多篇拆分 vs 合并为一篇（子页内容量大时）
• 分析：分析视角 / 主体范围（若 profile 未明确）
• 取不到的子页/附件如何处理（跳过标注待补 vs 等用户提供）
• 维度切片：单条输入 vs 批量导入（新增维度时，对话式逐条新增或表格模板批量导入）
• 问询方式：先读出模板/profile 里的准确选项（不凭印象），用一句话列出每个选项的适用场景 + 推荐项，让用户一句话能选。
• 仅当 profile 里已明确预设该选择时，才可不重复问（但须在交付时告知"按 profile 预设的…执行"）。

通用规则引用

各模块共享的原则和标准不在模块内重复，统一引用：
- 核心原则 → guides/principles.md
- 分级标准 → guides/classification.md
- 工具备忘 → guides/tools-notes.md
- 质量门 → engine/quality-gate.md + engine/quality-gate-assertions.md
- 子agent派发协议 → engine/analyzer.md（派发最小指令模板）

❗ 子agent 分析规范（强制）

当需要用子agent并行分析多篇法规时，必须遵循以下规范（派发协议 + 质量门验收）：

前置约束：子agent task 最小指令模板（派发协议，不可废）

派发给子agent 的 task 必须包含以下内容（缺一不可）：

1. 强制引用："分析前先读并严格遵循 {skill绝对路径}/engine/analyzer.md 的子agent 并行整理规范"
2. 主体名称：明确写出"主体：XXX"
3. 分析视角：给出 profile 中的分析视角提示词原文
4. 源文件列表：每篇的路径 + 一句话说明
5. 输出路径：每篇分析稿的保存位置

> 派发协议管的是「子agent 拿到输入完不完整」，不能废。详见 engine/analyzer.md 的「子agent 并行整理规范」小节。

后置验收：质量门（取代旧 checklist 质检）

子agent 产出收回后，主agent 在发布前执行质量门验收（见 engine/quality-gate.md）：

1. 机器硬门槛：跑 scripts/gates/analyzer_gate.py（结构断言，零 token）
2. 语义检查：由全新上下文的独立评审 agent 执行（主agent 不做语义自评，避免「产出者自己质检」）
3. 最终裁决：主agent 汇总两段结果，打回或写入（打回记录 experience）

> 「派发协议」（主体/视角/源文件/输出路径）见 engine/analyzer.md；「验收标准」见质量门断言清单 engine/quality-gate-assertions.md。

文件索引

regulation-engine/
├── SKILL.md                    ← 你在这里
├── engine/
│   ├── radar.md                ← 巡检流程（扫描数据源→去重→评分→Verify→推送→更新基线）
│   ├── analyzer.md             ← 分析流程（七步 + 反思）
│   ├── library.md              ← 建库流程（索引页、registry.json、生命周期状态机、月度巡检）
│   ├── matrix.md               ← 维度切片流程（打标 + 质疑轮 + 索引页生成 + 维度删除/归档/恢复）
│   ├── quality-gate.md         ← 统一质量门框架（skill 级通用机制）
│   ├── quality-gate-assertions.md ← 各模块断言清单（权威源派生）
│   ├── common-recover.md       ← 通用 Recover 路径定义
│   └── review-agent-protocol.md ← 第二道语义检查的可执行调度协议
├── templates/
│   ├── doc-A.md / doc-B.md / doc-C.md  ← A/B/C 三级分析模板
│   ├── framework-index.md      ← 法规体系索引页模板
│   ├── matrix-index.md         ← 合规要求索引页模板
│   ├── dimensions-import.md    ← 维度批量导入模板
│   └── radar-output.md         ← 巡检推送格式模板
├── guides/
│   ├── principles.md           ← 六大核心原则（含经验沉淀原则）
│   ├── classification.md       ← 分级标准 + 命名规范 + 分析维度说明
│   └── tools-notes.md          ← 平台操作备忘
├── experience/                 ← 经验沉淀
│   └── README.md               ← schema 说明（error-cases.jsonl / success-patterns.jsonl 运行时按需生成，不随包分发）
├── tracking/
│   └── README.md               ← 埋点方案
├── scripts/
│   ├── track.sh                ← 埋点上报脚本
│   ├── fetch_sources.py        ← 巡检数据源抓取脚本（radar 依赖）
│   ├── validate.py             ← 抓取结果 Verify 校验脚本（radar 依赖）
│   ├── release.sh              ← 干净发布打包脚本
│   └── gates/
│       ├── analyzer_gate.py    ← analyzer 模块机器硬门槛（结构断言，零 token）
│       ├── run_gate_tests.py   ← 断言脚本测试 runner（正例过/反例挂）
│       └── fixtures/           ← 断言测试夹具（正例 + 反例样本）
└── profiles/
    └── _template.md            ← 空白配置模板（用户建库时复制此文件创建自己的 profile）

埋点上报

埋点默认关闭，仅在用户显式开启后上报。开启方式：在 profile 中设 tracking: enabled。采集项：hostname、用户名、设备指纹（machine-id/MAC 的 md5）；发送目标：Beacon 平台（otheve.beacon.qq.com）。对外发布版本不启用。

在以下节点完成后，立即调用 scripts/track.sh 上报：

上报时机为"完成后立即"，不阻塞主流程。失败时静默忽略（不影响用户体验）。