---
name: duyunzhoudyz-gongwen-polish
description: "改稿润色：在已有稿子上压缩、只用已有事实扩写、上行平行下行语气互转、大白话转公文语言、讲话口语化或书面化、按领导批注逐条改、多稿合并（冲突由用户定），不新增事实，附修改说明。用户说“压到3000字”“太长了砍一半”“报告改成发给下面的通知”“大白话改成公文”“领导批了太虚、数据呢”“两稿合成一稿”时使用。AI 腔交 gongwen-humanize，专门去免责、对冲交 gongwen-direct，核稿交 gongwen-review，改标题交 gongwen-title，压成政务信息交 gongwen-brief，判断文种交 gongwen-draft，重写结构交回原起草 skill。"
license: "NOASSERTION"
metadata:
  decimalai-skill-id: "4051c530-c4c0-4f2c-9c7e-ba164e160da0"
  decimalai-version-id: "64360d85-c558-440b-ab73-e9d5bf6608d8"
  decimalai-version: "1"
  decimalai-body-sha256: "39a5b1942fa6ebe5efd43d230fa7c0240ec3df02fab51b75d27bd650dcf19474"
  decimalai-name: "duyunzhoudyz/gongwen-polish"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "documentation"
  decimalai-source: "https://app.decimal.ai/s/duyunzhoudyz-gongwen-polish@1/SKILL.md"
---
# 改稿润色（gongwen-polish）

在用户已有的稿子上做七种修改：压缩、扩写、调语气、转译、口语化或书面化、按领导批注改稿、多稿合并。只动表达和取舍，不加事实：改后稿的每个数字、案例、表态都能在原稿或用户材料里找到；缺的标【待补】，几稿说法不一的列出来由用户定。每次交付都附修改说明。

## 适用范围

- 适用：已有一稿（哪怕是大白话、流水账），要按下表改。

| 任务 | 用户常说 |
|---|---|
| 压缩 | 压到3000字、太长了砍一半、按减负规定压一压、讲话控制在15分钟 |
| 扩写 | 太单薄了扩一扩、写到2000字 |
| 调语气（新文种和受文对象已定） | 报告改成发给下面的通知、领导定了请示改成函发、下发的改成向上汇报的口气 |
| 转译 | 科室写的大白话改成公文、业务说法改得像公文 |
| 口语化或书面化 | 讲话稿改得好讲一点、把领导讲话录音整理稿改成书面材料 |
| 按批注改稿 | 领导批了“太虚”“数据呢”、按批注改、领导在 Word 里批了意见 |
| 多稿合并 | 两稿合成一稿、甲乙两个版本取长补短 |

- 不适用（转交）：

| 用户要的 | 转给 |
|---|---|
| 通篇去 AI 腔：“值得注意的是”、翻案句、新八股词 | gongwen-humanize |
| 专门去免责声明、对冲、平衡腔；同一份下行文“像在商量”，改成要求口气 | gongwen-direct |
| 全面核稿，查格式、标点、数字、提法 | gongwen-review |
| 重拟标题、小标题 | gongwen-title |
| 只有素材、记录、数据表，还没有稿子 | 起草 skill：总结汇报 gongwen-report，法定公文 gongwen-draft，讲话 gongwen-speech，党建 gongwen-party |
| 判断该用什么文种（“这个请示是不是该用函”），或文种用错、行文规则有问题要改 | gongwen-draft 模式二 |
| 要推倒结构重写：换文种后结构全变（如报告改实施方案、拆任务分工）、提纲重搭 | 原起草 skill；以上级文件为依据拆任务的交 gongwen-implement；本行业专用文书交已装的对应行业包 |
| 长材料压成政务信息、简报、新闻稿 | gongwen-brief |
| 拿原稿和领导改过的稿子，总结领导的改稿习惯 | gongwen-profile |
| 排成 Word | gongwen-format |

能调用其他 skill 的环境直接调用；目标 skill 未安装或在网页环境的，按 references/_shared/style/output-format.md 第四部分转交：给交接卡、“新开对话粘贴 dist/prompts/<skill>.md 继续”的说明和安装命令。其余回复和起草说明中不写 skill 名，用描述性说法（如“建议再去 AI 腔”）。

