Spec 工具用了一圈，最后还是决定自己造轮子
关于 Vibe Coding 的一些实践和思考
搞 vibe coding 一阵子了，一直都在折腾一件事：怎么让模型理解我要什么，写出来的东西别太离谱（大爆炸啦完全不是我想要的效果啦）。
踩过的坑
一开始我很傻很天真，在漫天盖地的 "程序员马上要被 AI 噶了" 的暴论中，采取最简单粗暴的做法：把 PRD 往死里堆！写详细点，再详细点，只要我能想到的，都给我写！然后丢给模型直接干。当然你也猜到结果了…
哦，cc 不是有全局约束吗？那就加！claude.md 写了一吨，结果还是玩儿蛋…
既然暴力堆砌 PRD 这条路走不通，那么去年开始爆火的各种 spec 方案都来一炮吧。什么 bmad-method、spec-kit、openspec 都给我上！其中 bmad 我约得最多，光看流程设计那叫一个字：“专业”！完整模拟真实公司里不同角色的协作，PM、架构师、Scrum Master… 反正就是主打一个高大上。
然后呢？
YouTube 上有老哥拿它做一个网页，花了 8 小时。只是一个网页…
我自己的体验更惨。需求稍微复杂点，比如 30 来个功能点，一堆文档在各种 agent 之间反复读来读去，最后生成的代码简直没眼看。
所以问题到底在哪
我把 YouTube 上播放量过万的 spec 相关视频基本都刷了一遍，发现一个很有意思的规律：演示用的全是 Todo App、CLI 小工具这种玩意。这种项目说实话我手写也就几个小时（请忽略 bug，那不是我的错，能跑就行）…
但真实的中小型项目呢？20 多个功能点，十几张表，几十个接口。这才是真正需要 spec 的场景吧？结果偏偏是这种场景崩得最惨。
后来我终于想明白了：不管流程设计得多牛逼，底下跑的还是 Transformer 那套东西。文档越堆越多，噪音就越来越大。模型写模块 A/B/C 的时候还行，到了模块 D 可能已经忘了 A 里定义的是 `userId` 还是 `user_id`。
这不是哪个 spec 工具的锅，是现阶段 LLM 本身的局限。
那 Spec 到底有没有用
有用，但得看你拿它干嘛。
如果你不熟悉软件开发流程，spec 工具能帮你建立 "需求 → 设计 → 实现" 的基本概念。团队协作、写文档，这套东西也有它的价值。
但如果你的目标是 "让模型把代码写对"，那问题就不是流程不够完善，而是喂给模型的东西太多太杂了。
Transformer 的注意力机制摆就在那：上下文越长，关键信息越容易被淹。一份 2000+ 行的 architecture 文档，模型大概率只能记住开头结尾，中间那堆字段定义和接口约定，能记住多少全看命（请记住多棒老奶奶过马路，甭管她想不想）。
所以我的原则是：** 降噪比加规则重要得多。**
我在搞的东西
参考了一圈 spec 方案，自己攒了一套 Workflow。核心思路就俩字：砍噪音，砍噪音，还特么的是砍噪音。
每个阶段开新对话，别让历史上下文污染当前任务。偶尔还要回到之前的命令窗口，烦吗？烦，但原因上面也说了。
引用全用稳定 ID（`GC#BR-001` `PRD#API-001` 这种），别指望模型理解 "参考上面说的是 abc，记住了啊，abc！！abc！！"
校验分两层，结构问题先拦，语义问题后查，有毛病早点发现。早爆炸早投胎，重生之无限可能～
执行阶段只给当前 story 需要的上下文，不让模型通读整个 PRD。别幻想了，接收你指令的是一只高级鹦鹉，不是 T800
现在迭代到 V6 了，拿 30 个中等复杂需求做了模拟测试，效果还行，测试报告都在 README。真实项目跑了 3 个（30-35 个需求，前后端都有），大问题没有，至少没爆炸。UI/UX 嘛… 能看能用，别要求太高… 大佬就当看个乐子吧。
写在最后
东西还挺糙的，肯定有我没想到的坑。Issue / PR 都欢迎，star 什么的我更喜欢了～
还有一句大实话：虽然模拟测试是按零编程基础用户设计的，但实际操作还是需要一点底子。不然遇到 bug 反复修不好，你连问题出在哪都定位不了，依赖缺失了什么模型要试半天。就现在的模型能力，你全信它还不如信我是始皇…
GitHub 上有完整文档，请仔细阅读
最后的最后
感谢站里每一位公益站长，你们提供了测试所需的一切支持，不然我钱包比代码先爆炸…
