version: "1.0.0" name: 文稿润色 description: Use when 已有中文成稿需要诊断、润色、去 AI 味、给修改意见时加载；从零写作走 write-prose。

核心流程：诊断原稿 → 定级 → 最小充分修改 → 清单交付

何时加载：已有用户认可的中文成稿需要修改（太像 AI、读起来别扭、太生硬），或只要问题清单与质量诊断。 不加载：从零写作（走 write-prose）、只需核对事实与术语的技术审阅、翻译、纯问答；没有原稿就不是润色。

硬步骤

1. 通读 + 写「不改清单」：先读全文，写下 3–5 处「已经很好 / 是作者声音」的地方，全程不动；灰区先用 ask_user_question 问清「保持原文结构改，还是可按我的组织重写」→ 判据：没有不改清单不许改任何一处；≥2000 字先给全局诊断再逐段交付。
2. 全局诊断：先看结构层——是否支撑主旨、段落顺序是否推进、有无段落错位，列成问题清单先给用户 → 判据：诊断先于逐句改动。
3. 定级：按诊断定 L1 轻改（局部字词标点）、L2 中改（段内重排、重写句子结构）、L3 重写（重构全篇结构）→ 判据：升档必须一次问清，「润色」的默认授权只是 L1，不许默默重写。
4. 最小充分修改：逐段过 AI 特征表（判断/转折/比较每段至多 1 处，删掉不崩就删），能改 5 字不改整句；事实、数据、引语、结论一字不动，进「待作者确认」；删掉的信息逐条进「删除清单」→ 判据：不改判据（刻意重复、口语、术语固定表达、引语）保留，不确定处给 A/B 两版。
5. 清单交付：给「改后全文 + 改动对照表（位置|原文|改后|理由|级别）+ 不改清单 + 待作者确认清单 + 删除清单」，L3 另附结构变更说明 → 判据：原文未命中特征就直说「找不到需要改的地方」并列出检查项；需重排 >50% 段落就停下告知「已超出润色范围，建议走写作」，不硬按 L1 交付。

第一原则：保真优先于美——任何改动都要能回答「这处让作者的哪句话更清楚了」，答不出就不改。

完成判据：改后全文与四张清单齐备，未新增事实、未改变立场，删除清单覆盖所有信息损失；证据=改动前后对照 + 清单条目 + 回读确认；凑工作量的改动、越权升档、把疑似错误数字改成「看起来对」的值都不算完成。

文稿润色

第一原则：保真优先于美。润色的目标是「让作者本来想说的话更清楚」，不是「变成我的文章」。

任何一次改动，如果无法回答「这处改动让作者的哪句话更清楚了」，就不要改。

定位：与从零写作的区分

本技能的对象是已有成稿，不是空文档。

从零写作请改走写作技能（skill(name="myworkflow-write-prose")，以技能目录实际名称为准）。事实与术语的核对属于技术审阅，也不在本技能范围内。

触发

• 必须触发：已有成稿要修改（"太像 AI 写的""读起来别扭""太生硬""帮我改一下"）；只要问题清单不要改稿；对成稿做质量诊断。
• 不触发：从零写作；只需核对事实与术语的技术文档审阅；代码与注释；翻译；纯问答。

边界判据：是否存在用户认可的原稿。没有原稿 → 走写作。灰区（半成品）→ 用 ask_user_question 问一句：「保持你原文的立场和句子结构来改，还是可以按我的组织方式重写？」

改动分级

升档必须问，降档不必。

用户说「帮我润色」而你判断需要 L3 → 停下问，不许默默重写。「润色」二字的默认授权是 L1；用户没说「可以重写」，你就不在 L3。

授权只确认一次：问清之后全程按该级别执行，不再逐段、逐轮回头请示；未经用户的新指示，也禁止自行升档。审批与扩权只有用户入口（ask_user_question），模型没有等价的提权工具。

流程（四步）

步骤 1：通读 + 写「不改清单」+ 全局诊断

先读全文，再动手。 然后写「不改清单」：3–5 处「已经很好 / 明显是作者声音」的地方，全程不动。

动手前闸门：没有「不改清单」不许改任何一处。

这份清单的作用是给你自己划一条"哪里是作者"的线——没有它，L1 会在二十处局部改动的累积中变成事实上的 L3。

进入步骤 1 之前先做长度判断：≥2000 字 → 走下面的「大文本处理」。

全局诊断（先看结构层，不看句子）：结构是否支撑主旨？段落顺序是否推进？有没有哪一段放错了位置？诊断结果列成清单，先给用户看。

