Policy Mapping｜政策产品雷达
> 把政策变化，变成产品变化。
> From Policy Change to Product Change.
不是告诉你“出了什么政策”，而是告诉你“这项政策会让什么产品发生什么变化”。
1｜这个 Skill 是什么
Policy Mapping 是一个面向产品经理、创业者、企业战略、运营、技术和合规团队的中国政策产品映射 Skill。
它用于持续发现中央、国家部委、全国监管机构及地方政府发布的政策、法规、办法、通知、征求意见稿和实施细则，并将政策从“信息”继续向下映射为：
政策 → 规则变化 → 影响行业 → 影响企业 → 企业动作 → 产品能力 → 产品功能 → 技术 / 运营改造
最终目标不是生成一篇篇冗长的政策摘要，而是形成可以直接用于产品规划、需求发现、合规改造、技术评估、运营调整和机会判断的「政策产品雷达」。
2｜它的逻辑是什么？与普通政策 / 热点抓取 Skill 有什么不同？
普通政策 / 热点工具
发现政策
↓
抓取政策
↓
总结政策
↓
分类 / 打标签
↓
输出政策新闻
主要回答：最近发生了什么？
Policy Mapping
发现政策
↓
识别政策生命周期
↓
识别 Policy Event Chain
↓
提取规则变化
↓
判断影响行业
↓
判断影响企业
↓
推导企业动作
↓
映射产品 / 系统
↓
映射具体功能
↓
映射 API / 数据 / 算法 / IoT / 运营
↓
判断 P0 / P1 / P2 / P3
↓
形成产品变化雷达
继续回答：这项政策会让哪些产品发生什么变化，我们应该关注或改什么？
> Most policy tools stop at “What happened?”
> Policy Mapping continues to “What should the product change?”
五个核心能力
- 全国政策雷达：中央、国家部委、全国监管机构，并支持 31 个省级行政区。
- Policy Event Chain：把征求意见→正式发布→生效→配套办法→实施细则→执法串成事件链，而不是孤立新闻。
- Policy → Product Mapping：政策→规则→行业→企业→系统→产品→功能→研发→运营→时间。
- Evidence Boundary：严格区分 FACT、INFERENCE、PRODUCT_SUGGESTION，AI 建议不得冒充政策要求。
- L1 → L2 → L3 数据下钻：L1 看政策、L2 看产品影响、L3 看具体功能/系统改造；L3 默认只展开全部 P0 + P1★/P2★，最多 10 条。
3｜怎么用
3.1 第一次使用：全国政策扫描
使用 Policy Mapping，扫描最近 7 天全国政策，
输出 L1→L2→L3 政策产品雷达。
首次使用且没有足够用户上下文时自动进入 Generic Mode：不显示 ★，不猜测用户行业，也不默认任何行业偏好。
3.2 带自己的行业 / 岗位 / 项目使用
我是跨境电商产品经理，重点关注支付、税务、物流和平台合规。
使用 Policy Mapping 扫描最近 30 天政策，
告诉我哪些政策可能影响我的产品。
有明确上下文后才进入 Personalized Mode，允许根据真实用户上下文标记 ★ 高度相关政策。
3.3 分析单条政策
使用 Policy Mapping 分析这条政策：《XXXX管理办法》。
告诉我政府改变了什么规则、哪些行业和企业受影响，
以及 APP / 后台 / API / 数据 / 算法 / IoT / 运营分别可能改什么。
严格区分政策事实、企业推导和产品建议。
3.4 每小时政策产品雷达
Skill 是大脑，不是闹钟。
需要由 GitHub Actions、Cron 或其他 Scheduler 定时触发。抓取异常必须输出 MONITOR_ERROR 或 PARTIAL_ERROR，绝不能把“网站抓取失败”误报成 NO_CHANGE。
执行规范
L1｜政策雷达总览
字段：编号｜日期｜政策名称｜发文部门｜涉及行业｜政策影响主题｜为什么重要
- L1 不显示 P0/P1/P2/P3。
- 政策名称必须绑定经过核验的官方来源。
- Markdown：
[政策名称](官方URL)。 - DOCX：真实 hyperlink relationship。
- HTML：
<a href="官方URL">政策名称</a>。 - 禁止裸 URL。
- 找不到可靠官方原文时标“来源待核”，不得虚构链接。
L2｜政策 × 产品映射总表
字段：编号｜优先级｜政策｜涉及行业｜影响对象｜产品变化方向｜一句话产品影响｜相关度
- 优先级只从 L2 出现。
- 编号与 L1 一致。
- “一句话产品影响”必须是产品/系统/技术/流程/运营动作。
- 严禁日期、发文机构、生效时间等字段错位。
优先级说明：P0＝已生效/临近生效且存在明确产品或合规改造需求；P1＝政策方向和产品影响较明确，建议进入近期 Roadmap；P2＝存在明确产品机会或潜在影响，建议规划储备；P3＝暂未形成明确产品动作，持续跟踪。
★ Personalized Relevance
★ = Policy × Current User Context
只有当前执行环境明确获得用户的行业、岗位、当前产品、当前项目或明确关注方向时，才允许启用 ★。
Personalized Mode
有足够上下文时允许在 L2 显示 ★，并可显示：★ 高度相关：根据当前用户关注的「X」动态识别。
Generic Mode
首次使用、无上下文或上下文不足时：
- 完全不显示 ★；
- 不显示任何“与你高度相关”的特定行业说明；
- 不猜用户行业；
- 不继承 Skill 作者历史上下文；
- 不从 README、Benchmark、示例推断偏好。
L3｜重点政策产品变化明细
只展开：全部 P0 + ★P1 + ★P2；最多 10 条。
本部分仅下钻展示：全部 P0，以及 ★ 与当前用户高度相关的 P1/P2；默认最多展示 10 条。其余政策仅保留在第二部分产品映射总表中，不重复展开。
卡片结构：编号｜优先级★｜《政策名称》 + 规则变化 + 影响对象 + 产品变化矩阵 + 时间节点。
三层证据边界
FACT：政策事实。INFERENCE：企业动作推导。PRODUCT_SUGGESTION：AI 产品建议。
AI 产品建议不得冒充政策强制要求。
Evidence Renderer｜跨格式证据标签
原则：颜色负责快速识别，文字负责保证语义永不丢失。
Markdown
- 🔵 F｜政策事实
- 🟡 I｜企业推导
- 🔴 PS｜产品建议
HTML
使用 CSS Badge + F/I/PS + 中文。
DOCX / Word
禁止依赖彩色 Emoji。必须使用 Word 原生底纹，同时显示：
- F｜政策事实
- I｜企业推导
- PS｜产品建议
TXT / 其他纯文本
[F] 政策事实[I] 企业推导[PS] 产品建议
全国化
默认中央/国家部委/全国监管机构 + 支持 31 省级行政区。北京只是普通地方来源和 Benchmark 之一，不特殊优先。
政策生命周期与 Policy Event Chain
识别 DRAFT → PUBLISHED → EFFECTIVE → SUPPORTING → ENFORCEMENT，并识别 AMENDED / REPEALED。同一事件链没有新增义务、范围、时间、处罚、数据字段、技术标准或执行口径时，不重复触发完整预警。
Token 漏斗
发现 → 标准化 → 去重 → FAST_RELEVANCE → Policy Event Chain → P0-P3 → DEEP_MAP → L1/L2/L3。禁止每条抓取内容都生成长报告。
定时状态
最终状态：CHANGES / NO_CHANGE / MONITOR_ERROR / PARTIAL_ERROR。抓取失败绝不能误报 NO_CHANGE。
验收
- L1 无优先级；有官方来源的政策名可点击；无裸 URL；随机抽查至少 3 条链接与标题匹配。
- L2 编号与 L1 一致；一句话产品影响不是日期/机构；★ 只基于真实上下文。
- L3 只含全部 P0 + ★P1 + ★P2；≤10 条；编号与 L1/L2 一致；证据边界正确。
