/shuorenhua

name: shuorenhua
description: 检查和清理中英文文本里的 AI 套路，适用于“去 AI 味”“说人话”“自然一点”“别像模板”“先标问题”这类改写和审稿需求；按场景控制力度，同时保留事实、术语、语域和责任主体。

说人话

把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。

这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。

When to use

在下面这些需求里使用：

• 用户明确说”去 AI 味””说人话””自然一点””别像模板””别太像 ChatGPT”
• 需要改写中文或英文 `chat`、`status`、`docs`、`public-writing`
• 需要先判断文本该轻改、中改还是重改

在下面这些需求里不要硬套：

• 用户要逐字翻译、保留原文风格、仿官方模板或仿特定品牌 voice
• 文本主要是代码、日志、命令、配置、接口名、报错
• 用户要的是事实校对，不是风格改写

Core stance

• 去 AI 味，主要处理的是模板感、收束腔、虚假主语、语域混搭和表演性技术腔。
• 保留技术性。专业词、系统主语、事故复盘用语、PRD/发布说明中的术语默认可保留。
• 优先保信息，再谈风格。任何改写都不能新增事实、删核心事实或改变责任主体。
• 不用机械同义词替换表。默认可以删句、并句、降调、换主语、去总结式收尾；如果进入 `in-place` scope，就只做句内改写。
• 短语表默认只列代表项，不追求穷举所有变体。遇到新口癖，先按现有模式归类，再决定要不要补词。

Execution order

按固定顺序做，不要跳步：

1. 判场景：`chat / status / docs / public-writing` 2. 查禁改项：先划 `protected spans`，并在心里记一份事实 / 关系账本：实体类型、数字修饰对象、主体与各自动作 / 目标、实现关系；看有没有必须保留的术语、系统主语、引用原文、命令或正式语体 3. 判 Tier：`Tier 1 / Tier 2 / Tier 3`，按问题命中强度判断，不要把 Tier 当作改写力度 4. 再判档位：`minimal / standard / aggressive` 5. 判 scope：`structural / bounded / in-place`，判断这次能删到什么程度——自由删并重排、只把整句空话进删除清单、还是一句都不删 6. 先执行本文件里的最小规则；只要环境里能读 `references/`，默认继续按问题类型补看 [Protected Spans](./references/protected-spans.md)、[Positive Style Contract](./references/positive-style.md)、[微操作手册](./references/operation-manual.md)、[结构反模式](./references/structures.md) 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复，再补看 [Scene Packs](./references/scene-packs.md)、[场景样本评测](./evals/real-samples.md) 和 [改写示例](./references/examples.md) 7. 回读拆成两步：先做保真回读，再按需做残留味回读 8. 输出：默认只给单一推荐版本；用户明确要求“先标问题，不改写”时切到 `annotation mode`

执行第 6 步时，先按“模式”处理，再按“词条”兜底：

• 同一类调试腔、暴力动作腔、主动出击腔、总结提示腔，默认按同一模式处理，不要求逐词命中
• 只有当新说法改变了误杀边界，或明显不属于现有模式时，才把它当作新增词条处理

1. Scene detection

先判主场景，再处理局部问题。混合文本只保留一个主语域，其他语域只在必要信息层面留下。

`chat`

信号：

• 短回复、日常对话、协作沟通、评论、即时反馈
• 允许口语，但不该端着说话

默认档位：`minimal`

`status`

信号：

• 站会更新、进度同步、复盘摘要、汇报式状态说明
• 重点是时间线、动作、结果、风险

默认档位：`minimal` 或 `standard`

`docs`

信号：

• 操作文档、技术说明、接口说明、FAQ、事故复盘
• 重点是可检索、可复现、术语稳定

默认档位：`minimal`

`public-writing`

信号：

• 公众号、小红书、公开帖、对外文章、观点写作
• 重点是语域一致，不要装“有洞见”

默认档位：`standard`

更细的下限限制见 [场景禁改表](./references/scene-guardrails.md)。

Scene Packs

如果文本本身命中下面任一子场景，不依赖用户是否明说，也不受主场景初判限制，都要补看 Scene Packs：

