你们都应该多问很多问题
作者说他听人讲解时平均每 30 秒问一个问题，靠它及早暴露误解；他还习惯在脑中先预演一遍实现，说这样能在动手写代码前发现设计缺陷。
中文
复制
别人给我讲解东西时，我平均每三十秒问一个问题。我知道这让有些人很烦，但这其实是个好习惯，你也应该这么做。
力求理解
我问的大多数问题都很短，答案也很短。通常我是在确认：“你说 X 的时候，指的是 Y 吗？”，或者“这个 X 就是你刚才说 Z 时提到的那个东西？”。问这些问题的目的，是确保自己听懂了。
早期的一个小误解，到后面会膨胀成大误解，因为你基于第一个误解所误读的一切，本身又会各自变成新的误解，如此层层叠加。所以你不能等对方讲完再一次性把问题都问出来1。
我认为大多数人不提问，是因为他们并没有真正想弄懂：他们乐于相信，跟自己说话的人清楚自己在讲什么。如果对方是德高望重或资历更深的工程师，这种心态会更明显。但一旦你利益攸关，一切就不一样了。当你处在这样的位置——成败由你负责，谈完话你就得回去落实一堆具体行动——你会发现自己想问很多问题。
在脑子里把它搭出来
在工作中，别人给我讲一个方案时，我通常会在脑子里把它搭出来：想象为了实现它需要写哪些具体的代码行。对于已经解决的问题，我有时会略过细节（比如我会说“像同一个服务里也发邮件的 X 子系统那样发邮件”），但至少我会理清这几件事：
- 数据需要在服务之间如何流动（什么样的数据，以及它如何通过网络传输）
- 服务之间如何通信（例如它们如何做认证？）
- 哪些数据需要持久化，以及存放在哪里
如果我听到某些含糊得可疑的说法（比如有人把服务 X 描述成“存储数据”，而我知道服务 X 只跟一个临时的 Redis 存储打交道），我会立刻问：“等等，这要怎么跑起来？”通常这说明漏掉了一个依赖（例如服务 X 必须对服务 Y 发起 RPC 调用，而服务 Y 才有持久化数据库），而这往往意味着设计要改（比如把部分或全部功能挪到服务 Y 里）。
有时候这类问题会暴露出设计中一个根本行不通的功能。这通常发生在某个方案没有考虑到某些棘手特性的时候。我记得很多年前，隔壁团队搭了一套复杂的事件驱动系统，非常优雅，但完全没法把客户数据隔离在单个数据中心里。因为我们公司的招牌特性就是“你的所有数据都存放在同一个位置”，这套系统根本不能用，最后实际上只能放弃。
如果你身处任何形式的技术领导岗位，这项工作你迟早都得做。越早做越好——也就是在别人向你描述方案的那场对话里就做——能省下几小时甚至几天的无效实现。很多时候，这就足以把一个失败的项目变成成功的项目。
与 AI agent 协作
也许你只跟可靠的工程师共事，可以放心让他们做出所有正确的决定。那你大可让他们一口气讲完，不用打断，因为你是否详细理解他们在说什么其实并不重要。那当然很好！但如今你多半还有一些天生就不可靠的同事：AI agent。
我主要用 GPT-6-Astra 和 Claude Opus 5.5。这两个模型都不错，不常犯 代码 错误：它们打算做某件事时，通常都能做成2。但它们一直在犯 设计 错误。它们会以为两个服务能互相通信，而实际上不能；或者忘了自己的代码既要跑在云端也要跑在本地，等等。这主要是因为缺少持续学习：这些东西你入职第一天也不懂，但你有大把时间去慢慢学会。语言模型永远停留在第一天。
你应当对 AI agent 狂轰滥炸 般地提问。我经常问这类问题：
- 这个代码库里其他地方有没有做过 X？
- 服务 Y 真的支持这种认证方式吗，还是你在假设我们还得自己去搭一套？
- 你建的这个子系统，是满足需求 Z 所必需的吗，还是它其实满足的是你假设的另一个需求？
- 为什么我们需要改 A 的接口？
- 为什么我们需要动这个文件？这跟这次改动不是没关系吗？
也许总有一天，我这些问题都能得到合理的回答，让我相信模型知道自己在干什么。但今天还不是那一天。我问的问题里大约有一半，得到的回答让我确信3模型犯了错：它本该复用 X 的现有子系统，或者用别的方式认证 Y，或者让 Z 的实现保持简单，等等。等这种情况不再出现，我也就不再提问了（然后大概得看看公司还愿不愿意付钱让我更多扮演架构师的角色）。
最后几点想法
你们都该多问得多得多。换句话说，你们都该更努力去真正理解自己听到的东西。不要因为觉得对方（或 AI 模型）比你聪明，就相信他知道自己在干什么。没人真正理解复杂的软件产品。如果你对代码库某个领域有深入的领域知识，你会经常发现自己要纠正强大的 AI 模型和 principal engineer。