我的书签
添加书签
移除书签1. 规范驱动开发（Spec-Driven Development, SDD）
What
规范驱动开发是一种以“规范文档”为核心的工程方法论。它要求：开发流程的每一步（需求、设计、编码、测试、交付）都必须以明确的规格（specifications）为依据，而不是传统的“先写代码后补文档”模式。在 SDD 中，规范不仅仅是参考文本，而是可执行、可生成代码和测试的源头。
Why
传统开发中，规范（如需求文档、设计文档）容易和代码实现脱节，导致沟通成本高、需求变更难、质量不可控。SDD 通过让规范成为唯一事实源（source of truth），可以：
- 保证需求与实现完全对齐
- 降低协作中的误解和返工
- 让变更快速同步到全部工程环节
How
spec-kit 通过 CLI 和 AI 工具链，实现“规格→实现”的自动化流程：
- 用户通过
/specify命令描述需求，生成结构化规格文档 - AI 解析规格，自动生成技术方案和实现计划（/plan）
- 规格文档内嵌测试用例、关键实体、约束等信息
- 代码、测试、文档均直接由规格驱动生成和更新
2. Intent-Driven Development（意图驱动开发）
What
意图驱动开发强调开发活动应以“业务目标和用户需求”为基础，先明确“做什么、为什么”，再决定“怎么做”。即先聚焦 specification 的内容和目的，而非具体的技术细节和实现方式。
Why
如果团队一开始就讨论技术方案，容易忽略用户价值和业务目标，导致技术“过度设计”或“南辕北辙”。Intent-driven 方法能：
- 保证所有实现都服务于明确业务目标
- 让需求和设计始终围绕用户和场景展开
- 避免技术细节绑架产品方向
How
spec-kit 的规格模板强制要求：
- 先用自然语言描述功能、场景和目的
- 明确“WHAT”和“WHY”，明确业务价值
- 技术选型和具体实现推迟到 /plan 阶段，规格阶段不允许出现技术方案
- AI/工具自动识别和标记未明确意图的部分，要求补充澄清
3. Executable Specifications（可执行的规格）
What
“可执行规格”指的是：规格文档不仅仅是静态文本，而是足够明确、完整、无歧义，以至于可以自动生成代码、API 合约、测试用例等实际工程产物。
Why
传统的规范文档往往被“忽略”或“过时”，因为它们无法直接被工具或系统消费。让规格成为“可执行”的，可以：
- 消除规格与实现的割裂
- 降低人工解释错误
- 自动生成/验证代码和测试，提升效率和一致性
How
spec-kit 的实现方式包括：
- 规格模板结构化（功能需求、实体关系、测试场景等）
- 明确要求所有需求必须是可测试、可验证的
- 通过 AI 解析规格，自动生成对应的代码框架、API 合约和测试逻辑
- 规格变更后，相关代码和测试自动重新生成与同步
4. Continuous Refinement（持续精炼）
What
持续精炼是指：规格文档不是一次性定稿，而是在整个开发生命周期中不断完善和调整，确保始终与业务目标和技术实现保持一致。
Why
需求和技术环境总是在变化。如果规格一旦定稿就不再维护，工程很快会偏离初衷。持续精炼可以：
- 及时发现和解决歧义、遗漏
- 跟踪业务和技术变更
- 保证规格是活的、可用的，而不是“文档墓地”
How
spec-kit 实现持续精炼的方法有：
- 规格文档内嵌 [NEEDS CLARIFICATION] 标记，强制记录未明确或有疑问的地方
- 每次变更自动触发 AI/工具审查，发现冲突、重复、遗漏
- 变更历史和评审流程纳入版本控制
- 生产环境反馈（如性能、故障）反哺规格修正
5. Research-Driven Context（研究驱动背景）
What
研究驱动指的是：在规格和技术方案制定过程中，自动收集技术选型、性能、安全、合规等背景信息，辅助决策和落地。
Why
工程师或团队常常缺乏对最新技术动态、组织约束、性能要求等的全局把控。研究驱动可以：
- 帮助团队做出更合理的技术决策
- 提前发现潜在风险和约束（如合规、兼容性）
- 让规格更具现实可行性
How
spec-kit 的落地方式包括：
- 研究代理（Research Agent）自动查找、汇总相关技术资料和组织标准
- 技术方案文档（/plan）中自动嵌入研究结论和选择理由
- 变更或补充需求时，自动提示需重新研究的部分，触发 parallel research 任务
6. Bidirectional Feedback（双向反馈）
What
双向反馈是指：工程实施和生产环境的实际表现（如性能指标、故障、用户反馈），反过来影响和完善规格文档，形成循环优化。
Why
如果规格只在初始阶段制定，后续从未根据实际表现调整，将很难持续提升产品质量。双向反馈可以：
- 持续提升规格的科学性和实用性
- 让工程管理和质量控制形成闭环
- 实现“数据驱动优化”而不是“经验主义”
How
spec-kit 的反馈机制包括：
- 生产环境的监控、指标、事故自动归档为“新需求”或“变更”
- AI/工具自动分析反馈内容，生成新的规格或修正建议
- 迭代周期内自动同步到规格文档，触发相关代码和测试再生成
7. Branching for Exploration（并行分支探索）
What
并行分支探索指的是：同一规格可以生成/探索多种技术实现或架构方案，便于团队做方案对比和创新实验。
Why
复杂项目常常面临技术选型、架构设计的多方案权衡。并行探索可以：
- 降低“单选失败”的风险
- 促进创新和性能优化
- 支持多团队/多技术栈协作
How
spec-kit 的实现方式包括：
- 每个 feature/规格自动生成独立分支存档
- 技术方案（/plan）可以生成多套实现计划
- 任务列表（/tasks）支持并行分组和执行，标记可并行 [P]
- 评审/实验后选择最优分支合并到主线
8. 宪法式架构原则（Nine Articles）
8.1 Library-First Principle（模块化优先）
What
所有功能都要先以独立库的形式实现，避免直接嵌入主应用，确保可复用和解耦。
Why
避免项目结构臃肿、代码难维护、复用性差。模块化能：
- 降低耦合度
- 提升可复用性和可测试性
- 支持并行开发和微服务化
How
spec-kit 强制每个 feature 从库开始：AI 生成实现方案时，必须先创建库分支、定义边界和依赖，禁止直接写主应用代码。
8.2 CLI Interface Mandate（命令行接口强制）
What
每个库必须以命令行形式暴露功能，输入输出均为文本或 JSON，支持多种交互方式（stdin、参数、文件）。
Why
CLI 便于测试、自动化、集成，也能降低“黑箱”风险。好处：
- 易于脚本化和持续集成
- 提升可观测性
- 降低依赖于具体 UI 或框架
How
spec-kit 的代码模板自动生成 CLI 包装，AI 方案中必须包含 CLI 设计说明和用例，规范接口协议。
8.3 Test-First Imperative（测试优先）
What
所有实现都必须先写测试（API 合约、集成测试、单元测试），且测试需经用户验证通过后，才能开始写代码。
Why
测试优先能确保需求完全被覆盖，避免“代码写完才发现需求变更”。优势：
- 提升质量和可维护性
- 避免遗漏和歧义
- 支持自动化验收与回归
How
spec-kit 流程约束：AI/工具自动生成测试文件，用户必须提前审查并通过，代码只能保证让测试通过为目标。
8.4 Simplicity & Anti-Abstraction（简化结构与反抽象）
What
项目结构必须最简，功能不超过 3 个初始项目，禁止无必要的抽象层，优先直接用框架原生特性。
Why
过度抽象和结构复杂会导致维护难度激增。简化结构能：
- 降低学习和维护成本
- 保持清晰边界
- 避免“为未来而设计”导致的臃肿
How
spec-kit 在实现方案模板中设立“简化门槛”：AI 必须逐项自检是否过度抽象，超标需写明理由并评审。
8.5 Integration-First Testing（集成优先测试）
What
测试必须以真实环境为主，优先做合约、集成和端到端测试，避免只做隔离的单元测试。
Why
真实环境测试能发现实际问题，保证上线后稳定性和兼容性。好处：
- 实际可用性保障
- 发现环境相关 bug
- 保证接口和系统集成无误
How
spec-kit 流程强制 test-first，且测试必须用真实数据库、服务等，AI 自动生成合约和集成测试用例，用户可自定义补充。
9. 关键实体与角色
9.1 Spec（规格文档）
What
描述业务目标、功能需求、用户场景、数据实体、测试标准等的主文档，是一切实现的依据。
Why
统一团队认知，让需求、设计、开发、测试有一致的“源头”，避免割裂和误解。
How
spec-kit 通过结构化模板和命令自动生成规格，支持自然语言补充、AI解析和自动标记待澄清点。
9.2 Entity（业务实体）
What
指系统中的核心数据对象，如用户、消息、任务等，定义属性和关系。
Why
业务实体是需求落地和数据建模的基础，影响接口、数据结构和测试。
How
规格模板中自动要求列出所有实体及其属性关系，AI 根据业务场景自动生成模型和接口。
9.3 Contract（API 合约）
What
定义系统内部或外部的接口协议，包括输入输出、错误处理、调用方式等。
Why
API 合约是系统协作的保障，确保不同模块/团队可以无缝对接。
How
spec-kit 自动生成合约文档和测试用例，代码实现必须严格遵循合约。
9.4 Test Scenario（测试场景）
What
覆盖所有功能和边界条件的测试方案，包括自动化测试、手工验收测试等。
Why
测试场景能保证需求被完全覆盖，防止遗漏和隐患。
How
规格模板强制列出所有用例，AI 自动生成对应测试代码。
9.5 Implementation Details（实现细节）
What
具体的代码结构、算法说明、技术选型等，是规格的落地表达。
Why
让开发团队明确如何实现、用什么技术、如何满足业务需求。
How
spec-kit 自动分离高层规格和细节文件，AI 生成技术方案和代码框架，支持人工补充。
9.6 角色分工
产品经理/需求分析师
- 负责业务规格撰写和澄清
- 驱动全流程的 WHAT/WHY
开发者
- 根据规格自动/手动实现代码
- 参与技术方案和测试用例完善
测试人员
- 依据规格生成和执行测试
- 反馈覆盖率和缺陷
AI/Copilot
- 自动解析规格、生成代码和测试
- 辅助发现歧义和优化方案
研究代理（Research Agent）
- 辅助技术选型、调研标准和约束
- 保障实现方案可落地
