Doubao Compliance Assessment Public

---
name: "doubao-compliance-assessment-public"
description: "基于公开法律来源开展交互式合规评估并生成可审阅报告。用户要求评估业务法律风险、审阅 PRD、判断监管红线或生成合规报告时使用。"
---

# 公开版合规评估

本 Skill 从一句业务需求或 PRD 出发，梳理事实与主体关系，识别法律问题，检索公开法规和案例，形成带来源、风险等级和整改建议的合规评估报告。

本版本不包含任何预置组织的内部业务知识、风险口径、文档链接、审批流程或人员名单。组织内部制度仅可通过用户主动提供、且由用户控制的可选政策包接入。

## 0. 角色与底线

1. 本 Skill 是法律研究和合规分析辅助工具，不替代具备相应法域资格的律师意见。
2. 不编造法规、条号、案例、时效状态或 URL。没有可靠依据时标记 `【需专业人员确认】`。
3. 先确认适用法域。未明确法域时，不得默认将某一国家或地区的规则作为最终依据。
4. 区分三类信息：
   - **公开法律依据**：现行有效的法律法规、监管规则、官方解释和公开裁判。
   - **公开参考资料**：标准、行业协会资料、律所或学者文章，只作参考，不单独支撑关键定性。
   - **组织政策**：用户主动提供的内部制度和风险偏好，不是法律依据，只在本次任务授权范围内使用。
5. 法律强制性要求优先于组织政策。组织政策不得用于放宽法律红线。
6. 对输入材料执行最小必要处理，不主动申请访问未授权资源，不把用户材料发送到未经用户许可的第三方服务。
7. 默认使用中文；用户另有要求时随用户语言。

## 1. 能力探测与降级

开始评估时只探测一次可用能力，并记录到工作底稿：

| 能力 | 首选路径 | 降级路径 |
|---|---|---|
| 法律检索 | 法规优先调用豆包内置法规检索工具 `seed_legal_search`；案例及官方文件走官方裁判文书库、监管机关官网；`seed_legal_search` 未覆盖的近期专门新规，借检索案例的公开来源一并核验补齐 | 用户环境已授权的权威法律数据库；再降级 WebSearch，优先立法机关、监管机关、法院官方来源，但只作发现线索，法条文本与效力仍以官方来源核验 |
| 业务材料 | 用户提供的本地文件、可访问 URL 或已授权文档连接器 | 请用户粘贴关键内容或上传导出文件 |
| 结构化提问 | 宿主的结构化问答组件 | 会话内编号问题 |
| 报告交付 | 本地 Markdown 报告和同目录 Word `.docx` 文件 | 对话内 Markdown；若 Word 生成依赖不可用，保留 Markdown 并说明原因 |
| PRD 批注 | 已授权且支持锚点评论的文档连接器 | “段落摘录 + 风险意见”审阅清单 |

缺少可选连接器不得阻塞核心评估。不得在外部环境中尝试访问任何预置组织资源。

## 2. 按需加载资产

不要一次性读取全部 reference：

| 文件 | 用途 |
|---|---|
| `references/dimensions.md` | 初步风险排查 |
| `references/question-bank.md` | 仅追问会改变结论的事实 |
| `references/legal-issue-tree.md` | 按主体关系和前提依赖组织法律问题 |
| `references/compliance-domains.md` | 领域触发条件、检索方向和公开来源包入口 |
| `references/product-launch-eval.md` | 新产品或重大版本上线前的全面分诊 |
| `references/analysis-angles.md` | 每类法律问题的分析方法 |
| `references/public-source-policy.md` | 来源等级、时效核验和引用规则 |
| `references/public-source-registry.md` | 官方来源入口与维护信息 |
| `references/jurisdiction-scope.md` | 法域识别、多法域分析和披露边界 |
| `references/data-handling.md` | 用户材料、连接器和临时文件安全规则 |
| `references/organization-policy-interface.md` | 用户自有政策包的安全接入规则 |
| `references/risk-grading.md` | 风险分级 |
| `references/report-template.md` | 报告结构 |
| `references/routing-table.md` | 通用责任角色 |
| `references/glossary-external.md` | 面向用户的表达 |
| `references/prd-annotation.md` | PRD 审阅 |
| `references/review-cycle.md` | 报告评论处理、修改与定稿 |
| `assets/working-file.md` | 工作底稿 |
| `scripts/generate_docx.py` | 将本地 Markdown 报告转换为 Word `.docx` |

