我用 shuorenhua 改了一遍自己的稿子

我写公众号时，最怕的不是错别字。

错别字好办，扫一遍就行。

更麻烦的是那种“每句话都像对的，但整篇都不像人写的”。

开头先铺一段大背景。

正文里动不动“核心价值”“关键路径”。

讲完一节，又补一句“这也说明了什么”。

结尾再拔高一下，好像不升华就不完整。

很多人说的 AI 味，大概就是这种感觉。

它不一定错，但很容易空。看起来有礼貌、有结构、有总结，离具体的人和事却很远。

shuorenhua 这个 Skill，就是专门处理这类中文 AI 味的。

它不负责把文章改得更华丽，也不靠替换几个“敏感词”。它会先看哪些事实、术语、文件名、引用不能动，再处理空背景、假总结、工程师腔、翻译腔和表演式过渡。

我前面写过一版介绍 shuorenhua 的文章。

写完以后，我自己读了一遍，发现问题挺典型：道理都在，结构也完整，但有些地方还是像“介绍一个工具”，不像我在讲一次真实改稿。

所以这篇干脆拿我自己的稿子开刀。

你会看到它到底改了什么，哪些地方该动，哪些地方不能乱动。

这比单纯说“去 AI 味”更实在。

1. 它先保信息，再改语气

shuorenhua 处理的是中文文本里的模板感、表演感和语域漂移。

它的仓库在这里：

https://github.com/MrGeDiao/shuorenhua

仓库里有一句话，正好能概括它：

先保信息，再谈风格。

这句话不是口号。

很多去 AI 味工具一上来就猛改。改完以后句子顺了，事实也跟着漂了。版本号没了，文件名被改了，责任主体换了，原来的判断也被写成另一种判断。

这不叫润色。

这叫把稿子洗坏了。

所以它解决的不是“怎么把句子写漂亮”。

它解决的是：怎么把一段看起来完整、读起来却很空的中文，拉回具体的人、具体的事和具体的判断。

2. 先看我这篇文章的改稿 diff

我把上一版草稿保存了下来，然后用 shuorenhua 的思路改了一遍。

下面不是完整 diff，只截几处有代表性的改动。

- 中文去 AI 味，先看这个 Skill：shuorenhua
+ 我用 shuorenhua 改了一遍自己的稿子

标题先变了。

原来的标题像工具推荐。新的标题先交代一个动作：我真的用它改了自己的稿子。

读者更容易知道这篇会讲什么。

- 所以我更愿意把 `shuorenhua` 当成一个中文审稿 Skill 来看。
- 它会提醒你哪些词像 AI，也会先判断这段文字是什么场景，再决定该怎么改。
+ `shuorenhua` 下手稳。
+ 它先看哪些东西不能动，再去处理那些空背景、假总结、工程师腔、翻译腔和表演式过渡。

这里删掉了“我更愿意把它当成……”这种解释姿态。

直接说它做什么。

- 这一步很朴素，也很要命。中文写作最怕一把尺子量到底。
+ 这一步看起来普通，但管用。中文改稿最怕一把尺子量到底。

“很要命”有点用力。

改成“管用”，语气没那么悬。

- 你会很快看出来：这类 Skill 真正有用的地方，不在“把句子变漂亮”。
- 它会让你发现，哪些话其实可以不说。
+ 用完以后，你会更清楚地看到一件事：
+ 有些句子不是写得不够好。
+ 它们根本不用写。

这里保留原判断，但把句子拆开。

读起来更像人说话，也更有停顿。

这个 diff 能说明 shuorenhua 的作用：它不会把文章改得更华丽，它会把姿态层压下去。

3. 怎么使用

安装很简单。

把这个 GitHub 地址给 AI：

https://github.com/MrGeDiao/shuorenhua

然后说：

帮我安装这个仓库里的 shuorenhua Skill。

装好以后，可以这样用：

请用 shuorenhua 检查下面这段公众号草稿。

要求：
1. 先标出哪里有 AI 味。
2. 再给一个可直接发布的版本。
3. 不要改动事实、术语、命令、路径、版本号和引用。

[贴上你的草稿]

如果你只想先看问题，不想直接改，可以加一句：

只标问题，先不要改写。

我更建议先这样用。

先看诊断，再决定要不要改。这样不容易被 AI 一把改过头。

4. 它为什么比普通“去 AI 味”提示词稳

我看完源码后，觉得 shuorenhua 最值得学的地方有三个。

第一个，它按场景改。

同一句“帮我优化一下”，放在聊天、技术状态同步、文档和公众号里，改法不该一样。

聊天要短一点，别端着。

技术状态同步要保留时间线、动作、结果和风险。

文档要准确、可检索，不能为了自然把术语改乱。

公众号文章要压掉空背景和假升华，但也要保住作者自己的节奏。

shuorenhua 在 SKILL.md 里把场景分成四类：

• chat
• status
• docs
• public-writing

它还会识别更细的子场景，比如 README、release note、论坛帖、issue 回复。

这一步看起来普通，但管用。中文改稿最怕一把尺子量到底。

第二个，它先划保护区。

