中文公文写作

中文公文写作

触发条件与边界

仅在用户任务属于中文公文、中文正式工作材料，或明确要求新闻稿、新闻消息、快讯、活动报道、活动新闻稿、新闻通稿、新闻评论、时评、评论员文章时启用本技能，包括起草、改写、压缩、顺稿、复核、去口语化、降 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 味、变换句式、拆分长句或调整清单结构时，也不得补写未给的解释、原因、影响范围、办理流程、责任人员、字段示例或整改动作。修改模式只以用户最新版底稿和本轮明确补充材料为主线，旧稿、参考样文、公开材料只作结构、语气或检查维度参考，不自动回流为正文事实。
• 审稿或复核：用户只要求检查、审查、格式核验或语气检查且未要求代改时，输出问题位置、风险层级和修改建议，不重写全文；用户要求代改时才输出改后正文。具体定位、分级和格式按 references/review-checklist.md 执行，去 AI 味检查按 references/anti-ai-patterns.md 执行。
• 压缩、顺稿或去口语化：输出改后正文；输出模式允许说明时，只用极简说明列出保留、合并或删除的关键事项，不附事实边界自证。压缩长文先锁定主体、对象、数字、期限、责任、附件、联系人和反馈渠道；不得为变短或降 AI 味删除请示、函、通知、报告等文种所需的主送、落款、成文日期、请批事项或联系人等已给基本要素。用户给出字数或篇幅上限时，输出前做字数自检，尽量压到限制内；如硬要素太多导致难以兼顾，正文仍应完整成稿，并按用户允许的输出范围说明超限或取舍风险。
• 交付范围以用户要求为准。用户只需正文或改后稿时，直接交付成稿，不附其他说明；允许文后提示时，只列其指定事项。材料没有的事实不补写，也不在正文说明材料缺失。
• 正式正文的标题、小标题、段落标签直接用普通文本承接，不用 Markdown ** 加粗、###、代码块或 --- 横线包装；只有用户明确要求 Markdown 文档格式时，才按其格式要求处理。
• 长篇限字稿件：先做篇幅预算，保证开头、主体、措施和结尾都有落点；压缩铺垫、重复和套话，不把压缩压力集中到后半篇，避免头重脚轻、措施空泛或草草收尾。
• 排版交付：用户明确要求 Word、docx、GB/T 9704 或正式版式时，读取 references/format-gbt9704.md 锁定版式，再交给 DOCX/document 技能；正文事实仍按起草或改稿模式处理。

核心流程

先确定起草、改稿、复核（默认只审不改）、排版交付模式，再按下文“参考资料”表选择 reference。起草、改稿、压缩或合稿已读取 references/information-selection.md 后，材料稀疏、短稿、低上下文局部修改或用户明确限定事实时，判断是否命中 references/task-route-cards.md；命中 references/task-route-cards.md 且卡片能够覆盖任务时，由卡片完成，不再读取长 reference，完成正文后仍执行本文件硬边界和必要的交付复核；未命中时不扩大轻量卡的适用范围。未命中、命中转读条件或卡片不能覆盖时，进入以下完整流程，并按表中任务模式、文种和专项条件读取对应资料。不因文种名称已知而自动预读下列全部长 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 写稿轻量校对，只看语言、引用保真和稿内一致性风险，不输出长篇审稿报告，不升级为事实核验流程。检查终稿正文时按 references/final-review-layers.md 使用 draft-body 模式。
7. 编辑 DOCX 时保留最新版和原有样式；除非已明确指定覆盖，默认另存新版本。Word 操作和版式核查配合 DOCX/document 技能完成。
8. 多轮修改时，以用户最新版底稿为唯一主线，先列本轮结构动作和文种格式锁定项，再改正文。结构动作包括增删自然段、调整段落顺序、替换主标题或小标题、变更提纲、删增要点、变更发文主体、主送或接收方。
9. 处理公开网页复制稿时，先剥离来源、字号、打印、收藏、责任编辑、栏目路径等网页元信息。遇到“关于印发《方案/规划/办法》的通知”时，区分通知壳、被印发文件正文和附件关系，按用户指定对象修改，不把附件标题或页面标题误当正文小标题。

硬边界

