Vibe Coding：先研究轮子再确定实现方案
通过先调研开源项目、比较方案，再让 AI 开工，提升 Vibe Coding 的决策质量。
原始内容
最好用的 Vibe Coding 提示词，可能不是： “帮我写一个 App。” 而是： “我想做一个 XXX 项目。先别急着写代码，去 GitHub 找几个类似的开源项目，比较它们的功能、架构、技术栈和优缺点，再给我一份实现方案。等我确认后再动手。” 先找轮子，再定方案，最后开工。 AI 写代码已经很快了，真正拉开差距的是：有没有让它先研究别人踩过的坑。
深度解析
是什么 这是一条关于 AI 辅助开发流程的方法论观点。作者反对把“帮我写一个 App”作为唯一提示，主张在编码前增加开源项目侦察与方案评审阶段。它的核心不是让模型少写代码，而是把项目启动从直接生成转为先理解问题、寻找先例和明确约束。
核心方法 流程可以拆成“问题定义—GitHub 检索—功能、架构、技术栈与优缺点对比—形成实现方案—人工确认—开始编码”。这样，模型同时承担研究助理和方案合作者角色，人工则保留目标确认与关键取舍的控制权。
关键洞察 “先找轮子”能够复用已有设计经验、工程实践和失败教训，减少重复造轮子，也让后续代码生成拥有更具体的上下文。对于 Agent 工程，这相当于在执行阶段之前增加一个研究与规划阶段，使输出更接近可落地的工程决策，而不只是局部代码片段。
边界与风险 开源项目可能过时、维护不足，或存在许可证、安全和兼容性问题；模型也可能只根据 README 做表面比较。实际使用时仍需检查源码、提交活跃度、测试、许可证与部署条件，并明确评估标准。对于一次性小原型，前置调研的成本未必值得；对于长期项目，则应把研究结论、假设和取舍记录下来，避免方案确认流于形式。
精选追评与案例
给出把相似项目克隆到新会话、让模型自行借鉴决策的实操做法。
@Vincent_AINotes 我直接让它clone几个相似的项目，然后放到那里不管，开新会话继续完成，遇到决策问题，它自己就会去抄这些项目的解决方案
补充了不能只看 README、要实际跑通安装与核心路径的重要边界。
@Vincent_AINotes 这个顺序我认，但我会多加一关：别只比较 README，要把候选项目跑起来，测一次安装、核心路径和最近维护状态。AI 很会整理仓库介绍，真正的坑往往在第一条失败命令里。
提供用 fork 现成项目大幅节省 token 的实操经验。
@Vincent_AINotes 哈哈，我也是，github直接fork，省百分之九十五的token
中文译文 · 机器翻译
哈哈，我也是，直接在 GitHub 上 fork，省下百分之九十五的 token。
点出反复换方案的时间成本，提醒权衡调研深度与交付速度。
@Vincent_AINotes 一个项目换三套方案的时间，够别人跑通两个版本了。