AI解释代码很流畅，如何验证它找到了真根因

一、流畅的解释，未必落在决定结果的那一行

把一个陌生项目交给智能编程工具，它通常反应很快：模块关系图画得清楚，函数职责讲得头头是道。这类“通读式理解”对建立全局认识有帮助，却与调试要回答的问题不在一个层面。调试追问的是“为什么导出文件里少了一条记录”，这需要指向具体的条件判断、具体的调用位置和具体作用的那份输入——一个听起来合理的叙述，可能覆盖了架构常识，却恰恰没有落到决定输出的那一行代码。

业界有一类值得借鉴的提示词设计思路：不要求模型一次理解整个系统，而是围绕单个功能做端到端追踪，并要求把“证据、推断、未知”三种成分显式分开。这个方向的价值在于，它把AI的输出从“讲一个故事”变成“提交一份可核查的推理记录”。下文不引用任何现成工具的示例，而是自建一个最小的导出程序，专门讨论怎样让解释接受检查。

二、第一步：把大问题收缩成可观察的差异

不要一上来就问“这个项目设计得怎么样”。先构造一个教学场景：程序把几笔商品记录导出为CSV文件，输入中有两件数量为正的商品和一件数量为零的商品，而输出文件里数量为零的那一行消失了。于是问题被精确表述为：为什么数量为零的记录没有出现在导出文件里？

这个问题同时锁定了三样东西：入口（导出程序）、输入（这批商品记录）、观察对象（实际输出与期望之间的差异）。你不需要先理解登录、搜索、通知等模块，只需沿着导出路径找出数据在哪里被选择、转换和写出。即便AI暂时认不出整体架构，也有机会对这一小段代码给出可核查的解释。

但问题小，不代表可以省掉前提。至少要写清楚：

• 导出范围：是导出全部商品，还是只导出“可售”商品？业务规则里零库存算不算有效数据？
• 输入版本：当前分析的输入文件，就是产生这次输出的那一份吗？
• 输出新鲜度：看到的输出文件是否被旧缓存或历史文件覆盖？

这些前提看似琐碎，却能防止分析从一开始就在解释另一条路径。实际排障中，相当一部分“AI解释错了”，其实是数据版本、缓存或环境等前提没有对齐。

三、第二步：沿着数据走，而不是沿着文件名猜

接下来追踪数据流：入口如何拿到记录、哪个函数筛选、哪个函数拼装字段、最后谁写出文件。两个提醒值得写进流程：

• 文件名叫“export”，不代表导出的全部逻辑都在这个文件里；
• 一个名字平平无奇的共享工具函数，可能才是真正决定哪些记录留下的角色。

用示意性伪代码表示这个教学程序：

# 教学示例：商品记录导出（伪代码）
records = read_file("inventory.csv")     # 读取输入记录
function is_valid(record):
    return record.quantity > 0            # 筛选条件
function export_csv(records, output_path):
    file = open(output_path, "write")
    file.write("sku,name,quantity")       # 写出表头
    for record in records:
        if is_valid(record):              # 实际调用位置
            file.write(join(record.sku, record.name, record.quantity))

在这个程序里，筛选规则是“数量大于零”，于是数量为零的记录在写文件之前就被移除了。注意，支撑这个结论的最小信息集是三件事：条件在代码中的实际位置（写文件循环内的判断）、执行的条件（quantity > 0）、该条件作用的具体输入（quantity = 0 的那条记录）。只说“系统可能做了过滤”，等于没有解释。

这也是检验AI回答质量的一把尺子：一个可接受的解释至少包含“定位到的代码位置＋该位置执行的条件＋条件对具体输入的作用结果”。缺任何一项，都应追问补齐，而不是默认成立。

四、第三步：把解释拆成三种成分——证据、推断、未知

同一个结论背后，往往混着三种性质完全不同的表述，而混用它们正是误判的主要来源：

1. 静态证据：代码中能直接定位的事实。比如“is_valid 的判断条件是 quantity > 0”“该判断位于写文件的循环内部”。这类表述不需要运行程序，靠阅读代码即可核实。
2. 推断：基于证据推演出的结果。比如“quantity 为零的记录会在写出前被移除，因此不会出现在文件中”。这是推理的产物，尚未被观察确认。
3. 运行证据：程序实际执行并产生了对应输出。比如真实运行一次，观察到输出文件中确实只有两行数据。

三者可以相互支持，但不应被压缩成一句“已经确认”。区分它们的意义在于：

• 只有推断没有证据，说明条件可能是“脑补”出来的，必须先回到代码里找到出处；
• 只有静态证据没有运行证据，可能存在别的路径——比如那条记录根本不在输入里，或者你查看的输出是旧文件；
• 显式标注“未知”（例如“尚未确认输入文件是否为最新版本”），为下一步检查留出明确入口。

实践中一个有效的提示词约束是：要求AI（也要求自己）按三栏作答——“我看到的代码事实 / 我据此作出的推断 / 我还不知道的部分”。仅这一个结构约束，就能显著减少把猜测混入事实的情况，因为它在表达层面禁止了“已确认”式的越权表述。

五、第四步：设计反例，让解释主动接受证伪

有了候选解释，下一步不是收集更多“赞同”它的例子，而是设计最能推翻它的小输入：

• 如果解释是“零库存被排除”：把另一件商品的数量也改成零，预期输出应随之减少一行；若输出不变，解释立刻存疑。
• 如果解释是“中文名导致导出失败”：保留中文名，只把数量从零改为正数，观察该行是否出现。一个输入就能把两个猜测区分开。
• 再试边界样本：负数量、空记录列表、缺失字段。负数量用于检验规则是严格的”> 0”还是”≠ 0”；空列表用于观察程序是崩溃、还是只写出表头。

这里的关键不是让AI为每个猜想都补一套庞大测试，而是每次只选一个“分辨力最强”的输入：它在不同解释成立时应当产生可区分的结果。一个能区分原因的样本，胜过大量重复验证原结论的样本。

更重要的是对失败结果的态度。反例推翻了解释时，正确动作是让结果推动解释更新——重新回到证据链，寻找新的条件位置；而常见的不良模式是当场“打补丁”：改口说这是特殊情况，顺口补一个新的未经验证的原因。规则很简单：任何新解释都必须再次交出“可定位的证据＋新的可区分实验”，否则它只是换个说法继续讲故事。

六、把方法沉淀为可复用的检查清单

与AI协作排障时，这套方法可以固化为六步清单：

1. 问题定义：一句话写清入口、输入、期望输出与实际输出的差异；
2. 前提核对：数据版本、导出范围、缓存与环境逐一确认；
3. 数据流追踪：按“读取→筛选→转换→写出”记录每个环节；
4. 三栏记录：证据、推断、未知分开填写，禁止混写；
5. 反例验证：为当前最强解释设计一个最能推翻它的输入；
6. 结论分级：静态证据与运行证据齐备，才允许标注“已定位”。

七、结语

AI辅助排障的价值，不在于产出一篇流畅的叙述，而在于加快“定位—推断—验证”这个循环。当你要求每条解释都附带可定位的证据链，并主动用反例去冲击它，AI的流畅就从风险变成了资产：它提出候选原因更快，而你验证得更快。把“听起来对”升级为“验证过”，才是与AI协作调试时真正可靠的姿势。