随着大型语言模型在代码生成领域的突破性进展，软件开发正在经历一场深刻的范式革命。传统的、以人为主导的编码模式正逐渐被新型的人机协作模式所取代。在这一变革浪潮中，两种截然不同的AI编程范式------Vibe Coding和Spec Coding------应运而生。
本文将对比两种编程范式Vibe Coding 与 Spec Coding ，并通过 spec-kit 来尝试一个案例，体验下 AI 时代，编程的最新玩法。
一、AI Coding 分级
AI Coding 分级体系可充分借鉴自动驾驶行业的成熟理念，构建从 L1 到 L5 的渐进式能力图谱：L1-L3 对应已深度融入研发生命周期的辅助工具；L4 进入"无人区"，AI 首次具备独立交付完整项目的能力，可初步替代人类工程师岗位；L5 则通过多智能体协同，端到端还原真实研发团队的完整工作流程，实现"零人类"闭环。
二、AI Coding 范式
1、Vibe Coding是一种直觉驱动的快速原型方法，通过自然语言与AI对话，以极高的速度将模糊想法转化为可运行代码，适用于个人项目、创意探索和MVP验证，但其生成的代码质量、可维护性和团队协作性较差。由 OpenAI联合创始人Andrej Karpathy在2025年初提出的"氛围编程"概念，强调"忘记代码存在，专注创意表达"的开发模式。
2、Spec Coding则是一种规范驱动的可控工程方法，强调在编码前通过结构化的文档明确需求和设计，再让AI在严格约束下生成代码，适用于企业级复杂项目、团队协作和需要长期维护的系统，虽然前期投入较高，但能保障代码质量和项目的可控性。从"Vibe"到"Spec"的演进，强调结构化与可控性，解决复杂项目中的可控性问题。
在软件开发的两种极端之间，Vibe Coding 与 Spec Coding 像两条岔路：一条凭直觉狂奔，一条按蓝图缓行。前者把键盘当画笔，先"跑起来"再谈对错；后者把需求当契约，先"画清楚"再动工。它们不是优劣之争，而是速度-可维护性天平上的左右砝码。
结论与建议：
- 选择 Vibe Coding：适合初创阶段、需求不明确、快速试错、创意探索型项目。
- 选择 Spec Coding：适合成熟业务、需求明确、团队协作复杂、长期维护型项目。
实际项目中，往往两者结合使用，初期用Vibe Coding快速探索，后期用Spec Coding规范化管理，实现效率与质量的平衡。
三、聚焦 Spec Coding
在 Amazon Kiro IDE 中，只需把一句"给我做个会员系统，炫酷一点"扔进对话框，30 秒后你就会得到三份文件：requirements.md、design.md、tasks.md------这是规范驱动开发（Spec-Driven Development，SDD）第一次以 IDE 原生能力的形态出现在主流工作流中。
Kiro 用静态提示词模板把模糊 Prompt 拆成角色-场景-验收，再生成上下文图与任务列表，看似完成了"从一句话到可执行计划"的魔术，却也在悄悄暴露一个老问题：业务黑话、缺失主语、隐性规则这些在人类评审里都要反复拉扯的坑，AI 同样会一脚踩空。
下文我们将聚焦 Spec Coding 这一范式，通过 Spec-Kit 来构建提示词链路与文档生成策略，看它在多大程度上能把"需求歧义"提前锁进笼子，又会把哪些新坑留给编译器之后的环节。
四、初始化
项目地址：github.com/github/spec...
1、安装uv包管理器
brew install uv
如果电脑没有安装，请先安装 brew，参考 Mac 安装： /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
2、构建项目
直接使用如下命令，初始化项目：
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
bash
# 示例：
# uvx --from git+https://github.com/github/spec-kit.git specify init try-spec-coding
# (若已有项目)集成 Spec-Kit，则执行初始化即可
uvx --from git+https://github.com/github/spec-kit.git specify init --here
接下来，会卡在这一步：
3、准备 AI assistant
这里你可以选择 Claude，如果没有账号，想要尝试下，使用 Qwen 即可。官网地址：qwenlm.github.io/qwen-code-d...
Qwen Code 将先进的代码模型能力带入你的终端，提供交互式的 Read-Eval-Print Loop (REPL) 环境。Qwen Code 由一个客户端应用 (packages/cli) 和一个本地 server (packages/core) 组成。Qwen Code 还包含多种工具，用于执行文件系统操作、运行 shell 命令和网络请求等任务，这些工具由 packages/core 管理。
全局安装：
bash
npm install -g @qwen-code/qwen-code
# 这里注意 Node 版本需要切换到 V20 以上，如：
nvm use v20.19.5首次使用，输入命令 qwen，做授权校验，之后就可以使用了。
测试下是否正常工作：
4、继续项目
安装好 QWen 后，选择即可。
按照指导，下一步即可创建项目。
注意：
Agent 文件夹安全性：某些 Agent 可能会在你的项目中的 Agent 文件夹内存储凭证、认证令牌或其他可识别和私有的信息。建议将 .qwen/（或其部分内容）添加到 .gitignore 中，以防止意外泄露敏感信息。
五、小试牛刀
进入我们上面初始化的项目： cd try-spec-coding
1、Constitution（原则）：建立项目原则
bash
/constitution 项目使用 React 构建，UI框架使用 Antd，如果涉及服务端请使用 Eggjs。项目严格要求测试文档，且注意前后端分离；必要的 Readme文档；
确认执行
创建完成，可以在目录下看到 constitution.md 文档：
2、Specify（规格化）：创建需求说明
bash
/specify 我需要构建一个AI资讯站点，可以通过API接口获取每日资讯，资讯内容包含：标题、时间、分类、评分、摘要、配图等信息。资讯以卡片形式展示，每行4列。页面由标题、搜索框、资讯卡片区域构成。标题需要醒目一些，赛博朋克风格。搜索框与资讯卡片联动，可以实时搜索。资讯卡片内容较多时，使用无限滚动加载，注意用户体验。整体风格暗黑色系，注意美观大方，动画效果酷炫。
等待生成，查看并修改 spec.md 文档：
3、Plan（规划）：制定实施方案
bash
/plan 使用 React 编写客户端，Eggjs 提供服务端，MongoDB数据库，JWT认证，nodemailer发送验证邮件
等待生成，查看文档：plan.md
4、Tasks（任务分解）：生成可执行任务
bash
/tasks 将上述要求和计划分解为可执行的开发任务
查看并修正：tasks.md
5、Implement（实现）：执行实施
bash
/implement 基于TDD原则实现代码
这一步还是真正开始写代码了，等待生成：
运行单元测试：
看看效果：
最终的项目目录如下：
js
demo/
├── spec.md # 项目规格文档
├── plan.md # 技术实现计划
├── tasks.md # 任务分解列表
├── tests/ # 测试文件
│ ├── unit/
│ ├── integration/
│ └── e2e/
├── app/ # 源代码
├── docs/ # 项目文档
└── README.md # 项目说明注意：这里修改了部分项目个性化信息，看看最通用的结构即可。
六、总结
Spec-Kit 以"规格驱动"重塑 AI Coding，让它从"闲聊式编码助手"跃升为"结构化软件开发搭档"。其核心信条只有四句：
1、先想后写：用规格厘清需求，再落笔成码。
2、测试先行：把质量关搬进第一行代码。
3、文档即契约：一份活文档，让团队零摩擦协同。
4、持续迭代：让每一次提交都比上一次更优雅。
当然，Spec Coding 也并非银弹，它更像一把双刃剑------
1、需求一抖，规格全朽。项目里一次"小小"的 pivot，可能让前期精雕细琢的 spec 瞬间变废纸，重写成本不亚于把高速列车改航道。
2、前期"重规"能否换来后期"轻债"？当规范文档的厚度超过代码行数，而迭代速度又被市场按在地上摩擦，ROI 的问号就会像编译器警告一样越滚越大：我们到底是在投资可维护性，还是在为仪式感买单？
于是问题来了：
如果需求必然漂移，Spec Coding 该不该给"变更"本身也写一份 Spec？
当 AI 已经能把"跑起来"的 Vibe Coding 反向生成规格，我们是否还需要人类先画蓝图？