背景：一篇 InfoWorld 的文章让我想起的事#

刚看完 Nick Hodges 在 InfoWorld 上 2026-04-29 发的 A new challenge for software product managers。文章不长，核心就一句话：

It used to be the hard part was jamming in that extra feature. Now? The hard part will be keeping them out.

作者的论点是给 PM 的：以前 PM 要争时间、争资源把 feature “塞"进版本，现在 agentic AI 让一个 feature “morning conceived, afternoon shipped”——backlog 这个本来给 due diligence 留缓冲的东西也跟着塌缩了，PM 的难点从"怎么加"反转成了"怎么挡”。

但我读的时候一直在想另一件事：这件事不只是 PM 的难题，工程师其实是被同一股压力波及的，而且我们过去赖以否决 feature 的最强武器，正好就是被 AI 拆掉的那个。

这篇是顺手写的延伸笔记，把 Hodges 那个反转放进工程师这一侧再看一遍。不是反驳——我同意他的判断——只是想说，“挡 feature"这个新责任如果只压在 PM 身上，通常挡不住。

Hodges 的反转：以前塞，现在挡#

先用一段把原文论点整理出来，方便后面对照。Hodges 的几条要点：

  • 过去 PM 的核心动作是"塞”——时间、人手、优先级都是稀缺资源，所以 feature 要排队、要写 PRD、要过评审；这套流程本身就是 due diligence 的隐式入口。
  • agentic AI 让单个 feature 的开发成本塌缩到一个下午。“morning conceived, afternoon shipped” 一旦成立，backlog 不再是过滤器——以前 PM 借助队列拒绝 feature，现在队列消失了。
  • 竞争压力让团队不敢慢——别人都在用 AI 一个下午加一个 feature，自己不加就显得落后。这种焦虑是 featuritis 的直接燃料。
  • Hodges 举的反例是 Word：在 WordPerfect 时代赢的那个 Word，到 Windows 时代变成了 “bloated and unwieldy”，每个版本都加一些"看上去 marketing sheet 漂亮、但让最终用户更困惑"的 feature。

最直接的一句概括：hard part 从 jamming in 反转到了 keeping out。

为什么这对工程师是同一种压力#

我把 Hodges 这个反转翻译到工程师的语境里，会变成一个更尴尬的问题：

工程师过去最有效的"否决权"，恰好是工作量。

我自己过往否决一个 feature 请求最常用的话术大概是：

  • “这个改动会牵动 X 个服务，请给我两个 sprint。”
  • “现在没人有时间做。”
  • “可以做，但要先做完 Y。”

这些理由的共同前提是：feature 实现是稀缺的、有重量的事情。这个前提就是 Hodges 说被反转掉的那个。当一个 PM（或者更直接，一个 vibe coding 中的工程师自己）能用 Claude Code / Cursor / Codex 在一个下午把改动 PR 出来时，“没时间"这个否决理由的可信度就开始打折——尤其是当对方已经把 PR 摆在你面前。

往下看，pressure 还有另一层：工程师自己也是 feature 的潜在制造者。我之前在 工程化引入 Agentic Workflow 里写过，agentic 模式下 IC 的角色从"代码作者"部分迁移到"agent 编排者 + 验证者”——这条迁移本身就放大了一个风险：当起手成本降到几分钟，我自己也更容易顺手实现一个"其实不该做"的东西。一个下午能让 agent 跑出来的 feature，不需要 PM 来要——工程师 PoC 一下就有了。

所以我现在的看法是：

Hodges 把"挡 feature"写成了 PM 的新难题。但同样的压力波也打在工程师身上，区别只是：PM 失去的是 backlog 这道闸，工程师失去的是工作量这道闸。

两道闸都没了之后，剩下的只有判断力本身。这件事如果只交给 PM 一个角色去扛，大概率扛不住——因为 PR 是从工程师手里出去的，最后一道挡 feature 的机会往往也在工程师这边。

拒绝 feature 的几条工程师视角理由#

那"判断力"具体指什么？我整理了几条自己常用的拒绝理由——不是"该不该做"的 PM 视角，而是"做了之后我维护起来值不值"的工程师视角。这些理由在 AI 时代之前就成立，只是现在更需要主动说出来，因为"工作量"这个隐式理由不再自动起作用。

复杂度预算#

每个软件系统都有一个隐性的复杂度承载量。新 feature 看起来是加法，但落进系统里很多时候是乘法——它会和已有 feature 两两组合、产生新的边角 case。

我做评审时常问的一个问题是：“这个新 feature 和现有的 N 个 feature 两两组合，有几个组合是被显式定义过行为的？“如果答案是"我们没仔细想”，那这次合入实际欠下的是 N 条隐式契约——而下一个修 bug 的人要还。

AI 不替你还这笔债。它能在一个下午写出 feature，但它不会回头帮你把那 N 个组合都梳一遍。

长期维护债#

代码加进来那一刻起，每次重构、每次升级、每次依赖更新都要带着它走。Java 升 25、Spring Boot 升 4 的时候，每多一个用得少的 feature 就多一份回归测试负担——这个负担在 Java 25 / Spring Boot 4 升级笔记 里我已经具体感受过一次。

