中文公文写作

使用本技能生成或修改中文正式文稿。最终文本应像文稿正文，而不是写作说明、概念讲解或外部顾问点评。

触发条件与边界

仅在用户任务属于中文公文或中文正式工作材料时启用本技能，包括起草、改写、压缩、顺稿、复核、去口语化、降 AI 味、文种校验、办理要素核对和 Word 文稿正文处理。

当用户明确要求中文通知、请示、报告、函、复函、批复、意见、决定、公告、通告、公示、通报、会议纪要、方案、说明、申请、工作总结、调研报告、可研报告、实施方案、建设方案、讲话稿、致辞、述职报告等正式文本时，按本文种和行文关系处理。

不要为以下任务启用本技能：英文写作、文学创作、营销软文、社交媒体文案、闲聊回复、代码说明、通用翻译、模型训练、批量语料生成、批量改写未知来源文本、规避人工审核、生成可冒充真实签发文件的完整编号/日期/印章信息。

本技能只提供写作和复核辅助，不替代法律/财务/采购/审计/政策依据判断。保密审查和正式签发结论必须保留人工复核；没有用户提供依据时，不编造真实单位、真实政策、真实金额、真实日期、电话、邮箱、文号、签发人、印章或审批结论。

三层使用原则

1. 硬边界：事实不编造、文种不错、行文关系不错、用户明确要求不丢、敏感信息不外泄、过程说明不进正文。用户写明“材料只有”“不新增事实”“不要编造”时，只能组织已给事实，不把概括动作扩展成未给的子项清单、参与对象、讨论过程、反馈结果、发文主体、联系方式、任务清单、处置方向或已形成材料，也不把用户点名禁止编造的字段写成正文中的“未提供”说明。篇幅要求不改变事实边界，不为凑篇幅补主体、流程、产物、范围、责任或联系方式；也不要用“基础底稿、基础清单、台账化、过程可追踪、统一督导流程”等近义包装绕开用户禁止的清单、台账、闭环或督办。正式正文默认用纯文本标题和小标题，第一行标题也不用 Markdown 加粗、井号标题、代码块或横线包装。涉及这些问题时按交付风险处理，必须优先修正。
2. 质量建议：低 AI 味、重复事项、表达松散、结构不顺、格式噪点、AI 写稿轻量校对、项目卡片式摘要、必要性罗列和测算说明腔，只作质量提示。检查后按文稿用途、用户模板和材料场景必要时调整，不作为自动阻断。
3. 场景参考：先读核心资料，再按任务读取文种 playbook、格式、称谓、算力或 DOCX 相关资料；不要一次性加载全部资料。

任务模式路由与交付模式

执行前先判定起草、改稿、复核、排版交付四类模式。用户已有提纲、模板、标题顺序时优先保留。先服从用户指定的输出模式，再按材料状态、事项关联性和办理必要性选择信息；起草、改稿、压缩或合稿时读取 references/information-selection.md，再进入轻量卡或文种叶子。用户把事项表述为考察、评估、建议、拟测试、考虑尝试或下一步设想时，正文保持原有状态强度，不改写成已定实施方案、执行命令或已安排动作。