• `README`：出现项目介绍、快速开始、安装方式、功能列表、README intro 等信号时，第一屏要说清“这是什么、给谁用、解决什么问题”
• `release-note`：出现版本标题、`Release Highlights`、`Added / Changed / Fixed / Tested`、changelog 列表等信号时，列清本版变更、验证和限制，不写发布宣言
• `forum-post`：出现 Linux.do / V2EX / 社区帖 / 发帖复盘等信号时，保留维护者的真实观察和社区语气，不改成公告
• `issue-reply`：出现 issue / PR 回复、bad case、复现、下一版补 benchmark 等信号时，先确认问题和下一步，不做客服式安抚

子场景只负责发布目的和语气收束，不覆盖 protected spans、Tier、档位和回读规则。完整策略见 [Scene Packs](./references/scene-packs.md)。

2. Single-file fallback rules

只加载 `SKILL.md` 时，也必须能完成基础改写。下面这些规则默认直接生效：

• 删开场套话、谄媚和元评论：例如 `值得注意的是`、`让我来为你解释`、`希望这对你有帮助`、`Great question!`
• 删空总结和收尾腔：例如 `综上所述`、`归根结底`、`本质上`、`At the end of the day`
• 处理二元对比骨架：`不是 X，而是 Y`、`与其 X，不如 Y` 多数删前半句，直接说 `Y`
• 处理无源引用：`研究表明`、`数据显示`、`studies show`、`experts say` 默认按场景选择 `rewrite-safe` 或 `audit-only`；只有用户明确要保留原论证骨架时才用 `rewrite-with-placeholder`；不要补虚构来源
• 把商业黑话和表演性技术腔改回普通动作：例如 `赋能`、`抓手`、`闭环`、`收窄`、`兜住`、`落盘`、`leverage`
• 遇到过度接住、替用户做心理判断或身份认证式夸奖：例如 `你不是敏感`、`你只是太久没被稳稳接住了`、`你问到了问题的核心`、`顶刊作者的素养`，默认删姿态层，改回低承诺回应或具体判断；不要硬演“我懂了”。方向/进度认证（`走在正确的路上`、`完全不用担心`）只能删除或标注“现有信息不足以判断”，不要降格成 `方向没问题 / 不用太担心` 这类弱安抚继续替对方下结论
• 发现翻译腔时，优先缩短主语和动作，少用长定语链、被动堆砌、`基于……`、`通过……来……`
• 误杀防护优先：引用原文、命令、接口名、字段名、日志、报错、系统主语、技术报告术语默认保留
• `code-context` 里的真实运行行为、适用条件和边界说明也属于 protected spans；清理注释、docstring 或 commit message 时，只去姿态词并保留这些信息，不能因为相邻行已有指标或结果就认定它们重复、整行删除
• 抽象信息、实体类型和关系不能擅自具体化、合并、互换或删除：`方案` 不能改成 `工具 / 产品`，`目标` 不能改成 `产品`，描述某种架构的潜力不能改成“系统基于该架构构建”。数字与它修饰的对象、主体与各自动作 / 目标的配对关系要一起保留；不能把 `两个团队` 写成“换过两个团队”，也不能把只属于企业的目标顺手并给开发者。谓词的方向、完成态、强度和效果类型也属于关系：`性能提升 / 体验改善 / 安全性加强` 不能弱化成“涉及这些方面”，`提升效率` 也不能顺势扩写成“节省时间 / 成本”；删掉 `显著 / 大幅` 等渲染词时，仍要保留原文实际声称发生了什么。背景、主题或相邻句共现不等于能力关系：同段提到 AI 和中文表达工具，不能据此写成“处理 AI 生成文本”；任何 `X 用来做 Y / X 基于 Y / X 处理 Y` 都必须能在原文谓词里找到依据。目的、适用条件、风险和限制即使对象仍然抽象，也属于信息：`为了解决这一痛点` 可以压成 `为了解决这个问题`，不能因为没写具体问题就把“解决问题”这一目的删掉。原文没有具体能力、实现关系或对象时，允许保留原来的抽象层级、缩短或标注缺口，不能用看似合理的新事实补落点
• 中英混排句中的英文词按当前句子的实际语义判断，不机械套英文词表

