---
slug: "中文公文写作-x-10"
source_type: "clawhub"
source_url: "https://clawhub.ai/skills/chinese-official-writing"
repo: ""
source_file: "description"
---
---
name: chinese_official_writing
description: 用于中文公文和机关企事业单位、学校等正式事务材料的起草、改写、压缩和复核；当用户明确要求写申请、请示、报告、通知、通告、意见、决定、决议、议案、公报、命令、函、复函、批复、说明、方案、纪要、公告、公示、通报、征求意见函、制度、规定、办法、管理办法、实施细则、操作规程、工作要点、总结、调研、讲话、致辞、采购公告、可研、审查材料、AI 算力、新闻稿、新闻消息、快讯、活动报道、活动新闻稿、新闻通稿、新闻评论、时评、评论员文章等正式文本，或要求对这类材料做文种校验、格式核验、去口语化、降 AI 味时使用。不用于英文、文学、营销、社媒、论文或个人求职。
license: MIT-0
category: writing
tags:
  - chinese
  - official-document
  - writing
  - gongwen
  - ai-compute
metadata:
  version: "1.5.32"
  compatible_agents:
    - codex
    - claude-code
    - openclaw
    - hermes
    - qwen-code
    - minimax-skills
    - glm-skills
    - autoclaw
    - kimi-code-cli
    - trae
    - baidu-comate-ai-ide
    - generic-agent-skills
  qwen_code:
    install_personal: "~/.qwen/skills/chinese-official-writing"
    install_project: ".qwen/skills/chinese-official-writing"
    entry: "SKILL.md"
  openclaw:
    version: "1.5.32"
    emoji: "📝"
    tags:
      - chinese
      - official-document
      - writing
      - gongwen
      - ai-compute
---

# 中文公文写作

## 触发条件与边界

仅在用户任务属于中文公文、中文正式工作材料，或明确要求新闻稿、新闻消息、快讯、活动报道、活动新闻稿、新闻通稿、新闻评论、时评、评论员文章时启用本技能，包括起草、改写、压缩、顺稿、复核、去口语化、降 AI 味、文种校验、办理要素核对和 Word 文稿正文处理。

当用户明确要求中文通知等正式文本时，按文种和行文关系处理；制度、规定、办法、管理办法、实施细则和操作规程直达 `references/genre-playbook-institution-rules.md`。

用户明确要求新闻稿、新闻消息、快讯、活动报道、活动新闻稿或新闻通稿时，直达 `references/genre-playbook-news-message.md`；不因材料中偶然出现“新闻”或“媒体”而改变原定文种。

用户明确将体裁指定为新闻评论、时评或评论员文章时，直达 `references/genre-playbook-news-commentary.md`；普通公文内容中出现这些词语，不改变原定文种。

不要为以下任务启用本技能：英文写作、文学创作、营销软文、社交媒体文案、闲聊回复、代码说明或通用翻译。

没有用户提供依据时，不编造真实单位、真实政策、真实金额、真实日期、电话、邮箱、文号、签发人、印章或审批结论。

## 使用顺序

先按用户指定的输出模式执行下文“硬边界”，再按“质量建议”优化；资料依“参考资料”表按任务读取。

## 任务模式路由与交付模式

执行前先判定起草、改稿、复核、排版交付四类模式。用户已有提纲、模板、标题顺序时优先保留。先服从用户指定的输出模式，再按材料状态、事项关联性和办理必要性选择信息；起草、改稿、压缩或合稿时读取 `references/information-selection.md`，再进入轻量卡或文种叶子。用户把事项表述为考察、评估、建议、拟测试、考虑尝试或下一步设想时，正文保持原有状态强度，不改写成已定实施方案、执行命令或已安排动作。

