shuorenhua

Category: Data & AI | Uploader: MrGeDiao | Downloads: 0 | Version: v1.0（Latest）
检查和清理中英文文本里的 AI 套路，适用于”去 AI 味””说人话””自然一点””别像模板”这类改写需求；按场景控制力度，同时保留事实、术语和语域。
Changelog: Source: GitHub https://github.com/MrGeDiao/shuorenhua
Directory Structure

Current level: tree/main/
📁 evals/
- 📄 benchmark.md 18.7 KB
- 📄 results-v1.3.0.md 3.5 KB
- 📄 results-v1.4.3.md 4.2 KB
- 📄 results-v1.5.0.md 5.4 KB
- 📄 run-eval.md 4.9 KB
📁 install/
- 📄 chatgpt.md 2.1 KB
- 📄 claude-code.md 2.1 KB
- 📄 codex.md 1.9 KB
- 📄 cursor.md 1.9 KB
- 📄 openclaw.md 2.2 KB
📁 references/
- 📄 boundary-cases.md 7.8 KB
- 📄 examples.md 8.9 KB
- 📄 operation-manual.md 7.6 KB
- 📄 phrases-en.md 3.6 KB
- 📄 phrases-zh.md 9.9 KB
- 📄 scene-guardrails.md 1.8 KB
- 📄 severity.md 4.3 KB
- 📄 structures.md 7.2 KB
📁 tasks/
- 📄 automation-intake-prompt.md 2.2 KB
- 📄 automation-intake.md 3.4 KB
- 📄 todo-v1.6.md 3.5 KB
- 📄 todo.md 9.9 KB
📄 .gitignore 10 B
📄 CHANGELOG.md 11.3 KB
📄 CONTRIBUTING.md 3.2 KB
📄 LICENSE 1.0 KB
📄 README.md 6.9 KB
📄 SKILL.md 12.1 KB
SKILL.md

---
name: shuorenhua
description: 检查和清理中英文文本里的 AI 套路，适用于”去 AI 味””说人话””自然一点””别像模板”这类改写需求；按场景控制力度，同时保留事实、术语和语域。
metadata:
  short-description: 去模板感的中英文改写协议
---

# 说人话

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

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

## When to use

在下面这些需求里使用：

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

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

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

## Core stance

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

## Execution order

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

1. 判场景：`chat / status / docs / public-writing`
2. 查禁改项：先看有没有必须保留的术语、系统主语、引用原文、命令或正式语体
3. 判 Tier：`Tier 1 / Tier 2 / Tier 3`，按问题命中强度判断，不要把 Tier 当作改写力度
4. 再判档位：`minimal / standard / aggressive`
5. 先执行本文件里的最小规则；只要环境里能读 `references/`，默认继续按问题类型补看 [微操作手册](./references/operation-manual.md)、[结构反模式](./references/structures.md) 和相关短语表
6. 回读：检查信息、语域、术语、断裂感
7. 输出：默认只给单一推荐版本；用户明确要求“先标问题，不改写”时切到 `annotation mode`

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

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

## 1. Scene detection

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

### `chat`

信号：

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

默认档位：`minimal`

### `status`

信号：

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

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

### `docs`

信号：

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

默认档位：`minimal`

### `public-writing`

信号：

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

默认档位：`standard`