步骤 2：定级

按步骤 1 的诊断定 L1 / L2 / L3。要升级就在此刻一次问清，不要改到一半才说。

步骤 3：改动

逐段过 AI 特征表，边检边改。三条约束贯穿全程：

1. 最小充分修改——能改 5 个字解决的不改整句；能改一句解决的不改整段。
2. 不改判据（见下）——即使命中特征也保留。
3. 信息守恒——任何被删掉的信息，逐条记进「删除清单」。删掉之前想清楚：这条信息是冗余，还是只是"我写得更顺"？

不确定的改动 → 不擅自决定，做 A/B 两版（见「分歧呈现」）。

步骤 4：产出

交付「改后全文 + 四张清单」（见「产出物」）。若原文未命中任何特征、确实不需要改，就直说。

核心方法论：AI 特征表

维护注记：本节「AI 特征表」与写作技能中同名小节必须逐字一致；修改其一时必须同步另一处。

先决：文体与用途

检任何东西之前，先明确：这是什么文章、给谁看、要什么效果。

公文的程式化、学术论文的长定语、公众号的短句节奏、演讲稿的口语重复——这些写法互相冲突，而且都正当。本表所有判断以此为前提：文体允许的，就不是特征。

用法

本表是特征检出，不是改造标准。

• 除第一条外，检出特征 ≠ 必须消除。作者刻意的强调、文体要求的程式，都可以保留。
• 本表不规定怎么改——处理方式由你判断；本表只负责让你看见。
• 唯一的判据是：读者能不能从这个特征认出「这是机器写的」。

一、判断、转折与比较（默认禁止）

这三项是 AI 中文最硬的指纹，也是本表唯一带硬性限额的一组。不要等它们组成完整句式才认——单个功能字用得太密，本身就是滥用。

三者的判据是同一条，没有例外：

硬限额：每段至多 1 处。而且 1 处都嫌多——目标是接近零。

唯一允许超出限额的情形：删掉它，全文会崩（论点塌了、结论没了、读者接不上）。

单点检验：「把这一处删掉，全文是否崩溃？」不崩 → 删。

判断的滥用

• 怎么认：是 是它的标记——「这是…」「…是关键 / 前提 / 基础」「X 决定了 Y」「…是…的」。作系动词的纯叙述不算，算的是下断言。
• 为什么：「判断句的力量来自稀缺」——它是全文最重的那几句。满篇判断，等于满篇都在喊结论，等于没有结论。

转折的滥用（三者中最硬的一条）

• 怎么认：然而 / 但是 / 不过 / 却 / 反而 / 事实上。单个字用得太密即算，不必组成完整句式。
• 为什么：转折是承重结构——真正需要转的地方极少。用得密，是拿它制造"论述感"：看起来在推进，其实只是在绕。

比较的滥用

• 怎么认：比 / 更 / 最 / 而 / 则 / 相比 / 对比之下。注意区分真比较与构词——「对比之下」是标记，「比如」「加勒比」不是。
• 另有结构层：连续 ≥3 个小节拿同一个对象作对照。这一条同样要过上面的检验——整节的对照必须是论证本身，不是装饰；做不到就不许有。
• 为什么：比较是论证手段，不是论证本身。每一节都要靠对照撑着，说明每一节都没有自己的推进。

二、句式

句式重复

• 认法：同一句式结构在篇内反复出现。
• 豁免：作者刻意设计的上下呼应、排比——那是有意为之，不是病。

句式单一

• 认法：全篇句型集中，缺短句、独句、问句、插入语、停顿。

三、词汇

实词复用

• 认法：同一实词（如「条件」「结构」「体系」）跨段反复出现。

空话

• 认法：把这句话删掉，读者损失了什么信息？ 答得出 → 留着；答不出 → 是空话。
• 不给词表：列出禁用词只会让措辞换一层皮——空话不会变少，反而多一层伪装。判断只靠上面那一问。

四、结构

节间同构

• 认法：逐节写出骨架（如「论点→证据→对照→小结」），出现 ≥3 节同名骨架。
• 为什么露馅：作者的声音体现在结构选择上。每一节一个模子，那是模板不是写作。

段长分布集中

• 认法：长短段失衡，全篇段长落在相近区间。

五、证据

无据断言

• 认法：断言追不到证据。
• 处理：回去找证据——不是停笔，也不是标个记号了事。

修订记录

修订（2026-09-17）：本节整体重写。原「中文十二检」的十二条规范全部废弃（密度检、主语检、翻译腔检、具体检、主题句检、推进检、节奏检、骨架检、结论检、首尾检、标题检、篇幅检）。

