Gongwen Direct skill

去防御性写作（gongwen-direct）

AI 写的公文常给自己留后路：结尾挂“仅供参考”，部署写成“建议各单位可以考虑”，请示不说倾向，批复不说同意还是不同意。本 skill 把这些话改成态度明确、措辞分层的公文表述，同时守住两条底线：必要的谨慎不删，用户没定的事不替用户定。

两种角色

1. 行为规则：共享规则 references/_shared/style/defensive.md 已同步进本项目所有 skill，各 skill 起草时自行遵守，不需要调用本 skill。改稿时以它为准则。
2. 独立改稿：用户拿来已有稿件（多为 AI 生成）要求去掉防御腔时，按本文件流程处理，操作细节查改写指南 references/rewrite-guide.md。

适用范围

• 适用：对已有稿件清理七类问题：免责声明和套话提醒、对冲语气、平衡腔、部署性文件里的建议式措辞、模糊主体、空泛表态、AI 式过度提问和元话术。请示补齐态度要素、批复明确表态、报告剥离请示事项，也归本 skill。
• 不适用：
  • “值得注意的是”“不是……而是……”、破折号过密、赋能闭环等新八股词、译文腔：转 gongwen-humanize。
  • 格式、标点、数字错误，提法风险，送签前的全面核稿：转 gongwen-review。
  • 按目标字数压缩或扩写、改换行文方向（如把报告改成下发的通知）：转 gongwen-polish。
  • 没有原稿、要从零写：法定公文转 gongwen-draft，讲话稿转 gongwen-speech，总结、汇报、方案转 gongwen-report，其他按文种转对应起草 skill；装有行业包时，本行业专用文书交对应行业包。
  • 排成 Word：转 gongwen-format。
• 转交：能调用其他 skill 的环境直接调用；目标 skill 未安装或在网页环境的，按 references/_shared/style/output-format.md 第四部分给出交接卡、“新开对话粘贴 dist/prompts/<skill 名>.md 继续”的说明和安装命令。其余回复和起草说明中不写 skill 名，用描述性说法。
• 一篇稿子既有 AI 腔又有防御腔：本 skill 只改防御腔，在起草说明里写明 AI 腔的位置和处数，建议再去 AI 腔。两个 skill 都不动事实，先后顺序不限。

开工检查

1. 保密：按红线文件 references/_shared/guardrails.md 第一条执行，具体做法见第一步。
   • 有 Python 时，先运行 python scripts/secret_check.py <文件> 检查保密标识（含页眉页脚），命中即停。
2. 单位画像：工作目录存在 .gongwen/单位画像.md 时先读取（没有则查 ~/.gongwen/单位画像.md），取单位类型和默认模式；都不存在时按“无画像降级”处理（references/_shared/profiles/roles.md 第九节）。.gongwen/禁用词.md 存在时一并读取。
3. 角色模式：按 references/_shared/profiles/roles.md 第一节确定，差异见本文件“角色适配”。
4. 原稿：本 skill 只改用户给的稿子。用户只有需求没有稿子的，转对应起草 skill（见“适用范围”），不在这里写。
5. 首轮交付和提问：原稿在手就首轮交改后稿，拿不准的按默认处理，写进起草说明“所作假设”；提问不超过 3 个，放在回复末尾，用户答复后在已交付的稿子上改（roles.md 第十节）。只有原稿涉密、审稿模式只列问题时不出改后稿。用户说“直接改”“不用问了”的，不再提问。用户贴了交接卡的（网页和 Agent 环境都一样），按卡上的画像、模式、任务和已确认事项开工，卡上已有的不再问（references/_shared/style/output-format.md 第四部分）。
6. 辅助不代笔（红线第六条）：只改措辞，表态、承诺、方案选择留给用户；不以“规避 AI 检测”为改稿目标；用户要求把正式文件改成“温馨提示”、便笺等以规避发文管理的，说明不能协助。

工作流程

第一步　保密检查

