我以前做 Vibe Coding 的时候，通常会开几个窗口，同时执行几个任务。这样可以比较好地利用时间，让 AI 去完成不同的需求。不过，这样做有几个前提：
- 需求尽量相互隔离，避免互相影响。
- 代码需要提前做好模块化设计。
- 尽量避免多个任务同时修改同一块代码。
但即使开了多个窗口，还是会有等待的时间。这个时候可以去喝咖啡、站起来走一走。
不过最近我越来越觉得，Vibe Coding 期间的空档，不一定要用来堆更多开发任务。这个时间其实很适合做一些研究型任务。
不要只开更多窗口
人的记忆力和注意力是有限的。你很难真正同时理解七八个任务，更不用说这些任务如果都在同一个代码仓库里，很容易互相影响。过一段时间回头来看，甚至会不清楚某个改动究竟是为了解决什么问题。
少做几个开发任务，反而能留下时间审查 AI 的产出：
- 它有没有引入重复代码？
- 有没有破坏原来的结构？
- 有没有为了完成一个小需求，把代码库变得更难维护？
这些审查工作通常需要借助外部搜索和研究，补充 AI 无法替我们判断的信息，再把结果带回开发过程中。
研究什么？
这里说的研究，不一定是系统地学习一门新学科，也可以是了解一个领域、验证一种做法，或者想清楚当前需求应该怎么做得更好。按照研究对象来看，大致有三类。
研究实现方案
比如现在的模块边界是否合理，有没有重复的逻辑，哪些地方未来会比较难维护。AI 可以帮我完成一个具体需求，但我仍然需要回过头看一看：它这次的实现，是否让整个代码库变得更复杂了。有没有更成熟的实现方案，当前方案里又有哪些妥协？
比如：
- 有没有更合适的部署方案？
- 有没有性能方面的问题？
- 实现同一个动效时，不同框架有什么区别？
- 有没有合适的工具或 Skill，可以帮助审查和开发？
研究产品和竞品
需求清单里的每一项都值得做吗？有没有更简单的实现方式？竞品是怎么解决类似问题的？这些都可以让 AI 帮忙搜索和整理。它也可以打开浏览器，查看竞品网站，把页面布局、功能流程和交互特点整理成一份文档，后续再作为设计和开发的参考。
- 做官网时，页面布局、产品展示方式和动效，都不是 AI 随便生成一版就结束了。你需要去看看类似网站是怎么做的，再决定哪些做法适合自己的产品。
- 做 Landing Page 时，可能会涉及好几个流程，流程之间的关系也比较复杂。这时可以先研究一下行业里的常见做法，再选择一种适合当前产品的方案，而不是让 AI 直接替你拍板。
- 做语义分析时，可以先研究当前常见的实现方案，再权衡效果、成本和实现复杂度，看看是否能形成相对竞品的优势。
研究新的领域
开发工作经常会涉及之前不了解的领域，这时更需要大量搜索和研究：
- 如果你在做数据分析模块，就需要了解需要用到哪些统计方法，理解置信区间等概念；
- 如果你在做 AI 搜索功能，就需要研究查询扩展、多轮搜索和结果汇总这些底层原理；
- 如果你在研究 AI 的工具调用，就可以进一步了解提示词、工具编排、Harness Engineering，以及相关的论文和实践。
这些内容看起来可能离眼前的代码有一点距离，但它们都会影响最后的实现方式。研究不是离开项目，而是在给项目补充判断依据。
蚂蚁也不会只沿着最浓的信息素走
这让我想到蚂蚁。
蚂蚁的路径选择，并不是对信息素的机械服从。已有路径上的信息素会提高蚂蚁选择这条路的概率，但不会让所有蚂蚁都沿着信息素浓度最高的方向行动。蚁群始终保留一定程度的探索，让个体继续尝试还没有被充分探索的路径；当新的路径获得更好的结果时，它上面的信息素逐渐增强，群体的选择概率也会随之改变。
这其实是一种动态的探索—利用机制：既利用已有经验，又不放弃对未知空间的探索。正是因为信息素会影响选择，但不会完全决定选择，才有助于降低蚁群过早收敛到次优路径的风险。
Vibe Coding 也有点像这样。AI 已经走过的路径、已经验证过的组件和实现方式，可以提高下一次选择它们的概率；但如果我们只让 AI 沿着已有路径继续生成，很可能会越来越快地把问题做偏。开发过程中留出时间去研究、比较和尝试，其实就是给系统保留一点探索。
所以，Vibe Coding 期间做研究，不是暂时离开开发，也不是把时间浪费在旁支上。它是在已经有经验的路径之外，再看几条路，避免我们过早把“能跑”当成“最合适”。
关于这种探索—利用关系，相关研究后来也启发了蚁群优化（Ant Colony Optimization, ACO），并被用于解决组合优化问题。这里不展开算法细节，重要的是记住这个直觉：经验应该影响选择，但不应该取消探索。