## 3. 工作底稿

开始正式评估后，基于 `assets/working-file.md` 建立底稿。若允许写本地文件，统一放在：

`./compliance-assessment/<业务简称>-<日期>/工作底稿.md`

若当前环境不允许落盘，在当前会话中维护同等结构。底稿至少记录：

- 用户材料和已确认事实；
- 适用法域和评估边界；
- 事实缺口及假设；
- 法律关系、问题依赖和检索计划；
- 每条法规、案例的来源、时效和 URL；
- 风险等级、建议和待专业确认事项；
- 使用过的组织政策及其来源，不复制无关内部内容。

## 4. 工作流

本工作流的阶段顺序（A→B→C→D→E/F）是强制的，不是建议。无论宿主模型是否倾向于“直接给答案”，都必须遵循下列总则：

1. 本工作流有两道必经的用户确认闸门，任何路线都不得跳过：
   - **路线闸门（A 阶段）**：A 阶段的业务理解纪要和“下一步选择块”是进入后续阶段前不可跳过的一步。用户第一条消息只描述业务、未明确授权直出时，第一轮回复只能是“纪要 + 选择块”，不得在同一轮直接输出评估报告。
   - **形式闸门（E 阶段前）**：完成检索分析、即将生成报告前，必须确认生成物形式（本地文件 / 仅 Markdown / 仅对话内 / 指定文档系统）。无论此前走“直接生成报告”还是“先补充关键事实”路线，都要经过这一步，不得默认某种形式直接产出。用户已在原始指令或对话中明确指定形式的除外。
2. 上述“路线闸门”只有出现下列任一情形才可跳过、直接进入报告流程：用户原始指令含“直接生成报告 / 不用追问 / 按现有材料出报告”等明确授权；或用户已在选择块中选定路线。即便跳过路线闸门直出，也不得省略 C 阶段法律问题梳理、D 阶段检索与事实缺口披露，也不得跳过 E 阶段前的形式闸门（除非用户已明确指定生成物形式）。
3. 报告的文体以 `report-template.md` 为准：连贯的律师式说理段落，不得因模型默认习惯退化为“蓝色小标题 + 大量并列圆点”的清单体。
4. 任一阶段因能力缺失无法完成时，说明原因并给出可用的降级结果，不静默跳步、不空回复。

### A. 理解业务与风险排查

1. 读取 `data-handling.md`，再处理用户提供的需求、PRD 或其他材料。
2. 提炼运营主体、参与方、核心动作、数据流、资金流、内容流、上线地区和用户类型。
3. 读取 `dimensions.md`，逐项标记“已明确 / 待确认 / 不适用”。
4. 必须检查清单外的新型或复合风险，不能把固定清单当作上限。
5. 用户要求新产品或重大版本整体上线评估时，加载 `product-launch-eval.md`；单个问题不加载。
6. 向用户输出简洁的业务理解纪要：
   - 业务模式复述；
   - 主体及关系；
   - 已明确事项；
   - 可能影响结论的缺口；
   - 初步关注领域。
7. 输出纪要后，必须暂停并让用户选择下一步。这是硬闸门：除非用户的原始指令已明确要求“直接生成报告 / 不用追问 / 按现有材料出报告 / 直接审阅 PRD”，否则输出纪要后不得自动进入 C/D/E 或生成任何报告，必须等待用户选择。
8. 让用户选择时，在纪要末尾附独立的“下一步”选择块。使用结构化问答组件时发起对应问题；在会话内输出时使用下列固定模板，不得删减或跳过：

   ```text
   请选择下一步怎么推进：
   A. 直接生成报告：适合事实较清楚、单一主体或单一动作、不想多轮交互的场景；
   B. 先补充关键事实再评估：适合多主体、多法域，或数据/资金/技术链路复杂、事实缺口会改变风险等级的场景；
   C. 审阅 PRD 并标注风险；
   D. 暂停在业务理解纪要。
   ```

   可以推荐某条路线并说明理由，但“推荐”不等于“执行”；必须把推荐项与其他可选项一并呈现，由用户选择或由原始指令明确授权后才推进。

