去 AI 味的 Skill，我拿自己的公众号稿子试了试

「文案里少点 AI 味，真诚就行。」

最近改自己的公众号稿子，这句话反复提过。标题换了，开头也改了，读起来还是会碰到一些很熟悉的句子。单句挑不出大毛病，放在一起，总像在哪里见过。

今天看到一个开源项目，叫 lieflat-less-ai-tone。名字有点长，做的事很具体，给成稿找出几类常见表达，只改命中的地方。

我把它的规则读完，又翻了自己的旧稿。最先动手改的，倒是那份指导 AI 写文章的规则。

里面一处要求「没有生活感就加一点」，另一处又要求不能编造经历。还有一条，直接把冒号禁掉了。

这几条放在一起，写稿的 AI 该怎么办？它没拿到真实经历，又被要求写得像个活人，很容易开始补反应、补感叹，或者把正常的说明句硬拧成聊天。

这次我把这些要求清掉了。也选了自己的两处文字，按这个项目的思路做了一次局部编辑。先看句子怎么变，再聊它能帮到哪一步。

有些话，直接说就够了

前几天那篇 Claude Code 工作流的稿子里，有一句是这样写的。

原句

「另一条是我在几个项目里都明确要求过的分工。那时的组合是 Fable 做规划、架构判断和最终检查，Opus 做具体实现、修复、跑命令。」

这段信息没有问题，但「另一条是……的分工」读起来绕了一下。现在我会这样写。

改后

「我在几个项目里都要求过这样的分工。Fable 负责规划，也做架构判断和最终检查；具体实现交给 Opus，由它修复问题、跑命令。」

项目里怎么分工，还是那件事。没有加一次熬夜，也没有补一句「我当场愣住了」。只是把做事的人和动作往前放了放。

这处改写参考了项目对迂回表达和密集并列的处理思路，是编辑示范，不代表某个模型一键运行必然得到同样的句子。

还有一句来自之前写 AI 产品成本的稿子。

原句

「一份漂亮答案和一件正确交付的工作，中间不是多一个按钮，而是多了一整段工程。」

改后

「从一份漂亮答案到一件正确交付的工作，还需要一整段工程。」

原句里的「多一个按钮」，并没有对应到前文某个具体误解。删掉它，文章要说的判断仍然在，读者也少绕了一步。

项目把这类表达叫「翻案腔」，先立起一个误解，再把它推翻。这个名字挺准，但也要看上下文。文章如果真的在纠正前面已经讨论过的错误，就不能见到转折句式便删。

这两处只是单句编辑。我没有把整篇交给一个检测器，也没有测出「AI 味降低了多少」。读起来是不是更顺，还是得把改前改后放在一起看。

那个 283 万字，究竟是什么

仓库介绍写着「基于 283 万字语料统计」。读到这里，先别把它理解成已经替我们验证好了改稿效果。

按作者公开的说明，研究比较了 629 篇文本，其中 300 篇由五个模型生成，另外 329 篇来自人类作者。作者检查了 26 项候选特征，报告其中 11 项有区分度。

这些是项目自报的研究结果。原始语料因版权和隐私没有公开，我也就无法用同一批文章复算它的结论。仓库公开了测量脚本和处理方法，但这与公开完整数据仍有区别。

我更愿意把它当成一份有研究过程的编辑参考。里面有一部分内容，专门记录作者测错过什么、后来怎么改。

比如，文本切分没处理好，表格和长列表也可能被当成一句话。统计出来的句长，看上去就会出现很大的差异。作者修正切分后，原来的判断也变了。

这提醒了我，检查句子时要回到具体文字。一个标记被命中了，最多说明这里值得再读一遍。

项目也明确保留了不少正常写法。问句可以留，比喻可以留，句子有长有短并不天然代表哪一种来源。目标作者本来就这么写，也应当优先尊重作者习惯。方法和限制都能在仓库的 研究说明 里找到。

所以，我不会拿它给一段话盖「人写」或「AI 写」的章。能帮我发现一句绕口的话，已经有用。

安装以后，先拿一小段试

项目提供的安装方式是下面这条。在支持的技能安装环境里运行，按提示选择要安装到的工具。

npx skills add larashero3-dotcom/lieflat-less-ai-tone

也可以先打开仓库里的 SKILL.md，读读它到底准备改哪些东西。这里的 Skill，是交给 AI 执行的一份规则，不是安装后就有确定效果的文字滤镜。

第一次用，我建议拿一段你熟悉的文字。你知道它原本要表达什么，才看得出改稿有没有偷换意思。

请求可以写得具体一点。

请用 lieflat-less-ai-tone 检查下面的成稿。
先读我提供的风格说明，只改明确命中规则的地方。

保留原来的事实、限定词、引文和链接。
不要添加经历、数字或情绪，不调整文章结构。
未命中的句子原样保留。

这次请额外列出修改对照，
说明原句、改句以及对应的规则。
最后给出修改后的全文。

我特意多要了一份修改对照。项目默认可以直接返回全文，但自己审核时，有对照省得来回找。

尤其要留意那些不起眼的词。「可能改善」被改成「改善」，语气就变重了；一个案例的条件被删掉，结论适用的范围也变了。句子顺了，意思却错了，这种改法不能收。

只挑最有把握的改动留下也行。原文没有命中问题，就让它待在那里，不必为了证明工具有用而改满一页。

我们自己的写法，也得改

回到这份公众号写作规则，我这次主要清理了几处冲突。

「没有生活感就加一点」删掉了。真实生活细节当然能写，但得是自己提供过的。没有素材，就把眼前的事情讲清楚，不拿口头禅来补。

标点也不再一刀切。需要解释时可以用冒号，引用别人时保留原话。真正要检查的，是那半句提示语有没有信息，或者是不是每段都要摆出一次郑重宣布的姿态。

以后成稿多做一道局部检查，先指出哪句话有问题，再写改句和理由。不能只留一句「AI 味太重，请重写」，然后让整篇文章换一套形容词。

手机上怎么分段，仍然单独处理。长段读着累，可以在意思转折处断开；这属于阅读排版，不拿它证明文章更像人写。专业说明需要完整条件时，也别为了短而拆碎。

这个 Skill 的思路可以借，但我没把整套外部规则不加判断地塞进来。有些改法也需要再审。例如并列项目被概括以后，原来的信息有没有丢；一个长句被拆开，因果关系还清不清楚。

对我们自己的稿子，最有用的做法是保留初稿，看见每一处修改。该保留的事实和判断留下来，没必要的铺垫删掉。至于文章有没有东西可说，还得靠素材。

如果你也拿它改稿，可以从最不满意的一段开始。最后留下了哪处修改，又撤回了哪处，比一个「去 AI 味成功」的评分更值得聊。