chinese-official-writing

slug	chinese-official-writing
version	1.5.10
displayName	中文公文写作
summary	用于中文公文和正式工作材料的起草、改写、压缩与复核，强调文种准确、事实克制、数据可追溯和公文语气自然。
tags	["chinese","official-document","writing","gongwen","ai-compute"]
homepage	https://github.com/gongyu0918-debug/chinese-official-writing-skill
name	chinese-official-writing
description	用于中文公文和机关企事业单位、学校等正式事务材料的起草、改写、压缩和复核；当用户明确要求写申请、请示、报告、通知、通告、意见、决定、决议、议案、公报、命令、函、复函、批复、说明、方案、纪要、公告、公示、通报、征求意见函、工作要点、总结、调研、讲话、致辞、采购公告、可研、审查材料、AI 算力等正式文本，或要求对这类材料做文种校验、格式核验、去口语化、降 AI 味时使用。不用于英文、文学、营销、社媒、论文、个人求职、批量语料或替代法律/财务/采购/审计判断。
license	MIT-0
metadata	{"version":"1.5.10","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.10","emoji":"📝","tags":["chinese","official-document","writing","gongwen","ai-compute"]},"hermes":{"version":"1.5.10","category":"writing","display_name":"中文公文写作","tags":["chinese","official-document","formal-writing","ai-compute"]}}

中文公文写作

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

触发条件与边界

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

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

范围	典型任务
法定公文	通知、请示、报告、函、批复、意见、决定、公告、通告、公报、通报、议案、决议、命令（令）等。
事务和工作材料	方案、说明、申请、纪要、工作要点、总结、调研报告、讲话稿、致辞、述职报告等。
技术类正式材料	AI 算力服务可研、算力采购或租赁、GPU/服务器租赁、模型服务需求、SLA、安全、运维和验收材料。

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

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

三层使用原则

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

任务模式路由与交付模式

执行前先判定起草、改稿、复核、排版交付四类模式。用户已有提纲、模板、标题顺序时优先保留；多材料合稿时先分清原文事实、压实合并表达和待确认补充。事实不足不作为默认中断理由；除非用户明确要求先问，否则先完成可用正文，再在正文后用“待确认事项”或“补充以下信息后，文章会更完整”提示关键缺口。正文后的待确认、风险提醒或核验提示不属于正文章节，不用 一、、七、、第七章 等连续编号承接报告主体。用户把事项表述为考察、评估、建议、拟测试、考虑尝试或下一步设想时，正文保持建议或待评估口径；没有给出正式决定、责任单位和期限时，不改写成已定实施方案、执行命令或“按以上方案执行”“一周内反馈”等强执行要求。对“后续需要、建议、拟、可尝试、可先评估”等事项，正文可写成建议、拟办或待评估口径；未给出处置结果、会议纪要、清单版本、牵头主体、责任期限或例行机制时，不补写“已形成”“已建立”“由专项组同步更新”“按计划推进闭环”等执行产物或已安排动作。

