在 AI 工程里，我开始把 UNKNOWN 当成一种正确答案

做 Praxis 的验证记录时，我开始更愿意保留 UNKNOWN。最初读一份测试全绿、安装完成、模型也有正常回答的报告，很容易顺势写下“已验证”。但这个词省略了最重要的部分：究竟验证了哪件事，在哪些条件下成立？

让我改变表达方式的，是安装、触发和实际收益之间的距离。它们都值得验证，却需要不同证据。把前一项的通过延伸成后一项的结论，会让一份看似完整的工程记录变得不准确。

PASS 后面需要跟着范围

Praxis 当前审阅使用 PASS SCOPED。我把它理解为：在明确的范围里通过，同时保留范围之外的问题。它要求说明被观察的行为和条件，不能只给一个让人安心的状态。

项目记录了三十项确定性安装测试，覆盖选择安装、幂等、冲突拒绝和修改内容保留等行为。它们能支持安装器在相应测试条件下的结论。至于 Agent 是否因此更准确地做工程决策，这批测试没有观察过，不能拿来背书。

同样，包可以重建、链接可以通过、Skill 格式符合要求，只能证明对应结构和交付行为。测试数量增加，不会自动扩大被验证的命题。我现在写总结时，会先把那句“验证通过”拆成几句具体的话。

Expert 审阅里有二十四个有效合成场景观察：每个专家各一个正例、负例和交界例。本批正例读到了目标 Skill，负例没有读取 Skill，交界回答也保留了相应职责。这说明有限场景下确实观察到了预期行为。

但这些输入有明显信号，负例还主动说明了任务简单或已有规范；会话独立，回答长度也受限制。七次初始调用遇到路由发现失败，降低并发后仅对失败例重试一次。失败是记录的一部分，不能悄悄从成功故事里删掉。

更关键的是，没有 Native Agent 或短提醒对照。回答看起来合理，可能来自原生能力，也可能来自题目给的信息。我无法据此分离 Skill 的贡献，更无法知道它带来的阅读、延迟和误触发成本是否被收益抵消。所以“可调用”有观察，“净收益”仍是 UNKNOWN。

宿主能发现 Skill，与宿主中的模型能正确运用它，也要分开。当前记录里，Claude 的安装发现验证通过，但隔离环境没有完成模型调用，语义行为是 NOT VERIFIED。不能用 loader 的成功填上这个空白。

Codex 那批 smoke 有实际读取和回答记录，但服务端确切模型名与版本仍为 UNKNOWN。单轮观察也没有覆盖自由长任务、多轮上下文累积和其它技能竞争。不能把这些结果写成跨模型稳定的专家能力，更不能推出长期业务质量。

这种限制并不让已完成的工作失去价值。它帮助我知道现在可以试什么、下一次应该观察什么，也避免后来的人把有限通过当成无需重审的保证。

Praxis 的专业边界文档反复遇到同一种问题：没有真实负载，无法确认容量改善；没有恢复演练，备份存在也不证明能恢复；没有代表性样本，格式正确也不证明 AI 输出语义可靠。这些是判断边界的例子，不能被写成 Praxis 已经历并解决的生产事故。

我现在更警惕那种推理上很顺的句子：“设计考虑了回退，因此生产安全”“用了某种方法，因此质量提升”。前半句可能是设计事实，后半句需要现实观察。缺失的观察只能去取得，或者缩小声明，不能靠更完整的解释补上。

事实写实际观察，例如某批场景读取了哪些指导；项目当前结论写现在选择保留什么、在何种范围可用；个人思考写我为什么倾向某种做法；UNKNOWN保存还没有证据回答的问题。设计决定可以明确，效果结论仍可以未知。

对 Praxis，目前可使用的正文和有限验证已经存在；真实业务增量价值、长期跨模型稳定性尚未成立。这是我对当前记录边界的表述，并非已经完成真实 Dogfood 的结果。我可以据此开始受控使用，却不能提前宣称成功。

UNKNOWN 也不必成为无限调查的理由。如果补充信息不会改变眼下可逆的小行动，就可以先行动，同时保留未知；涉及真实风险承诺的缺口，则需要先取得相应观察。关键是别让行动走在声明后面，也别让声明走在证据前面。我希望以后读回这些记录时，仍然看得清自己当时究竟知道什么。