2026年AI 编程进入下半场：从 Vibe 到 Spec

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

最近在看“从 Vibe Coding 到 Spec Coding”这组资料时，我最有共鸣的一句话是：

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

本文默认你使用 Node.js 20 + TypeScript + Vitest + Claude Code，目标不是做一个 Demo，而是把 AI 辅助开发拉到生产级。

问题分析：Vibe Coding 为什么总在后期失速

Vibe Coding 的优势是快，尤其适合探索期。但它在生产阶段常见 4 个问题：

1. 意图丢失：Prompt 只保留“怎么做”，很难沉淀“为什么这样做”。
2. 结果漂移：多人协作时，每个人的 Prompt 风格不同，输出标准不一致。
3. 验证滞后：先写代码再补测试，返工成本高。
4. 经验不可复用：一次性对话很难迁移到下一个项目。

所以关键不是否定 Vibe，而是给它一个更稳定的“骨架”——Spec Coding。

解决方案：Spec Coding 的三层规范模型

把规范当成 source of truth，代码当成实现产物。推荐用三层结构：

1. 功能规范（What）
定义用户故事、验收标准、边界条件。
2. 架构规范（How - 语言无关）
定义数据模型、API 契约、安全约束、性能目标。
3. 实现规范（How - 语言相关）
定义技术栈版本、测试框架、编码约束、发布要求。

在 Claude Code 中，对应关系通常是：

• CLAUDE.md：项目级总规范
• .claude/rules/：分层规则
• specs/.md：功能级规范
• /plan：把规范拆成可执行任务

实战示例：用规范驱动通知系统（可运行）

下面给一套最小可运行样例，体现“先规范，后实现，再验证”。

步骤 1：先写 `specs/notification.md`

# 用户通知系统规范 功能需求1. 支持站内通知、邮件通知、推送通知2. 通知类型：系统公告、订单状态、促销活动、安全提醒3. 支持已读/未读、批量已读4. 用户可按渠道与类型配置偏好 数据模型- notifications: id, userId, type, channel, title, content, isRead, createdAt- preferences: userId, type, channel, enabled 验收标准- 未读数在标记已读后实时正确- 批量已读后用户未读数为 0- 偏好变更后立即生效 非功能性要求- 所有输入参数必须校验- 错误要有明确错误码- 关键行为可测试

步骤 2：实现 `src/notification-service.ts`

export type NotificationType = 'system' | 'order' | 'promo' | 'security'export type Channel = 'in_app' | 'email' | 'push'export interface Notification interface PreferenceKey export class NotificationService   // 统一生成偏好键，避免拼接逻辑分散  private prefKey(key: PreferenceKey): string {    return ${key.userId}:${key.type}:${key.channel}  }  // 更新通知偏好，默认 true 表示开启  updatePreference(input: PreferenceKey, enabled: boolean): void   // 判断某类通知渠道是否开启  isEnabled(input: PreferenceKey): boolean   // 获取用户通知，支持按已读状态过滤  list(userId: string, isRead?: boolean): Notification[] )  }  // 标记单条已读，不存在时抛错，方便上层返回 404  markAsRead(userId: string, notificationId: string): void   // 批量标记已读  markAllAsRead(userId: string): number     }    return affected  }  // 未读数用于前端角标展示  unreadCount(userId: string): number }

步骤 3：验证 `tests/notification-service.test.ts`

import { describe, expect, it } from 'vitest'import  from '../src/notification-service'const seed = [  {    id: 'n1',    userId: 'u1',    type: 'system',    channel: 'in_app',    title: '系统维护',    content: '今晚 22:00 维护',    isRead: false,    createdAt: new Date('2026-04-09T10:00:00Z')  },  {    id: 'n2',    userId: 'u1',    type: 'promo',    channel: 'email',    title: '限时活动',    content: '全场 8 折',    isRead: false,    createdAt: new Date('2026-04-09T11:00:00Z')  }] as constdescribe('NotificationService', () => )  it('markAllAsRead 后未读应为 0', () => )  it('偏好关闭后 isEnabled 应返回 false', () => ,      false    )    expect(      service.isEnabled({ userId: 'u1', type: 'promo', channel: 'email' })    ).toBe(false)  })})

运行方式：

npm i -D typescript vitest tsxnpx vitest run

在 Claude Code 中的推荐指令

@specs/notification.md请按规范实现通知系统，严格分 4 步执行：1) 先输出 plan；2) 按任务逐步实现；3) 每步都运行测试；4) 完成后做一次 code review 并列出风险项。

这条指令的重点是：把“生成代码”变成“执行规范 + 验证规范”。

**实践与常见陷阱

**实践：

1. 规范与代码同仓库同版本管理，PR 同时审查。
2. 每个规范都带验收标准和非功能性要求。
3. 规范变更必须触发自动化测试，防止实现漂移。

常见陷阱：

1. 规范只写 happy path，漏掉错误处理与边界条件。
2. 把“实现细节”误写成“需求事实”，导致规范过早僵化。
3. 只让 AI 生成，不做验证，把草稿当成成品。

渐进迁移：从 Vibe 到 Spec 的可执行路径

1. 第 1 阶段（探索）
用 Vibe Coding 在 30 分钟内验证想法是否成立。
2. 第 2 阶段（沉淀）
把有效结论抽成 specs/.md，补齐验收与约束。
3. 第 3 阶段（重建）
基于规范重做生产实现，并强制测试与审查。

这个路径的核心是：速度来自 Vibe，质量来自 Spec。

总结

Spec Coding 不是替代 Vibe Coding，而是把 AI 编程从“会写”推进到“可交付”。
当你开始认真维护 CLAUDE.md、rules、specs，你已经在做工程化的 AI 开发。

如果你也在把 AI 从“会写”推进到“可交付”，欢迎留言说说你团队现在最卡的是规范、测试，还是协作流程。

参考资料

• 从 Vibe Coding 到 Spec Coding：AI 编程的进化之路

📌 声明：本文由 AI 辅助完成