研发模式从"代码为中心"转向"Spec为中心"
研发模式从"代码为中心"转向"Spec为中心"的含义解析
这句话描述了AI时代软件开发范式的根本转变：从关注"如何实现"转向关注"要做什么"，将需求规格（Specification，简称Spec）作为研发流程的核心驱动力。
一、核心概念：什么是Spec为中心
Spec为中心（Spec-Driven Development, SDD）是一种以结构化需求规格为起点的开发模式。在这种模式下：
- Spec不再是静态文档，而是可执行、可验证的生产原料
- 代码退居次要地位，被视为"从Spec自动生成的产物"
- 开发核心是定义和维护Spec，而非手撸代码
与传统模式的根本区别：
传统模式：需求 → 手写代码 → （可能）补文档
Spec模式：结构化Spec → AI生成代码 → Spec驱动全程
二、传统"代码为中心"的痛点
- 需求与实现脱节：文档常沦为摆设，代码实现与原始需求渐行渐远
- 上下文缺失：开发者"边写边想"，AI工具缺乏全局理解
- 低效的试错循环：陷入"生成-调试-修改-再生成"的玄学编程（Vibe Coding）
- 维护成本高昂：需求变更时，需人工遍历修改代码
三、Spec为中心模式的三大支柱
- 意图驱动开发
- 先明确"做什么"（What）和"为什么做"（Why）
- 而非"怎么做"（How）
- 开发者用自然语言精确描述产品场景，如"允许用户通过拖放整理相册，使用SQLite存储元数据"
- 结构化规格创建
- 通过模板和约束确保需求质量
- 规格采用可测试、可追踪的格式（如Gherkin、结构化Markdown）
- AI增强解释：利用Claude Code等工具解读规格意图
- 多步骤精化与生成
- 避免一次性生成，采用 Spec → 设计 → 任务拆解 → 代码 的渐进流程
- 工具链支持：GitHub spec-kit、Amazon Kiro、Tessl Framework等
四、Spec驱动的实践三层次
根据Thoughtworks和业界实践，SDD分为三个递进层次：
层次 描述 人类职责 AI职责
Spec-first 规格优先：先写深思熟虑的Spec，再基于它进行AI辅助开发 编写Spec、审查生成结果 按Spec生成代码
Spec-anchored 规格锚定：Spec长期保留，后续迭代和维护都基于原始Spec 维护Spec、验收变更 根据Spec更新代码
Spec-as-source 规格即源码：Spec是主要源文件，人类只编辑Spec，永不直接改代码 纯粹维护Spec 代码完全由Spec自动生成
目前主流实践处于Spec-first到Spec-anchored阶段，Tessl等激进工具已探索Spec-as-source。
五、对开发者工作流的变革
开发者角色转变
从编码者变为规格设计师：
- 60%时间用于需求澄清和规格定义
- 40%时间审查AI生成结果和解决边界问题
- 思维从"实现细节"转向"领域建模"
典型四步工作流（以spec-kit为例）
specify init：初始化项目环境和规格模板- 需求描述：用自然语言编写产品场景
- 技术规划：通过
/plan命令指定技术偏好 - AI生成：自动产出可执行代码和测试
效率与质量提升
- GitHub内部数据：新项目启动阶段节省37%时间，需求响应速度提升58%
- 自动生成代码的单元测试覆盖率达82%，远高于手动编码的65%行业均值
六、为什么现在发生这种转变？
- AI能力成熟：大模型已能胜任从Spec到代码的高质量转换
- 成本效益：清晰的Spec大幅减少AI"幻觉"和返工成本
- 工程化需求：企业需要将AI编程从"个人技艺"变为"可复制的工程实践"
七、总结：范式迁移的意义
这不是简单的工具升级，而是软件工程哲学的重构：
- 人类专注高价值活动：需求定义、架构设计、领域建模
- AI承担重复劳动：代码实现、测试生成、依赖管理
- 核心资产转变：代码变为"可丢弃的中间产物"，Spec成为"长期维护的知识资产"
正如Spec-Kit官网所言： "让组织专注于产品场景而非编写无差别的代码" 。未来最值钱的不再是"写代码"能力，而是 "定义清晰规格" 的能力。
适应建议：开发者应尽早学习需求工程、领域驱动设计（DDD）和结构化写作，培养将模糊需求转化为精确Spec的能力。
浙公网安备 33010602011771号