接手陌生模块时，我常会把一段代码丢给 AI，问：「这是在干什么？」它几乎总能讲出一套流畅的故事。问题是——流畅不等于正确，更不等于它真读懂了约束。
我越来越在意一种说话方式：它在「圆场」。表面在解释，实际在把不确定的地方用顺滑的因果糊过去。这篇文章记我怎么听、怎么追问、什么时候该停。写给同样会在「哇它好懂」和「等等它是不是编的」之间来回横跳的人。
圆场长什么样
我遇到过的圆场，大概有几类：
因果补全：代码里没写为什么，它给你编一个听起来合理的「因为……所以……」
命名联想：函数叫
refreshCache，它就按「刷新缓存」的教科书含义讲，不管仓库里这个词早就变味忽略例外路径：主路径讲得很漂亮，
catch、降级、兼容分支一笔带过把猜测说成事实：该说「我不确定」的地方，变成肯定句
用设计模式标签盖住细节：「这是典型的策略模式」——听起来高级，但你还是不知道失败时谁负责回滚
单独看每一句都不离谱。合起来会让你产生「我已经懂了」的错觉，然后带着错觉去改代码。圆场的可怕之处在于：它降低的是你的警惕，不是代码的复杂度。
图：圆场四象：因果补全、命名联想、略过例外、猜测当事实（原创示意图）
我听解释时抓的三样证据
现在我要求 AI 的解释必须带证据，否则我当它在聊天：
1. 指到具体行或符号
「这里因为要避免重复提交」——哪一行？哪个变量？哪个锁？指空了就继续追。指到了但仍像在猜，就让它把那一行原文贴出来再解释。
2. 能复述约束，不只复述步骤
步骤是「先 A 后 B」；约束是「为什么不能并行」「为什么必须先写日志再发消息」。圆场往往只会讲步骤。约束讲不清，说明它在讲教程，不是在讲这份代码。
3. 说不清就停，并标不确定
我会明确说：不确定的地方用「可能/我不确定」标记，不要用肯定语气硬圆。模型被这样约束后，解释质量通常立刻诚实一档。
若它做不到以上三点，我会停。不是生气，是节省被误导的成本。停比「再听它圆两句」便宜。
一套我常用的追问顺序
面对陌生文件，我很少只问一次「这是干什么的」。更常见的是：
「用三句话说明这段的输入、输出、副作用。」
「指出三个你最不确定的点。」
「这个名字在本仓库里是否可能有特殊含义？请先搜再答。」
「例外路径呢？失败时会发生什么？」
「如果我改 X，最可能破坏什么？」
第 2 问和第 3 问特别管用。圆场最怕被要求列出不确定点；一列，气泡就破了。第 3 问则逼它离开「通用常识」，回到「这个仓库的土话」。
我也试过反过来：先让它解释，我再故意提出一个和代码矛盾的「错误理解」，看它会不会顺着我的错继续圆。会顺着的，置信度直接降级。这招有点损，但对检验「它是在读代码还是在陪聊」很有效。
图：追问漏斗：输入输出→不确定点→仓库语义→例外→改动风险（原创示意图）
什么时候解释最容易飘
我的个人经验（含推测）：
文件很长，你只贴了中间一段：上下文不足，它只能靠先验知识补剧情
充满历史包袱的兼容代码：
if (legacy)背后可能是三年前的事故，模型看不见事故生成代码 + 手改混杂：风格不统一时，它更容易讲成「理想设计」而不是「实际演进」
你在催：你说「快点讲重点」，它就会更圆、更短、更滑
缺少测试与调用方：没有「谁在用、怎么验」，解释更容易飘成架构作文
所以我现在宁可多贴一点相关测试、调用方、最近的 commit message，也不要只丢一个函数让它「凭空懂」。输入贫瘠时，圆场几乎是默认模式。
解释和「能改」不是一回事
有个坑：它能把代码讲得头头是道，不代表它改得动。解释阶段我会把它当「导游」；进入修改前，还要再过一轮「如果改这里，测试会怎么哭」。
导游可以错景，改代码不行。我明确分两阶段：
只读解释阶段：禁止提补丁，只允许画地图
动手阶段：必须先复述约束与验收，再写改动
很多人一上来就「一边解释一边改」，圆场会直接变成错误补丁。贵的不是多一轮对话，是回滚和同事的信任。
有一次我让它解释一段限流逻辑，讲得很好，包括令牌桶的比喻。我一高兴就让它「顺便修一下阈值」。结果它按教科书令牌桶改了，而仓库里实际是「固定窗口 + 业务白名单」的土办法。解释阶段的圆场，在动手阶段变成了行为变更。从那以后，解释通过不等于动手许可。
我怎么验证它没在圆场
几个低成本验证：
让它画出调用关系，再和 IDE 里实际跳转对一下
让它预测某个输入的输出，我跑一下（哪怕是单测或本地脚本）
把关键注释遮住，看它是否还敢讲得一样肯定
换一个模型或换一次提问方式，看关键因果是否漂移
问它：「如果作者就在旁边，你最想确认的一个问题是什么？」好的解释者会有问题；只会圆场的往往说「没有了」
若两次解释的「为什么」互相打架，说明这里没有稳定理解，只有叙事。叙事可以启发，不能当规格。
图：验证三角：指到行、复述约束、最小跑通（原创示意图）
圆场不一定是恶意，但是有成本
我想强调：圆场多半不是模型「想骗你」，而是它被训练成「提供有帮助的完整回答」。完整感会压迫它填空白。你要做的是改任务定义：帮助 = 诚实标出空白，而不是填满空白。
我在提示里会写类似的话：「宁可短和不确定，也不要完整和肯定。」效果因模型而异，但方向对：你在奖励诚实，而不是奖励流畅。
对团队也一样：如果有人把 AI 的圆场解释直接贴进设计评审，成本会扩散。我的习惯是：AI 解释可以当草稿，进文档前必须有人用证据钉住因果。否则文档会变成「流畅的假懂」放大器。
什么时候我干脆不让它解释
也有情况我不问 AI：
代码本身有清晰的设计文档和作者还在
关键路径我准备自己单步调试（解释替代不了观察）
涉及安全/权限，我需要权威来源而不是二手叙事
我已经困到只想听一句「你很懂」——这种时候最容易被圆场安抚
AI 解释是加速器，不是真理源。把它放在「提出假设」的位置，比放在「宣布事实」的位置安全得多。
收尾：听懂之前，先听出它在圆
陌生代码最怕的不是难，是你以为自己懂了。AI 很擅长制造这种以为。
我给自己的检查句是：它指到行了吗？约束复述出来了吗？不确定处标出来了吗？ 三样里缺两样，就当它在圆场，继续追，或者自己读。
解释可以快，理解要贵一点。贵在证据，不贵在形容词。下次再让 AI 讲一段陌生代码，试着少说「讲讲这是干什么的」，多说「把证据和不确定点分开写」。你会发现，真正有用的解释，往往没那么好听——但你敢据此改代码。
最后补一句心态：把「听出圆场」当成读代码的基本功，而不是对模型的挑剔。模型会变，圆场还会在；训练自己要证据的肌肉，比追求一次完美解释更划算。
2026-10-15鱼鱼