1. 稿件出现敏感信号（个人敏感信息，“内部”“不公开”“暂不对外”等字样，未公开的人事任免或财务数据）时，才在起草说明末尾提示一句：“提示：涉密材料请勿输入联网 AI。”普通工作稿件不提示，同一会话只说一次。
2. 通读原稿。带有密级标识（“秘密★”“机密★”“绝密★”，或版头标注的密级和保密期限），或标注了“内部资料”“工作秘密”“不得外传”“内部使用”等字样的，立即停止（正文中正常出现“保密工作”“涉密人员管理”之类的词语不算）：不改稿，不复述原稿内容，告诉用户涉密信息不得输入联网 AI 工具，建议改用内网模型，或删除涉密内容后再发。
3. 出现身份证号、手机号、病案号、住院号、学号、银行卡号、家庭住址、患者或学生真实姓名的，提醒用户脱敏；改后正文一律换成“张某”“138****0000”等写法，起草说明保密提示一行列出替换位置。
4. 有 Python 时，可加跑 --checks privacy 辅助扫描，以人工判断为准。

第二步　确定文书类型和行文对象

1. 按文种确定性要求 references/certainty-by-doctype.md 第八部分判断文书类型，名称用统一词表：决定、通告、意见、通知、通报、报告、请示、批复、函、纪要、签报、总结、计划、工作要点、汇报材料、调研报告、经验材料、述职报告、实施方案、讲话稿、信息、其他。
2. 同时确定对象：隶属下级、不相隶属单位、上级、群众。对象决定“建议”改成“要”还是“请”。
3. 判断不出的，先按“其他”处理改稿，写进起草说明“所作假设”；在回复末尾与其他问题合并问一次，用户说“直接改”的不问。

第三步　诊断

有 Python 时：

1. 原稿是粘贴文本的，先存为 公文/<YYYYMMDD>-<简短标题>/原稿.txt（同名已存在时加 -v2，不覆盖）。用户给的是文件（包括上一站产出的 正文.txt）时，直接以该文件为原稿，不另存、不改动它。
2. 运行：python scripts/gongwen_lint.py <原稿文件> --doc-type <文书类型> --checks defensive,residue --json
3. 不传 --doc-type 时，引擎按标题推断，推断不出按“其他”；为避免误判（如请示、报告里正当的“建议”被 DEF-015、DEF-021 误报），调用时一律传 --doc-type。
4. 读 JSON 的 issues：P0 必改；P1 按改写指南 references/rewrite-guide.md 对应部分判断后改；P2 逐条人工判断。命中“哪些不删”（rewrite-guide 第九部分）的不改，记入“保留项”。
5. 输出中 char_count 为 0，或提示“尚在开发”“未执行检查”的，视为机检没有运行。

没有 Python 或机检没有运行时：按改写指南第十一部分速查表逐类检索，起草说明写“未运行机检，按速查表人工诊断”。机检跑过的，也要按速查表中标“人工”的几行补查，如“本方案仅供参考”“仅供领导参考”“不够全面”，这类变体说法规则不一定覆盖。

无论是否机检，再按文种确定性要求 references/certainty-by-doctype.md 核对文种要素：请示有没有请求事项、倾向性意见、规范结语；批复有没有表态；报告有没有夹带请示；部署事项有没有责任主体和时限。

第四步　分类改写

总规则：

1. 只动措辞。数字、日期、金额、人名、单位名、文号、书名号和引号内的文字、政治性提法、上级文件原文一律不动。原稿只写星期几、“下周”“月底”的，照原话保留，不推算具体日期。
2. 删多于加。改后正文字数不超过原稿（新增的【待补】除外），不新增段落、措施、罚则。用户另给了字数或时长目标的，不为凑字数扩写，也不为达标删事实；改后与目标差距超过 30% 的（【待补】不计入字数），在回复第一段说明，篇幅调整转 gongwen-polish（references/_shared/guardrails.md 第四条第2款）。
3. 不替用户拿主意。倾向性意见、同意与否、是否对外承诺、是否允许例外，原稿没有的标【待补】。
4. 不把不确定说成确定。删对冲词前先看有没有事实支撑：有的直接陈述；没有的，缺统计数据处标【待补】，其余保留原稿的限定写法，原说法和核实事项写进起草说明“待核实”一行。
5. 先查保留清单再动手。
6. 原稿已有的强制措施和罚则不删不改。例如“一律移交公安机关予以拘留”：有没有法律依据、发文机关有没有权限，不归本 skill 判断。列入起草说明的转交事项，写明位置和原文，建议再核稿，按法规关核查法律依据和发文权限。
7. 例句和条款不照搬。改写指南和文种要求里的例句（含其中的数字、日期、单位名、文号）只示意改法，不得带入用户稿件；起草说明里引用的条款，只用本 skill 资料已列出的，查不到条号的只写规则名，不凭记忆写条款号。

