没有什么东西是死的

SaaS已死。敏捷已死。MCP已死。RAG已死。如果你最近在关注人工智能工程或软件行业的商业动态，一定见过诸如此类的标题。每一个都斩钉截铁地宣称某种说法，却既不说明真相，也忽略了究竟发生了什么变化、以及这些变化会影响到谁。

37signals曾就“战争式语言”提出过类似的批评，而我想把同样的批评延伸到那些“X已死”的标题上。我还有一点小小的担忧：AI模型似乎也在模仿这种表达方式，不过这倒是个次要问题。

工作不是战争

37signals的企业原则第二条名为“工作不是战争”：

企业用语中充斥着战争的隐喻。公司要“征服”市场，要“抢占”用户心智份额，要“锁定”客户，要部署销售“部队”，要聘请“猎头”，要“击溃”竞争对手，要“挑选”战场，并从中“大赚一笔”。这是一种极其糟糕的范式，我们不愿与之为伍。工作不是战争。我们以和平之心而来。

“范式”一词恰如其分，因为一种隐喻会带来一整套看待工作的视角。如果把商业比作战争，那就必然有人失败，而他们的损失就成了胜利的代价。

软件领域也不乏这类词汇：作战室、久经考验、砍掉某个功能。我本人也曾使用过这些词，因为大家都这么讲；但我宁愿避免。若要补充一条，那就是近年来关于AI最常见的一句话：“X已死。”

“已死”省略了什么

在AI工程和商业写作中，“讣告式”文章已成为一种常见的文体。一项技术往往能火上一年，随后便被更新的技术取代，于是相关文章纷至沓来——近来多见于讨论MCP和循环工程。

接着，这种套路又蔓延到那些已存在数十年的概念，比如SaaS和敏捷开发。

这些标题从字面上看都不成立——毕竟今夜仍有无数系统在生产环境中运行着它们。但更大的问题在于，“已死”这一表述过于笼统。一次变化，哪怕再重大，也未必就能彻底否定某项工具、某种实践或一种商业模式。

长上下文窗口改变了系统的检索需求量，却并未否定检索本身的必要性。编码代理改变了代码的编写者，但依然需要有人验证代码是否符合预期。

因此，这类表述恰恰遗漏了读者最需要的信息。更具体的表述可能是：“借助长上下文，我们在小规模文档集上可以弃用检索模块”，它明确了变化的内容、适用范围以及具体哪些环节被取消。

你可以据此判断，或者发现它并不适用于自己。“RAG已死”则直接给出了一个结论，而结论一旦给出，评估也就戛然而止，甚至还没来得及付诸实践。

有人可能会辩称，没人会把“RAG已死”当真。这本来就是一种惯用的标题写法，你大概会把它理解为“炒作过度”或“正在衰落”。这话没错，我也承认。

即便将其视为夸张，这样的标题仍传递出一种笃定的语气，而正是这种笃定感才让观点得以广泛传播。

我在敏捷开发上亲眼目睹过这种先下结论后跳过评估的现象，因为我至今仍在使用它。大多数“敏捷已死”的文章矛头指向各种仪式和认证，其中不少批评确实有道理。

对此我无意辩护。我所坚持的是那份宣言中的理念：短反馈周期、用可运行的软件代替关于软件的文档、响应变化而非遵循计划。我把这些理念视作精益思想（消除工作流程中的浪费）的一种体现：一种思维方式，而非一套必须照搬的流程。

这些理念同样适用于编码代理的工作方式。我见过代理在小步迭代、持续交付以及反馈驱动下规模化运作。这正是敏捷精神在每个变更上的应用，而非局限于两周一次的迭代。

“敏捷与代理配合得好吗？”是个好问题，答案因团队而异。“敏捷已死”却直接绕过了这个问题。如果当初我信了那句话，恐怕就会丢弃支撑整个代理工作流的核心理念。

大规模的邓宁-克鲁格效应

邓宁-克鲁格效应源自贾斯汀·克鲁格和大卫·邓宁在1999年发表的一篇论文。他们发现，在某一领域技能越匮乏的人，往往越高估自己的能力。

当然，这一结论并非毫无争议：吉尼亚克和扎延科夫斯基在2020年指出，这更多是一种统计学上的伪象。在此我只是借用这一术语来描述一种现象，而非将其视为定论。

