用途：当调试或修改行为依赖不确定的因果假设、且下一步动作可以检验它时，使用 Bet On It 把每个动作变成一次可结算的“下注”。核心原则是让每个动作挣得或失去置信度，绝不在结果出现后重写预测。
用法：在工作笔记或注释中记录，而不是写入仓库文件。需包含：Hypothesis（当前因果解释）、Expected observation（下一步动作预期的具体结果）、Expected change（文件、状态、指标或行为；纯观察步骤写 none）、Disproof（会使假设不成立的结果）。使用可观测信号，一次下注可覆盖耦合步骤；机械性工作或已确定需求可跳过。
执行：选择最便宜且安全、能区分合理备选方案的最小判别步骤；优先只读观察或临时探针，再做持久化修改；保留基线，分离无关改动。
结算：动作后保留原始预测并追加 Observed（实际结果，含意外变化）、Verdict（matched / partially matched / failed / inconclusive）、Next action（继续、细化、放弃、回滚或获取更好信号）。判定应用需一致：matched 表示预期发生且未被证伪，提高置信但不证明因果，因为竞争假设可能预测同样结果；partially matched 需缩小或修订假设；failed 表示有效判别器产生证伪或未通过必要预测，应放弃或修改；inconclusive 表示该步骤或测量无法区分备选，不计为支持。
限制：假设失败后，对缺乏独立依据的推测性改动应回滚；若想保留，需说明新理由并在新预测下测试。
示例：针对重复结账请求，Bet 1 预测插桩会显示两次客户端处理器调用；一次调用伴随两次请求即证伪，此时不做行为改动。仅当 Bet 1 匹配时，Bet 2 预测移除 Checkout.tsx 中的重复绑定会把调用与请求从两次降到一次；一次调用后仍有两次请求即证伪。若 Bet 1 失败，不要实施或保留客户端修复，应形成重试或幂等性假设。