# Official Doc Writer

> 面向单位办公室、综合岗、文秘、材料岗和企事业单位用户的正式材料写作助手。核心用于公文写作、正式文书起草、汇报材料整理、讲话稿撰写、工作总结和方案报告生成。把零散想法、会议记录、工作素材、调研资料或初稿，整理成结构清楚、表达稳妥、逻辑完整、可直接修改使用的正式文稿。支持通知、请示、报告、函、复函、批复、会议纪要、通报、通告、公告、意见、方案、总结、管理办法、汇报材料、发言稿、讲话稿、调研报告、经验材料等常见文种和工作材料。可进行起草、改写、润色、扩写、压缩、标题优化、结构调整、语气统一和内容审查。涉及政策依据、数据支撑、案例参考时，使用内置大纲模板 + 知识库检索/联网搜索获取素材，并单独生成「溯源清单报告」帮助用户复核依据。正式交付时支持生成 Word 文档；用户明确需要时，也可生成红头文件。

- Skill: `dcoupe/official-doc-writer` (Agent Skill, multi-file: 42 files)
- Install (CLI): `npx skillmds@latest add dcoupe/official-doc-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dcoupe/official-doc-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: dcoupe (https://skillmd.com/u/dcoupe)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/dcoupe/official-doc-writer

---


# 公文写作

- 建议大纲 → 改为读取 `reference/outline-templates/` 下的**内置模板文件**；
- 素材检索 → 改为 **知识库检索（若已连接知识库 connector）优先 + 联网搜索（Web Search / Web Fetch）兜底**；
- 可信溯源报告 → 改为 **「溯源清单报告」**（列出来源标题、链接、摘要、检索方式，不再声称「已通过深知核验」）。

其余能力（文种标准、Word 排版、红头文件、审查清单、任务路由）完整保留。它不是固定从头到尾执行的演示脚本，而是根据任务选择最小必要流程，帮助用户完成公文写作、文书起草、汇报材料整理、讲话稿撰写、总结方案生成、素材检索、溯源清单报告和 Word 交付。


## 设计模式

本 Skill 组合使用五种模式：

- Tool Wrapper：封装内置大纲模板读取、知识库/联网检索、普通 Word 排版、红头文件生成和溯源清单报告 HTML 生成。
- Generator：根据文种标准、用户材料和素材指引生成公文正文。
- Reviewer：按审查清单检查格式、逻辑、素材来源和公文风险。
- Inversion：复杂任务或关键信息缺失时，先向用户追问。
- Pipeline：仅在政策依据型、长篇复杂材料、红头交付等场景执行带检查点的严格流程。


用户未配置发文机关、文号前缀或地域时，仍可生成文档：分别使用 `XX单位`、`XX〔年份〕XX号` 等醒目占位符，地域则根据当前任务询问或保持未指定。交付时提醒用户核对占位符。不得根据示例、历史文档或检索地域猜测用户所属单位，不得把任何具体客户名称作为默认值。

## 工作原则

- Python3 与 python-docx、requests 是生成 Word 的前置条件；如环境不具备，应先说明影响并征得用户同意后安装（`python3 -m pip install python-docx requests`），不安装则直接说明无法生成文件，不得强行生成损坏文件。可选的环境自检：`python3 scripts/initialize.py`（非强制）。
- 简单短文本任务可以直接完成，不强制走完整流水线。
- 正式写作需求进入检索或正文生成前，优先读取 `reference/outline-templates/` 下对应文种的内置大纲模板；模板给出结构参考和写作要点，但**不提供事实依据**，不得把模板内容当作政策、数据或案例依据。
- 大纲模板返回可用结构时，必须先向用户展示整理后的「建议大纲 + 检索建议」并等待确认或调整；用户确认后，再根据确认后的大纲和检索建议进入素材检索流程。
- 只有在政策、数据、案例、文号、标准等支撑材料必要时才检索。
- 检索逻辑遵循 `reference/search_policy.md`，素材四分类和来源可信度要求不得改变其精神。
- 执行过检索时，召回材料如何进入正文遵循 `reference/material_usage_guidance.md`；材料服务于观点，不得把检索结果简单拼贴成正文。
- 本 Skill 的检索默认优先使用**已连接的知识库 connector**（如用户侧知识库）；未连接知识库或知识库未覆盖时，使用 Agent 自带的**联网搜索（Web Search / Web Fetch）**兜底。两者均允许，且都需在溯源清单报告中如实标注检索方式（`retrieved_via`）。
- 只要准备做检索，必须先给出检索方案并等待用户确认；不得在同一轮里一边给方案一边执行检索。
- 对复杂材料，先读取内置大纲模板；只有模板给出了清晰结构时才确认大纲和检索建议。对简单短文本，能合理假设就先写。
- 对报告、总结、方案、汇报材料、产业研究、调研分析、政策研究等长篇正式材料，默认交付 `.docx`，即使用户没有明确说「生成 Word」。
- 只有用户明确说「直接在对话里给正文」「不要生成 Word」「先看文字草稿」时，才在聊天中输出正文全文。
- 对长篇正式材料，不得先在对话中发送「正文初稿」「压缩版」「预览版」或完整正文；应直接生成 Word，只给简短说明和文件路径。
- 正式公文 Word 默认保持纯净：正文中不得附带来源角标、`【素材使用情况】`、知识库链接或长 URL；执行过检索时，溯源清单信息单独生成 HTML 辅助交付物。
- 生成的普通 Word 文档末尾必须保留 `【AI生成提示】内容由AI生成，内容仅供参考。`，这是普通 Word 正式交付的固定要求；红头文件为保证国标版记排版，不保留该提示，红头脚本会自动移除普通 Word 中已有提示。
- Markdown 草稿只能作为生成 Word 的内部临时文件；不得向用户展示、链接、发送或要求用户审阅 `.md` 草稿。
- 生成 Word 时，凡正文超过一行，必须先写入临时 `.txt` 或 `.md` 文件，再把文件路径作为 `scripts/format_document.py` 的输入参数；不得把整篇多行正文直接塞进 `--text` 参数，也不得用临时 Python 脚本直接手写 `python-docx` 生成正式交付文件。
- 默认只生成普通 Word；只有用户明确说「红头文件」「红头版」「套红头」「生成红头」时，才生成红头文件。
- 当前版本不支持自动生成 PDF，且不得主动向用户提及 PDF 交付能力。用户明确要求「输出 PDF」「生成 PDF」「转成 PDF」等时，只生成对应 Word 或红头 Word，并明确说明：当前版本暂不支持自动生成 PDF，建议用户使用已生成的 `.docx` 在本机 Word/WPS 中另存或导出为 PDF。
- 不得使用 LibreOffice、ReportLab、PyPDF2/pypdf、浏览器打印、HTML 转 PDF 或其他降级方案生成正式公文 PDF。
- 任一关键步骤出现异常时，必须暂停并向用户确认下一步；不得自行跳过检索、改用未授权来源或继续生成正式结果。
- 生成前后按任务风险调用 `reference/review_checklist.md`。

## 任务路由

开始工作前先判断任务类型和复杂度。具体规则见 `reference/task_router.md`。

常见路由：

- 简单会议通知、内部事务通知：读取对应标准，按用户要求生成短正文或 Word。
- 普通通知、函、短报告：必要时追问少量关键信息，然后生成。
- 请示、复函、政策依据型报告：通常需要检索，按检索规则执行。
- 管理办法、实施方案、调研报告、工作总结、产业研究总结：通常先确认大纲或检索方案，再生成 Word。
- 用户要求「看看有什么问题」：进入 Reviewer 模式，优先输出问题清单。
- 用户要求「生成 Word」：只生成普通 Word。
- 用户明确要求「红头文件/红头版/套红头/生成红头」：先生成普通 Word，再使用代码化红头脚本生成红头文件。
- 用户明确要求「PDF」：仍只生成对应 Word 作为正式公文主产物；如同时要求红头 PDF，先生成红头 Word；然后说明当前版本暂不支持自动生成 PDF，建议用户用 Word/WPS 自行导出。

## 大纲模板规则

正式写作需求进入检索或正文生成前，优先读取 `reference/outline-templates/` 下对应文种的内置大纲模板：

```bash
# 读取内置大纲模板（示例：调研报告）
cat reference/outline-templates/调研报告_大纲.md
```

触发范围：

- 起草、撰写、生成正式公文或事务文书；
- 报告、总结、计划、方案、汇报材料、讲话稿、发言材料、经验交流材料、调研分析、政策研究等长篇材料；
- 用户明确要求「先给大纲」「参考范文结构」「设计写作框架」。

可跳过范围：

- 简单会议通知、时间地点变更、短告知、短提醒；
- 用户明确要求直接输出短正文，且无需政策、数据、案例或复杂结构；
- 用户提供完整大纲并要求严格按其大纲写作。

模板返回可用结构时，向用户展示：

- 建议标题和文种；
- 建议大纲，每个一级标题附简短写作目的和要点；
- 后续检索建议，只展示检索方向和用途。

用户可见确认内容必须使用清晰的 Markdown 分节和列表，不得把大纲、写作要点和检索建议压缩成一个长段落。推荐格式：

```text
我先根据内置大纲模板生成了参考大纲和后续检索建议，请确认是否按这个结构继续，或告诉我需要调整哪些部分。