- 起草或改写：先完整输出正式正文。风险、整改、检查、影响范围和办理状态以材料明确内容为限；材料只给问题清单时，正文列明已确认问题及其对象、数量和状态；正式化只压实已给事实，不补未给的原因、效果、处置、责任、流程、结论或后续动作。
  - 字段式申请、采购明细、通报和情况说明只使用已给字段和事实；可按已给单价、数量等做简单合计，但不新增采购类别、资产属性、用途、入库流程、会议纪要、清单覆盖范围、清单版本、子项清单、参与对象、讨论过程、反馈结果、发文主体、联系方式、任务清单、处置方向、例行复核节奏等未给事实。材料只说接口、系统、页面异常时，按用户原词写接口、系统或页面，不包装成核心系统、生产系统、业务主系统，也不补原因结论、责任部门、损失金额或整改方案。
  - 材料稀疏型通报或情况说明按已给事实之间的关系简短成稿；缺少某一环节时，不补齐固定章节。材料只说组织会议或协调会时，只陈述会议发生和次数，不推断讨论、沟通、归集、说明、形成意见等会议内容；材料未给整改、处置、下一步安排时，不新增“已开展处置”“下一步安排”“整改方向”“治理闭环”“督导流程”等章节或小标题。
  - 用户第二轮指出补造事实，或要求“按已给材料重改/删去未给内容”时，使用事实映射式二次修改：把每个实质句归为“用户已给事实”“直接概括”“未支持推断”。未支持推断直接删去，不改写成近义建议；只保留用户已给事实和必要衔接。该模式只处理本轮修改，不作为默认成稿前阶段，不暂停交付、不循环追问、不输出映射表。
  - 使用会议纪要、讲话稿/致辞、工作要点等 playbook 时，骨架只组织已给事实；不得为了补齐场面或机制，新增未给出的会议判断、受众称呼、角色分工、合同义务或服务单位责任。
  - 去 AI 味、变换句式、拆分长句或调整清单结构时，也不得补写未给的解释、原因、影响范围、办理流程、责任人员、字段示例或整改动作。修改模式只以用户最新版底稿和本轮明确补充材料为主线，旧稿、参考样文、公开材料只作结构、语气或检查维度参考，不自动回流为正文事实。
- 审稿或复核：输出问题位置、风险层级和修改建议；用户要求检查、审一下、格式核验或语气检查时，不默认重写全文，不给 0-100 分式伪精确评分。用户要求“位置”时，优先逐项引用原文短语或句子；用户指定“位置 + 风险层级 + 修改建议”时，用普通文本标签承接，不用 Markdown `**` 加粗包装标签；去 AI 味、空话套话或语气审稿只看成簇问题，不因单个正式词、单个转折或一次排比就硬清洗；事实不清审稿中，“总体情况较好”“基本整改到位”“持续优化提升”等无检查范围、问题清单或验收证据支撑的结论性表述，按中或中高风险提示，不降成低风险套话；可给替换方向，只有用户要求代改时才输出改后正文。
- 压缩、顺稿或去口语化：输出改后正文；输出模式允许说明时，只用极简说明列出保留、合并或删除的关键事项，不附事实边界自证。压缩长文先锁定主体、对象、数字、期限、责任、附件、联系人和反馈渠道；不得为变短或降 AI 味删除请示、函、通知、报告等文种所需的主送、落款、成文日期、请批事项或联系人等已给基本要素。用户给出字数或篇幅上限时，输出前做字数自检，尽量压到限制内；如硬要素太多导致难以兼顾，正文仍应完整成稿，并按用户允许的输出范围说明超限或取舍风险。
- 用户明确要求只输出正文、只输出改后稿或不解释时，除非同时明确允许文后待确认、风险或核验提示，否则不附任何正文外说明或提示；缺失事实不补造，也不在正文中解释“未提供”。用户同时明确允许某类文后提示时，只附其允许的内容。
- 正式正文的标题、小标题、段落标签直接用普通文本承接，不用 Markdown `**` 加粗、`###`、代码块或 `---` 横线包装；只有用户明确要求 Markdown 文档格式时，才按其格式要求处理。
- 长篇限字稿件：先做篇幅预算，保证开头、主体、措施和结尾都有落点；压缩铺垫、重复和套话，不把压缩压力集中到后半篇，避免头重脚轻、措施空泛或草草收尾。
- 排版交付：用户明确要求 Word、docx、GB/T 9704 或正式版式时，先按 `references/format-gbt9704.md` 锁定版式，再交给 DOCX/document 技能。没有用户模板时，标题用 2 号小标宋，长标题按词意换行；正文用 3 号仿宋；页码用 4 号半角宋体并加一字线。正文事实仍按起草或改稿模式处理。