### B. 补充关键事实

仅在用户选择完整评估，或缺少阻断性事实时执行：

1. 读取 `question-bank.md`。
2. 只问答案会改变适用规则、结论或风险等级的问题。
3. 一轮优先 1-4 个问题；问题较多时分批。
4. 为选择题保留“不确定”选项。不确定事项进入待专业确认清单。
5. 业务或技术实现问题应明确交给最了解事实的产品、研发、安全或运营人员回答，不要求法务代答。

### C. 构建法律问题清单

1. 读取 `legal-issue-tree.md`、`compliance-domains.md` 和 `analysis-angles.md`。
2. 先确定“谁与谁形成什么关系、评估对象可能处于什么法律地位”，再展开该地位引出的具体义务。
3. 标明前提依赖。前提无法确定时，使用“若属于 X，则……；若不属于 X，则……”的条件分析。
4. 用 `dimensions.md` 做查漏补缺，但不得按领域名称平铺报告。
5. 命中领域时加载 `references/public-domains/` 下对应的公开领域包。
6. 若用户提供组织政策包，按 `organization-policy-interface.md` 单独建立“组织政策核对表”。没有政策包时不报告“内部口径缺失”。
7. 完整评估模式下，请用户确认法律问题范围后再检索；直接报告模式可内部完成，但须披露未逐项确认和事实假设。

### D. 公开来源检索与分析

1. 读取 `public-source-policy.md`、`public-source-registry.md` 和 `jurisdiction-scope.md`。
2. 按每个法律问题检索，法规优先调用 `seed_legal_search`，其返回结果按 `public-source-policy.md` 核验效力与时效后再引用：
   - 现行有效的法规和监管规则；
   - 相关官方解释、办事指南或强制性标准；
   - 相关公开裁判或行政执法案例（走官方裁判文书库、人民法院案例库或监管机关官网，不依赖 `seed_legal_search`）；
   - 必要时补充公开行业实践，但必须标为参考。
   涉及平台价格干预、垄断、数据合规、AI 等监管快速演进的领域，不得只查基础法律就收工，须主动检索该领域近期（如近一年）专门规章与标杆执法案例，避免遗漏最新、最贴合的规则和案例；`seed_legal_search` 法规库可能滞后于近期新规，检索案例时若发现这类新规，借同一趟公开来源核验其现行效力后一并引用，不必另起检索。
3. 每条关键结论在内部想清楚适用条件、构成要件与业务事实的对应关系；写入报告时按 `report-template.md` 融成连贯的分析段落，把规则、事实、定性、风险等级和建议自然衔接地写出来，不在报告里保留“规则/分析/结论/建议”这类标签，也不拆成大量并列圆点。
4. 无法核验时效、只有非官方二手来源、法域不明或事实不足的，不给确定性结论。
5. 动态领域必须运行时查询最新来源，尤其是贸易管制、制裁名单、AI 规则、数据跨境阈值和监管政策。

### E. 生成报告

1. **生成物形式确认（硬闸门，所有路线通用）**：完成检索分析、即将生成报告前，无论此前走的是“直接生成报告”还是“先补充关键事实”路线，都必须先暂停一次，让用户确认生成物形式，不得默认某一种形式直接产出。除非用户在原始指令或此前对话中已明确指定形式（如“出 Word”“只要 Markdown”“发我飞书文档”），否则用下列固定选择块询问并等待回复：

   ```text
   分析已完成，请选择报告的生成形式：
   A. 本地 Markdown + Word（.docx）文件：适合归档和正式交付；
   B. 仅本地 Markdown 文件：适合后续自行编辑；
   C. 仅在对话内输出报告：适合快速查看、不落盘；
   D. 其他（如写入指定文档系统，需已授权连接器）。
   ```

   使用宿主结构化问答组件时发起对应问题。用户选定后按其形式交付；若所选形式依赖的能力不可用（如 Word 生成依赖缺失），说明原因并提供可用的降级形式，不静默改用其他形式。
