在 AI Coding 时代，如何真正开始一个项目

最常见的开始方式

我要开始一个项目了。

但是很多时候，我们所谓的”开始”，其实只是脑子里突然冒出了一个想法：

“我要做一个 xxx 项目。”

它叫什么？大概有什么功能？也许有一点模糊的轮廓。然后呢？没有然后了，直接开干。

这是一种很常见的状态，尤其是对刚开始做项目的新人来说。项目还没被真正定义，需求还没被拆清楚，技术选型也没有经过思考，甚至连”这个项目到底解决什么问题”都还没想明白，就已经打开编辑器，开始新建文件夹了。

我最开始加入 1024 培训营的时候，也是这样的思维。

特别是在 AI Coding 越来越普遍之后，这种倾向变得更明显了。很多人不再是”先想清楚再做”，而是：

“我有一个想法，开干吧。”

设计细节？交给 AI。

代码实现？交给 AI。

项目结构？让 AI 自己发挥。

我承认，AI 很强。强到在代码层面，你甚至可以把接近 99% 的实现交给它。它能写页面，能写接口，能写数据库操作，能写测试，甚至还能帮你修 bug。

但问题是：

代码能写，不代表项目能做好。

功能能跑，不代表结构是对的。

AI 能生成代码，不代表它知道你的项目真正要去哪里。

我踩过这个坑，所以我理解这种感觉。

一开始，让 AI 直接开跑真的很爽。你只要输入一句话，它就能刷刷刷生成一堆代码。页面出来了，功能也跑起来了，好像项目正在飞速推进。

可等你回头一看，问题就来了。

这个模块是干什么的？

为什么这里有一个功能，另一个模块里也有一个差不多的？

为什么状态管理这么乱？

为什么这里写死了这么多硬编码？

为什么一个小功能牵一发动全身？

为什么 AI 前面写的东西，后面自己又推翻了？

这时候你会发现，你得到的不是一个项目，而是一坨看起来很高级的代码山。

它可能用了漂亮的技术栈，可能有很多文件，可能跑起来也没问题，但它缺少一个真正的设计核心。

所以我后来慢慢意识到，开始一个项目之前，最重要的不是立刻写代码，而是先问自己：

我到底要做什么？

为什么要做？

给谁做？

怎么做才算做对？

没有设计的项目，只是在原地打转

没有目的地的漫游，和坐在一圈一圈转着的摩天轮有什么区别？

看起来一直在动，其实哪里也没去。

很多项目失败，并不是因为代码写不出来，而是因为一开始就没有方向。

没有方向，就会导致需求无限膨胀。

没有边界，就会导致功能越做越乱。

没有结构，就会导致后期维护越来越痛苦。

这也是为什么我后来开始相信一件事：

文档先行。

这里的”文档”，不是为了形式主义，也不是为了写给别人看起来专业，而是为了逼自己思考。

文档真正的价值，是让一个模糊的想法，被迫变得清晰。

当你把脑子里的想法写下来时，你会发现很多东西其实并没有想明白。你以为自己知道要做什么，但一落到文字上，就会暴露出大量问题。

这个功能到底有没有必要？

用户为什么需要它？

它和已有产品有什么区别？

第一版到底做到哪里就够了？

哪些是核心功能，哪些只是锦上添花？

这些问题不先想清楚，后面都会以 bug、返工、重构、推翻重来的形式回来找你。

第一份文档：PRD

首先是 PRD，也就是产品需求文档。

做一个项目之前，我现在会先问自己：

这个项目是为了解决什么问题？

它的目标用户是谁？

用户为什么不用现成的工具，而要用我的？

第一版最小可用版本应该是什么？

哪些功能必须有，哪些功能可以以后再说？

如果只是为了”做一个项目”，那这个项目很可能从一开始就没有意义。

当然，练手项目也有价值，但即便是练手，也应该有明确的训练目标。比如这个项目是为了练习全栈开发，还是为了熟悉某个框架，还是为了沉淀一个可以复用的工具。

如果目标不明确，就很容易变成”看起来做了很多，其实什么都没练到”。

