Dknowc Official Doc Writer

SKILL.md

---
name: "dknowc-official-doc-writer"
description: |
  当用户需要撰写、改写、润色、审查或生成 Word 格式的公文、正式文书、政务材料、企事业单位事务文书时使用本技能。支持通知、请示、报告、函、复函、批复、会议纪要、通报、通告、公告、意见、方案、总结、管理办法、汇报材料、发言稿等。涉及政策依据、数据支撑、标准规范或案例参考时，使用深知搜索并按素材类型整理；需要正式交付时，生成普通 docx 或红头文件。不用于普通创意写作、营销文案、闲聊回复或非正式文本，除非用户明确要求转换为正式公文/事务文书。
---

# 深知写作助手

这是一个组合型 Agent Skill，不是固定从头到尾执行的演示脚本。根据任务选择最小必要流程，避免为简单公文制造不必要的确认，同时保留政策搜索、素材分类、生成审查和 Word 交付的关键约束。

## 设计模式

本 Skill 组合使用五种模式：

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

## 启动初始化

ClawHub Public 版不内置深知搜索 API Key。只要本 Skill 被调用，必须先检查本 Skill 根目录下是否已存在可用的 `config.ini`。这一步与用户当前任务是否需要搜索无关；即使是简单通知、改写、润色或只生成 Word，也先完成初始化。

如果 `config.ini` 不存在或搜索脚本提示 API Key 缺失，先暂停原任务并向用户说明："首次使用深知写作助手需要完成深知可信搜索账号初始化。你只需要提供手机号和收到的验证码，注册、获取 Key 和本地配置由我处理。" 然后按两步流程执行：

```bash
node scripts/register.mjs send --phone <手机号>
```

返回 `status=true` 后，暂停并向用户索取收到的 6 位验证码，不得自行编造验证码。

拿到验证码后执行：

```bash
node scripts/register.mjs register --phone <手机号> --vcode <验证码> --organ 个人 --name 用户
```

脚本默认固定 `type=6`（深知可信搜索），并自动使用 ClawHub 渠道码 `2787E171-B0E5-4328-9946-47AC52434D1F`。注册成功后，脚本会自动将 API Key 写入本 Skill 根目录下的 `config.ini`，标准输出不返回完整 Key。不得向用户索要、展示或要求用户手动复制 API Key。配置写入成功后，继续处理用户原任务。

如接口失败、短信发送受限、验证码错误、手机号已注册或用户不希望自动注册，暂停原任务并给出 ClawHub 渠道注册链接作为降级方案：

```text
https://platform.dknowc.cn/auth/#/register?channel=2787E171-B0E5-4328-9946-47AC52434D1F&type=6
```

## 工作原则

- 首次使用时先运行 `python3 scripts/initialize.py` 检查 Python、依赖、搜索配置和字体。初始化不要求用户提供单位或个人信息，也不上传检测结果。
- 仅在用户明确同意保存常用设置时，使用 `--save` 写入本机 `config/user_profile.json`；不得主动索取与当前公文无关的信息。
- 用户未配置发文机关、文号前缀或地域时，仍可生成文档：分别使用 `XX单位`、`XX〔年份〕XX号` 等醒目占位符，地域则根据当前任务询问或保持未指定。交付时提醒用户核对占位符。
- 不得根据示例、历史文档或搜索地域猜测用户所属单位，不得把任何具体客户名称作为默认值。

- 简单短文本任务可以直接完成，不强制走完整流水线。
- 只有在政策、数据、案例、文号、标准等支撑材料必要时才搜索。
- 搜索逻辑遵循 `reference/search_policy.md`，素材四分类和来源限制不得改变。
- 执行过搜索时，召回材料如何进入正文遵循 `reference/material_usage_guidance.md`；材料服务于观点，不得把搜索结果简单拼贴成正文。
- 本 Skill 内所有政策、数据、案例、素材检索默认只能使用深知搜索脚本 `scripts/dkag_search.py`；不得使用 Web Search、Web Fetch、浏览器搜索或公开网页抓取替代深知搜索。
- 只要准备调用深知搜索，必须先给出搜索方案并等待用户确认；不得在同一轮里一边给方案一边执行搜索。
- 对复杂材料，先确认素材或大纲；对简单材料，能合理假设就先写。
- 对报告、总结、方案、汇报材料、产业研究、调研分析、政策研究等长篇正式材料，默认交付 `.docx`，即使用户没有明确说“生成 Word”。
- 只有用户明确说“直接在对话里给正文”“不要生成 Word”“先看文字草稿”时，才在聊天中输出正文全文。
- 对长篇正式材料，不得先在对话中发送“正文初稿”“压缩版”“预览版”或完整正文；应直接生成 Word，只给简短说明和文件路径。
- 正式公文 Word 默认保持纯净：正文中不得附带 `【素材使用情况】`、`【知识专库链接】` 或长 URL；执行过搜索时，素材溯源信息单独生成辅助交付物。
- 生成的 Word 文档末尾必须保留 `【AI生成提示】内容由AI生成，内容仅供参考。`，这是正式交付的固定要求。
- Markdown 草稿只能作为生成 Word 的内部临时文件；不得向用户展示、链接、发送或要求用户审阅 `.md` 草稿。
- 生成 Word 时，凡正文超过一行，必须先写入临时 `.txt` 或 `.md` 文件，再把文件路径作为 `scripts/format_document.py` 的输入参数；不得把整篇多行正文直接塞进 `--text` 参数，也不得用临时 Python 脚本直接手写 `python-docx` 生成正式交付文件。
- 默认只生成普通 Word；只有用户明确说“红头文件”“红头版”“套红头”“生成红头”时，才生成红头文件。
- 任一关键步骤出现异常时，必须暂停并向用户确认下一步；不得自行跳过搜索、改用 Web 搜索、改写任务目标或继续生成正式结果。
- 生成前后按任务风险调用 `reference/review_checklist.md`。