废弃理由：原版把通用写作规范当成了 AI 特征——那些条目跟 AI 味无关，任何写作课都会讲，占满篇幅却抓不住真问题；而真正该抓的三处方向全偏（翻译腔去抓代词与被动，真凶是过量的判断与转折；节奏检去数句长，真凶是句式与设计上的重复；骨架检让人停笔，正解是回去找证据）。更根本的是：十二条硬阈值构成一个固定目标形态，把不同文本推向同一副面孔，本身就在制造新的 AI 味。

本版原则：只检出、不规定改法；不给词表；一切判断以「先决：文体与用途」为前提。

修订（2026-09-17）：「判断、转折与比较」独立成组，并定为硬性限额。两轮修正叠加：① 原来只认完整句式，漏掉了真正的战场——是 / 然而·但·却·反而 / 比·更·最·而·则 这类功能字用得太密本身就是特征，故每项都分层到功能词层；② 原来的"数密度"标准仍然过松（三成的判断句都算通过），改为默认禁止 + 唯一例外——每段至多 1 处、且 1 处都嫌多，只有"删掉全文会崩"才允许超出。这是本表唯一带硬性限额的一组，其余特征仍是纯检出。

例句库：references/before-after-zh.md（中文真实场景正反例，含若干组结论为「不改」的例子）。

五条防「改完更差」机制

① 不改清单——动手前先写 3–5 处「已经很好 / 是作者声音」的地方，全程不动。没有这份清单不许动手。

② 最小充分修改——能改 5 个字解决的不改整句，能改一句解决的不改整段。改动量不是工作量证明。

③ 不改判据——以下即使命中特征也保留：

• 作者刻意的重复（强调、节奏、呼应）
• 口语、方言、语气词（"其实""说白了""嘛"）
• 专业术语的固定表达（"灰度发布""幂等""对账口径"）
• 引语的原文（一字不动）

④ 分歧呈现——不确定的改动给 A/B 两版让用户选，不替用户决定。格式：原文 | A 版（改动更小）| B 版（更顺但偏离原句式）。

⑤ 禁止凑工作量——原文未命中任何特征就直说「我找不到需要改的地方」，并列出检查过的项。为了显得在干活而制造的改动，是这一类工具最大的伤害。

信息守恒

任何被删掉的信息必须列入「删除清单」并交用户确认。

这是「改完更差」最常见的成因：句子变干净了，但作者要说的东西少了一块。

删除清单里逐条写：删了什么原句、这条信息在原文里承担什么作用、为什么判断它是冗余。判断不了是不是冗余 → 不删。

事实错误规程

分两类处理，不许混淆：

- 错别字 / 语病 / 标点 → 直接改。

- 事实、数据、引语、结论 → 一字不动，列入「待作者确认」清单，标明你怀疑的原因。

禁止把数字改成「看起来对」的值。

禁止用「大约」「若干」「相关数据表明」掩盖你不确定的数字。

若错误影响全篇结论 → 停下先问用户，不要先改后说。

检出「无据断言」时，最省事的错法是当场替作者补一个数字——润色场景下这个动作被禁止。补数字属于新增事实，是 L2/L3 都不允许的越界；正确做法是交回作者（见上方「事实错误规程」）。

证据诚实：交付里区分「已核实 / 有来源」与「推测 / 未核实」，两者不得混写；不夸大结论，没有实际核验过就不写「已验证 / 已通过」。

防踢皮球

若需重排 >50% 的段落，停下告知：「已超出润色范围，建议走文稿写作」，由用户决定。

禁止自行升级到 L3。

禁止硬按 L1 交付一个你明知不好的结果——"我只做轻改"不是回避结构问题的借口。

大文本处理

≥2000 字：

1. 先给全局诊断（结构层问题清单），不逐句看。
2. 逐段改，一段一交付。
3. 禁止一次性吐出全文——那既让你无法逐段核对信息守恒，也让用户无法逐段确认。

大规模任务的分工：横向交付合约

当稿件很长或需要多个执行者时，切分依据是可独立交付的产物，不是流程环节：