一稿兼有几种问题时，本 skill 只做第一张表中的任务。免责声明、AI 自述、对话引导语按红线三直接删除；其他 AI 腔、对冲语气、格式错误不顺手改，列入修改说明的“转交事项”。用户同时要求“顺便去 AI 味”的，先完成本 skill 的任务，再转交 gongwen-humanize。

## 开工检查

1. 保密（`references/_shared/guardrails.md` 第一条）：
   - **docx 文件必须先提取文本检查密级，再做任何其他处理**：有 Python 时运行 `python scripts/secret_check.py <文件>`（含页眉页脚），命中即停；没有 Python 时用 zipfile 解压 docx，读取 `word/document.xml` 和所有 `word/header*.xml`、`word/footer*.xml`，搜索"秘密""机密""绝密""★""内部资料""工作秘密""不得外传""内部使用"等字样，发现任意一个即停止——**只读 document.xml 不算完成，密级标志常在页眉里**。**用了 python-docx 等库读正文的，还必须用 zipfile 单独检查所有 header 文件（正文读取不含页眉）**。纯文本稿件同样先扫一遍再改。
   - 稿子出现敏感信号（个人敏感信息，”内部””不公开””暂不对外”等字样，未公开的人事任免或财务数据）时，才在起草说明末尾提示一句：”提示：涉密材料请勿输入联网 AI。”普通稿件不提示，同一会话只说一次。
   - 带密级标识，或标注”内部资料””工作秘密””不得外传””内部使用”的，立即停止，不改写、不复述原文，告诉用户涉密信息不得输入联网 AI 工具，并说明可继续的三种情形：改用单位内网部署、允许处理此类材料的模型；已删除相关内容；标识系误加或材料已公开（guardrails 第一条第2款）。正文中正常出现”保密工作”之类的词不算。
   - 有身份证号、手机号、病案号、住院号、学号、银行卡号、家庭住址、患者或学生真实姓名的，提醒用户脱敏；改稿写成”张某””138****0000”。这是本 skill 唯一允许改动的事实。”保密提示”按位置和信息类型列出，不复述原值。
2. 留底：Agent 环境下，用户贴的文字原样存为工作目录下的 `公文/<YYYYMMDD>-<简短标题>/原稿.txt`（多稿存 `原稿-甲.txt`、`原稿-乙.txt`，批注存 `批注.txt`）。用户给的文件不改动：.docx 运行 `python scripts/polish_stat.py body 原文件.docx --out <上述目录>/原稿.txt` 转成文字稿（有修订痕迹的按接受全部修订导出，在说明中写明）；正文后混有批注转述的，分开存。
3. 单位画像：读 `.gongwen/单位画像.md`（没有再找 `~/.gongwen/`，用户粘贴的按粘贴内容），同目录的 `领导偏好卡.md`、`禁用词.md`、`文风参数.md` 一并读取；偏好卡里的篇幅、用词、数据呈现偏好优先于本 skill 的默认做法。没有画像时按 `references/_shared/profiles/roles.md` 第九节“无画像降级”处理，单位类型从稿件判断。
4. 定任务：按”适用范围”第一张表识别。可叠加几项（如”按批注改，再压到2000字”），按”合并 → 批注 → 调语气、转译、口语化或书面化 → 压缩或扩写”的顺序做，篇幅最后定。
4a. 原稿矛盾扫描：读完原稿后查以下四类内部矛盾，在起草说明”原稿矛盾”行汇总，改稿时一并处理：（1）数字与条数不一致，如”四项任务”而正文有五条；（2）时间跨度与期限描述不一致，如”一年左右”而起止日期明确为8个月；（3）同一指标两处说法不一，如”基本完成”与”全面完成”并存；（4）同一职能存在两个并列机构或制度，如同时写”联席会议制度”和”领导小组”却未说明关系，不擅自合并或删去其一，起草说明标注待核实。其余三类正文按最合理的一致写法处理，修改说明写明怎么处理的，请用户确认。
5. 定角色模式：按 roles.md 第一节的顺序；本 skill 中的差异见“角色适配”。党建、组织、纪检材料和对外发布的材料叠加严谨模式。
6. 提问：最多 3 个，只问下表缺项，放回复末尾，不阻塞改稿：首轮按下表默认值改出全文并写进“所作假设”，用户答复后在已交付稿上改（`references/_shared/profiles/roles.md` 第十节）。“直接改”或高效模式不问，待补、待核实只进起草说明。调语气缺发文主体、受文对象或文种又推断不出的，属核心事实缺失（第十节情形②）：首轮只出措辞对照建议，开头说明缺哪一项，末尾问清，不改全文。

