企业官网建设流程全解析

easy-vibe 深度指南：从 Vibe Coding 到 Spec Coding，让规范文档成为 AI 编程的新代码

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

"Code is a lossy projection of intent." 代码，是意图的有损投影。 —— Sean Grove，OpenAI，AI Engineer World's Fair 2025

本篇技术指南聚焦 easy-vibe 课程第三阶段核心技能中的Spec Coding（规范驱动开发）章节，系统讲解为什么"规范即代码"会成为 AI 编程的新范式，并给出在 Claude Code 中从零落地的完整工作流：CLAUDE.md项目规范、.claude/rules/分层规则、/plan四阶段循环，以及从 Vibe Coding 渐进迁移到 Spec Coding 的混合策略。读完本文，你将掌握把模糊需求转化为可执行 Markdown 规范、并让 AI 据此稳定产出生产级代码的完整方法论，并能在 easy-vibe 课程体系与真实项目中直接实践。

写在前面：Spec Coding 的核心思想——一切皆 Markdown

在深入 Spec Coding 之前，先理解 Claude Code 的设计哲学：一切皆 Markdown。

在 Claude Code 的设计哲学中，过程记录、信息传递、甚至与模型的对话都可以是 Markdown：

• CLAUDE.md：描述项目约定的 Markdown 文档
• .claude/rules/：一组分层的 Markdown 规则文件集合
• specs/：功能需求的 Markdown 描述
• 对话历史：Claude Code 的聊天记录本身就是 Markdown 格式
• AGENTS.md：定义 Agent 行为的 Markdown 指令

这正是 Spec Coding 的核心：规范本身就是代码。当你用 Markdown 写下需求、设计决策和验收标准时，你已经在"写代码"——AI 会读取这份 Markdown，然后生成真正的实现。

Josh Beckman 对 Grove 演讲的总结恰到好处：

"Software engineering (and lawmaking and legal review) is specification repair." 软件工程（以及立法和法律审查）本质上是规范修复。

在 Claude Code 中，这个"规范修复"过程就是：修改 Markdown → AI 读取 Markdown → 生成/修改代码 → 验证结果。整个工作流都由 Markdown 驱动。

值得注意的是，这一哲学在本仓库中有最直观的实例——AGENTS.md 就是 easy-vibe 自己的"规范即代码"文件：它用 Markdown 描述了项目结构（docs/为 VitePress 站点源码）、构建命令（npm install/npm run dev/npm run build）、编码风格与提交流程。任何接入该仓库的 AI Agent 都会先读这份规范，再决定如何行动，这正是"规范驱动"的日常形态。

一、Sean Grove 的《The New Code》：一场改变思维方式的演讲

2025 年，OpenAI 研究员Sean Grove在 AI Engineer World's Fair 上发表了题为《The New Code》的演讲，震撼了整个开发者社区。他提出了一个颠覆性的观点：70 年来我们一直在写代码来解决问题，但代码只是意图的有损投影——规范（Specification）才是真正的"新代码"。

这场演讲被广泛视为 Spec Coding 运动的思想起点。Grove 此前创立了 GraphQL 开发者工具公司 OneGraph（后被 Netlify 收购），现在在 OpenAI 从事 alignment reasoning 工作——帮助将高层意图转化为可执行的规范与评估标准。

1.1 核心论点：代码是意图的有损投影

Grove 演讲的核心概念可以用一句话概括：

Code is a lossy projection of intent.代码是意图的有损投影。

这意味着什么？当你脑中有一个想法，并把它转化为代码时，大量上下文在途中丢失了——为什么选择这个方案、考虑过哪些权衡、哪些约束是重要的。最终代码只保留了"怎么做"，却丢失了"为什么要这样做"。

这就像把一本书压缩成一条推文——信息密度急剧下降，原始意图被严重削弱。

1.2 编程的本质是沟通

Grove 提出了一个简单但深刻的观点：

"If you can communicate effectively, you can program." 如果你能有效沟通，你就能编程。

