vibe 这玩意出来很久了，其实大家往往就是喜欢说，许愿。
但是其实许愿也有段位，很多佬说许愿出来的东西不咋地，对许愿这种行为有点抵制，喜欢做什么研究写什么约定
其实我只能和大家说，这样的方式太程序员了，不是 新时代的 vibe 方式。
下面这种方式，其实我试过很多次，感觉效果不错。毕竟许愿最大的问题是，其实自己都不知道自己想咋滴，按行业黑话就是，0-》1，先得将 1 讲清楚，太难了太难了。
我基本上第一轮的操作，是这样做的：
/goal 我要做一个 xxx 的产品，我需要有【web/App/小程序】，在【我的电脑上/服务器上】能跑。我什么都不知道，现在你来完成这个第一版的产品生成。你需要调用 subagent 去研究 GitHub 的同类优秀项目以及使用搜索功能进行不少于 10 轮的深入调研，从而完成这个产品的规划，然后调用 subagent 进行审计，确认产品规划，落地能交付给产品人员查看都 PRD（产品视觉）文档、给 开发人员的 开发文档，然后交付 subagent 再次进行审核。注意所有的文档都必须生成，UI 设计方面，【我很喜欢 xxx 产品/我喜欢这个项目 https://xxxxxx，我想按它的风格来】。
本项目的远端git 地址为：xxxxx
如果发现无法访问某些地址，可以使用代理：127.xxxxxxx然后大模型就会哔哩吧啦给你跑好久给你出方案，问就是别看，太复杂了
/init 项目准备根据 xxxx 文档（第一步的文档），启动开发，请你帮我完成项目开发通用规范、UI 规范的创建，以便后续开发不偏离需求规范出来了，不看，然后开始写代码，挂上 goal，去干下一个项目了
/goal 用户说你是地球上最强的AI 开发者，是时候显示你真正的实力。马上根据 xxxx 文档（第一步的文档），启动开发，每轮开发结束，调用 subagent 进行审核，每次完成后再进行下一步。本轮开发的作用，是根据文档要求，提交给用户直接试用的 第一个版本，一些兜底设计可以暂缓，但是必须让成果能让用户清晰了解，并给于下一步建议。【用户体验非常重要，我要求所有功能都必须截图后进行用户体验评判，修正相关问题】。开发完成后，必须输出面向用户的产品说明文档（html 格式）。与此同时，所有开发必须准备的文档，你都需要全部按标准生成。大概就这样了。第一轮之后，想喷就喷，想鼓励就鼓励，玩法就多了