‘说不工程师’是ZIRP时代的产物The just-say-no engineer was a ZIRP phenomenon

那些总是说“不”的工程师，是资深和 Staff 工程师群体中的一个典型代表。他们的职责是放慢节奏，阻止增加复杂性的功能开发，并尽可能减少代码量（因为代码本身就是一种负债）。

我们可以称他们为“直接说不”型工程师，与“直接说是”型工程师相对。“直接说是”型工程师痴迷于快速推进，默认批准代码变更，更看重平均修复时间（MTTR），倾向于大量发布代码。而“直接说不”型工程师则注重质量，乐于缓慢推进，默认阻止代码变更。大多数工程师其实处于两者之间的某个位置。这里所说的“直接说不”型工程师，指的是最认同这一角色定位的那群人。

在人工智能时代，“直接说不”型工程师的日子并不好过。过去他们只需拒绝初级工程师手写的 PR 即可，但现在却要面对铺天盖地由 AI 生成的代码——其中一些甚至来自难以拒绝其要求的经理和高管。他们职业生涯中首次面临巨大压力，不得不降低标准，开始频繁地说“是”。然而，这并非因为 AI 的出现，而是因为 ZIRP 时代的终结。

ZIRP 与“直接说不”型工程师

ZIRP，即“零利率政策”，是对 2008 年至 2022 年间软件开发时期的一种简称——当时银行允许企业以接近零利率借款。在此期间，投资者将借来的资金疯狂投入各种项目，导致科技公司被激励不断招聘工程师参与低风险、高回报的项目。成功的企业常常从几十名工程师迅速扩张至数千人，这些人会着手处理各类事务：边缘化的开源项目、无休止的技术迁移、用其他语言重写系统等。

那是一个软件工程师的黄金年代。我们拥有强大的议价能力，几乎可以为任何工作拿到高薪。老板们大多漠不关心，原因有二：（a）团队扩张太快，根本无暇关注；（b）只要多招人就能推高股价，而这正是他们最关心的。但科技公司也面临一个问题：如此多的工程师自由发挥，如何防止系统变得完全失控？这时，“直接说不”型工程师便应运而生。

在这种环境下，拥有一位只负责说“不”的超资深工程师，对公司而言其实非常有价值。原因如下：

ZIRP 的终结

当银行加息时，几乎所有科技公司都立即裁掉了5%-20%的工程师。因为维持一支臃肿的工程团队来推高股价已不再划算。相反，公司必须真正开始赚钱了。然而，这种裁员原因在公开场合并不好说——承认自己曾高薪雇佣数百名工程师从事不盈利的工作听起来实在显得底气不足。幸运的是，零利率时代（ZIRP）的结束大致与ChatGPT的兴起同步，于是科技公司便顺理成章地将裁员归咎于AI的强大能力。“借助这项颠覆性新技术，我们能用一半的工程人力交付十倍的价值”——这个说法听起来就体面得多，尽管逻辑上站不住脚（如果这真的可行，那为何不保留现有工程师，进而实现二十倍的价值提升呢？）

类似的情况正发生在那些“直接说不”的工程师身上。如今，科技公司的专注度达到了过去二十年来的顶峰。它们不再搞一堆杂乱无章的项目，而是疯狂追逐能带来收入的新功能和能力（主要是基于AI，原因显而易见）。这种新环境对“直接说不”的工程师而言极具敌意。就像一条深海巨鲨被扔进湍急的河流：曾经作为顶级掠食者的强大存在，如今却晕头转向、手足无措。

这类工程师过去通常能获得管理层隐含的支持（尽管这种支持往往比较疏远）。如果有人提出异议，他们常会得到回应：“那位工程师很清楚自己在做什么，如果他们说不，我相信他们的判断。”如今，这种支持已不复存在。“直接说不”的工程师现在正遭到批评，甚至被管理层直接否决。他们被要求更像一个“团队合作者”，要找到办法说“是”，或者干脆不再被咨询关键决策（而公司对此也乐见其成）。他们因过去广受褒奖的相同行为而收到差评——这种情况始于2022年之前。

这一切与AI无关。即便LLM（大型语言模型）在本十年没有爆发式增长，行业内部仍会发生同样的文化转变。公司依然会裁掉工程师，而那些原本职责就是拒绝某些事情的工程师，依旧会对“为何现在因说‘不’而被惩罚”感到困惑和不满。

AI

颇具讽刺意味的是，如果ZIRP没有结束，这对“直接说不”的工程师来说本应是一个辉煌的时刻。LLMs本应加剧“工程师失控”的问题——而这正是“直接说不”工程师被赋予权力去解决的问题。由于无法在公开或私下场合质疑AI辅助编码，科技公司将严重依赖这些工程师来阻止AI代码浪潮淹没整个组织。他们本应获得更高的薪酬，并像国王一样受到礼遇。

然而，LLMs反而让“直接说不”的工程师雪上加霜。他们被迫眼睁睁看着其他工程师合并那些原本会被他们拦截的AI生成PR（Pull Request），并被要求亲自使用这些工具：被迫成为自己职业生涯中一直奋力对抗的那种工程师。

更糟糕的是，AI 工具目前运行得还不错。它（尚）未引发任何灾难性后果。代码质量不算高，理解程度也有限，但基本可用（尤其是在企业不断尝试新事物、放弃失败项目的背景下）。因此，那些习惯说“不”的工程师不仅面临生计威胁，连自我认同都受到冲击：他们要么坚称末日将至，要么就得承认自己的技术角色不过是科技行业特殊经济环境下的产物。

纯粹与不纯粹的工程

那么，这些习惯说“不”的工程师会灭绝吗？不会。虽然他们已无法适应所有科技公司，但在某些领域仍不可或缺。在《纯粹与不纯粹的软件工程》一文中，我区分了“纯粹工程”——目标明确、以技术为核心（如开发编译器或语言运行时），和“不纯粹工程”——目标模糊、由客户需求驱动（比如尝试一个不确定能否成功的新功能）。在零利率时代（ZIRP），科技公司做了大量纯粹工程（例如构建 React），甚至将不纯粹工作也当作纯粹工程来对待。而习惯说“不”的工程师恰恰擅长纯粹工程，因为纯粹项目对代码质量要求极高，能容忍较慢的开发节奏。

大多数科技公司仍在进行某种形式的纯粹工程，通常体现在其核心基础设施中。这类工作是必要的，但不需要庞大的工程团队，也鲜少成为焦点。如果你希望继续做一名习惯说“不”的工程师，建议尝试转向这类岗位（同时也要接受：相比2010年代，你的影响范围会更受限）。

总结

如果你喜欢这篇文章，可以考虑订阅我的邮件更新以获取新帖通知，或在 Hacker News 上分享它。

这里是一篇相关预览文章，与本文共享标签。

我不知道十年后我的工作是否还存在。2021 年，成为一名优秀的软件工程师感觉很棒。世界充满了软件，每年都有更多公司需要雇佣工程师来编写代码和运行系统。我知道自己擅长这个，也知道只要我愿意，就能一直做下去。我喜欢的工作不会枯竭。继续阅读……