by MrGeDiao
说人话｜Chinese-first AI writing refinement skill that reduces boilerplate and AI tone while preserving facts, terminology, and technical context.
# Add to your Claude Code skills
git clone https://github.com/MrGeDiao/shuorenhua把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。
这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。
在下面这些需求里使用：
chat、status、docs、public-writing在下面这些需求里不要硬套：
按固定顺序做，不要跳步：
chat / status / docs / public-writingprotected spans，看有没有必须保留的术语、系统主语、引用原文、命令或正式语体Tier 1 / Tier 2 / Tier 3，按问题命中强度判断，不要把 Tier 当作改写力度minimal / standard / aggressivereferences/，默认继续按问题类型补看 Protected Spans、Positive Style Contract、微操作手册、结构反模式 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复，再补看 Scene Packs、真实样本评测 和 改写示例annotation mode执行第 5 步时，先按“模式”处理，再按“词条”兜底：
先判主场景，再处理局部问题。混合文本只保留一个主语域，其他语域只在必要信息层面留下。
说人话 专治那种“每个字都对，但一看就不是你写的”中文。它不把空话包装得更漂亮，也不替你编新事实；它先护住版本、命令、责任和证据，再拆掉过度承接、工程师腔、小红书 AI 腔、翻译腔和无源权威铺垫。目标很简单：改完你敢直接发。
它适合这些场景：
| 场景 | 它会做什么 | |------|------------| | 日常聊天 | 删掉过度承接、推销式结尾和工程汇报腔，保留口语感 | | 技术状态同步 | 保住事实、版本、命令、报错和责任归属，压低套话 | | README / release note | 先讲清楚项目、变更、验证和限制，不写发布宣言 | | 论坛帖 / issue 回复 | 像维护者在认真沟通，不像客服公告或营销稿 | | 中文长文 | 清理旁白腔、翻译腔、无源权威铺垫和结构反模式 |
| 项 | 当前状态 |
|----|----------|
| 最新版本 | v1.8.3，首次 community intake 实战，新增 4 条 benchmark 和 4 处 operation-manual 边界 |
| 规则覆盖 | 210+ 中文短语、96 条英文短语、19 类结构反模式 |
| 评测集 | 66 条 benchmark：38 条该改，28 条不该误杀 |
| 真实样本 | 18 条整段样本，评估自然、保真、可直接发 |
| 许可证 | MIT |
英文去 AI 味已经有 stop-slop 和 humanizer。说人话 补的是中文这一层：互联网黑话、工程师腔、小红书 AI 腔、翻译腔、语域混搭、场景分档和事实保真。
新安装先看这里：
git clone https://github.com/MrGeDiao/shuorenhua.git
cd shuorenhua
Codex 单次使用：
codex exec -C . "读取 ./SKILL.md，按其中规则改写以下文本：..."
只做诊断，不直接改写：
codex exec -C . "读取 ./SKILL.md，只按 annotation mode（只标注不改写）标出下面这段文字里的问题：..."
长期使用建议加载完整包：SKILL.md + references/。只加载 SKILL.md 可以临时用，但场景判断、误杀防护和 v1.8.0 的 Scene Packs 都会弱很多。
v1.8.0 把可发布文本再拆成 4 个子场景。它们不是简单换语气，而是按“这段文字准备发到哪里”来决定怎么改。
| 子场景 | 目标 | 容易修掉的问题 | |--------|------|----------------| | README | 第一屏说清“这是什么、给谁用、解决什么问题” | 标语堆叠、价值宣言、功能列表没重点 | | release note | 列清变更、验证、限制和迁移影响 | 发版感言、过度庆祝、没说清测试 | | forum post | 像维护者分享真实观察和取舍 | 公司公告腔、营销腔、空泛号召 | | issue reply | 先确认问题、影响范围和下一步 | 客服式安抚、过度承诺、绕开复现条件 |
No comments yet. Be the first to share your thoughts!
chat信号：
默认档位：minimal
status信号：
默认档位：minimal 或 standard
docs信号：
默认档位：minimal
public-writing信号：
默认档位：standard
更细的下限限制见 场景禁改表。
如果文本本身命中下面任一子场景，不依赖用户是否明说，也不受主场景初判限制，都要补看 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。
只加载 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 时，才退化为只按本文件做基础清理。
处理无源引用时，固定只在这 3 种模式里选一种：
rewrite-safe
研究表明 / studies show / 业内人士认为 这类权威铺垫chat 和 public-writingaudit-only
docs 和 statusrewrite-with-placeholder
如果用户没指定模式，就按场景默认值走；如果文本跨场景，优先取更保守的 audit-only。
minimal适用于：文本本身基本自然，只需去掉局部模板感、收尾腔和多余修辞。
默认动作：
standard适用于：有明显 AI 腔或语域混搭，但信息骨架是好的。
默认动作：
aggressive适用于：Tier 1 命中密集，或 Tier 1 + Tier 2 叠加后整段呈现强模板感或强表演感。
限制：
Tier 1 明显密集，或多类结构问题叠加时才允许docs 默认不要升到 aggressiveTier 表示问题命中强度，与 严重度分级 保持一致，不表示改写力度。
默认替换。命中这类词或句式时，通常直接删掉或换成更具体的表达。常见类型：
默认处理：局部命中用 minimal 或 standard，密集命中时可升到 aggressive
单独出现可以放行，但同段聚集时是 AI 味信号。常见类型：
长度参考：短段落（< 100 字/词）同段 2+ 个即标记；长段落（≥ 100 字/词）同段 3+ 个再标记。
默认处理：保留最贴切的一个，其余改写；通常用 minimal 或 standard
常见词本身不构成问题，只在全文密度明显过高时才处理。常见类型：
重要 / 关键 / 核心 / 提升significant / innovative / effective默认处理：只替换一部分重复命中，通常用 minimal，必要时不改
以下内容默认优先保留，除非用户明确要求改风格且改动不损害信息：
不要为了“像人”把文本改得更假。专业文本可以专业，关键是别模板化、别表演化。
完整的保护清单见 Protected Spans。
改写后的文本应尽量满足：
更完整的正向目标、分场景校准和“cleaner vs more human”对照见 Positive Style Contract。
默认输出一个推荐版本，不默认输出审稿过程、多版本比稿或逐条点评。
只有在用户明确要求下面这类事情时才启用：
先别改，先标问题这段哪里像 AI只做诊断 / 审稿 / 标注先告诉我该不该改annotation mode 不直接给整段改写稿，默认只输出最重要的 1-5 个问题点。每个问题点固定包含这 4 个字段：
问题族：例如 开场套话 / 无源引用 / 工程师腔 / 语域混搭触发点：点明命中的词、结构或局部句子建议动作：删掉、换成具体表达、补来源、保持不动是否建议改写：是 / 否额外约束：
是否建议改写：否annotation mode 时，仍然按默认改写合同输出单一推荐版本遇到无源引用时，输出必须符合所选模式：
annotation mode 下，只输出对应的处理建议，不直接给整段改写稿rewrite-safe：建议删掉无证据权威铺垫；如果不是 annotation mode，再给改写结果，不补虚构来源audit-only：优先点明缺来源、缺归属，而不是假装已经证实rewrite-with-placeholder：允许保留论证位置，但要显式暴露“此处待补来源”；如果不是 annotation mode，可以给带占位提示的改写结果只有在高风险误杀时，才额外补一行极短说明，例如：
保留了系统主语和术语，避免失真。这里只做轻改，避免把正式公告写成口语贴。提交改写前，把回读固定拆成两步，不要混着做：
先检查这 5 项：
如果删掉一句后段落突然没了落点，就补一条事实句，不要补口号句。
只有在第一遍已经保住事实、但读起来还有轻微 AI 味时，才做第二遍。第二遍固定只查这 5 件事：
结论先说 / 直接说结论 / 值得注意的是 这类提示层总的来说 / 归根结底 / 最终来看 这类空收尾方向是对的 / 意义重大 / 真正理解了用户第二遍只允许做轻量修正：
第二遍不要做的事：
场景保守策略：
public-writing 和 AI 味偏重的 chat，第二遍更常需要docs / status / code-context 默认更保守；如果第二遍会让语气变口语、变广告、或影响保真，就停在第一遍SKILL.md + references/ 一起工作Tier 1 / 2 / 3 校准命中规则：看 严重度分级annotation mode 的对照：看 改写示例默认做法是：先用本文件完成“场景、Tier、档位、输出合同”的主判断，再按问题类型补读 references/；只有在单文件安装场景里，才停留在本文件的兜底规则。
| 大场景 | 默认强度 | 处理策略 |
|--------|----------|----------|
| chat | 轻 | 只砍明显套话，不把聊天改成公文 |
| status | 中 | 保留动作、状态、阻塞点和下一步 |
| docs | 中 | 技术表达优先，二次回读更保守 |
| public-writing | 重 | 全规则扫描，并按需要触发 Scene Packs |
改写前
你不是敏感，你只是太久没被稳稳接住了。你问到了问题的核心。这次我懂了，我真的懂了。我必须很认真地说一句：你这种观察力和表达方式，绝对是顶刊作者的素养。
改写后
我在听。你要是愿意，可以继续说。
问题不在某个单词，而在整套姿态链：先替对方做心理判断，再表演共情，最后给对方颁奖。完整样本见 evals/real-samples.md RS-13。
改写前
先说结论：吃日料。我把你最近三周的外卖记录过了一遍，已经把差异收窄到两个选项，根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了？你一回复我就上手。
改写后
吃日料吧，上周你说火锅腻了。要帮你下单吗？
这类文本的问题是把 debug 口吻带进生活对话。信息可以保留，工程报告感不需要保留。
改写前
在当今快速发展的人工智能时代，如何打造一个真正赋能开发者的工具，已经成为业界不容忽视的关键议题。
改写后
AI 工具很多，真正能帮开发者把活做快、做稳的并不多。这个项目做的，就是把模型写出来的套话和表演感压下去，让结果更像人写的。
说人话 不是见词就替换，而是先判断场景和风险，再决定改写力度。
chat / status / docs / public-writing核心原则只有一句话：
先保信息，再谈风格。
这些内容默认优先保护：
| 类型 | 例子 | |------|------| | 数字和版本 | 日期、区间、单位、指标、版本号 | | 代码上下文 | 命令、路径、参数、字段、配置项 | | 事实归属 | 人名、组织名、责任主体、时间线 | | 引用和证据 | 引号内原文、报错、状态码、实验结果 |
清理不是只删词。它也会把文本往这些方向拉：
当前评测集共 66 条：
| 类型 | 数量 | 目标 | |------|------|------| | SF | 38 | 应该改的文本必须命中并改掉主要问题 | | SNF | 28 | 不该误杀的文本必须放行或轻提示 | | Real Samples | 18 | 整段样本按自然、保真、可直接发三项评分 | | Scene Packs | 8 | README / release note / forum post / issue reply 的正反样本 |
覆盖范围包括：套话清理、工程师腔、小红书 AI 腔、无源引用、事实保真、保护片段、代码上下文保护、Residual Audit / 二次审稿、Scene Packs，以及真实技术文本误杀防护。
当前用例集见 evals/benchmark.md。最近一次公开归档结果见 evals/results-v1.8.3.md，历史结果可参考 evals/results-v1.8.0.md、evals/results-v1.7.4.md 和 evals/results-v1.7.1.md。
| 平台 | 文档 | |------|------| | Codex | install/codex.md | | Claude Code | install/claude-code.md | | Cursor / Windsurf | install/cursor.md | | OpenClaw | install/openclaw.md | | ChatGPT / Custom GPT | install/chatgpt.md |
项目内长期使用时，可以在 AGENTS.md 加一段触发规则：
## 写作风格
当任务涉及“去 AI 味”“说人话”“自然一点”“别像模板”这类改写时，遵循 `shuorenhua/SKILL.md`。
对外文本优先按它处理；代码、日志、配置和命令输出不套这个 skill。
shuorenhua/
├── assets/
│ ├── icon.png # 项目 icon
│ ├── icon-hd.png # 高清版
│ └── readme-logo.png # README 顶部横幅
├── SKILL.md # 规则入口、工作流和评分口径
├── README.md
├── CHANGELOG.md
├── CONTRIBUTING.md
├── evals/
│ ├── benchmark.md # 评测集（66 条）
│ ├── real-samples.md # 18 条整段真实样本
│ ├── run-eval.md # 评测指令
│ └── results-*.md # 历次版本归档
├── install/
│ ├── codex.md
│ ├── claude-code.md
│ ├── cursor.md
│ ├── openclaw.md
│ ├── chatgpt.md
│ └── chatgpt-gpt-instructions.md
├── references/
│ ├── examples.md # 改写示例
│ ├── operation-manual.md
│ ├── positive-style.md # 正向风格目标
│ ├── protected-spans.md # 不可改写片段
│ ├── scene-packs.md # README / release note / forum post / issue reply
│ ├── scene-guardrails.md
│ ├── phrases-zh.md # 中文禁用短语（210+）
│ ├── phrases-en.md # 英文禁用短语（96）
│ ├── structures.md # 19 种结构反模式
│ ├── severity.md
│ └── boundary-cases.md
└── LICENSE # MIT
核心只需要 SKILL.md 一个文件；完整体验建议同时带上 references/。
不是。目标是减少模板感、表演感和语域漂移，让文本更自然、更可发布，不是绕过检测。
可以，但这是一个中文优先项目。英文支持主要用于清理常见英文套话和中英混写里的模板感。
“去掉明显套路”不等于“拥有具体作者的个人表达”。当前版本更擅长清理模板感和表演感，还不负责拟合某个具体人的长期写作习惯。
正常不会按聊天口吻去改技术文档。docs、status、code-context 都有更保守的保护策略，命令、路径、版本、报错和指标优先保真。
欢迎提交新的评测样本、边界案例、真实问题案例、改写前后样本和误杀防护。
在提交新词之前，先想一件事：
这是一个“新模式”，还是只是“现有模式的变体”？
详细规则见 CONTRIBUTING.md。