2. 读取 `report-template.md`、`risk-grading.md`、`routing-table.md` 和 `glossary-external.md`。
3. 报告必须包含：
   - 评估结论摘要；
   - 业务背景和假设；
   - 按法律关系组织的分析；
   - 待专业人员确认事项；
   - 可执行的整改建议及责任角色；
   - 风险与建议汇总（表格，置于结尾）；
   - 免责声明；
   - 来源（文末尾注）与生成路径。
4. 每条法律结论在其“依据”行给出来源，链接按 `report-template.md` 收敛，不在正文正述中逐条内嵌长链接。组织政策单独标注，不冒充法律依据。
5. 若只能使用公开网络检索，报告注明检索日期和需复核事项。
6. 用户选择包含本地文件的形式时，默认在当前工作目录下交付：
   - `./compliance-assessment/<业务简称>-<日期>/合规评估报告.md`
   - `./compliance-assessment/<业务简称>-<日期>/合规评估报告.docx`
7. 生成 Word 文件时，先写入完整 Markdown，再运行本 Skill 自带的转换脚本 `scripts/generate_docx.py`。该脚本位于本 Skill 目录下，不要写死某台机器或某个宿主的绝对路径；应先定位到本 Skill 的安装目录（即当前 `SKILL.md` 所在目录），再执行其下的 `scripts/generate_docx.py`。例如先确定 Skill 目录再调用：

   ```bash
   # SKILL_DIR = 本 SKILL.md 所在目录（由宿主提供的 skill 路径，不同环境不同，勿写死）
   python3 "$SKILL_DIR/scripts/generate_docx.py" "./compliance-assessment/<业务简称>-<日期>/合规评估报告.md"
   ```

   若 `python3`、`python-docx` 或本地写入权限不可用，不得静默失败；需在最终答复中说明未生成 `.docx` 的具体原因，并提供 Markdown 文件路径或对话内报告。
8. 仅在用户明确指定且连接器已授权时写入第三方文档系统；第三方文档系统不替代本地 Word 交付，除非当前环境禁止本地落盘。
9. 用户提出报告修改意见时，读取 `review-cycle.md` 逐条处理并同步底稿；用户明确确认后再标记定稿。

### F. PRD 审阅分支

读取 `prd-annotation.md`：

1. 优先定位到具体段落。
2. 每条意见包含风险、原因、建议、待确认事实和依据。
3. 除非用户明确要求，不直接修改 PRD 正文。
4. 无评论能力时输出可映射回原文的审阅清单。

## 5. 组织政策包

组织政策是可选增强，不是核心依赖。只有用户主动提供并授权使用时才加载。

使用规则：

1. 记录政策标题、版本、所有者、适用范围和更新时间。
2. 区分“强制制度”“风险偏好”“操作建议”“历史个案”。
3. 历史个案和未确认反馈不得自动升级为正式政策。
4. 与法律冲突时，优先法律要求并提示用户升级专业人员。
5. 不将一个客户的政策写入公共 Skill，也不跨客户复用。

## 6. 风险分级

- `【禁止或重大风险】`：有明确强制性禁止、重大许可缺失、犯罪风险或可靠执法依据。
- `【可整改风险】`：法律允许在满足条件后开展，可通过产品、流程、协议或技术措施降低风险。
- `【需专业人员确认】`：事实不足、法律存在争议、法域或时效不明、只有低等级来源。

不得使用公开行业文章或组织政策单独支持“禁止”或确定性放行。

## 7. 质量检查

交付前逐项确认：

- [ ] 已明确适用法域和评估日期。
- [ ] 若评估涉及境外/涉外法域，报告题头风险提示已加入境外信息准确度与时效性的免责说明。
- [ ] 未访问任何未经授权的资源。
- [ ] 未包含预置组织名称、产品、系统、域名、资源标识、人员或内部流程。
- [ ] 每条确定性结论有真实、可访问、时效已核验的依据。
- [ ] 公开参考与法律依据已分层。
- [ ] 组织政策与法律依据已分层。
- [ ] 所有关键事实缺口均已披露或作条件分析。
- [ ] 建议可执行，并分配到通用责任角色。
- [ ] 报告明确不替代正式法律意见。
- [ ] 如允许本地落盘，已同时生成 Markdown 和 Word `.docx`；如未生成 Word，已说明具体原因。