上个月我给自己定了一条规矩，现在越用越觉得值。说出来很简单：以后只要我说"我要开发一个什么什么"，AI 的第一反应不应该是建文件、更不是输出代码——而是先去 GitHub 上把同类开源项目摸一遍。

这事儿看着不起眼，但它直接决定了你最后拿到的是"能用的东西"，还是"看起来能用的东西"。

一、我们太容易让 AI 一上来就写代码

你有了一个想法，兴奋地跟 AI 说"帮我做个 X"。它二话不说，唰唰唰开始建目录、写函数、跑起来。你看着代码一行行冒出来，很有成就感。

但冷静下来想：它写的这套架构，真的是这个场景里最适合的吗？它踩过的那些坑，是真的踩过了，还是凭训练数据"猜"的？

我越来越确信，让 AI 一上来就写代码，是"最高效的低效"。它确实快，快到让你来不及发现方向是偏的。

二、没有调研的代码，是闭门造车

AI 写代码，依据的是它见过的训练数据。它给出的方案，往往是"它以为对的"方案。但真实世界里，你这个想法，大概率已经有人做过、验证过、踩过坑、改良过了。

不调研就动手，等于让 AI 在黑屋子里重新发明轮子——而且重新发明出来的，常常是个方的。

开源社区最值钱的地方，不是代码本身，是那句没写进文档里的"这里当初为什么这么设计""那个坑我们花了三周才爬出来"。这些东西，AI 不主动去翻，是给不出来的。

三、一条我给自己定的铁律

现在我的规矩是这样：当我说"我要开发一个 X"，AI（尤其负责工程的 Codex）的第一动作，不是建文件、不是写代码，而是——去 GitHub 调研同类开源项目。

具体要干这么几件事：

先筛选出最有参考价值的几个方案，别贪多。然后逐个分析：它们解决了什么问题、用了什么架构、依赖哪些技术、目前还活不活跃。最重要的是，哪些设计值得我直接复用，哪些坑我得绕着走。

等这些摸清了，再结合我自己的需求，给出四样东西：技术选型、系统架构、MVP 范围、开发顺序。

注意，到这里为止，一行代码都没有。我要先看懂"该往哪走"，确认无误了，再让它进实现阶段。

四、这样 AI 会先做三件事

把"先调研"焊死在流程前面，你会发现 AI 进场时的状态完全不一样：

1️⃣ 找到经过真实项目验证的方案。 不是教科书理论，是有人真刀真枪跑过、Star 数和时间检验过的路子。

2️⃣ 研究别人已经踩过的坑。 别人用三个月趟平的雷，你一天就能绕开。这才是开源最大的红利。

3️⃣ 根据你的需求做技术取舍。 同样一个功能，A 项目为性能牺牲了可读性，B 项目为简单放弃了扩展性——你的场景到底要哪个，调研完才清楚。

等方向定了，再让它写代码。这时候写出来的东西，才是站在巨人肩膀上的，不是从零开始瞎摸。

写在最后

用 AI 开发，最贵的从来不是 token，是方向。

让 AI 先去 GitHub 调研，本质上是让它替你做"前期尽职调查"——把"怎么做得不蠢"这件事，交给已经被现实校验过的方案；而把"要不要做、做成什么样"这个确认权，攥在你自己手里。

这跟上一篇说的"编排多个 AI"是一回事：你不是在让 AI 写代码，是在让 AI 替你把最难、最容易被忽略的那段路先走完。

这件事我刚跑起来，但回头看已经省下了不止一个"推倒重来"。

岛主的 AI 思考 · 第 33 篇