No AI Slop：有证据的编辑、打包与效果评估
No AI Slop 架构：两条输出路径与一份编辑自检清单
跟踪原稿、模式选择和保留约束如何形成检测报告或改稿，并理解自然语言指令与强制执行机制的差别。
你将学会
- 助手负责执行，技能提供行为约定
- 检测应在进入改写路径前结束
- 自检同时检查意义与风格
开始前需要
- 一份事实可以核对的原稿
- 理解助手指令与插件安装范围
检查模式证据、保护原意，并区分包验证与未测量的编辑效果。
先看结论
- 助手解释指令，技能包没有确定性正文处理引擎。
- 检测路径应输出证据后停止，不擅自改写。
- 自检不等于独立评测或程序强制约束。
助手负责执行，技能提供行为约定
助手加载包内指令并接收用户原稿，SKILL.md 要求先理解原稿重点、目标读者和作者风格，缺少必要上下文时再请求补充。仓库没有一个独立的确定性解析器，能够把每句话机械地归入某种模式；判断仍由接收这些规则的模型完成。
清单说明插件如何展示、技能从哪里发现，却不执行正文转换。Python 构建器属于分发工具，运行它不能模拟助手对话。区分助手、规则和构建器，才能避免把打包成功误读成编辑工作流已经在真实环境中执行完成。
检测应在进入改写路径前结束
检测请求的预期结果是模式名称、原句和简短建议，流程到这里停止。编辑请求才进行最小修改，再按 eval.md 自检，返回完整修改稿和变更说明。两种模式不应混成一个未经要求就重写全文的输出，否则作者失去了决定是否接受修改的机会。
这些分支以自然语言表达，由模型解释，并不是能在运行时阻止作者概率分数或虚构数字的硬性程序。需要强约束的应用，应另外添加验证和人工审阅机制，不能仅因为规则写了禁止事项，就认为所有不合规回答都会被程序拦截。
自检同时检查意义与风格
eval.md 要求检查事实、个性和可辨认的节奏是否保留，同时处理具体套路；如果未通过，就修改后再次检查。这是模型对自身输出的检查循环，不是一套已经记录数据集、模型配置和实测成功率的独立评测系统，两种证据不能互相替代。
架构图因此把检测和改写分开，自检只放在改写分支上。人工验收仍在循环之外：模型说自己通过，不能证明某句引文保持准确，也不能证明作者认可声音。保留原稿和改稿，读者才能实际核对这些主张。
如何选择
| 比较维度 | 方案 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
核对该分支的输出约定。
- 4
保存原稿和改稿供人工比较。
可复制示例
{
"detect": {
"rewrite": false,
"authorshipScore": false,
"output": [
"pattern",
"quote",
"short fix"
]
},
"edit": {
"selfCheck": "eval.md",
"output": [
"full draft",
"change explanation"
]
},
"runtimeEnforcementProvided": false
}常见问题
eval.md 是可执行测试程序吗？
不是。它是一份要求助手逐项检查的自然语言清单。
插件会在运行时强制阻止违规答案吗？
已检查的文件没有建立独立的运行时强制拦截机制。
资料来源
- No AI Slop / skills/no-ai-slop/SKILL.md来源核查 2026-09-14
- No AI Slop / skills/no-ai-slop/eval.md来源核查 2026-09-14
- No AI Slop / .codex-plugin/plugin.json来源核查 2026-09-14
- No AI Slop / scripts/build_plugin.py来源核查 2026-09-14