用Plumbgraph核查AI代码是否真正完成

AI 编程助手说「完成了」，最多说明它停止了修改，不能说明依赖真实存在、测试没有缩水、改动也没有波及其他调用方。作者介绍的 Plumbgraph，想把这些验收问题变成可执行的检查，最后汇成一个 verdict。

它的价值在于把「看起来能用」拆成几项可以追问证据的判断。不过，原文提供的是工具能力说明和一次演示，没有给出准确率、误报率或团队效率的对照数据。

验收不能只问测试有没有通过

作者首先检查两个容易被忽略的问题：代码有没有被使用，依赖是否真实。

dead-code 用来识别死代码，同时提供可达性证据和误报风险。可达性就是沿着调用关系，判断某段代码有没有机会被执行。这里有用的不是单独一个「未使用」标签，而是工具把判断依据和不确定性一起交出来，方便人继续核实。

check-deps 则把导入声明与项目的依赖清单比较，还可以选择查询 PyPI、npm、crates.io。它针对的是 AI 编程中一种具体错误：生成了看似合理、实际不存在的包名。

但这两层检查回答的问题不同。依赖清单检查关注导入与项目声明是否一致；在线查询关注仓库里是否存在这个包。包确实存在，也不能直接证明它就是当前代码应该使用的包。 原文没有进一步交代版本兼容性、导出接口等问题如何检查。

测试有没有变弱，改动会影响到哪里

测试通过之前，还要看测试本身发生了什么变化。

weakening 读取 git diff，寻找被删除的测试、新增的跳过标记，以及被放宽的断言。如果验收只看最后一次测试结果，就可能遗漏「实现没修好，约束先变松了」的问题。

这也是作者这套流程里比较有针对性的一环：检查对象不仅是业务代码，还包括证明业务代码正确的那些条件。

另一个问题是影响范围。impact 列出传递调用方和需要运行的测试。传递调用方指的是间接依赖这段代码的上层调用者：修改一个底层函数，风险可能沿调用链向上传递。

map 则提供受 token 预算约束的代码概览。它试图解决 AI 阅读仓库时的上下文分配问题，让有限输入优先装下代码结构信息。至于概览如何取舍、测试如何筛选，给出的原文没有展开。

一个 FAIL，背后应该有可追查的原因

Plumbgraph 通过 CLI 和 MCP 提供本地代码分析，并把自己定位为提交前的检查关卡。文中的 MCP 使用 stdio 通信；项目徽章还标出了 Rust 1.85+ 和 Apache-2.0。

最后，verify 将前面的检查与 diagnostics、semgrep、ast-grep 等结果合并，给出统一 verdict。原文到这里便结束了，没有展示完整配置和各项结果如何影响判定。

作者展示了在 examples/demo-app 上运行 plumb verify --run --online 的真实输出：虚构的导入、未使用函数、eval() 和 print() 被报告，最终结果为 FAIL。

这张演示由 scripts/render-demo.py 捕获，原始文本位于 docs/demo/verify.txt，至少提供了可以追查的输出来源。但演示里报告了 print()，不等于所有项目都应该禁止它；具体规则和适用场景，原文没有说清。

我的判断

我认同它把「完成」拆成独立验收项的方向，尤其是依赖真实性和测试弱化检查。它们补上了单看测试是否通过时容易漏掉的两类问题。

不过，统一 verdict 的可靠性仍取决于底层分析和规则。工具报告的死代码是否真能删除、列出的测试是否足以覆盖影响，都需要结合项目结构判断。作者主动提供误报风险，是合理的设计方向，但原文没有数据证明判断有多准。

和常见的类型检查、lint、测试流水线相比，这套工具增加了检查维度。原文没有给出对照实验，不能据此认定它已经能替代现有验收流程。 更稳妥的定位，是给 AI 编程增加一组有证据的复核入口。

能拿来做什么

• 审查 AI 修改的前端或 Node 项目时，把新增导入与依赖清单逐项核对；遇到陌生 npm 包，再确认它是否真实存在。
• 阅读代码 diff 时，同时检查测试 diff，重点看删除的用例、新增的跳过标记和变宽松的断言，并要求解释修改原因。
• 修改公共函数前，先梳理直接和间接调用方，再选择需要运行的测试；采用 impact 时，也要复核它给出的范围。
• 如果试用 Plumbgraph，可以把文中的 plumb verify --run --online 作为了解检查输出的入口，重点阅读问题证据和误报提示，而不是只看最终 verdict。