截止目前的 vibe coding 工程化实践
不太敢相信，从今年年初 Claude Code 爆火，到现在连一年都没到，而大部分真正用过 Claude Code、Codex 这些 SOTA Harness 干过活的程序员应该都会接受手写代码的时代已经过去了
而究竟怎么 vibe coding 效果比较好，这里面的实践和理解，也在快速发展。我今年四月专门学习和实践了一段时间，这个月，我又专门学习和实践了一波。这篇博客，记录一下目前为止我个人的 vibe coding 工程化实践经验
今年四月的 vibe coding 实践
今年四月的时候，经过学习和实践，我最终选择用 Claude Code + superpowers 的工作流
这个工作流，最让人惊艳的就是 superpowers 里 Brainstorming 这个 skill，当时的 superpowers 还在刚起步阶段，比较轻量化，没有现在那么多 skills，我基本上觉得 superpowers 就是 Brainstorming 这个 skill
这个 skill 可以帮助对齐想法、聊清楚模糊的需求，比直接用 Claude Code 效果确实会好上不少。并且这个对齐的过程也是极其享受的，模型是真的考虑得挺周全，在当时，让我深深感受到 Opus 模型的聪明
除此以外，印象深刻的一些点：
- 权限问题：当时 Claude Code 还没有 auto 模式，很多感觉也没啥危险的操作也要手动 allow，人得一直盯着
- 自验证问题：当时 claude chrome extension 才刚起步，虽然已经有了，但读 dom 都还不是特别流畅，很多时候前端调试需要人直接到浏览器里执行 Claude 给的脚本然后粘贴回结果，非常麻烦
- 缺乏工程化理论：工程化主要依靠的只有 Claude.md，大部分人会执行个 /init 往里加一些要求，除此以外没有更多有指导性的想法、概念
- 第一次生成的代码执行不了是正常现象：生成完代码，往往要人去聊几轮调试下才能跑，还没法做到直接写出来就大概率能跑
如今的 vibe coding 实践
我现在主要用 Codex + Matt Pocock Skills/superpowers 的工作流
用 Codex 没啥特别的，主要就是 Claude 封号导致的，Codex 虽然有慢和疯狂写门禁、测试的问题，但终究活是能干的
而开始用 Matt Pocock Skills，主要是 superpowers 后面发展之后，多了很多 skills，整个流程变得很重（比如非要用 git-worktree、subagents），我有次整个不太复杂的活耗了大量 token 之后，调研了下，选择用更轻量的 Matt Pocock Skills
对比几个月前，如今 vibe coding 成熟不少：
- 权限问题基本不用考虑：开启 approve for me 后，基本上不用管权限，带来的好处就是聊完需求后的实现阶段人可以不用管
- agent 自验证自循环已非常优秀：coding agent 可以自己跑测试修复流程、tdd 流程，可以自行用浏览器插件读 dom 发现问题所在并且修改，甚至可以直接控制 app、网页打开用视觉功能自测。生成出来的东西，基本上只存在会错意写错了，不存在完全没法跑的情况
- 出现了一些指导实践的理论概念：SDD、Agent-Friendly Repository 这些概念被提出，了解相关理念后可以进行实践摸索
- 桌面端 APP：Codex 和 Claude Code 都有桌面端了，虽说 TUI 更加 Geek 一些，但真正用起来还是会发现 Desktop App 还是更方便一些
vibe coding 工程化实践经验
实践下来，以下是我的一些经验之谈
AGENTS.md/CLAUDE.md 要注意维护
随着开发过程中的踩坑，不断调整 AGENTS.md/CLAUDE.md，可以有效避免下次踩同样的坑
同时注意保持 AGENTS.md 的精简，及时维护，删掉不用的规则
SDD (Spec-Driven Development) 值得采用
所谓的 Spec-Driven Development，其实有点像文档先行的理念，感觉有点类似用 Claude Code 先 plan mode 生成设计文档，再根据设计文档实现
只不过所谓的 Spec 更加类似 AGENTS.md 的风格，是一些指令性的东西，这样 coding agent 自由发挥的空间就会更小，生成的代码确定性更高，更加符合需求
具体的实践，可以直接用 Matt Pocock Skills 里的 Main Flow。我实际用下来，觉得 grill-with-docs 一定要用，生成的 CONTEXT.md、Glossary.md、ADR 文档确实是有用的，而 to-spec、to-tickets 如果不是复杂的需求则必要性不大，容易徒增复杂度，很耗 token
当然，后续用 TDD 的方式实现，这基本也是 vibe coding 项目标配
测试、验证方式很重要
我上面提到过，如今的 coding agent，自验证自循环能力已经非常优秀
相应的，就是一定要提供测试和验证方式：
- 首先，一定要用 TDD，生成的单元测试有助于防止 agent 改错代码。matt pocock skills 和 superpowers 这些热门 skills 基本上 TDD 是标配，用就完了
- 另外，告诉 coding agent 怎么端到端验
提供了测试、验证方式，基本上人只需要验收即可，大部分时候都能在人不干预的情况下一遍跑出来
实践 Agent-Friendly Repository
所谓 agent-friendly repository，也就是代码结构要让 agent 更好理解，具体的实践其实就是我上面说的几点
我主要是觉得这个概念非常值得了解，里面的各个内容可以当成 checklist 去实践
Matt Pocock Skills 和 Superpowers 的选用
Matt Pocock Skills 和 Superpowers 是最热门的两个 vibe coding 工作流，我实际用下来感觉各有千秋，也各有让我觉得用着不太舒服的点
Matt Pocock Skills 主要实践 SDD 理念，主流程由 grill-with-docs, to-spec, to-tickets, implement(tdd), code-review 组成
Superpowers 主要的流程则是 brainstorming, writing-plans, executing-plans, test-driven-development, verification-before-completion，不过会强制用 using-git-worktree, subagent-driven-development 这些 skills
首先，给我的感觉就是现在的 superpowers 相比几个月前重了不少，很耗 token，处理一些简单的需求，哪怕什么 skill 都不用 codex 也基本能跑出来，用 superpowers 就又费时、又费 token
而 Matt Pocock Skills 也是类似，to-spec 和 to-tickets 会把一个简单的需求拆出 10 个 issue，然后依旧是费时、费 token
两个 skill 的核心都是最开始的对齐，matt pocock skills 的 grill-with-docs 会生成格式相对统一的 CONTEXT.md、Glossary.md、ADR，而 superpowers 的 brainstorming 会生成格式相对不那么统一的设计文档
具体用下来，会发现 grill-with-docs 一般要回答 30-50 多个问题（有时候会有种答力竭的感觉），各种 corner case 都列出来让你确认，最终开发出来的东西确定性会更高，而 brainstorming 的问题更少，只确认一些关键的设计，相应的开发出的东西会更多模型的自由发挥
所以，如果是开发确定的需求，我会用 Matt Pocock Skills，如果是平时自己 vibe coding，更在意开发的“氛围感“、期待 AI 开发出的东西给我一些惊喜，我会用 Superpowers，毕竟 Matt Pocock 的问题实在太多了，过于影响“氛围感“和 Vibe Coding 本身给人带来的创造的快感
而为了避免费时和费 token 的问题，大多数时候，我都会跳过 Matt Pocock Skills 里的 to-spec 和 to-tickets，直接实现，Superpowers 里也避免用 subagent-driven-development，减小复杂度。其实现在的 SOTA 模型已经足够强大，不需要太复杂的流程
人一定要验收、端到端验证
几个月前，如果代码生成出来人不亲自去验证一遍，那大概率会出问题，甚至可能跑都跑不起来。而现在，如果用 Matt Pocock Skills 或 Superpowers 聊清楚了想法，生成的代码大概率是没有基本问题的
不过，我觉得人手动去验收、端到端验证还是必不可少，首先肯定是以防万一，但我觉得更重要的是自验的过程也是检验想法是否对齐的过程：
- 可能 AI 生成出来的东西和最初的想法完全对不上，那么就应该考虑重新聊重新做
- 可能发现 AI 生成出的东西比想象中还要好，那么也是更新自己想法的过程
- 实战中会发现，AI 生成的东西，很容易会带上聊的过程的一些信息（比如日志打上“这一次已经按你所说把xx清除了“），这些东西不应该对用户呈现，就需要再聊几轮让 AI 去掉
- 凭借自己的 taste 去看一些用的不顺手的、看不惯的地方，让 AI 改掉，需要这么一个 polish 的过程
所以，其实就是 eat your own dogfood 的理念，自己做出来的东西自己一定要用一用、试一试，靠自己的 taste 就能判断出一些不对的地方
总结
从零到一的系统：比如类似的 FDE 的东西，需要和客户、业务人员根据 prototype 讨论迭代的，直接用 Superpowers 的 Brainstorming 做出来再根据对方的反馈不断迭代，不需要特别精细，关键是有这么个 prototype 去聊清楚对方的想法。等聊清楚了，后面再考虑工程化的测试、部署、维护这些问题
相对成熟稳定的系统：简单的需求直接聊，让 AI 模仿已有的代码实现，实践下来基本没啥问题；复杂的需求用 Matt Pocock Skills，聊清楚边界再实现