谈到项目意义，就绕不开调研。

市面上有没有类似的产品？

如果已经有完全一致的，那我为什么不直接用别人的？

如果有相似的开源项目，那我为什么不拉下来改？

如果我还是要自己做，那我的差异点在哪里？

差异点不一定非要惊天动地。它可以是更轻量、更适合中文用户、更符合自己的工作流，也可以只是为了学习某种技术路线。

但你至少要知道自己为什么做。

PRD 不需要一开始就写得像公司文档一样复杂。对个人项目来说，它可以很简单：

项目背景是什么？

目标用户是谁？

核心痛点是什么？

核心功能有哪些？

不做什么？

第一版验收标准是什么？

尤其是”不做什么”，非常重要。

很多项目不是死于功能太少，而是死于什么都想做。

第二份文档：架构设计

如果说 PRD 解决的是”为什么做”和”做什么”，那架构文档解决的就是”怎么做”。

架构是项目的骨架。

皮相再好看，如果骨架不稳，项目迟早会变形。

我以前很容易忽略架构设计，觉得反正 AI 能写，先让它写出来再说。但后来发现，没有架构约束的 AI，就像一个执行力极强但没有方向感的工人。

它会很努力地盖房子。

但你没告诉它这是民宿、仓库还是图书馆。

于是它今天砌一堵墙，明天开一扇窗，后天又把门改到另一个方向。每一步看起来都合理，但整体就是不协调。

所以现在我会先做技术栈调研。

比如：

前端用什么框架？

后端用什么框架？

数据库选什么？

是否需要缓存？

是否需要鉴权？

是否需要任务队列？

是否需要文件存储？

部署在哪里？

这些问题不一定都要复杂化，但至少要想一遍。

技术选型不是越新越好，也不是越复杂越专业。对于个人项目而言，最好的技术栈通常是：

自己能掌控。

社区足够成熟。

后期维护成本可接受。

能满足当前阶段需求。

不要为了用技术而用技术。

一个简单的博客系统，不一定需要微服务。

一个内部工具，不一定需要 Kubernetes。

一个 MVP 项目，不一定一开始就上复杂的权限系统。

架构设计的重点不是炫技，而是让项目在未来可理解、可扩展、可维护。

第三份文档：项目结构

技术栈确定之后，就要定项目结构。

项目结构看似只是文件怎么放，但它实际上决定了后续开发的心智负担。

结构清晰的项目，打开目录就能大概知道每个模块负责什么。

结构混乱的项目，找一个功能都像考古。

我现在会尽量提前确定这些东西：

页面放在哪里？

组件如何拆分？

业务逻辑放在哪里？

API 请求如何组织？

类型定义放在哪里？

工具函数如何分类？

配置文件如何管理？

测试文件如何放置？

这些东西如果一开始不约定，后面就会被随手写散。

今天一个 helper，明天一个 utils，后天又来一个 common。看起来都能用，但时间一长，项目就会变成一个垃圾场。

项目结构不是为了限制创造力，而是为了降低混乱。

尤其是和 AI 协作时，项目结构更重要。因为 AI 很容易根据当前上下文”临时发挥”，如果没有明确规范，它可能会在不同地方重复创建类似文件。

你要告诉它：

哪些目录可以放什么。

哪些目录不能随便新增。

已有能力应该复用哪里。

新增模块应该遵守什么模式。

这就是项目结构文档的价值。

第四份文档：AI 规范文档

在 AI Coding 时代，我认为每个项目都应该有一份 AI 规范文档。

比如 AGENTS.md、CLAUDE.md，或者你自己定义的 AI_RULES.md。

它的作用不是给人看的，而是给 AI 看的。

你不能默认 AI 每次都理解你的偏好。

你也不能默认 AI 会自动遵守你的项目风格。

如果你不写清楚，它就会按照自己的习惯来。而不同模型、不同上下文、不同对话轮次下，它的习惯可能还不一样。

所以你需要明确告诉它：

项目使用什么技术栈。

代码风格是什么。

命名规范是什么。

哪些库可以用，哪些不要用。

