从氛围编程到规范驱动开发

鹿Sir上线，见字如面。

2025 年的今天，当你打开 Cursor、Codex 或国内的通义灵码，只需几句自然语言描述，AI 就能快速生成代码片段甚至完整模块——这种被 Andrej Karpathy 称为 “氛围编程（Vibe Coding）” 的开发模式，正以惊人的效率改变着软件开发的面貌。Y Combinator 报告显示，W25 届初创公司中 25% 的代码库 95% 由 AI 生成，零基础产品经理也能 “写” 代码的场景已成为现实。

然而，当热潮褪去，越来越多开发者发现：那些 “看起来能跑” 的 AI 代码，正在生产环境中暴露出致命问题。从个人原型到团队协作，从快速验证到长期维护，氛围编程的 “自由” 正在催生新的技术债务。

此时，规范驱动开发（SDD，Spec-Driven Develop）的崛起，为 AI 编码从 “灵感创作” 走向 “工业生产” 提供了关键解法。

氛围编程的核心魅力在于 “即时反馈”——开发者用模糊指令（如 “优化登录模块性能”“拆分复杂函数”）与 AI 互动，无需深入思考架构细节，就能快速获得可运行的代码。

这种模式特别适合周末原型开发、小型工具构建，或是验证初期产品想法，让开发流程变得像 “搭积木” 一样轻松。

但随着项目规模扩大，氛围编程的三大痛点逐渐凸显：

“把 observe 函数拆分一下，职责太多了”——当你给出这样的指令，AI 会迅速生成拆分后的代码，甚至告诉你 “单元测试已通过”。可联调时却发现：本应剥离的上下文管理逻辑被硬塞进 agent 内部，临时状态意外存入持久化存储，action_plan 莫名混入 observation 结构。

问题根源在于意图理解偏差：AI 基于概率模型选择 “最可能正确” 的实现方式，却无法真正理解你的架构设计目标。正如某团队重构实践所示，前两次未加规范约束的重构耗时两周仍未解决核心问题，反而让模块耦合度越来越高。

鹿Sir本想在一周内用Qoder搞定订单服务-价格计算的V2版本重构，没曾想，2300的Credits用完了还是让我不满意，其实这里就是Vibe Coding作祟，让AI没办法写出企业级代码。

氛围编程生成的代码往往缺乏设计文档与注释，开发者难以追溯 AI 的设计决策。据传，当项目依赖 AI 生成代码超过 60% 后，新人接手时需要花费 3 倍时间梳理逻辑，代码审查效率下降 50%。

更严重的是，AI 可能引入 “隐性漏洞”——如硬编码密钥、未过滤的 SQL 注入风险，这些问题在快速迭代中不断累积，最终成为生产环境的定时炸弹。

当多个开发者用氛围编程协作时，代码风格、接口设计、错误处理方式会因个人指令差异而混乱。

我一朋友亲身经历，他经手的电商项目在迭代 3 个版本后发现：同一功能存在 7 种不同的异常处理逻辑，跨模块调用需要适配 4 种接口格式，团队不得不暂停新功能开发，花费两周时间进行代码统一。

面对氛围编程的局限，规范驱动开发（SDD）以 “先定义规则，再生成代码” 的核心理念，成为 AI 时代软件工程的新范式。其本质是将 “意图（Intent）” 转化为 “形式化规范（Specification）”，让 AI 在明确约束下生成可预测、可维护、可验证的代码，实现从 “代码优先” 到 “规范优先” 的转变。

• 可控性提升：规范成为 AI 与人类的 “契约”，GitHub 数据显示，使用 spec-kit 的项目首次实现准确率达 95%，远高于氛围编程的 “能跑就行”。

• 质量保障：通过前置定义测试标准、安全要求、性能指标，SDD 将质量控制融入开发源头，某金融团队实践显示，AI 生成代码的缺陷密度下降 62%。

• 可维护性增强：规范作为 “活文档” 随项目演进更新，架构决策、业务规则被显式记录，新人上手速度提升 70%。

• 协作效率优化：产品经理、设计师、测试人员可通过规范提前对齐需求，减少返工率，某 SaaS 公司需求变更成本降低 45%。

2025 年，SDD 工具已形成完整生态，覆盖从个人开发到企业级协作的全场景：

