用AI开发一个完全不熟悉的项目

项目里那些最重要的决定,需要有人先做。

平时在公司里做开发,其实很多东西已经有人铺好了。技术栈定了,项目脚手架有了,目录结构有规范,组件库、接口规范、知识库、MCP、Skill 甚至 CI 都已经准备好了。你要做的事情,更多是在一个成熟体系里完成需求。

真正麻烦的是另一种情况。突然想做一个自己完全没接触过的东西。比如你平时写 Web,现在想做一个 macOS 原生工具。平时写 Flutter,突然想做一个 Go 后端。或者想做音视频、浏览器插件、桌面 Agent、NAS、P2P 同步。

这时候最容易干的一件事,就是把需求全部扔给 Codex、Claude Code,让它自己规划,再让它生成产品经理、架构师、前端、后端、测试几个子 Agent,然后告诉它们:你们自己讨论,自己开发,最后给我一个能运行的项目。

听起来特别合理。但我实际用下来,这种方式往往效果一般。

公司项目:上下文已经铺好;陌生项目:决策空间是空的。先补上下文,再放 Agent 进去跑。

01 一开始最重要的是先研究

如果这个项目是你熟悉的领域,你看到需求的时候,大脑里其实已经自动完成了很多判断:用什么框架、哪些库靠谱、数据库怎么选、哪些地方以后容易踩坑、什么该第一版做,什么可以后面做、直接调系统 API,还是找三方库。

这些经验不会写在需求里,但它们决定了后面项目会不会越写越乱。

可一旦进入陌生领域,这些判断全部消失了。这时候直接让 AI 开发,AI 面对的其实是一个巨大决策空间。

于是你经常会看到一种情况:代码写得很快,文件创建了一大堆,功能看起来也像那么回事,但做到 30% 以后开始不停返工。今天换一个库。明天发现这个库不支持当前平台。后天重新改架构。再过两天发现最核心的系统能力根本无法这样实现。

所以我现在做陌生项目,第一阶段基本不让 AI 大规模写业务代码。先研究。

02 先让 AI 帮我建立这个领域的地图

比如我要第一次做一个 macOS 录屏工具。我不会直接说「帮我开发一个录屏 App」,我会先让 AI 帮我回答几个问题:

1. macOS 现在主流的录屏方案有哪些?
2. ScreenCaptureKit 和老方案分别适合什么场景?
3. 系统权限怎么申请?
4. 录屏过程中音频怎么处理?
5. 窗口捕获、区域捕获、屏幕捕获分别有什么限制?
6. 哪些地方 Flutter、Electron 做不了,必须写 Swift?
7. 有哪些成熟开源项目可以参考?

这里的目标是先把这个领域里的关键名词和关键问题找出来。做到这一步以后,你会从「完全不知道自己不知道什么」,进入「至少知道应该研究什么」。这个变化非常重要。

03 先找三个成熟项目抄作业

我现在做陌生项目,很少让 AI 凭空设计架构。通常会先找 GitHub 上两三个接近的项目。不用跟我要做的东西完全一样,只需要分别解决其中的一部分问题。比如一个项目可以参考系统 API 调用方式,一个项目参考数据结构,一个项目参考 UI 和目录组织。

然后让 AI 去读它们。重点是让它告诉我:

1. 核心功能具体在哪几个文件里实现。
2. 用了哪些关键依赖。
3. 数据怎么流动。
4. 哪些代码是平台相关的。
5. 项目里有哪些设计值得我们借鉴。
6. 有哪些做法明显是历史遗留,不应该继续抄。

这一步其实是在给 AI 建立一个临时知识库。公司项目为什么好做?因为已经存在大量上下文。陌生项目难做,本质上就是上下文为空。所以第一件事是补上下文。

04 只做一个最小技术验证

这是我觉得最容易被忽略的一步。很多人上来就让 AI 建整个项目:登录、首页、设置、数据库、主题、自动更新全部搭起来。

我现在基本不会这么做。我会先把项目里最不确定的那个东西单独拿出来。比如做跨端剪贴板同步,我不会先做 UI,我会先验证三件事:Mac 端剪贴板能不能稳定监听;Android 后台能不能持续工作;一条文本能不能跨设备过去。

先写一个非常丑的 Demo。只要终端里能看到:

Mac copy hello
Android received hello

这个项目最核心的技术风险就已经解决了一大半。如果这一关都过不了,前面写再漂亮的设置页都没有价值。