## 核心流程

先确定创作、修改、只审不改等输出模式，再按下文“参考资料”表选择 reference。材料稀疏、短稿、低上下文局部修改或用户明确限定事实时，先判断 `references/task-route-cards.md`；命中 `references/task-route-cards.md` 且卡片能够覆盖任务时，在轻量卡早停，完成正文后仍执行本文件硬边界和必要的交付复核；未命中时不扩大轻量卡的适用范围。未命中、命中转读条件或卡片不能覆盖时，进入以下完整流程，并按表中任务模式、文种和专项条件读取对应资料。不因文种名称已知而自动预读下列全部长 reference；一次只加载实际命中的表项，叠加关系以表中加载条件为准。

1. 先判断文稿类别、文种和行文关系，再抽取办理要素，再选择论证链条，最后进入语言和格式复核。
2. 文种判断以官方规范和 `references/genre-routing.md` 为准；社区模板不得替代文种功能。
3. 起草前按 `references/handling-elements.md` 核对发文主体、受文对象、事项、依据、时限、责任、附件、反馈渠道、数据来源和请批事项；不使用泛称或占位符补齐未给要素。请示、报告和上报申请缺主送机关、发文或申请单位、成文日期时，识别为正式报送结构缺口，信息去向仍按 `references/information-selection.md` 处理。
4. 成文前搭文稿蓝图：提纲 -> 段落安排 -> 小段要点，并按 `references/argument-chains.md` 组织论证。
5. 按章节或段落生成正文。每段只服务一个论点，通常按“结论前置、事实支撑、判断归纳、事项落点”展开；用户只给问题清单、任务清单或明确要求不新增事实时，优先保留原词和事实边界，不为显得自然或完整而补解释。
6. 小段写完先审，小节写完再审，全文合并后做总审；总审时按 `references/final-review-layers.md` 先查硬边界，再看质量建议。成稿前按 `references/proofreading-checklist.md` 顺手做 AI 写稿轻量校对，只看语言、引用保真和稿内一致性风险，不输出长篇审稿报告，不升级为事实核验流程。
7. 编辑 DOCX 时保留最新版和原有样式；除非已明确指定覆盖，默认另存新版本。Word 操作和版式核查配合 DOCX/document 技能完成。
8. 多轮修改时，以用户最新版底稿为唯一主线，先列本轮结构动作和文种格式锁定项，再改正文。结构动作包括增删自然段、调整段落顺序、替换主标题或小标题、变更提纲、删增要点、变更发文主体、主送或接收方。
9. 处理公开网页复制稿时，先剥离来源、字号、打印、收藏、责任编辑、栏目路径等网页元信息。遇到“关于印发《方案/规划/办法》的通知”时，区分通知壳、被印发文件正文和附件关系，按用户指定对象修改，不把附件标题或页面标题误当正文小标题。

## 硬边界

