shuorenhua（说人话）

shuorenhua（说人话）快速入门

「别让模型替你装腔」——shuorenhua（MrGeDiao/shuorenhua）是一个中文优先的去 AI 味改写 Skill：清理 AI 起草内容里的模板套话、商业黑话、工程师姿态腔、翻译腔和无依据断言，同时把数字指标、版本编号、命令参数、文件路径、因果条件、责任归属全部锁死不动。2026-09-26 核验：GitHub 1,878★ / 79 fork，最近 push 2026-09-25（持续活跃），最新版 v2.4.0，MIT 许可。

这是什么？适合谁？

大多数「去 AI 味」工具是短语黑名单替换，砍掉套话的同时经常把事实一起砍掉——p95 延迟从 480ms 降到 160ms 被概括成「明显优化」，展示了云原生潜力 被升格成「已采用云原生架构」。shuorenhua 的核心差异是改写前先锁定事实：识别文本场景 → 锁定事实片段 → 判断问题强度 → 优先处理句式与段落结构（短语表仅兜底）→ 双向保真回读（原文所有事实点改写后均有对应，改写后每个结论原文均有出处）→ 残留审计。它还自带一套 120 条用例的评测体系和「L1 硬约束零失败才可发布」的门槛（虚构事实、保护片段漂移、篡改归属、超 scope 任一出现即阻塞）。

适合人群：

• 用 AI 起草 README / Release Notes / 工作同步 / Issue 回复 / 论坛发帖的开发者与维护者：要的是「改完可直接发」
• 技术写作者、公众号作者：处理中英混排的结构冗余与翻译腔
• 给团队配置统一文风规范的人：一条 npx skills add 装进 Agent，AGENTS.md 里一句引导规则即可全员生效

不适合谁：想拟合特定作者个人文风的人（官方明示只做规则驱动的冗余清理与保真纠偏）；想用它绕过 AI 内容检测的人（FAQ 明确否认此设计目标）；英文为主写作的人（中文优先，英文规则只兜底清理常见套话）。

准备工作

• 运行环境：任一支持 Skill 的 Agent（Claude Code / Codex / Cursor / Windsurf / OpenClaw）；或零安装走网页版「说人话 GPT」（需 ChatGPT Plus/Pro）
• 账号要求：无（开源 MIT）；网页版需 ChatGPT 付费计划
• 时间预算：安装 1 分钟，首次改写即时见效
• 前置知识：知道「给 Agent 装 Skill」是什么；明确自己的文本场景（README/发版说明/论坛帖/Issue 回复/API 文档/FAQ）
• 替代方案：hardikpandya/stop-slop（英文规则）、blader/humanizer（英文分类体系）、自己手改

快速上手

第一步：安装

Claude Code 内执行：

/plugin marketplace add MrGeDiao/shuorenhua
/plugin install shuorenhua@shuorenhua

其他支持 skills 协议的 Agent：

npx skills add MrGeDiao/shuorenhua

Codex 单次使用：

git clone https://github.com/MrGeDiao/shuorenhua.git && cd shuorenhua
codex exec -C . "读取 ./SKILL.md，按其中规则改写以下文本：……"

第二步：第一个任务

对话里直接说：

把这段去 AI 味：
本次优化在性能方面取得了显著成效，有效改善了接口响应问题，
充分体现了团队持续优化的能力。（附：p95 延迟从 480ms 降到 160ms）

预期产出：这次优化把接口 p95 延迟从 480ms 降到 160ms。——指标全保留，空话全删掉。这正对应评测集硬约束用例 SF-46。

第三步：按场景选改写力度

• 只想排查不想改：附加「按 annotation mode 只标注不改写」
• 长文怕改坏结构：默认 bounded scope（疑似空话归入「建议删除（待确认）」清单）；要大修用 structural；严格保留排版用 in-place
• 不同文体自动切换场景包：README / Release Note / Forum Post / Issue Reply / API Reference / FAQ 各有定制改写重心（API Reference 严格保护 Endpoint、参数、状态码）

第四步：团队固化（可选）

在团队仓库的 AGENTS.md 加一段引导规则，Agent 之后自动调用：

## 写作风格
当任务涉及「去 AI 味」「说人话」「自然一点」「别像模板」这类改写时，
遵循 shuorenhua/SKILL.md。对外文本优先按它处理；
代码、日志、配置和命令输出不套这个 skill。

