公文写作助手

技能文档

---
name: official-doc-copilot
title: 公文写作助手
category: 办公效率
description: 面向单位办公室、综合岗、文秘与企事业单位的正式材料写作助手。覆盖公文写作、正式文书起草、汇报材料、讲话稿、工作总结与方案报告，支持起草、改写、润色、扩写、压缩、标题优化、结构调整与内容审查；可按国家标准生成 Word 文档与红头文件，涉及政策依据时可检索权威来源并生成溯源核验报告。当用户需要写公文、起草通知请示报告、整理会议纪要、写讲话稿或工作总结时触发。触发词：公文、通知、请示、报告、会议纪要、讲话稿、红头文件、工作总结。
---


# 深知公文写作

面向正式材料写作场景的组合型技能：不是固定从头到尾执行的演示脚本，而是根据任务选择最小必要流程，帮助用户完成公文写作、正式文书起草、汇报材料整理、讲话稿撰写、总结方案生成、素材检索、溯源核验报告和 Word 交付。

## 技能工作流

### 步骤1：启动初始化

运行 `python3 scripts/initialize.py` 检查运行环境与 API Key 状态（详见「启动初始化」）。

### 步骤2：任务路由

读取 `reference/task_router.md` 判断任务类型与复杂度，选择最小必要流程。

### 步骤3：起草与改稿

按文种读取 `reference/standards/` 对应标准文件生成正文；需要大纲参考时调用 `scripts/outline_reference.py`；改稿轮遵循 `reference/revision_workflow.md`。

### 步骤4：搜索与溯源

仅在政策、数据、案例、文号、标准等支撑材料必要时搜索；遵循 `reference/search_policy.md`，执行后生成溯源核验报告。

### 步骤5：审查

按 `reference/review_checklist.md` 执行格式与内容审查；语言复核参考 `reference/anti_ai_patterns.md`，可选运行 `scripts/prose_lint.py`。

### 步骤6：Word 交付

正文按 `reference/output_guide.md` 的 Markdown 格式落盘，调用 `scripts/format_document.py`（或 `scripts/template_generator.py` 生成红头文件），交付前执行 `scripts/deliver_outputs.py` 复制到交付目录。

## 设计模式

本 Skill 组合使用五种模式：

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

## 启动初始化

本技能不内置搜索 API Key。API Key 必须通过环境变量 `DKNOWC_API_KEY` 注入。本 Skill 被调用后，先运行一次初始化检查：

```bash
python3 scripts/initialize.py
```

初始化用于检查 Python、`python-docx`、`requests` 等基础运行环境，不要求用户提供单位或个人信息，也不上传检测结果。初始化不是 API Key 硬性门禁：只有当当前任务确实需要调用深知搜索时，API Key 才是前置条件。

### 不需要搜索的任务

简单通知、内部事务通知、改写、润色、审查、基于用户材料写作、只生成 Word 或红头文件等不涉及政策、数据、案例检索的任务，只要 `python3`、`python_docx`、`requests` 就绪即可继续写作，不要求配置 API Key，也不必引导用户配置搜索功能。初始化结果显示 `api_key_configured=false` 或 `search_ready=false` 时，不阻断这类任务，直接按原任务流程继续。

### 需要搜索的任务

只有任务确实需要检索权威来源（需要政策依据、数据支撑、案例参考，或用户明确要求查最新政策、最新情况、权威数据）时，API Key 才是前置条件。初始化结果显示 `api_key_configured=false`、`search_ready=false` 或 `search_blocking_issues` 包含 `api_key_missing` 时，向用户说明：需要配置环境变量 `DKNOWC_API_KEY`（向搜索服务提供方获取）；未配置前，政策依据位置以醒目的「待补」标注继续写作，交付时提醒这些位置未经权威核验。

硬规则：

- **禁止编造**：需要搜索的材料，政策依据只能来自真实检索或「待补」标注，禁止用模型自身知识冒充检索结果。
- 不向用户暴露内部术语（API Key 环境变量名、脚本名）；用户侧只说「配置搜索功能」。
- 用户未配置时不反复纠缠；交付后每个任务最多轻提示一次。

## 参考资料（渐进式读取）

按任务条件只加载命中的参考资料，不一次性读取全部文件。每个文件只在对应阶段读取，未命中条件不预读。

