虽然说 vibe 没有最佳实践可言,每个人做事情的方式还是值得参考下,我在 vibe 的时候因为同时开几个项目,为了保持思路的连贯性,不同的项目做事情的顺序几乎保持一致,首先打开 /plan 模式和 cc 聊清楚所有背景:包括为什么做这个产品,目标用户是谁,产品主要的 user story 是什么。 一开始我们可能自己也不清楚自己要做什么,只有一个大概的想法,所以第一次的 plan 主要是让 cc 和我们有一个大致的共识,然后它会不断提问题以丰富我的想法,最后选择一个 mvp 方案给我们,把权限设定好之后让 cc 一次性去完成即可,它会拆分为 1-7 个阶段,然后全部自动执行。 在 mvp 的基础上最重要的是走通主要 user story 验证它的功能性,小 bug 可以暂时不管,验证成立之后,我会把之后要做的 bugfix 以及所有不重要的事情让他放到下一个迭代中去,具体迭代周期如何定义,这个看每个人的习惯,我觉得就算同样的提示词,它最后生成出的 md 文件中去记录迭代的 todo 也并非能做到可以 100% 一致,我们不需要太在乎这个。在这个时候,我会让他自己写一个 hooks 一旦判断这个 todo 文件被修改的时候就进行自动提交。方便之后我们回滚。 最后 mvp 完成所有主要任务,就是上线部署前的最后一步:品牌形象和 UI 的重新设计,这里为什么要放到最后来做,一个是这是一个几乎可以全自动的复杂任务,我一般让 Gemini 生成参考的 logo,单页网页和设计风格图片,再将设计风格对应的 html 下载到本地让 cc 自己参考,如果不要求特别细节,其实也可以直接复制粘贴网上已经存在的 design prompt,出来的效果大差不差,都非常好。 现在整个 UI/UX 的改版就像喝咖啡那么简单,实际上每到最后一步我就去客厅做其他事情了,cc 在这方面能做到从头到尾全部自动化,不太需要人工干涉。 最后是部署,用 vercel 和 next.js 的话也是全自动的,没什么需要操心的部分。在上线之前可以再打开一个 plan 模式让 cc 帮忙写法务文件,隐私条款什么的。是在不放心可以让 codex 来 review 下是否有显著的安全风险。