从看 diff 到跑应用：执行式代码评审为何能抓到静态评审漏掉的 bug
传统 AI 代码评审大多把改动行喂给 LLM 让它「猜」问题，但生产环境的 bug 往往 diff 干干净净、只在真实数据流动时才暴露（过期会话把用户踢进登录死循环、mock 的依赖通过而真实 API 挂掉）。执行式评审换了一条路：在每个 PR 起一个一次性容器，用 computer-use 智能体像真人一样把受影响流程点一遍，再把视频、日志、复现步骤贴回 PR。典型例证是 Ito 在一个后端库里揪出 diff 完全看不出的 SQL 命名窗口 bug，6 周内约半数实质 PR 被标出问题、确认/误报比超 2:1。它的边界也很清楚：不替代安全精读与探索性测试，原生移动端仍在路线图上；价值在于把「人工点一遍流程」的回归层自动化，让 agentic 编码闭环里终于有一步「真去验证它真的能跑」。
传统 AI 代码评审的默认姿势，是把 PR 的改动行塞给 LLM，让它根据「看起来像不像 bug」做判断。这条路在语法层、明显逻辑层有用，但生产环境里最贵的那批 bug 恰恰不在 diff 里——它们只在真实数据流动时才暴露：一个过期 session 把用户踢进登录死循环，一个被 mock 的依赖在单测里通过、真实 API 却挂掉，一段并发写入在本地没事、上线就丢数据。读代码读不出时序、状态与集成路径，自然抓不到。
执行式评审（execution-based review）把问题换成「跑一遍」：在每次 PR 触发时，起一个一次性容器、从源码构建应用，用 computer-use 智能体像真人一样把受影响的用户旅程点一遍——登录、填表、结算、边界 case——再把视频、控制台/网络日志、精确代码行、复现步骤作为证据贴回 PR。这样做的信息密度远高于「这里可能有问题」的猜测。
一个可核验的例子：Ito 在一个后端数据库项目里，跑通真实 server 与 SQL 查询，揪出一个 diff 完全看不出的命名窗口（named-window）框定 bug，6 周内约半数实质 PR 被标出问题，且确认/误报比超过 2:1。也就是说，它抓到的是静态分析结构性看不到、因为从不执行任何东西的东西。
边界也要说清：它不是万能评审。原生移动端仍在路线图上；对敏感 diff 的精细安全精读、对内部性能工作的探索性测试，人仍然不可替代。它的真实价值是把「工程师每天花 1–2 小时手动点流程」的回归层自动化，尤其在 agent 写码越来越多、人根本 review 不过来的当下，给 agentic 编码闭环补上「真去验证它跑得起来」那一步——让自动合并的循环能跑更长、又不过度信任输出。