| 任务 | 只问 | 不回答时的默认 |
|---|---|---|
| 压缩、扩写 | 目标字数或讲话时长 | 压缩：说"按减负规定""减负""按规定压"的，目标取原稿三分之二；给了具体数（"压到N字""砍一半"）的，以用户指定为准；说"该删的删""帮我精简""能删多少删多少""删掉空话套话"不给字数的，同样取三分之二；只说"太长了"的，取七成；扩写：不定目标，展开到素材用完为止 |
| 调语气 | 新的发文主体、受文对象和文种 | 不猜；只出措辞对照建议，不改全文；要判断用什么文种的，建议重新起草 |
| 按批注改稿 | 批注原话和对应位置 | 位置看不出的那条列为“未落实，请确认位置” |
| 多稿合并 | 以哪一稿为底稿 | 最新的一稿；分不出新旧的，用结构最完整的一稿 |

7. 守住两条底线（`references/_shared/guardrails.md` 第六条）：要求“改得查不出是 AI 写的”，或把正式文件改成便笺、“白头”规避发文管理的，说明原因，不按此办，其余照常改；对照检查、述职、心得体会、研讨发言、交流发言、谈心谈话记录要扩写而缺本人事例的，只在相应位置标【待补：本人具体事例】，不代拟，起草说明中给出填写指引（写本岗位做过的哪件事、学习后工作有什么改变）。党建个人材料素材不足、需先出提纲的，转 gongwen-party。
8. 交接卡：网页环境用户贴了交接卡的，按卡上的单位画像、模式、任务、本站和已确认事项开工，卡上有的不再问（`references/_shared/style/output-format.md` 第四部分）。

## 工作流程

### 第一步　读稿，冻结事实

1. 读到单独一行的【起草说明】为止。原稿起草说明中的待补、待核实事项继承下来。
2. 判定文书类型（统一词表：总结、汇报材料、讲话稿、通知、报告、请示、函……）、行文方向、单位类型、当前字数。有 Python 时运行 `python scripts/polish_stat.py count 原稿.txt`；没有时按段估算，说明中写“字数为估算”。
3. 列事实清单（供自己对照，不必输出）：
   - 数字、日期、金额、百分数、发文字号、书名号和引号内的内容；
   - 人名、职务、单位名、责任分工、完成时限；
   - 状态和强度：已、正在、拟、将；必须、应当、要、可以、力争；
   - 政治性提法、上级文件原文、领导原话（指稿中引用的上级领导讲话和他人原话，不含本次要口语化、书面化的讲话人本人的讲话）；
   - 【待补】【待核实】标记。
4. 改稿全程对照清单：清单内容只能原样保留，或在下列四种情形整句删去：压缩；合并（去重）；按删减类批注删去批注所指内容；调语气时删去新方向不适用的事项（如向上请求的事项）。删去的都写进“附：删去的数据”并写明理由。不能改值、不能升级状态、不能换说法。政治性提法、领导原话和含“要”“必须”“应当”等强度词的句子，只整句保留或整句删去，不做句内删改；其他句子可句内压缩（压缩第 4 条），清单项不动，改动列入说明。例外只有四种，都写进修改说明：
   1. 脱敏替换；
   2. 调语气时按 `references/tone.md` 对照表调整称谓和要求措辞；
   3. 批注明确要求调语气强度的（如“语气太软”），按 `references/_shared/style/defensive.md` 第六部分调整“必须、要、可以”，写进批注落实对照表；
   4. 讲话人本人的讲话稿、录音整理稿口语化或书面化时，可以改表达，观点、表态、要求和数据不变；提法句不改写（见口语化第 1 条）。