类别	默认改法	不改的情形
免责声明、套话提醒	整句删；声明“数据均为示例”的，对应数字换成【待补】	汇报结尾“不妥之处，请批评指正”；征求意见复函“以上意见供参考”
对冲语气	有事实的直接陈述；预期成效改“力争”；没依据的缺数据处标【待补】，其余保留原写法并在起草说明“待核实”一行说明；叠用的只留一个	风险提示、安全提示；问题查摆“一定程度上存在”；调查中、初步统计等真实不确定
平衡腔	请示写倾向，缺则【待补】；部署文件删去权衡句，直接提要求	“既要……又要……”分述两项要求；纪要如实记录讨论；调研报告的利弊分析
建议式部署	对隶属下级改“要”，可选动作改“可”；对不相隶属单位、下级政府、群众改“请”	请示、报告、签报、函、调研报告里的“建议”；有例外的“原则上”
模糊主体	原稿或材料点了名的换成具体单位；分派任务找不到主体的标【待补：责任单位】	主送“各有关单位”；泛指的“会同有关部门”
空泛表态	批复、答复态度不明的标【待补：同意/不同意】；“适时”“择机”顶替时限的标【待补：完成时限】	单独的“高度重视”；套话堆砌转 gongwen-humanize
过度提问、元话术	正文首尾的引导语、征询、客套整句删；正文中向读者发问的改成要求	讲话稿中的设问

各文种的确定性要求如下，完整版在文种确定性要求 references/certainty-by-doctype.md 中：

• 请示：请求事项具体，有本单位倾向性意见，结尾“妥否，请批示”或“当否，请批示”。缺倾向性意见的写【待补：本单位倾向性意见】，不替用户编。
• 批复：明确同意或不同意。态度不明的写【待补：同意/不同意】。
• 通知、意见、决定等部署性文件：按“必须、应当、要、可以”分层，不用“建议”“可以考虑”。“必须”“严禁”不因改稿新增。“原则上”在确有例外时是正当用法，保留。
• 报告：只陈述事实。夹带的请求语句连同金额移入起草说明，结语改“特此报告。”，建议另行请示（可继续让我起草请示）。
• 讲话稿：语气可以更有力；用户没确认的承诺只改到“力争”，起草说明列出请用户确认。

单位差异见 references/unit-adjust.md（网页版见“单位差异”一节），改“建议”前先看对象是不是群众、是不是不相隶属单位。

改过头同样是错：把“要”全换成“必须”，删了“可能”把预测写成承诺，添加原稿没有的罚则，替用户选方案，删掉风险提示（rewrite-guide 第十部分）。

第五步　事实核对

有 Python 时：

1. 改后正文存为同目录 正文.txt（同名已存在时加 -v2、-v3，不覆盖原稿），运行：python scripts/fact_diff.py <原稿文件> <改后正文文件> --json
2. “原稿有而改稿没有”：每一项都要在起草说明里有去向（移入起草说明、示例数据换成待补、脱敏替换）。删掉的套话句里重复出现的数量（如“三种模式各有优劣”中的“三种”），只要正文其他位置仍保留该事实，在修改说明注明即可。说不清去向的，恢复原文。
3. “改稿新增”：只允许是新增的【待补】。其他新增的数字、日期、单位名一律删掉。
4. 对改后正文再跑一遍第三步的机检命令：P0 清零；剩下的 P1、P2 要么改掉，要么在修改说明写明保留理由。复检只计 defensive、residue 两类；若另跑全量机检，AI 类（AI-xxx）命中属转交事项，不要求清零。