建议大纲：

一、发展背景与战略意义
- 写作目的：……
- 主要要点：
  - ……
  - ……

二、主要做法与推进路径
- 写作目的：……
- 主要要点：
  - ……

后续检索建议：

1. 政策依据
- 检索方向：……
- 用途：……

2. 数据支撑
- 检索方向：……
- 用途：……

3. 参考案例
- 检索方向：……
- 用途：……
```

确认话术：

```text
我先根据内置大纲模板生成了一个参考大纲和后续检索建议，请确认是否按这个结构继续，或告诉我需要调整哪些部分。确认后我再进入政策、数据和案例检索。
```

用户确认或修改后，再进入检索方案设计。模板中的 `search_suggestions` 只能作为检索方案设计输入，必须转化为用户可理解的检索项后再次确认；不得直接当作已经检索到的素材。

## 检索规则

需要检索时，严格遵循 `reference/search_policy.md`：

1. 设计检索方案，覆盖政策依据、数据支撑、参考案例等必要维度；不要把「表述参考型」设计为独立检索项。
2. 优先使用**已连接的知识库 connector** 做检索；知识库未覆盖或返回不足时，使用 **Agent 自带的联网搜索（Web Search / Web Fetch）** 兜底。
3. 向用户展示检索方案并停止，等待用户确认或调整。
4. 用户确认检索方案后，执行检索；如用户调整，按调整后的方案执行。执行检索时记录每条材料的 `retrieved_via`（知识库 / 联网搜索）。
   - 多个检索项默认串行执行，完成第 1 项并确认结果后再执行第 2 项；不得并发、后台或多 Agent 同时检索，除非用户明确要求提速并确认可接受风险。
5. 将召回素材分为四类：政策依据型、数据支撑型、参考案例型、表述参考型；表述参考型只能从已召回材料中归纳，不单独检索。
6. 按 `reference/material_usage_guidance.md` 判断各类材料的正文用途，区分依据、数据、案例和表述参考。
7. **来源可信度要求**：政策依据、精确数据、排名、占比、金额、文号等高风险内容，优先采用权威来源（政府官网、官方发布、正式出版物、用户侧知识库）；联网检索到的非权威来源只能作为背景或表述参考，不得写成确定结论。
8. 对政策依据、数据支撑、参考案例做充分性自检，必要时补搜。
9. 用户确认素材后，再进入大纲或 Word 生成；长篇正式材料不得把正文初稿作为聊天消息发出。
10. 执行过检索时，正式公文正文不再内嵌来源角标、知识库链接或溯源卡片；必须另行生成 `标题_溯源清单报告.html`，将完整正文写入 HTML，并把正文中的 `[1]`/`【1】` 角标变成可点击的来源跳转。报告底部统一展示溯源清单。溯源清单报告不再使用「已完成深知核验」之类措辞，改用「以下来源由本次检索召回，请自行核对权威性」等中性表述。
11. 溯源清单报告必须按 `reference/search_guide.md` 的固定流程生成：先整理结构化 JSON 到 `official-docs/input/标题_溯源清单报告.json`，再调用 `python3 scripts/source_trace_html.py ...` 输出 HTML。不得由模型手写完整 HTML，不得自行拼接 `<a>`、`onclick`、按钮、卡片或页面样式。
12. 整理 `sources` 时，凡来自检索的材料，必须将原始结果的 URL 原样写入 `url`；若检索未返回 URL（如知识库仅返回片段），该来源不显示原文链接，不得猜测、补造或用搜索接口地址代替。
13. 溯源清单报告中的来源链接必须来自每次检索真实返回的结果；不得使用占位链接、`alert()`、纯文本说明或无法点击的伪链接替代。

检索异常处理：

- 如知识库检索失败、联网搜索异常、网络异常、权限异常，或关键检索项返回空结果，立即停止后续写作。
- 向用户说明异常发生在哪个检索项、错误信息或空结果情况，以及已经成功/失败的检索项。
- 必须请用户确认下一步，选项包括：重试当前检索、调整 query/范围后重试、跳过该检索项继续、暂时不检索、改用用户提供材料、切换到另一种检索方式（知识库 ↔ 联网搜索）。
- 未经用户明确确认，不得把不可靠来源写成确定结论，也不得用占位链接伪装来源。

检索方案必须包含：

- 检索范围：使用用户任务对应的国家、省或市，不预设具体地区。
- 检索内容：每条 query 的目的。
- 素材类型：仅列政策依据型、数据支撑型、参考案例型。表述参考型不作为独立检索项，只从已召回材料中吸收表达方式。
- 使用边界：哪些材料可作为政策依据，哪些只能作为案例或表述参考。
- 面向用户展示检索方案时，不得出现脚本内部参数；执行参数只用于用户确认后的内部检索调用。

检索方案确认话术：

```text
我建议先按下面方案检索，请确认是否执行，或告诉我需要增删哪些检索项。
```

## 写作规则

生成正文前，按文种读取对应标准文件：

- 报告：`reference/standards/01_报告_标准.md`
- 请示：`reference/standards/02_请示_标准.md`
- 批复：`reference/standards/03_批复_标准.md`
- 通知：`reference/standards/04_通知_标准.md`
- 意见：`reference/standards/05_意见_标准.md`
- 函：`reference/standards/06_函_标准.md`
- 会议纪要：`reference/standards/07_会议纪要_标准.md`
- 通报：`reference/standards/08_通报_标准.md`
- 通告：`reference/standards/09_通告_标准.md`
- 公告：`reference/standards/10_公告_标准.md`
- 无意见复函：`reference/standards/11_复函（无意见）_标准.md`
- 有意见复函：`reference/standards/12_复函（有意见）_标准.md`
- 提醒函：`reference/standards/13_提醒函_标准.md`
- 其他法定文种或未明确文种：`reference/standards/14_通用公文_标准.md`
- 事务文书：`reference/standards/15_事务文书_模板.md`

写作时正文不加引用标记。执行过检索时，正文只写正式内容，不在文末追加素材使用情况或溯源清单链接；素材来源说明作为单独 HTML 辅助文件生成，格式见 `reference/search_guide.md`。

对工作总结、工作要点、实施方案、专项整治方案、会议讲话、研讨发言、汇报材料等长篇材料，生成正文前还应读取 `reference/standards/99_可选参考_常用句式和结构.md`，内部完成结构选择、小标题策略和段落功能分配。该文件只提供通用写作方法，不得机械套用参考句式，也不得用表达增强替代事实、措施和责任。

执行过检索时，生成正文前必须读取 `reference/material_usage_guidance.md`。它只提供材料使用原则，不强制套用固定结构；写作时应优先满足用户任务和文种要求，再把政策、数据、案例材料转化为支撑观点的内容。

高风险事实处理：

- 政策名称、文号、发布日期、精确数字、排名、占比、金额、全国首个/领先/唯一等表述，只有来源明确且口径一致时才写成确定结论；否则降级为概括表述，或在溯源清单中如实标注来源与口径。
- 超出用户题目时间范围的信息，只能作为背景、延续动态或趋势参考，不得混作当期政策、当期成效或已经完成事项。
- 无法通过检索确认的权威数据和文号，不写入正文；如确有参考价值，只能改用概括表述。溯源清单报告只展示本次检索真实召回、且已写入正文依据的材料。
- 通知、函、请示等短公文默认少检索、少堆依据，优先把事项、对象、责任、时限和报送要求写清楚。
- 调研报告、政策研究报告和产业研究材料必须形成「事实支撑-问题判断-原因分析-对策建议」的链条，避免只堆政策、数据和案例。

表格写作与排版规则：

- 只有在需要呈现重复记录、指标对比、政策维度比较、责任分工、时间安排、问题清单等行列数据时，才使用表格；普通论述、原因分析和建议段落不得为了显得丰富而硬塞表格。
- 表格不得直接作为文档小节标题使用。表格应归入统一的章节编号体系中，放在一个汇总性、比较性或综述性小节内。
- 正文中每张表格都必须有表题，如「表1 五省粮食产量对比」。表题是表格名称，不是小节标题；表题作为普通文字出现在小节标题下方，不使用 `#`、`##`、`###` 或 `####` 标题语法。不得生成无表题表格。
- 正文中的表格编号按全文出现顺序连续编号（表1、表2、表3……），不按章节重新编号；多个表格可以归入同一个汇总小节，各自拥有独立表题编号。
- 生成 Word 时允许使用标准 Markdown 表格。普通竖版表格建议控制在 3-6 列；超过 6 列的宽表、用户明确要求「横排表格」的表格，或表格前一行写有 `<!-- landscape-table -->` 标记时，排版脚本会单独切换到横向 A4 页面生成表格，再恢复竖向正文。
- 表格跨页时不重复表头；排版脚本会尽量避免同一行、同一单元格内容被拆到两页。若单个单元格内容过长，Word 仍可能强制分页，因此长内容应改为正文段落或分条说明。