这种现象具有双向性。在写作端，宣布某事物“死亡”可谓轻而易举。你无需亲自在生产环境中运行过RAG，就能断言它已死；而且实践经验越少，就越容易笃定。

这正是邓宁-克鲁格效应的表现。与此同时，来自实际使用者的详细报告却很难浓缩成一个引人注目的标题。于是，那种充满自信的说法更容易传播，而基于事实的声音反而被淹没。

在阅读端，一个盖棺论定的结论可能让你误以为自己已洞悉全局，却缺乏足以辨别谬误的细节。这种认知会被带入规划会议或招聘对话中。

单个过度自信的人尚属寻常，但如果每个读到这类标题的人都如此，那么信心便会扩散，而真正的知识却滞留在原地。

有时事物的确会终结

Python 2于2020年1月1日停止维护，Adobe也在同年年底终止对Flash的支持。即便如此，还是有更为平实的措辞：“退役”。它表明是有人主动关闭了某项服务，从而便于追问何时关闭、以及由何替代。

“已死”固然更简洁，但它终究是一种隐喻，传达的信息远不及“退役”详尽。

在软件领域，“已死”也有其确切的用法：死代码、死信队列、死链接。这些术语指代的是真实存在的机制，且依然有效。类似“jQuery已死”的标题甚至能给初学者选技术栈时提供有益参考：别从这里入手。

但说“不要用jQuery启动新项目”同样能传达这一信息，且没有虚假成分。

无论是发生变化还是走向终结，准确的表述都应明确：发生了什么，以及你是调整了它，还是用其他方案替换了它。

不妨这样表述

这些文章大多本可以更有价值，只要把隐藏在其下的本质呈现出来：一个问题、一项建议或一场论证。“敏捷与代理配合得好吗？”这样的问题，以及“如今SaaS领域的关键差异化因素”这样的建议，都在邀请读者自行评估。

而“什么时候MCP才是合适的集成方案？”“循环工程在哪些场景奏效，又在哪些场景失效？”之类的标题，则针对代理工作提出了同样的思考。

“敏捷已死”则以十足的自信给出了一个错误的结论。

在正文中，同样适用以下原则：

• 当某事发生变化时：“Y改变了X的运行方式，因此我们对其进行了调整”，或“Y使X不再适用，所以我们用Z取而代之。”
• 当某事终结时：“我们已于[日期]将X退役”，或“X在Z取代它时被退役。”
• 当某事不再流行时：如实说明，或干脆不提。
• 始终明确：该变化适用于哪些对象。

这并非语言审查。“已死”并不冒犯，只是未能传递读者做出判断所需的关键信息。

一个较小的担忧

模型通过学习我们的内容来提升写作能力，为此我做了一个小实验。我让Claude根据十个仅含主题的提示各生成三篇文本，并对结果进行标注。

这些提示只包含格式和主题，例如：“写一篇关于RAG的简短评论。”

每个提示共生成9篇，总计90篇。其中18篇采用了“已死”的框架，主要集中在RAG（九篇中有六篇）和初级开发者岗位（九篇中有六篇）。

另有六篇提示未产生任何此类结果。按模型划分，Opus在其30篇输出中使用了11次，Sonnet使用了7次，Haiku则一次未用。

多数命中结果是否定句，通常出现在标题中：“RAG并未死亡，只是你的检索做得不好。”“初级开发者并未消失，只是职位描述变了。”还有三篇要求读者停止询问“RAG是否已死”。

唯一的例外是SaaS，Opus在其三次生成中均使用了“座位已死，成果万岁”这一表述。也就是说，这些输出虽在内容上反对“已死”的说法，却仍将它写进了标题。

这只是单一供应商、每个提示三次生成、且由Claude自身标注的结果，因此不同来源的数据可能有所差异。我对此只是略有担忧，并未感到惊慌。

只有像这样跨供应商、长期重复的测试，才能让我们进一步了解情况。

动笔之前

下次当你准备写下“X已死”时，请先写出它背后的真实含义：发生了什么变化、适用于哪些对象，以及你是调整了它，还是用其他方案替换了它。

如果你们团队有AI助手代写文案，不妨将这条建议纳入他们的风格指南。