他认为，真正的编码工作只占开发的10%-20%，其余 80% 是围绕需求与目标的结构化沟通——理解用户想要什么、与团队对齐解决方案、定义验收标准、处理边界情况。

这意味着，编程能力的核心不是掌握某种语言的语法，而是将模糊意图转化为精确描述的能力。

1.3 谁写 Spec，谁就是程序员

这是 Grove 最具颠覆性的观点：

"Whoever writes the spec - be it a PM, a lawmaker, an engineer, a marketer - is now the programmer." 无论谁写规范——是产品经理、立法者、工程师还是市场人员——他现在就是程序员。

随着 AI 越来越擅长把规范转化为代码，真正的"编程工作"从"写代码"转移到了"写规范"。谁能最精确地表达意图，谁就会成为最有价值的"程序员"。

1.4 规范可以拥有类似代码的工具链

Grove 指出，规范可以拥有和代码一样的完整工具链：

"Specs actually give us a very similar toolchain, but it's targeted at intentions rather than syntax."

• 组合（Composition）：规范可以像代码模块一样模块化、可组合
• 测试（Testing）：规范可以内嵌单元测试，验证行为是否符合预期
• Lint：规范中的模糊语言可以被检测出来，就像 linter 发现语法问题
• 一致性检查：跨部门的规范可以进行一致性检查，类似类型检查器

1.5 OpenAI Model Spec：活的证明

Grove 用 OpenAI 自己的Model Spec文档作为证据。

当 OpenAI 发现了一个 Sycophancy（谄媚奉承）问题时，他们没有重新训练模型，而是直接修改了规范文档。修改自动在系统中传播，问题被修复了。

这证明了一个关键点：规范本身可以像可执行代码一样运作。修改规范就等于修改行为，而无需触碰一行传统代码。

Josh Beckman 的总结再次应验：

"Software engineering (and lawmaking and legal review) is specification repair." 软件工程（以及立法和法律审查）本质上是规范修复。

二、Spec Coding：把规范当作代码

2.1 什么是 Spec Coding

Spec Coding，又称Spec-Driven Development (SDD)，是一种将规范文档作为开发核心产物的方法论。

其核心思想是：先清晰写出规范，再让 AI 根据规范生成代码。规范是事实的唯一来源（source of truth），代码只是从中派生的实现产物。

Robert C. Martin 在《Clean Code》中的经典论断在 AI 时代重新焕发生机：

"Specifying requirements so precisely that a machine can execute them is programming." 将需求精确到机器可以执行的程度，就是编程。

2.2 Vibe Coding 与 Spec Coding 的对比

两者并非对立。正如 Brad Jolicoeur 强调的：

"Clever engineers will even use vibe coding as a first step to generate the initial draft of a specification." 聪明的工程师甚至会先用 Vibe Coding 作为第一步，来生成规范的初稿。

2.3 Spec Coding 的三层规范结构

Red Hat 的工程师总结了一套实用的三层规范模型：

第 1 层：功能规范（做什么 / Was）

用自然语言描述预期结果，回答"它应该做什么"：

## 用户认证功能 ### 用户故事 - 作为新用户，我希望用邮箱注册 - 作为注册用户，我希望用邮箱和密码登录 - 作为忘记密码的用户，我希望通过邮箱重置密码 ### 验收标准 - 注册时校验邮箱格式与密码强度 - 连续 5 次登录失败后锁定账户 15 分钟 - 密码重置链接 30 分钟内有效

第 2 层：语言无关规范（怎么做 - 架构层 / Wie）

定义数据结构、架构模式与安全要求：

## 技术设计 ### 数据模型 - users 表：id, email, password_hash, created_at, locked_until - sessions 表：id, user_id, token, expires_at ### API 设计 - POST /api/auth/register -> 201 Created - POST /api/auth/login -> 200 OK + JWT - POST /api/auth/reset-password -> 202 Accepted ### 安全要求 - 密码使用 bcrypt，成本因子 >= 12 - JWT 15 分钟过期，Refresh Token 7 天过期 - 所有端点启用 Rate Limiting

