- anti-slop 要求小幅修改，保护事实、引用、技术主张和段落结构。
- slopbeth 将数字、来源、条件与不确定性列为保护对象，提供改写检查脚本。
- no-ai-slop 提供编辑与检测两种模式，使用句子可迁移性检查识别空泛表述。
- humanizer、deslop 与 soundshuman 从结构、措辞和排版等角度检查模板化表达。
- lieflat-less-ai-tone 面向中文，采用限定范围的改写规则，并公开语料研究的方法与局限。
去 AI 味 Skill 怎么选：看编辑范围和事实保护
这些项目把写作要求组织成 skill.md，部分附有参考文件或检查脚本。使用时，模型依据规则处理原稿。挑选的重点包括修改范围、作者口吻的保留方式，以及事实发生变化时的处理要求。面对一篇有材料、有判断的成稿，保留作者意图应成为小幅润色的前提。
下面按任务匹配项目。表中的推荐反映规则设计与场景的匹配关系；不同模型、原稿质量和提示要求下的输出效果，需要通过自己的文章检验。各项目的规则依据见后文仓库链接。
anti-slop：适合保留作者口吻的成稿精修
elithrar 的 anti-slop 把编辑权限写得清楚：修改填充语和公式化表达，保护事实、引用、技术主张、段落结构与作者论点。大范围重写以用户要求为前提。它要求阅读整篇文章，理解作者声音，保留有意使用的短句、排比、幽默和有效对比。
这套边界适合个人博客、观点文章和经过打磨的产品介绍。比如，作者用一组对比解释选择理由，编辑需要判断两边的信息价值。删除对比中的一半，存在削弱论证的风险。anti-slop 允许保留有意表达，并要求在存疑处说明取舍，这给作者留下了判断空间。
slopbeth：适合数字与限制条件密集的文章
slopbeth 的编辑流程从事实保护开始，覆盖实体、数字、日期、链接、引用、技术主张和不确定性。对于缺少材料的文案，它要求指出证据缺口，避免把抽象收益改成凭空出现的产品能力、客户案例或效果指标。财务分析、技术说明和项目复盘，可以参考这套保护机制。
它提供的检查工具适合作为辅助。其中，preservation_check.py 比较数字、链接等字符串的增减，检查范围与完整语义存在差距。数字对应的对象发生交换、预测变成事实，这些变化需要人工核对。中文稿件使用前，需要评估其英文导向的匹配规则，避免将字符串检查通过视为语义验收。
no-ai-slop：适合找出缺少内容的句子
Peter Yang 的 no-ai-slop 区分编辑和检测：前者交付改稿，后者标出问题句与修改建议。它强调最小有效修改，并提出句子可迁移性检查：更换人物、公司或产品后，句子能否套入另一篇文章？这为检查产品介绍中的泛泛赞美提供了入口。
例如，“这款产品为团队协作带来了新的可能性”缺少功能与机制，产品名成了一个供替换的位置。此时应补查原材料，寻找产品改变的具体步骤。操作提醒、定义和必要过渡具有跨文章复用的价值，这项测试适合作为复核信号。禁词清单应让位于术语精度与作者原意。
humanizer：适合检查结构和模板化表达
blader 的 humanizer 将问题拆成结构铺垫、节奏模板、夸大表述、格式习惯和聊天残留等类型。当前规则要求保留有信息的对比和三项列举，并允许作者样稿覆盖默认风格。对于充满重复总结、戏剧性短句和模板段落的初稿，这种分类有助于定位编辑工作。
使用前需要约定结构权限。它允许合并、拆分段落和调整结构，编辑范围大于局部换词。原稿存在明确的论证顺序，或作者希望保留叙事节奏时，可以要求输出问题标注，确认后进入改写。这样能够区分“这个段落需要重组”和“这句话需要删掉铺垫”。
deslop：适合科技写作，但需要保留专业表达
Stephen Turner 的 deslop 关注科学写作、研究报告和科技文章。它区分专业术语与浮夸行话：具有精确含义的领域术语应得到保留，承担装饰作用的商业词汇需要检查。对技术作者而言，这个区分关系到文章能否在可读性与专业精度之间取得平衡。
它的部分规则偏硬，包括删除破折号、调整三项列举、把被动句改成主动句。科学写作中的被动表达具有安排句子焦点的作用，列举数量应由材料决定。建议借鉴术语审查与具体表达要求，对句式禁令设置体裁例外，避免把研究报告处理成口语博客。
soundshuman：适合用作者样稿校准风格
aashaexo 的 soundshuman 提供名为 humanize 的 Skill，整合 41 类写作模式，并加入作者声音校准。提供写作样本后，模型需要参考句长、用词、标点和过渡习惯；样本优先于默认风格规则。这种设计适合希望保留个人表达习惯的博客作者。
需要关注的是规则与示例的一致性。它声明禁止编造事实，但一个画廊改写示例新增了房间数量。作者使用这类 Skill 时，应核对示例是否带入来源之外的信息，并禁止模型为增加具体感补写场景。观点文章需要保留原有态度，避免编辑者替作者增加立场。
lieflat-less-ai-tone：面向中文成稿的局部清理
lieflat-less-ai-tone 从中文语料对照中提取编辑线索。作者报告的研究规模为 629 篇、约 283 万汉字，检查 26 项候选特征，筛出 11 项。仓库说明，原始语料受版权与隐私约束，公开范围限于方法与脚本；话题配对存在局限。这些数据属于作者报告，第三方复核存在条件限制。
它的改写范围有明确限制，保护文章框架、原有事实和判断强度，适合中文成稿的句子级清理。使用时应检查否定关系与列举项目：把“采集、存储、展示”缩成“从采集到展示”，会失去对存储环节的明确表述。对这类信息损失，应保留原句。语料差异能帮助发现问题，成稿质量需要逐句验证。
如何开始使用：用同一篇稿件比较两种方案
开始测试时，选择一个符合场景的项目，阅读 skill.md 及其引用的参考文件，通过所用工具的技能加载方式调用。对于支持自定义指令的工具，lieflat-less-ai-tone 文档给出了把规则作为指令使用的方案。附带脚本的检查功能需要对应运行环境；粘贴规则文本与执行脚本属于不同操作。
输入材料包含原稿、目标读者、发布渠道和允许的编辑范围。个人风格要求可以附一篇自己的文章作为参考。建议采用这样的任务说明：“请处理这篇文章中的空泛表述和重复内容，保留事实、数字、引文、技术条件、判断强度与作者立场。材料不足的地方请标注，新增事实需要来源。输出改稿，并说明影响含义的修改。”
比较两个 Skill 时，让它们处理同一份原稿，保持模型、材料和编辑要求一致。人工检查事实是否漂移、口吻是否保留、阅读是否顺畅，并记录需要返工的地方。多套规则叠加使用会增加归因困难；原稿与各自输出的对照，是判断规则适配性的依据。选择标准应落在成稿质量与返工成本上。
相关链接：
AI 速览
