No AI Slop：有证据的编辑、打包与效果评估
No AI Slop 是什么：有证据的写作模式检查，而非作者身份鉴定
理解这个技能包修改什么、检测报告应包含什么，以及为什么两种模式都不能证明一篇文章出自人类或模型。
你将学会
- 项目实际提供了什么
- 编辑和检测交付不同结果
- 什么时候有用，什么时候需要克制
开始前需要
- 一份事实可以核对的原稿
- 理解助手指令与插件安装范围
检查模式证据、保护原意，并区分包验证与未测量的编辑效果。
先看结论
- 交付物是给现有助手使用的指令包。
- 检测应引用模式证据，不推测作者身份。
- 打包验证不能证明编辑效果。
项目实际提供了什么
No AI Slop 把编辑规则打包给现有助手使用。核心 SKILL.md 要求以必要的最小修改保留原意、独特用词、节奏和真实的不确定性，仓库另外提供自检清单与 Python 打包脚本。本文检查提交 000650b，插件清单中的版本为 1.0.6，包内没有另外训练或分发一个语言模型。
例如一份更新说明声称某次改动体现了创新承诺，却没有解释读者现在能做什么。技能会针对这种空泛评论，要求改成原稿已经支持的具体后果；如果材料没有给出效果或性能数字，就不能为了让句子显得具体而制造一项客户收益。
编辑和检测交付不同结果
编辑模式输出完整修改稿和简短的修改说明；检测模式则标注模式名称、引用相关原句并给出短建议，不改写全文，也不打作者身份分数。人类和模型都可能写出某种套路，因此引用的原句只能作为读者能够复核的编辑证据，不能充当判断生成来源的鉴定结果。
README 还给出夸张讽刺的示例提示，但这不等于仓库实现了第三种生产分析引擎，核心规则仍然定义编辑与检测两条流程。团队评估应使用事实已知的普通稿件，而不是专门塞入所有违禁表达的搞笑例子，否则难以判断实际审稿场景中的价值。
什么时候有用，什么时候需要克制
当助手经常抹平作者个性，或者保留大量可以放到任何产品上的空话时，这套规则值得试用。精确引文、技术术语和刻意重复的文学表达，不适合直接通过一个不加判断的过滤器。规则中包含很强的风格偏好，具体一句话是否该改，仍取决于读者、体裁和上下文。
本系列把指令效果与打包行为分开。我们用合成文件执行了固定版本 Python 校验函数的七个隔离案例，发现 Windows 路径分隔符会影响包校验。这些结果不能证明模型保留幽默、改善阅读或识别所有模式，本次没有运行真实模型写作评测。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
选择事实可以核对的一份原稿。
- 2
明确要检测结果还是完整改稿。
- 3
标出必须保留的个性与原文。
可复制示例
{
"project": "petergyang/no-ai-slop",
"manifestVersion": "1.0.6",
"mode": "detect",
"authorshipInferenceAllowed": false,
"modelEvaluationExecuted": false
}常见问题
能证明文章是 AI 写的吗？
不能。检测规则明确禁止猜测 AI 作者身份。
包校验成功意味着写作规则有效吗？
不意味着。文件和清单检查不测量模型回答质量。
资料来源
- No AI Slop / README.md来源核查 2026-09-14
- No AI Slop / skills/no-ai-slop/SKILL.md来源核查 2026-09-14
- No AI Slop / .codex-plugin/plugin.json来源核查 2026-09-14