| 文件 | 阶段 | 加载条件 |
| --- | --- | --- |
| `reference/task_router.md` | 任务开始 | 判断任务类型与复杂度，所有任务先读 |
| `reference/revision_workflow.md` | 改稿轮 | 用户基于已交付 Word 提修改意见的连续改稿 |
| `reference/local_memory_guide.md` | 素材/偏好管理时 | 素材库或偏好数量大于 0，或用户要求保存/查看/删除素材与偏好时 |
| `reference/fact_discipline.md` | 起草/改稿前 | 所有正式写作任务，约束事实边界 |
| `reference/anti_ai_patterns.md` | 定稿前/审查 | 正式正文语言复核、去 AI 味、审查模式 |
| `scripts/prose_lint.py` | 定稿前 | 检查草稿语言、格式、重复风险（可选） |
| `scripts/local_memory.py` | 写作前/写作后 | 素材库或偏好数量大于 0 时检索素材、应用偏好；用户确认保存时写入 |
| `scripts/deliver_outputs.py` | 交付前 | 把产出物复制到交付目录（`--dest` 或环境变量指定），用户才能看到交付文件 |
| `reference/search_policy.md` | 搜索前 | 需要政策/数据/案例检索时 |
| `reference/search_guide.md` | 执行搜索后 | 生成溯源核验报告 HTML 时 |
| `reference/material_usage_guidance.md` | 执行搜索后 | 召回素材如何进入正文 |
| `reference/output_guide.md` | 生成 Word 前 | 正文 Markdown 格式、Word 交付 |
| `reference/review_checklist.md` | 生成前后 | 按任务风险执行审查时 |
| `reference/standards/*.md` | 按文种 | 命中对应文种时读取（见"写作规则"） |

## 个人素材库与写作偏好

本 Skill 在本机维护个人素材库 `knowledge-base/` 与写作偏好 `config/writing_preferences.json`，均只对当前用户生效、不随公开包分发、不上传。初始化结果 `local_memory` 字段返回二者数量；数量大于 0 时，写作任务应先检索素材库并应用偏好。

- 保存或删除素材/偏好必须先经用户确认；一次性使用的内容不保存。
- 素材库命中的材料按用户提供的材料对待（与当轮材料同优先级，高于搜索素材），仍须遵守 `reference/fact_discipline.md` 事实边界。
- 用户明示的写作偏好优先于文种标准和默认排版（红头国标强制项除外，冲突时向用户说明）；与当轮要求冲突时当轮优先。

命令与完整规则（六类分类、沉淀时机、应用范围）见 `reference/local_memory_guide.md`。

## 工作原则

- 首次使用时先运行 `python3 scripts/initialize.py` 检查 Python、依赖和 `DKNOWC_API_KEY` 环境变量配置。初始化不要求用户提供单位或个人信息，也不上传检测结果。
- Python 和 `python-docx`、`requests` 依赖属于基础前置条件：如无法运行 `python3`，或初始化结果显示 `python_docx=false`、`requests=false`，必须暂停执行 Skill 的写作、搜索、Word、红头和溯源核验报告能力。
- API Key 属于按需前置条件：只有当前任务需要深知搜索（政策依据、数据支撑、案例参考、查最新政策情况）时，才要求 `api_key_configured=true`、`search_ready=true`。不需要搜索的简单通知、改写、润色、基于用户材料写作或只生成 Word 的任务，即使 `api_key_configured=false`、`search_ready=false` 也不阻断，直接按原任务流程继续。
- 发现依赖缺失且 `dependency_install_prompt_needed=true` 时（initialize 会同时输出统一的 `env_message` 话术），向用户说明需要补装两个小组件——不出现 python-docx/requests 等组件名，就绪时不向用户提任何环境话题；征得用户同意后执行 `python3 -m pip install python-docx requests`；未经用户同意不得自行安装依赖。安装后必须重新运行 `python3 scripts/initialize.py` 确认 `ready=true` 后再继续。如用户不同意安装依赖，执行 `python3 scripts/initialize.py --decline-dependency-install` 记录拒绝状态，后续不再反复询问，但仍因缺少必备依赖而暂停相关能力。
- 如缺少 Python 或当前环境无权限安装依赖，应提示用户切换到具备 Python 的 Agent/运行环境，或由用户/平台管理员先完成 Python 与依赖安装。
- 字体不作为 Skill 初始化阻断项，也不主动检测、安装或引导用户安装字体。Word 文档会写入公文常用字体名称；交付时简单提醒用户：如打开端缺少对应字体，Word/WPS 可能自动替换，需以本机打开后的显示为准。
- 仅在用户明确同意保存常用设置时，使用 `--save` 写入本机 `config/user_profile.json`；不得主动索取与当前公文无关的信息。
- 用户未配置发文机关、文号前缀或地域时，仍可生成文档：分别使用 `XX单位`、`XX〔年份〕XX号` 等醒目占位符，地域则根据当前任务询问或保持未指定。交付时提醒用户核对占位符。
- 不得根据示例、历史文档或搜索地域猜测用户所属单位，不得把任何具体客户名称作为默认值。

