深知写作助手

深知写作助手

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

设计模式

本 Skill 组合使用五种模式：

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

工作原则

• 简单短文本任务可以直接完成，不强制走完整流水线。
• 只有在政策、数据、案例、文号、标准等支撑材料必要时才搜索。
• 搜索逻辑遵循 reference/search_policy.md，素材四分类和来源限制不得改变。
• 执行过搜索时，召回材料如何进入正文遵循 reference/material_usage_guidance.md；材料服务于观点，不得把搜索结果简单拼贴成正文。
• 本 Skill 内所有政策、数据、案例、素材检索默认只能使用随包的深知搜索能力；不得使用通用网页检索、浏览器检索或公开网页抓取替代深知搜索。
• 只要准备调用深知搜索，必须先给出搜索方案并等待用户确认；不得在同一轮里一边给方案一边执行搜索。
• 对复杂材料，先确认素材或大纲；对简单材料，能合理假设就先写。
• 对报告、总结、方案、汇报材料、产业研究、调研分析、政策研究等长篇正式材料，默认交付 .docx，即使用户没有明确说“生成 Word”。
• 只有用户明确说“直接在对话里给正文”“不要生成 Word”“先看文字草稿”时，才在聊天中输出正文全文。
• 对长篇正式材料，不得先在对话中发送“正文初稿”“压缩版”“预览版”或完整正文；应直接生成 Word，只给简短说明和文件路径。
• 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. 用户确认搜索方案后，必须执行随包的深知搜索能力；如用户调整，按调整后的方案执行。

5. 将召回素材分为四类：政策依据型、数据支撑型、参考案例型、表述参考型；表述参考型只能从已召回材料中归纳，不单独搜索。

6. 按 reference/material_usage_guidance.md 判断各类材料的正文用途，区分依据、数据、案例和表述参考。

7. 严禁将外省政策作为本省政策依据。

8. 对政策依据、数据支撑、参考案例做充分性自检，必要时补搜。

9. 用户确认素材后，再进入大纲或 Word 生成；长篇正式材料不得把正文初稿作为聊天消息发出。

10. 执行过搜索的文档，末尾必须包含素材使用情况和知识专库链接。

搜索异常处理：

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

外部搜索禁用规则：

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

搜索方案必须包含：

• 搜索地域：如中国、广东省、广州市等。
• 搜索内容：每条 query 的目的。
• 素材类型：仅列政策依据型、数据支撑型、参考案例型。表述参考型不作为独立搜索项，只从已召回材料中吸收表达方式。
• 使用边界：哪些材料可作为政策依据，哪些只能作为案例或表述参考。

搜索方案确认话术：

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

搜索执行规则：

• 时间条件只用于 2025年、2025年08月、2025年08月15日 这类单个明确时间点；不要传 2023-2025 这类范围。
• 没有明确时间点时不设置时间条件。

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

多次搜索结果需要合并时，保留每次搜索的来源信息和知识专库链接，不得丢失原始材料来源。

写作规则

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

• 报告：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/material_usage_guidance.md。它只提供材料使用原则，不强制套用固定结构；写作时应优先满足用户任务和文种要求，再把政策、数据、案例材料转化为支撑观点的内容。

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

审查规则

以下情况必须执行审查：

• 执行过搜索
• 请示、复函、政策依据型报告
• 管理办法、实施方案、调研报告
• 用户要求正式 Word 或红头文件
• 用户明确要求检查、审核、把关

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

Word 输出

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

普通 Word：

• 调用随包 Word 排版能力生成普通 .docx 文件。
• 调用前先把多行正文保存为临时正文文件，再交给排版能力处理。
• 只有一句话以内的极短文本才允许直接传入；多行正文不得直接作为一整段参数传入，避免换行被破坏后整篇文档变成一个段落。

红头 Word：

• 红头能力只能在用户明确要求红头时调用。
• 用户只要求“生成 Word”“正式 Word”“排版文件”时，不调用红头能力。

生成成功后，只向用户返回最终 Word 文档和一句简短说明；不要同时发送 Markdown 草稿、正文初稿、完整正文或中间过程材料。WebChat 场景下尤其避免一次返回多个文档链接，降低误打开新对话的概率。

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

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