5 人 7 天干完 20 人数周的活：Spec-Driven Development 如何重新定义 AI 编程

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 办公效率, 网络安全, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/hVizUucsy8rwFOUR-VZ6wA

摘要

阿里妹导读文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。 "5 人 7 天" 震撼实验本文分享一个让人震撼的案例："5人、7天，用 Qoder 开发 QoderWork"——完成了传统需要 20 人数周的工作量。这不是 PPT 里的概念验证，而是一个已经上线的产品。它的时间线值得逐日复盘： DAY 0：不写一行代码，只写 Spec。 团队没有急着打开 IDE，而是花了一整天做四件事——定义 MVP 边界、拆解模块、为每个模块撰写 Spec、将所有 Spec 汇入 Repo Wiki。这一天的产出是零行代码，但它决定了后面六天的一切。 **DA...

核心内容

阿里妹导读

文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。

"5 人 7 天" 震撼实验

本文分享一个让人震撼的案例："5人、7天，用 Qoder 开发 QoderWork"——完成了传统需要 20 人数周的工作量。

这不是 PPT 里的概念验证，而是一个已经上线的产品。它的时间线值得逐日复盘：

DAY 0：不写一行代码，只写 Spec。

团队没有急着打开 IDE，而是花了一整天做四件事——定义 MVP 边界、拆解模块、为每个模块撰写 Spec、将所有 Spec 汇入 Repo Wiki。这一天的产出是零行代码，但它决定了后面六天的一切。

DAY 1-2：用 Qoder 完成架构开发。

框架与容器同步开发。每个人都是 "Spec 工程师"——不是写代码的人，而是定义代码应该长什么样的人。通过 Skill 驱动并行推进，Quest 模式同时执行多个开发任务。两天时间，系统骨架成型。

DAY 3-4：Spec 迭代增量需求。

发现新需求或 BUG？不用排期——立即写一个增量 Spec，委派 Quest 执行。AI 自动写代码并提交 PR，人负责 Review 与合并。单人日均处理多个 PR，效率惊人。

DAY 5-6：打磨、Dogfooding。

用 QoderWork 的早期版本测试 QoderWork 自身。发现问题？写 Spec，Quest 修复。这是一个自举式的正反馈循环。

DAY 7：正式发布上线。

七天，从零到一个可用的产品。

这个案例之所以震撼，不是因为 "AI 写代码很快"——快只是表象。真正值得追问的是：为什么 5 个人能驾驭 AI 同时推进这么多并行任务而不失控？

答案藏在 DAY 0 那个看似 "什么都没做" 的日子里。那一天写下的 Spec，就是整个项目的锚点。

这套方法论有一个正式的名字：Spec-Driven Development（SDD）。

一、SDD 是什么：代码只是 Spec 的副产品

1.1 一句话定义

Spec-Driven Development：将规格说明（Specification）作为唯一真实来源（Single Source of Truth），代码作为其派生产物。

用更直白的话说：先定义 WHAT，再让 AI 做 HOW。

这不是一个全新的发明。如果你做过 API-First Development、Design by Contract、或者严格的 TDD，你会觉得 SDD 似曾相识。但 SDD 的核心差异在于——它是为 AI 编程时代 量身设计的工程方法。

在传统开发中，Spec 写得好不好主要影响沟通效率；在 AI 编程时代，Spec 写得好不好 直接决定代码质量。因为 AI 不会追问你 "这个边界情况怎么处理"，它只会按照你给的上下文尽力推断——推断对了是运气，推断错了是 Bug。

1.2 不是一个人的发明，而是一个时代的汇聚

SDD 没有单一发明者。2025 年，多个方向同时收敛到了这个理念：

Karpathy 的 Vibe Coding（2025.2.2）作为反面参照，暴露了 "不管代码、只管 vibes" 的致命问题，倒逼社区思考 "AI 编程到底需要什么样的约束"；
GitHub 推出 Spec Kit，提供了 agent-agnostic 的 SDD 工具链；
AWS 发布 Kiro，成为第一个内置 SDD 工作流的 IDE；
Fission-AI 的 OpenSpec，走轻量迭代路线；
阿里的 QoderWork，通过 Qoder Quest 模式实践了 SDD 的规模化执行。
这种多方同时推动的局面，说明 SDD 不是某个团队的灵光一闪，而是 AI 编程发展到当前阶段的 结构性需求。

1.3 Microsoft 的那句点评

Microsoft 对 SDD 有一个精辟的评价：

"SDD is version control for your thinking."

传统的版本控制管理的是代码的演变历史。SDD 管理的是 思考的演变历史——为什么做这个功能、边界在哪里、成功标准是什么。当代码可以被 AI 秒级重写时，真正有价值的不是代码本身，而是代码背后的决策。

二、SDD 完整流程拆解

2.1 四阶段模型

SDD 的标准流程分为四个阶段：

Specify（规格定义）-> Plan（方案规划）-> Implement（代码实现）-> Validate（验证确认）阶段主导者核心产出关键动作Specify人spec.md定义问题、边界、成功标准Plan人 + AIplan.md架构选型、模块划分、接口定义ImplementAI代码 + 测试按 plan 逐任务实现Validate人 + AI测试报告自动化测试 + 人工 Review
人机分工的核心原则：人定义 WHAT，AI 实现 HOW。

这不是一个僵硬的瀑布流程。在实践中，Specify 和 Plan 之间会有多轮迭代，Implement 和 Validate 之间也是持续循环的。

2.2 三文件体系：Spec Kit 的核心设计

GitHub 的 Spec Kit 提出了一个简洁的三文件体系：

spec.md —— 需求规格

这是 "唯一真实来源"。它回答 "做什么" 和 "为什么做"，不涉及 "怎么做"。

-

Feature: 用户权限管理模块## Problem Statement当前系统缺乏细粒度的权限控制。所有用户要么是管理员（全部权限），要么是普通用户（只读权限）。产品团队需要支持至少 5 种角色，以满足不同部门的差异化需求。## Success Metrics- 支持自定义角色，每个角色可配置不少于 20 种独立权限- 权限校验 API 响应 P95 < 50ms- 权限变更实时生效，无需用户重新登录- 向后兼容：现有管理员/普通用户的权限行为不变## User Stories1. 作为系统管理员，我可以创建自定义角色并分配权限组合2. 作为部门主管，我可以将部门成员批量分配到指定角色3. 作为普通用户，我的权限变更后无需重新登录即可生效## Acceptance Criteria- [ ] RBAC 模型支持角色继承（最多 3 层）- [ ] 单用户可拥有多个角色，权限取并集- [ ] 提供权限变更审计日志，保留 90 天- [ ] 权限校验支持通配符匹配（如 `resource:*:read`）## Non-Goals- 本期不实现跨组织的权限委托- 不支持基于时间段的临时权限- 不涉及 UI 层的权限管理界面（由前端团队单独出 Spec）## Constraints-

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充