- 简单短文本任务可以直接完成，不强制走完整流水线（即不强制大纲、搜索、素材确认环节）；但交付物仍必须是 Word 文档，不因任务简单而改为在对话中直接输出正文。
- 正式写作需求优先调用 `scripts/outline_reference.py` 获取范文参考大纲和后续搜索建议；接口未返回可用大纲或调用失败时，不中断任务，也不另行生成替代大纲，直接忽略该能力并按 3.1.4 原流程继续。
- 公文范文大纲接口不是深知搜索，不提供事实依据，只提供结构参考和搜索建议；不得把范文大纲中的内容当作政策、数据或案例依据。
- 大纲接口返回 `outline_available=true` 时，必须先向用户展示整理后的“建议大纲 + 搜索建议”并等待确认或调整；用户确认后，再根据确认后的大纲和搜索建议进入原有深知搜索流程。
- 只有在政策、数据、案例、文号、标准等支撑材料必要时才搜索。
- 搜索逻辑遵循 `reference/search_policy.md`，素材四分类和来源限制不得改变。
- 执行过搜索时，召回材料如何进入正文遵循 `reference/material_usage_guidance.md`；材料服务于观点，不得把搜索结果简单拼贴成正文。
- 本 Skill 内所有政策、数据、案例、素材检索默认只能使用深知搜索脚本 `scripts/dkag_search.py`；不得使用 Web Search、Web Fetch、浏览器搜索或公开网页抓取替代深知搜索。
- 只要准备调用深知搜索，必须先给出搜索方案并等待用户确认；不得在同一轮里一边给方案一边执行搜索。
- 对复杂材料，先尝试范文大纲接口；只有接口返回可用大纲时才确认大纲和搜索建议。对简单短文本，能合理假设就先写。
- 所有正式写作任务（起草、改写、润色、压缩、审查后定稿等），默认交付 `.docx` Word 文档，即使用户没有明确说“生成 Word”；执行过搜索时另附 HTML 溯源核验报告。这是固定交付物，不得因任务简单而改为在对话中直接输出正文。
- 只有用户明确说“直接在对话里给正文”“不要生成 Word”“先看文字草稿”时，才在聊天中输出正文全文。
- 正式写作任务不得先在对话中发送“正文初稿”“压缩版”“预览版”或完整正文；应直接生成 Word，只给简短说明和文件路径。
- 正式公文 Word 默认保持纯净：正文中不得附带来源角标、`【素材使用情况】`、`【知识专库链接】` 或长 URL；执行过搜索时，可信溯源信息单独生成 HTML 辅助交付物。
- Word 正文不内嵌 AI 生成提示，docx 属性元数据同样不写入。AI 生成标识仅由交付话术承担：在对话中自然说明一句——本稿由 AI 辅助生成、依据已经过可信核验，建议按单位审签流程核批后正式行文。排版脚本会自动过滤正文输入中误带的提示行。

字体表述规范：交付时不主动说明字体（格式规范已内置，无需赘述）；仅在用户问到字体或对字体有疑问时回答，且一律写全称"仿宋_GB2312（公文标准字体）"，禁止简写"仿宋"——两者是字体库中的不同字体，简写会误导用户。

版记：普通 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。
- 任一关键步骤出现异常时，必须暂停并向用户确认下一步；不得自行跳过搜索、改用 Web 搜索、改写任务目标或继续生成正式结果。
- 生成前后按任务风险调用 `reference/review_checklist.md`。