常见踩坑

1. 担心技术文档被误改：docs/status/code-context 场景有更严保护策略（锁定命令、路径、版本、报错、性能数据）；真遇到误改，官方征集脱敏 Bad Case（Issue #5），别闷头自己改规则。
2. 长文直接上 structural scope：跨句合并重排对长文结构破坏大，长文默认 bounded 是有原因的；不确定就先用 annotation mode 看标注再动手。
3. 把 mini 规格当完整版用：dist/shuorenhua-mini.md 是 1,500 字符内的自包含精简版，用于 Custom Instructions 等上下文受限环境；长期工程项目用 full（SKILL.md + references 完整规则集）。
4. 以为它能「润色出文采」：它删的是套路与冗余，不拟合个人文风；改完「不够生动」是设计使然，不是 bug。
5. 贡献词条前不看规范：新增词条前先确认它代表新的表达模式而非已有规则的同义词（CONTRIBUTING.md 有明确要求），否则 PR 会被打回。

常见问题 FAQ

Q1：能用于规避 AI 内容检测吗？

A：不能也不以此为目标。它清理模板化表达、公关腔调与生硬句式，提升可读性与准确度；FAQ 明确否认绕过检测算法的设计意图。

Q2：支持英文吗？

A：支持但以中文优化为主；英文规则主要用于清理常见英文套话和中英混排时的结构冗余。英文为主可看同项目的友链 stop-slop / humanizer。

Q3：改写质量怎么保证不删掉事实？

A：双向回读验证（原文事实点 ↔ 改写结论互查）+ L1 硬约束门槛（虚构事实/保护片段漂移/篡改归属/超 scope 必须零失败才能发版）+ 匿名乱序盲评 benchmark + 独立校验脚本 hard_metrics.py。v2.4.0 评测记录显示双模型 L1 违规均为 0。

Q4：评测集是什么规模？

A：主 benchmark 120 条（SF 应改 63 + SNF 不应改 57）+ 20 条场景样本单独评估；另有 10 篇人类长文对照用于观察假阳性，不计入分母。SNF 误杀率门槛是 10% 以下。

Q5：Claude Code 之外还有哪些接入方式？

A：Codex（clone 后 codex exec）、Cursor/Windsurf、OpenClaw、ChatGPT Custom GPT（网页版），install/ 目录逐平台有文档；规格分 mini / lite / full 三档按场景选。

权限、安全、成本与限制

• 许可：MIT。
• 安全：纯文本改写规则，无代码执行、无网络调用；贡献时官方要求脱敏（禁止包含未授权对话、账号密钥、内网链接、个人隐私）。
• 成本：完全免费；网页版消耗你已有的 ChatGPT 订阅。
• 限制：中文优先（英文仅兜底）；不拟合个人文风；本文基于仓库 README 与 GitHub API 核验（2026-09-26），未逐条跑 120 条评测集。

小技巧

1. 先用 annotation mode 跑一遍存量文档，看它标注的问题密度，再决定哪些文件值得真改。
2. 发版说明用 Release Note 场景包：变更项、验证结果、使用限制会保留，公关式发版宣言会被清掉。
3. 中英混排文档交给它处理「翻译腔」比手动逐句顺稿快得多，重点看它对连接词嵌套的简化。
4. p95 延迟 480ms→160ms 类的数字-修饰绑定是它最招牌的能力，抽查改写结果时优先核这类句子。
5. 团队接入时把「代码、日志、配置和命令输出不套这个 skill」写进引导规则，避免误伤技术文本。

进阶学习方向

• 保护边界工程：读 references/protected-spans.md，学它如何定义「不可动的事实片段」，思路可迁移到任何 LLM 文本改写工具。
• 评测体系设计：evals/ 目录的 SF/SNF 划分、匿名乱序盲评、硬指标校验脚本，是一套可复用的 Skill 质量验收范式。
• 相关项目对比：stop-slop（英文规则+评估框架）、humanizer（英文模式分类）、avoid-ai-writing（问题分类与严重度）、speak-human-tw（繁体中文）——横向对比能看清「中文优先」的差异化在哪。
• scope 参数演进：跟进 issue #4 关于长文力度控制的讨论，理解 structural/bounded/in-place 的取舍逻辑。

参考链接

• 官方仓库
• 评测基准
• v2.4.0 评测记录
• 说人话 GPT 网页版