用 ProofRun 给 AI 写的代码跑一遍本地验证才敢放心合并

把代码交给 AI Agent 写的最大痛点不是它能不能写出来，而是你不敢直接 merge。每次都要手动跑一遍测试，或者盯着终端看有没有报错，这种心智负担其实很高。ProofRun 的逻辑很简单，它相当于给 AI 编码过程开了一张“本地验证收据”，在代码进入主分支前，强制在本地环境跑通验证逻辑。

我之前尝试过很多种验证流，但大多数要么太重（得起一套完整的 CI/CD），要么太轻（全靠 AI 自吹自擂说它跑通了）。ProofRun 这种本地凭证机制能把“AI 声称已修复”和“本地环境真实通过”这两个环节死死锁在一起。

具体到实操层面，它的工作流大概是这样的：

一、定义验证脚本
你需要为每个任务编写一个简单的验证脚本（比如 shell 或 python），用来定义什么才叫“成功”。

# 示例：验证 API 接口是否返回 200
curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health | grep 200

二、运行验证并生成 Receipt
当 AI Agent 完成代码修改后，ProofRun 会在本地执行上述脚本。如果通过，它会生成一个包含时间戳、执行环境和结果的验证凭证（Receipt）。

三、凭证校验
在提交 PR 或合并代码前，检查这个凭证是否存在且有效。如果没拿到这张“收据”，代码直接打回重写。

这种方式其实是在给 AI Agent 增加一个确定性的约束层。对于那些复杂的大模型编程任务，如果缺乏这种本地闭环验证，很容易出现 AI 在一个 Bug 还没修好时就开始修下一个 Bug，最后导致整个 codebase 陷入混乱。

• 验证维度： 依赖本地实际运行结果，而非 LLM 的自我评估。
• 信任机制： 通过 Receipt 机制将不可信的 AI 输出转化为可信的本地状态。
• 集成难度： 极低，只要能写简单的测试脚本就能跑通。

比起盲目追求更强的模型，这种在工作流中加入验证节点的实战方案反而更让我觉得靠谱。