ProofPilot｜AI任务履约验证智能体已完整落地：从真实大模型计划到证据哈希链

本文记录 ProofPilot｜AI任务履约验证智能体的落地情况，只写已经完成并核对过的事实。

一、结论先说清楚

ProofPilot 已经完整落地。它不是一个只停留在概念上的验证想法，而是一条可以走通的链路：从真实大模型生成结构化计划，到按明确口径判定履约，再到用证据哈希链固定判定依据，最后用测试和前端产物收尾。

二、真实大模型生成结构化计划

计划不是手写模板，也不是模型随意输出的自然语言。调用入口是 POST /api/contracts/from-goal，模型侧走的是码道 CLI DeepSeek V4.1，输出的是结构化计划。

这一步的关键在于“真实调用”和“结构化”：计划要能被后续环节逐项拆解、逐项核查，而不是只能被人读一遍、无法被机器继续处理。

三、判定口径：查得到和查不到要分开

履约判定最容易出错的地方，是把“没有找到”和“无法判断”混在一起。ProofPilot 的口径是明确区分的：

• 文件能查、查后确认不存在：FALSE_COMPLETION；
• 文件查不了、证据不足以判断：INSUFFICIENT_EVIDENCE。

前者是明确的未完成结论，后者是证据不足的结论。两者不能互相替代，也不能因为查不到就直接说任务完成了。

四、证据哈希链

判定要有依据，依据要有办法固定。ProofPilot 用证据哈希链把相关证据串起来：证据内容发生变化，哈希就会变化，链上的记录也就不再对应原来的证据。这样做的好处是，判定结果可以回溯到当时的证据，而不是只留下一个孤立的结论。

五、对抗性判定矩阵：五种情形全部吻合

为了检验判定口径是不是只在顺利场景下成立，ProofPilot 做了对抗性判定矩阵。五种情形的判定结果全部吻合，说明口径不是只对一种输入有效，而是在不同对抗情形下都能按既定规则给出一致的判定。

六、测试与前端产物

• 测试结果：102 passed；
• 前端 dist 已入库。

测试通过说明这条链路在已有用例下是通的；前端 dist 入库，说明前端产物已经进入代码库，可以作为后续复核和使用的依据。

七、这篇记录的边界

本文只围绕上面这些已核对的事实写：真实大模型计划生成、两条判定口径、证据哈希链、五情形对抗矩阵、102 passed、前端 dist 入库。没有写没有做过的部署、推广或效果数据，后续如果有新的验证结果，再单独记录。