## 任务路由

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

常见路由：

- 简单会议通知、内部事务通知：读取对应标准，直接生成 Word 文档；只有用户明确说“直接在对话里给正文”“不要生成 Word”“先看文字草稿”时，才在对话中输出正文。
- 普通通知、函、短报告：必要时追问少量关键信息，然后生成。
- 请示、复函、政策依据型报告：通常需要搜索，按搜索规则执行。
- 管理办法、实施方案、调研报告、工作总结、产业研究总结：通常先确认大纲或搜索方案，再生成 Word。
- 用户基于已交付 Word 提修改意见（"第二段太长""落款改一下""再加一节"等）：进入改稿轮，按 `reference/revision_workflow.md` 执行——以最新版 Word 为唯一底稿，逐条落实并汇报，默认不重复已完成搜索，交付 `_v1`/`_v2` 新版本。
- 用户要求“看看有什么问题”：进入 Reviewer 模式，优先输出问题清单。
- 用户要求“生成 Word”：只生成普通 Word。
- 用户明确要求“红头文件/红头版/套红头/生成红头”：先生成普通 Word，再使用代码化红头脚本生成红头文件。
- 用户明确要求“PDF”：仍只生成对应 Word 作为正式公文主产物；如同时要求红头 PDF，先生成红头 Word；然后说明当前版本暂不支持自动生成 PDF，建议用户用 Word/WPS 自行导出。

## 范文大纲规则

正式写作需求进入搜索或正文生成前，优先尝试调用公文范文大纲接口：

```bash
python3 scripts/outline_reference.py "用户写作需求" --output outline_任务名.json
```

`用户写作需求` 必须尽量使用用户原始需求的完整表述，保留文种、主题、地域、用途、重点内容和交付要求；不得只传入压缩后的标题或文件名。例如用户要求“关于深圳市人工智能赋能基层治理应用情况的调研报告，重点包括发展背景、主要做法、典型应用场景、存在问题和下一步建议”，不得压缩成“深圳市人工智能赋能基层治理应用情况调研报告”后调用。

未指定目录的范文大纲结果保存到 `official-docs/outline-results/`。调用时使用环境变量 `DKNOWC_API_KEY`，不得向用户展示 API Key、接口参数或内部保存路径。脚本输出中 `request_success` 只表示接口请求成功，是否有可用大纲必须看 `outline_available`；`outline_available=false` 时，直接忽略范文大纲能力，不向用户确认大纲，也不要让模型自行生成替代大纲。

触发范围：起草、撰写正式公文或事务文书（报告、总结、计划、方案、汇报材料、讲话稿、调研分析、政策研究等长篇材料），以及用户明确要求"先给大纲""参考范文结构"。可跳过：简单会议通知、时间地点变更、短告知短提醒、用户提供完整大纲要求严格照写、或明确要求直接输出短正文。

范文大纲接口同样使用 `DKNOWC_API_KEY`。任务不需要搜索且未配置 Key 时，直接跳过范文大纲，按文种标准写作，不引导用户配置 Key；任务需要搜索时，按"启动初始化"先确保 API Key 已配置，再调用范文大纲接口。任务需要搜索时，按“启动初始化”先确保 API Key 已配置，再调用范文大纲接口。

大纲接口返回可用结果时，向用户展示：

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

用户可见确认内容必须使用清晰的 Markdown 分节和列表，不得压缩成一个长段落；展示格式与确认话术模板见 `reference/search_guide.md` 第一节。

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

大纲接口未返回可用结果、超时、权限异常或服务异常时：

- 不阻断写作流程。
- 不向用户展示“未获取到可用范文大纲”之类的中间状态，除非用户明确询问。
- 不让模型自行生成替代大纲，也不进入“大纲确认”环节。
- 直接按 3.1.4 原流程继续：需要搜索时设计搜索方案并等待用户确认；不需要搜索时按文种标准直接写作或生成 Word。

## 搜索规则

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

