我的 Vibe Coding 工作流：从 session log 到 skill 迭代
这个项目是从零开始、一步一步靠 vibe coding 做出来的。一开始我并不太会调 AI 的输出，基本是想到什么就让 AI 去改。时间一长就发现效率很低，于是开始去网上找教程，查怎么防止 AI 输出幻觉，顺着查到了 skill、MCP、工作流这些做法，就开始一项一项实验。
从 session log 开始
最先上手的是 session log：把 AI 的每次改动都总结成一篇记录。攒得多了，再从这些记录里，结合过往的 PR 归纳出一个 skill，然后就这样一直迭代下去。
参考 DeepSeek 的
.agent 目录
后来我看了 DeepSeek 的开源项目，他们的 .agent
目录里有几个文件值得抄：
archive：用来归档不再需要的东西。note：下面有三种文件。
note 里的三种文件分别是：
archive：归档。把实现过但已经弃用的东西放进这里。implemented：已经实现的功能和内容，里面又分成architecture、bug fix、feature等等，都写成 markdown 文件。proposed：相当于 issue。如果自己冒出一个想法，觉得可以应用到这个项目上，就先写在这里。
我照这个思路改了改：skill 被 AI 读进来之后，会把新想法写成
proposed 下的一个 markdown
文件；如果评估下来觉得可行，再传到 Issue 上。
skill 我也装了不少。最初看到 DeepSeek 有一堆
skill，我挑着整理成适合这个项目的格式装了进来，其中相当一部分是 UI
相关的，还有 agent notes（用来规范 Agent 目录里 markdown
文件的写法）。平时用得最多的是 session
log、pre-push checks、agent notes 和
translate docs —— AI 每次改完代码，会自动写一篇 session
log，并顺手把文档更新掉。
需求先问清楚：grill → spec → tickets
在 X 上看到不少开发者分享自己的工作流，学过来之后，我发现其中有一个非常好用，就是从开发过程中反复踩的坑里总结出来的一类 skill。
我用得最频繁的是 grill with ducks：当自己需求还不明确时，先把它丢给 AI，AI 会一直反问你，问到需求清晰为止。这时候再把确定下来的需求写成文档，让 AI 总结成 issue。
需求落地之后，接着用 to spec：把自己的需求传到 issue 上；再用 to tickets：把这份需求拆成十个左右的小需求。
为什么一定要拆小：大模型与小模型的取舍
如果不拆，让 AI 一次性全改完，不仅 token 消耗非常大，还可能产生很严重的幻觉。而且执行流程不够清晰的时候，用高级模型会烧掉大量 token；换成性价比高的模型，最后的效果又可能达不到预期。
拆成几个小需求、把执行流程写清楚之后，无论大模型还是小模型，都能更好地完成这部分的代码。这就是我在做这个项目过程中最大的一个收获——什么时候用大模型、什么时候用小模型，区别和性价比就在这里：
- 需求文档足够清晰、执行流程足够规范时，小模型也能给出很不错的结果。把需求整理成几个 sub-issue，交给小模型执行更快、更省 token，完成率也很高。
- 如果连自己的需求都没想清楚，只靠大模型一顿乱改，产生的问题会非常严重。等到对结果不满意，又反复追问，最后花掉的 token 反而更多，换来的还是一个「勉强能用」的结果。
Code Review 与 Retro
模型写完代码当然不可能百分百全对，可能 90% 是对的，剩下有几个 bug 或小错误。这时候就要 Review：用 code review skill 把每个 sub-issue 逐个检查一遍，再让 AI 去改，完成率会有很大提升。检查没问题之后，提交成 PR 并合并——这一套下来，就总结成了一条工作流。
这条工作流里还有一个很关键的 skill：retro。它能把和 AI 长时间的会话总结出来。因为一个人可能会反复跟 AI 讲同一个问题，讲上一两次，AI 就知道「原来我每次对话都要自动翻译文档」，于是把这一套操作沉淀成一个 skill 装进项目。之后运行时不用再重复交代，它改完代码就会自动更新中英文文档。
从「想到什么就让 AI 改」，到需求拆解、小步执行、Review 闭环、经验沉淀成 skill，中间隔着的其实不是模型能力，而是流程。