去 AI 味最容易误伤的，是事实，不是形容词。

比如这些东西默认不该乱改：

• 命令
• 路径
• 版本号
• 报错
• 接口名
• 字段名
• 引用原文
• 技术报告里的固定说法
• 谁做了什么、谁该负责

shuorenhua 会先看这些 protected spans，也就是先把不能乱动的地方圈出来。

这对技术文章特别有用。

公众号里讲 Skill，经常会写到仓库名、文件名、配置、命令和 API。AI 一热心，就喜欢把这些也顺手“润色”。润完可能更像中文，也更不像事实。

第三个，它把“改写力度”和“能不能删句”分开。

很多人让 AI 去味，会遇到两个结果：

一类是改得太轻，空话还在。

一类是改得太狠，一篇 2000 字的文章变成 900 字，节奏全没了。

shuorenhua 除了分轻度、中度、重度，还会看这次能不能删整句。

它有三种 scope：

• structural：可以删句、并句、调整结构。
• bounded：长文默认用，只把整句空话列成“建议删除”，等你确认。
• in-place：一句都不删，只在句子内部降调。

公众号长文很吃这个设计。

你写了 3000 字，不一定想让 AI 帮你砍成 1500 字。你可能只是想知道：哪些句子真是空的，删了不丢信息。

bounded 就是在做这件事。

5. 它实际是怎么实现的

这里先说清楚：shuorenhua 主要是一个规则和工作流型 Skill。

我没有看到它背后有专门改写中文的 CLI，也没有看到它用 Python 脚本处理文本。

它主要依赖这些文件：

• SKILL.md：主规则，定义什么时候用、按什么顺序改。
• references/protected-spans.md：哪些内容不能乱改。
• references/operation-manual.md：具体微操作，比如删套话、改主语、降调。
• references/structures.md：结构层面的 AI 味，比如空总结、二元对比、三段式。
• references/scene-packs.md：README、release note、论坛帖、issue 回复这些场景怎么处理。
• evals/benchmark.md 和 evals/real-samples.md：用例和真实样本，用来检查规则有没有跑偏。

所以它不是一个“神奇改写按钮”。

它更像一份很细的编辑流程。

拿这篇文章来说，它会先判断场景。

这是一篇公众号文章，主场景就是 public-writing。

然后它会圈出不能改的东西。

比如 shuorenhua、SKILL.md、protected-spans.md、GitHub 地址、安装提示词，这些不能随便改名。

接着看问题密度。

几个句子有套话，就轻改。整段都在摆姿态，就改重一点。

再看能不能删句。

这篇是长文，不适合让 AI 自己大删大改。更稳的做法是保留结构，把整句空话列出来，作者确认后再删。

最后回读。

事实有没有丢，术语有没有漂，语气有没有跑偏，保护区有没有被误改，都要看一遍。

这个流程不玄。

好的 Skill 本来就不该玄。它要把原来靠经验拍脑袋的事，拆成可执行的步骤。

6. 如果你想写一个类似的 Skill

不要一上来写：

请让文字更自然。

这句话太空。

可以照 shuorenhua 学这几个结构。

先定义触发条件。

什么情况下用这个 Skill？用户说“去 AI 味”“说人话”“自然一点”“别像模板”时触发。用户要事实校对、逐字翻译、保留官方口吻时，别乱触发。

再定义场景。

同样是改写，聊天、文档、公开文章不是一回事。你至少要写清楚：这个 Skill 主要服务哪几类文本。

然后写保护区。

哪些东西一定不能改？技术文章里尤其要写清：命令、路径、版本号、报错、字段名、引用原文。

接着写工作流。

不要只给原则，要给顺序：

判场景
划保护区
判断问题密度
选择改写力度
选择能不能删句
执行改写
回读检查
输出结果

最后准备样本。

没有样本，Skill 很容易变成口号。你要给它一些“该改”的例子，也要给它一些“不该改”的例子。

后者更重要。

会改不难，不误伤才难。

7. 可以怎么改成自己的版本

如果你也写公众号，可以在 shuorenhua 的基础上加自己的风格约束。

比如我的公众号会加这些要求：

• 开头从具体卡点进，不从大背景进。
• 少用工整转折。
• 技术拆解要讲真实实现，不能编。
• 讲 Skill 安装时，先给仓库地址，再给 AI 安装提示词。
• 遇到不确定的实现，只说“这里我没看到”，不猜。

这样一来，shuorenhua 负责去掉通用 AI 味，你自己的规则负责保持栏目味道。

这两个最好分开写。

通用 Skill 管共性，个人指南管偏好。分开写，后面好维护。

8. 最后给一个可复制的动作

找一段你最近写的草稿，贴给 AI：

请用 shuorenhua 帮我审这段文字。

先判断它属于 chat、status、docs 还是 public-writing。
再标出最像 AI 的 5 处。
然后给一版改写。

注意：
不要改动事实、术语、链接、文件名、版本号和引用。
如果某一句只是空话，先列入建议删除，不要直接删。

[贴草稿]

用完以后，你会更清楚地看到一件事：

有些句子不是写得不够好。

它们根本不用写。