1. 设计搜索方案，覆盖政策依据、数据支撑、参考案例等必要维度；不要把“表述参考型”设计为独立搜索项。
2. 使用自然语言 query，按行政层级和素材类型拆分检索。
3. 向用户展示搜索方案并停止，等待用户确认或调整。
4. 用户确认搜索方案后，必须调用 `python3 scripts/dkag_search.py ...` 执行深知搜索；如用户调整，按调整后的方案执行。内部调用时必须把该搜索项的“搜索目的”传入 `--purpose`，用于检索目的记录；该参数不得展示给用户。
   - 多个搜索项必须默认串行执行：完成第 1 项并确认结果 JSON 写入后，再执行第 2 项，以此类推。
   - 不得使用并发、后台任务、并行命令、批量同时请求或多 Agent 同时调用搜索接口。
   - 只有用户明确要求提速并确认可接受并发风险，且平台和接口限流条件允许时，才可以并发搜索；否则一律串行。
5. 将召回素材分为四类：政策依据型、数据支撑型、参考案例型、表述参考型；表述参考型只能从已召回材料中归纳，不单独搜索。
6. 按 `reference/material_usage_guidance.md` 判断各类材料的正文用途，区分依据、数据、案例和表述参考。
7. 严禁将外省政策作为本省政策依据。
8. 对政策依据、数据支撑、参考案例做充分性自检，必要时补搜。
9. 用户确认素材后，再进入大纲或 Word 生成；正式写作任务不得把正文初稿作为聊天消息发出，直接生成 Word（执行过搜索时另附 HTML 溯源核验报告）。
10. 执行过搜索时，正式公文正文不再内嵌来源角标、知识专库链接或溯源卡片；必须另行生成 `标题_溯源核验报告.html`，将完整正文写入 HTML，并把正文中的 `[1]`/`【1】`角标变成可点击的来源跳转。报告首屏展示核验报告单（依据溯源、引用对应、材料新旧、材料构成、交付前检查）。凡通过深知可信搜索召回并写入正文的依据，默认按已完成可信检索和可溯源处理，不得使用“建议核对”“需人工核验”等削弱可信度的措辞。
11. 溯源核验报告必须按 `reference/search_guide.md` 的固定流程生成：先整理结构化 JSON 到 `official-docs/input/标题_溯源核验报告.json`（`materials[].type` 用四分类取值，`self_check` 必须如实写入成稿自检 5 项结果），再调用 `python3 scripts/source_note_html.py ...` 输出 HTML。`document_content` 必须在关键结论后标注 `[1]`、`[2]` 等角标并逐条对应 `materials`——脚本会校验，正文无角标时拒绝生成并报错，必须修正 JSON 后重跑，不得省略角标直接交付。不得由模型手写完整 HTML，不得自行拼接 `<a>`、`onclick`、按钮、卡片或页面样式。
12. 整理 `materials` 时，凡来自深知可信搜索的材料，必须将原始结果中的 `源网址` 原样写入 `source_url`；不得只写规范化后的文章标题，再依赖标题反查网址。若接口未返回 `源网址`，该材料不显示原文链接；不得猜测、补造或用搜索接口地址代替。

搜索异常处理：

- 如搜索脚本返回 `error=true`、接口异常、网络异常、权限异常，或关键搜索项返回空结果，立即停止后续写作。
- **额度或余额用尽（`quota_exhausted=true`）：禁止任何形式的重试**——不得重发同一搜索、不得换 query 再试、不得当作普通网络异常反复调用。立即向用户说明：额度或账户余额已用完，需要到服务提供方的管理平台完成认证或充值，处理后说一声即可继续。在用户确认已处理前，不得再次调用深知搜索；可按用户意愿改为基于已有材料继续写作。
- 向用户说明异常发生在哪个搜索项、错误信息或空结果情况，以及已经成功/失败的搜索项。
- 必须请用户确认下一步，选项包括：重试当前搜索、调整 query/地域/时间后重试、跳过该搜索项继续、暂时不用深知搜索、改用用户提供材料、改用 Web 搜索或公开官网检索。
- 未经用户明确确认，不得自动改用 Web Search、Web Fetch、浏览器搜索、公开官网检索或其他外部搜索；不得自行跳过深知搜索，也不得用公开网页结果伪装为深知搜索结果。