所以我现在会专门让 AI 给项目列一个「技术风险清单」。哪个问题风险最高,就先验证哪个。

05 架构一定要落到文件

技术验证跑通以后,我才会正式让 AI 做架构设计。但这里也有一个坑:不要只让它给你一张漂亮的架构图。什么表示层、领域层、数据层、基础设施层,这些文字看起来都对,但对 AI Coding 的帮助非常有限。

我需要的是能直接约束后续代码的东西。例如:

/app
/core
/features
/platform
/storage
/sync

这些东西要写清楚:每个目录干什么;模块之间谁能调用谁;状态放在哪里;数据库表有哪些;接口怎么定义;平台能力怎么封装;哪些模块必须独立。

这些东西最后写进项目里的 AGENTS.md、docs/architecture.md 或者自己的开发文档里。以后 Codex 每次进入项目,先读这些东西。这时候项目才开始有自己的「公司框架」。区别只是这个框架是我们刚刚和 AI 一起建立起来的。

06 按边界分工

我以前也喜欢让 AI 创建很多角色:产品经理 Agent、架构师 Agent、开发 Agent、测试 Agent。后来发现很容易变成一群 Agent 互相写文档。

真正开发的时候,我更喜欢按照任务边界拆。比如剪贴板监听、本地数据库、设备发现、同步协议、UI。每个人都有明确的输入和输出。最好还能对应独立目录,甚至独立 Worktree。

这样的并行才有效,因为它们真正减少了代码冲突。「你当架构师,他当程序员」这种角色扮演,对复杂开发的价值没有想象中那么大。边界清楚,比角色丰富重要得多。

07 我只给 AI 一个阶段

以前我会写「根据这份 PRD 完成整个项目」。现在基本不会这样。我通常拆成:

1. 先完成技术验证。
2. 然后建立项目骨架。
3. 然后完成核心数据层。
4. 再完成第一个完整功能。
5. 接着补 UI。
6. 最后测试、打包、发布。

每完成一个阶段,都让 AI 做一次检查:当前实现和设计文档有没有偏离;有没有为了赶进度引入临时代码;有没有重复实现;有没有应该抽象但是没有抽象的地方;测试有没有覆盖。然后更新文档,再进入下一阶段。

这里有一个很大的好处:项目跑偏的时候,你会在 10% 的位置发现。

08 把踩过的坑重新喂给项目

陌生项目做到后面,会慢慢变成熟悉项目。这时候最有价值的东西,是这个过程中积累下来的判断。比如:某个平台 API 有什么限制;某个库为什么不能用;某个权限必须什么时候申请;某个接口一定要在主线程执行;某个框架升级以后哪里会出问题。

这些东西我都会逐渐写回项目文档。以后 AI 再处理这个项目,就不需要重复踩坑。

所以很多人会问:新项目没有公司里的知识库、Skill、MCP 怎么办?一开始当然没有。你需要在开发过程中把它们慢慢长出来:

• 第一天,可能只有一份 README,先把问题域和当前判断写下来。
• 第三天,有架构和目录约定(architecture.md),Agent 再进项目就有边界可守。
• 一个星期以后,有测试规范、踩坑记录、开发规则,项目开始有自己的工程纪律。
• 再往后,专门的 Skill、CLI、MCP,项目自己的工程体系就这样建立起来了。

写在最后

如果让我今天重新做一个完全陌生的项目,大概会按照这个顺序:

你会发现,真正让项目质量提升的部分,基本都发生在「让 AI 大规模写代码」之前。

现在模型写代码已经很快了。Codex、Claude Code 这些工具,一次生成几百上千行代码根本不是什么问题。真正稀缺的是你有没有给它一个足够清晰的世界:这个项目为什么这样设计;哪些东西已经验证过;哪些方案不能用;不同模块的边界在哪里;什么状态才算完成。

这些东西越清楚,Agent 越像一个熟悉项目的老开发。如果这些东西全部为空,再强的模型也只能一边开发,一边替你猜需求、猜技术、猜架构。最后效果自然不会太稳定。

所以现在我越来越少使用「一句话生成整个项目」。我更愿意先花一点时间,和 AI 一起把这个陌生领域弄明白,再把项目的规则、架构和知识一点点建立起来。等这些东西都有了以后,再把 Codex 放进去跑。到了这个阶段,AI Coding 才真正开始快起来。