先说仓库本身
项目地址：https://github.com/yjlo123/spec2code | ⭐ 0 | 无语言标注
没有 README，没有语言信息，没有可运行的任何东西。描述只有一句：写规范自动生成代码。按本专栏的收录标准，它不合格，我不会推荐任何人去 star。
但我还是写了这篇。因为 spec2code 这个名字背后有一条被 LLM 热潮盖过去的技术路线，它指向的问题，正好是现在 AI 写代码最大的坑。
概率生成和契约生成，是两条路
主流代码生成靠概率推断。你输入“用户下单后库存要减少”，模型从训练语料里补全缺失细节，输出完整代码。质量取决于模型的记忆，每次输出还带随机性。
spec2code 指向另一条更老的路：字段级接口契约。入参出参、类型、长度、错误码、鉴权规则、路由结构，规范写全，代码是确定的翻译结果。输入不完整，直接报错，不猜。
这条路的可验证性是真的：规范完整，输出可预期，跑一百次结果一致。代价是对输入的要求高到苛刻。
真正的分歧在需求缺口
我写代码这些年，反复遇到同一个现象：需求永远有缺口。库存扣减发生在下单时还是支付后？库存不足要不要取消订单？跨服务调用失败怎么保证一致性？这些答案在需求文档里通常不存在，但在代码里必须存在。
工程师的日常，很大一部分是在无意识地填这些缺口。问产品一句，或者自己拍板，然后继续写。决策散落在已关闭的 issue 和聊天记录里，没人能追溯。
spec2code 的立场是：缺口要在写规范阶段暴露，不能拖到写代码时。这个立场我部分同意。决策点前置，团队的追问沉淀成文档，决策质量从“取决于工程师当天怎么想”变成“取决于文档评审”。
代价：它取消了“先跑起来再说”
字段没定义，生成直接拒绝。以前拖到联调才暴露的问题，现在动笔之前就得面对。
对还在验证业务方向的团队，这是负资产。探索阶段的代码本来就该模糊、该快、该随时推翻。
对已经在维护字段级接口文档的团队，这笔账反过来算。金融、支付、对外 OpenAPI 这类场景，字段级文档本来就省不掉，写文档从“迟早要做但一直拖着”变成写代码的前置条件。流程成本是转换成本，不是新增成本。这类团队用它有实际收益。
0 星说明了什么
0 星不冤枉。没有 README，没有可运行的实现，别人连拒绝它的机会都没有。
但两件事要拆开：这个仓库的完成度是 0，它指向的问题是真问题。
LLM 生成代码最大的风险不是写得慢，是写得“看起来对”。概率推断擅长填补缺口，也擅长掩盖缺口——模型会用最符合训练语料的方式替你做决定，你不追问，它不提醒。spec2code 的立场正好相反：不完整就停下。
如果字段级契约加确定性生成这条路线成立，收益最大的环节可能不在代码产出（脚手架工具都能生成骨架），而在强制澄清需求。工具会失败，方向未必错。
所以我的建议是：别 star，也别关掉页面。记住这个仓库提的问题，去检查你最近的 AI 生成代码：需求缺口是模型替你填的，你知道它填了什么吗？
等一个带着完整 README 回来的实现。