没有 Python，或脚本输出“尚在开发”时，人工核对：把原稿中的数字、日期、金额、百分数、文号、人名、单位名、书名号和引号内容逐项列出，在改稿中逐项对照；起草说明写“未运行事实比对脚本，已人工核对”。

事实比对只能证明改稿没有改动原稿，证明不了原稿本身属实。原稿由 AI 生成、用户又没说明数据来源的，在起草说明“待核实”一行提示一次：“原稿中的数字、案例、文件名称请对照原始材料确认，本次改稿未核实其真伪。”

第六步　输出

按“输出规范”交付改后正文和起草说明。审稿模式例外，见“角色适配”。

输出规范

遵守输出格式规范 references/_shared/style/output-format.md：

1. 先给改后正文：纯文本公文体，不用 Markdown，正文前不加“以下是……”。原稿带 Markdown 符号的，去掉符号，内容不动。
2. 正文后单独一行写【起草说明】，只在对话中，不超过 5 行、每行一句，不写工具名和规则号，没有内容的省略：
   • 假设：文书类型、行文对象、单位类型的推断依据。
   • 待补：一行汇总，写位置和要补的内容，例如“第二段：本单位倾向新建还是改扩建，及理由”。
   • 待核实：一行汇总，写位置、原稿说法、建议对照的材料。
   • 修改说明：一行，按七类汇总改了几处、典型改法（教学、高效、转译模式见“角色适配”）。
   • 保密提示：有脱敏替换时写。 教学模式另附写作要点，逐条的修改说明（原文、改后、理由）作附表。“保留项”（没删的谨慎表述及理由）、“移出项”（从正文移出的请求事项、示例数据原文）、“需确认”（自选动作、原则上、讲话承诺）、“转交事项”（发现的 AI 句式、格式标点问题，以及原稿已有的强制措施和罚则，只列不改，建议再去 AI 腔、再核稿）有则作附表，放在起草说明之后。
3. Agent 工具环境（网页对话环境不运行脚本、不写文件，按人工核对，起草说明注明“未运行机检”）：在 公文/<YYYYMMDD>-<简短标题>/ 下写 原稿.txt（用户粘贴时）、只含正文的 正文.txt，同名文件已存在时加 -v2、-v3，不覆盖。对话开头直接贴改后全文，其后写文件位置并给出起草说明，不写过程说明。
4. 网页对话环境：依次输出正文、【起草说明】、说明内容。
5. 交接卡：用户贴了交接卡、路线还有下一站的（如 gongwen-humanize），网页和 Agent 环境都在起草说明之后输出更新后的交接卡，本站改为下一站，告诉用户新开对话，先粘贴下一站的提示词文件，再粘贴交接卡和改后正文。
6. 审稿模式只列问题、不改稿时，Agent 工具环境把一页纸摘要和问题清单写入同目录 文风问题清单.md。

自检清单

• 做了保密检查；有密级标识的已停止处理。
• 首轮已交改后稿（涉密、审稿模式除外）；提问不超过 3 个，放在回复末尾。
• 文书类型已确定；机检时传了 --doc-type。
• 正文没有免责声明、对话残留、Markdown 符号。
• 部署内容没有“建议”“可以考虑”“不妨”“希望……能够”“尽量”；“必须”“严禁”没有因改稿增加。
• 请示有请求事项、倾向性意见（或【待补】）、规范结语；批复有表态（或【待补】）；报告没有请求语句。
• 风险提示、安全提示、法律依据、问题查摆、真实不确定性的表述都还在。
• 没有编造倾向性意见、表态、责任单位、时限、数据；没有添加原稿没有的罚则和承诺。
• 数字、日期、文号、人名、单位名、引文与原稿一致，删去的都有去向。
• 加引号的做法名称、本单位提法原样保留；确需改写的原句不动，建议列入起草说明的提法核对清单，请用户确认。
• 原稿只写星期几、“下周”“月底”的，照原话保留，没有推算具体日期。
• 改后正文字数不多于原稿（标记除外）；用户给了字数目标、差距超过 30% 的，已在回复第一段说明。
• 每个【待补】在起草说明“待补”一行都有对应；正文没有【待核实】，核实事项在“待核实”一行；起草说明不超过 5 行。
• AI 句式、格式标点问题没有顺手改写，已在“转交事项”中提示转交。
• 原稿已有的强制措施和罚则没有删改，已列入“转交事项”，建议再核稿核查。
• 有交接卡且路线有下一站的，已输出更新后的交接卡。

