WRITING.md：别为了去 AI 味，把文章改坏

我最近改公众号稿，有一个很明显的感受：去 AI 味不能只靠删词。

删掉几个连接词，少用一点破折号，把句子长短错开，再加几句口语，这些办法有时管用。

但用过头，文章会变成另一种怪样子：语法故意松，句子故意碎，观点像临时想到的。

看起来没那么像 AI，也没那么像好文章。

WRITING.md 最值得讲的地方，就在这里。

它没有把目标定成“骗过检测器”。

它的目标更朴素：让文字适合具体语境，少一点默认模型腔，多一点可验证的内容。

1. 先把来源说清楚

WRITING.md 的仓库在这里：

https://github.com/Anbeeld/WRITING.md

仓库里有几个版本：

WRITING.md
WRITING-compact.md
WRITING-mini.md
skills/writing/SKILL.md

完整规则在 WRITING.md。

压缩版可以放进 AGENTS.md 或 CLAUDE.md。

skills/writing/SKILL.md 是打包好的 Skill 版本，适合 Claude Code、Codex、Cursor、OpenCode 这类支持 Skills 的工具。

如果你想安装，可以把仓库地址给 AI：

https://github.com/Anbeeld/WRITING.md

然后说：

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

2. 它第一句话就把方向定住了

WRITING.md 的 Purpose 里有一句话，基本定了整套规则的方向：

写作要适合 medium、task 和 reader。

也就是先看：

这是发在哪的？
读者是谁？
这段文字要完成什么事？

这比“写得像人一点”更稳。

一封同事邮件、一篇公众号文章、一段产品文案、一份技术文档，不该用同一种语气。

有些场景就应该结构清楚。

有些场景就应该少用列表。

有些场景需要中立。

有些场景需要作者站出来。

WRITING.md 没有一把尺子量到底。它先让 AI 判断语境。

这正好能解释公众号 Skill 深拆的难处。

它不是官方文档，也不是朋友圈碎碎念。它要像经验分享，但源码和实现又不能讲错；它要让小白能看懂，又不能把技术细节说假。

语境先定准，后面规则才不会乱。

3. 它不鼓励假装成人

我最喜欢它的 Safety rails。

它明确说：

• 不要编错别字。
• 不要故意破坏语法。
• 不要硬塞俚语、脏话、假不确定。
• 不要为了“像人”制造凌乱。
• 不要用程序化的句长变化来伪装自然。

现在很多去 AI 味做法，其实是在给文章加噪音。

把句子弄得更乱，不等于更真实。

把结构拆掉，也不等于更像人。

WRITING.md 的判断更清楚：AI 味常常来自过强的规律性、语境错位和内容空泛，不是因为文字太干净。

所以它反对“假人味”。好文章不需要故意粗糙。

4. 它要求每段有具体锚点

WRITING.md 里有一条规则叫 concrete specificity。

意思是：重要段落里要有具体锚点。

什么算锚点？

比如这些：

• 具体名字
• 具体数字
• 直接引用
• 一个可检查的细节
• 一个真实决策或场景
• 一个读者能观察到的变化

什么不算？

比如：

很多
各种
有意义的变化
广泛影响
本质上
最终
通常模式

这条规则特别适合检查 AI 文章。

AI 很会写“正确但没有抓手”的句子。

比如：

这个 Skill 能显著提升写作效率。

听起来没错，但读者不知道它到底做了什么。

换成下面这样，动作就出来了：

它会先让 AI 判断文章发在哪、给谁看，再决定该用列表、段落还是更像聊天的写法。

公众号文章需要这种锚点。没有动作、文件、场景或前后变化，句子就容易飘。

5. 它提醒你：具体也要有证据

很多人知道“空话不好”，于是开始反向用力：加数字、加日期、加人名、加看起来很具体的细节。

这些东西如果没来源，就会变成“假具体”。

WRITING.md 专门提醒这一点。

它说，数字、日期、引用、因果判断、内部机制，都要谨慎。

不能为了避免空泛，就编一个看起来可信的细节。

这条规则和我们写 Skill 深拆很贴。

比如讲一个 Skill 的实现，不能因为文章需要生动，就编一个“它内部通过某某算法判断”的说法。

看了代码就说看了代码，没看到就说没看到，只能推测就明确说是推测。

宁可少讲，也不要讲假。这条对 Skill 深拆尤其要守住。

6. 它抓的是规律性

WRITING.md 对 AI 味的判断，不靠某一个词。

它更关注重复模式。

比如：

• 每段都是一个结论句开头。
• 每段都按同样的节奏展开。
• 每一节都用同样的转折。
• 连续出现三段式排比。
• 把相邻的想法拆成一行一句，制造假锋利。
• 每段最后都补一个总结句。

这些我在自己文章里也踩过。有时候单句没问题，问题是整篇太整齐。

读者读着读着，会感觉作者不在现场，只有一个模型在按模板推进。

这也是我们前面说过的：短句不是不能用，但连续短句堆叠，会变成另一种 AI 味。看着像有态度，其实只是把每个判断都单独摆了一行。

7. 它把长文结构也管起来

很多写作规则只管句子，WRITING.md 还管长文结构。

它提醒你，不要让文章变成 catalog prose 或 system-tour prose。

简单说，就是不要每段都像在介绍一个模块。

比如：

背景
机制
影响
总结

或者：

功能 A
功能 B
功能 C
我的判断

这种结构有时清楚，但也容易像说明书。

做 Skill 深拆时，我们也很容易这样写：先讲来源，再讲文件，再讲规则，再讲用法，最后来一段总结。

如果每篇都这么写，读者会很快疲劳。

所以要找一条主线。

比如这一篇的主线是：

不要为了去 AI 味，把文章改坏。

后面的规则都围着这句话展开。

8. 对写自己的公众号 Skill 有什么启发

如果我要把 WRITING.md 的思路迁移到公众号风格 Skill，我会让它先做四个判断。

第一，判断文章场景：这是 Skill 深拆、经验复盘、教程、工具推荐，还是系列总结。不同文章不能套同一个结构。

第二，保护事实：仓库地址、文件名、脚本行为、API 结果、发布状态，都不能为了顺口乱改。

第三，检查锚点：没有例子、动作、文件、对话、diff、截图位置的段落，要么补实，要么删掉。

第四，检查规律性：不要每节都写成“问题-解释-价值-总结”，也不要每段都用短句压判断。

最后才处理结尾。讲完就收，读者需要下一步动作，不需要一段宏大升华。

9. 我的判断

WRITING.md 不是检测器，也不承诺让文章骗过什么工具。

它更像一套写作护栏：先看语境，再保事实，再补具体锚点，再检查规律性，最后把那些为了“像人”而加进去的假动作删掉。

这套思路很适合我们后面继续写 Skill 系列。公众号稿要追求的东西很具体：有对象，有事实，有现场，也有自己的判断。表面上“不像 AI”，只是结果，不该是目标。