NoWreck：用静态分析核查 AI 编程助手的改动声明

NoWreck 是一款面向 AI 编程助手的「确定性验证器」，核心思路是：当 AI 编程工具修改代码并给出改动说明时，NoWreck 会通过静态代码分析核对「说明」与「真实 diff」是否一致，而不再借助第二个 AI 来评判。这一做法把验证环节从「语义判断」拉回「结构事实」，试图解决 AI 编程场景中常见的「说一套做一套」问题。

它要解决的问题

AI 编程助手在生成 diff 时，往往会附带一段说明，描述它做了什么改动。但实践中这段说明并不总是可信的，常见问题包括：

• 引用了并不存在的内部文件、函数或类；
• 声称调用了某个 API，实际代码里并没有对应调用；
• 描述了某个改动，但该改动并不在真正的 diff 中；
• 实际修改了代码，却在说明中完全没提。

NoWreck 明确把自己定位为「只回答一个问题」的工具：AI 的改动说明是否与仓库中真实发生的变化一致。它不评估代码逻辑是否正确、不检查运行时缺陷、不做安全审计，也不识别第三方包名幻觉（后者被作者交给 slopcheck / slop-scan 等工具处理）。

工作原理

NoWreck 的验证流程大致分为五步：

• 改动前扫描仓库，提取符号、函数、类等结构信息；
• 把用户提示发送给已配置的模型，获取 diff 与结构化声明；
• 改动后再次扫描仓库；
• 通过对比两次扫描结果，独立确定「实际改了什么」；
• 双向比对：既检查每条声明是否成立，也检查每处真实改动是否被提及。

比对完成后，每条声明会被标记为 CONFIRMED（已确认）、CONTRADICTED（被否定）或 UNVERIFIABLE（无法验证），并附上来自结构分析的具体证据。

当前支持的声明类型

v0.1.0 的 MVP 覆盖七类声明，全部通过直接结构事实判定，不做关键字猜测，也不做语义推断：

• ADD_FUNCTION / REMOVE_FUNCTION：结构性存在性检查；
• ADD_CLASS / REMOVE_CLASS：结构性存在性检查；
• FILE_CREATED / FILE_DELETED：结构性存在性检查；
• CALLS_FUNCTION：通过调用点检测判断。

对于无法确定的情况，工具倾向于直接报告 UNVERIFIABLE，而不是猜测。

一个真实运行示例

作者给出了一个针对 openai/gpt-oss-120b（经由 Groq 调用）的实测：提示模型在 somme_file.py 中新增 is_valid_email(email: str) -> bool，同时要求它在说明里谎称调用了并不存在的 sanitize_input()，但代码中不要真的加入该调用。NoWreck 最终报告「1 confirmed / 1 contradicted」：新增函数被确认，虚假调用声明被否定，并给出了基于 diff 的确定性证据。

部署与使用

工具可通过 pipx install . 安装，之后作为系统级 nowreck 命令使用。配置阶段只需设置 base_url、api_key、model 三个参数，支持任何 OpenAI 兼容端点，包括 Groq、DeepSeek、本地 Ollama / LM Studio、OpenRouter 以及 OpenAI 自身。日常使用方式是 nowreck fix "<自然语言需求>"，工具会自动完成「发提示—取 diff—核验说明」的完整链路。

已知局限

• 仅支持 Python；
• 无法穿透动态行为：exec() / eval()、动态导入、getattr() / setattr() 动态参数、元类、猴子补丁和反射等场景会被报告为 UNVERIFIABLE；
• 静态分析本身有公认的边界，作者将其明确列出，不宣称「万能」。

与其他工具的定位差异

• 与 Cursor、Claude Code、Copilot 等生成式工具：互补关系，后者负责生成与编辑，前者负责核验；
• 与 CodeRabbit、Qodo、Greptile 等 AI 代码评审工具：后者给出主观质量判断，NoWreck 做的是确定性事实核查；
• 与 slopcheck、slop-scan：分属不同幻觉类别，NoWreck 明确把第三方包名幻觉让给这些工具。

路线图

作者列出了一些后续方向，包括面向非 CLI 用户的交互式终端选择器、显示完整确定性证据的 --verbose 模式，以及更多模型与声明类型的支持。整体来看，NoWreck 试图用「结构事实」而非「另一个模型的判断」来约束 AI 编程助手的输出可信度，是 AI 编程工作流中一个值得关注的轻量级补充。