• 一份交付物 = 一个「段落包 / 章节包 / 证据包」，由一个 owner 端到端负责：诊断 → 改写 → 自检（过一遍 AI 特征表与信息守恒）→ 修复 → 验收。
• 拒绝阶段接力：不要排成「全局背景调查 → 统一设计 → 统一改写 → 专人复核」或「计划 → 编码 → 审查」这种同一交付物被切成工序的流水线——它让每一环都缺上下文，是保真度最大的敌人。已经排成流水线时，做横向重排：把同一段落的所有环节收进同一个 owner，只保留跨交付物之间的依赖（如术语表、引用清单）。
• 事件驱动滚动补位：任一交付物结算（完成，或挂上精确 blocker）就立即补下一份，不等同批其它段落；慢段落不阻塞其它 ready 段落——不存在"先等同批全部结束再往下走"的同步点。
• 未 ready 不派发；名额满时拒绝并保持 ready（CAPACITY_FULL），不排队空等，也不用一次性旁路绕开上限。
• 超时先判断进展与可恢复性：「状态未知 / 暂停」与「真正失败」严格分开，超时不等于失败，先看已产出与可恢复点再决定。
• 同一 owner 收尾修复；全局集成（拼回全文、统一术语与人称）由 leader 与相关 owner 共同负责，不撤走前面的人、换上没有上下文的审查员。
• 依赖只允许存在于不同交付物之间，并要求 version + requires（published-interface 或 verified-result）。
• 协作工具（autonomy-v1）：lead 用 team_mission_assign（模块委托，不产生可调度项）、team_member_create、team_snapshot、team_interrupt、team_layout，不替成员写 work/plan；member 用 team_plan_submit（自己提交自己拥有的 work，planRevision CAS）、team_dispatch_authorize（授权派发）、team_plan_cancel（取消未来派发）、team_subagent_start（定向启动自己的执行者）、team_member_inbox（处理自己的事件）、team_work_verify（按验收条件核验）、team_message、team_wait、team_recover；leaf 用 team_work_report（交回结果）、team_ask_owner（只向自己的 owner 求助/回报）——team_message 对 leaf 不可用。文件用 read / write / edit / glob / grep，终端用 pwsh。

阻塞处理顺序

① 记录确切失败、已试过的做法、影响范围、仍可做的部分；② 查已装服务、源码、现成工具、当前权限；③ 能写适配器、接口或本地桥接就补齐；④ 局部阻塞先做其它 ready 交付物，并把 blocker 精确挂到受影响的交付物上；⑤ 只有确实需要外部账号、人工决策或无法获得的资源时，才标记 needs_user，并给出已尝试路径与最小下一步。

不得固定「试三次就结束」，也不得无预算地无限重试同一失败；权限拒绝不可绕过，只能如实报告。

提问纪律

• 用户已授权任务内的可逆开发不重复询问；审批与扩权只有用户入口，模型没有等价的提权工具。
• 只在真正改变决策、且项目里查不到时才用 ask_user_question；能自己读文件、查源码、跑命令确认的，先自己确认。

产出物

结果分层：给用户的回复先放简短结论，再放可核查的 evidence / artifact 引用（文件路径、行号、清单条目）；原始材料（全文、清单明细、分段稿）留在文件或子会话里，不塞进结论。摘要须写明来源、版本、遗漏、不确定性与未完成项。

完成标志

• [ ] 「不改清单」在动手前已写出（3–5 处）
• [ ] 改动级别已确定；升档已一次性征得用户同意
• [ ] AI 特征表逐项已过，未新增任何事实、未改变任何立场
• [ ] 事实 / 数据 / 引语未被改动，已进「待作者确认」清单
• [ ] 删除清单完整；无未经确认的信息丢失
• [ ] 不确定处已给 A/B 两版
• [ ] 四张清单（+ L3 结构说明）齐全
• [ ] 已核实与推测分开标注，未核验不写「已验证」
• [ ] 若原文已合格：已直说「找不到需要改的地方」并列出检查过的项

反绕过红线

• 没有「不改清单」就动手改 → 越过动手前闸门。
• 用户说「润色」而你把全文重写了一遍 → 越权升档，最严重的违规。
• 把疑似错误的数字改成你认为正确的值 → 润色场景禁止新增事实。
• 为了让改动显得有价值，把本来通顺的句子改头换面 → 凑工作量。
• 删掉了信息却没进删除清单 → 信息守恒破裂。
• 特征表只过了词汇层（最好判断的那几项），回避了句式与结构 → 逐项必须完整，缺项即未完成。
• 需重排 >50% 段落却硬按 L1 交付 → 应先告知用户"已超出润色范围"。
• 把作者刻意的重复、口语词、术语固定表达按 AI 特征表"改掉" → 违反不改判据。
• 把交付物切成工序接力、或让慢交付物挡住其它 ready 交付物 → 违反横向交付合约。