深知公文写作-x-8

内容来源:clawhub · 原始地址 · 查看安装指南

原始内容


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

深知写作助手

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

设计模式

本 Skill 组合使用五种模式:

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

ClawHub Public 初始化

ClawHub Public 版不内置深知搜索 API Key。只要本 Skill 被调用,第一步必须运行:

python3 scripts/initialize.py

这是硬性启动门禁,与用户当前任务是否需要搜索无关;即使用户只是要求生成简单通知、改写、润色、写一段文字或只生成 Word,也必须先完成初始化检查。

只有初始化结果同时满足 ready=trueconfig_ini=trueconfig_api_key=true 时,才可以进入任何写作、改写、润色、审查、范文大纲、深知搜索、Word 生成或红头生成流程。

如果初始化结果中 config_api_key=falseconfig_ini=false,或 blocking_issues 包含 api_key_missingconfig.ini_missingconfig.ini_invalid,必须立即暂停原任务,只允许引导用户完成 API Key 配置;不得输出正文、草稿、大纲、示例通知、Word 文件或任何可替代正式写作结果。

如果 config.ini 不存在或脚本提示 API Key 缺失,先暂停原任务并向用户说明:

深知公文写作还没有配置 API Key。ClawHub Public 版不内置 API Key;如你同意,我可以通过深知 MaaS 注册接口协助完成手机号验证码注册,获取 API Key,并写入本 Skill 本地 config.ini。该文件会保存在当前 Skill 目录,仅供本地脚本使用,不会打包发布。

MaaS 管理平台地址是:https://platform.dknowc.cn/ 。新用户注册后会有 300 次体验额度;体验额度用完后,可到 MaaS 管理平台充值。完成实名认证后,平台也可能提供 100 元赠金,具体以 MaaS 平台页面展示为准。

只有用户明确同意由 Agent 协助注册后,才执行:

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

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

拿到验证码后执行:

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。配置写入成功后,重新运行 python3 scripts/initialize.py,确认 ready=true 后再继续处理用户原任务。

如用户不同意 Agent 协助注册,或接口失败、短信发送受限、验证码错误、手机号已注册,应停止注册流程,并给出 MaaS 管理平台地址作为手动方案:

https://platform.dknowc.cn/

工作原则

  • 首次使用时先运行 python3 scripts/initialize.py 检查 Python、依赖和搜索配置。初始化不要求用户提供单位或个人信息,也不上传检测结果。

  • Python、必备依赖和 API Key 属于前置条件:如无法运行 python3,或初始化结果显示 python_docx=falserequests=falseconfig_api_key=falseready=false,必须暂停执行 Skill,不得继续搜索、写作、生成 Word、生成红头或生成素材来源 HTML。

  • 发现 python-docxrequests 缺失且 dependency_install_prompt_needed=true 时,可以先向用户说明影响,并征得用户同意后执行 python3 -m pip install python-docx requests;未经用户同意不得自行安装依赖。安装后必须重新运行 python3 scripts/initialize.py 确认 ready=true 后再继续。如用户不同意安装依赖,执行 python3 scripts/initialize.py --decline-dependency-install 记录拒绝状态,后续不再反复询问,但仍因缺少必备依赖而暂停相关能力。

  • 如缺少 Python 或当前环境无权限安装依赖,应提示用户切换到具备 Python 的 Agent/运行环境,或由用户/平台管理员先完成 Python 与依赖安装。

  • config_api_key=false 时必须暂停本 Skill 全部能力,并提示用户先通过 ClawHub 初始化流程或 MaaS 管理平台在本地 config.ini[dkag] api_key 中配置有效 Key;如缺失,不得退化为纯 Word 写作。

  • 字体不作为 Skill 初始化阻断项,也不主动检测、安装或引导用户安装字体。Word 文档会写入公文常用字体名称;交付时简单提醒用户:如打开端缺少对应字体,Word/WPS 可能自动替换,需以本机打开后的显示为准。

  • 仅在用户明确同意保存常用设置时,使用 --save 写入本机 config/user_profile.json;不得主动索取与当前公文无关的信息。

  • 用户未配置发文机关、文号前缀或地域时,仍可生成文档:分别使用 XX单位XX〔年份〕XX号 等醒目占位符,地域则根据当前任务询问或保持未指定。交付时提醒用户核对占位符。

  • 不得根据示例、历史文档或搜索地域猜测用户所属单位,不得把任何具体客户名称作为默认值。

  • 简单短文本任务可以直接完成,不强制走完整流水线。

  • 正式写作需求优先调用 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”“先看文字草稿”时,才在聊天中输出正文全文。

  • 对长篇正式材料,不得先在对话中发送“正文初稿”“压缩版”“预览版”或完整正文;应直接生成 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。

  • 任一关键步骤出现异常时,必须暂停并向用户确认下一步;不得自行跳过搜索、改用 Web 搜索、改写任务目标或继续生成正式结果。

  • 生成前后按任务风险调用 reference/review_checklist.md