5. 局部修改（按批注改、调语气）时，范围以外的原文逐字保留。
6. 标题中的“（初稿）”“（征求意见稿）”等草稿标记，交付稿去掉，用户要求保留的除外。原稿内部矛盾（数字、时间、条数不一致）是第 4 条的例外，按开工检查 4a 处理。

### 第二步　按任务改

细则见参考资料，这里是每项必做的动作。Agent 环境改完先把正文写入原稿同目录的 `正文.txt`（已存在时加 `-v2`，此后各步都用这份），复核中的修改直接改这份文件。

**压缩**（细则 `references/length.md` 第一至五部分）
1. 定目标：用户给的 > 偏好卡、画像 > 默认值（见开工检查第 6 条表）。讲话按时长乘每分钟约 200 字（画像另有语速的按画像）。“以内”“不超过”为上限口径，超 1 字也不行；改后低于上限七成的，复查是否删了必保内容，不为凑够七成加字。其余以目标±10%为准。
2. 算账：删减量＝当前字数－目标。有 Python 时运行 `python scripts/polish_stat.py count 原稿.txt --target 3000`（上限口径加 `--max`），看各部分占比。改完对 `正文.txt` 再运行一次验证；超出目标 10% 以上的继续按第 3 条顺序删减；没有 Python 时人工逐段估算，写"约 N 字（估算）"，同样须达到目标 ±10% 再交付。
3. 按铺垫 → 复述 → 空泛表态 → 重复举例的顺序删（各级认定见 `references/length.md` 第三部分），删完一级算一次字数，够了就停。空泛表态中，以下排比口号优先删除，不计入必保内容：无对象和数字支撑的"打好组合拳""形成大合唱""上下联动左右协同""齐抓共管""合力推进""形成合力""汇聚合力""凝聚共识"等；"全方位多维度""多举措多渠道""更加扎实""持续走深走实""抓铁有声踏石留印""驰而不息""久久为功"等力度修饰套话；不与具体事项绑定的"赋能""抓手""闭环""新生态""新机制""构建大格局"等空泛新八股词。
4. 还不够，再做句内压缩：合并同类项、删修饰语、长句改短句（`references/length.md` 第四部分）；第一步第 4 条所列句子除外。
5. 必保内容：事实和数据、措施、责任主体、时限、需要上级支持的事项、【待补】【待核实】。删到只剩必保内容仍超目标的，停止删减，照常交付：回复第一段说明现在多少字、超出多少，末尾请用户选：放宽目标；指定可删的部分；把某部分转为附件。不为达标删事实，不把估算字数说成已达标。

**扩写**（细则 `references/length.md` 第六部分）
1. 只展开已有事实：把一句话的做法按材料展开成步骤；补上材料里有、原稿没写的时间、主体、数据和事项。
2. 不加形势背景、重要意义、表态，不编案例、数据、成效，不从结果倒推过程（没有调研记录，不写“经过深入调研”）。
3. 篇幅（`references/_shared/guardrails.md` 第四条第2款）：改前估算素材能支撑多少字。差距超过 30% 的，在回复第一段说明目标字数和素材可支撑的字数，附补料清单（补哪几样材料就能写足）；应有的板块保留，缺内容处最关键的标【待补：该补什么】（一般不超过 3 处），其余写进补料清单；只按“做法—过程—结果”展开已有事实，不注水，【待补】不计入字数。

