别被 AI 写代码写得顺溜给骗了

现在的 Benchmark 大多在测代码生成的质量，但对于我们移动端开发或者做复杂业务逻辑的人来说，真正值钱的是 AI 能不能像个 Senior Engineer 一样，知道改动某个核心 Model 后，哪些隐藏的依赖、动态分发的逻辑或者底层的 Worker 会跟着炸掉。很多模型在单文件解释上表现得极其“自信且流畅”，但这很可能只是它在复读文本，而不是真的理解了代码的拓扑结构。

我最近在琢磨怎么量化这种“理解力”，想测它到底知不知道代码里的“尸体”埋在哪。我试着搞了个“变更影响审计（change-impact teardown audit）”的测试逻辑：

1. 构造任务：找一个项目里的核心 Hub Model，给 Agent 下指令：“在修改这个 Model 的销毁逻辑前，找出代码库中所有依赖它的地方。”
2. 硬核校验：不能听它在那儿瞎掰。必须人工预先标注好所有的依赖点（精确到 file:line），然后让一个 Reference-aware 的 Judge 去比对。哪怕它说对了大概方向，只要没指到具体的行，一分都不能给。
3. 抗随机性：别指望一次推理就能定胜负，同样的 Prompt，有的模型跑两次可能一次对一次错，这种方差必须考虑进去。

我拿了 13 个 Ruby 项目跑了测试，发现如果给 Agent 提供结构化的 Map，它在大项目里的表现会大幅提升。但这套测试依然有坑：它太依赖静态结构了，如果你的项目里全是 Pub-Sub 事件总线或者高度动态的 Dispatch，这种测试法还是会失灵。

如果你的项目里存在大量运行时数据流（Runtime data flow），这种基于静态依赖的审计可能根本测不出 AI 的智商。

# Change-impact audit test logic
Task: "Before you change how this model is torn down, find every place in the codebase that depends on it."
Validation: Match agent output against manually pinned [file:line] key.