待验证｜kill-ai-slop 跟进：Skill 补齐安装与规范
待验证：当天增量是安装与规范适配，实际内容质检效果仍无第三方验证。
本文要点
- 从让模型直接改稿，转向先保护事实再执行风格处理。
- 从抽象的去 AI 味要求，转向规则目录和不可误杀样本。
- 从一次性提示词，转向可安装 Skill 和复核步骤。
阅读辅助
先看数字、证据和来源，再读正文。
kill-ai-slop 把视觉与文案痕迹目录接入了 Agent Skill。
2026-03-22 · shuorenhua 创建，为中文去 AI 味规则和评测提供更早背景。
这是一条跨日跟进，不是 kill-ai-slop 的第二次发布。7 月 12 日早报已经报道该项目；目标窗口内可核验的新增，是仓库补充安装入口，并在北京时间 7 月 13 日 05:15 把 Skill description 从 1352 字符裁到 1024 字符规范上限。speak-human-tw 只作为较早的规则与测试对照。
能确认的是项目公开材料。kill-ai-slop 的 README 整理了 32 项常见视觉与文案痕迹，并提供面向项目扫描和修复的 Skill。speak-human-tw 面向繁体中文写作，自述检查 35+ 种痕迹，并给出 40 条自带评测样本。
不能确认的是效果。两者都没有公开第三方误报率、漏报率、人工一致性或真实团队采用数据。GitHub 星标只能说明有人关注，不能证明它们能把初稿稳定改成可发布内容。
对读者最实用的启发不是立刻安装某个 Skill，而是采用它们的流程顺序：先锁住不可改事实，再标记风格问题，再由人确认修改，最后复核有没有信息漂移。
两个项目解决的是同一道后处理问题
kill-ai-slop 的对象包括页面视觉与文案。README 列举渐变、发光卡片、emoji 堆叠、全大写数据卡等常见机器默认模式，并把目录接到 Agent Skill。扫描器可以输出机器可读报告，再由 Agent 或人工决定是否修改。
这里的关键信息不是 32 项这个数字有多大，而是审美判断开始被写成可定位的问题。过去设计师可能只说“这个页面很像 AI 做的”；规则目录则要求指出具体元素、解释风险，并给出候选修复。它让意见更可讨论，也可能把主观偏好误写成硬规则。
speak-human-tw 的对象更窄，集中在繁体中文。README 强调它做的是校对而非创作：先保护价格、专有名词、引用、优惠和承诺，再处理空话、公式句、标点、地域用语和模板结尾。这个顺序比“请写得像人一点”更安全，因为风格改写最危险的失败不是不自然，而是改丢事实。
项目自带的 40 条评测分为两组：26 条应修改样本和 14 条不可误杀样本。前者检查规则是否命中，后者检查模型是否保留正确内容。它至少说明作者意识到“改得多”不是唯一目标，但样本量仍不足以证明对长文、品牌文案或客服内容有效。
| 项目 | 处理对象 | 流程资产 | 可确认部分 | 仍缺证据 |
|---|---|---|---|---|
| kill-ai-slop | 页面视觉与文案痕迹 | 32 项目录、扫描器、Agent Skill | README 与 Skill 目录可查 | 误报率、修复质量、真实项目对照 |
| speak-human-tw | 繁中语域、标点与模板句 | 35+ 种规则、保护清单、40 条样本 | 流程和样本划分可查 | 第三方复测、长文效果、跨模型一致性 |
| shuorenhua | 中文去 AI 味规则 | 更早的规则与评测背景 | 说明这类做法并非首次出现 | 不作为本期新增事件 |
为什么它们是内容后处理而不是生成新闻
两者都不提供新的基础模型，也没有宣布新的生成能力。它们处理的是模型已经写出页面或文字之后，如何发现问题、保护事实和批准修改。因此更准确的分类是内容后处理工具，而不是“AI 生成又进步了”。
这个分类会影响读者预期。生成工具的核心问题是能不能产出；后处理工具的核心问题是能不能发现风险、少误杀、保留作者意图，并留下可审阅的修改记录。如果只展示改完后的漂亮案例，不展示被误判和被改坏的样本，就无法判断工具是否可靠。
对团队来说，理想流程也不是让第二个 Agent 自动覆盖第一个 Agent 的输出。更稳妥的做法是：扫描器只报告风险；规则给出修改理由；涉及事实、品牌和承诺的改动必须由人确认；修改后再比较差异和关键字段。自动化负责缩小检查范围，人负责最终取舍。
新闻标准下的证据边界
本页保持 low confidence，原因有三层。第一，核心来源都是项目方自己的 GitHub 和 README。第二，数字描述的是目录和自带样本规模，不是独立效果指标。第三，kill-ai-slop 已在前一日报道，本期不能用星标继续增长制造“新发布”的错觉。
因此，这页可以支持的结论只有两个：kill-ai-slop 在目标窗口内继续完善可安装性和规范兼容；有开发者正在把内容后处理包装成 Skill，并加入保护清单和测试样本。它不能支持“去 AI 味工具已经有效”“团队正在大规模采用”或“AI 内容质量问题已经解决”。
这条边界也解释了为什么本页不再混入拉片、录屏证据或 Agent 自验证项目。那些工具可能同样涉及质量，但处理对象、用户和验收标准不同。把所有“验证”项目塞进一条趋势，会让共同点看起来比实际更强。
一次可信的后处理评测应包含什么
首先要把“发现问题”和“修好问题”分开。扫描器命中某种渐变、句式或标点，只能证明规则触发，不能证明原内容有错。第二阶段才应由编辑判断问题是否成立，再比较候选修改是否更清楚、更准确。把命中率直接写成质量提升，会混淆检测与编辑两个任务。
其次要保留不可修改项。价格、日期、专有名词、引用、优惠条件和法律承诺，应该在改写前被抽取成保护清单。评测不能只看文字是否更自然，还要检查这些字段是否逐项保持一致。speak-human-tw 把不可误杀样本单列出来，方向正确，但 14 条样本还不足以覆盖真实发布风险。
第三要加入多种内容场景。产品首页、技术文档、客服回复和个人文章对语气的要求不同。同一句强调语在营销文案里可能合理，在故障公告里可能显得夸张。可信评测应按场景报告结果，不能用一套风格偏好替所有读者做决定。
第四要比较不同模型和不同操作者。同一份 Skill 在 Claude Code、Codex 或 Cursor 中执行，可能因底层模型、上下文和工具权限不同而产生不同结果。人工编辑之间也会对“AI 味”有分歧。公开一致率和分歧样本，比只公布几个成功改写更能说明工具边界。
第五要追踪修改成本。若扫描报告产生大量误报，编辑逐条确认的时间可能高于直接审稿；若自动修复范围过大，回滚和复核成本也会上升。团队真正需要的指标不是“发现了多少痕迹”，而是减少了多少审稿时间、保留了多少事实、产生了多少需要撤回的修改。
最后要让读者看到证据。项目可以公布匿名化的原文、规则命中、候选修改、人工结论和最终版本，形成可复查样本。没有这种证据链，32 项目录和 40 条评测仍只是项目规模描述，而不是效果证明。
按这套标准看，两个项目已经提供了可讨论的流程资产，但都还没完成可信效果验证。这也是本页保留“待验证”和低置信标记的原因。
早报判断是，内容后处理会成为 Agent 工作流的固定一层，但“去 AI 味”不是充分的质量标准。好内容首先要事实准确、结构清楚、语气适合读者；是否含有某种模板痕迹只是其中一项。
kill-ai-slop 和 speak-human-tw 的积极意义，是把模糊的不满拆成可检查步骤。尤其是先保护事实、再处理风格的顺序，值得内容团队直接借鉴。
反面风险是规则本身会模板化。把 emoji、破折号或某种句式一律判错，可能抹掉作者风格，也可能让模型学会另一套“看起来不像 AI”的固定套路。工具应提供风险提示和证据，而不是垄断审美判断。
在出现第三方复测前，这仍是低置信社区信号。32 项目录和 40 条样本说明项目做了结构化工作，不说明它们已经达到编辑部可托管发布的可靠性。
接下来看什么
第一，看评测是否公开扩展。最有价值的不是增加更多禁用词，而是公布误报、漏报、人工分歧和不同模型执行同一 Skill 的差异。
第二，看真实内容。长篇报道、商业文案、客服回复和产品页面的风险不同；只有跨场景结果，才能判断规则是通用能力还是演示样本。
第三，看接入位置。如果工具只能靠用户临时说“帮我去 AI 味”，采用价值有限。进入发布前审校、内容工作台或 PR review，才说明它成为了流程基础设施。
第四，看人工控制。成熟的后处理工具应显示改动理由、保护字段和差异，让编辑能逐项接受或拒绝，而不是自动把一套审美覆盖到所有内容上。