第 3 层：语言相关规范（怎么做 - 实现层 / Wie）

明确版本要求、测试框架与文档标准：

## 实现约束 ### 技术栈 - 运行时：Node.js 20+ - 框架：Express 5 - ORM：Prisma - 测试：Vitest ### 代码约定 - 使用 TypeScript Strict Mode - 使用自定义 AppError 类处理错误 - 所有 API 端点要求 JSDoc 注释

三层结构的分工非常清晰：第 1 层面向业务与验收，第 2 层面向架构决策，第 3 层面向实现细节。规范写到这里，AI 已经不需要"猜测"任何东西。

三、在 Claude Code 中实践 Spec Coding

理解了理论之后，下一个问题是如何在 Claude Code 中落地。Claude Code 的设计哲学天然适配 Spec Coding——它的CLAUDE.md、Rules 目录和/plan命令都是规范驱动开发的形式。

OpenAI 自己用 Codex 构建项目时也使用类似模式：用一份AGENTS.md文件作为控制 AI Agent 的规范。他们最重要的经验是：如果 Agent 遇到困难，把它当作信号——识别缺少什么，是工具、护栏（Guardrails）还是文档，然后把它补充进仓库。这与 Spec Coding 完美契合：规范是活的产物，应该持续演化。

Augment Code 的研究支持同样的结论：可执行的规范能够保持精确，因为 AI Agent 直接从中生成代码，这产生了一种强制力——过时的规范会产出损坏的实现。这意味着规范不会像传统文档那样腐烂。

3.1 第一步：用 CLAUDE.md 建立项目规范

CLAUDE.md是项目的"活规范"。每次 Claude Code 启动都会读取这个文件，相当于给 AI 一本永久的项目手册。

在之前的章节 Claude Code 快速入门核心指南 中，我们已经学会了如何创建CLAUDE.md。在 Spec Coding 语境下，它的角色更加重要——它不只是配置文件，而是项目规范的入口点。

LogRocket 的工程师强调，为 AI Agent 提供扎实的上下文至关重要，可以防止幻觉与低效。没有规范，AI Agent 可能对项目做出大规模、不可控的修改。CLAUDE.md是提供这种"扎实上下文"的第一道防线。

# 电商项目规范 ## 项目定位 面向中小商家的 SaaS 电商平台，支持多店铺、多渠道支付。 ## 架构决策 - 前后端分离，API-First 设计 - 微服务后端架构，服务间通过消息队列通信 - 读写数据库分离 ## 核心约束 - 所有金额以整数分存储，避免浮点精度问题 - 订单状态机必须严格遵守：待支付 -> 已支付 -> 已发货 -> 已完成 - 支付相关端点必须幂等

Aviator 团队总结了规范应捕获的关键信息——这正是你的CLAUDE.md应该覆盖的内容：

• 输入输出格式与数据类型
• 业务规则与边界情况
• 系统依赖与限制
• 性能与可扩展性要求
• 错误处理与安全要求

3.2 第二步：用 Rules 目录管理分层规范

当项目成长后，单一的CLAUDE.md会变得臃肿。此时使用.claude/rules/目录来组织分层规范。

这正是 Augment Code 所说的"可执行规范"理念：规范不是静态文档，而是被 AI Agent 直接消费的活指令。当你在 Rules 目录中拆分规则时，每条规则文件只在与相关文件编辑时被加载，既节省 token 又保持精确性。

Tessl 的工程师发现，把需求拆解为结构化文档——用 PRD 定义"做什么和为什么"，用技术规范定义"怎么做"——有助于防止 AI 在长对话中积累混乱，显著提升输出一致性。

.claude/rules/ ├── 00-architecture.md # 架构规则（全局） ├── 01-security.md # 安全规则（全局） ├── 10-api-design.md # API 设计规则 ├── 11-frontend-patterns.md # 前端模式规则 ├── 12-database.md # 数据库规则 └── 20-testing.md # 测试规则

