接手旧代码库，先核验 AI 的每项结论

接手一个老仓库，最危险的可能是那份看起来很完整的架构说明：README 已经过时，AI 又根据目录和命名补出了一张貌似合理的地图。等你沿着它开发，才发现依赖的模块早已没人调用。

原文提出的「代码考古核验」有一个明确原则：把 AI 的探索报告拆成待验证的主张，再逐条查源码。这个思路值得借鉴，但文中的调用预算、存证和付费方案属于 Zambo 的产品流程，不能直接当成代码理解准确率的证明。

AI 画出的架构图，为什么只能先当作假设

作者描述了一个典型风险：探索者给出的模块、入口和数据流说明，有些正确，有些只是听起来合理。页面上没有区分，接手者就可能在六周后，基于一段死代码继续设计功能。

解决办法是改变交付单位。不要直接交付「系统如何运行」的大段说明，而要拆成可以检查真假的陈述，并指向具体文件。

没有核验的主张，必须一直保留「未检查」状态。

原文的流程先用一次 new_session 建立任务，再用一次 memory_remember 保存范围和规则，包括仓库是谁、什么算一条主张，以及打开对应源码文件之前不得标为已验证。随后，provibe_audit 提供自动审计结果，探索者的主张按代码区域分成五组，用五次 memory_remember 保存。

这里有个实用约束：每条主张应能对照一个文件判断。它迫使报告写得具体，也方便后来的人复查。

不过，「某个函数是否导出」适合这样验证，「请求最终是否经过权限检查」通常涉及多个文件。原文没有解释复杂调用链如何拆分，也没有给出实际仓库和主张清单。因此，这更接近一份核验流程设计，还不是经过案例展示的效果报告。

打开文件是证据入口，但不是正确性的终点

核验阶段安排了 24 次 pdf_extract，每次通过源码原始 URL 打开一个模块文件，对应一条主张；再用 9 次 pdf_extract 深挖风险最高、最可能被后续开发依赖的模块。

工具名虽然叫 pdf_extract，文中用途是读取源码 URL。它如何处理访问权限、源码格式和读取失败，原文没说清。

完成核验后，用四次 memory_remember 保存地图，四次 journal_log 记录过程，再读六次源码解决分歧。最终交付包含裁定结果和第 2 周的继续调查计划。

地图中的主张分为四类：verified、corrected、dead、unchecked，分别表示已验证、已纠正、死代码和未检查。找不到对应文件，或者文件打不开，都必须写明原因，留在 unchecked。

作者还区分了两种证据：源码读取支持对代码行为的判断；回执（receipt）证明保存的记录自保存后没有变化。

记录没有被修改，不等于记录里的判断正确。

这一区分是原文最扎实的部分。不过，即使打开了源码，也可能读错条件分支；判断死代码，还可能需要搜索引用、检查动态注册或运行验证。原文没有展示这些检查。因此，「已验证」究竟覆盖文件内容、调用关系还是运行行为，实际落地时仍需补充定义。

58 次调用是产品预算，不是通用工程定额

作者为整个流程预设了 58 次计量调用，另有免费的收尾和交接。免费路径每天提供 20 次调用，分三天完成：

• 第 1 天执行第 1—20 次调用，完成建档、规则、审计、五组主张及前 12 条源码核验，交接时列出剩余 12 条。
• 第 2 天执行第 21—40 次调用，完成第 13—24 条核验及前 8 次深挖。第 21 次调用就是第 13 条核验，深挖尚未开始。
• 第 3 天执行第 41—58 次调用，完成第 9 次深挖、地图、日志、分歧处理、裁定和后续计划。

第 20 步之后还剩 38 次调用。任务可以通过 Continue my Zambo session 加上收尾返回的 pickup 信息继续；作者称恢复免费，不占次日的 20 次额度，并保留目标、回执和下一步。

这里的三天是额度安排，不能理解成任意仓库三天就能核验完。

商业方案也很直接：Day Pass 一次支付 $0.99，24 小时内不限调用；Zambo Pass 为 30 天 $29，$ZAMBO 持有者为 $19，均不自动续费。这些是原文报价，未经过本文独立核实。

接入统一经过 MCP 端点 https://zambo.dev/mcp。原文列出 Claude、Cursor、ChatGPT、Windsurf、VS Code，并要求把随文工作流文件交给 agent；当前提供的材料没有包含该文件。

代码侧的安装命令如下，解决的是不同 agent 框架接入同一服务的问题：

pip install crewai-zambo
pip install langchain-zambo
pip install aer1-openai-agents
pip install aer1-autogen
pip install agno-aer1
pip install aer1-llamaindex
npm install aer-1

按行对应的原文版本是 CrewAI v0.1.9、LangChain v0.1.10、OpenAI Agents v0.1.20、AutoGen v0.1.16、Agno v0.1.2、LlamaIndex v0.1.15、npm / Node v0.1.27。要留意最后一行：它安装的是 Node 包，以上命令都没有锁定版本。

作者称各入口共用 AER-1 记录格式，并将 draft-zambo-aer1-26 称为开放 IETF 草案。草案身份与正式标准、广泛兼容仍是不同的事。

我的判断

我认可把「探索」和「核验」分开。AI 特别擅长把零散线索组织成流畅叙述，明确标注未检查项，能减少读者把推测当事实的机会。

但这篇文章带有明确的产品推广目的。作者披露自己是 AI，也是 Zambo 的运营负责人。文中没有准确率、缺陷发现率、耗时对比，也没有展示为什么恰好选择 24 条主张和 9 次深挖。这些数量应视为工作流配置，不能作为效果背书。

与普通 Markdown 交接文档相比，存证服务提供了保存记录和恢复任务的机制；与引用搜索、静态分析、测试相比，它没有替代后者的验证能力。一般团队可以先在仓库内维护带文件位置、核验理由和未解决问题的清单，等到确实需要跨工具核验记录时，再判断存证是否值得引入。

另外，原文强调记录保存后未变，却没有说明如何绑定仓库提交。源码会继续变化，核验结论若不注明对应版本，很快也可能成为下一份过期 README。

能拿来做什么

• 接手前端或 Node 老项目时，先让 AI 列出带文件路径的待核验主张，优先检查入口、路由和关键依赖，再据此安排修改。
• 让交接报告明确区分已验证、已纠正、死代码和未检查，并为未检查项写出原因，避免后续 agent 自动把它们当作事实。
• 对权限链路、动态加载和死代码判断，要求 AI 补充引用搜索或运行证据，并注明核验对应的提交版本。
• 采用 Zambo 前，先用一小组真实主张检查文件读取、任务恢复和回执核验是否满足需求，再决定是否购买额度。