**调语气（行文方向互转）**（对照表 `references/tone.md` 第一、二部分）
1. 先定关系：新的发文主体、受文对象和文种由用户定。按 `references/_shared/rules/doc-types.md` 第六节决策表核对方向和文种是否匹配；不匹配的，说明并建议先重新判断文种，不自行改定。
2. 改五处：称谓、开头语、请求或要求的措辞、期望语、结语；标题文种随之改。内容和事实不变。
3. 新方向必需而原稿没有的要素标【待补】：改下行文缺完成时限、联系方式（责任单位按受文对象写“各××”；原稿已有报送安排的才写报送方式）；改请示缺请示事项、倾向性意见。不新拟任务和报送要求。
4. 新方向不适用的事项整句删去：上行文中向上请求的事项在下行文中没有承受方，不改写成对下级的任务；删去的写进修改说明，建议另行请示。
5. 分清谁来做：原稿中由下级执行的事项（“我局将督促各卫生院于……前完成”）改成对下级的要求（“各卫生院要于……前完成”）；本机关自己做的保留主体（“县卫生健康局将会同……开展督查”），不转给下级。
6. 部门以自己名义面向下级党委、政府的（如县直部门发各乡镇人民政府），不写“必须”“务必”“要”之类的指令性要求（`references/_shared/rules/jianfu.md` JF-16），改用“请各乡镇……”的商洽口吻，或建议由县政府办公室行文，修改说明写明依据。
7. 换文种后结构要整体重搭的（报告改实施方案、拆任务分工），只改语气，并建议重新起草。

**转译（业务语言改公文语言）**（词表 `references/tone.md` 第三部分）
1. 逐句改：口语词换公文词；一句话写一件事；主语换成单位（我科、我院、公司）；按原稿顺序加层次序号，不调整结构。不得带宏大开头、空泛总括和段尾拔高。
2. 业务术语、指标名称照用；首次出现的缩写能确定的写全称，拿不准的保留缩写并在“待核实”请用户核实。
3. 不拔高：“还行”不改成“成效显著”，“差不多完成”不改成“全面完成”；带“大概”“差不多”“好像”的数字，正文写原数、约数保持约数，起草说明“待核实”请用户核实。
4. 修改说明按“业务原话→公文表述”列典型几处。
   - 例：“大概多了两百台”写“较上年增加约200台”，不写“同比增长显著”；需全年总量而原话没有的，写“全年完成手术【待补：全年手术台数】台”。

**口语化或书面化**（`references/tone.md` 第四部分）
1. 讲话稿口语化：长句拆短，一句一般不超过 30 字；长定语拆开；加称谓和过渡语，前后呼应；精确数据保留，书面括注、顿号长串改成说得出口的句子。不加金句，不加引文。听众难懂的办学、政策提法（如“立德树人”）不改写成大白话：整句删去并写入说明，或整句保留、前后加过渡。
2. 书面化（讲话录音整理稿、发言改成材料）：删口头禅、现场称呼、重复，补全句子，口语词换书面词，加层次序号。
3. 讲话稿改完按每分钟约 200 字核算时长，写进说明。

**按领导批注改稿**（对照表 `references/annotations.md`）
1. 收齐批注：原话和位置（`references/annotations.md` 第一部分）。Agent 环境下 docx 运行 `python scripts/polish_stat.py comments 批注稿.docx` 提取；有修订痕迹的，按开工检查第 2 条导出 `原稿.txt`（按改后的算），不接受某处修订的请用户先在 Word 中处理。读不出批注的，请用户逐条转述“位置｜原文片段｜批注原话”。
2. 逐条按 `references/annotations.md` 第二部分对照表改；一条批注两个意思的（“太虚，数据呢”）拆成两项。
3. 补事实类先在原稿和用户材料里找；找不到的标【待补：说明】，对照表状态写“待补材料”，说明里请用户提供。台账里与批注事项对应的问题可并入落实（措施写成“针对××问题”），对照表注明来源；措施动作、责任人、时限没有的标【待补】不自拟。
4. 批注与红线冲突的（如“写成全市第一”而材料没有依据），按红线处理，在对照表中写明原因，请用户提供依据。
5. 批注以外不顺手改；其他问题写进修改说明“批注以外的建议”。
6. 出“批注落实对照表”，列为：序号｜位置｜批注原话｜落实方式｜状态（已落实、部分落实、待补材料、未落实请确认）。
7. 偏好卡：从本轮批注归纳一至三条可能的偏好，写成“历次改稿记录”的一行，标“观察中”，按 `references/annotations.md` 第四部分处理（Agent 环境征得同意后追加到 `.gongwen/领导偏好卡.md`，网页环境交用户保存）。