任务路由

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

常见路由:

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

范文大纲规则

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

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

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

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

触发范围:

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

可跳过范围:

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

大纲接口返回可用结果时,向用户展示:

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

用户可见确认内容必须使用清晰的 Markdown 分节和列表,不得把大纲、写作要点和搜索建议压缩成一个长段落,也不得只给“确认执行/调整后执行”而不展示可读结构。推荐格式:

我先根据范文库生成了参考大纲和后续搜索建议,请确认是否按这个结构继续,或告诉我需要调整哪些部分。

建议大纲:

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

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

后续搜索建议:

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

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

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

确认话术:

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

用户确认或修改后,再进入深知搜索方案设计。大纲接口返回的 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 生成;长篇正式材料不得把正文初稿作为聊天消息发出。
  10. 执行过搜索时,正式公文正文不再内嵌素材使用情况和知识专库链接;必须另行生成 标题_素材来源说明.html,以网页形式展示知识专库链接、素材溯源卡片和需人工核验的高风险信息。素材来源说明固定为 HTML,不生成 Word 版。
  11. 素材来源说明必须按 reference/search_guide.md 的固定流程生成:先整理结构化 JSON 到 official-docs/input/标题_素材来源说明.json,再调用 python3 scripts/source_note_html.py ... 输出 HTML。不得由模型手写完整 HTML,不得自行拼接 <a>onclick、按钮、卡片或页面样式。
  12. 素材来源说明中的知识专库链接必须来自每个原始搜索结果 JSON 的 knowledgeBasecontent.knowledgeBasesearch_meta.knowledgeBase 字段,并写入结构化 JSON 的 knowledge_bases[].url。不得使用占位链接、alert()、纯文本说明、搜索接口地址或无法点击的伪链接替代。

搜索异常处理:

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

外部搜索禁用规则:

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

搜索方案必须包含:

  • 搜索地域:使用用户任务对应的国家、省或市,不预设具体地区。
  • 搜索内容:每条 query 的目的。
  • 素材类型:仅列政策依据型、数据支撑型、参考案例型。表述参考型不作为独立搜索项,只从已召回材料中吸收表达方式。
  • 使用边界:哪些材料可作为政策依据,哪些只能作为案例或表述参考。
  • 面向用户展示搜索方案时,不得出现 --area--search-type--policy--search-channel--clean--output 等脚本参数,也不得设置名为“参数”的列或字段。执行参数只用于用户确认后的内部脚本调用。

搜索方案确认话术:

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

搜索命令:

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,避免写作场景下过度剔除材料。调用时不要额外传段落数量或精简参数。

合并命令:

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

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

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

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

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

高风险事实处理:

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

表格写作与排版规则:

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

审查规则

以下情况必须执行审查:

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

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

Word 输出

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

python3 scripts/initialize.py

如果 python3 不可运行,或初始化结果显示 ready=falsepython_docx=falserequests=falseconfig_api_key=false,必须先暂停,不得继续执行本 Skill 的搜索、写作、Word、红头和素材来源 HTML 生成。缺失 python-docxrequests 时,先请用户确认是否允许安装;用户同意后再执行:

python3 -m pip install python-docx requests

安装完成后重新运行初始化检查,确认通过后继续。

如果初始化结果显示 config_api_key=falsesearch_ready=false,必须暂停并提示用户配置本地 config.ini,不得继续执行纯 Word 或仅基于用户材料的写作。

字体不作为初始化阻断项,不主动检测、安装或引导用户安装字体。Word 文档会按配置写入公文常用字体名称;交付时只需提醒:如打开端缺少对应字体,Word/WPS 可能自动替换,需以本机打开后的显示为准。

用户明确授权保存常用设置时,才执行:

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

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

普通 Word:

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

调用前先把正文写入本 Skill 工作目录下的 official-docs/input/ 临时正文文件。默认保存到 config/format.jsonoutput.dir,且输出只能位于 official-docs/output/;脚本默认从正文标题生成正式文件名,并在同名文件已存在时追加 _v1_v2。如用户明确要求保存文件名,可传入 --output 文件名.docx。只有一句话以内的极短文本才允许使用 --text;多行正文不得直接通过命令行参数传入,避免换行被破坏后整篇文档变成一个段落。

红头 Word:

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”就先把正文粘贴到聊天窗口。