每条规则文件可以通过 frontmatter 指定其生效范围：

--- globs: - "src/api/**/*.ts" - "src/services/**/*.ts" --- # API 设计规则 ## 路由设计 - RESTful 风格，使用复数名词：/api/v1/orders - 嵌套资源最多两层深：/api/v1/users/123/orders ## 响应格式 - 成功：{ data, pagination? } - 错误：{ error: { code, message, details? } } ## 必须遵守 - 所有写操作要求认证 - 所有列表端点必须支持分页 - 敏感操作必须写审计日志

这样，当 Claude Code 编辑 API 相关文件时，会自动加载这条规范，确保生成的代码符合标准。globs机制实现了"按需加载"，这正是分层规范相比单一大文件的优势。

3.3 第三步：用 /plan 落地 Specify → Plan → Tasks → Implement

标准的 Spec Coding 工作流是一个四阶段循环。GitHub Spec Kit 将其标准化为Specify → Plan → Tasks → Implement，Claude Code 的/plan命令天然支持这一流程。

SpecThis 团队强调一个关键原则：在 Agent 运行之前就界定边界——在代码变更发生之前知道什么应该改变。这正是/plan的价值。

阶段 1：Specify（明确规范）

先把要构建的内容清晰地写下来，不要急于写代码：

/plan 我需要实现一个订单退款功能。规范如下： 功能需求： - 发货前用户可申请全额退款 - 发货后 7 天内用户可申请退货退款 - 退款需要管理员审批 验收标准： - 退款金额不得超过订单实际支付金额 - 退款状态机：已申请 -> 已批准 -> 退款中 -> 已退款 - 退款完成后恢复库存 - 全程记录每一步操作

阶段 2：Plan（制定计划）

Claude 根据你的规范生成技术方案：

📋 退款功能实现计划 1. 数据模型设计 - 创建 refunds 表 - 在订单状态机中新增退款相关状态 2. API 设计 - POST /api/orders/:id/refund - 申请退款 - PUT /api/refunds/:id/approve - 审批退款 - GET /api/refunds - 退款列表 3. 业务逻辑 - 退款资格校验 - 退款金额计算 - 库存恢复逻辑 4. 集成 - 对接支付方退款 API - 发送退款通知

阶段 3：Tasks（拆解任务）

将计划拆解为可独立执行的小任务，并为每个任务定义清晰的完成标准。

阶段 4：Implement（实施）

逐一实现任务，每完成一个就验证一次。

这一流程与 easy-vibe 课程中的 Claude Code 快速入门核心指南 中/plan的用法一脉相承——先定义实现计划，再逐步执行。

3.4 实战对比：用 Spec Coding 构建一个通知系统

用一个完整示例来对比 Vibe Coding 与 Spec Coding。Orchestrator.dev 的数据显示，在 Stack Overflow 2025 年调查中，84% 的开发者正在使用或计划使用 AI 工具，但只有 22% 对结果感到满意，46% 将准确性问题视为痛点。Spec Coding 正是弥合这种满意度差距的关键。

Vibe Coding 方式：

你：构建一个通知功能 AI：[立即开始写代码，生成一个简单的通知列表] 你：它应该支持已读和未读 AI：[修改代码，添加 read 字段] 你：还需要多种通知类型 AI：[再次修改，添加 type 字段] 你：它还应该向手机推送通知 AI：[做了一次大重写，之前的结构又对不上了...]

结果：经过四轮修改，架构被反复推倒重来，代码随着时间推移越来越混乱。

Spec Coding 方式：

首先写一份规范文档specs/notification.md：