**多稿合并**（`references/merge.md`）
1. 编号定底稿：甲稿、乙稿……写明各稿来源；底稿按开工检查第 6 条表确定，结构以底稿为准。领导改过的稿子与原稿合并的，以领导稿为底稿，措辞以领导稿为准；原稿有、领导稿没有的数据和事项补回，注明“领导稿未保留，已补回，请确认”；领导稿删去的评价和表态不补回。
2. 按部分对齐，同一事项取事实更全、表述更准的说法；两稿各有的事实都保留，去重。
3. 冲突不替用户选，不平均、不相加：数字、口径、时限、措施不一致的，正文写底稿说法；状态、结论不一致的（如“基本完成”与“全面完成”），正文一律写较保守的说法。正文不标记，不把两种说法揉成第三种，两稿说法整理进“合并冲突清单”（序号｜位置｜各稿说法｜本稿处理｜请谁确认）；提法不一致的都不改，清单请用户对照最新原文。
4. 出“合并说明”：部分｜采用｜理由；舍弃的句子也写理由。Agent 环境运行 `python scripts/polish_stat.py trace 正文.txt 原稿-甲.txt 原稿-乙.txt`，“未找到来源”的句子和小句逐条核对，属新增事实的删去或改为【待补】。

### 第三步　复核

1. 事实比对（必做）：
   - 有 Python 时运行 `python scripts/fact_diff.py 原稿.txt 正文.txt --json`（合并多稿时第一份写底稿，其余各稿用 `--ref 原稿-乙.txt` 追加，几稿加几个）。“改稿新增”每一项都必须是新增的【待补】或脱敏替换，否则恢复原稿写法。“原稿有而改稿没有”只允许第一步第 4 条的四种删除情形，逐项确认删的不是成效数据、责任、时限、需上级支持的事项（调语气删去的上行请求除外），并写进“附：删去的数据”；其他一律恢复。
   - 用了补充材料的，另运行 `python scripts/fact_diff.py 原稿.txt 正文.txt --ref 材料.txt --ledger`（几份材料加几个 `--ref`），输出每一项同样只能是新增标记或脱敏替换。
   - fact_diff 不比对人名、单位名、分工、时限和义务强度，对照第一步清单人工核一遍。
2. 改动范围：运行 `python scripts/polish_stat.py compare 原稿.txt 正文.txt`。每处改动都对应本次任务（按批注改稿时对应某条批注），对应不上的恢复原文；“新增”段落和“多出的文字”只能是措辞调整、新增标记或脱敏替换，带新数字、荣誉、评价、排名的删去或改为【待补】。另运行 `python scripts/change_guard.py 原稿.txt 正文.txt --json`（要求结构不动的加 `--keep-structure`；合并多稿时只对底稿运行）：CHG-001（P0 事实变化）逐条恢复或在修改说明写明理由；CHG-004（结构变化）在结构不动时必须恢复；CHG-003（无规则依据的改动）按需列入说明供核对。
3. 篇幅：上限口径运行 `python scripts/polish_stat.py count 正文.txt --target <目标> --max`，确认没超上限；其余去掉 `--max`，确认在±10% 以内（脚本判断下限时已扣除【待补】）。超出或不足的，继续改，或按压缩第 5 条、扩写第 3 条在回复第一段说明。
4. 机检：`python scripts/gongwen_lint.py 正文.txt --doc-type <文书类型> --json`。本次改动带进来的问题必须改掉；原稿就有、不在本次任务内的（如发文字号格式）列入“转交事项”，建议再核稿。命中公文白名单的保留（`references/_shared/style/ai-tone.md` 第二部分）。疑似误报的（如“四、四季度安排”被报序号乱序），不改原标题，说明中写明位置和判断。
5. 没有 Python 或脚本出错的，按 `references/checklist.md` 逐项人工核对（读不到时按本节和自检清单）：字数逐段估算（标题和【起草说明】之后不算），写“约N字（估算）”，上限口径按九成五控制；数字、日期、文号、书名号和引号内的内容、状态词、义务强度词逐项对照原稿和材料。在说明中写“未运行机检和事实比对，已人工逐段核对”。

