1. 为什么“去 AI 味”值得单独做成一个 skill先说结论把“去 AI 味”做成一个可复用的 skill比每次手动改稿靠谱得多。原因很简单——人写东西时判断标准是飘的今天觉得“这段挺自然”明天再看又觉得“怎么这么像机器写的”。而 skill 的价值就在于把这种模糊的直觉固化成一套每次都能跑一遍的检查规则。我最初动这个念头是因为帮朋友改一份产品说明。原文里有一句“本方案通过优化链路结构为用户提供高效稳定的使用体验”。这句话单看没毛病语法通顺、用词专业但读起来就是一股子模板味。我把它改成“这套方案把中间环节砍掉了用起来快也不容易断”朋友看完说“对这才像人话”。问题在于这种修改我每次都要重新想一遍效率极低而且不同稿子改出来的风格还不统一。后来我意识到所谓“AI 味”其实不是某一个词的问题而是一组可识别的模式过度使用“通过……可以……”“随着……的发展”“为……提供支持/保障”、滥用“总之/综上所述”、喜欢用被动语态、爱堆四字词、段落长度高度均匀、每段都以总结句收尾。这些模式一旦被列出来就完全可以写成规则交给 skill 去逐条检查。这里要区分两个概念skill 和 agent 的区别。agent 是能自主决策、调用工具、多轮执行的角色skill 更像是一份“操作手册 检查清单”它不负责决策只负责在你需要的时候把一套固定的流程和规则提供出来。所以“去 AI 味”这件事做成 skill 比做成 agent 更合适——它不需要自主判断该不该改只需要在改稿时把规则跑一遍。我用的环境是 Claude Code 配合 Codex 做辅助校验。Claude Code 负责按规则改写Codex 负责跑一遍反向检测看改写后的文本里还有没有残留的模板句式。这个组合的好处是改写和检测分离避免“自己改自己查”导致的盲区。如果你用的是其他 AI 编程工具思路是一样的一个负责生成一个负责校验规则文件独立存放。提示skill 的规则文件不要写得太抽象。像“语言要自然”这种描述AI 根本没法执行。必须写成“禁止出现‘通过……可以……’句式”“每段不超过 5 行”“禁止连续三段以总结句结尾”这种可判定的条件。2. 我实际在用的几条硬规则以及它们为什么有效2.1 禁用句式清单从“通过……可以……”开始我整理了一份禁用句式清单这是整个 skill 里最核心的部分。清单不是拍脑袋想的而是我把过去半年改过的几十篇稿子里出现频率最高的模板句式全部提取出来按出现次数排序得到的。排在前面的几条几乎每篇 AI 初稿都会中招。禁用句式出现频率替换思路通过……可以/能够……极高直接说“用……做……”或改成“你只要……就……”随着……的发展极高删掉直接说现在的情况为……提供支持/保障高改成“让……能……”或直接说结果综上所述/总之高删掉最后一段直接说结论不仅……而且……中拆成两句或只保留后半句在……的背景下中删掉直接进入正题具有……的意义/价值中改成“这件事有用在哪”这份清单的关键在于可判定。比如“通过……可以……”这条skill 执行时会用正则去匹配“通过”和“可以”在同一句里出现的情况命中就标记出来。这样就不会出现“AI 觉得这句话挺自然”的漏网之鱼。我试过把清单写得太宽泛比如“避免使用书面语”结果 AI 把“因此”改成了“所以”但“通过……可以……”还在。后来我把规则改成“逐条匹配具体词”命中率立刻上来了。这说明一件事去 AI 味的规则必须具体到词和句式不能停留在风格描述层面。2.2 段落节奏规则为什么每段不能一样长AI 写东西有个很明显的特征段落长度高度均匀。每段大概都是 3 到 4 句每句大概都是 20 到 30 字读起来像节拍器在打拍子。人写东西不是这样的——人会突然写一句很短的也会写一段很长的节奏是乱的。所以我在 skill 里加了一条规则相邻段落的字数差不能小于 30%。也就是说如果上一段是 100 字下一段要么少于 70 字要么多于 130 字。这条规则执行起来很简单skill 会统计每段字数然后检查相邻段落的差值比例。这条规则的效果非常明显。我拿一段 AI 初稿测试原文五段分别是 98、102、95、105、99 字改完之后变成 112、64、138、71、120 字。读起来立刻就不一样了因为节奏被打乱了眼睛不会觉得“怎么每段都一样”。注意这条规则不要用在技术文档的步骤说明里。步骤说明需要每步长度接近方便对照。它只适用于叙述性、观点性的段落。2.3 句首词多样性避免“我们”“这”“它”开头刷屏还有一个容易被忽略的点句首词重复。AI 特别喜欢用“我们”“这”“它”“该”开头连续好几句话都是同一个词起头。人写东西时句首词是随机的因为人的注意力在内容上不在句式上。skill 里对应的规则是连续三句话的句首词不能相同。执行时skill 会提取每句话的前两个字然后检查连续三句是否有重复。如果重复就把其中一句的句首词换掉或者调整语序。这条规则听起来很细但效果很好。我改过一段话原文是“我们可以通过调整参数来优化性能。我们可以用不同的配置来测试。我们可以观察结果的变化。”三句话全是“我们”开头。改完之后变成“调整参数能优化性能。换几组配置测一下结果会不一样。观察的时候重点看变化趋势。”读起来就自然多了。2.4 禁止“总结句收尾”让段落自然结束AI 还有一个习惯每段最后都要来一句总结。比如“由此可见XXX 非常重要”“总的来说XXX 是关键”。这种句子在正式报告里没问题但在日常分享里就显得很假。skill 里的规则是段落最后一句不能以“由此可见”“总的来说”“因此”“所以”开头。如果命中就把这句删掉或者把它改成具体的事实描述。我试过这条规则效果立竿见影。有一段原文结尾是“因此选择合适的工具非常重要。”删掉之后段落停在“工具选错了后面全是返工。”反而更有力。这说明一件事很多时候总结句是多余的删掉比改掉更好。3. 把规则写成 skill 文件的具体做法3.1 文件结构一个主文件加一个规则清单我的 skill 目录结构是这样的deai-skill/ SKILL.md rules/ banned-phrases.md rhythm-rules.md sentence-openers.md examples/ before.md after.mdSKILL.md是主文件写清楚这个 skill 是干什么的、什么时候用、怎么用。rules/下面放具体的规则清单每条规则单独一个文件方便增删改。examples/放改前改后的对照示例给 AI 做参考。这种结构的好处是规则和说明分离。改规则的时候只动rules/里的文件不用碰主文件。而且规则文件可以单独拿出来复用比如你写另一个 skill 时也可以把banned-phrases.md直接拷过去。3.2 规则文件的写法用“条件 动作”格式每条规则我都写成“条件 动作”的格式。比如## 规则禁用“通过……可以……” 条件同一句话中同时出现“通过”和“可以/能够” 动作将“通过 A 可以 B”改写为“用 A 做 B”或“A 能 B” 示例 - 原文通过调整参数可以提升性能。 - 改写调整参数能提升性能。这种格式的好处是可执行。AI 读到这条规则时知道什么时候触发、触发后做什么、做成什么样算合格。如果只写“避免使用模板句式”AI 就不知道具体该改哪个词。我试过把规则写成自然语言段落结果 AI 执行时经常漏掉。后来改成“条件 动作 示例”的三段式命中率明显提高。这说明规则文件要像代码一样写不能像散文一样写。3.3 在 Claude Code 里调用 skill 的方式在 Claude Code 里skill 的调用方式很简单。你只需要在对话里说“用 deai-skill 改一下这段”它就会自动加载SKILL.md和rules/下的规则文件然后按规则逐条检查。我通常的流程是把初稿贴进去说“用 deai-skill 跑一遍”Claude Code 输出改写后的版本并列出命中了哪些规则我把改写版贴到 Codex 里说“检查这段还有没有模板句式”Codex 返回检测结果如果有漏网的我再手动补一条规则这个流程跑熟之后一篇 2000 字的稿子大概 5 分钟就能改完而且风格统一。以前手动改同样的稿子要 20 分钟还经常改到一半就烦了后面越改越敷衍。提示如果你用的是 Codex 做检测建议把banned-phrases.md里的词条直接喂给它让它按同样的清单去匹配。这样改写和检测用的是同一套标准不会出现“改的时候按 A 标准查的时候按 B 标准”的混乱。4. 实测中遇到的几个坑和对应的修法4.1 规则太严导致“改过头”最开始我把规则设得很严结果 AI 改出来的东西变得很口语化甚至有点油。比如原文“该方案具有较高的可行性”被改成“这事儿能成”。虽然去掉了 AI 味但把专业感也去掉了。后来我加了一条保底规则改写后的文本不能出现“这事儿”“那玩意儿”“搞一下”这类过于随意的表达。也就是说去 AI 味的目标是“像人写的”不是“像聊天”。人写专业内容时也会用“可行性”“方案”这类词只是不会用“具有较高的可行性”这种绕弯子的说法。修法很简单在banned-phrases.md里加一个“反向禁用清单”列出过于口语化的词命中就替换回中性表达。这样就能在“去 AI 味”和“保持专业”之间找到平衡。4.2 不同文体需要不同规则我一开始想用一套规则打天下结果发现不行。技术文档、产品说明、个人分享这三种文体的“AI 味”表现不一样。技术文档的 AI 味是“通过……可以……”和“为……提供支持”个人分享的 AI 味是“总之”“由此可见”和每段总结句。后来我把规则分成三组通用规则所有文体都适用、技术文档规则、个人分享规则。调用时根据文体选择加载哪一组。这样就不会出现“用个人分享的规则去改技术文档改完变得太随意”的问题。文体重点禁用重点保留技术文档通过……可以、为……提供支持步骤编号、参数说明产品说明随着……的发展、在……背景下功能描述、使用场景个人分享总之、综上所述、每段总结句口语化表达、个人经验4.3 规则文件版本管理规则改多了之后会出现“改了一条规则结果另一篇稿子改出来不对劲”的情况。后来我给规则文件加了版本号每次改动都记一笔改坏了可以回滚。具体做法是在rules/目录下建一个CHANGELOG.md每次改规则时写清楚改了哪条、为什么改、影响范围是什么。这样过一个月再回头看就知道当时为什么把某条规则删掉了。这个习惯是从写代码那边搬过来的。规则文件本质上就是代码只不过执行者是 AI 而不是编译器。既然是代码就该有版本管理。5. 几条可以直接抄的规则原文下面这几条是我现在还在用的规则原文你可以直接拷到自己的 skill 里。每条都经过实测命中率和改写效果都比较稳。## 规则 1禁用“通过……可以……” 条件同一句话中同时出现“通过”和“可以/能够” 动作改写为“用 A 做 B”或“A 能 B” 示例 - 原文通过调整参数可以提升性能。 - 改写调整参数能提升性能。 ## 规则 2禁用“随着……的发展” 条件句首出现“随着”且句中出现“的发展” 动作删除“随着……的发展”部分直接说现在的情况 示例 - 原文随着技术的发展工具越来越多。 - 改写工具越来越多。 ## 规则 3段落长度差 条件相邻两段字数差小于 30% 动作将其中一段拆成两段或合并到相邻段 示例 - 原文两段都是 100 字。 - 改写一段 120 字一段 65 字。 ## 规则 4句首词重复 条件连续三句话的句首词相同 动作调整其中一句的语序或换一个起头词 示例 - 原文我们可以调整参数。我们可以测试配置。我们可以观察结果。 - 改写调整参数能优化性能。换几组配置测一下。观察的时候重点看变化。 ## 规则 5禁止总结句收尾 条件段落最后一句以“因此”“所以”“总的来说”“由此可见”开头 动作删除该句或改为具体事实描述 示例 - 原文因此选择合适的工具非常重要。 - 改写直接删除这几条规则加起来不到 500 字但覆盖了大部分常见的 AI 味来源。你可以先拿这五条跑一遍看看效果再根据自己的文体特点往里加。注意规则不是越多越好。我试过加到 20 条结果 AI 执行时经常顾此失彼改完一段又违反另一条。后来砍到 8 条左右效果反而更稳。建议先从 5 条核心规则开始跑顺了再逐步加。6. 这套 skill 还能怎么扩展我现在这套 skill 主要针对中文文本但思路可以扩展到其他场景。比如英文写作里的 AI 味也很明显常见的是“delve into”“it is important to note that”“in conclusion”。把这些词换成对应的英文清单规则逻辑完全不用改。另一个扩展方向是按平台适配。不同平台对“AI 味”的容忍度不一样。有的平台喜欢短句和口语化有的平台接受长句和专业术语。可以在 skill 里加一个“平台配置”文件调用时指定目标平台规则自动调整松紧度。还有一个我还没试但觉得可行的方向把规则做成可量化的评分。比如每命中一条规则扣 10 分满分 100 分改到 80 分以上才算合格。这样就不用靠感觉判断“改够了没有”直接看分数就行。不过这个需要先把规则权重调准不然会出现“扣分扣得莫名其妙”的情况。我个人在实际操作中的体会是去 AI 味这件事核心不在于“改得多好”而在于“改得一致”。手动改稿最大的问题是每次标准不一样今天严明天松。做成 skill 之后每次跑的都是同一套规则改出来的风格就统一了。至于规则本身完不完美反而不是最重要的——先跑起来再慢慢调。