AI编程提效：先找轮子，再定方案，最后开工

在使用 AI 辅助编程（Vibe Coding / Web Coding）时，很多人习惯性地上来就对 AI 说"帮我写一个 XX 应用"，然后等着代码一行行吐出来。但这种做法往往会陷入反复修改、架构混乱的困境。B站一位 UP 主分享了一套更高效的 AI 编程工作流，核心可以概括为一句话：先找轮子，再定方案，最后开工。

这套方法看似简单，却直击 AI 编程的一个核心痛点——AI 擅长生成代码，但不擅长在没有约束的情况下做出优秀的架构决策。把成熟的开源项目引入到 AI 的思考过程中，能够显著提升产出质量。

所谓 Vibe Coding（氛围编程），是由 OpenAI 联合创始人 Andrej Karpathy 在 2025 年初提出的概念，指的是开发者通过自然语言描述需求，让 AI 生成代码的编程方式。开发者不再逐行编写代码，而是像"指挥"一样告诉 AI 想要什么效果，AI 负责具体实现。这种方式极大降低了编程门槛，但也带来了代码质量不可控、架构设计缺失等问题——而这正是本文要解决的核心挑战。

别急着写代码，先让 AI 去 GitHub 找轮子

传统的提示词往往是这样的："帮我写一个待办事项 App"。而更优的做法是把提示词改写成一个"调研 + 决策"的流程：

我想做一个某某项目，先别急着写代码，去 GitHub 上找几个类似的开源项目，比较一下它们的架构、技术栈等方面的优缺点，再给我一份实现方案，等我确认以后再动手。

这个提示词的精妙之处在于，它把 AI 从一个"闷头写代码的执行者"转变成了一个"先做技术调研的架构师"。在实际动手之前，AI 会先横向对比多个成熟方案，权衡各自的优劣，最终给出一份经过深思熟虑的实现规划。

让 AI 去 GitHub 搜索项目，依赖的是当前 AI 工具的联网搜索或 Agent 能力。如 Cursor、Claude、ChatGPT 等工具已支持实时联网检索，能够访问 GitHub API 获取仓库信息、README、代码结构等。部分工具还支持将整个仓库作为上下文导入，让 AI 深入理解参考项目的实现细节。这种能力使得"技术调研"环节可以在对话中自动完成，而非需要开发者手动查找后再粘贴给 AI。

这样做的好处显而易见：你避免了 AI 从零开始凭空设计架构可能带来的踩坑，也让最终的技术选型建立在业界已有的最佳实践之上。

为什么 AI 从零设计架构容易出问题？这与大语言模型的工作原理有关。当前 LLM 在代码生成时是基于概率分布生成下一个 token，而非基于工程经验做出系统性设计决策。模型在训练中虽然见过海量代码，但缺乏对项目全生命周期（开发、测试、部署、维护）的整体考量。没有明确约束时，AI 倾向于生成"能运行"但非"最优"的方案。引入开源项目作为参考，本质上是为 AI 提供了一个高质量的"约束空间"，让它的输出更加可控和可靠。

AI 写不对时，去开源项目找现成实现

第二个关键技巧，针对的是 AI 编程中另一个常见的场景——某个功能 AI 怎么写都写不对。

很多人遇到这种情况，会不断地重试、追加提示词，让 AI 一遍遍修改。但这往往越改越乱，浪费大量 token 和时间。更好的建议是：

当 AI 一直写不出某个功能的时候，也别让它一直死磕，直接让它去 GitHub 上搜，有没有现成的项目已经实现了这个功能，拿过来参考，这个方法特别管用。

这里需要理解"浪费 token"背后的技术含义。Token 是大语言模型处理文本的基本单位，每次对话都会消耗一定数量的 token。当开发者反复让 AI 修改同一段代码时，累积的上下文会迅速占满模型的上下文窗口（Context Window），导致模型"遗忘"早期信息，输出质量反而下降。目前主流模型的上下文窗口从 128K 到 200K token 不等，合理管理上下文、避免无效重试，是高效使用 AI 编程工具的关键技能。当你发现 AI 陷入循环修改时，及时跳出来换一种策略，比如引入外部参考，往往比继续在同一个上下文中死磕更有效。

