接一段别人写的代码，我以前的默认动作是从入口一路往下读，读到看懂为止。认证中间件、队列消费者、那个没人记得是谁写的导出模块——一天至少三次，每次二十分钟打底。读到最后常常发现，真正要改的只有一行。
现在第一个动作是找测试。
不查文档，文档八成已经过期；也不问人，问人得等人家有空。直接翻这个子系统现存的测试文件，跑一遍，先确认现在是绿的：
npm test -- src/billing
然后加一条断言，描述我这次想要的行为，看着它变红。⚡这一下，红的那一行就把边界画出来了——哪些是契约、哪些只是碰巧能跑，一目了然。
剩下的活儿基本是照着那条红线改，改完再跑一遍，绿了收工。是真的爽！
这周用下来，原本二十分钟起步的通读，变成五分钟的找测试加写断言。一天三次，一天省四十多分钟，一周三个多小时——体感估算，我没卡表，但三个小时是真的还给我了。
坑得说在前面：没测试的仓库里这招直接失效。那种情况我现在是先写一条描述“当前行为”的测试，哪怕就一行，哪怕只是把输入输出钉死。写不出来，说明问题根本不是“我读不懂”，是这个模块压根没人说清它该干嘛，那得先解决这个。
至于通读整段代码、读懂整个模块的收益，八成用不上。白读。
第二个是我这半年回报最高、但小到不像个技巧的东西。
以前修完一个坑，我会把解法存下来。后来发现没用——解法搜索引擎里全有，真正难的是我当初为什么会想错。所以现在修完一个不轻松的 bug，我强迫自己写三行：
2026-09-14 webhook 重试
以为：重试是幂等的，重复投递无所谓
实际：下游按 request_id 去重，我们没传
下次先问：这条链路的重入靠什么保证
不写“怎么修的”，只写“我错在哪”。
攒到第三个月，会撞见一件挺打击人的事：自己的错误翻来覆去就那么五六种。我的高频项是“默认对方的接口是幂等的”和“假设配置加载顺序无关”。知道自己有这两个毛病之后，读代码那一眼会不自觉地往那儿瞟。一个系统正常跑的时候什么都看不出来，它坏的方式才暴露了当初谁假设了什么。
顺便说，记录这件事我坚持不下来的版本有很多，只有这个三行格式活下来了。为这三行我还认真想过要不要做个模板工具，想了半小时，最后发现手动打字更快。
它的收益不在记录，在下次动手之前那三秒钟的迟疑。
第三个偏一点，但最近踩得最多。
调 AI 写代码觉得“这模型不行”的时候，先别换模型，去看链路。上周一个 Markdown 渲染的活儿，模型给的代码怎么看都对，拼进页面缩进全乱、// 注释被吞。折腾半天才发现是中间那层解析器的事，跟模型一点关系没有。
模型只是链路上的一环，它前面有上下文怎么拼，后面有工具怎么返回，中间还有权限允不允许它动那个文件。哪一环坏了，表现出来都是“AI 变笨了”。所以排查顺序我改成从后往前：先确认工具真的被调用了，再确认返回没被截断，最后才怀疑模型。换模型是最贵的一步，别把它排最前面。
得往回补一句，不然这篇像在无脑劝人“别学习了”。
按需学、撞了再补，前提是你真的补了。有些人的“等项目需要再说”其实是“撞了之后绕过去”，绕三次那条路就废了，下次还得绕。差别不在方法，在有没有回头看那一眼。
另外有两种情况我老老实实从头读，不省这一步：碰到权限判断的时候，和碰到钱的时候。这两个地方的错不是慢一点，是错得没法回滚。前阵子翻到一段判断，表面上按角色拦住了，实际换个入口就能绕过去。这种“看着拦了其实没拦”的地方，你不通读发现不了。省时间省到这儿就该停。
回到最上面那个：找测试这动作，学它花的时间大概就是弄明白你们仓库怎么跑测试，十分钟顶天。一天三次的话，一周内回本，之后全是净赚。
你要是有更快的定位办法，教教我。