• 起草或改写：先完整输出正式正文。风险、整改、检查、影响范围和办理状态以材料明确内容为限；材料只给问题清单时，正文列明已确认问题及其对象、数量和状态；正式化只压实已给事实，不补未给的原因、效果、处置、责任、流程、结论或后续动作。
  • 字段式申请、采购明细、通报和情况说明只使用已给字段和事实；可按已给单价、数量等做简单合计，但不新增采购类别、资产属性、用途、入库流程、会议纪要、清单覆盖范围、清单版本、子项清单、参与对象、讨论过程、反馈结果、发文主体、联系方式、任务清单、处置方向、例行复核节奏等未给事实。材料只说接口、系统、页面异常时，按用户原词写接口、系统或页面，不包装成核心系统、生产系统、业务主系统，也不补原因结论、责任部门、损失金额或整改方案。
  • 材料稀疏型通报或情况说明按已给事实之间的关系简短成稿；缺少某一环节时，不补齐固定章节。材料只说组织会议或协调会时，只陈述会议发生和次数，不推断讨论、沟通、归集、说明、形成意见等会议内容；材料未给整改、处置、下一步安排时，不新增“已开展处置”“下一步安排”“整改方向”“治理闭环”“督导流程”等章节或小标题。
  • 用户第二轮指出补造事实，或要求“按已给材料重改/删去未给内容”时，使用事实映射式二次修改：把每个实质句归为“用户已给事实”“直接概括”“未支持推断”。未支持推断直接删去，不改写成近义建议；只保留用户已给事实和必要衔接。
  • 使用会议纪要、讲话稿/致辞、工作要点等 playbook 时，骨架只组织已给事实；不得为了补齐场面或机制，新增未给出的会议判断、受众称呼、角色分工、合同义务或服务单位责任。
  • 去 AI 味、变换句式、拆分长句或调整清单结构时，也不得补写未给的解释、原因、影响范围、办理流程、责任人员、字段示例或整改动作。修改模式只以用户最新版底稿和本轮明确补充材料为主线，旧稿、参考样文、公开材料只作结构、语气或检查维度参考，不自动回流为正文事实。
• 审稿或复核：输出问题位置、风险层级和修改建议；用户要求检查、审一下、格式核验或语气检查时，不默认重写全文，不给 0-100 分式伪精确评分。用户要求“位置”时，优先逐项引用原文短语或句子；用户指定“位置 + 风险层级 + 修改建议”时，用普通文本标签承接，不用 Markdown ** 加粗包装标签；去 AI 味、空话套话或语气审稿只看成簇问题，不因单个正式词、单个转折或一次排比就硬清洗；事实不清审稿中，“总体情况较好”“基本整改到位”“持续优化提升”等无检查范围、问题清单或验收证据支撑的结论性表述，按中或中高风险提示，不降成低风险套话；可给替换方向，只有用户要求代改时才输出改后正文。
• 压缩、顺稿或去口语化：输出改后正文；输出模式允许说明时，只用极简说明列出保留、合并或删除的关键事项，不附事实边界自证。压缩长文先锁定主体、对象、数字、期限、责任、附件、联系人和反馈渠道；不得为变短或降 AI 味删除请示、函、通知、报告等文种所需的主送、落款、成文日期、请批事项或联系人等已给基本要素。用户给出字数或篇幅上限时，输出前做字数自检，尽量压到限制内并留出 5%-10% 余量；如硬要素太多导致难以兼顾，正文仍应完整成稿，并按用户允许的输出范围说明超限或取舍风险。
• 用户明确要求只输出正文、只输出改后稿或不解释时，除非同时明确允许文后待确认、风险或核验提示，否则不附任何正文外说明或提示；缺失事实不补造，也不在正文中解释“未提供”。用户同时明确允许某类文后提示时，只附其允许的内容。
• 正式正文的标题、小标题、段落标签直接用普通文本承接，不用 Markdown ** 加粗、###、代码块或 --- 横线包装；只有用户明确要求 Markdown 文档格式时，才按其格式要求处理。
• 长篇限字稿件：先做篇幅预算，保证开头、主体、措施和结尾都有落点；压缩铺垫、重复和套话，不把压缩压力集中到后半篇，避免头重脚轻、措施空泛或草草收尾。
• 排版交付：用户明确要求 Word、docx、GB/T 9704、红头、发文字号、签发、版记或正式文件时，先做正式交付前要素核对卡，再按 references/format-gbt9704.md 交给 DOCX/document 技能或现有文档工具处理；正文是否已定稿不明时标“待确认”，不要写成“已确认可作为 Word 稿基础”。用户已点名缺少文号、签发人、版记等具体要素时，核对卡优先只列这些点名要素，其他正式要素用一句“按单位模板另行核对”概括，不展开成长清单；不得编造文号、密级、签发人、印章、版记或正式签发信息，正式 Word 输出前不得残留 Markdown **、代码块或 ### 标题标记。