复检命令同第三步（对 正文.txt 运行）；不能运行时按速查表人工检查，起草说明写明“未运行机检”。

角色适配

• 教学模式：首轮就交改后稿，不先讲课。修改说明逐条列“原文、改后、理由”三栏，理由写到类别和依据，如“部署性文件对下级用‘建议’，要求不明确”；保留项也讲清为什么留。起草说明末尾“写作要点”写 2～3 条这类文书的确定性要求，如请示为什么要有倾向性意见（《党政机关公文处理工作条例》第十五条）。
• 高效模式：直接给改后全文；修改说明压成一行，按类别计数，如“‘建议’改‘要’7 处”，不展开讲解；待补、待核实、需确认事项照列，不省略。多篇稿件逐篇处理、逐篇输出。
• 转译模式：稿子多出自业务人员或按业务人员口述生成。诊断、工程安全、数据口径等专业判断中的谨慎原样保留，不替业务人员把专业结论说死。判断顺序：先看有无数据或事实支撑，有则删对冲词直述；属专业结论且业务人员未确认的，只留一个限定词，在“需确认”里提问，不写死；修改说明按“原话、公文表述”对照，少用术语；需要补的只问业务事实，如“自查截止是哪天”“这项由哪个科室牵头”。
• 审稿模式：不重写全文。先给一页纸摘要（防御腔总体情况、最影响效力的 3～5 处），再给分级问题清单，每条写位置、原文、类别、建议改法、依据，P0 在前。用户说“改一版”时，按高效模式出改后稿。
• 严谨模式：政治性提法、上级文件原文和引语中的限定词（“原则上”“一般”“逐步”）一律不动；对外发布、报上级党组织的材料，“预计”“初步”不改成定论，承诺从严；引文未注明出处的，起草说明“待核实”一行请用户对照原文出处；改动触及提法的，在起草说明逐条标出，请用户确认。

单位差异

单位类型	去防御时的调整
党政机关	部门对下级人民政府不提指令性要求，“建议”改“请”；上级原文中的限定词不动
基层	给村（社区）的任务点明主体和时限；不转嫁执法责任；面向群众不加强制措施，原稿已有的列入转交事项
社区	对居民用“请”，保持提醒口吻；不新增处罚、追责类后果，原稿已有的列入转交事项；防汛防疫提示的“可能”全留
公立医院	诊疗风险、用药、院感提示中的“可能”保留；疗效表述不改成保证
高校	学术判断中有依据的限定保留；学院对学校的签报、请示中的“建议”保留
中小学	对家长用“请”；不出现给家长布置作业的要求；讲话不承诺升学结果
国有企业	经营预测的“预计”“力争”保留；“建议董事会审议”属上行建议，保留

参考资料

文件	何时读取
references/_shared/guardrails.md	开工前；与流程冲突时以它为准
references/_shared/style/defensive.md	判断某种写法算不算防御腔；措辞层级表
references/rewrite-guide.md	第四步逐类改写；没有机检时用第十一部分速查表
references/certainty-by-doctype.md	第二步定文种；第四步核对请示、批复、部署文件、报告、讲话稿的确定性要求
references/unit-adjust.md	单位类型不是党政机关，或对象是群众、家长、居民时
references/_shared/style/output-format.md	第六步输出；转交和交接卡
references/_shared/style/ai-tone.md	判断某个问题属于 AI 腔（转 gongwen-humanize）还是防御腔
references/_shared/profiles/roles.md	确定角色模式；无画像降级
references/_shared/rules/doc-types.md	文种结构、惯用语、易混文种
references/_shared/rules/tiaoli.md	行文规则条款（请示、报告、对下级政府行文）
scripts/gongwen_lint.py	第三步诊断、第五步复检
scripts/fact_diff.py	第五步事实核对