# 通知系统规范 ## 功能需求 1. 支持三种渠道：应用内通知、邮件通知、推送通知 2. 通知类型：系统公告、订单状态、营销活动、安全警告 3. 用户可以按渠道和类型配置通知偏好 4. 支持已读/未读状态与批量标记已读 ## 数据模型 - notifications 表：id, user_id, type, channel, title, content, is_read, created_at - notification_preferences 表：user_id, type, channel, enabled ## API 设计 - GET /api/notifications?type=&is_read= - 获取通知列表（分页） - PUT /api/notifications/:id/read - 标记已读 - PUT /api/notifications/read-all - 全部标记已读 - GET /api/notification-preferences - 获取偏好 - PUT /api/notification-preferences - 更新偏好 ## 验收标准 - 未读通知数量实时更新 - 通知列表支持无限滚动 - 推送通知延迟 < 3 秒 - 偏好修改立即生效

然后在 Claude Code 中：

@specs/notification.md 根据这份规范实现通知系统。 先做数据模型，再实现 API，最后构建前端组件。 每完成一个模块就暂停，我会确认后再继续。

结果：一次干净利落地完成，架构清晰，没有反复推倒重建。

3.5 用 Superpowers 为 Spec Coding 赋能

在之前的章节 Claude Code Superpowers：工程级开发 中，我们了解了 Superpowers 技能系统。Spec Coding 与 Superpowers 是天然搭档：

组合使用示例：

@specs/notification.md 用 TDD 方式根据这份规范实现通知系统， 完成后帮我做代码审查

这一条指令同时激活了 Spec Coding 工作流与 Superpowers 的 TDD、Code Review 等技能，构成完整的工程级开发流程。

3.6 规范的版本控制与持续演进

The Vibe Coding Substack 提出了一个重要的观点：Specs are now code。如果规范就是代码，那么就应该像代码一样被管理：

• 版本控制：规范文件纳入 Git，与代码一起提交
• 变更追踪：规范的每次修改都有 commit 记录，可以追溯谁在何时为何修改
• 代码审查：规范的修改同样要走 PR Review，确保团队信息同步
• CI 集成：规范变更触发自动化测试，验证实现是否仍然符合规范

在 Claude Code 中，这意味着你的CLAUDE.md、.claude/rules/和specs/目录都应该纳入版本控制。Robomotion 的经验是，将规范与实现一起版本化，可以防止漂移，让一切可追溯。

OpenAI 的 Harness Engineering 实践也印证了这一点：他们的AGENTS.md文件本身由 Codex 编写，并随项目演进而持续更新。当 Agent 遇到困难时，解决方案不是直接改代码，而是让 Codex 自己更新规范——这形成了一个规范的自愈闭环。

四、混合策略：从 Vibe 到 Spec 的渐进迁移

行业共识不是"放弃 Vibe Coding"，而是在正确的场景选择正确的方法。

4.1 何时使用 Vibe Coding

• 30 分钟内验证一个想法是否可行
• 探索不熟悉的技术或框架
• 黑客松或内部演示
• 一次性脚本或工具

4.2 何时使用 Spec Coding

• 生产功能开发
• 多人协作项目
• 需要长期维护的代码
• 安全、支付、数据等敏感领域
• API 设计与系统集成

4.3 推荐的渐进式工作流

阶段 1：Vibe 探索

用 Vibe Coding 快速验证想法，暂不写规范、不纠结代码质量：

先做一个简单的通知弹窗，让我们看看它的体验如何

阶段 2：提炼规范

可行性确认后，把探索中学到的东西整理成规范。你甚至可以请 AI 帮忙：

基于我们刚做的通知功能原型， 帮我写一份正式的功能规范文档， 包括数据模型、API 设计和验收标准

阶段 3：按 Spec 重建

基于这份规范，用 Spec Coding 重新实现生产级版本：

@specs/notification.md 严格按照规范从零实现，不要参考之前的原型代码

这个工作流的好处显而易见：用 Vibe Coding 的速度验证方向，用 Spec Coding 的质量交付产品。

Robomotion 总结得很到位：

"The spec is the source of truth. The AI generated output is the draft implementation. Validation is not optional." 规范是事实的来源。AI 生成的输出是草稿实现。验证不是可选项。

五、常见问题

F1：Spec Coding 会不会太慢？

