这听起来像捷径吗？对我来说是的。在这个行业职责了25年多，它如实让我联思到一些东西。它看起来与瀑布法子如斯一样，仅仅当今有了AI的匡助。但我认为今天它与30年前的瀑布法子有着一些相通的时弊。

在Martin Fowler的一篇经典著述《缱绻已死？》中，他磋商了"计较缱绻"和"演化缱绻"之间的辞别。SDD嗅觉像是回到了计较缱绻。它假定咱们不错在构建系统之前了解对于它的一切。

在职何范围可不雅的神气中，你唯有起原编码时才会发现着实的不容。要是你的神气小到不错放入LLM的潦倒文窗口，SDD可能灵验。对于其他一切，翔实的规格确认最终会撞上未预见的时刻实践的墙壁。

1、"简便"功能的陷坑

当我在2000年起原职责时，敏捷正在兴起。它造就咱们一个粗暴的真相：短迭代是拿获无理假定的惟一法子。SDD假定咱们不错在构立功能之前了解对于它的一切。

让咱们思象一个咱们系统中极端常见的任务：处理一个新的支付webhook。

它看起来很简便。你为你的AI智能体写一个昭着、精准的规格确认。以下是咱们不错写的一个直率节录：

- 创建一个POST端点 /webhook

- 从JSON负载中索要 order_id，不然复返400 Bad Request。

- 在数据库中查找订单，要是不存在则复返404 Not Found。

- 将其现象更新为'PAID'（pay_type_id = 3）——触发'ReceiptEmail'类。

AI十足按照你的要求作念了。它写出了干净的代码，效用你的AGENTS.md和测试。你将其部署到你的预发布环境。你嗅觉终点高效。

然后，实践打击了你。

你作念一个手动集成测试，坐窝瞩目到客户收到了三封收条邮件。发生了什么？你调试代码并刚毅到支付提供商欲望在500毫秒内收到 200 OK 反馈。要是莫得收到，它会重试。你的端戳破耗了600毫秒，因为它是同步发送邮件的，大要因为预发布管事器很小，被其他斥地东谈主员的职责挤满了。

完好意思的规格确认莫得酌量到收集延伸、重试或竞态要求。为了耕作它，你当今需要转向。你刚毅到你需要一个十足不同的经由：

一个不错存储负载以便稍后处理的队伍，独立即复返 200 OK。

一个后台程度来异步更新和发送邮件。

一个幂等键来防护重迭。

你本来的规格确认当今没用了。开动代码必须被毁灭。你唯有通过与环境的本色交互才发现了着实的架构需求。

虽然，AG中国手机官方网页版这仅仅一个例子，但它展示了一个简便的任务若何容易变得复杂。是的，我知谈你们中一些读者会认为我方会作念得更好，认为我方应该了解架构，经典的"你作念错了"。好吧，让我告诉你，莫得东谈主知谈一切，连LLM也不知谈。你的团队也不是充满了能揣度每个可能旯旮情况的高档工程师。

2、Token税 vs. 重构税

有了AI，事先缱绻引入了一个新的经济问题：Token税。

你花了token来讲解Webhook规格确认。你花了token来生成有时弊的代码。当实践迫使你转向时，天博体育(TBSports)官方网站你又付了一次税，向AI讲解队伍、后台职责者和幂等性。这是低效的。

我更可爱将这些token投资于 重构税。从小处起原。让AI构建一个简便的宗旨考据（POC），只记载传入的负载。运行它。不雅察提供商的本色行动。一朝你了解了实践，使用AI来捏续重构——索要邮件逻辑、添加队伍并在过程入彀帐代码。这保捏代码库健康，并让架构当然地泄露。

3、舆图，而不是蓝图

当我写缱绻文档时，我可爱Simon Brown（以C4模子着名，这是一种友好的软件架构图表法子）的Google Maps类比。

你需要邋遢来看潦倒文。你不需要一张自大每一根草的翔实舆图。

恶运的缱绻文档（SDD立场）：

WebhookController将理会JSON，考据签名，更新MySQL中的 status 列，并实例化Mailer管事。

好的缱绻文档（Fluid立场）：

支付事件通过webhook接收并甩掉在队伍上。后台职责者处理订单履行和邮件分发，以确保幂等性。

存眷迫切的决策。为什么咱们使用队伍？这些模块若何解耦？将逐行达成留给代码。

4、使用适合度函数，而不是章程

要是你莫得翔实的规格确认，若何防护AI制造零散？你使用适合度函数。

适合度函数是自动化的治理。你不是在文本辅导中要求AI"请保捏HTTP层与领域解耦"。你写一个强制实践此要求的架构测试。我曩昔评论过这个，比如在这篇著述中。

咱们若何防护前边的情况发生？咱们写一个快速测试，当像 ReceiptEmail 这么的慢速管事胜利在HTTP限度器中使用时立即失败（可选地，咱们不错在管事层本人进行快速查验，要求在后台任务中才调赓续）。

你不是在写规格确认；你是在建设一个硬范围。畴昔的规格确认不再需要记念这个问题。AI不错在这些墙壁内解放探索和编写代码；当其POC中抛出相宜的无理音尘时，它会自动转向。

瞩目：有些东谈主认为测试驱动斥地不错用于这些场景。我不太喜悦。我发现TDD过早地固定了你的达成；它终点适宜袖珍bug耕作，但在探索新功能并需要喘气空间时就不那么好了。但那是另一个话题。

5、我现时的谜底：Fluid Design

那么，SDD的替代决议是什么？我可爱称之为Fluid Design。

缱绻文档，而不是规格确认： 只记载高层决策、范围和形状。

主动原型缱绻： 不要章程处理决议。向AI相关达成选项。构建小的POC来测试未知身分（如webhook延伸），然后再承诺于某个架构。

及时更新： 将你的缱绻文档视为活记载。每次你在代码中发现新的照顾时，更新文档。

你是船主： 你掌舵。你不是把舆图交给AI然后去睡眠。你字据代码告诉你的信息及时转移航向。

归根结底天博体育(TBSports)官方网站，惟一迫切的规格确认等于代码。其他一切齐仅仅揣摸。勤俭单起原，捏续重构，让你的架构当然演化。