先推敲想法，再开始 vibe coding
我不会在 Cursor 里开启一个新项目。我会先去 ChatGPT。
在 repo 出现之前，先有一个想法。在实现计划出现之前，通常只有一个半成形的直觉，在我脑子里听起来比它实际更聪明。我已经学会不相信那个第一版。所以现在我会把这个想法讲给一个 LLM，像是在向一个见过上千个平庸产品、对客套反馈毫无耐心的创业者做路演。
这会立刻改变对话的性质。问题不再是“帮我把这个做出来”，而是：这个东西以这种形式，真的值得做吗？
先给想法上压力
我的第一轮不是技术讨论，而是商业和策略讨论。
我会让 ChatGPT 扮演创业者，把这个想法拆开看。哪里薄弱？哪里太泛？切入口在哪里？谁会真的想要它？怎样才能让它更有防御性？然后我继续迭代，直到这个东西比我一开始带进来的版本锋利得多。
这时我会用上一些无聊但必要的工具：SWOT 分析、可行性分析、moat 分析、分发问题、显而易见的失败模式。这些都不性感，但都重要。很多糟糕的 vibe coding，起点就是一个从来没有被充分质疑过的想法。
重点不是把想法包装得更高级。重点是让它能扛住怀疑。来回几轮之后，我通常会落在两个结果之一：要么这个想法塌掉了，这其实很有价值；要么它变得足够具体，让我真的愿意花一个周末去把它做出来。
到了那一刻，我才继续往下走。
先有 requirement，再有 repository
当我确定这个想法值得做，我会让模型给我一份完整 requirement。
不是松散的功能清单，也不是一句“帮我做个 MVP”。我要的是一份真正的 requirement 文档：产品是什么，给谁用，用户流程是什么，约束是什么，非目标是什么，主要组成部分是什么，以及“做完”到底意味着什么。如果我跳过这一步，项目的开始会很快，然后很快退化成 agent 的即兴发挥。
这是很多人低估的一点。现在的瓶颈已经不是代码了，而是模糊性。
当 agent 拿到模糊指令时，它会做一个聪明实习生会做的事：用看起来合理的默认值去填空。有时候这样也能成。大多数时候，它会产出一个自洽但不对的东西。强 requirement 不能消灭错误，但能显著减少后续过程里的猜测成分。
所以我会让 LLM 在前面先帮我把思路想清楚，在转向成本还很低的时候完成这件事。
Cursor 是我的控制界面
requirement 稳了之后，我才进入 vibe coding 环境。
你可以用 opencode、Claude Code，或者任何别的 coding agent 组合来做这件事。我现在用的是 Cursor，因为我喜欢那种细颗粒度控制。我不想要一种完全自治的模糊流程，agent 消失去跑一大段，回来后给我一个惊喜。我想要的是掌舵。我想尽早介入。我想在代码开始偏离我本来意思的时候及时纠偏。
问题在于，完整 requirement 往往太长，不适合让每个 agent 在每次会话里都反复重读。每次都把整个文档塞进上下文窗口，消耗掉的是重复 token，而不是执行空间。
所以我会用 Cursor 把 requirement 压缩成 agent 真正能工作的形态。我会让 agent 把它拆成更小、更容易消化的部分。需要的话，我还会让它生成多份参考文件：架构说明、任务拆解、约束条件、数据契约、集成细节，任何应该跨会话保持稳定的东西。我也会加上一个 AGENTS.md，让项目的工作规则贴着代码存在，而不是只留在我脑子里。
这一步比大多数人想的更重要。它把一份过大的文档，变成了这个项目的一套小型操作系统。
Skills 也是构建的一部分
环境准备好之后，我会从 skills.sh 安装 find-skills。
然后我会让 Cursor agent 用 find-skills 去分析这个项目本身：把所有真正有助于我更好地做 vibe coding 的 skill 找出来，再把推荐的那些装上。我不把 skill 当成锦上添花。我把它当成上下文基础设施。
这会直接改变每次会话的质量。我不需要反复解释同一套约定，而是能让 agent 一开始就站在更好的位置上。前端任务会带着前端指导开始。Cloudflare 任务会带着 Cloudflare 指导开始。内容任务会带着内容工作流指导开始。Agent 并不是抽象意义上变聪明了，而是在这个具体项目里更有方向感了。
这是我对 AI 辅助开发理解里很大的变化之一。原始模型当然重要，但工作环境同样重要。好的参考文件、清晰的规则、合适的 skill，会彼此叠加。它们减少漂移，减少返工，让每一次 prompt 都更有分量。
为什么 spec 不再是真正的 truth
我现在已经不再用 spec-kit 作为这套流程的一部分。
我依然觉得 spec-kit 很适合项目起步。它很擅长在一开始强迫你结构化地思考。但我发现，一旦真实开发开始，它的维护成本就会变得很奇怪。Vibe coding 会产生 bug。修 bug 需要人工掌舵。人工掌舵会带来一些原始 spec 里没有的局部决策。然后，spec 和代码就开始分叉。
到了那个阶段，假装 spec 依然是 source of truth，反而会变成负担。文档说的是一套，代码呈现的是另一套。Agent 最终遵循的，只是你那天碰巧贴进 prompt 的那一份东西。
我更愿意承认一个活项目的现实。真正的 truth，是不断演化的代码库、整理好的参考文件，以及写在 AGENTS.md 里的项目规则。这些东西能跟着工作一起变化，并始终贴近现场。一份自上而下的大 spec，通常做不到这一点。
这不代表我想要更少的结构。它只意味着，我想要的是一种能在迭代中活下来的结构。
结论
我现在的 vibe coding 流程，原则上其实很简单：先给想法上压力，产出一份严肃的 requirement，把它压缩成 agent 友好的参考资料，安装对的 skills，然后在紧密的人为掌舵下开始构建。
最深的变化是，真正的工作现在开始得比代码更早。好的 vibe coding 不是“让模型自己发挥”。它是先想清楚什么值得存在，再搭一个能让 agents 带着上下文行动的环境，并且拒绝让过时文档凌驾于代码现实之上。我在这件事上越熟练，整个构建过程就越不像是在写 prompt，越像是在做导演。