提交代码前要检查什么。

不要随便引入新依赖。

不要重复实现已有功能。

不要修改无关文件。

新增功能前先阅读哪些文档。

复杂改动前先给出计划。

这些规范看起来很啰嗦，但它能显著降低 AI 乱写的概率。

AI 很强，但它需要边界。

没有边界的 AI，会让项目变快，也会让项目变乱。

有边界的 AI，才是真正的生产力工具。

第五份文档：实现规划

最后是实现规划。

小项目在完成前面的文档之后，可能已经可以直接让 AI 开始构建了。只要及时 review，微调细节，基本问题不大。

但如果是稍微大一点的项目，就不能一口气让 AI 全部写完。

你不能一口气吃成胖子。

AI 也不能在没有阶段目标的情况下，稳定地完成一个复杂项目。

所以我会把项目拆成阶段。

比如：

第一阶段，只完成基础项目初始化。

第二阶段，完成核心数据模型。

第三阶段，完成主要页面和交互。

第四阶段，接入后端接口。

第五阶段，完善鉴权、错误处理和边界状态。

第六阶段，补测试、优化体验、准备部署。

每个阶段都应该有明确目标。

这一阶段完成什么？

不完成什么？

验收标准是什么？

完成之后需要检查什么？

这样做的好处是，你可以持续掌控项目，而不是把项目完全丢给 AI。

AI 更适合执行明确任务，而不是替你承担所有决策。

你越能把任务拆清楚，AI 的产出就越稳定。

你越懒得思考，AI 生成的东西就越容易失控。

AI 不是项目负责人，你才是

这是我现在很深的一个感受：

AI 可以是程序员，可以是助手，可以是顾问，但它不应该是项目负责人。

项目负责人必须知道方向。

必须决定取舍。

必须控制边界。

必须判断什么是对的，什么只是”能跑”。

如果你把这些全部交给 AI，最后很容易得到一个表面完整、内部混乱的项目。

AI 不会天然知道你的长期目标。

它不知道你后面要不要扩展。

它不知道你最在意的是学习、上线、维护，还是作品展示。

它只会根据你给出的上下文，尽可能生成一个看似合理的答案。

所以真正的问题不是”AI 能不能写代码”，而是”你能不能指挥 AI 写出正确的代码”。

这也是设计的意义。

设计不是为了拖慢开发。

设计是为了避免你在错误的方向上狂奔。

我现在如何开始一个项目

如果现在让我重新开始一个项目，我大概会按这个顺序来：

先写一句话项目定义。

这个项目是什么？给谁用？解决什么问题？

然后写 PRD。

明确项目目标、用户痛点、核心功能、非目标和 MVP 范围。

接着做简单调研。

看看有没有同类产品，有哪些值得参考，有哪些坑可以提前避开。

然后写架构文档。

确定技术栈、数据流、模块划分、部署方式和关键设计。

再写项目结构规范。

把目录、模块、命名、复用方式提前定下来。

之后写 AI 协作规范。

告诉 AI 应该如何理解这个项目，如何写代码，哪些行为禁止。

最后写实现计划。

把项目拆成一个个可执行的小阶段，每个阶段都有清晰验收标准。

完成这些之后，我才会真正开始写代码。

这不是因为我变慢了。

恰恰相反，这是为了更快。

因为没有设计的快，往往只是前期快。

后面会用更多时间还债。

真正高质量的快，是在开始之前就知道自己要去哪里。

结语

以前我觉得，开始项目就是新建文件夹，打开编辑器，写第一行代码。

现在我觉得，开始项目的第一步，其实是停下来。

停下来想清楚：

我为什么做？

我要做什么？

我不做什么？

我要怎么做？

我如何判断它做对了？

代码只是项目的表达形式。

设计才是项目的灵魂。

AI Coding 的时代，写代码的门槛越来越低，但做好项目的门槛并没有消失。相反，它变得更依赖人的判断力、抽象能力和设计能力。

你可以让 AI 帮你写代码。

但你不能让 AI 替你思考整个项目的意义。

因为最终为这个项目负责的人，不是 AI。

是你。