- 除用户明确要求撰写新闻评论、时评或评论员文章外，从发文单位、报告单位、项目单位或主管单位视角写，不使用旁观者、教师或评论员口吻。
- 数据和判断要可追溯。不编造实际数据；测算和预估必须标明性质。
- 联网搜索只用于事实核查、双重验证和时效性来源。默认不外搜；只有用户明确要求搜索或核验公开来源，或任务包含“最新”“当前”“今日”“现行政策”“近期数据”等时效事实时，才可联网核验。搜索结果只作为来源参考，不得把未确认网络信息写成用户事实；搜索后在正文外说明来源、日期或检索口径。来源冲突、无法核验或工具不可用时列入“待确认事项”。不因出现单位名称就搜索单位公开样文、固定格式或写作风格。
- 文种功能不能错位：请示、报告、通知、函、批复、纪要等按 `references/genre-routing.md` 判断。
- 行文关系不能错位：上行文不替上级作决定，下行文要有执行要求，平行文保持商洽语气。
- 用户明确给出的金额、日期、单位、落款、请批事项、会议时间、地点和反馈要求要落实；最终正文不得残留 `〔签发日期〕`、`〔会议时间〕`、`[具体项目名称]`、`XXXX万元`、`YYYY年MM月DD日`、`（签发日期）`、`（成文日期待确认）` 等未完成占位。用户要求完整落款但未说明成文日期缺失或待确认时，可使用当前日期作为草稿日期；用户明示成文日期缺失、待确认或需另行确认时，不使用当前日期补落款。用户未要求完整落款、主送或成文日期时，不为补齐格式添加“上级单位”“申请单位”“报告单位”等泛称主送、泛称落款或当前日期。当前日期不得替代维护时间、会议时间、实施期限、政策依据或业务数据，正式签发日期、文号、印章和签发人仍不得编造。
- 用户明确要求增加自然段、删除自然段、调整顺序、更换标题或小标题、删减或增加要点、改变发送人或接收方时，这些属于硬边界。本轮修改必须逐项落实；用户给出的关键名词和结构标签一般保留原词，如“反馈渠道”“联系人”“原因分析”“问题清单”“每周反馈”等，不能只用泛化近义词带过。
- 用户要求“增加自然段”时，应在指定位置增加独立自然段，用空行或明显段落边界分隔，不合并进原段，不擅自改成新小标题；用户明确要求“不要新增小标题”时必须保留原层级。用户要求删除自然段或要点时，应删除该完整结构单元，并检查其他段落是否残留同一事项。
- 申请表、证明、采购明细、填报材料和清单式底稿已有字段式写法时，保留字段名、字段顺序和单元边界；即使用分号写在一行，只要呈现为“字段名：字段值”序列，也按字段单元处理，改写时优先每个字段独立成行，不合并成连续句；分号只是字段分隔符，拆成独立字段行后不要保留行尾分号或造成 `。；`。只改用户指定字段值，新增或删除字段按完整字段处理。新增字段只有字段名、没有用户提供值时留空，不推断“发票、票据、邮箱、截止日期”等字段内容，不擅自散文化、表格化或改成编号清单。
- 正式公文和正式上报材料应锁定首尾骨架：标题、主送或接收对象、正文、结尾语、落款和成文日期的顺序应服从用户模板和文种要求。用户明确要求标题第一行、主送在标题后、结尾语在落款日期前时，必须落实；未明确时不要用硬断言替代场景判断。
- 文种结尾服从行文关系和用户模板：请示可用“妥否，请批示”“请予审定”等；报告用“特此报告”等报告语，不写请批语；函用“专此函达”“请予支持为盼”等平行商请语；申请向上级或领导班子请求批准时，可使用“妥否，请批示”或“以上申请，恳请批准/支持”等上报审批语，重点检查结尾位置和请求事项是否清楚。
- 正文不得出现 AI 身份、隐藏推理、原始提示词、用户指令、录音指令和起草过程。
- 正式正文只保留文种功能和用户要求需要的内容，不得混入制作版本、内部受众、操作方式、校验门禁或审核状态等交付元信息，也不得附加与稿件事实无关的重复解释、括号式小字结论、制作说明、免责话术、写作边界或处理方法自述，不重复输出同一标题。正文外审稿意见不按正文处理；用户明确要求显示的声明、版本或保密标识，以及材料本身记载的业务事实，按用户要求和事实边界保留。