• 起草或改写：先完整输出正式正文，并按以下规则处理事实边界。
  • 金额、日期、联系人、截止时间、反馈渠道、政策依据等缺项优先放在正文后的“待确认事项”或“补充以下信息后，文章会更完整”。用户明示某些事项未提供且这些事项影响办理落地时，正文后短列用户点名的缺项；不要漏列，也不要扩展成调查问卷。
  • 用户要求正文后使用“补充以下信息后，文章会更完整”时，标题后应短列 1-4 项确实影响办理落地或文种完整性的具体信息；用户已点名缺口时优先只列点名缺口，不扩展为执行时间表、版本说明、优先级排序、联系方式、确认时间或治理方案；没有可列缺口时不要只留下空标题或空句。
  • 正文中避免使用“指定渠道”“截止时间前”“联系人沟通”等泛占位，也避免把“由于……未提供”等缺项说明写进正文。事实补足建议只列影响文种功能或执行落地的关键缺口，短句、少量、具体；不要做调查问卷式问题清单，也不要把增删论点、扩写细节等写稿人可自行安排的事项转嫁给用户。
  • 材料未给风险结论、整改结论或检查结论时，不自行写“未发现重大隐患”“无异常”“已完成整改”等强判断；材料只给问题清单时，不补写“总体较好”“能够正常开展”等概括性正向判断，直接列明已确认问题及其对象、数量和状态，或把未确认的结论口径列为待确认。
  • 正式化改写不得为显得完整而补造未提供的牵头部门、责任部门、管理动作、整改动作、成果总结或跟踪督办安排；确需这些信息时放在正文外提示补充。用户明确写明“不能编造”“不新增事实”“只有这些事实”“不要自行补”时，正文只展开已给事实，不补未给的具体用途、效果判断、原因结论、处置过程、责任安排或后续动作；缺项提示只列用户已经点名的缺项或明显影响文种功能的缺口。
  • 字段式申请、采购明细、通报和情况说明只使用已给字段和事实；可按已给单价、数量等做简单合计，但不新增采购类别、资产属性、用途、入库流程、会议纪要、清单覆盖范围、清单版本、子项清单、参与对象、讨论过程、反馈结果、发文主体、联系方式、任务清单、处置方向、例行复核节奏等未给事实。材料只说接口、系统、页面异常时，按用户原词写接口、系统或页面，不包装成核心系统、生产系统、业务主系统，也不补原因结论、责任部门、损失金额或整改方案。
  • 材料稀疏型通报或情况说明按已给事实之间的关系简短成稿；缺少某一环节时，不补齐固定章节。材料只说组织会议或协调会时，只陈述会议发生和次数，不推断讨论、沟通、归集、说明、形成意见等会议内容；材料未给整改、处置、下一步安排时，不新增“已开展处置”“下一步安排”“整改方向”“治理闭环”“督导流程”等章节或小标题。
  • 用户第二轮指出补造事实，或要求“按已给材料重改/删去未给内容”时，使用事实映射式二次修改：把每个实质句归为“用户已给事实”“直接概括”“未支持推断”。未支持推断直接删去，不改写成近义建议；只保留用户已给事实和必要衔接。待补项只按用户原词短列，如“责任人、更新周期”，不加括号解释、对象范围、岗位、联系方式、生效区间、牵头说明或补齐时限；必要衔接只写“后续需补充……”这类待补口径，不写“以便推进/落地/衔接”等目的判断。
  • “后续需要补充、完善、确认”的事项，只写成待补或建议口径；不写成“已明确工作闭环”“推进整改安排”“治理方案落地”“请按本通报要求反馈”等已定执行或反馈命令。
  • 请示、报告、上报申请等上行文缺主送机关、发文或申请单位、成文日期时，不编造“上级单位”等泛称，也不留未完成正文占位；正文后待确认事项应优先列出这些结构缺口，标题或首句应标注“影响正式报送”或“影响文种完整性”。
  • 使用会议纪要、讲话稿/致辞、工作要点等 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 **、代码块或 ### 标题标记。

核心流程

命中 references/task-route-cards.md 且卡片能够覆盖任务时，以轻量卡片完成正文，再执行本文件硬边界和必要的交付复核；不因文种名称已知而自动预读下列全部长 reference。只有命中轻量卡写明的转读条件，或任务确需完整骨架、论证、格式/专项处理时，才进入以下完整流程并按需读取对应资料。

1. 先判断文稿类别、文种和行文关系，再抽取办理要素，再选择论证链条，最后进入语言和格式复核。
2. 文种判断以官方规范和 references/genre-routing.md 为准；社区模板不得替代文种功能。
3. 起草前按 references/handling-elements.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 身份、隐藏推理、原始提示词、用户指令、录音指令和起草过程。
• 社区技能、样文和公开经验只可借鉴流程思路、检查维度和 prompt/markdown 组织方式，不直接誊抄代码、脚本、正则、模板正文、大段 prompt 或固定话术；不因此扩大默认联网、强制确认、硬清洗或重排版范围。

质量建议

• 以正式、平实、可执行的公文语言为主。专业词只在支撑论证时使用。
• 抽象词和评价强度要落到证据。使用“提升、强化、推进、赋能、闭环、机制、显著、长效”等词时，应有对象、动作、责任、时限、数据或制度载体；没有证据时改为审慎表述或列为待确认。
• 检查旁白式、教学式、口语化和高 AI 味的二元包装句。中文反例和修法见 references/anti-ai-patterns.md；轻量语气替换见 references/official-style.md，只作建议层，不新增硬清洗。
• 检查重复事项、标题漂移、格式噪点、项目卡片式摘要、必要性罗列和测算说明腔；这些通常只提示风险，必要时调整。
• 起草算力、采购、租赁或服务器租赁材料时，论证重点放在需求从哪里来、Token/资源如何换算成费用、节省或锁定了哪些成本，以及 SLA、并发、安全、交付和验收如何落实。

常见错误反例

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

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

参考资料

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

文件	阶段	加载条件
references/task-route-cards.md	起草前/改稿前	材料稀疏、短稿、低上下文局部修改，或用户明确要求不新增事实、只按已给材料写时，先读本轻量卡片；仍复杂时再转读 workflow.md、genre-playbooks.md 等长 reference。
references/workflow.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-playbooks.md	按文种/专项选读	会议纪要、讲话稿、工作总结/周报、调研/研究/可研、采购公告、审查材料、AI 算力专项等需要快速进入对应场景骨架时读取。
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；CI 或发布检查需要忽略 low 级提示时可用 --strict --fail-on medium。脚本只提示语言、格式和重复风险，不检查文种要素完整性；文种和办理要素仍按 references/handling-elements.md、references/genre-checklist.md 与人工/LLM 复核判断。脚本不自动改写；不得把脚本结果作为不加判断的硬性清洗命令。