氛围编程的蜜月期结束了

你刚用三小时搭完一个用户系统，成就感爆棚。十八个月后，你正在第三次重构同一个模块——这次是因为安全审计发现密码哈希迭代次数不一致，而你已经找不到当初为什么要选bcrypt 10轮还是12轮。

这不是技术债，是技术雪崩。而且是以机器速度发生的。

氛围编程的甜蜜陷阱

用自然语言描述需求，看着AI生成代码，确实爽。原型从几天压缩到几小时，这是真红利。但LLM有个致命盲区：它没有上周的架构决策记忆，不知道团队约定的安全边界，更不关心六个月后的代码健康度。

它只优化当前提示词。每一次。

生成的代码单看都合理，但系统层面逐渐失序：业务逻辑渗进HTTP处理器，分层混乱，安全规则有的地方执行有的地方漏掉。你得到了"能跑的代码"，代价是全局一致性。

转折点通常出现在三个时刻：招第二个工程师、第一次合规审计、第三次重构同一模块。

规范驱动开发：不是流程，是纪律

规范驱动开发（Spec-Driven Development，简称SDD）不是什么新框架，也不依赖特定工具。核心就一条：在提示AI生成代码之前，先写一份机器可读的规范，并且每次生成调用都把它作为上下文喂进去。

道理朴素到可笑：AI模型的输出质量完全取决于输入上下文。给它一份结构良好的规范——领域边界、分层规则、安全要求、验收标准——它就能生成真正属于这个系统的代码。给它模糊的提示，你得到的是"看起来能跑但不知道能不能 fit"的代码。

关键认知：每次AI代码生成调用都是无状态的。模型不会记得你为订单服务选了事件溯源，也不会记得团队禁止HTTP层直接访问数据库。没有持久化规范供AI读取，每次会话都在冒险否定之前的决策。

从"氛围提示"到"规范锚定"的对比

看看差距有多具体。

氛围版提示："帮我建个登录接口。"

规范锚定版：

「上下文：@requirements.spec.md @domain-model.spec.md @architecture.spec.md

任务：在应用层实现LoginUseCase。

- 必须满足NFR-SEC-01（bcrypt≥12轮）、NFR-SEC-02（限速5次/分钟）

- 必须触发AuthenticationAttempted领域事件

- 禁止引入基础设施层——仅使用IUserRepository端口

- 同步编写单元测试

禁止生成控制器、路由或HTTP类型。」

AI不再是自由发挥，而是在执行工程师写的计划。安全规则是约束条件，不是事后补丁。分层边界是指令，不是建议。

工具组合：Kiro与Claude的分工

目前有两款工具从互补角度切入SDD，配合起来能覆盖从规范编写到代码生成的完整工作流。

Kiro的定位是"规范优先的IDE"。它把规范文件当作一等公民，提供结构化编辑、版本关联、与代码生成的紧密集成功能。你在Kiro里写的规范不是文档，是活的生产资料——每次代码生成自动引用。

Claude则通过扩展上下文窗口和工具调用能力，成为规范的执行引擎。它能读取多份规范文件，理解其中的约束关系，并在生成代码时主动检查合规性。

一个管"写规范"，一个管"按规范执行"。

为什么现在必须认真考虑这个切换

氛围编程的边际收益正在递减。早期项目简单，AI的局部优化不会暴露系统性风险。但一旦进入团队协作、合规要求、长期维护阶段，"快"的代价就会复利式显现。

规范驱动不是让你变慢，是把速度从"原型阶段"迁移到"可持续交付阶段"。前期写规范确实多花时间，但省掉的是十八个月后的第三次重构、安全审计的紧急补丁、新成员 onboarding 时的架构考古。

更隐蔽的收益：规范成为团队共识的物化载体。架构决策不再只存在于某个工程师的脑子里，也不散落在 Slack 线程和会议纪要的废墟中。它是可版本控制、可 diff、可自动化验证的。

落地建议：从单点试验开始

不需要推翻现有工作流。选一个边界清晰的新模块——比如支付相关的核心领域——尝试完整走一遍SDD流程。

第一步：用Markdown或专用格式写三份基础规范（需求、领域模型、架构约束）。

第二步：在提示词中强制引用这些文件，观察AI输出的稳定性变化。

第三步：建立规范与代码的同步检查机制——可以是简单的CI脚本，验证生成代码是否违反了规范中的硬性约束。

跑通一个模块后，你会对"可预测的生产力"有体感。那时候再决定要不要扩大范围。

氛围编程把你带到了这里。但接下来能不能走得稳，取决于你愿意在"指定"上投入多少纪律。AI不会替你做架构决策，它只会放大你决策的质量——或者混乱。

你现在的代码库里，有多少"当时觉得能跑"的决策，正在成为明天的重构理由？