AI 把"加"做廉价了，但没把"扛"做廉价。删一个 feature 的时候你还是要：通知用户、迁移数据、改文档、删测试、说服自己这次真的能删。这些步骤里 AI 能帮的有限——尤其是"通知用户"和"说服团队"这两步。

心智模型负担#

用户能记住的产品形态是有限的。每多一个 feature，要么用户得多记一件事，要么得多分裂一次心智模型。

Hodges 拿 Word 当例子很贴切——我自己最近想插一个引用脚注，Word 给我开了三个不同的菜单入口（References / Insert / 自定义快捷键），三条路径行为还略有差异。这不是单一开发者的错，是几十年累加的 feature 各自合理、合起来灾难的典型样本。

工程师拒绝一个 feature 的合理理由可以是：”它会让其它 feature 更难解释。“这条理由在 PR 评审里说出来通常会被认真听，但你得先有这个意识去说。

配置面 / 状态空间爆炸#

很多 feature 看上去只是加一个 switch，但实际上是给系统的状态空间乘 2。两个 switch 是 4 个状态，五个 switch 是 32 个——其中很多分支永远不会被真正测过。

这件事在 feature flag 大量出现的项目里尤其明显。我在 Full-stack flag upgrade order 里写过升级顺序的麻烦，那已经是 flag 用得相对克制的项目了。一旦 flag 多到没人能记住 active set，整个系统的可预测性就开始往下掉。

AI 能帮你写 flag 入口的代码，但它不替你回答：”这个 flag 我们什么时候删？"——这个问题不回答清楚就引入的 flag，通常很容易留下来变成永久状态。

撤回成本#

加一个 feature 是几小时；删一个 feature 是几个月。原因不是技术——是用户依赖、合同条款、文档里写过的承诺、客服话术、训练材料里截的那张图。

我会把这条当成"加 feature 的隐性押金"——每个新 feature 都附带一笔将来要付的撤回成本。AI 把首付变小了，但押金没变，甚至因为东西做得更快、用户更早依赖上，撤回成本可能反而更高。

工程师可以主动做的几件事#

上面几条理由本身不够——要在 AI 时代真正承担起这份共同责任，工程师还需要主动做点动作。我目前在做和打算做的几件：

  • 学会写 “we shouldn’t build this” 的 ADR。ADR 不只是用来记录"为什么我们选了 outbox 而不是 AFTER_COMMIT"，它也很适合用来记录"为什么我们决定不做这件事"。负向决策同样会被遗忘、同样会在半年后被人重新提起、同样需要 agent 在下一次迭代时读到。这件事我在 ADR 与 Service Catalog 一起用 里聊过，但当时主要写的是正向决策——负向决策值得有同等地位。
  • 维护一份反向 backlog。不是要做的列表，是已经决定不做、或者打算删掉的东西。这份列表的存在本身就能压一压"再加一个吧"的冲动。
  • PR 评审时把"是否应该存在"列为一类显式 reject reason。code quality、test coverage 都是常见的 reject 维度，但"scope 不该存在"很少被单列出来。这件事如果不显式化，AI 写得越快、评审越来越变成"挑 lint"。
  • 对自己起的 PoC 设过期日。我现在的习惯是：vibe coding 出来的小工具如果两周内没被用上，就主动删掉，而不是让它沉到 repo 里某个 tools/ 目录下变成永久负担。
  • 在 spec 阶段就介入。如果团队按照 Spec Kit 或 SPDD 这类 spec-driven 的流程做事（参见我对 PDD / SPDD / Spec Kit 几条线的对照），那 spec.md / constitution.md 是工程师最该早期插话的入口——比 PR 阶段说"这个不该做"成本低得多。

这些动作不会让团队变慢——它们只是把 due diligence 从 PM 那一侧扛过来一部分。Hodges 把这个责任写给 PM，但我倾向认为这是一份要工程师和 PM 共同扛的责任：PM 看市场视角下的"该不该做"，工程师看维护视角下的"扛不扛得住"。两边都不主动，feature 就会顺着 AI 的低成本管道直接灌进 main。

收尾：feature velocity 不等于产品质量#

回到 Hodges 的那句话：

The hard part will be keeping them out.

我想给这句话补一个工程师视角的脚注：keeping them out 的最后一道兜底门，往往还是 PR review 那一关。更早的 spec / design gate 成本通常更低；但如果前面几道都没拦住，PR review 至少还是工程师能补上的最后一次判断。

AI 时代很容易把 feature velocity 当成产品健康的代理指标——本周合了 X 个 PR、关了 Y 个 issue、ship 了 Z 个 feature——这些数字越好看，越要警惕。至少在我看来，单看这些数字并不能说明产品更好了；Word 的例子更像在提醒我，功能加得越快，越要小心整体可解释性。

至少对我自己来说，AI 时代最值得练的反而是一件"反速度"的能力：在 agent 已经把 PR 写出来、CI 已经绿了、PM 已经说"这个挺好的合了吧"之后，还能停下来问一句"这玩意儿真的该存在吗？"。这句话过去靠工作量替我们说，现在得自己说出来。

参考资料#

文章本体：

我自己的相关笔记：

方法论参考：