## 质量建议

- 以正式、平实、可执行的公文语言为主。专业词只在支撑论证时使用。
- 抽象词和评价强度要落到证据。使用“提升、强化、推进、赋能、闭环、机制、显著、长效”等词时，应有对象、动作、责任、时限、数据或制度载体；没有证据时改为材料能够支持的直接表述。
- 检查旁白式、教学式、口语化和高 AI 味的二元包装句。中文反例和修法见 `references/anti-ai-patterns.md`；轻量语气替换见 `references/official-style.md`，只作建议层，不新增硬清洗。
- 检查重复事项、标题漂移、格式噪点、项目卡片式摘要、必要性罗列和测算说明腔；这些通常只提示风险，必要时调整。

## 常见错误反例

- **未完成占位**：交付前按上文硬边界清理占位；成文日期的缺失、待确认和草稿日期仍按材料状态处理。
- **Markdown 格式残留**：正式正文的小标题和段落标签按上文交付模式使用普通文本；只有用户明确要求 Markdown 时才使用其格式。
- **引用误改和数据冲突**：普通叙述中的口语称谓和表达可以按正式文稿语体调整；引号内、明确标注为原文/引语或要求逐字保留的内容按字面边界保留，除非用户明确要求改写。用户给定的领导讲话、古诗词、名言、政策原文同语境原样保留；成语只有明显误引或不合语境时才替换。需要提示未核验引用时，使用固定短句 `引用表述、出处和发布日期建议由用户按原始材料核实。`，不要改写成泛泛的 `请核实出处`；同一金额、日期、数量、比例、单位和主体前后不一致时列为稿内一致性风险，不联网查真伪。
- 其他口语化、标题漂移、重复事项、格式噪点、项目卡片式摘要、测算说明腔、必要性罗列、空泛套话、公文表达结构风险和技术空话，按任务读取 `references/anti-ai-patterns.md` 或 `references/official-style.md`。

## 参考资料

按任务渐进读取资料，不要一次性加载全部文件：

