AI 编程把代码生成速度拉高之后很多团队反而发现返工率上升了。代码写得越快需求理解错得越早返工成本就越高。问题通常不在 AI 生成的代码质量而在需求从“人说的话”变成“可执行代码”的过程中缺少中间产物。Spec Kit 的完整工作流就是围绕“需求评估 - Specify - Plan - Tasks”四个环节把每次需求变化都记录成可评审、可追溯的工程资产。下面会顺着这条主线做一次完整拆解每个阶段做什么、产物是什么、怎么判断是否完成、过程中常见的坑在哪里以及如何结合 AI Agent 和 Coding Plan 这类模式落地。先理解一个核心判断AI 编程的返工绝大多数不是写代码阶段造成的而是“编码前信息不完整”造成的。返工成本不是 AI 生成代码的成本而是“需求误解被代码固化之后再改回来”的成本。Spec Kit 做的事是在编码前增加几层轻量的“翻译和确认”让需求每变化一次都有地方留下记录让 AI 每次动手前都基于最新规格而不是模糊记忆。1. 为什么 AI 写得越快返工反而越多1.1 生成速度快放大了需求误解传统开发中写代码是相对昂贵的环节所以团队会在写代码前做评审、设计、澄清因为改文档便宜、改代码贵。到了 AI 编程阶段写代码变得极其便宜代价转移到“确认需求是否正确”这件事上。如果不经过需求评估就把一句话丢给 AI它会在几百毫秒内生成一个结构完整、风格统一、但可能完全不是业务想要的实现。速度越快错误实现产生得越早浪费越大。从这个角度看“AI 写得快”不是 bug而是特性。真正的问题是团队没有为“快”建立新的检查点。过去代码慢评审机会发生在编码前现在代码快必须把评审前移到规格层。否则团队等于用汽车的速度跑在没有护栏的山路上出事只是时间问题。1.2 返工主要发生在“做什么”和“怎么做”之间返工可以分成两类。一类是“怎么做”返工例如接口设计不合理、命名不一致、事务边界错误这类通常可以靠代码评审和重构解决。另一类是“做什么”返工例如业务规则理解错、边界条件漏掉、验收标准不明确这类等代码写完才发现成本非常高。AI 编程最常见的返工集中在第二类。因为 AI 不会主动承认自己不理解需求它只会基于上下文生成最符合概率的答案。用户给的信息越少它补充的假设就越多。比如只说“做订单超时关闭”AI 可能默认 15 分钟、默认只改状态、默认不释放库存。这些默认值一旦进入代码就变成了隐藏需求后续排查时极难定位。1.3 关键矛盾上下文不足时 AI 只能快速产出“看起来正确”的方案这里有一个经验判断AI 代码生成质量高度依赖上下文质量。上下文包括需求背景、约束条件、现有项目结构、验收标准、异常分支。上下文不足时AI 不是无能为力而是会尽力补全补全出来的结果往往“读起来合理跑起来错位”。Spec Kit 的工作方式就是把这些上下文变成显式输入。它不让 AI 直接写代码而是先让 AI 参与需求评估、形成规格说明、制定实施计划、生成任务列表。每一步都有产物每一步都能被打回每一步变化都有记录。这样 AI 的“快”才被约束在正确轨道里。注意不要只验证 AI 能生成代码要验证它生成代码前是否已经正确理解规格。这个判断适用于所有 AI 辅助编码场景。2. Spec Kit 是什么先让“要做什么”变成可评审的规格2.1 它是方法组合不必然是一个安装包这里讨论的 Spec Kit在不同团队里落地形态可能不同。有的团队把它封装成 CLI 工具通过交互命令生成规格文档有的团队把它做成提示词模板把评估、规格、计划、任务四段放进 AI Agent 的系统提示词有的团队只用一套 Markdown 模板在代码仓库里建specs/目录每次需求变化就更新对应文档。在正式拆解之前先明确这里讨论的 Spec Kit 是指一套“需求到任务的工程化产物”核心链路是需求评估Requirement Assessment- 规格化Specify- 计划Plan- 任务Tasks这里的“Spec”指规格说明不是代码规范“Kit”指一组模板、工具和检查清单。无论技术栈是什么这套链路都成立。2.2 四阶段分别解决什么问题可以用一张表概括阶段核心问题主要产物通过标准需求评估这件事值不值得做范围是什么需求评估记录、范围说明业务方和开发对目标一致Specify到底要做什么不做什么规格说明文档或结构化文件边界条件、异常分支、验收标准齐全Plan按什么顺序做需要改哪些模块实施计划、依赖关系每个步骤都有输入和输出可评审Tasks谁在什么时间做什么状态如何任务列表、变更记录每个任务可执行、可验证、可回溯这里有两点值得注意。第一Specify 的产物不是用户故事一句话而是把“业务目标”翻译成“系统行为和边界条件”。第二Plan 和 Tasks 不能混为一谈。Plan 回答的是“实现路径”Tasks 回答的是“执行单元”。很多团队只在 Tasks 层记录变化漏了 Plan 和 Spec 层结果需求变化后任务改了但规格没有同步最终代码仍然基于过期理解生成。2.3 为什么它能减少返工返工的本质是信息在传递过程中失真。传统流程里业务方把需求说给产品经理产品经理写成文档开发再理解文档每一层都可能失真。AI 编程让“开发理解”这一步变成了“prompt 到代码”的直接映射失真没有消失而是被压缩进了 prompt。Spec Kit 的做法是在最前面加了一层“结构化确认”。规格写出来之后人可以评审AI 可以复述测试可以根据验收标准设计用例代码生成只是最后一个执行步骤。等于把最容易出错的“需求理解”环节从隐性的 prompt 里剥离开来变成一份显式资产。3. 需求评估先判断值不值得进入规格化3.1 评估阶段要收集的信息需求评估不是写完整需求文档而是做一个“少走弯路”的预判。在把需求交给 AI 之前至少要问出四类信息原始诉求业务方用一句话描述的期望不加工、不美化。业务目标解决什么问题用什么指标判断成功。约束条件时间窗口、技术栈、数据量、合规要求、已有模块。验收口径怎么验证做完了谁来判断结果正确。这里最常见的错误是跳过评估直接写规格。尤其当需求看起来很简单时团队容易产生“这个不用评估直接让 AI 改一下就行”的判断。但简单需求往往意味着上下文少AI 只能靠猜。3.2 用评估模板固定思考路径实际项目里可以用一个 Markdown 模板每次需求进来先填一遍## 需求评估 - 需求编号REQ-2025-001 - 来源业务方 / 用户反馈 / 内部优化 - 原始描述一句话说清楚要什么 - 业务目标解决什么问题量化指标是什么 - 约束条件 - 技术栈限制 - 数据量级 - 上线时间 - 合规与权限要求 - 涉及已有模块 - 验收口径 - 决策进入 Specify / 暂缓 / 不需要开发 - 评估人 / 日期模板的价值不是增加文档负担而是强制团队回答“AI 不知道、但代码必须知道”的问题。业务目标可以避免“功能做出来了但业务不认”约束条件可以避免 AI 在实现时选了错误的技术路线验收口径是后续测试用例和任务完成判断的依据。3.3 评估结果如何流向 Specify评估通过后不要把评估记录丢到聊天窗口里。建议把上面内容整理成仓库内的一段记录并把需求编号带进后续所有规格、计划和任务。这样当需求变化时可以通过编号追溯到最初意图而不是翻聊天记录。如果评估结论是“暂缓”也要保留记录。后续再次提出类似需求时可以避免重复分析。如果评估结论是“不需要开发”原因是“已有功能覆盖”同样建议写下来防止 AI 在后续重构中又把这个逻辑当作新需求实现一遍。4. Specify把自然语言翻译成机器和人都能读懂的规格4.1 规格文件的必备字段Specify 阶段的目标是把需求评估的结论细化成“系统行为描述”。一条可以直接交给 AI 的规格通常包含以下字段需求标识和要求标题用户故事或业务场景业务规则边界条件和异常分支非目标Out of Scope验收标准数据变更和接口影响4.2 不要让 AI 直接面对“自然语言小作文”很多人写 prompt 时习惯写一段很长的自然语言例如“帮我把订单系统改造一下要让超时的订单自动关闭同时还要考虑库存回补性能也要好一点注意不要影响线上”。这类描述信息密度低AI 只能提取关键词然后自由发挥。推荐做法是把关键信息结构化。以 YAML 为例下面是一个订单超时自动关闭的简化规格spec: id: SPEC-2025-001 title: 订单超时自动关闭 user_story: 用户提交订单后超过可配置时间未支付系统自动将订单状态改为已关闭 business_rules: - rule_id: BR-001 content: 超时时间可配置默认 30 分钟 - rule_id: BR-002 content: 只有待支付状态订单参与超时判断 - rule_id: BR-003 content: 超时关闭后回补库存并释放优惠券 - rule_id: BR-004 content: 已部分支付的订单不自动关闭 edge_cases: - 支付回调与超时任务并发时以支付成功为准 - 关闭操作必须幂等重复执行不产生副作用 - 订单已进入关闭流程时用户再次支付需要返回明确错误 out_of_scope: - 用户主动取消订单 - 退款、售后流程 - 短信和消息通知 acceptance_criteria: - AC-001: 给定超时时间 30 分钟和待支付订单超过 30 分钟后订单状态变为已关闭 - AC-002: 支付回调在超时前到达订单不关闭 - AC-003: 库存回补数量与订单商品数量一致 - AC-004: 超时关闭任务重复执行两次结果保持一致结构化的好处有三个。第一AI 可以逐条消费信息不会漏掉关键规则。第二人可以快速评审看到 BR-004 就知道“部分支付”场景是否被覆盖。第三测试人员可以直接把 AC-001 到 AC-004 转成测试用例验收标准不再是抽象描述。4.3 边界条件和异常分支是返工重灾区AI 生成代码时最容易漏掉的是异常分支。传统开发中开发人员会因为既往经验主动询问“如果支付并发怎么办”。AI 不会提问它只会根据上下文补全一个合理分支。因此规格描述里必须显式列出边界条件。实际项目中边界条件的来源包括时间边界刚好 30 分钟、状态边界待支付、已关闭、支付中、并发边界回调与定时任务同时发生、幂等边界重复执行、数据边界空列表、超大批量、权限边界无权限用户提交操作。如果规格里没有这些AI 生成后大概率需要返工。返工点不在 AI而在规格缺失。4.4 规格评审让 AI 复述理解而不是直接生成代码在把规格交给 AI 生成 Plan 之前可以多花一步让 AI 用自己的话复述规格并列出它识别出的关键规则和至少三个潜在边界问题。这一步非常便宜却能提前暴露理解偏差。一个简单的 prompt 模式如下你对下面这份规格有什么理解请用自己的话重述核心业务规则列出 1. 你识别到的业务规则 2. 你判断需要进一步澄清的地方 3. 你担心会出错的边界场景 不要生成代码不要开始设计接口。如果 AI 复述出的业务规则和原规格不一致就说明规格还不够清晰或者 prompt 里混入了多余信息。先修正规格再进入下一步不要急着生成代码。建议如果 AI 复述出的业务规则和原规格不一致先修正规格再进入下一步不要急着生成代码。5. Plan把规格拆成可执行、可验证的实施路径5.1 Plan 不是任务清单规格确认后下一步是制定 Plan。Plan 与 Task 的区别在于Plan 关注“改动路径”Task 关注“执行单元”。Plan 至少要回答三个问题要改动哪些模块和服务这些改动之间有什么依赖关系每一步完成时如何验证结果如果把 Plan 直接写成平铺任务清单AI 可能先做第二步再回补第一步导致中间状态丢失甚至产生编译错误。因此 Plan 需要表达依赖顺序。5.2 从规格推导模块、接口和数据变更一个从规格推导 Plan 的方法是逐条分析规格中的业务规则和验收标准问三个问题这条规则需要改数据库吗如果要改哪些表、哪些字段这条规则需要新增或修改接口吗如果要请求和响应结构是什么这条规则需要新增或修改业务逻辑吗如果要放在哪个服务或模块里以订单超时关闭为例Plan 可以这样组织plan: id: PLAN-2025-001 based_on: SPEC-2025-001 steps: - step_id: 1 title: 调整订单状态模型 changes: - 新增超时关闭时间字段 - 新增超时任务执行状态字段 verification: 数据库迁移可回滚订单状态枚举包含已关闭 depends_on: [] - step_id: 2 title: 实现超时检测与关闭主流程 changes: - 新增定时任务或延迟消息处理 - 查询待支付且超过超时时间的订单 verification: 单测覆盖 AC-001 和 AC-002 depends_on: [1] - step_id: 3 title: 实现库存回补与优惠券释放 changes: - 调用库存服务回补接口 - 调用优惠券服务释放接口 - 处理回补失败后的重试或补偿 verification: 库存回补数量与订单商品数量一致 depends_on: [2] - step_id: 4 title: 幂等与并发处理 changes: - 关闭操作使用事务和唯一约束 - 处理支付回调与超时任务并发 verification: 重复执行两次结果一致 depends_on: [2, 3]这里的关键是“每个 step 有明确验证方式”。验证方式不一定是完整测试至少要让 AI 主动说明做完这一步后用什么命令、什么用例、什么日志来判断它没有做偏。这个习惯能显著减少返工。5.3 和 Coding Plan、Token Plan 的关系近期的 AI 编程工具普遍开始提供“先规划、再执行”的模式。比如某些工具会先输出一个 Plan用户确认后才继续写代码有些产品按 Coding Plan 或 Token Plan 的方式管理一次性任务额度。这些形态看起来是产品功能底层逻辑和 Spec Kit 一致先消耗少量上下文和 token 做规划再让 AI 基于规划生成避免大量 token 被花在错误方向上。使用这类模式时不要只把 Plan 当成“让 AI 停下来等确认”的开关而要把 Plan 内容保存下来和规格关联。否则计划通过后AI 执行过程中仍然可能因为上下文被截断而偏离计划。5.4 计划变更时保留旧版本的执行路径需求变化在项目中不可避免。Plan 变更时不要直接覆盖旧计划建议保留历史版本。最简单的方式是在代码仓库目录中按版本号保存或者在文档顶部维护变更记录2025-01-12 14:00超时时间从 15 分钟调整为 30 分钟 影响PLAN-2025-001 的 step 2 中查询条件需要修改step 1 的影响较小 原因业务方希望给用户更多支付缓冲时间这条记录的用途是让 AI 在后续开发中理解“为什么现在的计划和最初不同”。如果直接删除旧版本后续生成代码时可能又会按旧逻辑实现。6. Tasks把计划拆成原子任务让变化有迹可循6.1 任务粒度怎么定任务粒度过大AI 容易在一个任务里自由发挥最终结果难以 review。任务粒度过小计划和执行成本增加AI 频繁切换上下文也会浪费 token。一个比较合理的参考标准是一个任务只改一个关注点。一个任务的输出可以被验证。一个任务失败时影响范围可以定位。例如“实现订单超时关闭主流程”可以拆成多个任务但不要拆到“写一个 if 分支”这种程度。Task 更接近于“完成一个可验收的 commit”的粒度。6.2 任务状态如何与需求变化关联每个 Task 建议带上规格编号、计划编号、需求编号。示例task: id: TASK-2025-001-02 req_id: REQ-2025-001 spec_id: SPEC-2025-001 plan_id: PLAN-2025-001 title: 修改订单状态枚举增加已关闭状态 status: 进行中 acceptance: 状态枚举包含已关闭已有代码可正常编译 log: - time: 2025-01-12 15:30 event: 超时时间从 15 分钟调整为 30 分钟 impact: 该任务描述中的固定时间改为读取配置当需求变化影响到某个任务时不要只改任务描述还要在log里记录“变化前是什么、变化后是什么、影响面是什么”。这样即使过了几周AI 重新读取任务列表时也能理解为什么当前任务长成这样。6.3 每次需求变化都应该留三类记录很多团队在需求变化时代码改了、任务改了但记录没有同步导致 AI 在后续对话中继续沿用旧上下文。建议至少维护三类记录记录位置记录内容作用需求评估记录需求背后的业务目标、验收口径变化避免“功能实现正确但方向错了”规格变更记录业务规则、边界条件、非目标变化避免 AI 按旧的业务规则生成代码计划与任务变更记录改动路径、依赖关系、任务状态变化避免执行链路断裂便于定位返工点6.4 任务完成后如何和规格回对任务完成后不要直接宣布完成。建议做一个“规格回对”让 AI 按验收标准逐条自检请根据 SPEC-2025-001 的验收标准逐条检查你的实现 - AC-001 是否通过如何验证 - AC-002 是否覆盖如何验证 - AC-003 是否覆盖如何验证 - AC-004 是否覆盖如何验证 逐条回答不要跳过。如果某条没有覆盖给出原因和修复计划。这里的关键是“逐条回答不要跳过”。AI 倾向于输出完成结论如果不强制逐条自检它可能只挑自己实现良好的部分回答漏掉边界场景。自检结果应当作为任务完成记录的一部分归档。注意AI 倾向于输出完成结论如果不强制逐条自检它可能只挑自己实现良好的部分回答漏掉边界场景。7. 在 AI Agent 和主流编码工具中如何落地7.1 把 Spec Kit 变成 Agent 的执行约束如果团队使用 AI Agent 辅助编码Spec Kit 可以进入 Agent 的系统提示词或工具说明。例如在 Agent 开始任何代码修改之前强制它先读取规格文件再读取计划最后读取任务。不要允许 Agent 在缺少规格的情况下直接生成代码。一个简化的 Agent 规则可以这样写你在执行编码任务时必须遵守以下流程 1. 先找到关联的 SPEC 文件并总结业务规则。 2. 再找到关联的 PLAN 文件并说明当前步骤。 3. 只修改当前 TASK 涉及的代码。 4. 每次修改后对照 acceptance_criteria 检查。 5. 如果发现规格缺失或前后矛盾停止编码并提问。这个规则看起来简单但它把“先理解再动手”变成 Agent 的默认行为。实际使用中如果 Agent 忽略规则可以通过输出解析和工具调用校验例如在它执行写文件之前检查当前上下文是否已包含规格内容。7.2 结合编码工具中的 Plan 模式很多 AI 编程工具开始提供 Plan 模式。使用这类模式时建议把“Specify”和“Plan”分开先让 AI 输出对规格的理解再让 AI 输出实施计划确认后再切到执行模式。不要把 Plan 输出和代码生成放在同一次对话里。在实际操作中可以分两次对话第一次让 AI 读取规格文件复述业务规则给出实施计划。第二次让 AI 按计划生成代码并逐条对照验收标准。这样做的原因是一次对话里如果既要求规划又要求写码AI 很可能为了效率直接生成代码规划部分就变成了形式化的“假计划”。7.3 版本管理是 Spec Kit 落地的关键规格、计划、任务建议和代码一起纳入版本管理。可以在仓库根目录建立specs/ REQ-2025-001/ assessment.md spec.yaml plan.yaml tasks/ task-001.md task-002.md代码变更和规格变更可以放在不同 Pull Request 中或者在同一个 PR 中明确标注规格变更点。好处是当需求变化时reviewer 可以同时看到“规格为什么变”和“代码改了什么”。如果规格与代码不一致PR 应该被打回。7.4 最小落地路径一个人也能用不需要一开始就建立一个复杂的流程。推荐按下面顺序逐步落地先从最痛的需求开始增加一份规格文件。在 AI 生成代码前先让它复述规格。规格确认后再让它输出 Plan。Plan 确认后再进入 Tasks 执行。需求变化时先更新规格再更新计划和任务最后改代码。如果团队只有一个人也可以使用“规格文件 一次 Plan 对话 逐任务自检”的最小组合。这套方法不依赖任何特定商业工具。8. 常见坑与排查链路8.1 AI 生成了代码但需求实现错了现象AI 生成的代码能编译、能运行但业务方看后说不是自己要的。可能原因需求评估阶段没有形成业务目标。规格文件只写了用户故事没写业务规则和异常分支。交互 prompt 中混入大量历史对话AI 被旧信息干扰。AI 被直接要求“生成整个功能”没有先复述理解。排查顺序先看需求评估记录确认业务目标和验收口径是否记录。再看规格文件检查非目标和边界条件是否缺失。让 AI 读取规格后复述业务规则对比是否存在偏差。如果偏差出现在复述阶段说明 prompt 上下文或规格表达有问题。修正规格后重新生成不要在原代码上反复打补丁。8.2 规格改了但任务列表没有同步更新现象规格从 15 分钟超时改为 30 分钟但代码里还是写死 15 分钟任务描述也没变。可能原因任务没有关联规格编号。需求变化发生时只在聊天里说明没有回写规格和任务文件。团队成员认为“小改动不需要记录”。排查顺序搜索任务文件中有没有spec_id或req_id字段。检查需求变化发生时是否有变更记录日志。如果任务和规格没有关联说明流程建设不完整先补齐关联字段。重新读取最新规格让 AI 找出任务描述中与规格不一致的地方。8.3 Plan 通过后实现过程中仍然偏航现象Plan 阶段 AI 列出的步骤很清楚但执行时跳过了某一步或使用了计划外的实现方式。可能原因单次对话上下文过长AI 丢失了计划后段内容。任务没有被拆成独立步骤AI 一次性完成太多改动。Plan 中的步骤没有验证方式AI 无法判断自己是否做偏。用户没有要求 AI 按 step 逐个执行。排查顺序回到 Plan 文件确认当前步骤的depends_on是否满足。限制当前对话只处理一个 Task不要一次对话执行整个 Plan。在 Plan 的每个 step 中增加 verification 字段让 AI 先自检再进入下一步。如果上下文窗口受限把整个 Plan 拆成多次独立对话每次携带完整规格摘要。8.4 需求变化频繁不知道返工成本从哪里来现象一个看似简单的功能反复修改团队感觉“AI 改一次崩一次”。可能原因没有需求评估每次都是直接让 AI 改代码。规格没有维护变更记录AI 基于多个历史版本混合生成。验收标准不明确测试无法判断是否完成。排查顺序先统计最近几次返工分别属于“做什么返工”还是“怎么做返工”。如果是“做什么返工”问题大概率在 Specify 阶段之前。修复方式不是增加更多代码而是先冻结需求把规格补全。对频繁变化的参数例如超时时间、费率、开关做配置化减少后续代码级改动。针对这些问题整理成一张速查表现象常见原因优先检查处理建议代码能跑但不是业务要的需求评估或规格缺失需求评估记录、规格文件先补规格再让 AI 复述确认小改动反复返工业务规则未结构化规格中的 business_rules拆成规则条目逐条覆盖计划通过后实现偏差任务粒度太大Plan 的 step 和 verification拆小任务每步自检改需求后代码旧逻辑残留变化仅存在于聊天记录变更记录和任务日志回写规格、Plan、Tasks 三层记录Token 消耗高但交付效果差直接生成代码缺少规划是否有 Plan 和自检先规划再执行降低无效生成9. 从个人试用走向工程实践落地清单与扩展方向9.1 推荐的最小文件结构建议在代码仓库中维护一个规格目录结构如下docs/specs/ REQ-2025-001/ README.md # 需求评估记录 spec.yaml # 规格化描述 plan.yaml # 实施计划 tasks/ # 任务和变更记录 REQ-2025-002/ ...这个结构对个人项目和团队项目都适用。个人项目可以把 README.md 省略只保留spec.yaml和plan.yaml两个文件。重点是文件和任务之间存在可追踪的 ID 关联而不是文件数量。9.2 学习环境与生产环境差异如果只是在学习 AI 编程可以不需要完整流程直接体会“规格文件 复述确认”的效果。但进入生产环境时建议至少增加以下能力关注点学习环境生产环境需求记录可以只写在对话里入库或版本管理可追溯规格变更直接改 prompt保留变更记录绑定需求编号代码验证编译通过即可单测、集成测试、验收用例逐条对应权限与安全本地示例代码审查、最小权限、敏感信息不入库回滚方案不需要迁移脚本可回滚规格历史可恢复资源消耗关注效果关注 token 成本和执行时长增加规划阶段9.3 发布前检查清单每次需求上线前可以对照以下清单[ ] 需求评估记录包含业务目标、约束条件、验收口径。[ ] 规格文件包含业务规则、边界条件、非目标和验收标准。[ ] 计划文件包含每个 step 的依赖关系和验证方式。[ ] 任务列表与规格、计划存在关联编号。[ ] 所有需求变化都在变更记录中留痕。[ ] AI 对规格做过复述确认和原规格一致。[ ] 代码实现已按验收标准逐条自检。[ ] 涉及生产环境时迁移脚本、权限、监控和回滚方案已确认。这个清单不一定在初期全部满足但至少要意识到它存在。流程越轻量越好但关键记录不能丢。9.4 扩展方向Spec Kit 的思路并不局限于 AI 编程。它适合所有“快速生成内容但难以校验质量”的场景包括测试用例生成、接口文档生成、数据迁移脚本生成、代码评审辅助等。如果团队基于 Spring AI 等框架搭建内部智能体也可以把规格文件作为 Agent 调用工具前的约束让 Agent 在变更数据库结构或调用外部服务前先检查规格和计划。对个人开发者而言最有价值的练习是下一个需求不要直接让 AI 写代码先花 20 分钟写一份规格再让 AI 复述和给计划。对比一下“有规格”和“无规格”两种方式的返工次数、上下文长度和代码改动量。多数情况下显式规格节省的时间会比写规格本身多得多。回到最开始的问题AI 写得越快为什么返工越多因为速度让“需求理解的偏差”被迅速固化成代码。Spec Kit 的答案是在代码生成前设置四道低成本的检查关卡需求评估、Specify、Plan、Tasks。每一次需求变化都在四层里留下记录。AI 的速度优势被保留而返工的主要来源也就是模糊需求被提前挡在了代码之外。 
长河君 · 2026/9/9 21:08:39 · 阅读 1.2k AI编程返工率高？用Spec Kit四阶段流程把需求变成可追溯的工程资产
AI 编程把代码生成速度拉高之后很多团队反而发现返工率上升了。代码写得越快需求理解错得越早返工成本就越高。问题通常不在 AI 生成的代码质量而在需求从“人说的话”变成“可执行代码”的过程中缺少中间产物。Spec Kit 的完整工作流就是围绕“需求评估 - Specify - Plan - Tasks”四个环节把每次需求变化都记录成可评审、可追溯的工程资产。下面会顺着这条主线做一次完整拆解每个阶段做什么、产物是什么、怎么判断是否完成、过程中常见的坑在哪里以及如何结合 AI Agent 和 Coding Plan 这类模式落地。先理解一个核心判断AI 编程的返工绝大多数不是写代码阶段造成的而是“编码前信息不完整”造成的。返工成本不是 AI 生成代码的成本而是“需求误解被代码固化之后再改回来”的成本。Spec Kit 做的事是在编码前增加几层轻量的“翻译和确认”让需求每变化一次都有地方留下记录让 AI 每次动手前都基于最新规格而不是模糊记忆。1. 为什么 AI 写得越快返工反而越多1.1 生成速度快放大了需求误解传统开发中写代码是相对昂贵的环节所以团队会在写代码前做评审、设计、澄清因为改文档便宜、改代码贵。到了 AI 编程阶段写代码变得极其便宜代价转移到“确认需求是否正确”这件事上。如果不经过需求评估就把一句话丢给 AI它会在几百毫秒内生成一个结构完整、风格统一、但可能完全不是业务想要的实现。速度越快错误实现产生得越早浪费越大。从这个角度看“AI 写得快”不是 bug而是特性。真正的问题是团队没有为“快”建立新的检查点。过去代码慢评审机会发生在编码前现在代码快必须把评审前移到规格层。否则团队等于用汽车的速度跑在没有护栏的山路上出事只是时间问题。1.2 返工主要发生在“做什么”和“怎么做”之间返工可以分成两类。一类是“怎么做”返工例如接口设计不合理、命名不一致、事务边界错误这类通常可以靠代码评审和重构解决。另一类是“做什么”返工例如业务规则理解错、边界条件漏掉、验收标准不明确这类等代码写完才发现成本非常高。AI 编程最常见的返工集中在第二类。因为 AI 不会主动承认自己不理解需求它只会基于上下文生成最符合概率的答案。用户给的信息越少它补充的假设就越多。比如只说“做订单超时关闭”AI 可能默认 15 分钟、默认只改状态、默认不释放库存。这些默认值一旦进入代码就变成了隐藏需求后续排查时极难定位。1.3 关键矛盾上下文不足时 AI 只能快速产出“看起来正确”的方案这里有一个经验判断AI 代码生成质量高度依赖上下文质量。上下文包括需求背景、约束条件、现有项目结构、验收标准、异常分支。上下文不足时AI 不是无能为力而是会尽力补全补全出来的结果往往“读起来合理跑起来错位”。Spec Kit 的工作方式就是把这些上下文变成显式输入。它不让 AI 直接写代码而是先让 AI 参与需求评估、形成规格说明、制定实施计划、生成任务列表。每一步都有产物每一步都能被打回每一步变化都有记录。这样 AI 的“快”才被约束在正确轨道里。注意不要只验证 AI 能生成代码要验证它生成代码前是否已经正确理解规格。这个判断适用于所有 AI 辅助编码场景。2. Spec Kit 是什么先让“要做什么”变成可评审的规格2.1 它是方法组合不必然是一个安装包这里讨论的 Spec Kit在不同团队里落地形态可能不同。有的团队把它封装成 CLI 工具通过交互命令生成规格文档有的团队把它做成提示词模板把评估、规格、计划、任务四段放进 AI Agent 的系统提示词有的团队只用一套 Markdown 模板在代码仓库里建specs/目录每次需求变化就更新对应文档。在正式拆解之前先明确这里讨论的 Spec Kit 是指一套“需求到任务的工程化产物”核心链路是需求评估Requirement Assessment- 规格化Specify- 计划Plan- 任务Tasks这里的“Spec”指规格说明不是代码规范“Kit”指一组模板、工具和检查清单。无论技术栈是什么这套链路都成立。2.2 四阶段分别解决什么问题可以用一张表概括阶段核心问题主要产物通过标准需求评估这件事值不值得做范围是什么需求评估记录、范围说明业务方和开发对目标一致Specify到底要做什么不做什么规格说明文档或结构化文件边界条件、异常分支、验收标准齐全Plan按什么顺序做需要改哪些模块实施计划、依赖关系每个步骤都有输入和输出可评审Tasks谁在什么时间做什么状态如何任务列表、变更记录每个任务可执行、可验证、可回溯这里有两点值得注意。第一Specify 的产物不是用户故事一句话而是把“业务目标”翻译成“系统行为和边界条件”。第二Plan 和 Tasks 不能混为一谈。Plan 回答的是“实现路径”Tasks 回答的是“执行单元”。很多团队只在 Tasks 层记录变化漏了 Plan 和 Spec 层结果需求变化后任务改了但规格没有同步最终代码仍然基于过期理解生成。2.3 为什么它能减少返工返工的本质是信息在传递过程中失真。传统流程里业务方把需求说给产品经理产品经理写成文档开发再理解文档每一层都可能失真。AI 编程让“开发理解”这一步变成了“prompt 到代码”的直接映射失真没有消失而是被压缩进了 prompt。Spec Kit 的做法是在最前面加了一层“结构化确认”。规格写出来之后人可以评审AI 可以复述测试可以根据验收标准设计用例代码生成只是最后一个执行步骤。等于把最容易出错的“需求理解”环节从隐性的 prompt 里剥离开来变成一份显式资产。3. 需求评估先判断值不值得进入规格化3.1 评估阶段要收集的信息需求评估不是写完整需求文档而是做一个“少走弯路”的预判。在把需求交给 AI 之前至少要问出四类信息原始诉求业务方用一句话描述的期望不加工、不美化。业务目标解决什么问题用什么指标判断成功。约束条件时间窗口、技术栈、数据量、合规要求、已有模块。验收口径怎么验证做完了谁来判断结果正确。这里最常见的错误是跳过评估直接写规格。尤其当需求看起来很简单时团队容易产生“这个不用评估直接让 AI 改一下就行”的判断。但简单需求往往意味着上下文少AI 只能靠猜。3.2 用评估模板固定思考路径实际项目里可以用一个 Markdown 模板每次需求进来先填一遍## 需求评估 - 需求编号REQ-2025-001 - 来源业务方 / 用户反馈 / 内部优化 - 原始描述一句话说清楚要什么 - 业务目标解决什么问题量化指标是什么 - 约束条件 - 技术栈限制 - 数据量级 - 上线时间 - 合规与权限要求 - 涉及已有模块 - 验收口径 - 决策进入 Specify / 暂缓 / 不需要开发 - 评估人 / 日期模板的价值不是增加文档负担而是强制团队回答“AI 不知道、但代码必须知道”的问题。业务目标可以避免“功能做出来了但业务不认”约束条件可以避免 AI 在实现时选了错误的技术路线验收口径是后续测试用例和任务完成判断的依据。3.3 评估结果如何流向 Specify评估通过后不要把评估记录丢到聊天窗口里。建议把上面内容整理成仓库内的一段记录并把需求编号带进后续所有规格、计划和任务。这样当需求变化时可以通过编号追溯到最初意图而不是翻聊天记录。如果评估结论是“暂缓”也要保留记录。后续再次提出类似需求时可以避免重复分析。如果评估结论是“不需要开发”原因是“已有功能覆盖”同样建议写下来防止 AI 在后续重构中又把这个逻辑当作新需求实现一遍。4. Specify把自然语言翻译成机器和人都能读懂的规格4.1 规格文件的必备字段Specify 阶段的目标是把需求评估的结论细化成“系统行为描述”。一条可以直接交给 AI 的规格通常包含以下字段需求标识和要求标题用户故事或业务场景业务规则边界条件和异常分支非目标Out of Scope验收标准数据变更和接口影响4.2 不要让 AI 直接面对“自然语言小作文”很多人写 prompt 时习惯写一段很长的自然语言例如“帮我把订单系统改造一下要让超时的订单自动关闭同时还要考虑库存回补性能也要好一点注意不要影响线上”。这类描述信息密度低AI 只能提取关键词然后自由发挥。推荐做法是把关键信息结构化。以 YAML 为例下面是一个订单超时自动关闭的简化规格spec: id: SPEC-2025-001 title: 订单超时自动关闭 user_story: 用户提交订单后超过可配置时间未支付系统自动将订单状态改为已关闭 business_rules: - rule_id: BR-001 content: 超时时间可配置默认 30 分钟 - rule_id: BR-002 content: 只有待支付状态订单参与超时判断 - rule_id: BR-003 content: 超时关闭后回补库存并释放优惠券 - rule_id: BR-004 content: 已部分支付的订单不自动关闭 edge_cases: - 支付回调与超时任务并发时以支付成功为准 - 关闭操作必须幂等重复执行不产生副作用 - 订单已进入关闭流程时用户再次支付需要返回明确错误 out_of_scope: - 用户主动取消订单 - 退款、售后流程 - 短信和消息通知 acceptance_criteria: - AC-001: 给定超时时间 30 分钟和待支付订单超过 30 分钟后订单状态变为已关闭 - AC-002: 支付回调在超时前到达订单不关闭 - AC-003: 库存回补数量与订单商品数量一致 - AC-004: 超时关闭任务重复执行两次结果保持一致结构化的好处有三个。第一AI 可以逐条消费信息不会漏掉关键规则。第二人可以快速评审看到 BR-004 就知道“部分支付”场景是否被覆盖。第三测试人员可以直接把 AC-001 到 AC-004 转成测试用例验收标准不再是抽象描述。4.3 边界条件和异常分支是返工重灾区AI 生成代码时最容易漏掉的是异常分支。传统开发中开发人员会因为既往经验主动询问“如果支付并发怎么办”。AI 不会提问它只会根据上下文补全一个合理分支。因此规格描述里必须显式列出边界条件。实际项目中边界条件的来源包括时间边界刚好 30 分钟、状态边界待支付、已关闭、支付中、并发边界回调与定时任务同时发生、幂等边界重复执行、数据边界空列表、超大批量、权限边界无权限用户提交操作。如果规格里没有这些AI 生成后大概率需要返工。返工点不在 AI而在规格缺失。4.4 规格评审让 AI 复述理解而不是直接生成代码在把规格交给 AI 生成 Plan 之前可以多花一步让 AI 用自己的话复述规格并列出它识别出的关键规则和至少三个潜在边界问题。这一步非常便宜却能提前暴露理解偏差。一个简单的 prompt 模式如下你对下面这份规格有什么理解请用自己的话重述核心业务规则列出 1. 你识别到的业务规则 2. 你判断需要进一步澄清的地方 3. 你担心会出错的边界场景 不要生成代码不要开始设计接口。如果 AI 复述出的业务规则和原规格不一致就说明规格还不够清晰或者 prompt 里混入了多余信息。先修正规格再进入下一步不要急着生成代码。建议如果 AI 复述出的业务规则和原规格不一致先修正规格再进入下一步不要急着生成代码。5. Plan把规格拆成可执行、可验证的实施路径5.1 Plan 不是任务清单规格确认后下一步是制定 Plan。Plan 与 Task 的区别在于Plan 关注“改动路径”Task 关注“执行单元”。Plan 至少要回答三个问题要改动哪些模块和服务这些改动之间有什么依赖关系每一步完成时如何验证结果如果把 Plan 直接写成平铺任务清单AI 可能先做第二步再回补第一步导致中间状态丢失甚至产生编译错误。因此 Plan 需要表达依赖顺序。5.2 从规格推导模块、接口和数据变更一个从规格推导 Plan 的方法是逐条分析规格中的业务规则和验收标准问三个问题这条规则需要改数据库吗如果要改哪些表、哪些字段这条规则需要新增或修改接口吗如果要请求和响应结构是什么这条规则需要新增或修改业务逻辑吗如果要放在哪个服务或模块里以订单超时关闭为例Plan 可以这样组织plan: id: PLAN-2025-001 based_on: SPEC-2025-001 steps: - step_id: 1 title: 调整订单状态模型 changes: - 新增超时关闭时间字段 - 新增超时任务执行状态字段 verification: 数据库迁移可回滚订单状态枚举包含已关闭 depends_on: [] - step_id: 2 title: 实现超时检测与关闭主流程 changes: - 新增定时任务或延迟消息处理 - 查询待支付且超过超时时间的订单 verification: 单测覆盖 AC-001 和 AC-002 depends_on: [1] - step_id: 3 title: 实现库存回补与优惠券释放 changes: - 调用库存服务回补接口 - 调用优惠券服务释放接口 - 处理回补失败后的重试或补偿 verification: 库存回补数量与订单商品数量一致 depends_on: [2] - step_id: 4 title: 幂等与并发处理 changes: - 关闭操作使用事务和唯一约束 - 处理支付回调与超时任务并发 verification: 重复执行两次结果一致 depends_on: [2, 3]这里的关键是“每个 step 有明确验证方式”。验证方式不一定是完整测试至少要让 AI 主动说明做完这一步后用什么命令、什么用例、什么日志来判断它没有做偏。这个习惯能显著减少返工。5.3 和 Coding Plan、Token Plan 的关系近期的 AI 编程工具普遍开始提供“先规划、再执行”的模式。比如某些工具会先输出一个 Plan用户确认后才继续写代码有些产品按 Coding Plan 或 Token Plan 的方式管理一次性任务额度。这些形态看起来是产品功能底层逻辑和 Spec Kit 一致先消耗少量上下文和 token 做规划再让 AI 基于规划生成避免大量 token 被花在错误方向上。使用这类模式时不要只把 Plan 当成“让 AI 停下来等确认”的开关而要把 Plan 内容保存下来和规格关联。否则计划通过后AI 执行过程中仍然可能因为上下文被截断而偏离计划。5.4 计划变更时保留旧版本的执行路径需求变化在项目中不可避免。Plan 变更时不要直接覆盖旧计划建议保留历史版本。最简单的方式是在代码仓库目录中按版本号保存或者在文档顶部维护变更记录2025-01-12 14:00超时时间从 15 分钟调整为 30 分钟 影响PLAN-2025-001 的 step 2 中查询条件需要修改step 1 的影响较小 原因业务方希望给用户更多支付缓冲时间这条记录的用途是让 AI 在后续开发中理解“为什么现在的计划和最初不同”。如果直接删除旧版本后续生成代码时可能又会按旧逻辑实现。6. Tasks把计划拆成原子任务让变化有迹可循6.1 任务粒度怎么定任务粒度过大AI 容易在一个任务里自由发挥最终结果难以 review。任务粒度过小计划和执行成本增加AI 频繁切换上下文也会浪费 token。一个比较合理的参考标准是一个任务只改一个关注点。一个任务的输出可以被验证。一个任务失败时影响范围可以定位。例如“实现订单超时关闭主流程”可以拆成多个任务但不要拆到“写一个 if 分支”这种程度。Task 更接近于“完成一个可验收的 commit”的粒度。6.2 任务状态如何与需求变化关联每个 Task 建议带上规格编号、计划编号、需求编号。示例task: id: TASK-2025-001-02 req_id: REQ-2025-001 spec_id: SPEC-2025-001 plan_id: PLAN-2025-001 title: 修改订单状态枚举增加已关闭状态 status: 进行中 acceptance: 状态枚举包含已关闭已有代码可正常编译 log: - time: 2025-01-12 15:30 event: 超时时间从 15 分钟调整为 30 分钟 impact: 该任务描述中的固定时间改为读取配置当需求变化影响到某个任务时不要只改任务描述还要在log里记录“变化前是什么、变化后是什么、影响面是什么”。这样即使过了几周AI 重新读取任务列表时也能理解为什么当前任务长成这样。6.3 每次需求变化都应该留三类记录很多团队在需求变化时代码改了、任务改了但记录没有同步导致 AI 在后续对话中继续沿用旧上下文。建议至少维护三类记录记录位置记录内容作用需求评估记录需求背后的业务目标、验收口径变化避免“功能实现正确但方向错了”规格变更记录业务规则、边界条件、非目标变化避免 AI 按旧的业务规则生成代码计划与任务变更记录改动路径、依赖关系、任务状态变化避免执行链路断裂便于定位返工点6.4 任务完成后如何和规格回对任务完成后不要直接宣布完成。建议做一个“规格回对”让 AI 按验收标准逐条自检请根据 SPEC-2025-001 的验收标准逐条检查你的实现 - AC-001 是否通过如何验证 - AC-002 是否覆盖如何验证 - AC-003 是否覆盖如何验证 - AC-004 是否覆盖如何验证 逐条回答不要跳过。如果某条没有覆盖给出原因和修复计划。这里的关键是“逐条回答不要跳过”。AI 倾向于输出完成结论如果不强制逐条自检它可能只挑自己实现良好的部分回答漏掉边界场景。自检结果应当作为任务完成记录的一部分归档。注意AI 倾向于输出完成结论如果不强制逐条自检它可能只挑自己实现良好的部分回答漏掉边界场景。7. 在 AI Agent 和主流编码工具中如何落地7.1 把 Spec Kit 变成 Agent 的执行约束如果团队使用 AI Agent 辅助编码Spec Kit 可以进入 Agent 的系统提示词或工具说明。例如在 Agent 开始任何代码修改之前强制它先读取规格文件再读取计划最后读取任务。不要允许 Agent 在缺少规格的情况下直接生成代码。一个简化的 Agent 规则可以这样写你在执行编码任务时必须遵守以下流程 1. 先找到关联的 SPEC 文件并总结业务规则。 2. 再找到关联的 PLAN 文件并说明当前步骤。 3. 只修改当前 TASK 涉及的代码。 4. 每次修改后对照 acceptance_criteria 检查。 5. 如果发现规格缺失或前后矛盾停止编码并提问。这个规则看起来简单但它把“先理解再动手”变成 Agent 的默认行为。实际使用中如果 Agent 忽略规则可以通过输出解析和工具调用校验例如在它执行写文件之前检查当前上下文是否已包含规格内容。7.2 结合编码工具中的 Plan 模式很多 AI 编程工具开始提供 Plan 模式。使用这类模式时建议把“Specify”和“Plan”分开先让 AI 输出对规格的理解再让 AI 输出实施计划确认后再切到执行模式。不要把 Plan 输出和代码生成放在同一次对话里。在实际操作中可以分两次对话第一次让 AI 读取规格文件复述业务规则给出实施计划。第二次让 AI 按计划生成代码并逐条对照验收标准。这样做的原因是一次对话里如果既要求规划又要求写码AI 很可能为了效率直接生成代码规划部分就变成了形式化的“假计划”。7.3 版本管理是 Spec Kit 落地的关键规格、计划、任务建议和代码一起纳入版本管理。可以在仓库根目录建立specs/ REQ-2025-001/ assessment.md spec.yaml plan.yaml tasks/ task-001.md task-002.md代码变更和规格变更可以放在不同 Pull Request 中或者在同一个 PR 中明确标注规格变更点。好处是当需求变化时reviewer 可以同时看到“规格为什么变”和“代码改了什么”。如果规格与代码不一致PR 应该被打回。7.4 最小落地路径一个人也能用不需要一开始就建立一个复杂的流程。推荐按下面顺序逐步落地先从最痛的需求开始增加一份规格文件。在 AI 生成代码前先让它复述规格。规格确认后再让它输出 Plan。Plan 确认后再进入 Tasks 执行。需求变化时先更新规格再更新计划和任务最后改代码。如果团队只有一个人也可以使用“规格文件 一次 Plan 对话 逐任务自检”的最小组合。这套方法不依赖任何特定商业工具。8. 常见坑与排查链路8.1 AI 生成了代码但需求实现错了现象AI 生成的代码能编译、能运行但业务方看后说不是自己要的。可能原因需求评估阶段没有形成业务目标。规格文件只写了用户故事没写业务规则和异常分支。交互 prompt 中混入大量历史对话AI 被旧信息干扰。AI 被直接要求“生成整个功能”没有先复述理解。排查顺序先看需求评估记录确认业务目标和验收口径是否记录。再看规格文件检查非目标和边界条件是否缺失。让 AI 读取规格后复述业务规则对比是否存在偏差。如果偏差出现在复述阶段说明 prompt 上下文或规格表达有问题。修正规格后重新生成不要在原代码上反复打补丁。8.2 规格改了但任务列表没有同步更新现象规格从 15 分钟超时改为 30 分钟但代码里还是写死 15 分钟任务描述也没变。可能原因任务没有关联规格编号。需求变化发生时只在聊天里说明没有回写规格和任务文件。团队成员认为“小改动不需要记录”。排查顺序搜索任务文件中有没有spec_id或req_id字段。检查需求变化发生时是否有变更记录日志。如果任务和规格没有关联说明流程建设不完整先补齐关联字段。重新读取最新规格让 AI 找出任务描述中与规格不一致的地方。8.3 Plan 通过后实现过程中仍然偏航现象Plan 阶段 AI 列出的步骤很清楚但执行时跳过了某一步或使用了计划外的实现方式。可能原因单次对话上下文过长AI 丢失了计划后段内容。任务没有被拆成独立步骤AI 一次性完成太多改动。Plan 中的步骤没有验证方式AI 无法判断自己是否做偏。用户没有要求 AI 按 step 逐个执行。排查顺序回到 Plan 文件确认当前步骤的depends_on是否满足。限制当前对话只处理一个 Task不要一次对话执行整个 Plan。在 Plan 的每个 step 中增加 verification 字段让 AI 先自检再进入下一步。如果上下文窗口受限把整个 Plan 拆成多次独立对话每次携带完整规格摘要。8.4 需求变化频繁不知道返工成本从哪里来现象一个看似简单的功能反复修改团队感觉“AI 改一次崩一次”。可能原因没有需求评估每次都是直接让 AI 改代码。规格没有维护变更记录AI 基于多个历史版本混合生成。验收标准不明确测试无法判断是否完成。排查顺序先统计最近几次返工分别属于“做什么返工”还是“怎么做返工”。如果是“做什么返工”问题大概率在 Specify 阶段之前。修复方式不是增加更多代码而是先冻结需求把规格补全。对频繁变化的参数例如超时时间、费率、开关做配置化减少后续代码级改动。针对这些问题整理成一张速查表现象常见原因优先检查处理建议代码能跑但不是业务要的需求评估或规格缺失需求评估记录、规格文件先补规格再让 AI 复述确认小改动反复返工业务规则未结构化规格中的 business_rules拆成规则条目逐条覆盖计划通过后实现偏差任务粒度太大Plan 的 step 和 verification拆小任务每步自检改需求后代码旧逻辑残留变化仅存在于聊天记录变更记录和任务日志回写规格、Plan、Tasks 三层记录Token 消耗高但交付效果差直接生成代码缺少规划是否有 Plan 和自检先规划再执行降低无效生成9. 从个人试用走向工程实践落地清单与扩展方向9.1 推荐的最小文件结构建议在代码仓库中维护一个规格目录结构如下docs/specs/ REQ-2025-001/ README.md # 需求评估记录 spec.yaml # 规格化描述 plan.yaml # 实施计划 tasks/ # 任务和变更记录 REQ-2025-002/ ...这个结构对个人项目和团队项目都适用。个人项目可以把 README.md 省略只保留spec.yaml和plan.yaml两个文件。重点是文件和任务之间存在可追踪的 ID 关联而不是文件数量。9.2 学习环境与生产环境差异如果只是在学习 AI 编程可以不需要完整流程直接体会“规格文件 复述确认”的效果。但进入生产环境时建议至少增加以下能力关注点学习环境生产环境需求记录可以只写在对话里入库或版本管理可追溯规格变更直接改 prompt保留变更记录绑定需求编号代码验证编译通过即可单测、集成测试、验收用例逐条对应权限与安全本地示例代码审查、最小权限、敏感信息不入库回滚方案不需要迁移脚本可回滚规格历史可恢复资源消耗关注效果关注 token 成本和执行时长增加规划阶段9.3 发布前检查清单每次需求上线前可以对照以下清单[ ] 需求评估记录包含业务目标、约束条件、验收口径。[ ] 规格文件包含业务规则、边界条件、非目标和验收标准。[ ] 计划文件包含每个 step 的依赖关系和验证方式。[ ] 任务列表与规格、计划存在关联编号。[ ] 所有需求变化都在变更记录中留痕。[ ] AI 对规格做过复述确认和原规格一致。[ ] 代码实现已按验收标准逐条自检。[ ] 涉及生产环境时迁移脚本、权限、监控和回滚方案已确认。这个清单不一定在初期全部满足但至少要意识到它存在。流程越轻量越好但关键记录不能丢。9.4 扩展方向Spec Kit 的思路并不局限于 AI 编程。它适合所有“快速生成内容但难以校验质量”的场景包括测试用例生成、接口文档生成、数据迁移脚本生成、代码评审辅助等。如果团队基于 Spring AI 等框架搭建内部智能体也可以把规格文件作为 Agent 调用工具前的约束让 Agent 在变更数据库结构或调用外部服务前先检查规格和计划。对个人开发者而言最有价值的练习是下一个需求不要直接让 AI 写代码先花 20 分钟写一份规格再让 AI 复述和给计划。对比一下“有规格”和“无规格”两种方式的返工次数、上下文长度和代码改动量。多数情况下显式规格节省的时间会比写规格本身多得多。回到最开始的问题AI 写得越快为什么返工越多因为速度让“需求理解的偏差”被迅速固化成代码。Spec Kit 的答案是在代码生成前设置四道低成本的检查关卡需求评估、Specify、Plan、Tasks。每一次需求变化都在四层里留下记录。AI 的速度优势被保留而返工的主要来源也就是模糊需求被提前挡在了代码之外。