AI 编程没有杀死“总说不”的工程师，账本先变了

软件团队里有一类人，最常说的话不是“我来做”，而是“这个别合”。

他们会拦低质量 PR，反对仓促重写，要求补测试，追问边界条件。Sean Goedecke 近期把这类人称为 just-say-no engineer。中文里可以叫“默认说不”的工程师。

这类人最近变得尴尬。

AI 编程工具让代码来得更快。Copilot、ChatGPT 可以生成样板代码、小功能、测试和脚手架。经理看到的是速度。产品看到的是“先跑起来”。但守门型工程师看到的，往往是更多需要审的代码、更多不确定的依赖、更多以后要还的债。

我更在意的不是 AI 有多强，而是组织为什么突然不愿意听“别急”。答案更像是：账本变了。

“总说不”曾经是扩张期的安全阀

ZIRP 指零利率政策时代。大致从 2008 年金融危机后到 2022 年前后，低利率让科技公司更容易低成本融资。投资人也更愿意接受长期增长叙事。

那几年，很多软件公司持续扩招工程师。团队变大后，会自然长出一批不直接对应当季收入的工作：系统迁移、架构重写、内部平台、开源项目、边缘功能、技术品牌建设。

这些工作未必立刻赚钱，但在扩张期能被解释为“为增长做准备”。

于是，“默认说不”的工程师有了组织空间。系统被更多人改，代码库变厚，跨团队依赖变多，确实需要有人踩刹车。否则今天快一点，明天可能全线变慢。

这不是把高级工程师写成“只会阻挠”。好的 Staff 工程师，本来就该在质量和交付之间做取舍。

区别在于，过去组织会承认“少写一点代码也是贡献”。现在同样一句“不”，更容易被追问：这能省多少钱？能少出多少事故？能不能支持这个季度上线？

这就是主线。

“说不”的价值没有消失，但它必须换一种证明方式。

利率上升后，“默认阻止”不再天然占理

2022 年后，美联储进入加息周期。科技公司的融资成本上升，市场也不再只奖励扩张。随后，行业出现多轮裁员、招聘放缓和项目收缩。Meta、Amazon、Google、Microsoft 等大公司都公开削减过岗位或收缩项目。

这里不能简单说“AI 导致裁员”。证据不够，也不准确。

更稳妥的判断是：钱变贵后，公司开始要求工程投入更快转成收入、利润或效率。管理层不再愿意为大量探索性工程，配套同等规模的技术把关。

这会改变技术评审里的权力关系。

过去，资深工程师说“这个设计会带来长期维护问题”，管理层可能默认相信。现在，管理层更可能接着问：“那有没有更便宜的版本？能不能先上线？出了问题能不能回滚？”

对 Staff 工程师来说，动作要变得更具体：

• 不只说“架构不干净”，要说清楚会增加哪些故障面、哪些值班成本、哪些迁移成本；
• 不只拦 PR，要给出可接受的降级方案，比如灰度、开关、回滚、可观测性补齐；
• 不只谈长期质量，要把质量翻译成事故率、恢复时间、云成本、返工次数。

对技术管理者来说，难点是别把所有“说不”都当阻力，也别把所有“先上”都当敏捷。

核心基础设施、编译器、运行时、数据库、权限系统这类领域，仍然需要高门槛。这里一旦出错，成本不是一个功能延期，而可能是稳定性、数据一致性或安全边界受损。

但增长功能、内部工具、AI 试验项目，适合另一套打法：小范围上线、可回滚、可观测、失败后能快速废弃。

刀要用在刃上。守门也一样。

AI 放大了冲突，但不是根因

AI 生成代码让冲突变密了。

过去守门型工程师面对的是人手写的 PR。现在还要面对 AI 补全、AI 生成模块，以及团队对“更快交付”的期待。代码更多，审查压力更大，争论也更容易从技术问题变成资源问题。

拒绝一段 AI 辅助生成的代码，表面是在说质量不够。实际可能是在挑战一个项目的时间表、预算和 KPI。

但这仍然不能说明 AI 是根因。

如果低利率扩张还在，AI 可能会让守门型工程师更有价值。代码洪水越大，越需要人守核心系统、权限边界、数据一致性和运行时稳定性。

真正反转的是组织目标：公司不再愿意为“更多代码、更多项目、更多探索”继续买单。AI 只是让这个反转更刺眼。

接下来更该看四个指标，而不是只看 AI 写代码像不像人：

如果这些指标没有恶化，很多团队会继续把默认答案从“不”改成“先上线”。

如果它们恶化，组织会重新想起那类难相处的人。不是因为他们更会表达，而是因为账本又会把质量写回来。

回到开头的问题：AI 编程没有杀死“总说不”的工程师。它只是让他们更难用旧话术生存。

以前，“这是正确的工程做法”可能就够了。现在不够。现在要证明：不这么做，会具体贵在哪里。