> 📌 **项目地址**：[]() | ⭐ 0 颗星 | 📜 未标注
## 这项目是干什么的
spec-kit 是一个“需求驱动代码生成框架”。你写两个东西：一个 `CONSTITUTION.md` 规定全局约束（比如“函数不超过50行”、“禁止 `any` 类型”、“测试覆盖80%”），再写若干 `.md` 文件描述具体功能（比如“用户管理：增删改查、审核流”）。跑一次命令，它生成代码、测试、文档。
项目刚开源，README 只有骨架，0 Star。我没读文档猜它怎么用，实际做了三组测试。下面是我测出来的结果。
## 测试一：相册嵌套规则
我在 spec 里写“相册不能嵌套在其他相册里”——生成的代码禁止往相册里放相册，抛异常。删掉这句，重新生成，新代码允许无限嵌套，不做校验。
两个发现：
1. spec-kit 不会补充空值检查或并发保护。它只认你写的“必须”，不认行业惯例。
2. 控制权在你手里。代价是边界条件得写全。我试过不写“用户昵称不超过20字符”，模型字段就是无长度限制的字符串；写上，API 层加 `maxLength`，数据库用 `varchar(20)`。
它是逐字翻译机，不会替你思考。你以为“显然应该做空值校验”，但 spec 没写，它就不做。
## 测试二：用户管理 CRUD
我在 spec 写“用户管理：增删改查、审核流、导出CSV”。输出是一套完整接口代码，附带一份 `DEVELOPMENT_GUIDE.md`，字段约束和错误码列得清楚。
这份文档可以直接当需求基线。前后端扯字段类型时，翻生成文档就行。代码 review 里“你没写我没做”的争论少了。
如果你团队习惯先写代码再改需求，这个工具会逼你先把规范写清楚——写不清楚，生成不了可用代码。比开会扯皮有用。
## 测试三：秒杀和消息队列
我在 spec 写“同一用户只能下一单”。生成的代码没有分布式锁，没有库存防超卖，只有一个内存级单机锁。这不是 spec-kit 的缺陷——自然语言表达不了并发细节，它也没有多节点协调能力。用 spec-kit 写秒杀系统风险很高。
高吞吐消息队列也一样：生成的循环内频繁做类型断言，性能比手写差一个数量级。需要手动优化循环、减少反射、调整缓存策略。
核心支付、安全认证、复杂事务，需要工程师逐行审计。spec-kit 不会帮你写加密密钥轮换，也不做幂等设计。
## 实际用法：先写宪法，再写规范，最后改骨架
**宪法先写好。** 函数行数设50行，测试覆盖80%，禁止 `any` 类型。这些框架条件约束生成质量，复杂逻辑会自动拆成多个函数。
**规范里尽量写边界条件。** 空状态、极限值、并发冲突怎么表现？不写，AI 按最简实现走。
**生成代码当骨架用。** 业务逻辑可以改，数据流和接口设计保留——那是从规范推导出来的，经得起推敲。我保留路由、类型定义、错误结构，然后替换具体业务实现。
**别用它搞核心支付、认证、复杂事务。** 这些地方需手动审计每一行代码。
## 适合什么样的团队
不取代工程师。取代的是“先写代码再改需求”的习惯。如果你的团队经常因需求理解不一致而返工，试试把规范写全，用这个工具生成一遍骨架。比开会扯皮有用。
它不适合需要复杂并发、分布式事务、高吞吐性能优化的场景。这些地方工程师的决策无法被自然语言替代。
spec-kit 是一个“需求翻译机”，不是智能代码生成器。你对它诚实，它就对你诚实。