当 AI 逼着程序员重新写文档：一篇“告别敏捷”文章戳中了软件业的旧伤口

“敏捷已死”这种标题，放在科技圈并不新鲜。过去十多年里，几乎每隔一阵子，就会有人跳出来宣布 Agile 名存实亡，或者被企业流程彻底异化。但 Lewis Campbell 这篇《Saying Goodbye to Agile》之所以值得聊，不只是因为它骂得狠，而是因为它挑了一个非常微妙的时间点：大模型正在改写软件开发习惯，曾经被敏捷阵营嫌弃的“重文档、重规格、重设计”，居然又回来了。

这件事像极了行业的一次集体回头。很多老工程师看着今天大家认真写 spec、给 AI 喂清晰需求、强调接口定义，恐怕会露出一种略带疲惫的微笑：折腾了一圈，你们终于又走回来了。

敏捷最大的问题，也许是它从来没有被说清楚过

Campbell 的核心批评很直接：敏捷像一场席卷软件业的浪潮，但它始终缺乏一个清晰、可操作、可验证的定义。每当有人质疑 Scrum、站会、敏捷教练、故事点这些实践是否真的有效，总会有人抬出那句经典辩护——“那不是真正的敏捷”。问题是，如果行业里大多数人搞了二十多年，还是没法说明白“真正的敏捷”到底是什么，那这个概念本身就很可疑。

他说得刻薄，却并非没有道理。2001 年《敏捷宣言》确实更像一组价值偏好，而不是工程方法论。它告诉你“个体和互动高于流程和工具”，“可工作的软件高于面面俱到的文档”，这些话读起来很顺耳，也很适合被印在会议室海报上。但真到了复杂项目现场，团队要面对的是需求变更怎么控、架构边界怎么定、质量责任怎么追、客户承诺怎么签。宣言在这些地方给出的帮助，其实相当有限。

更尴尬的是，敏捷后来在企业里往往变成一套宗教化动作：每天站会、两周迭代、燃尽图、回顾会、敏捷转型办公室。软件有没有因此更好交付？有些团队确实受益，尤其是小团队、产品探索型项目和需求高度不确定的场景；但也有大量公司只是把原来的层层汇报，换成了更频繁、更碎片化的汇报。开发者最深的感受不是“敏捷”，而是“会更多了”。

被敏捷塑造成反派的“瀑布”，其实早就不是稻草人了

这篇文章里最有意思的一点，是它提醒人们回头去看历史。敏捷之所以能成为一种时代话语，很大程度上是因为它需要一个反派，而这个反派就是“瀑布开发”。在很多培训和咨询语境里，瀑布被描述成一种僵化、线性、拒绝变化的史前方法，仿佛软件行业直到 2001 年才第一次学会迭代。

但 Campbell 翻出了 Winston W. Royce 1970 年的经典论文。这个常被后人当作“瀑布之父”的人，恰恰在论文里指出了线性开发模式的问题，并主张尽早做原型、持续让客户参与、通过设计和文档逐步澄清需求。换句话说，很多后来被包装成“敏捷创新”的理念，半个多世纪前就已经写在论文里了。

这其实是软件工程史里一个常被误读的细节。所谓“瀑布模型”，从来不是行业唯一真理，更不是 20 世纪软件工程师集体信奉的铁律。Bell 和 Thayer 在 1976 年关于需求工程的研究，也已经明确提到：很多需求问题，只有在设计和实现过程中才会暴露出来。也就是说，迭代发现问题、逐步修正方案，本来就是工程常识。敏捷真正擅长的，未必是发明了这些东西，而是把它们重新包装成了一套更容易传播、更容易卖咨询服务的话语体系。

这也是我看这篇文章时最有共鸣的地方：今天不少企业把“反瀑布”当成政治正确，却忘了真正的敌人从来不是文档、不是设计、不是前期思考，而是僵化、迟钝和脱离现实的管理。把“文档”骂成万恶之源，本身就是一种偷懒。

大模型正在让“写清楚”重新变得值钱

Campbell 文中最有现实意义的判断，是他把这一轮“告别敏捷”的情绪，与 LLM 带来的开发变化联系了起来。他认为，廉价且能力强大的大模型，正在迫使软件从业者重新写规格说明。这个观察很重要。