## 审查规则

以下情况必须执行审查：

- 执行过检索；
- 请示、复函、政策依据型报告；
- 管理办法、实施方案、调研报告；
- 工作总结、工作要点、专项整治方案、会议讲话、研讨发言、汇报材料等长篇材料；
- 用户要求正式 Word 或红头文件；
- 用户明确要求检查、审核、把关。

审查清单见 `reference/review_checklist.md`。发现问题时先列问题，再说明修改建议。用户上传已有 Word 时，格式审查和内容审查可以分别执行，也可以组合执行；执行内容审查并使用检索时，必须生成溯源清单报告 HTML。

## Word 输出

本 Skill 生成 Word 依赖 Python3 与 python-docx、requests。如 `python3` 不可运行或缺少依赖，先说明影响并征得用户同意安装（`python3 -m pip install python-docx requests`）；不安装则直接说明无法生成 Word 的限制，不得强行生成损坏文件。可选的环境自检：`python3 scripts/initialize.py`（非强制）。

用户明确授权保存常用设置时，才执行：

```bash
python3 scripts/initialize.py --organization "用户提供的单位" --doc-prefix "用户提供的前缀" --region "用户提供的地域" --save
```

需要生成 Word 时，正文必须使用 `reference/output_guide.md` 支持的 Markdown 格式。