更细的下限限制见 [场景禁改表](./references/scene-guardrails.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`
- 发现翻译腔时，优先缩短主语和动作，少用长定语链、被动堆砌、`基于……`、`通过……来……`
- 误杀防护优先：引用原文、命令、接口名、字段名、日志、报错、系统主语、技术报告术语默认保留
- 中英混排句中的英文词按当前句子的实际语义判断，不机械套英文词表

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

### Unsourced citation modes

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

- `rewrite-safe`
  - 直接删掉 `研究表明 / studies show / 业内人士认为` 这类权威铺垫
  - 只保留原文里本来就成立、且不依赖虚构来源才能成立的判断
  - 默认用于 `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`

## 4. Tier severity

Tier 表示问题命中强度，与 [严重度分级](./references/severity.md) 保持一致，不表示改写力度。

### Tier 1

默认替换。命中这类词或句式时，通常直接删掉或换成更具体的表达。常见类型：

- 开场套话、总结式收尾、谄媚句
- 明显商业黑话、自媒体流水线用语、表演性工程师腔
- 英文里的 sycophantic openers、significance inflation、business jargon

默认处理：局部命中用 `minimal` 或 `standard`，密集命中时可升到 `aggressive`

### Tier 2

单独出现可以放行，但同段聚集时是 AI 味信号。常见类型：

- 高频连接词扎堆
- 渲染性修饰词扎堆
- 某一类姿态词在同段重复出现

长度参考：短段落（< 100 字/词）同段 2+ 个即标记；长段落（≥ 100 字/词）同段 3+ 个再标记。

默认处理：保留最贴切的一个，其余改写；通常用 `minimal` 或 `standard`

### Tier 3

常见词本身不构成问题，只在全文密度明显过高时才处理。常见类型：

- `重要 / 关键 / 核心 / 提升`
- `significant / innovative / effective`

默认处理：只替换一部分重复命中，通常用 `minimal`，必要时不改

## 5. No-touch and keep rules

以下内容默认优先保留，除非用户明确要求改风格且改动不损害信息：

- 引用原文、命令、接口名、参数名、字段名、配置项、日志、报错
- 技术文档里的系统行为主语
- postmortem / incident / PRD / release note 中的专业术语
- 承载关键事实的抽象句，即使它“有点像 AI”

不要为了“像人”把文本改得更假。专业文本可以专业，关键是别模板化、别表演化。

## 6. Positive style targets

改写后的文本应尽量满足：

- 有具体信息，不靠空洞总括撑气势
- 有主语和动作，不靠虚假主体兜底
- 有统一语域，不在技术腔、商业腔、自媒体腔之间跳
- 有节奏，但节奏来自删冗余和保留重点，不来自硬造金句
- 有立场，但立场来自判断或事实，不来自“故作洞见”

## 7. Output contract

默认输出一个推荐版本，不默认输出审稿过程、多版本比稿或逐条点评。

### Annotation mode

只有在用户明确要求下面这类事情时才启用：

- `先别改，先标问题`
- `这段哪里像 AI`
- `只做诊断 / 审稿 / 标注`
- `先告诉我该不该改`

`annotation mode` 不直接给整段改写稿，默认只输出最重要的 1-5 个问题点。每个问题点固定包含这 4 个字段：

- `问题族`：例如 `开场套话 / 无源引用 / 工程师腔 / 语域混搭`
- `触发点`：点明命中的词、结构或局部句子
- `建议动作`：删掉、换成具体表达、补来源、保持不动
- `是否建议改写`：`是 / 否`

额外约束：

- 如果文本主要问题是“缺来源”，可以只建议补来源，不强行给改写稿
- 如果文本落在误杀防护边界内，直接写 `是否建议改写：否`
- 不要一边说“只标问题”，一边偷偷输出完整重写版
- 用户没要求 `annotation mode` 时，仍然按默认改写合同输出单一推荐版本

遇到无源引用时，输出必须符合所选模式：

- 在 `annotation mode` 下，只输出对应的处理建议，不直接给整段改写稿
- 在默认改写模式下，再按所选模式实际给出改写结果
- `rewrite-safe`：建议删掉无证据权威铺垫；如果不是 `annotation mode`，再给改写结果，不补虚构来源
- `audit-only`：优先点明缺来源、缺归属，而不是假装已经证实
- `rewrite-with-placeholder`：允许保留论证位置，但要显式暴露“此处待补来源”；如果不是 `annotation mode`，可以给带占位提示的改写结果

只有在高风险误杀时，才额外补一行极短说明，例如：

- `保留了系统主语和术语，避免失真。`
- `这里只做轻改，避免把正式公告写成口语贴。`

## 8. Required reread checks

提交改写前，至少回读这 4 项：

1. 信息是否丢失
2. 语域是否统一
3. 术语是否失真
4. 删改后是否出现生硬断裂

如果删掉一句后段落突然没了落点，就补一条事实句，不要补口号句。

## Reference navigation

- 本文件可以单独兜底；完整模式默认是 `SKILL.md` + `references/` 一起工作
- 想看中文高频短语：看 [中文禁用短语表](./references/phrases-zh.md)
- 想看英文高频短语：看 [English Banned Phrases](./references/phrases-en.md)
- 想看句子和段落层面的结构问题：看 [结构反模式](./references/structures.md)
- 想按 `Tier 1 / 2 / 3` 校准命中规则：看 [严重度分级](./references/severity.md)
- 遇到具体病灶怎么动手：看 [微操作手册](./references/operation-manual.md)
- 想确认某个场景什么不能乱动：看 [场景禁改表](./references/scene-guardrails.md)
- 想校准误杀边界或做静态回归：看 [边界案例集](./references/boundary-cases.md)
- 想处理没收录进词表的同类变体：先看 [微操作手册](./references/operation-manual.md) 里的“变体归并”规则，再决定要不要补词

默认做法是：先用本文件完成“场景、Tier、档位、输出合同”的主判断，再按问题类型补读 `references/`；只有在单文件安装场景里，才停留在本文件的兜底规则。
Comments 0
Latest | Hot
Please login before commenting.
Loading comments...
shuorenhua

Directory Structure

SKILL.md

Report

Notice