换句话说，当 AI 陷入死循环时，最好的做法不是继续逼它"硬想"，而是给它提供一个已经被验证过的参考答案。开源社区里往往已经有成熟的项目实现了类似功能，让 AI 基于这些现成代码去改写、适配，成功率会大幅提升。

这本质上是一种"站在巨人肩膀上"的思路：与其让 AI 重新发明轮子，不如让它去找到轮子并装到你的车上。

参考开源项目的深层价值

引入开源项目作为参考，带来的价值远不止"节省时间"这么简单。

一个核心观点是：

参考别人的开源项目不只是能少走弯路，还能让你的架构更稳，维护性也更强。

这个观点值得深入理解。一个在 GitHub 上有一定 star 数、经过社区检验的开源项目，其代码组织方式、模块划分、依赖选择通常都经过了实践打磨。当 AI 参照这样的项目来构建你的应用时，产出的代码往往具备更清晰的结构和更好的可维护性。

GitHub 上的 Star 数、Fork 数、Issue 活跃度、最近提交时间等指标，构成了评估开源项目质量的多维信号。一个拥有数千 Star、持续维护的项目，通常意味着其架构经过了大量真实用户的验证和反馈迭代。这些代码凝结了无数开发者的实践经验和 Code Review 成果。让 AI 参考这类项目，本质上是利用了开源社区的集体智慧——这是任何单个 AI 模型从训练数据中难以完整获取的实践知识。

相比之下，AI 从零生成的代码虽然能"跑起来"，但可能在架构层面埋下隐患——比如混乱的目录结构、不合理的状态管理、难以扩展的耦合逻辑。这些问题在项目初期不明显，但随着功能迭代会逐渐暴露，成为后期维护的噩梦。

三步工作流：先找轮子，再定方案，最后开工

把上面的方法归纳起来，就是一个清晰的三步工作流。

第一步：先找轮子

在动手之前，让 AI 去 GitHub 搜索并对比同类开源项目，了解业界都是怎么解决这类问题的。这一步相当于技术调研。

第二步：再定方案

基于调研结果，让 AI 给出一份完整的实现方案，包括技术栈选择、架构设计、模块划分等。你在这一步做人工确认，把控整体方向。

第三步：最后开工

方案确认之后，再让 AI 按照既定规划编写代码。此时 AI 有了明确的参考和约束，产出的质量会稳定很多。

这个顺序的核心逻辑是：把不确定性前置。在写代码之前先解决"怎么做"的问题，而不是一边写一边纠结架构，从而避免了后期推倒重来的高昂成本。

"把不确定性前置"的思想源自软件工程中的经典方法论。无论是瀑布模型中的需求分析和系统设计阶段，还是敏捷开发中的 Spike（技术探针，指在正式开发前用最小成本验证技术可行性的短期实验），核心都是在正式编码前解决关键技术风险。业界研究表明，在设计阶段发现并修复一个架构问题的成本，仅为在生产环境中修复同类问题成本的 1/100 到 1/1000。这一原则在 AI 编程时代同样适用——甚至更加重要，因为 AI 生成代码的速度极快，如果方向错误，产生的"技术债务"也会以前所未有的速度累积。

写在最后

这套"先找轮子、再定方案、最后开工"的方法，本质上是把软件工程中成熟的"调研—设计—实现"流程移植到了 AI 编程场景。它提醒我们，AI 编程不是简单地把需求丢给 AI 就万事大吉，而是需要人类在关键节点上做好引导和决策。

对于经常使用 AI 工具做项目的开发者来说，善用开源社区这个巨大的知识库，让 AI 在成熟项目的基础上工作，往往能事半功倍。下次做项目时，不妨记住这个顺序，试一试效果如何。

核心要点