外部搜索禁用规则：本 Skill 不得主动调用 Web Search/Web Fetch/浏览器搜索；仅当用户明确说"改用 Web 搜索""用公开官网检索"时才允许，且使用前必须说明这些材料不是深知搜索结果、不能作为深知搜索素材来源；从深知搜索返回链接取全文也必须先经用户确认。外部搜索结果不得伪装为深知搜索结果。


搜索方案要素与展示边界（地域/内容/素材类型/使用边界，禁止出现脚本参数）见 `reference/search_policy.md` 与 `reference/search_guide.md` 第三节。


搜索方案确认话术：

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

搜索命令：

```bash
python3 scripts/dkag_search.py "搜索词" --area 地域 --time 时间 --purpose "搜索目的" --clean --output result_地域.json
```

未指定目录的搜索结果文件会保存到 `official-docs/search-results/`；合并搜索结果时也只能读取和写入本 Skill 的 `official-docs/input/`、`official-docs/output/`、`official-docs/search-results/` 工作目录。

`--time` 只用于 `2025年`、`2025年08月`、`2025年08月15日` 这类单个明确时间点；不要传 `2023-2025` 这类范围。没有明确时间点时省略 `--time`。

本 skill 的搜索脚本固定使用 `segmentCount=2`，每篇材料最多返回 2 个相关段落；同时固定 `simplified=false`，避免写作场景下过度剔除材料。调用时不要额外传段落数量或精简参数。

合并命令：

```bash
python3 scripts/merge_search_results.py result1.json result2.json --output merged.json
```

## 写作规则

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

- 报告：`reference/standards/01_report.md`
- 请示：`reference/standards/02_qingshi.md`
- 批复：`reference/standards/03_pifu.md`
- 通知：`reference/standards/04_tongzhi.md`
- 意见：`reference/standards/05_yijian.md`
- 函：`reference/standards/06_han.md`
- 会议纪要：`reference/standards/07_minutes.md`
- 通报：`reference/standards/08_tongbao.md`
- 通告：`reference/standards/09_tonggao.md`
- 公告：`reference/standards/10_gonggao.md`
- 无意见复函：`reference/standards/11_fuhan_approve.md`
- 有意见复函：`reference/standards/12_fuhan_objection.md`
- 提醒函：`reference/standards/13_reminder.md`
- 决定、决议、命令、公报、议案等低频法定文种：`reference/standards/16_decision.md`、`reference/standards/17_resolution.md`、`reference/standards/18_order.md`、`reference/standards/19_gazette.md`、`reference/standards/20_motion.md`，或未明确文种时使用 `reference/standards/14_generic.md`
- 事务文书：`reference/standards/15_business_docs.md`、`reference/standards/21_explanation.md`、`reference/standards/22_application.md`、`reference/standards/23_publicity.md`、`reference/standards/24_procurement.md`

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

正文一律使用中文全角标点，引号使用中文全角引号 `" " ' '`，禁止英文半角引号 `"` `'`。生成正文时直接写全角引号，不依赖排版脚本转换；定稿检查时按 `reference/anti_ai_patterns.md` 核对。

所有正式写作、改写、润色、压缩任务，生成正文前必须按 `reference/fact_discipline.md` 约束事实边界：材料已给事实保持原状态强度，材料未谈事项省略，占位符不得残留，改稿以最新版底稿为主线，不得为显得完整而补写责任、时限、下一步等材料没有的内容。

对工作总结、工作要点、实施方案、专项整治方案、会议讲话、研讨发言、汇报材料等长篇材料，生成正文前还应读取 `reference/standards/99_expressions.md`，内部完成结构选择、小标题策略和段落功能分配。该文件只提供通用写作方法，不得机械套用参考句式，也不得用表达增强替代事实、措施和责任。长篇材料定稿前按 `reference/anti_ai_patterns.md` 做语言复核，排查旁白句、思考泄露、二元包装、口号收尾、空泛词和格式噪点。

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

执行过搜索时，全部召回材料（含未引用）进入溯源核验报告材料面板，不在报告中生成知识专库链接区。

高风险事实处理：

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

表格写作与排版规则：

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

成稿快速自检（每次生成 Word 前默认执行，逐项过、不合格先自查修正再交付，不向用户输出自检过程）：