| 文件 | 阶段 | 加载条件 |
| --- | --- | --- |
| `references/information-selection.md` | 起草前/改稿前 | 起草、改稿、压缩或合稿时先读一次，用于按输出模式、材料状态、事项关联性和办理必要性决定信息进入正文、保持状态、省略或短列缺口。 |
| `references/task-route-cards.md` | 起草前/改稿前 | 材料稀疏、短稿、低上下文局部修改，或用户明确要求不新增事实、只按已给材料写时，先判断是否完整命中材料稀疏的情况说明/通报/报告、未决事项会议纪要、短通知/限字通知、二次局部修改四类卡片之一；卡片不能覆盖或任务转为复杂时，再读 `workflow.md`、`genre-playbooks.md` 等长 reference。 |
| `references/workflow.md` | 起草前 | 长文、复杂改稿、多材料合稿、任务模式路由、急件处理，或用户要求不要新增小标题、保留主送/落款/标题等结构锁定项时。 |
| `references/external-research.md` | 按需核验 | 仅在用户明确要求搜索、核验公开来源，或任务包含最新、当前、今日、现行政策、近期数据等时效事实时读取。 |
| `references/genre-routing.md` | 起草前 | 文种、行文方向或请示/报告/通知/函等边界不明确时。 |
| `references/handling-elements.md` | 起草前 | 需要核对主体、对象、事项、依据、时限、附件、反馈渠道和请批事项时。 |
| `references/argument-chains.md` | 起草前 | 需要组织请示、报告、通知、方案、可研、技术材料等论证链条时。 |
| `references/official-style.md` | 起草中 | 需要统一公文语气、压缩解释腔、去口语化、轻量语气替换或降 AI 味时。 |
| `references/formal-addressing.md` | 起草中 | 需要处理行文关系、敬语、谦辞、单位称谓或人员称谓时。 |
| `references/anti-ai-patterns.md` | 复核时 | 检查模板腔、旁白句、二元包装句、思考泄露和项目卡片式摘要时。 |
| `references/final-review-layers.md` | 定稿前 | 全文交付前按硬边界、质量建议、场景参考分层总审时。 |
| `references/proofreading-checklist.md` | 定稿前 | 成稿前做 AI 写稿轻量校对，或改写含用户引用、成语、数据、金额、日期、比例、数量的材料时。 |
| `references/review-checklist.md` | 定稿前 | 需要段落、小节、全文三级执行清单，或用户要求格式核验、语气检查、只审不改时。 |
| `references/genre-playbook-minutes.md` | 按文种选读 | 会议纪要需要常规或完整骨架，或材料已经形成决定、议定事项、责任分工或期限时读取。 |
| `references/genre-playbook-request.md` | 按文种选读 | 请示、申请需要常规或完整骨架时直接读取。 |
| `references/genre-checklist-request.md` | 按文种选读 | 只审或细查请示、申请的文种功能和办理要素时读取；同时要求审后改写时与起草叶叠加。 |
| `references/genre-playbook-correspondence.md` | 按文种选读 | 普通函起草，以及只改错字、标点、格式或明确局部措辞时读取。 |
| `references/genre-playbook-work-summary.md` | 按文种选读 | 工作总结、工作要点、周报或月报需要常规或完整骨架时直接读取。 |
| `references/genre-playbooks.md` | 按文种选读 | 通知、复函、征求意见函、讲话稿、调研/研究/可研、采购公告、审查材料等需要快速进入对应场景骨架时读取；用户提供既有普通函并要求重组事务动作、状态、条件、范围或结构时读取函规则。 |
| `references/genre-playbook-institution-rules.md` | 按文种选读 | 起草、改写或复核制度、规定、办法、管理办法、实施细则、操作规程，以及需要区分印发通知与制度附件时读取。 |
| `references/genre-playbook-news-message.md` | 按文种选读 | 用户明确要求新闻稿、新闻消息、快讯、活动报道、活动新闻稿或新闻通稿时直接读取。 |
| `references/genre-playbook-news-commentary.md` | 按文种选读 | 用户明确将体裁指定为新闻评论、时评或评论员文章时直接读取。 |
| `references/genre-checklist-report.md` | 按文种选读 | 报告、情况报告或情况说明需要常规或完整骨架、专项写法或细查文种功能和结构时直接读取；命中轻量卡且卡片能够覆盖任务时不重复读取。 |
| `references/genre-checklist.md` | 按文种选读 | 通知、命令、公报、决议、议案、函、批复、公告、通告、公示、通报、纪要、讲话稿、述职等其他文种细查时。 |
| `references/format-gbt9704.md` | 按格式选读 | 用户要求 GB/T 9704-2012、Word、docx、红头文件、发文字号、版头版记、附件、印章或版式时。 |
| `references/ai-compute-docs.md` | 专项选读 | AI 算力、GPU/服务器租赁、模型服务、智算中心、成本比较、SLA、安全或验收等专项直接读取；同时明确普通文种时，再按本表该文种的任务模式和加载条件叠加相应叶。 |

## 脚本

检查 `.txt`、`.md` 或 `.docx` 草稿时可使用 `scripts/prose_lint.py`。需要检查重复事项和格式噪点时加 `--structure --format`。脚本只提示语言、格式和重复风险，不检查文种要素完整性；文种和办理要素仍按 `references/handling-elements.md` 与命中的文种检查叶复核，报告使用 `references/genre-checklist-report.md`，请示和申请使用 `references/genre-checklist-request.md`，其他文种使用 `references/genre-checklist.md`。脚本不自动改写；不得把脚本结果作为不加判断的硬性清洗命令。