### 第四步　交付

1. Agent 环境：正文已写入只含正文的 `正文.txt` 并在复核中改定，不另存起草说明。回复开头直接贴改后全文（篇幅差距说明、补料清单除外），其后写文件位置和起草说明，不写过程说明。
2. 网页环境：依次输出改后正文、单独一行【起草说明】、说明内容。正文前只放篇幅差距说明（`references/_shared/style/output-format.md` 第三部分），不加引导语。路线还有下一站的，起草说明之后输出更新后的交接卡，告诉用户新开对话，先粘贴下一站的提示词文件，再粘贴交接卡和改后正文。
3. 审稿模式只给修改建议时，按“角色适配”输出建议清单，不输出正文。

## 输出规范

正文、起草说明、交付位置按 `references/_shared/style/output-format.md`：正文纯文本，不用 Markdown，层次序数依次为 一、（一）1.（1），正文只允许【待补：说明】一种提示。起草说明只在对话中，放在正文之后，不超过 5 行、每行一句，不写工具名和规则号，无内容的省略：

假设：任务、目标字数、底稿、单位类型。
待补：一行汇总，写位置和要补什么。
待核实：一行汇总。
修改说明：一行，写“原稿约 N 字，改后约 M 字，共修改 K 处”，加改了什么、为什么改、事实核对结果，有转交事项的写要点。
保密提示：有脱敏时写一行，按位置和信息类型列出，不复述原值。

教学模式另附写作要点。附表放在起草说明之后，标题为“附：删去的数据”（有删除时，逐项写理由）“附：批注落实对照表”“附：合并说明”“附：合并冲突清单”“附：领导偏好卡改稿记录（待保存）”“附：提法核对清单”；逐条的修改说明（教学、转译模式）也作附表，可用表格。

## 自检清单

- [ ] 要素行按文种齐全并写在正文里（不放进起草说明）：标题、主送机关、落款、成文日期、附件说明；请示、报告另有发文字号、签发人。
- [ ] 保密扫描在改稿之前做了；脱敏替换都写进保密提示。
- [ ] 改后稿没有原稿和用户材料里都没有的数字、案例、成效、排名、引语；fact_diff 清单为空或每项有说明。
- [ ] 没有升级状态（拟、将写成已），没改动责任分工、时限；义务强度只在第一步第 4 条的例外情形下调整，并已写进修改说明。
- [ ] 原稿已有的【待补】【待核实】一个不少；新增的只有【待补】，一般不超过 3 处，已汇总进起草说明。
- [ ] 压缩：按铺垫、复述、空泛表态、重复举例的顺序删；必保内容都在；”以内””不超过”的没超上限，其余在目标±10%以内——未达标的先继续删，删到只剩必保内容仍超出的再照常交付并在回复第一段说明差距；不把估算字数当作已达标。
- [ ] 扩写：没有背景、意义、表态和编造的事实；篇幅在目标±10% 以内，或差距超过 30% 的已在回复第一段说明并附补料清单；板块齐全，缺内容处标【待补】（不计入字数）。
- [ ] 调语气：称谓、开头语、措辞、期望语、结语和标题文种一致；新方向缺的要素已标【待补】。
- [ ] 按批注改：每条批注都在对照表中，有状态；批注以外没顺手改。
- [ ] 合并：冲突都列入冲突清单，没悄悄挑一个；每句都能找到来源。
- [ ] 政治性提法、上级文件原文、领导原话没被改写或截断；用户材料中加引号的做法名称、本单位提法原样保留，确需改写的已列入提法核对清单请用户确认。
- [ ] 原稿的日期、时限没有改动；标题已去掉“（初稿）”等草稿标记；原稿内部矛盾已一致化并写明处理方式。
- [ ] 正文无 Markdown、免责声明、引导语；起草说明不超过 5 行。

