关键判断
- 运行时 skew、构建漂移、缺失 dist/loader 异常，本身就是重要证据，不能被当成单纯噪音跳过。
- shim/stub 可以帮助理解控制流，但会快速削弱“这是产品真实行为”的证明力。
- 安全研究里最危险的不是失败，而是把 harness 行为误当成产品行为。
- 证据要分层：branch-only、lab-only、carrier-grade、user-visible，层级不同，结论也必须不同。
- 真正高质量的结论，往往来自先修复验证边界，而不是先追求一个能演示的结果。
做安全验证时，很多人天然会被“把链路跑通”吸引。能跑通，像是进展；跑不通，像是卡住。所以当环境开始出现构建漂移、loader 异常、缺失 dist、运行时 skew 之类的问题时，最顺手的动作往往是再补一层 shim、再打一个 stub、再垫一个临时补丁，先让东西动起来再说。
但问题是，东西动起来，并不等于你更接近真相。有时候你只是更接近一个由自己和 harness 共同制造出来的假象。
shim 和 stub 当然不是坏东西。它们对研究很有用，尤其是在你想理解控制流、确认某个 fallback 是否会被触发、观察某段逻辑在缺少输入时会怎么走的时候。问题不在于你用了它们，而在于你忘了它们改变了什么。一旦你为了“继续验证”不断扩展 shim 面、替换 loader 行为、绕过原始构建条件，最后得到的很可能不是“产品在真实条件下会怎样”，而是“你改造过的环境在当前假设下会怎样”。
这条边界在 AI Agent 和插件系统里尤其重要。因为这类系统本来就有更多动态加载、工具注册、上下文继承和权限降级路径。你以为自己是在验证一个 user-scoped tool 的身份绑定问题，结果却可能先撞上安装形态失真；你以为只是修一下启动链路，实际上已经把原始载体替换成了研究专用分叉。此时如果还急着输出肯定性结论，就很容易把 harness 行为误写成产品行为。
更成熟的做法，反而是承认“当前不能继续诚实验证”。这不是退步，而是更高等级的控制。构建漂移、运行时 skew、活体安装不一致，本身就是重要证据。它说明当前载体已经不足以承受更强结论。此时最有价值的动作，不是继续堆补丁，而是明确给证据分层：branch-only 线索只能说明控制流方向；lab-only 结果只能说明隔离环境中的可观察行为；真正接近产品级结论的，必须来自更完整、更一致、更少人工改写的载体。
很多时候，研究质量的分水岭不在于你有没有“搞出一个 PoC”，而在于你是否愿意在该停的时候停下，并把“为什么现在不能下结论”写清楚。失败并不可怕，最大的风险是把不诚实的成功误当成完成。对今天越来越复杂的 AI 安全验证来说，这条边界可能比多发现一个 bug 更重要。