regulatory-reg-feed-watcher · git:20260529.efece30 · 2026-05-29 · sha256 1f0592de521ed9f4
regulatory-reg-feed-watcher git:20260529.efece30A
Immutable. This exact content is served forever at /api/v1/blob/1f0592de521ed9f4.
---
name: regulatory-reg-feed-watcher
description: 现在核查监管信息源，报告自上次核查以来的新内容，按你的重要性阈值过滤。在用户说"查信息源"、"什么新内容"、"监管更新"时使用，定时巡检任务调用时使用，或用户手工粘贴一条监管动态做分类与比对时使用。
argument-hint: "[可选: --since 日期]"
---
# /reg-feed-watcher
1. 读 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` → 关注清单、重要性阈值、信息源配置
2. 用下面的工作流
3. 拉每个信息源。按重要性过滤
4. 输出：新内容，按重要性档分类
---
## 用途
拉信息源，按重要性过滤，输出留下的。**过滤本身就是价值** —— 未过滤的信息源就是噪音。
## 读取上下文
`$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` → 关注清单、重要性阈值、信息源配置、简报输出路径（如已设）。
`references/source-catalog.md`（本技能目录内）→ 各类信息源 RSS / JSON / HTML 源的整理目录（覆盖中央层级、地方层级、行业协会、二级来源等）。在配置新源或用户关注清单覆盖有缺时使用（见第 0 步）。
## 工作流
### 第 0 步：覆盖核查（拉之前）
跑拉取之前，对照 `references/source-catalog.md` 比较关注清单 + 信息源配置：
- 用户按关注清单关注哪些类别（中央监管 / 地方监管 / 行业协会 / 司法）？
- 哪些类别配置的源极少或没有？
如果有明显**信息源缺漏** —— 例如用户在关注清单写"网信办"但信息源配置里只有一个 `cac.gov.cn`，遗漏地方网信办、相关协会、最高院数据条线 —— 在简报顶部说一次：
> **信息源覆盖缺漏提醒**：你的关注清单包含 [类别]，但只配置了 [N] 个源。源目录列出本类别有 [X] 个选项（例如 [前 2-3 名]）。要我建议添加吗？跑 `regulatory-cold-start-interview --redo` 更新，或直接编辑 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md`。
**不要**对同一缺漏反复唠叨 —— 如果用户已明确说"地方监管暂时不管"，尊重。在 profile.md 里记录这个状态让它保留。
### 第 1 步：拉取
从所有配置的信息源档拉。**优先级从高到低**：
**第 1 级 —— 元典开放平台 MCP（首选）**
`mcp__yuandian-law__*` 工具按上次核查日期查询新法规 + 案例 + 行政处罚，过滤关注清单监管。
**为什么这是第 1 级**：
- 已结构化数据（标题、文号、发布机关、生效日期等字段化）
- 覆盖中央层级法律 / 行政法规 / 部门规章 / 司法解释 / 指导性案例 / 行政处罚
- 引用核验有据 —— 元典直接对应一手出处
- 站点改版不影响（API 稳定）
**若元典 MCP 不可用**（未配置 API key、调用失败）：在简报顶部明确说"元典 MCP 不可用，本次降级到栏目页 + 网页检索"，**不要静默降级**。
**第 2 级 —— 栏目页轮询（主力方案，覆盖元典未覆盖的源）**
对 `profile.md` 中 `## 信息源配置` 标 `栏目页` 类型的源：
**轮询前 URL 时效检查**：
- 读配置中的 `验证日期` 和 `状态` 字段
- 若状态为 `❌ 待补`：跳过轮询，在简报底部注："[监管] 栏目页状态为待补，未执行轮询。跑 `regulatory-cold-start-interview --redo` 重新搜索验证有效 URL。"
- 若验证日期为空或超过 **90 天**：先尝试浏览器访问验证 URL 仍可达；如不可达，执行一次联网搜索重新确认当前有效 URL，更新配置后再轮询。在简报中注："[监管] 栏目页 URL 已超过 90 天未验证，执行重新验证..."
**轮询步骤**：
1. **抓取栏目页**：优先用 **playwright MCP**（`mcp__playwright__browser_navigate` + `browser_snapshot`），因为多数政务网站是单页应用，`WebFetch` 拿到的只是页面壳。`WebFetch` 仅在确认目标是纯静态 HTML 时用
2. **提取列表项**：从页面抓 `[标题, 链接, 发布日期]`
3. **指纹对比**：读 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/feed-cache/<source-id>.json`（记录上次见过的 URL 集合），对比识别新增
4. **更新指纹**：把本次见到的全部 URL 写回 `<source-id>.json`
5. **输出新增**：仅把新增项进第 2 步分类
指纹文件结构：
```json
{
"source_id": "cac-zcfg",
"source_url": "https://www.cac.gov.cn/zcfg/index.htm",
"last_pulled_at": "2026-05-18T09:00:00Z",
"seen_urls": [
{"url": "https://...", "title": "...", "first_seen": "2026-05-11"}
]
}
```
**栏目页参考清单**：见 `references/source-urls.md`，列了历史上曾测试可达的栏目页入口。**仅作搜索验证的起点**，不直接用于轮询。
**第 3 级 —— 官方 RSS（少见，遇到再用）**
`profile.md` 中标 `RSS` 类型的源 → `WebFetch` 拉 XML，解析后做指纹对比（同栏目页机制）。中央监管基本无官方 RSS；偶见行业自律协会、地方部门有。
**第 4 级 —— 通用网页搜索（兜底，标 `[需核验]`）**
第 1-3 级对某个监管返回很少或无结果，且用户授权时，可用 `WebSearch` / `WebFetch` 通用网页搜索补充。**所有第 4 级结果必须标 `[网页检索 — 需核验]`**，依赖前必须对照一手出处核对。
**第 5 级 —— 手工录入**
用户粘贴监管文本或摘要（而非从定时信息源核查调用）：把粘贴内容当作单条项，跳到第 2 步分类，记录来源为"手工录入"。**不需要信息源拉取**。这条路径不论订阅状态都能用。
**对公众号源**：本版本走人工录入。用户可批量粘贴公众号文章 / 链接到本技能。每条自动标 `[二级来源 — 公众号]`，强制要求用户在依赖前核对到一手出处。**不允许**仅凭公众号源升到"重点跟踪"。
跨档去重 —— 同一份文件可能在多个级别出现。在加深度输出中优先用最丰富的源（一般是第 1 级元典）。
**不擅自补充**：如果信息源拉取对关注清单某个监管返回很少或无结果，报告拉到的内容并停下来。**不要**默默从公网搜索或模型知识补缺漏，除非问过。说："信息源核查从 [拉到的监管] 返回 [N] 项。[监管 / 话题] 覆盖看起来偏薄。选项：（1）放宽日期窗口、（2）试不同信息源或 MCP、（3）公网搜索 —— 结果会标 `[网页检索 — 需核验]`，依赖前应对照发布机关网站核验、（4）就此停下。要哪个？"律师 / 法务决定是否接受低信度源；技能不替他们决定。
**来源归因**：给每个引用和监管项打标，标明它来自哪里 —— `[国家法律法规数据库]`、`[政府网/政策文件库]`、`[部委公开栏目]`、`[元典法规]`、`[元典案例]`、`[最高院司法解释]`、`[指导性案例]`、`[协会自律规则]`，对通过集成取得的项用具体的 MCP 工具名；对公网搜索结果用 `[网页检索 — 需核验]`；对模型训练数据呈现的用 `[模型知识 — 需核验]`；对手工粘贴的用 `[用户提供]`。标"需核验"的条目造假风险高于工具检索的项，应先核。**绝不**剥离或合并标签 —— 它们是用户对哪些引用先核验的最快信号。
**二级来源**：部分目录条目（公众号转述、律所提醒、聚合服务）报告一手监管动态但不是一手出处。从这些源拉的项**额外**标 `[二级来源 — 公众号]` / `[二级来源 — 律所/律师邮件]` / `[二级来源 — 聚合源]`（除了源名标签），并附"→ 请到 [一手出处名称] 核对"。**不要**仅凭二级来源把项归为"始终重要"档 —— 在找到一手出处前**降一档**。
拉完后记核查时间戳。下次定时核查从这里向前拉。
### 第 2 步：分类
每条项按 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` 拿重要性档：
| 项类型 | 对照阈值 |
|---|---|
| 法律（人大及其常委会通过） | 始终"始终重要" |
| 行政法规（国务院制定） | 始终"始终重要" |
| 国务院政策文件 / 部委联合规范性文件（新增） | 通常"始终重要" |
| 正式部门规章（部务会议通过 + 首长签署 + 命令公布 三要件齐备） | 通常"始终重要" |
| 部门规章征求意见稿 | 通常"值得复核" —— 并**始终**登记评议截止日 |
| 规范性文件（单部委发布的"通知 / 办法 / 指引"，不符合部门规章三要件） | 通常"值得复核" |
| 最高院司法解释 | 通常"始终重要"（**有法律约束力，作裁判依据**） |
| 指导性案例 | 通常"值得复核"（**作裁判理由，不作裁判依据**；不可作政策硬整改触发） |
| 行政处罚通报（行政事实行为） | 同业 → 重要（事实信号档）；非同业但相同业务 → 值得复核；其他 → 速览或跳过 |
| 数据合规专项（新增）—— 数据出境 / 个保审计 / 算法 / 生成式 AI 备案 | 通常"始终重要"（2024-2026 最活跃监管领域） |
| 监管评级 / 分类监管文件（新增） | 通常"始终重要"（直接影响监管对待） |
| 国家 / 团体标准（新增）—— GB/T 信安 / 个保 / 行业团体标准 | 通常"值得复核"（推荐性标准）；强制性标准 → "始终重要" |
| 答记者问 / 监管讲话 | 通常"值得复核" —— **强制**标 `[非正式监管口径 — 无法律约束力 / 具实际执法导向 / 建议跟踪]` |
| 监管窗口指导 / 约谈通报 | 通常"值得复核" —— **强制**标 `[非正式监管口径 — 无法律约束力 / 具实际执法导向 / 建议跟踪]`；通过协会转述时同时标 `[协会自律规则]` |
| 行业自律新规 | 通常"值得复核" |
| 行业自查通知 / 专项整改 | **始终重要** —— 这会触发被动监管接触工作流（`regulatory-incoming-letter`（监管来函处置）技能，阶段 3 启用） |
| 行政指导 / 监管意见书 | "始终重要"或"值得复核"按发布对象 |
| 监管谈话 / 约谈 | "始终重要"（要求负责人到场） |
**部门规章 vs 规范性文件机械判别（三要件，依据《规章制定程序条例》国务院令第 322 号）**：
- ① 由部务会议通过（决策程序）
- ② 由首长签署（如部长令）
- ③ 以"令"的形式公布（发布形式）
三要件齐备 = 部门规章；任一要件缺失 = 规范性文件。本技能在分类时优先按此三要件机械判别。
**对中国监管特有的"非正式"层（答记者问、窗口指导、约谈通报）**：技能**强制**额外标 `[非正式监管口径 — 无法律约束力 / 具实际执法导向 / 建议跟踪]`。**不允许**默认把它们当成硬约束。可以做"立即提醒"的特殊处理（如果用户重要性阈值配置了），但分类必须明确是非正式口径，不是现行义务。
**司法解释 vs 指导性案例的处置差异**：
- 司法解释：**有法律约束力，作裁判依据**；可触发 `regulatory-policy-diff`（政策比对）+ 内规差异整改
- 指导性案例：**作裁判理由，不作裁判依据**；**不应**触发政策比对强对照；建议作为"裁判趋势参考"加入观察清单
**对征求意见稿的评议截止日处理**：
对每条征求意见稿（不论档位"跳过"以上）：
- 提取评议截止日（部委公开栏目通常作为结构化数据返回；如果是 PDF / 公告页，从文本中抓取）
- 如果 `profile.md` 中评议跟踪启用：附加到 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/comment-tracker.yaml`，状态"未决"，负责人取 `profile.md` 中默认评议决策负责人
- 在输出条目中包含评议截止日
**对涉及自查通知 / 专项整改工作函**：
这是被动监管接触的入口。本阶段（阶段 1）监管动态监测把它分类并呈现在简报顶部，附建议："→ 这条要求公司响应。阶段 3 的 `regulatory-incoming-letter`（监管来函处置）技能将处理完整工作流。当前请通过常规渠道（合规风评会、法务总监会签）组织响应。"
### 第 3 步：加深度
对每条速览以上档：
- 一句话摘要（什么变了）
- 为什么这事可能在这里重要（关联点 —— "这是关于 [你做的某个业务]"）
- 一手出处链接
- 生效日期或评议截止日（如适用）
**不要**对速览项逐条加深度 —— 只数。
## 输出
简报默认进对话窗口。**同时写入可分享的文件**，每当输出含一个或多个速览以上项目，除非用户 `profile.md` 明确设 `简报输出 → 仅对话窗口`。
**文件输出行为**：
1. 查 `profile.md` 的 `简报输出路径`。如已设，写那里。未设默认：`${HOME}/regulatory-legal-digests/reg-digest-YYYY-MM-DD.md`
2. 按需创建父目录
3. 写完整简报为 Markdown（同对话窗口输出，包括工作秘密标识、源标签、核验脚注）
4. 同日已有文件就追加加时间戳子标题的新节，不要覆盖 —— 同日可能多次跑（早间简报、临时核查）
5. 写完告诉用户："简报写到 `<path>`。可以直接分享，或用 Pandoc 转 .docx：`pandoc <path> -o <path>.docx`。"
6. 如果写失败（权限、用户没授权创建的目录、磁盘满），降级到仅对话窗口输出并说出来 —— 不要默默丢掉文件请求
文件格式与对话窗口格式完全一致（下方）。Markdown 在 GitHub、Notion、Obsidian、飞书文档（通过"导入 Markdown"）、腾讯文档、多数邮件客户端中渲染良好。
```markdown
[工作秘密标识 —— 按 ## 谁在用这个插件 + shared/header-by-role.md 选定]
## 监管信息源核查 —— [日期]
**周期**：[上次核查] 至 [现在]
**已核查源**：[列出活跃档 —— 例如"国家法律法规数据库、央行公开栏目、金管总局公开栏目、元典开放平台"]
**总计**：[N] 项
### 核心结论
[N 个内规差异在 [日期] 前需要行动 —— 前 3：X、Y、Z]
### 🔴 重点跟踪
> **分类档→显示档映射**：profile.md 中的 `始终重要` 档 → 简报显示为 `🔴 重点跟踪`（中文表述更自然，分类逻辑不变）
**[监管] —— [标题]**
[一句话摘要]。[关联点]。生效 [日期]。
[链接]
→ 建议：跑 `regulatory-policy-diff`（政策比对）对 [可能受影响的政策]
[每条重复]
### 🟡 值得复核
**[监管] —— [标题]**
[一句话]。[关联]。[截止日，如有]。
[链接]
[征求意见稿：加 "💬 评议截止日：[日期] —— 决策未定"如果评议跟踪启用]
[重复]
### 📝 速览
[N] 项 —— [可展开的标题 + 链接清单，无摘要]
---
**上次核查更新到**：[时间戳]
**评议台账**：[N] 个征求意见稿评议决策开放 —— 跑 `regulatory-comments`（评议管理）复核
---
**依赖前请核验引用**。本处监管引用由 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` 或改 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` 调整。"
- **信息源配置空**：只跑国家法律法规数据库 + 政府网，附："本输出只用了公开网页源，因为你的配置没列直接 RSS 或付费源。用 `regulatory-cold-start-interview --redo` 或改 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md` 加信息源。"
相关值已填写时**不说**关于配置的事。
如果速览以上无内容："全部安静。[N] 条速览项，无需关注。"
## 移交
- **给 `regulatory-policy-diff`（政策比对）**：任何"始终重要"档（简报显示为"重点跟踪"）项带可能政策影响 → 提议跑比对
- **给 `regulatory-gap-surfacer`（内规差异呈现）**：比对找到内规差异 → 跟踪
- **给评议台账（`comment-tracker.yaml`）**：任何征求意见稿分类在"跳过"以上 → 评议截止日自动登记（如跟踪启用）
- **给 `regulatory-incoming-letter`（监管来函处置，阶段 3 启用后）**：任何"自查通知 / 专项整改工作函"识别为被动监管接触入口 → 提议跑该技能
## 收尾决策树
按 `profile.md` 中 `## 输出` 的决策树收尾。把选项定制给本技能这次产出的内容 —— 五个默认分支（起草 X、上报、补充事实、观察等待、其他）是起点，不是锁死。决策树本身就是输出；律师 / 法务挑。
## 本技能不做的事
- 完整读每一项。它分类和加深度；深度阅读留给过了过滤的项
- 改重要性阈值。过滤不对就改 `$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md`
- 强制要求元典开放平台。公开网页源是基线；商业源加深度
- 自动抓取公众号。本版本走人工录入路径