考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经）。AI coding 普及之后，"怎么让 agent 稳定产出符合预期的代码"成了核心问题，SDD（Spec-Driven Development，规范驱动开发）是社区给出的主要答案之一。面试官想看你有没有真的用 spec 驱动过 agent 干活：能不能说清为什么"直接口述需求让 agent 写"不可靠、spec 在流程里扮演什么角色；第二问对比 Spec-kit 和 OpenSpec 则是检验你是否关注过这个生态的具体工具，还是只停留在听说概念。追问可能往"spec 写多细合适""老项目怎么引入 SDD"上走。
参考答案
什么是 SDD
SDD 的核心主张一句话：规格说明（spec）是开发的单一事实来源，代码是 spec 的派生物。传统流程里文档是代码的附属品、写完就腐化；SDD 把它反过来——先写清楚"要做什么、为什么、验收标准是什么"，评审通过后再让 agent（或人）按 spec 实现，实现过程中 spec 持续更新，始终保持"spec 说什么、代码就是什么"。
为什么 AI coding 时代这件事变得重要？因为 agent 放大了"需求模糊"的代价。人写代码时需求不清会来回问，agent 不会——它会高高兴兴地按自己的理解写两千行，方向错了你还得逐行 review 才发现。spec 相当于把"对齐意图"这件事前置、显式化：agent 生成代码前先输出 spec，人审 spec 的成本远低于审代码，方向错误在写码之前就被拦住了。同时 spec 还是 agent 的上下文锚点：长任务执行中对话被压缩、上下文漂移，spec 文件始终在那里，agent 随时可以回去对齐。
一个典型 SDD 工作流
以 GitHub 开源的 Spec-kit 为例，流程是四段式：/specify 先把需求写成功能规格（用户场景、功能需求、验收标准，刻意不讨论技术方案）；/plan 在 spec 基础上产出技术实现计划（架构选择、涉及模块、数据模型）；/tasks 把计划拆成可执行、可验证的任务清单；/implement 按清单逐项实现。每段产出都是仓库里的 markdown 文件，段与段之间有人工评审的关口。
Spec-kit 与 OpenSpec 的区别
两者都是 SDD 工具，但设计重心不同，适合的场景也不同。
| 维度 | Spec-kit | OpenSpec |
|---|---|---|
| 定位 | 全生命周期脚手架 | 变更管理优先 |
| 流程 | specify → plan → tasks → implement 完整流水线 | proposal（为什么改）→ specs（能力规格）→ changes（增量变更） |
| spec 形态 | 每个 feature 一份完整规格 | 主 spec 描述系统现状，变更以 delta 形式叠加，合并后更新主 spec |
| 最适合 | 从零开始的新项目、greenfield 功能 | 已有项目的增量演进、存量系统 |
具体讲，Spec-kit 强在流程完整、开箱即用：四个斜杠命令把"从想法到代码"的路全铺好，还内置了宪法（constitution）机制定义项目不可违反的原则。代价是流程重，小改动走完全套流程显得繁琐，而且它的视角偏"每个功能独立立项"，对"系统当前的完整规格是什么"这个回答得不够好。
OpenSpec 的思路更像 git 之于代码：它管理的是变更本身。一个改动先以 proposal 目录存在（说明动机、列出会动到哪些 spec 的哪些条目），评审通过后 spec 增量合并进主规格。这样在任何一个时点，主 spec 都准确描述系统现状——这对老项目极其重要，因为存量系统最缺的就是一份活着的、可信的规格。它的流程比 Spec-kit 轻，适合持续演进的团队。
我的选择经验：新项目想快速建立规范用 Spec-kit 上手；项目已经在跑、主要诉求是"让 agent 改的每个东西都有据可查、规格不腐化"，OpenSpec 更合身。两者不互斥，社区里也有人用 Spec-kit 立feature、用 OpenSpec 管变更。
可能的追问
spec 应该写多细？ 细到"另一个人（或 agent）不看代码也能判断实现是否正确"：用户场景、输入输出契约、边界条件、验收标准必须有；技术选型写方向和约束，别把 spec 写成代码伪码，否则 review spec 就变成了 review 两遍代码。
SDD 会不会拖慢开发？ 小步快走的改动，spec 就是几行字，成本可忽略；真正花时间的是想清楚需求，而这个成本不花在这里就花在返工上。实证体感是：任务越复杂，SDD 越赚。
老项目没有 spec，怎么开始？ 不要补写全量 spec，从新变更开始：每个改动按 SDD 走，顺手把改动涉及模块的现状补进主 spec，几个月后核心模块自然就有活文档了。