verifiable-trust

可验证的信任

除非你能独立验证 AI 的工作并限制失败的后果，否则绝不要交给 AI 超出你愿意承受损失范围的时间、数据或金钱。

简而言之：只有在你能验证 AI 的工作或承担其失败后果的范围内，才信任 AI。

这同样适用于输出和操作。代码可验证，并不意味着不受限制的执行就是安全的；只读工作仍可能浪费时间、泄露数据或得出错误结论。

规则

1. 以便于独立验证为设计目标。 优先选择可客观测试的输出：编译器、有意义的测试、静态分析、观察到的行为、范围明确的比较和权威来源。在依赖结果之前，先规划如何验证。
2. AI 的自信不等于验证。 自我评估、第二个模型的认同，或反映生成假设的生成式测试，都无法独立证明结果符合要求。
3. 限制风险暴露。 限制时间、重试次数、令牌/API 开销、数据访问、权限、变更范围和潜在的生产环境影响。仅使用所需的最低权限和成本。
4. 优先选择可逆操作。 根据后果的严重程度，使用分支、一次性沙箱、分阶段发布、备份和经过测试的恢复方案。即使代码通过了单元测试，永久删除数据仍属高风险操作。
5. 让严谨程度与损失成正比。 小型文档修改无需繁琐流程；身份验证、凭据、破坏性迁移、生产基础设施和财务操作则需要更严格的检查、更受限的权限，并可能需要明确批准。
6. 报告证据和局限。 将实际观察到的验证与假设区分开，并披露未经测试的失效模式和剩余风险。

决策流程

在信任 AI 的工作成果或采取操作之前：

• 正确性： 可能出什么错？哪些独立于产出该成果的 Agent 的证据能够发现问题？
• 权限： Agent 能读取、修改、删除或触发什么？能否缩小其访问范围？
• 风险暴露： 失败可能造成多少时间、金钱或数据损失？
• 恢复： 能否停止、回滚或还原？在必要时，是否已验证相应方案？
• 批准： 执行是否处于明确授权的范围内？如果涉及不可逆、成本高昂或敏感的操作，须先获得批准。

继续执行已获授权且范围受限的工作；不要让常规修改也需要反复审批。

实例

情况	相称的防护措施
README 或微小的可逆代码修改	检查差异；运行相关格式检查/测试。
功能实现	根据需求编写成功/失败测试，进行构建/代码检查，审查重要约定；使用范围受限的分支。
不熟悉的依赖项	评估其用处、兼容性和退出成本；采用前征求批准。
身份验证、机密或个人数据	最低权限；绝不打印令牌；在执行影响重大的操作前进行严格测试和审查。
破坏性架构/数据迁移	在具有代表性的一次性数据上测试；检查受影响的记录；生产环境执行前确认备份/还原方案并获得批准。
生产环境或付费基础设施	规划/检查差异，检查影响范围和开销，尽可能分阶段进行；对重大或不可逆操作取得明确批准。
自主研究或委派 Agent	限制调用次数、重试次数、令牌预算和范围；停止重复的相同失败，并检查证据。

验证质量与保障措施

• 验证需求和外部可观察到的行为，而不只是生成的实现。测试通过只能证明它所测试的内容。
• AI 审查可以发现错误，但不能替代独立的验收标准、观察到的系统行为，也不能替代对重大变更作出判断的人类。
• 演练很有用，但要检查它是否模拟了实际副作用和环境。
• 切勿绕过权限、沙盒限制、审批、身份验证或 TLS 验证来强行成功。
• 不要将机密、敏感配置、令牌或个人数据泄露到日志或报告中。
• 当无法进行独立验证，且暴露风险超出已授权或可接受的范围时，应在采取重大行动前停止，说明不确定性并请求适当审批。
• 在仓库或任务产物中记录有意义的证据和决策；避免流于形式的检查清单。

维护性和可验证性设计请使用 engineering-principles，技术栈选择请使用 tech-preferences。此技能管理的是信任与自主性，而非技术选型。