核心流程

先确定创作、修改、只审不改等输出模式，再选择 reference。材料稀疏、短稿、低上下文局部修改，或用户明确要求“不新增事实”“只按已给材料写”时，先判断是否完整命中 references/task-route-cards.md 的四类卡片之一；未命中时不扩大轻量卡的适用范围。命中 references/task-route-cards.md 且卡片能够覆盖任务时，以轻量卡片完成正文，再执行本文件硬边界和必要的交付复核；不因文种名称已知而自动预读下列全部长 reference。文种明确且需要常规或完整骨架时，可从本文件直接进入 references/genre-playbooks.md 的对应叶子。只有命中轻量卡写明的转读条件，或任务确需完整骨架、论证、格式/专项处理时，才进入以下完整流程并按需读取对应资料。

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，只作建议层，不新增硬清洗。
• 检查重复事项、标题漂移、格式噪点、项目卡片式摘要、必要性罗列和测算说明腔；这些通常只提示风险，必要时调整。
• 起草算力、采购、租赁或服务器租赁材料时，论证重点放在需求从哪里来、Token/资源如何换算成费用、节省或锁定了哪些成本，以及 SLA、并发、安全、交付和验收如何落实。

常见错误反例

定稿前用以下核心反例快速自查：

• 视角错位：检查是否像外部顾问讲解“报告应该怎么写”，改为从发文或项目主体视角说明本单位拟做什么、为什么做、如何做。
• 行文关系和文种错位：请示不能替上级作结论，报告不得夹带审批请求，函不能写成命令或请示，批复不能没有同意与否的答复。
• 首尾错位：在文种或用户模板要求明确时，检查标题、主送或接收对象、正文、结尾语、落款和成文日期顺序；请批、申请、报告或函件结尾语通常不应排在落款和成文日期后。
• 未完成占位：交付正文前删除或处理 〔签发日期〕、〔会议时间〕、〔待补充〕、[具体项目名称]、XXXX万元、X项、YYYY年MM月DD日、（签发日期）、（成文日期待确认） 等占位；成文日期明示缺失或待确认时不使用当前日期，不能把占位或当前日期混入落款区。
• Markdown 格式残留：活动方案、实施方案等长稿正文的小标题用 一、、（一）、1. 或普通小标题承接，不用 **加粗**、###、--- 横线或代码块包装正式正文。
• 引用误改和数据冲突：普通叙述中的口语称谓和表达可以按正式文稿语体调整；引号内、明确标注为原文/引语或要求逐字保留的内容按字面边界保留，除非用户明确要求改写。用户给定的领导讲话、古诗词、名言、政策原文同语境原样保留；成语只有明显误引或不合语境时才替换。需要提示未核验引用时，使用固定短句 引用表述、出处和发布日期建议由用户按原始材料核实。，不要改写成泛泛的 请核实出处；同一金额、日期、数量、比例、单位和主体前后不一致时列为稿内一致性风险，不联网查真伪。
• 其他口语化、标题漂移、重复事项、格式噪点、项目卡片式摘要、测算说明腔、必要性罗列、空泛套话、公文表达结构风险和技术空话，按任务读取 references/anti-ai-patterns.md 或 references/official-style.md。

参考资料

按任务渐进读取资料，不要一次性加载全部文件：

脚本

检查 .txt、.md 或 .docx 草稿时可使用 scripts/prose_lint.py。需要检查重复事项和格式噪点时加 --structure --format；CI 或发布检查需要忽略 low 级提示时可用 --strict --fail-on medium。脚本只提示语言、格式和重复风险，不检查文种要素完整性；文种和办理要素仍按 references/handling-elements.md、references/genre-checklist.md 与人工/LLM 复核判断。脚本不自动改写；不得把脚本结果作为不加判断的硬性清洗命令。