语音编程：快速搞懂陌生代码库的实用姿势

阅读陌生的代码本质上是一个你还无法准确描述的搜索问题。你不知道这个代码库的词汇表，所以无法用 grep 找到你需要的东西——因为你不知道它叫什么。

于是你只能走那条慢的路：打开入口文件，跟随一个 import 往下走，丢失线索，回去，再试另一个文件。一小时之后你有了一张粗糙的地图，却完全不知道它是否准确。

最快的穿越方式，是假设你有一个熟悉这个仓库的同事，向他提一个模糊的问题，让他来帮你缩小范围。这本质上就是对话，而对话用嘴说要比打字便宜得多。

模糊问题才是关键

关于一个陌生代码库，一个好的初始问题往往出奇地不精确："一个请求实际上是从哪里进入这个系统的？""什么东西在和数据库通信？""有两个 config loader 是什么原因？"

这些问题打字写出来非常糟糕。它们看起来不够严肃，所以你把它们重新组织成听起来更技术化的表述——而这个重新表述的过程中，偷偷夹带了你没有任何依据的假设，你在还不知道是否存在"中间件链"的时候就已经在问它了。

这正是语音编码在一个不是你写的代码库上发挥作用的地方。用嘴说，你只需要问那个模糊的问题。它不需要看起来多好看。而且模糊的版本更诚实地反映了你实际上不知道什么，这让答案更有用。

你愿意打字提出的那个问题，已经被"清理"过了。而真正的困惑就在这个"清理"过程中丢失了。

追问才是真正划算的地方

定向了解不是一个问题，而是二十个连续的问题，每个都依赖于前一个。在这条问题链上，打字变得昂贵——不是任何一个单独的 prompt 贵，而是第二十个问题贵，那时候你已经重新组织表述了半小时。

大声说出来，追问只需要四个字。"哪个先跑？""谁调用的那个？""那个是死代码吗？"你不断追问，因为追问是免费的，地图拼装的速度比阅读构建它的速度要快得多。

而且它更能应对中断。当回答是口头回来的，你可以正看着被描述的那个文件，而不是盯着聊天面板，你的眼睛停留在代码上，而解释同时到达。

指向而非描述

有些问题演示出来要快得多。一个快捷键可以把你当前的屏幕截图附到你下一条语音请求上，所以"这是干什么的？"可以指的是屏幕上这个，而不是用一段话描述你指的是哪个文件的哪部分。

新人上手的一半摩擦，在于定位你困惑的那个东西——足够准确地描述出来以便提问。指向完全省去了这一步。

如果你刚刚接手一个代码库，大致可用的流程是：

用你最模糊的方式问执行从哪里开始。问三到四个主要的移动部件是什么，不用担心命名是否正确。选一个你将要修改的部分，让它带你从头到尾走一遍真实的调用路径。问它对这个仓库感到意外的是什么，哪些看起来不寻常、不一致或者是承重架构的部分。

最后这个问题是人们最容易忘记问的，而它往往是最有用的警告所在之地。

要点不是要避免阅读代码。而是要在花了一下午才发现哪些代码值得读之前，就知道哪些代码值得读。连上一个项目，在你继承的下一个代码库上试试。