这两个月我把主力工作流切到了 spec coding,配合 spec-kit 做规格驱动开发。先给结论:对于边界模糊、逻辑分支多的业务模块,先把需求写成机器可读的规格说明,再让 AI 基于规格生成代码和测试,效果比传统“一句需求 + 一段 prompt”的方式稳定太多。如果你现在还停留在“把需求丢给 ChatGPT 让它自由发挥”的阶段,我建议你耐心看完全文,这套方法能把你从“AI 写代码我返工”的循环里捞出来。
我先快速解释一下 spec-kit 是什么。它不是一个普通的代码生成器,而是一套围绕规格说明组织开发流程的工具链:你把业务规则用规定格式写清楚,它负责校验规格的完整性、生成测试骨架、生成实现骨架,并且打通回归验证。换句话说,它让规格文件不只是“给 PM 看的文档”,而成了真正能驱动开发、驱动测试、驱动验收的工程资产。
这篇文章我会从“为什么必须换工作方式”讲起,拆解 spec-kit 的工作流设计,再用一个完整的购物车场景把从规格到代码再到测试的整条链路跑一遍,最后把我这两个月踩过的坑和一些已经落地的经验分享出来。无论你是后端、前端还是测试转开发岗,这套思路都值得抄一份。
1. 为什么我放弃了“拿到需求就动手写代码”这种工作方式
1.1 传统 prompt 开发模式的三个致命问题
先说个大实话:大部分人在用 AI 辅助写代码时,效率其实没有提升多少,只是把工作量转移了而已。你让它写一个结算模块,它给你生成 200 行代码,然后你开始 review。问题在于,它前置信息不足,只能基于自己的训练经验脑补需求,你如果不说清楚“满减和折扣能不能叠加”“优惠券是否影响运费计算”,它就默认按最简单的方式处理。结果就是:代码看起来能跑,但业务上到处是窟窿。
我过去两个月用传统方式写过三个业务模块,每次都是这个循环:
- 我给 AI 一段需求描述,它生成一个初版实现;
- 我 review 时发现某个边界条件没处理;
- 我补一句让它修,结果它把另一个已经正常的逻辑改坏了;
- 反复修三轮之后,我终于失去耐心,自己上手写。
这个循环的本质问题不是 AI 能力不行,而是需求信息没有结构化的传递通道。你给它的需求描述是散文,它给你的代码是逻辑,散文到逻辑的翻译损耗,最后全部由你的 review 时间来承担。
1.2 需求描述的“散文”问题与可执行契约
传统工作流里,需求从产品经理口中出来,变成一句话:比如“购物车结算时要根据数量给折扣”。这句话有很多种解读方式。数量是“件数”还是“品类数”?折扣是“整单打折”还是“超出的部分打折”?能不能和其他优惠叠加?这些不确定项,在代码里就是一堆 if-else,而且每个人写的 if-else 还都不一样。
spec coding 的基本思想,是把需求描述从“散文”翻译成“行为契约”。一段规格不是“购物车结算时要根据数量给折扣”这种自然语言,而是:
- 当购物车内有 3 件同款商品,单价 50 元,且满足“满 2 件打 9 折”条件时;
- 结算结果应为 135 元。
一旦规则写成这样,它就同时成为三样东西:给 AI 看的实现依据、给测试框架用的断言数据、给产品经理验收用的确认单。这三样东西来自同一个文件,就不会出现“开发理解的边界”和“产品预期的边界”不一致的问题。
1.3 spec-kit 在这套方法论里的角色
方法论可以不用任何工具,纯手工也能做。例如自己写一个 Excel 表,每条规则一行,再手工去对应测试用例。但问题是规则一多,格式难以统一,校验逻辑很难自动化,生成测试用例的过程又要重复劳动。
spec-kit 起到的作用,就是把这套方法论固化成标准流程。在我实际用的版本里,它处理的是这么几个环节:
- 规格解析:读取预设目录下的 spec 文件,检查结构是否合法;
- 完整性校验:检查每条规则是否包含输入、条件、预期结果三要素,缺失即报错;
- 测试生成:基于规则生成对应语言的测试骨架,测试直接引用规则 ID;
- 实现生成:根据规则生成初版实现代码,标注出未覆盖的分支;
- 回归挂接:把生成的测试接入现有测试框架,跑通后整个规格进入“已实现”状态。
这套流程解决的问题,是让“规格驱动开发”不依赖个人自觉,而是靠工具强制约束。你写少了它不让过,你写错了它告诉你哪里不完整。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. spec-kit 的规格文件结构:先看懂它想要的文档长什么样
2.1 一个最小 spec 文件长什么样
我目前主力使用 Python 技术栈,所以下面例子是 Python 生态下的样子。spec-kit 支持的规格格式是 Markdown + YAML frontmatter 混合体,核心由四个区域组成:元信息、行为场景、业务规则、验收断言。
markdown复制---
id: cart-001
title: 购物车金额结算
status: in-progress
owner: backend-team
tags: [cart, payment, discount]
non-goals:
- 不处理跨境税费
- 不处理优惠券组合叠加
---
# 购物车金额结算
## Scenario: 单件商品无折扣结算
- Given 购物车内有 1 件商品,单价 100 元
- When 发起结算
- Then 应付金额为 100 元
## Scenario: 两件以上商品享受数量折扣
- Given 购物车内有 3 件同款商品,单价 50 元
- And 当前满