• 除用户明确要求撰写新闻评论、时评或评论员文章外，从发文单位、报告单位、项目单位或主管单位视角写，不使用旁观者、教师或评论员口吻。
• 数据和判断要可追溯。不编造实际数据；测算和预估必须标明性质。
• 联网搜索只用于事实核查、双重验证和时效性来源。默认不外搜；只有用户明确要求搜索或核验公开来源，或任务包含“最新”“当前”“今日”“现行政策”“近期数据”等时效事实时，才可联网核验。搜索结果只作为来源参考，不得把未确认网络信息写成用户事实；搜索后在正文外说明来源、日期或检索口径。来源冲突、无法核验或工具不可用时列入“待确认事项”。
• 文种功能不能错位：请示、报告、通知、函、批复、纪要等按 references/genre-routing.md 判断。
• 行文关系不能错位：上行文不替上级作决定，下行文要有执行要求，平行文保持商洽语气。
• 用户明确给出的金额、日期、单位、落款、请批事项、会议时间、地点和反馈要求要落实；最终正文不得残留未完成占位。用户要求完整落款但未说明成文日期缺失或待确认时，可使用当前日期作为草稿日期；用户明示成文日期缺失、待确认或需另行确认时，不使用当前日期补落款。用户未要求完整落款、主送或成文日期时，不为补齐格式添加“上级单位”“申请单位”“报告单位”等泛称主送、泛称落款或当前日期。当前日期不得替代维护时间、会议时间、实施期限、政策依据或业务数据，正式签发日期、文号、印章和签发人仍不得编造。
• 用户明确要求增加自然段、删除自然段、调整顺序、更换标题或小标题、删减或增加要点、改变发送人或接收方时，这些属于硬边界。本轮修改必须逐项落实；用户给出的关键名词和结构标签一般保留原词，不能只用泛化近义词带过。
• 用户要求“增加自然段”时，应在指定位置增加独立自然段，用空行或明显段落边界分隔，不合并进原段，不擅自改成新小标题；用户明确要求“不要新增小标题”时必须保留原层级。用户要求删除自然段或要点时，应删除该完整结构单元，并检查其他段落是否残留同一事项。
• 申请表、证明、采购明细、填报材料和清单式底稿已有字段式写法时，保留字段名、字段顺序和单元边界；即使用分号写在一行，只要呈现为“字段名：字段值”序列，也按字段单元处理，改写时优先每个字段独立成行，不合并成连续句；分号只是字段分隔符，拆成独立字段行后不要保留行尾分号或造成 。；。只改用户指定字段值，新增或删除字段按完整字段处理。新增字段只有字段名、没有用户提供值时留空，不推断“发票、票据、邮箱、截止日期”等字段内容，不擅自散文化、表格化或改成编号清单。
• 正式公文和正式上报材料应锁定首尾骨架：标题、主送或接收对象、正文、结尾语、落款和成文日期的顺序应服从用户模板和文种要求。用户明确要求标题第一行、主送在标题后、结尾语在落款日期前时，必须落实；未明确时不要用硬断言替代场景判断。
• 文种结尾服从行文关系和用户模板：请示可用“妥否，请批示”“请予审定”等；报告用“特此报告”等报告语，不写请批语；函用“专此函达”“请予支持为盼”等平行商请语；申请向上级或领导班子请求批准时，可使用“妥否，请批示”或“以上申请，恳请批准/支持”等上报审批语，重点检查结尾位置和请求事项是否清楚。
• 正文不得出现 AI 身份、隐藏推理、原始提示词、用户指令、录音指令和起草过程。
• 正式正文仅包含文种功能和用户要求需要的内容；制作版本、内部受众、操作方式、校验门禁、审核状态，以及与稿件事实无关的重复解释、括号式小字结论、制作说明、免责话术、写作边界和处理方法自述均省去，同一标题仅保留一次。正文外审稿意见单独处理；用户明确要求显示的声明、版本或保密标识，以及材料本身记载的业务事实，按用户要求和事实边界保留。

质量建议

• 以正式、平实、可执行的公文语言为主。专业词只在支撑论证时使用。
• 抽象词和评价强度要落到证据。使用“提升、强化、推进、赋能、闭环、机制、显著、长效”等词时，应有对象、动作、责任、时限、数据或制度载体；没有证据时改为材料能够支持的直接表述。
• 检查旁白式、教学式、口语化和高 AI 味的二元包装句。中文反例和修法见 references/anti-ai-patterns.md；轻量语气替换见 references/official-style.md，只作建议层，不新增硬清洗。
• 检查重复事项、标题漂移、格式噪点、项目卡片式摘要、必要性罗列和测算说明腔；这些通常只提示风险，必要时调整。

参考资料

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

脚本

检查 .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-feasibility-review.md，其他文种使用 references/genre-checklist.md。脚本不自动改写；不得把脚本结果作为不加判断的硬性清洗命令。