项目官网：www.chuhaijian.com
GitHub：github.com/tajleonbennis-maker/buildproof
在线案例：DeepTutor 分析档案
一、代码生成之后，出现了新的理解鸿沟
传统开发中，程序员通常一边设计、一边编码，因此脑中天然保存着系统结构。Agent 编程改变了这个过程：人描述目标，Agent 在短时间内创建几十个页面、接口、任务和依赖。代码确实运行起来了，但使用者未必知道它是怎样运行的。
面对一个 Agent 生产的仓库，我们往往会追问：
- 这个系统到底有多少用户可访问页面？
- 每个页面会请求哪些接口？
- 接口最终由哪个后端函数处理？
- 哪些接口需要登录，哪些可能直接暴露？
- 前端和后端分别引入了哪些第三方组件？
- 当前实际安装版本是否存在已公开漏洞？
这些答案散落在路由目录、组件导入、请求封装、后端装饰器和锁文件中。让产品负责人查询图数据库，或者逐个阅读源码，本质上都是把工具的复杂度转嫁给用户。
代码生成解决的是“把系统造出来”，代码验收解决的是“证明造出来的系统是什么”。
二、把代码还原成一份系统档案
基于这个判断，我们开发了 BuildProof。它接收公开 GitHub 仓库，通过确定性静态分析生成可保存、可分享的项目档案。第一阶段没有让大模型自由解释代码，而是优先寻找可以从源码直接证明的事实。
以 DeepTutor 为例，一次分析识别出 63 个 Web 页面、315 个 HTTP API、8 个 WebSocket、27 个业务域以及 120 个直接依赖。相比“这是一个 AI 教学系统”这样的摘要，这些结构化事实更接近验收依据。
三、把页面、请求、API 和函数串起来
只列出页面和 API 清单仍然不够。BuildProof 从页面入口出发，沿前端模块导入关系寻找请求，再将请求路径与后端路由模板匹配，最终定位处理函数：
页面 /workspace
→ 前端请求 GET /api/v1/projects/:id
→ 后端路由 GET /api/v1/projects/{project_id}
→ 处理函数 get_project()
链路中每一步都附有源码文件和行号。动态拼接、无法静态确认的 URL 会进入“待确认”，不会为了让报告好看就猜一个结果。代码分析产品的可信度来自清晰的证据边界，而不是语言模型说得多像真的。
四、供应链不能只看 package.json
package.json 中的 ^12.24.0 是允许安装的范围，并不等于实际版本。可靠的漏洞匹配必须继续解析 package-lock.json 等锁文件。
DeepTutor 中识别出 23 个前端运行组件、80 个后端组件和 17 个工程工具。23 个前端组件都能从锁文件获得精确版本，随后通过 OSV 按生态、组件名和版本查询已公开漏洞。
这里必须保持克制：“未发现已知漏洞”不代表组件绝对安全。对于只有 >= 范围、没有锁文件的 Python 依赖，也不能拿猜测版本查询 CVE。正确做法是标记“版本未锁定”，提示提交锁文件、SBOM 或部署清单。
五、为什么不让用户直接查图数据库
代码天然适合表达成图：页面连接组件，组件发起请求，请求命中路由，路由进入函数。但图数据库是实现技术，不应该成为产品界面。大多数用户不知道节点标签、关系类型和查询语言，也不应该为了回答业务问题学习 Cypher。
BuildProof 因此把图隐藏在产品后面，直接提供系统总览、Web 暴露面、业务能力、API 清单和软件供应链。用户看到的是答案和证据，而不是数据库操作台。
六、Agent 代码验收会成为独立环节
现有工具分别解决代码知识库、SAST、SCA 和 API 文档等问题。但 Agent 生产代码带来了一个更靠前的问题：在讨论漏洞和治理之前，人首先需要快速理解并确认 Agent 交付了什么。
未来每一次 Agent 交付都应该附带一份机器生成、可验证的说明书：
- 功能证明：实现了哪些页面、业务能力和接口；
- 连接证明：前端请求如何进入后端函数；
- 供应链证明：使用了哪些直接和传递依赖；
- 安全证明：暴露面、权限边界和已知漏洞；
- 变更证明：本次生成相对上个版本改变了什么。
BuildProof 目前仍处于早期。后续将把代码审计能力接入同一份系统档案，并增加版本差异分析。目标不是再造一个只有安全工程师会用的扫描器，而是让产品、研发和安全人员围绕同一份证据讨论 Agent 的交付质量。
结语
当代码越来越便宜，理解、验证和承担代码后果的成本反而会上升。Agent 可以在几分钟内生成系统，但组织仍然需要知道它是否符合预期、是否可维护、是否安全。
我们需要的不只是更强的代码生成 Agent，还需要一套独立于生成者的验收机制。BuildProof 是我们对这个问题的一次实践。