前两篇建立了一个判断：方法论更替的驱动力是成本。当成本结构变了，一些"正确但太贵"的实践会重新变得经济。
这篇聊一个具体的例子。
过去十年，User Story 几乎成为需求表达的默认语言。
作为一个[角色]，我想要[功能]，以便于[价值]。验收标准：……
简洁，轻便，写起来快，改起来也快。在需求快速变化、需要频繁试错的环境里，它比 RUP 时代的用例文档好用得多。
这是一个合理的取舍。
但取舍意味着有东西被放弃了。
User Story 放弃了什么？
用一个例子来说。
"顾客购买商品"——这句话能说清楚正常情况下发生什么：浏览、加购、下单、支付、收货。
但如果你把这句话交给一个需要独立完成整个流程的 Agent ，它还需要知道更多。
库存不足怎么办？
支付失败怎么办？
用户没有收货地址怎么办？
优惠券在支付过程中过期了怎么办？
用户同时下了两笔订单，库存只够一笔怎么办？
这些"如果出了问题怎么办"的信息，User Story 选择性地省略了。
这不是 User Story 的设计缺陷。在那个时代，这是一个正确的决定。
敏捷面对的核心挑战是反馈速度。先把正常路径做出来，上线看效果，异常路径遇到了再补。在"试错成本低"的环境里，先说清楚正常流程，性价比最高。
但 Agent 改变了一件事。
当 Agent 需要独立执行一个带着分支和例外的任务时，它面对的不再是一个"可以边做边补"的环境。它在开始执行之前，就需要知道完整的路径——包括哪些地方可能出错，出错了应该走哪条路，哪些边界条件绝对不能踩。
Agent 需要的，恰恰是 User Story 当年选择省略的那些东西。
这就是为什么用例（ Use Case ）最近又开始被讨论。
不是因为它是一种更好的文档格式。
而是因为它的结构里，天然携带了 User Story 省掉的那部分信息。
一个标准用例不只是写"正常情况下做什么"。它逼你同时回答三件事——
主流程：顺利的情况下，步骤是什么？
备选流程：某一步走了另一条路呢？
异常流程：某一步失败了呢？
"库存不足怎么办"和"支付失败怎么办"不是事后补丁。在用例的结构里，它们和主流程是同等地位的组成部分。
不是"这个系统有什么功能"。而是"这个系统在所有情况下会怎么做"。
我后来越来越觉得，它们其实都在描述同一种东西：行为（ Behavior ）。
这里值得多说一句。
用例并不是唯一一种表达行为的方式。BDD 的 Given/When/Then 在做类似的事。状态机也在做类似的事。
它们各自在不同时代、从不同角度，试图解决同一个问题：如何把系统的行为完整地表达出来。
用例只是其中最早被大规模使用、也最早被大规模抛弃的一种。
被抛弃的原因，前两篇其实已经说过了。
不是因为它想表达的东西错了。而是因为维护这种表达的代价太高。
RUP 时代，用例写完之后，相关的 UML 图、设计文档、测试计划都需要人工同步更新。需求一变，整套制品跟着变。维护成本极高。最终代码更新了，文档没更新——系统和对它的描述逐渐分裂。
压垮用例的，从来不是互联网，不是敏捷，不是"太重了"这种模糊的批评。
是维护成本。
前篇说过一句话：很多实践是"正确但太贵"的。用例就是典型案例。它想做的事情——把行为完整地表达出来——不是错的。但在当时的技术条件下，保持这种表达的同步更新，代价高到了不可持续。
那么今天呢？
Agent 开始具备协助完成这些工作的能力，例如文档同步、变更分析、测试生成、一致性检查。
AI 开始让这些工作第一次具备自动化的可能。
这些恰恰是用例当年被压垮的原因。
这不是说 Agent 今天已经能完美地做这些事，远没有。但它第一次让"保持行为描述与系统实现的一致性"这件事，具备了自动化的可能性。
用例曾经失败的主要原因——维护成本——正在被削弱。
AI 并没有证明用例正确。它只是削弱了用例当年失败的主要原因。
但这里需要说清楚一件事。
用例是不是 AI 时代的最终答案？大概率不是。
Agent 真正需要的，不是某一种特定的格式。
它需要的是行为信息——系统在所有情况下会怎么做。
用例只是人类曾经发明过的一种行为表达方式。BDD 是另一种。状态机是另一种。也许未来还会出现新的形式。
真正值得关注的，不是哪一种格式会赢。
而是"行为"这个维度本身——当 Agent 开始独立执行任务，我们对它说清楚"做什么"已经不够了。我们还需要说清楚"在各种情况下应该怎么做"。
这个需要，以前被实现成本遮住了。
现在它正在暴露出来。
下一篇，我想聊一件更危险的事。
如果 Agent 完全按照你的描述执行，而你的描述本身就是错的，谁来发现这个错误？
最后留一个问题。
你给 Agent 的指令里，包含"如果出错怎么办"的信息吗？
如果没有，你有没有观察到它自己猜错了的时候？
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.