普通 Word：

```bash
python3 scripts/format_document.py official-docs/input/official_doc_content.txt
```

调用前先把正文写入 agent 工作区（默认当前工作目录，可由 `AGENT_WORKSPACE` 环境变量覆盖）下的 `official-docs/input/` 临时正文文件。默认保存到 `config/format.json` 的 `output.dir`，相对路径解析到 agent 工作区下的 `official-docs/output/`（不再锁定在 Skill 安装目录）；脚本默认从正文标题生成正式文件名，并在同名文件已存在时追加 `_v1`、`_v2`。如用户明确要求保存文件名，可传入 `--output 文件名.docx`。只有一句话以内的极短文本才允许使用 `--text`；多行正文不得直接通过命令行参数传入，避免换行被破坏后整篇文档变成一个段落。

红头 Word：

```bash
python3 scripts/template_generator.py 通知 --input 普通Word文件路径 --org "发文机关" --doc-number "发文字号"
```

红头脚本只能在用户明确要求红头时调用。用户只要求「生成 Word」「正式 Word」「排版文件」时，不调用红头脚本。

当前版本不支持自动生成 PDF，也不提供 PDF 转换命令。用户明确要求 PDF 时，生成正式 `.docx` 或红头 `.docx` 后，提示用户使用本机 Word/WPS 的「另存为 PDF」或「导出 PDF」功能完成转换；不得声称已生成 PDF。

