- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 评审队列里的十二个 PR 全都挺好
- 摩擦本是一台过滤器,而过滤器只有消失之后才看得见
- 眼光曾经是沿着什么路径长出来的
- 现在正发生在新人身上的事
- 「眼光就是全部」这个结论会在哪里变得危险
- 把判断变成可被观测的
- 刻意恢复摩擦的三个习惯
- 团队层面能改的是评审提出的问题
- 参考资料
评审队列里的十二个 PR 全都挺好
周一早上,评审队列里躺着十二个 PR。个个带着测试、命名规整、注释认真。一个一个看过去,没有一个有理由打回。
可把它们摆在一起看,这十二个里有五个是压根就不该做的功能。多了一个开关,多了三个配置项,将来要维护这些东西的人也多了一个。想写打回理由时,冒出来的只有一句「代码没问题,但我不明白我们为什么要做这个」,而这句话作为评审意见看上去很失礼。
摩擦本是一台过滤器,而过滤器只有消失之后才看得见
2026 年 8 月 6 日发布的 Taste Is All That Is Left 正面处理了这个局面。文章的核心是一个观察:努力本身就是一台过滤器。而正如所有过滤器一样,它在被拆掉之前是看不见的。
从前做一个功能要花三天。三天这个成本本身就是一道审查。它逼你先问自己「这值不值三天」,而一半模棱两可的点子就死在这个问题上。现在同样的功能 40 分钟就出来了。40 分钟这个价钱,太便宜了,便宜到过不了任何审查。
于是那些本不该做的东西被做了出来。而且因为它们做得并不差,反驳起来就更难。
眼光曾经是沿着什么路径长出来的
同一篇文章更重要的一段是这个:眼光是以缓慢、笨拙、丢脸的方式长出来的。做出糟糕的东西,被迫和它一起生活,然后在众人面前失败。
把这个顺序拆开,就能看出每一步为什么必要。做出糟糕东西的那一步,把「这样做就会那样」的因果刻进了身体里。和它一起生活的那一步,把维护成本变成了直觉。失败的那一步,把自己的判断和现实之间的差距量了出来。
三者都要花时间,三者都不好受。而且三者只有在产物很糟的时候才会发生。
现在正发生在新人身上的事
问题就出在这里。正如原文所观察到的,现在起步的人已经没有机会把糟糕的版本发出去、然后坐在里面待一阵子了 —— 因为工具白送给他们一个四平八稳的版本。
这不是能力问题,恰恰相反。今天的新人做出能跑的东西,比三年前的新人快得多。只是在这个过程里,那件让他学到「这个选择半年后会索取什么代价」的事情,压根没有发生。他获得了流畅,却跳过了学徒期。
而且这道缝隙在指标上看不见。吞吐量、交付周期、PR 数量里都不显形,直到两年后,它以「一支没人能拍板结构的团队」的形态显现出来。会上两个方案摆着,谁也不敢强硬地主张哪一个,最后要么两个都做,要么听最后一个说话的人的。
再补一句:这不是关于代际的故事。十年经验的人一样会经历。当你在不熟悉的领域里开始接受工具给出的四平八稳的结果,你在那个领域的判断力就在那里停止生长了。区别只在于,你在别的领域已经积攒的直觉,让你更难自己察觉。
「眼光就是全部」这个结论会在哪里变得危险
原文最后的主张很强硬:能告诉你什么值得做的人几乎没有,那一直是更难的技能,而现在只剩下它了。
作为诊断这很有说服力,但把这句话变成处方时得当心。读成「以后只要有眼光就够了」是要出问题的。因为眼光是「做」这份经验的副产品,而不是它的替代品。从没动手做过的人的判断不是眼光,是口味;两者的差别会在出错的时候显露出来。
更准确的归纳是这一句:眼光的价值上升的同时,眼光的供给通道被堵住了。 正因为这两件事一起发生,这不是好消息,而是问题。
把判断变成可被观测的
所以个人能做的第一件事,是把判断掏到外面来。眼光本来就是一种默默运转的能力,而默默运转的东西既无法验证也无法传授。
具体做法是这样。在动手做之前写两三行:要做什么、为什么是现在、不做的话会发生什么。做完之后再把这条笔记读一遍。攒上半年左右,你就能看出自己的预测总往哪个方向偏。大多数人一贯地在「不做会发生什么」上高估。
这条笔记不必是设计文档。事实上写长了你就不会写了。提交信息的正文也好,issue 的第一条评论也好,只要放在以后找得回来的地方,三行就够。要紧的不是篇幅,而是它是在判断做出的那一刻被记下来的这个事实。知道结果之后再写的复盘,会把自己的判断重新编排一遍,没法当作学习材料。
刻意恢复摩擦的三个习惯
第二件事,是人为地把消失的摩擦找回来。不必全部找回来,只挑那些原本会发生学习的点就够了。
| 习惯 | 具体动作 | 被找回来的东西 |
|---|---|---|
| 先自己定一个答案 | 在叫工具之前,把设计用一段话写下来 | 度量自己的判断与四平八稳默认答案之间的差 |
| 强制产生备选 | 拿到第一个结果后,再做两个别的路子来对比 | 只有在选项不止一个时才会产生的判断 |
| 与自己做的东西一起生活 | 亲自负责自己所做功能的运维与故障处理,至少一个季度 | 维护成本变成直觉的那份经验 |
第三条效果最大,也最常被省掉。做的人和维护的人一旦分离,眼光在哪一边都攒不起来。做的一方不付代价,维护的一方不知道选择的来龙去脉。如果组织架构本来就是这么画的,很多时候个人改不了;那种情况下,至少让自己继续收到自己所做那部分的故障告警,也是好的。
第二条里也有个陷阱。让工具一次给你三个备选,出来的通常是彼此相似的三个,因为它们绕的是同一个默认答案。所以至少要有一个是自己动手做的,而且尽可能加上完全相反的约束,比较才成立。比如试着加上「一个配置项都不新增地解决它」这样的约束。
团队层面能改的是评审提出的问题
最后是组织层面。今天的代码评审被设计成去问「这段代码对不对」,而这个问题工具已经答得相当好了。如果评审一直只问这个问题,那评审里就没什么可学的了。
把问题往前挪一步就行。在 PR 模板里加一栏「考虑过但被舍弃的备选及其原因」,并定一条规则:这一栏空着就不开始评审。这一栏做了两件事:逼作者把选择语言化,也给评审者一个看判断而不是看代码的位置。
回到开头那十二个 PR:其中五个会卡在这一栏。没有被舍弃的备选,通常意味着根本没想过备选;而没想过备选,就意味着「干脆不做」这个选项也从来没有被审视过。
参考资料
- Taste Is All That Is Left — notashelf.dev, 2026-08-06 —— 作为过滤器的努力、眼光被养成的过程、四平八稳的默认答案让人跳过学徒期,这些观察是这篇文章的论旨。
- Hacker News 讨论 —— 反方意见也值得一并读一读。
- 本博客的相关文章:「代码从来就不是难的那部分」这句话,为什么那么招人上火
- 正文里的习惯表和 PR 模板建议并非出自原文,而是我自己整理的。