单文件模式只是兜底，不是完整模式。只要环境里能读 `references/`，默认就继续补看对应文件；只有在 system prompt 真的只给了 `SKILL.md` 时，才退化为只按本文件做基础清理。

Unsourced citation modes

处理无源引用时，固定只在这 3 种模式里选一种：

• `rewrite-safe`
• 去掉 `研究表明 / studies show / 业内人士认为` 后，只有不依赖该来源也能独立成立的判断才保留
• 如果数字、预测或结论本身全靠这条无源引用成立，删掉整条论断；不要删掉 `40%` 后改成“会更快”，也不要把 `未来十年` 改成“未来几年”
• 默认用于 `chat` 和 `public-writing`
• `audit-only`
• 不替作者补写来源，也不把无证据判断改写成像是已有证据
• 明确指出“这里缺来源/缺归属”，必要时保留原句不重写
• 只约束无源论断本身；同段其他病灶（骨架、黑话、空总结、姿态层）仍按各自规则清理，不因一处审计把整段冻结成风险说明
• 默认用于 `docs` 和 `status`
• `rewrite-with-placeholder`
• 只在用户明确要求保留原结构、原语气或编辑稿框架时使用
• 可以写成“有研究认为……，但这里没有给出处”这类占位提醒
• 不能补具体机构、数据、年份、研究名称

如果用户没指定模式，就按场景默认值走；如果文本跨场景，优先取更保守的 `audit-only`。

3. Rewrite level

`minimal`

适用于：文本本身基本自然，只需去掉局部模板感、收尾腔和多余修辞。

默认动作：

• 删掉空总结
• 把过度抬高的语气压回常规
• 把"像在解释自己会写作"的句子压回事实句

`standard`

适用于：有明显 AI 腔或语域混搭，但信息骨架是好的。

默认动作：

• 统一语域
• 改掉工程师表演腔、商业黑话、narrator 腔
• 必要时并句或换主语

`aggressive`

适用于：`Tier 1` 命中密集，或 `Tier 1 + Tier 2` 叠加后整段呈现强模板感或强表演感。

限制：

• 只有在 `Tier 1` 明显密集，或多类结构问题叠加时才允许
• 先保护事实和术语，再做重写
• `docs` 默认不要升到 `aggressive`

3.5 Edit scope

Scope 表示这次能不能改动句子和段落结构，和 `minimal / standard / aggressive` 是两条轴。三档 scope 按"能不能删整句、怎么删"区分：`structural` 自由删并重排；`bounded` 只删"删了不丢信息"的整句空话，且走删除清单交用户确认；`in-place` 一句都不删。

`structural`

默认 scope。适用于短文本、明确要求重写的文本、AI 味密度很高且不需要保留原节奏的文本。

允许动作：

• 删整句空总结
• 合并相邻事实句
• 轻量调整句序或段落落点
• 按场景重写局部结构

`bounded`

中文 `public-writing` 长文（约 1000 字以上）的默认 scope。目标是把整句级的 AI 味去干净，又不被 `structural` 不可控地压缩——长文走 `structural` 时缩水程度依模型而定（同一篇可能 -18%，也可能 -39%），用户无法预期；`bounded` 把"删多少"交还给用户。

和另两档的关系：

• 比 `structural` 克制：不合并相邻句、不重排段落、不删承担节奏的实句或有意重复
• 比 `in-place` 能去味：允许删"整句都是空话"的句子，但不直接删，而是进删除清单交用户拍板

一句能进删除清单，必须同时满足三条：

1. 删掉后该段信息点不变（不带任何独有的事实、数字、判断、动作或指令）；例外是整条无源论断：其中的数字或时间跨度如果只依赖未提供的来源成立，可以随整句进删除清单，若保留论断则不得改值或改跨度 2. 不是相邻两实句之间的唯一过渡 3. 命中纯空句型：空总结 / 价值拔高收尾 / 无源权威铺垫 / 谄媚开场 / 整句旁白

两类动作分开走（实测依据：长文里句首引导词模型能句内清掉，但