生成成功后，优先返回正式 `.docx` 文件路径和一句简短说明。执行过检索并生成溯源清单报告 HTML 时，可同时返回辅助文件路径，但必须明确主文件是正式成稿、溯源清单报告不是正文附件。不要发送 Markdown 草稿、正文初稿、完整正文或中间文件路径。

如需先把正文落为临时 Markdown 文件供脚本读取，必须在同一工作流中继续生成 `.docx`；不得停在 Markdown 草稿，也不得把 Markdown 文件作为阶段性成果发给用户。只有用户明确要求「先看草稿」「先发 Markdown」「不要生成 Word」时，才可以交付 Markdown 或正文预览。

对「写一份/起草/生成/整理/形成……报告、总结、方案、汇报材料、产业研究」等长篇正式材料，默认理解为需要正式文件交付；不得因为用户未写「Word」就先把正文粘贴到聊天窗口。

## 溯源清单报告

执行过检索时，正式公文 Word 不在正文中添加来源角标、素材清单和来源链接。撰写完成后，单独生成 `标题_溯源清单报告.html`，将完整正文写入 HTML，并把正文中的 `[1]`/`【1】` 角标变成可点击的来源跳转；报告底部展示溯源清单。溯源清单报告固定为 HTML，不生成 Word 版。

生成方式：

1. 先将溯源清单报告整理为结构化 JSON，保存到 agent 工作区下的 `official-docs/input/标题_溯源清单报告.json`，其中正文写入 `document_content`，正文引用使用 `[1]`、`[2]` 等角标。
2. JSON 中的 `sources` 必须逐条来自真实检索结果；每次检索对应一组来源，并标注 `retrieved_via`（知识库 / 联网搜索）。
3. 再调用 `scripts/source_trace_html.py` 生成 HTML：

```bash
python3 scripts/source_trace_html.py official-docs/input/标题_溯源清单报告.json --output 标题_溯源清单报告.html
```

未指定目录的 `--output` 会保存到 agent 工作区下的 `official-docs/output/`。

生成边界：

- 必须使用 `scripts/source_trace_html.py` 生成最终 HTML；模型只负责准备结构化 JSON，不得手写完整 HTML 页面。
- 不得自行拼接 `<a>`、`onclick`、按钮、卡片、CSS 或整页 HTML；不得用 Markdown、Word 排版脚本、浏览器保存网页等方式替代。
- `sources[].url` 必须是真实来源 URL，来源只能是对应检索结果的 `url` 字段。
- `sources[].label` 必须优先使用来源标题；`retrieved_via` 如实标注检索方式。
- 不得使用 `alert()`、`javascript:`、纯文本提示、占位 `XXX` 或不可点击文本充当来源链接。
- 如果任一关键检索项没有可用来源链接，必须在报告中注明「未返回原文链接」，不得继续生成伪链接或省略后当作正常完成。

JSON 示例：

```json
{
  "title": "深圳市人工智能赋能政务服务应用情况调研报告_溯源清单报告",
  "summary": "本报告展示本次写作所使用的素材来源。正文采用的政策、数据和案例依据均来自下方溯源清单，请自行核对来源权威性与口径。",
  "sources": [
    {
      "type": "政策依据型",
      "title": "《深圳经济特区人工智能产业促进条例》",
      "agency": "深圳市人大常委会",
      "date": "2024年",
      "url": "https://example.gov.cn/xxx",
      "retrieved_via": "联网搜索",
      "section": "一（二）深圳地方政策体系",
      "excerpt": "支撑深圳以地方立法推动人工智能产业和政务场景应用的制度基础。",
      "verification": "来源为深圳市人大常委会官网公开文本；请核对最新施行版本。"
    }
  ],
  "verification_notes": [
    "以下来源由本次检索召回，请自行核对权威性与时效性。",
    "联网检索结果可能含非官方来源，仅作背景或表述参考，不得作为确定结论。"
  ]
}
```

格式要求：

- 正式公文正文中不得包含 `【素材使用情况】`、知识库链接、来源 URL 或素材清单。
- 溯源清单报告 HTML 是辅助核验文件，不是正式公文附件，不附在正式正文后；它包含完整正文和可点击来源跳转。
- HTML 首页必须先展示溯源清单，再展示素材使用卡片和「来源核验说明」。
- 每条来源必须标注 `retrieved_via`（知识库 / 联网搜索），链接文字使用真实来源标题。
- `sources` 中每条素材至少包含 `title`、`agency`、`section`、`excerpt`；来自检索的材料还必须把原始结果的 `url` 原样写入 `url`，不得依赖标题反查。接口未返回原网址时不填、不猜测。
- 每条素材只写实际用于正文的核心依据，不机械罗列所有检索结果；同类材料可合并说明。
- 不得使用表格承载素材使用情况；HTML 由脚本生成卡片式布局。
- HTML 由 `scripts/source_trace_html.py` 生成；不要手写完整 HTML 页面，也不要用 Word 排版脚本生成溯源清单报告。
- 最终 HTML 必须包含真实 `<a href="来源URL">来源标题</a>` 链接。若检查发现 `href` 缺失、`onclick`/`alert()` 伪链接、占位 URL 或链接文字与来源不一致，视为生成失败，必须回到 JSON 和原始检索结果修正后重新运行脚本。