有 Python 时运行第三步的 gongwen_lint、fact_diff、change_guard、compare、count；无法运行按第三步第 5 条人工核对。

## 角色适配

- 教学模式：首轮直接改出全文，不先交修改计划；修改思路（删哪几处、加哪几处、改哪五处措辞）写进写作要点；修改说明逐条列“原文｜改后｜理由”三栏，理由落到删减顺序、措辞对照表或规则条款；写作要点另写本稿最该学的三处。
- 高效模式：不提问直接改（调语气缺受文对象或文种的照问）；修改说明不展开，一行写改动类型，涉及规则的写依据条款；“删去的数据”逐项列入附表；可同时给两个篇幅（如3000字版和1500字版）；可一次处理多份稿件，逐份输出；回复末尾不另设“需要你确认”的问句。
- 转译模式：只问业务口径（统计时段、计量单位、指标名称）；术语、指标、口径一字不动；修改说明按“业务原话→公文表述”对照，理由用业务人员听得懂的话写。
- 审稿模式：用户只要意见、没让动稿子的（“先别动稿子”“看看哪些能删”），给一页纸：主要问题三至五条（每条一句话加依据）、建议删改的段落和预计改后字数（只给一个推荐值）、需要补的材料、转交事项（AI 腔的类型和位置，即使在拟删文字内也列出，建议再去 AI 腔）；不提问，需背景的标“待确认”；用户点名要改（如“压到3000字”）或说“那你改一版”的，首轮按高效模式出改后稿。
- 严谨模式：政治性提法、上级文件原文、领导原话一律不改写、不截断，压缩时只能整句保留或整句删去并在说明中列出；附提法核对清单（提法｜位置｜出处｜是否改动）。原稿已有提法不在正文逐处标记，出处栏写“未提供原文，请对照最新原文”；新增引用处也只在清单中标出。

## 单位差异

| 单位类型 | 改稿时特别注意 |
|---|---|
| 党政机关 | 下行文件压缩按减负规定上限，超限为 P1；提法最密，改前先圈出 |
| 基层 | 面向群众的稿子转大白话时写清时间、地点、要求、咨询电话；不向村（社区）转嫁责任 |
| 社区 | 对居民用服务和提醒的口气，不用命令口吻；居民信息一律脱敏 |
| 公立医院 | 指标名称照用原稿，不改成通俗说法；缩写首次写全称；患者信息脱敏 |
| 高校 | 校级与学院两级发文语气不同；学术材料保留学术用语；学生信息脱敏 |
| 中小学 | 致家长的稿子通俗、具体，写清需要家长配合的事 |
| 国有企业 | 经营数据、专业术语照用；商业秘密提醒脱敏；党委前置研究等程序表述不删 |

表中要“写清”的要素，原稿和材料没有的标【待补】，不自拟。医院、学校、国企内部材料不受减负规定字数条款直接约束，超限只作提示。详见 `references/units.md`。

## 参考资料

没有文件系统（网页版、内网提示词版）时，读不到的文件按本文和附录执行，不向用户索要。

| 文件 | 何时读取 |
|---|---|
| `references/length.md`、`tone.md`、`annotations.md`、`merge.md` | 第二步各任务（见各任务标题后的括注） |
| `references/checklist.md`、`references/units.md` | 无法运行脚本时；定单位类型后 |
| `references/_shared/guardrails.md`、`style/output-format.md` | 开工前、与用户要求冲突时；交付、交接卡 |
| `references/_shared/style/ai-tone.md`、`references/_shared/style/defensive.md` | 判断哪些归 humanize、direct；调语气强度 |
| `references/_shared/rules/` 下的 jianfu.md、doc-types.md、gbt15835.md、data-expression.md | 定压缩目标、查 JF-16；核对文种和惯用语；数字写法、百分点 |
| `references/_shared/profiles/roles.md`、`references/_shared/profiles/units/` | 定角色模式和单位类型 |
| `scripts/polish_stat.py` | count、compare、trace、comments、body |
| `scripts/fact_diff.py`、`scripts/change_guard.py`、`scripts/gongwen_lint.py` | 第三步复核 |