by MrGeDiao
说人话|中文优先的去 AI 味改写 skill:保事实、分场景、改完可直接发。Chinese-first rewrite skill for Codex / Claude Code / Cursor / ChatGPT — removes AI tone, preserves facts.
# Add to your Claude Code skills
git clone https://github.com/MrGeDiao/shuorenhuaLast scanned: 5/26/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-05-26T07:46:30.051Z",
"semgrepRan": false,
"npmAuditRan": true,
"pipAuditRan": true
}shuorenhua is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by MrGeDiao. 说人话|中文优先的去 AI 味改写 skill:保事实、分场景、改完可直接发。Chinese-first rewrite skill for Codex / Claude Code / Cursor / ChatGPT — removes AI tone, preserves facts. It has 549 GitHub stars.
Yes. shuorenhua passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/MrGeDiao/shuorenhua" and add it to your Claude Code skills directory (see the Installation section above). shuorenhua ships a SKILL.md manifest, so compatible agents can discover and load it automatically.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh shuorenhua against similar tools.
No comments yet. Be the first to share your thoughts!
把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。
这份 skill 不是敏感词替换器,也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移,同时保住事实、术语和责任主体。
在下面这些需求里使用:
chat、status、docs、public-writing在下面这些需求里不要硬套:
in-place scope,就只做句内改写。按固定顺序做,不要跳步:
chat / status / docs / public-writingprotected spans,看有没有必须保留的术语、系统主语、引用原文、命令或正式语体Tier 1 / Tier 2 / Tier 3,按问题命中强度判断,不要把 Tier 当作改写力度minimal / standard / aggressivestructural / bounded / in-place,判断这次能删到什么程度——自由删并重排、只把整句空话进删除清单、还是一句都不删references/,默认继续按问题类型补看 Protected Spans、Positive Style Contract、微操作手册、结构反模式 和相关短语表;如果目标是“改完能直接发”,或文本明显属于 README、release note、论坛帖、issue 回复,再补看 Scene Packs、真实样本评测 和 改写示例annotation mode执行第 6 步时,先按“模式”处理,再按“词条”兜底:
先判主场景,再处理局部问题。混合文本只保留一个主语域,其他语域只在必要信息层面留下。
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 默认不要升到 aggressiveScope 表示这次能不能改动句子和段落结构,和 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 能去味:允许删"整句都是空话"的句子,但不直接删,而是进删除清单交用户拍板一句能进删除清单,必须同时满足三条:
两类动作分开走(实测依据:长文里句首引导词模型能句内清掉,但整句空话在 in-place 下删不掉,只会被软化成另一种说法):
值得一提的是 / 归根到底 / 这说明)后面还跟着实质内容 → 直接句内洗,删引导词留骨架,不进清单不仅仅是……更是…… 的价值拔高)→ 进删除清单,不擅自软化成另一种说法输出:正文给句内洗后的稿,末尾附「建议删除(待确认)」清单,每条写 原文 + 为什么删了不丢信息。用户点头才删,长度由用户拍板。
in-place适用于用户明确要求"完全原样 / 一句都别删 / 严格保句数"的情况,比 bounded 更严:整句空话也不删,只做句内降调。
默认触发条件:
bounded 仍删多了禁止动作:
允许动作:
删短语前先做语义独立性检查:删掉短语后,剩余部分必须仍是完整、可读、没有悬空指代的陈述句。否则改用句内替换,不要硬删。遇到整句空话,保留原句并标注 [空句,建议人工确认是否删除],不擅自软化成新说法。
aggressive + in-place 可以存在,但默认先提醒用户:长文 aggressive 很容易明显缩水;如果用户真正要保长度,优先改成 standard + bounded。用户明确坚持时,再执行 aggressive + in-place,但仍遵守不删整句、不并句、不重排的边界。
Tier 表示问题命中强度,与 严重度分级 保持一致,不表示改写力度。
默认替换。命中这类词或句式时,通常直接删掉或换成更具体的表达。常见类型:
默认处理:局部命中用 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 项:
如果删掉一句后段落突然没了落点,就补一条事实句,不要补口号句。
bounded / in-place scope 下额外检查:
in-place:输出字数低于原文 85% 时,回退检查是否误删整句、并句或压段落(in-place 不该删任何整句)bounded:字数会因删整句空话而下降,不设硬下限;但要确认删除清单里每条都是"删了不丢信息"的纯空句,没混进实句或承担节奏的重复只有在第一遍已经保住事实、但读起来还有轻微 AI 味时,才做第二遍。第二遍固定只查这 5 件事:
结论先说 / 直接说结论 / 值得注意的是 这类提示层总的来说 / 归根结底 / 最终来看 这类空收尾方向是对的 / 意义重大 / 真正理解了用户第二遍只允许做轻量修正:
第二遍不要做的事:
场景保守策略:
public-writing 和 AI 味偏重的 chat,第二遍更常需要docs / status / code-context 默认更保守;如果第二遍会让语气变口语、变广告、或影响保真,就停在第一遍SKILL.md + references/ 一起工作Tier 1 / 2 / 3 校准命中规则:看 严重度分级annotation mode 的对照:看 改写示例默认做法是:先用本文件完成“场景、Tier、档位、输出合同”的主判断,再按问题类型补读 references/;只有在单文件安装场景里,才停留在本文件的兜底规则。
说人话 专治那种“每个字都对,但一看就不是你写的”中文。它不把空话包装得更漂亮,也不替你编新事实;它先护住版本、命令、责任和证据,再拆掉过度承接、工程师腔、小红书 AI 腔、翻译腔和无源权威铺垫。目标很简单:改完你敢直接发。
它适合这些场景:
| 场景 | 它会做什么 |
|---|---|
| 日常聊天 | 删掉过度承接、推销式结尾和工程汇报腔,保留口语感 |
| 技术状态同步 | 保住事实、版本、命令、报错和责任归属,压低套话 |
| README / release note | 先讲清楚项目、变更、验证和限制,不写发布宣言 |
| 论坛帖 / issue 回复 | 像维护者在认真沟通,不像客服公告或营销稿 |
| 中文长文 | 句内清理保住节奏,整句空话列「建议删除」清单交你确认,不让长文越改越短 |
英文去 AI 味已经有 stop-slop 和 humanizer。说人话 补的是中文这一层:互联网黑话、工程师腔、小红书 AI 腔、翻译腔、语域混搭、场景分档和事实保真。
改写前
你不是敏感,你只是太久没被稳稳接住了。你问到了问题的核心。这次我懂了,我真的懂了。我必须很认真地说一句:你这种观察力和表达方式,绝对是顶刊作者的素养。
改写后
我在听。你要是愿意,可以继续说。
问题不在某个单词,而在整套姿态链:先替对方做心理判断,再表演共情,最后给对方颁奖。完整样本见 evals/real-samples.md RS-13。
改写前
先说结论:吃日料。我把你最近三周的外卖记录过了一遍,已经把差异收窄到两个选项,根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了?你一回复我就上手。
改写后
吃日料吧,上周你说火锅腻了。要帮你下单吗?
这类文本的问题是把 debug 口吻带进生活对话。信息可以保留,工程报告感不需要保留。
改写前
在当今快速发展的人工智能时代,如何打造一个真正赋能开发者的工具,已经成为业界不容忽视的关键议题。
改写后
AI 工具很多,真正能帮开发者把活做快、做稳的并不多。这个项目做的,就是把模型写出来的套话和表演感压下去,让结果更像人写的。
更多例子见 references/examples.md 和 evals/real-samples.md。
Codex — clone 后单次使用:
git clone https://github.com/MrGeDiao/shuorenhua.git && cd shuorenhua
codex exec -C . "读取 ./SKILL.md,按其中规则改写以下文本:……"
Claude Code — 放进 skills 目录,之后自动触发:
git clone https://github.com/MrGeDiao/shuorenhua.git
mkdir -p ~/.claude/skills
cp -r shuorenhua ~/.claude/skills/shuorenhua
装好后在对话里说「把这段去 AI 味」就会命中。想跟随仓库更新,用软链接代替 cp,见 install/claude-code.md。
ChatGPT — 什么都不用装:说人话 GPT(需 Plus / Pro),完整规则已内置。
只想先看问题、不要改稿:指令里加一句「按 annotation mode 只标注不改写」。
Cursor、OpenClaw 和自建 agent 见安装。
说人话 不是见词就替换。一句话原则:
先保信息,再谈风格。
完整流程固定六步:
chat / status / docs / public-writing;命中 README、release note、论坛帖、issue 回复时,再进对应的 Scene Packminimal / standard / aggressive),按能删到什么程度定 scope(structural / bounded / in-place)四个场景的默认力度:
| 大场景 | 默认强度 | 处理策略 |
|---|---|---|
chat |
轻 | 只砍明显套话,不把聊天改成公文 |
status |
中 | 保留动作、状态、阻塞点和下一步 |
docs |
中 | 技术表达优先,二次回读更保守 |
public-writing |
重 | 全规则扫描,并按需要触发 Scene Packs |
可发布文本再按「发到哪里」细分,不是换语气,是按发布目的决定改法:
| 子场景 | 目标 | 容易修掉的问题 |
|---|---|---|
| README | 第一屏说清“这是什么、给谁用、解决什么问题” | 标语堆叠、价值宣言、功能列表没重点 |
| release note | 列清变更、验证、限制和迁移影响 | 发版感言、过度庆祝、没说清测试 |
| forum post | 像维护者分享真实观察和取舍 | 公司公告腔、营销腔、空泛号召 |
| issue reply | 先确认问题、影响范围和下一步 | 客服式安抚、过度承诺、绕开复现条件 |
长文按默认动作改写,删句、并句会叠加,1800 字可能被压到 1000 字;反过来一句不删,整句的空话又留在文里。所以长文把「删到什么程度」单独分成三档,和力度档位正交:
| scope | 删整句吗 | 适用 |
|---|---|---|
structural |
自由删并重排 | 短文、明确要重写 |
bounded(长文默认) |
整句空话列成「建议删除(待确认)」清单,删多少你拍板 | public-writing 长文 |
in-place |
一句都不删,只句内降调 | 明确要求「完全原样」 |
长文按默认 structural 动作改写时,删句、并句、重排段落容易叠加,一篇 1800 字的稿子可能被压到 1000 字(见 #4)。但反过来只做句内改写(in-place),整句级的空话(无源引用、价值拔高收尾)又删不掉、去味偏弱——v1.8.6 用真实模型实跑验证了这一点:两个模型在 in-place 下都把无源引用和拔高收尾整句留了下来。
bounded 的取舍:句内洗实句直接改、承担节奏的重复不动;整句都是空话的(剥掉引导词就什么都不剩)进「建议删除(待确认)」清单,删多少由用户拍板。这样既不像 structural 那样不可控地缩水,也不像 in-place 那样把整句空话留在文里。
这些内容默认优先保护:
| 类型 | 例子 |
|---|---|
| 数字和版本 | 日期、区间、单位、指标、版本号 |
| 代码上下文 | 命令、路径、参数、字段、配置项 |
| 事实归属 | 人名、组织名、责任主体、时间线 |
| 引用和证据 | 引号内原文、报错、状态码、实验结果 |
清理不是只删词。它也会把文本往这些方向拉:
规则层覆盖 210+ 中文短语、96 条英文短语、19 类结构反模式。
当前评测集共 73 条:
| 类型 | 数量 | 目标 |
|---|---|---|
| SF | 41 | 应该改的文本必须命中并改掉主要问题 |
| SNF | 32 | 不该误杀的文本必须放行或轻提示 |
| Real Samples | 19 | 整段样本按自然、保真、可直接发三项评分,长文加 长度节奏 |
| Scene Packs | 8 | README / release note / forum post / issue reply 的正反样本 |
| Long-form In-place | 4 | 长文保长度场景,检查字数留存、句数对齐和关键转场 |
| Bounded | 3 | 长文整句空话进删除清单,但不误删实句和节奏句 |
v1.9.0 起 benchmark 改为双模型实跑口径(Codex + Claude 交叉判分,见 evals/results-v1.9.0.md);静态走查退为发版前快速自查。完整用例集见 evals/benchmark.md,整段真实样本见 evals/real-samples.md。results-v1.8.6.md 保留为 v1.8.6 首次模型实跑归档。
| 平台 | 文档 |
|---|---|
| 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 |
核心只需要 SKILL.md 一个文件(lite);长期项目、公开文本和需要误杀防护的场景,建议带上 references/ 完整包(full)。
项目内长期使用时,可以在 AGENTS.md 加一段触发规则:
## 写作风格
当任务涉及“去 AI 味”“说人话”“自然一点”“别像模板”这类改写时,遵循 `shuorenhua/SKILL.md`。
对外文本优先按它处理;代码、日志、配置和命令输出不套这个 skill。
不是。目标是减少模板感、表演感和语域漂移,让文本更自然、更可发布,不是绕过检测。
可以,但这是一个中文优先项目。英文支持主要用于清理常见英文套话和中英混写里的模板感。
“去掉明显套路”不等于“拥有具体作者的个人表达”。当前版本更擅长清理模板感和表演感,还不负责拟合某个具体人的长期写作习惯。
正常不会按聊天口吻去改技术文档。docs、status、code-context 都有更保守的保护策略,命令、路径、版本、报错和指标优先保真。
欢迎提交新的评测样本、边界案例、真实问题案例、改写前后样本和误杀防护。
如果你遇到“改完还是像 AI”的具体文本,可以用 bad case 模板 提交。请先脱敏,不要贴未授权私聊全文、密钥、内部链接或真实个人身份信息。也可以直接贴到征集 issue。
在提交新词之前,先想一件事:
这是一个“新模式”,还是只是“现有模式的变体”?
详细规则见 CONTRIBUTING.md。