1. **事实有据**：政策名、文号、数字、日期要么来自用户材料或素材库，要么来自深知搜索结果；凭印象写的高风险表述（全国首个/领先/唯一等）删除或降级为概括表述。
2. **结构完整**：文种必需要素齐全（标题、主送、正文、结语、落款、成文日期；请示有请批事项和请批语，报告不带请批），无缺失章节；联系人电话须写入正文相关事项段，结尾不得出现独立的联系人电话段（上行文必须写明、平行文可选、下行文不强制，见各文种标准）。
3. **无占位残留**：正文无 XX单位、XXXX万元、〔待补充〕、YYYY年MM月DD日 等未处理占位（用户明确要求模板稿除外）。
4. **无 AI 味**：无旁白句（"本文将…"）、思考泄露（"作为AI…"）、口号式收尾（"提供有力支撑"）、Markdown 残留（**加粗**/###/代码块）；引号一律中文全角。可选运行 `python3 scripts/prose_lint.py <草稿> --format` 辅助确认，命中项结合上下文判断处理，不作机械清洗。
5. **格式合规**：表格有表题且连续编号、表题非标题语法；落款日期格式正确；字数符合用户要求（有明确上限时先自检字数）。

自检在生成 Word 的临时正文文件上完成，修正后重新写入再调用排版脚本；不得跳过自检直接交付，也不得把自检结果当作长篇审稿报告发给用户。

## 审查规则

以下情况必须执行审查：

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

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

语言与格式审查时，可按 `reference/anti_ai_patterns.md` 检查旁白句、思考泄露、二元包装、口号收尾、空泛词和格式噪点；需要时可选运行 `python3 scripts/prose_lint.py <草稿文件> --format --structure` 做语言质检。脚本只提示语言、格式和重复风险，不检查文种要素完整性，不自动改写；不得把脚本结果作为不加判断的硬性清洗命令。

## Word 输出

首次使用或用户要求检查环境时：

```bash
python3 scripts/initialize.py
```

如果 `python3` 不可运行，或初始化结果显示 `ready=false`、`python_docx=false`、`requests=false`，必须先暂停（依赖缺失处理见"工作原则"）。API Key 按需前置：不需要搜索的任务即使未配置 Key 也可正常生成 Word；需要搜索的任务按「需要搜索的任务」一节先配置。

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

```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
```

调用前先把正文写入本 Skill 工作目录下的 `official-docs/input/` 临时正文文件。默认保存到 `config/format.json` 的 `output.dir`，且输出只能位于 `official-docs/output/`；脚本默认从正文标题生成正式文件名，并在同名文件已存在时追加 `_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 草稿、正文初稿、完整正文或中间文件路径。

**交付目录：** 产出物默认落在 skill 安装目录，部分环境只展示其工作区文件。**每次交付前一律执行 `python3 scripts/deliver_outputs.py <产出物路径...>`**，按返回 JSON 处理：`copied=true` 向用户展示 delivered 路径；`need_dest=true` 必须补 `--dest <交付目录>` 重跑，此前不得把 skill 内部路径当交付路径发给用户。

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

对“写一份/起草/生成/整理/形成/润色/改写……”等所有正式写作任务，默认理解为需要 Word 正式文件交付（执行过搜索时另附 HTML 溯源核验报告）；不得因为用户未写“Word”就先把正文粘贴到聊天窗口。简单会议通知、内部事务通知、短改写等任务同样默认交付 Word。

使用说明

# 公文写作助手

面向企事业单位的正式材料写作助手：公文起草、汇报材料、讲话稿、工作总结，支持按国家标准生成 Word 与红头文件，政策依据可检索溯源。

## 使用

```text
起草一份关于开展安全生产大检查的通知，要正式 Word 版
```

```text
把这份会议记录整理成会议纪要，红头格式
```

## 准备

```bash
python3 scripts/initialize.py   # 检查 Python 与 python-docx、requests 依赖
```

涉政策检索需另配置 `DKNOWC_API_KEY` 环境变量；不涉及检索的写作任务无需配置。

## 工作原理

按任务类型路由到最小必要流程：读取对应文种标准（reference/standards/，覆盖 30+ 文种）→ 起草或改稿 → 按审查清单检查格式与公文风险 → 生成 Word（红头需明确要求）。检索到的政策依据附溯源核验报告，正文引用可回溯原文。

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。