写规范确实需要前期投入。但 Greg Ceccarelli 的团队用 Spec Coding 在四周内、仅凭三人交付了一个完整的 macOS 产品——这在传统开发中几乎不可能。

早期花在写规范上的时间，会在后期通过更少的返工、更少的 bug 和更低的沟通成本赢回来。

F2：规范应该写多详细？

Robomotion 的建议是：一份高质量的规范可以只有一页。关键是它是否回答了这八个问题：

1. 我们要自动化什么？
2. 输入是什么？
3. 输出是什么？
4. 约束条件是什么？
5. 失败模式有哪些？
6. 安全要求是什么？
7. 性能要求是什么？
8. 哪些测试能证明它有效？

F3：AI 只做规范里写了的事，漏掉"显而易见"的功能怎么办？

这确实是 Spec Coding 的局限之一。GitHub Spec Kit 用户的反馈是，AI 会**"严格且只"**做规范里写了的事。

解决办法是在规范中增加一个"非功能需求"（NFR）部分，列出错误处理、日志、无障碍等通用期望；或者把它们放进CLAUDE.md的全局规则中。

F4：小项目也需要 Spec Coding 吗？

不需要。Spec Coding 最适合：

• 生产级项目
• 团队协作项目
• 需要长期维护的项目

对于快速原型、一次性脚本和学习实验，Vibe Coding 更合适。

F5：如何让团队接受 Spec Coding？

从一个小的功能作为试点开始，让团队看到 Spec Coding 如何减少返工、提升首次成功率。Stack Overflow 2025 年调查显示，84% 的开发者使用或计划使用 AI 工具，但只有 22% 对结果满意——Spec Coding 正是提升这种满意度的关键。

六、总结

从 Vibe Coding 到 Spec Coding 的转变不是革命，而是进化。

Sean Grove 在《The New Code》中说得很清楚：70 年来我们写代码来解决问题；现在我们应该写规范来生成代码。代码是意图的有损投影，而规范能够完整捕获意图、上下文与约束。

对于使用 Claude Code 的开发者，这种转变已经在发生：

• 你写的CLAUDE.md就是你的项目规范
• 你配置的 Rules 目录就是你的分层规范系统
• 你用/plan做的规划就是 Specify → Plan → Tasks 流程
• 你结合 Superpowers 的 TDD 与 Code Review 就构成了完整的 Spec Coding 工作流

核心要点：

• Vibe Coding 适合探索与原型，Spec Coding 适合生产与协作
• 规范是事实的来源，代码是从中产出的实现产物
• 写规范的能力 = 编程能力，沟通能力比语法能力更重要
• 从小处开始：仅仅把CLAUDE.md写好，你就已经迈出了 Spec Coding 的第一步

在 easy-vibe 的课程体系中，Spec Coding 是进阶开发（stage-3 目录）中"核心技能"板块的重要一环。如果你已经完成 basics 章节 中关于/plan、CLAUDE.md、/init的基础训练，并理解了 Superpowers 的工程级开发纪律，那么 Spec Coding 就是把这两者串成一条完整生产线的方法论。仓库中 examples 目录下的提示词示例（如trae-block-game/prompt.txt）展示了典型的一次性 Vibe 风格提示，而本文的工作流则展示了如何把它们升级为可复用、可维护、可审查的规范驱动开发流程。

参考来源（文中观点出处）：Sean Grove 在 AI Engineer World's Fair 2025 的演讲《The New Code》；Josh Beckman 的演讲笔记；Red Hat、LogRocket、Aviator、Tessl、Robomotion、Augment Code、SpecThis、GitHub Spec Kit、The Vibe Coding Substack 等团队关于规范驱动开发、规范优先工作流与 Harness Engineering 的公开文章；Stack Overflow 2025 开发者调查数据。

::: tip 下一步 在下一章节中，我们将学习如何利用 Claude Code 的 Agent Teams 能力，让多个 AI 实例像真正的开发团队一样协作。 :::

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe