No AI Slop：有证据的编辑、打包与效果评估
读 No AI Slop 打包源码：七个文件、提示长度与路径分隔符
沿 validate_source 与 validate_build 分析实际检查，结合七个隔离案例，区分目录验证、字节一致与压缩包内容验证。
你将学会
- 源码检查覆盖字段存在性和部分边界
- 构建与校验面对的对象不同
- 原生 Windows 案例暴露可移植性限制
开始前需要
- 一份事实可以核对的原稿
- 理解助手指令与插件安装范围
检查模式证据、保护原意，并区分包验证与未测量的编辑效果。
先看结论
- 前置校验通过，不代表最终构建输入全部已验证。
- 目录清单和 ZIP 内部内容需要分别核对。
- 预期失败案例是在记录限制，不是认证平台。
源码检查覆盖字段存在性和部分边界
validate_source 要求若干清单与界面字段为真值，限制初始提示最多三条、每条最多 128 个字符，再检查技能、自检文件和图片路径存在。隔离案例验证了边界输入被接受，以及空版本、四条提示、超长提示和缺失图片会被拒绝。
这些检查不是完整的结构或内容验证。图片路径存在不证明字节构成有效图像，该函数也没有在这一阶段要求 LICENSE。我们的合成案例缺少 LICENSE 仍通过，而后续构建函数会尝试复制它；这说明前置检查范围和整个构建实际需要的输入并不相同。
构建与校验面对的对象不同
build_plugin 重建分发子目录，复制清单、规则、自检、图片和三份许可或政策文件，再写入带版本号的压缩包。validate_build 比较目录中的七文件集合，并核对打包后的规则、自检与原文件字节一致，最后检查压缩文件是否属于有效 ZIP。
最后这一项并不会逐一核对 ZIP 内成员是否符合预期集合。目录验证和压缩包内容验证是不同断言。当前构建函数确实从生成目录写出 ZIP，但更强的独立发行验收应直接检查归档中的成员名与字节，而不是从另一个位置间接推断其内容。
原生 Windows 案例暴露可移植性限制
预期文件集合使用正斜杠，而实际项由 str(path.relative_to(plugin_root)) 产生，Windows 下会包含反斜杠。第七个隔离案例确认，内容齐全的合成目录在这里被拒绝。测试通过是因为准确记录了预期拒绝，不代表 Windows 打包本身已经通过。
七个案例执行固定版本的 validate_source 和 validate_build，并将路径重定向到一次性目录；没有调用 build_plugin 或 main，没有安装技能，也没有调用模型。建议修复方向是比较前统一归档风格路径，再在 Windows 与 POSIX 上测试，本次没有修改上游实现。
如何选择
| 比较维度 | 方案 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
比较不同系统的原生路径行为。
可复制示例
# 建议的可移植比较，不是已经提交给上游的补丁。
actual = {
path.relative_to(plugin_root).as_posix()
for path in plugin_root.rglob("*") if path.is_file()
}
# 还应独立检查归档成员名称和字节。常见问题
执行了整个打包程序吗？
没有。只对临时合成数据执行了两个已经审阅的校验函数。
可移植性修复应该测什么？
统一后的相对路径、精确文件集合，以及 Windows 和 POSIX 下的归档成员。
资料来源
- No AI Slop / scripts/build_plugin.py来源核查 2026-09-14
- No AI Slop / .github/workflows/plugin.yml来源核查 2026-09-14
- No AI Slop / .codex-plugin/plugin.json来源核查 2026-09-14