过去几年，AI 编程工具从 GitHub Copilot、Cursor 到各类代码代理，已经把一个事实摆到桌面上：如果你的需求表达模糊，AI 就会一本正经地帮你胡说八道。它可以很快生成函数、接口、测试样例，甚至重构一段系统模块；但前提是，你得先把问题说清楚。输入越含糊，输出越像“看起来很努力，实际上全错”。

于是，一个颇有讽刺意味的场景出现了：曾经被敏捷口号压低优先级的文档工作，反而成了 AI 时代最实用的生产力基础设施。PRD、技术设计、接口协议、状态机定义、验收标准、边界条件说明，这些东西不是官僚主义残余，而是让人和模型都能理解同一件事的共同语言。

敏捷曾强调“Working software over comprehensive documentation”，很多团队把它简化成“不用写那么多文档”。可大模型给出的现实教育是：没有足够清晰的文档，往往也不会有真正可靠的 working software。你可以把这理解为一种行业纠偏。不是文档战胜了代码，而是大家终于重新承认，设计、规格和实现本来就是一体的。

在这点上，Campbell 引用 Royce 那句老话非常到位：在编码开始之前，文档、规格和设计其实说的是同一件事。如果文档很差，设计通常也不会好。放到今天，这句话简直像是写给 AI 编程时代的。

敏捷该被扔进历史垃圾桶吗？我看没那么简单

不过，Campbell 的结论也有点“怒气值拉满”的成分。他主张把 Agile 扔进历史垃圾桶。我理解这种情绪，但未必完全同意。

敏捷的问题，从来不只是理念空泛，而是它被企业制度和培训产业过度消费。很多组织引入敏捷，不是为了更快验证产品、缩短反馈链路，而是把它当成一种绩效管理工具，或者一种显得自己“现代化”的公司仪式。这就像健身房里最贵的年卡，不代表你真的更健康。真正糟糕的不是迭代、回顾、跨职能协作这些方法本身，而是它们被模板化、教条化了。

换句话说，敏捷不是完全没价值，而是它的黄金时代叙事已经结束了。今天的软件开发比 2001 年复杂得多：云原生、微服务、DevOps、平台工程、SRE、开源依赖、AI 代理协作，哪一个都不是《敏捷宣言》能直接回答的。再加上监管、隐私、安全、模型治理这些现实压力，单靠“拥抱变化”四个字显然不够。行业需要的是更具体、更可执行的工程纪律，而不是继续围着一个含糊口号打转。

这也是为什么“Spec-Driven Development”最近越来越常被提起。它未必会成为像敏捷那样席卷全行业的新旗号，但它抓住了一个很朴素的事实：当软件由更多人、更多服务、更多模型共同完成时，明确的规格就是协作的地基。你可以不迷信文档，但你很难在复杂系统里长期逃避它。

这场争论真正有价值的地方，是让软件业重新尊重工程

我觉得，这篇文章最值得转发的，不是“敏捷已死”这四个字，而是它背后的提醒：软件行业这些年太爱追逐新口号，反而容易忽略那些朴素但有效的工程原则。需求要澄清，设计要推敲，原型要验证，客户要持续参与，文档要能支撑协作——这些听上去一点都不性感，甚至没有“敏捷转型”“AI 原生开发”那样适合做大会标题，但它们才是真正能让项目少翻车的东西。

从这个角度看，大模型也许反而帮行业完成了一次去神话。它没有消灭程序员，也没有让软件开发变成纯自然语言许愿机。它只是非常残酷地放大了一个事实：你表达不清，就做不对；你规格含糊，系统就会失控；你没有想清楚边界，AI 只会更快把错误扩散出去。

这让我想到一个更有意思的问题：未来的软件团队，核心竞争力会不会从“谁写代码更快”，转向“谁定义问题更准确”？如果答案是肯定的，那么敏捷时代那种对正式规格若即若离的态度，恐怕真的要退场了。下一代优秀工程师，可能不只是会写代码的人，更是会写清楚的人。

软件业当然不必回到厚厚一本需求说明书、半年不改一版的老路上。没人怀念那种把变化视为敌人的时代。但在 AI 时代，行业确实正在重新学会一件老派却珍贵的事：在动手之前，先把话说清楚。这个动作看上去不酷，却比任何管理学流行词都更接近软件工程的本质。