AI 知识课程

Appearance

3.3 三者融合：探索 → 规格化 → 验证 ​

小明最终没有选择其中一种——他三种都用了。这不是妥协，而是行业正在形成的共识。

融合的核心理念 ​

Vibe Coding
探索
快速验证想法
确认需求
低成本试错
SDD
规格化
从原型提炼规格
定义精确契约
团队协作基础
TDD
验证
核心逻辑测试
重构安全网
持续质量保障

小明的真实项目时间线 ​

回到小明的员工管理系统项目，看看融合工作流怎么落地：

第 1 周：用 Vibe Coding 探索 ​

小明: "帮我做一个员工管理系统原型，支持登录、员工列表、请假申请"

AI 生成 → 运行 → 修 Bug → 继续迭代

2 天后：原型跑起来了
小明把原型拿给产品经理看
产品经理："这个不是我想要的，请假申请需要审批流程"
小明："好的，让我调整"

这个阶段的关键：快速出原型，暴露真正的需求。如果一开始就写规格，可能规格本身就是错的。

第 2-3 周：用 SDD 正式化 ​

需求确认后，小明不再用 Vibe Coding，而是把原型中验证过的需求提炼成规格：

yaml
# 从原型提炼出的 API 规格
openapi: 3.0.3
info:
  title: 员工管理系统 API
paths:
  /employees:
    get:
      summary: 获取员工列表
      parameters:
        - name: department
          in: query
          schema:
            type: string
        - name: status
          in: query
          schema:
            type: string
            enum: [active, inactive, on_leave]
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/EmployeeList'
  /leave-requests:
    post:
      summary: 提交请假申请
      requestBody:
        content:
          application/json:
            schema:
              type: object
              required: [employee_id, start_date, end_date, reason]
              properties:
                employee_id: { type: integer }
                start_date: { type: string, format: date }
                end_date: { type: string, format: date }
                reason: { type: string, minLength: 10 }
      responses:
        '201':
          description: 请假申请已提交

这个阶段的关键：从"模糊理解"过渡到"精确契约"。规格定好后，前端和后端可以并行开发。

第 4 周及以后：用 TDD 验证核心逻辑 ​

对于核心业务逻辑（如请假审批流程），小明切换到 TDD：

typescript
// 请假审批的测试
describe('LeaveRequestService', () => {
  it('should auto-approve if manager is the requester', () => {
    // 老板自己请假，自动批准
  })

  it('should require approval for non-manager employees', () => {
    // 普通员工请假，需要审批
  })

  it('should reject if overlapping leave exists', () => {
    // 时间冲突时拒绝
  })

  it('should not allow leave exceeding annual quota', () => {
    // 超过年假额度时拒绝
  })
})

这个阶段的关键：核心逻辑必须有测试保护，这是 Vibe Coding 给不了你的保障。

三步融合工作流详解 ​

步骤方法论做什么产出
第一步人类写规格用 SDD 定义"做什么"OpenAPI/Gherkin 规格
第二步AI 生成测试AI 根据规格生成测试套件TDD 测试用例
第三步人类+AI 写代码按契约构建代码通过测试的实现

这正是 TDD 的严谨性，但无需 TDD 的手动开销。

什么时候从 Vibe Coding 切换到 SDD？ ​

不是所有项目都需要三种方法论。关键是识别转换信号：

1
上下文漂移：AI 修了一个 Bug，但破坏了其他文件。代码之间的关联开始超出 AI 的理解范围。
2
回归模式：新功能不再遵循已有的设计模式，代码风格越来越不一致。
3
团队扩张：超过一个人需要理解代码库时，需要用规格来协调。
4
生产意图：真实用户或业务流程将依赖这个系统时，必须切换到更严谨的方式。

经验法则：当你发现自己花更多时间修复 AI 引入的问题而不是添加新功能时，就是切换的信号。

不同项目类型的推荐组合 ​

项目类型推荐组合理由
快速原型/MVP纯 Vibe Coding速度第一，验证想法
内部工具Vibe Coding + 少量 TDD快速出活，核心逻辑加测试
企业级 APISDD + TDD规格先行，测试保障
微服务系统SDD 为主 + TDD 核心服务间契约是关键
安全关键系统SDD + TDD（必须）不允许任何歧义和漏洞
个人学习项目纯 Vibe Coding学习优先，享受探索
长期维护产品三者融合探索 → 规格 → 验证

📌 本节核心要点

概念要点
融合工作流Vibe Coding（探索）→ SDD（规格化）→ TDD（验证）
第一步人类写规格，定义"做什么"
第二步AI 根据规格生成测试套件
第三步人类+AI 按契约写代码
转换信号上下文漂移、回归模式、团队扩张、生产意图
经验法则修复 AI 引入的问题 > 添加新功能时 → 该切换了

知识检查 ​

问题 1：三步融合工作流是什么？每一步分别做什么？

查看答案
  1. 第一步（人类写规格）：用 SDD 定义"做什么"——使用结构化框架定义系统约束，不留给 AI 猜测空间
  2. 第二步（AI 生成测试）：AI 根据规格约束生成单元测试、识别边界条件
  3. 第三步（人类+AI 写代码）：AI 按照契约构建代码，而非猜测

核心优势：这保留了 TDD 的严谨性，但无需 TDD 的手动开销。

问题 2：从 Vibe Coding 切换到 SDD 的四个"转换信号"是什么？

查看答案
  1. 上下文漂移：AI 修了一个 Bug 但破坏了其他文件
  2. 回归模式：新功能不再遵循已有设计模式
  3. 团队扩张：超过一个人需要理解代码库
  4. 生产意图：真实用户或业务流程将依赖这个系统

问题 3：对于一个"内部管理仪表盘"项目（3 人团队，1 个月工期），推荐什么方法论组合？为什么？

查看答案

推荐 Vibe Coding + 少量 TDD：

  • 内部工具风险低、用户少，bug 影响有限 → Vibe Coding 快速出活
  • 但核心数据逻辑（如统计计算）→ 用 TDD 保证正确性
  • 不需要 SDD——团队小、工期短，写规格的投入产出比不高

下一节预告 ​

知道了融合工作流，但具体怎么判断"我的项目该用什么"？下一节给你一个可以直接用的决策工具。

→ 下一节：决策矩阵与转换信号