凌晨两点，你盯着白板上的"用户注册API"六个字发呆。需求就这么一句话，但你知道真正的坑在后面：字段校验规则是什么？并发冲突怎么处理？错误码该返回400还是409？
这不是写代码，这是猜谜。
传统测试驱动开发（TDD）假设你清楚自己要造什么。但现实中，需求文档往往比程序员的心情还飘忽。更麻烦的是无服务器架构——Lambda函数、API网关、DynamoDB表、IAM权限，这些云服务的"依赖"没法像单体应用那样轻松模拟。
最近一种做法在圈内悄悄流行：用AI把模糊需求变成可执行的详细规格，再用规格驱动测试和代码。说白了，让AI先写"考试大纲"，你只管答题。
为什么传统TDD在无服务器场景卡壳
经典TDD循环很简单：写失败测试→写代码通过→重构。这套玩法在确定性强的问题域里跑得通，比如实现一个已知算法的排序函数。
但"实现用户注册"完全是另一回事。你需要决定：邮箱格式用RFC 5322还是宽松校验？密码最小长度8位还是12位？用户名唯一性冲突返回什么错误体？这些不是技术问题，是产品决策。
常见的三种应对方式各有硬伤：
开长会讨论细节——时间黑洞，且会议结论常随人员变动蒸发；
写厚文档——写完没人看，看了不更新，更新不同步；
直接写代码让代码成为规格——三个月后人走茶凉，新接手的工程师对着魔法数字和隐式规则抓瞎。
无服务器让情况更糟。你的Lambda可能在冷启动时超时，API网关的映射模板可能把JSON转义搞砸，DynamoDB的GSI设计可能让查询成本爆炸。单元测试里的mock能骗过自己，骗不过AWS的真实行为。
云集成测试必须跑，但慢且贵。一个完整的CI/CD流水线如果每次提交都跑全量云测试，账单比程序员加班打车费还刺激。
规格驱动：在需求和代码之间插一层"可执行合同"
规格驱动开发（Spec-Driven Development）的思路是把"规格"做成一等公民。不是Word文档里的静态描述，而是机器能读、能验、能生成衍生产物的结构化定义。
成功路径、错误条件、数据格式、业务约束，全部显式声明。这份规格同时服务于多方：测试框架拿它生成用例，文档工具拿它生成API参考，客户端生成器拿它产出SDK，实现代码拿它当验收标准。
OpenAPI是最接近大众认知的例子，但纯OpenAPI有个局限——它描述的是"接口长什么样"，而非"业务规则是什么"。比如"用户余额不能为负"这种约束，OpenAPI本身表达不了，需要额外的规格层补充。
关键突破在这里：AI可以帮你写这份规格。
不是简单地把"做个注册接口"扩写成废话文学，而是基于API设计模式、AWS最佳实践、以及你现有代码库的隐式风格，产出可直接落地的详细规格。包括字段级别的校验规则、错误码枚举、并发控制策略、甚至CloudFormation资源的配置建议。
这改变了TDD的启动方式。以前是"我不知道测什么，先写个大概"，现在是"规格已经定义了所有边界条件，我只需要实现让测试通过的最小代码"。
模糊性被前置消化，编码阶段的认知负担骤降。
AI生成规格的实际操作与边界
具体怎么玩？典型流程分三步。
第一步，用自然语言描述高层需求，同时喂给AI上下文——现有系统的API风格、团队的技术栈约束、合规要求（比如GDPR的数据驻留规则）。AI输出第一版规格草案，通常是结构化的YAML或JSON，包含端点定义、模型schema、错误场景枚举。
第二步，人工审查和迭代。AI会漏掉业务特有的隐式规则，比如"同一手机号24小时内最多发3条验证码"这种运营策略。工程师需要把这类约束补进规格，形成最终版。
第三步，工具链接管。规格自动生成：①单元测试框架的stub；②集成测试的Pact契约；③API文档；④客户端SDK骨架；⑤基础设施即代码的初始模板。
编码阶段回归经典TDD红绿循环，但测试用例已经由规格预生成，不再靠工程师临场发挥。
这套打法对无服务器场景尤其解渴。Lambda的输入输出格式、API Gateway的集成响应映射、DynamoDB的键设计，这些云特有的细节可以被编码进规格模板，AI生成时自动套用。工程师不用再翻AWS文档查"Proxy集成和Lambda集成到底区别在哪"。
当然，边界也很清晰。AI生成的是"基于模式的最佳实践推测"，不是"业务真相"。如果需求本身包含创新性的交互设计，AI只会复读常见套路，需要人工打破路径依赖。安全敏感规则（如权限模型的最小特权原则）也必须人工审计，不能全托给机器。
本质上，AI在这里扮演的是"经验压缩包"——把社区积累的设计模式、AWS的运维教训、团队的既有约定，快速注入到新项目中。它不负责创新，负责把重复决策成本压到接近零。
对于25-40岁这个区间的技术从业者，这种分工很对味：把机械劳动交给机器，把脑力留给真正需要判断的地方。不是"AI取代工程师"，是"AI让工程师早点下班去干更有意思的事"。
无服务器架构的复杂性不会消失，但可以被规格层隔离。当云服务的配置细节、接口的边界条件、测试的覆盖策略都被显式声明并版本控制，团队获得了两种能力：一是新人 onboarding 时不必在代码里考古，二是变更影响范围可静态分析，而不是靠上线后报错发现。
这大概是TDD在2020年代该有的样子：测试仍然驱动开发，但驱动的方式从"边写边想"变成了"先想清再写"。AI不是让TDD变得不必要，而是让它终于能在复杂场景下跑起来了。
热门跟贴