你是不是也这样：兴冲冲打开 AI，想做个自己的项目，结果坐在那儿，第一步该干嘛都不知道。
脑子里一堆想法，就是不知道从哪下手。
要么干脆甩一句“帮我做个某某系统”，剩下的全扔给 AI，然后眼睁睁看着它越写越乱，自己心里越来越没底。
一天一个 vibe coding 小技巧，今天讲：用 AI 做开发，从立项到动手写代码之前，整个流程到底怎么走。
其实我整个内容的排序，本身就是按这条开发流程来的——立项、拆分、技术选型、项目架构，一期接一期，连起来就是一条完整的线。
可大家是一期一期零散看的，单看每节好像都懂，真要自己从头做一遍，谁先谁后、怎么串成一条线，照样心里没数。
所以这一篇，我不讲什么新东西，就把这条线，从头到尾给你捋一遍。
因为要讲的东西比较多，我拆成上下两篇。
上篇讲前半段：动手写代码之前，怎么先把地基和规矩立好。
下篇讲后半段：开始写代码之后，怎么一个阶段一个阶段往前推，还不让 AI 中途跑偏。
先看整体。
在真正让 AI 写业务功能之前，其实有四步要走：立项和功能清单、选技术栈、搭项目架构、写 agent 宪法。
这四步全部走完，你才算把地基和规矩立好了。
下面一步步说。
第一步：立项和功能清单
这是整个流程的起点，也是最多人想偷偷跳过的一步。
立项，说白了就是先想清楚，这个项目到底要做什么。
功能清单，是再往下拆，拆成一条条说得清清楚楚的功能。
这两步我之前用好几篇专门讲过，没看过的去翻立项篇和立项补充篇。
我就提醒一句：这一步要是糊弄过去，后面很容易返工，因为你都不知道你需要什么，那么AI在写项目的时候也基本上是全靠猜了。
说到底，用 AI 做开发，变的只是开发里的角色。
以前做一个产品，是项目方要和程序员，把业务需求一条条对清楚。
而现在，AI 就是你的程序员。
所以你也一定要和 AI，把需求对得明明白白。
不管是现在还是以前，不管对面是专业程序员，还是 AI。
任何时候，模糊不清的需求，都是危险的。
第二步：选技术栈
项目要做什么定下来了，接着就得定，用什么来做。
这就是选技术栈——前端用什么技术栈、组件库，后端用什么语言、什么框架，都得定下来。
这一步的关键，不是挑最高级、最厉害的，而是挑最适合你这个项目、AI 也最熟的。
别小看这一步，它的分量很重，不是随手定定就完事的。
选错了，往往写到一半才暴露，再推倒重来，特别费时费力。
具体怎么选、怎么让 AI 帮你判断有没有过度选型，我前面专门讲过。
这里你只要记住一点：技术栈一旦定下来，就别来回摇摆。
前端今天 React、明天 Vue，后端今天 Python、明天 Go，每摇摆一次，前面的地基就得跟着重打一次。
第三步：搭项目架构
技术栈定了，下一步，是搭项目架构。
不管是前端还是后端，在动手写业务之前，都应该先搭一个合格且稳的项目架构。
这就跟盖大楼一样。
你不会一上来，就冲进去装修某个房间，而是先把地基、框架、承重墙立起来。
项目架构，就是你这栋楼的框架。
注意，这一步不是让 AI 上来，就把登录、订单、支付这些功能全写出来。
而是先搭一个最小的、能跑起来的架子，把通用规则先定下来。
拿后端举例：项目能启动、配置能读、接口返回统一、错误处理统一，还有日志、数据库连接、权限入口，这些先搭好。
前端也一样：目录怎么分、组件怎么规范、请求怎么统一封装、状态怎么管，这些同样要先立一套规矩。
说白了，不管前端还是后端，都是先定好一件事——以后每个功能，都按同一套规则写。
怎么搭、怎么判断这个架子稳不稳，我前面专门拆过，前端、后端都有，后端还分了骨架的搭建篇和验收篇，这里就不展开了。
第四步：写 agent 宪法
地基搭好了，接着，要给这个项目立一份 agent 宪法。
agent 宪法是什么、为什么它能让 AI 不乱来，我在往期视频中专门讲过。
还没看过的，建议去翻一下，这一篇就不细说了。
这里可以简单说一下它的概念：agent 宪法，就是写给 AI 的项目规矩，做什么功能都得守的那套规则。
关于这份宪法，我发现大家最容易卡在两个地方。
一个是，它到底凭什么能管住 AI。
另一个是，这东西到底该放哪。
这两点，我重点说说。
先说它怎么起作用。
很多人以为，agent 宪法就是一份写给自己看的说明文档，写完放那就完事了。
不是的。
它真正的关键在于：这类 AI 编程工具，基本都有这么一个机制。
你把规则文件，放在它指定的位置。
之后每次干活之前，它都会自动把这份文件读进去，塞进 AI 的上下文里。
说白了，就相当于你每次开口让 AI 干活之前，它都先把这套规矩，从头默念了一遍。
所以它不是摆设，而是实实在在地影响着 AI 的每一次判断。
也正因为它认的是“指定位置”，第二个问题就来了：这份宪法必须放对地方。
放对了，工具每次都自动读；放错了，工具根本不读，这份宪法就等于白写。
而不同的开发工具，要求的位置和文件名都不一样。
你不用去死记这些。
最稳的办法，是直接问你的 AI 工具：“请在当前工具会自动读取的位置，帮我创建 agent 宪法文件。”
它会帮你放到对的地方。
说完位置，再提一句它和前面那份项目架构设计文档的分工，别搞混。
架构设计文档讲的是，这个项目的代码该怎么组织、目录怎么放。
agent 宪法讲的是，AI 做事必须守的行为准则。
比如：必须遵守架构设计文档；要改底层、要换框架、要加新依赖，得先说明原因；能用框架自带的能力，就别自己手写一套；每个阶段做完，要自己先检查一遍。
那为什么，非要排在第四步来写？
因为一份好用的宪法，必须结合你这个项目的真实情况：你的立项、功能清单、技术栈。
而这些，恰好前面三步刚刚定下来。
这时候写，才写得准。
那具体怎么写？
你不用自己从零去造。
我自己就有一份通用的 agent 宪法，平时项目都在用。
而且这份宪法，不是我凭空写出来的。
是我让 Codex，把我电脑里所有项目的宪法都翻了一遍，再提炼、汇总成的一份通用版。
所以它是从一个个真实项目里沉淀下来的，不是拍脑袋编的。
不过，就算你拿到了这份模板，也先别急着原样复制进你的项目。
我看很多人，一拿到就把整份宪法直接粘进去，就算完事了。
千万别这么做。
我的那份宪法模板是通用的，设计之初不是为了给你们看到，而是直接给AI看的。为了这我还留了很多变量位置，都是让AI去填的。
所以，正确的做法是，直接把它扔给 AI，然后这样说：
“请根据当前项目的真实情况，深度结合这份宪法模板，从中制定一份专属于本项目的 agent 宪法。”
这里的关键词，是“结合你项目的真实情况”。
你的立项、功能清单、技术栈，都是那份通用模板里没有的。
AI 要根据你实际用的语言、框架、业务，把这些通用规则，落到你自己的项目上，这份宪法才真正管用。
定制完，你大概看一眼。
有看不懂的地方，别装懂，直接让 AI 用大白话给你讲清楚每一条到底在管什么。
上篇小结
到这里，上半段就走完了。
再回顾一下这四步：
第一，立项和功能清单，想清楚做什么、拆成一条条功能。
第二，选技术栈，挑最适合、AI 最熟的，定了就别摇摆。
第三，搭项目架构，前后端都先搭一个能跑的架子，定好统一规则。
第四，写 agent 宪法，把“做什么功能都得守的规矩”集中写下来，让 AI 每次开工都先照着走。
这四步做完，地基和规矩就都立好了。
这里先记住一条底线：地基一旦打好，后面就尽量别再回头翻它了。
至于为什么不能翻、翻了代价有多大，下篇我们细说。
地基和规矩立好之后，下一步，才是真正让 AI 开始写代码。
怎么把每个大阶段拆成详细的小阶段，怎么让 AI 照着一步步推、还不跑偏，这些放到下篇讲。
如果你连立项都还没做，先去翻我之前的立项篇。
如果你想要那份通用的 agent 宪法模板，可以留言“宪法”。