以最受欢迎的 GitHub Spec-Kit 为例，其工作流 “specify → plan → tasks → implement” 将模糊需求转化为结构化任务：开发者只需用自然语言 + 简单 Schema 描述需求（如用户认证模块的输入参数、验证逻辑、返回格式），工具就能自动生成实现计划、测试用例，甚至调用 Copilot、Claude 等 AI 代理完成编码。

对于需要灵活适配多 AI 工具的团队，单纯依赖现成工具可能存在学习成本与约束限制。鹿Sir一哥们技术团队在重构 agent 项目时，提炼出ISPI 四层规范模型，通过 “自顶向下” 的约束设计，实现 AI 与人类的深度意图对齐，最终用一周时间完成前两次两周未解决的重构目标。

核心是让 AI 理解重构的目的与边界，需回答三个问题：

• 当前存在什么问题？（如 observe 函数承担上下文管理、状态视图、记忆读取 3 个职责，违反单一职责原则）

• 预期目标是什么？（如 observe 只负责生成当轮观察快照，上下文管理交给独立模块）

• 禁止做什么？（如 action_plan 不得进入 observation，observe 不处理跨轮状态）

实践显示，让 AI 复述意图并确认，可减少后续 50% 的理解偏差。

要求 AI 描述当前代码结构，识别偏差点。以 observe 函数重构为例，AI 需明确：

• 函数当前调用链：如何读取 WorkingMemory（WM）、合并 act_log、增强领域逻辑？

• 关键偏差：如每轮从 WM 完整重建上下文导致 token 用量超 2500，action_plan 污染观察上下文等。

若 AI 分析与人类认知不一致，需返回第一层重新对齐，避免 “南辕北辙”。

基于偏差分析，让 AI 提出技术方案并说明 trade-off。例如 observe 函数拆分的三种方案：

• 方案 A（拆分为多个函数）：改动最小，但职责边界仍模糊；

• 方案 B（引入 ContextManager）：职责分离彻底，可测试性高，但抽象成本增加；

• 方案 C（逻辑下沉到 utils）：保持向后兼容，但可能导致 utils 臃肿。

将方案转化为可执行的优先级任务，包括：

• 改动文件：如新增 context\[_builder.py](_builder.py)、agent_statu\[_view.py](_view.py)；

• 迁移步骤：先封装 ContextManager，再修改 observe 函数签名，最后更新测试；

• 回滚预案：保留旧函数为_observe_legacy，通过配置开关切换版本；

• 验证标准：单元测试通过率 100%，完整 ReAct 循环无报错。

通过这种方式，将规范文档转化为 AI 的 “操作手册”，编码阶段无需反复沟通。

值得强调的是，SDD 并非要完全取代氛围编程，而是形成 “互补模式”：

• 探索阶段用氛围编程：快速验证想法、搭建原型，享受 AI 带来的效率红利；

• 生产阶段用 SDD：通过规范约束确保质量，让 AI 生成可维护、可上线的代码。

国内一互联网公司的混合实践显示：在需求探索期，用 Vibe Coding 快速生成 3 个原型版本（耗时 1 天）；确定方向后，用 SDD 编写规范并生成生产代码（耗时 2 天），整体周期比纯氛围编程缩短 40%，同时代码质量达到企业级标准。

当 AI 越来越擅长 “执行”，人类的核心价值正从 “编写代码” 转向 “定义规则”。氛围编程让我们看到 AI 的创造力，而 SDD 则让这种创造力可控、可衡量、可协作。

对于开发者而言，2025 年的核心竞争力不再是 “写代码的速度”，而是 “设计规范的能力”——能将模糊需求转化为结构化规范，能让 AI 成为理解架构意图的协作伙伴，才能在 AI 编码时代立于不败之地。

不妨从今天开始：用 Spec-Kit 初始化你的下一个项目，用 OpenSpec 改造现有代码，或是用 ISPI 模型梳理重构需求。

当规范成为开发流程的核心，你会发现：AI 编码不仅能 “快速跑起来”，更能 “稳定走下去”。

关于「鹿Sir」

分享架构技术/IT资讯/牛马日常

电商·SaaS架构师/DDD极客，COLA-DDD/DDD4j框架作者

→关注公众号，撩小码鹿「已接入AI」

→加我备注“进群”，进技术大佬群学习