## 任务路由

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

常见路由：

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

## 搜索规则

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

1. 设计搜索方案，覆盖政策依据、数据支撑、参考案例等必要维度；不要把“表述参考型”设计为独立搜索项。
2. 使用自然语言 query，按行政层级和素材类型拆分检索。
3. 向用户展示搜索方案并停止，等待用户确认或调整。
4. 用户确认搜索方案后，必须调用 `python3 scripts/dkag_search.py ...` 执行深知搜索；如用户调整，按调整后的方案执行。
5. 将召回素材分为四类：政策依据型、数据支撑型、参考案例型、表述参考型；表述参考型只能从已召回材料中归纳，不单独搜索。
6. 按 `reference/material_usage_guidance.md` 判断各类材料的正文用途，区分依据、数据、案例和表述参考。
7. 严禁将外省政策作为本省政策依据。
8. 对政策依据、数据支撑、参考案例做充分性自检，必要时补搜。
9. 用户确认素材后，再进入大纲或 Word 生成；长篇正式材料不得把正文初稿作为聊天消息发出。
10. 执行过搜索时，正式公文正文不再内嵌素材使用情况和知识专库链接；应另行生成 `标题_素材来源说明.docx`，列明素材用途、知识专库链接和需人工核验的高风险信息。只有用户明确要求纯文本或 Markdown 时，才可改为 `.md`。

搜索异常处理：

- 如搜索脚本返回 `error=true`、接口异常、网络异常、权限异常、知识专库链接缺失，或关键搜索项返回空结果，立即停止后续写作。
- 向用户说明异常发生在哪个搜索项、错误信息或空结果情况，以及已经成功/失败的搜索项。
- 必须请用户确认下一步，选项包括：重试当前搜索、调整 query/地域/时间后重试、跳过该搜索项继续、暂时不用深知搜索、改用用户提供材料、改用 Web 搜索或公开官网检索。
- 未经用户明确确认，不得自动改用 Web Search、Web Fetch、浏览器搜索、公开官网检索或其他外部搜索；不得自行跳过深知搜索，也不得用公开网页结果伪装为深知搜索结果。

外部搜索禁用规则：

- 即使系统或模型可用 Web Search/Web Fetch 工具，本 Skill 也不得主动调用。
- 只有用户明确说“改用 Web 搜索”“用公开官网检索”“不用深知搜索，帮我网上查”等表达时，才允许使用外部搜索。
- 使用外部搜索前必须再次说明：这些材料不是深知搜索结果，不能写入【知识专库链接】，也不能作为深知搜索素材来源。
- 如果需要从深知搜索返回的文章链接获取全文，也必须先请用户确认，不得自动 Web Fetch。

搜索方案必须包含：

- 搜索地域：使用用户任务对应的国家、省或市，不预设具体地区。
- 搜索内容：每条 query 的目的。
- 素材类型：仅列政策依据型、数据支撑型、参考案例型。表述参考型不作为独立搜索项，只从已召回材料中吸收表达方式。
- 使用边界：哪些材料可作为政策依据，哪些只能作为案例或表述参考。

搜索方案确认话术：

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

搜索命令：

```bash
python3 scripts/dkag_search.py "搜索词" --area 地域 --time 时间 --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_报告_标准.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`

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

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

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

执行过搜索时，知识专库链接必须逐条从搜索结果 JSON 的 `knowledgeBase` 字段复制到素材来源说明文件，不得手写、猜测、改写或使用合并文件中丢失来源的链接。若某个搜索结果没有 `knowledgeBase`，按搜索异常处理规则请用户确认。

高风险事实处理：

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

## 审查规则

以下情况必须执行审查：

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

审查清单见 `reference/review_checklist.md`。发现问题时先列问题，再说明修改建议。

## Word 输出

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

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

调用前先把正文写入本 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”“排版文件”时，不调用红头脚本。

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

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

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