# 实验：run_check 沙箱执行 攻克细微算术 off-by-one

## 动机
唯一静默漏报（addBusinessDays 跨周末 off-by-one）需要**真正执行**才能稳定暴露。
按业内最优做法，新增 opt-in 沙箱执行工具 `run_check`，让 logic 维度运行边界用例验证，而非心算。

## 实现（已合并，默认关闭）
- `tool/exec_check.rs`：沙箱跑自包含 JS/Python 片段——临时目录 cwd + 清空环境(仅 PATH) + 6s 超时 +
  `kill_on_drop` + stdin 关闭 + 输出截断 + 退出即清理。
- **默认关闭**（`ctx.allow_exec=false` 直接拒绝），仅 `--exec-verify` 开启——**保留只读信任边界**。
- logic 维度提示：涉及日期/业务日/带跳过循环/进位等，建议用 run_check 跑边界输入再下结论。

## 结果（诚实）：能力到位，但**未能自动攻克** addBusinessDays
- 即便 `--exec-verify` 开启、且 prompt（含一版"强制"措辞），模型对 addBusinessDays **仍在第 1 轮直接 task_done**，
  **没有调用 run_check**——它认为这段代码"看起来合理"，不触发验证。
- **根因**：瓶颈是**模型的"怀疑阈值"**，不是缺少执行能力。对看似合理的细微算法，模型不会主动去验证；
  prompt 强制也无法可靠地逼模型用工具（且对整类日期代码强制执行会显著拖慢/加成本，得不偿失）。

## 结论与定位（按业内最优 + 一步到位）
- `run_check` 作为 **opt-in 验证工具保留**：当模型确有怀疑、或用户显式要核某算法时，它能用真正执行消除心算错误，价值真实。
- **但它不改变"模型是否怀疑"**，故 addBusinessDays 这类"看起来合理的细微多步 off-by-one"**仍是已知局限**。
- **可靠防线仍是单元测试**（业内共识：静态审查不替代测试）。这是诚实、可信的定位——不因加了执行工具就夸大能抓住一切算术 bug。
- 软化了"强制"措辞为"建议"，避免无效的 prompt 膨胀与对整类代码强制执行的成本。