如果你让 AI 上来就直接写代码，那这个项目大概率已经开始跑偏了。
因为刚开始用 AI 做项目的人，最缺的往往不是代码能力，而是不知道该让 AI 按什么技术路线、什么框架规范去写。AI 很强，但如果你不给它边界，它就很容易自己发挥。今天这样写，明天那样改，最后项目看起来能跑，里面却是一团乱。
所以立项之后，不要马上开写。下一步要做的，是先确定技术栈。
所谓技术栈，你可以先简单理解成：这个项目准备用哪些技术、框架、工具和 SDK 来完成。你做的是网站、小程序、App，还是纯后端接口，对应的开发方式完全不一样。产品形态不同，技术栈就不同，后面的项目结构、开发流程、部署方式也都会不一样。
一、先确定产品形态
你现在可以先问自己一个问题：你的产品最终是以什么形式呈现给用户的？
它是一个网站？一个小程序？一个 App？一个后台管理系统？还是一个只给其他系统调用的纯后端接口？
如果这个问题你答不上来，就先别让 AI 写代码。因为产品形态都没确定，后面的技术栈一定会乱。
如果你做的是网站，就会优先考虑 Web 前端技术栈。如果你做的是小程序，就要考虑小程序平台的开发规范。如果你做的是 App，就要考虑原生开发、跨平台开发，或者其他 App 技术方案。如果你做的是纯后端接口，那前端可能暂时不是重点，接口设计、数据库和服务部署才是核心。
如果你不确定自己的产品应该做成什么形态，可以直接让 AI 根据前面的立项文档来分析。你要让它结合产品目标、用户场景、核心功能和后期规划，判断这个项目最适合做成哪一种形态，并说明理由。
注意，这里不是让 AI 随便替你拍板，而是让它基于已经讨论过的项目事实，给出一个明确的主线判断。对没有代码基础的人来说，最怕的不是没有选择，而是选择太多。你真正需要的不是一堆看起来都有道理的方案，而是一个当前最适合执行的方向。
二、技术栈不是越高级越好
很多新手很容易被各种技术名词带偏。今天听说一个框架很火，明天看到一个工具很新，就觉得自己的项目也应该用。
但做项目不是比谁用的技术更新。尤其是 Vibe Coding，更不能为了看起来高级就乱选技术栈。
你可以想一下：如果一个项目只是普通官网，有没有必要一上来搞一套特别复杂的前后端架构？如果只是一个轻量工具，有没有必要引入一堆大型框架？如果你连项目怎么部署、怎么维护都不清楚，上来就追求高级技术，最后只会让自己更难收场。
技术栈最重要的不是炫，而是适合。它要适合你的产品形态，适合你的项目复杂度，适合 AI 理解和维护，也适合你后期继续迭代。
所以选择技术栈时，一定要克制。技术选型的目标，是让项目结构清楚、边界清楚、后期能维护，而不是堆一堆听起来很厉害的名词。
三、优先选择成熟框架和 SDK
互联网技术发展到现在，很多功能其实早就有成熟方案了。你做项目时会发现，项目里涉及到的技术栈、功能模块、开发框架、第三方 SDK，往往已经有很多现成轮子。
这些成熟轮子，不只是帮你更快把产品做出来，更重要的是能帮你省掉大量试错、重写和踩坑的时间。
这也是做 Vibe Coding 时非常关键的一点：不要动不动就让 AI 从零开始造。你不会代码，更不应该让 AI 在没有框架约束的情况下自由发挥。
成熟框架的价值，不只是它提供了现成能力，还在于它通常有自己的项目结构、开发规范、最佳实践和社区经验。换句话说，它不仅告诉你“能怎么写”，也告诉你“应该怎么写”。
新手最欠缺的往往就是规范。AI 已经是一个很强的编码助手了，但如果没有规范，它就容易乱写、绕路、打补丁。相反，如果你选了一个成熟框架，并且明确要求 AI 必须遵守这个框架的官方规范、目录结构和推荐写法，项目质量通常会稳定很多。
你可以直接告诉 AI：这个项目必须严格遵守当前框架的官方规范，不允许为了图省事绕开框架设计。
仅仅这一句话，就能在一定程度上减少 AI 漂移。因为这句话意味着 AI 不能自己想怎么写就怎么写，也不能觉得哪里近就从哪里绕过去。它必须理解这个框架，在框架的边界内工作。
关于这一点，后面在讲“给 AI 立宪法”的章节里，我会单独展开。
四、怎么判断一个技术靠不靠谱
如果你完全不懂代码，不需要自己硬查所有技术细节，但至少要知道怎么让 AI 帮你判断一个框架或 SDK 靠不靠谱。
你可以让 AI 帮你查几个关键点：这个技术是不是有足够多的人在用，项目是否还在维护，文档是否完整，社区里有没有大量讨论，最近更新时间是不是太久远，授权协议是否允许商业使用。
如果是开源项目，可以让 AI 帮你查看 GitHub 的 star 数、issue 活跃度、最近提交时间、发布记录和使用案例。star 数不是唯一标准，但它能说明这个项目有没有一定关注度。社区活跃度也很重要，如果一个项目出了问题没人维护，后面你会很痛苦。
授权协议也不能忽略。有些开源项目可以随便用，有些项目对商业使用有限制。你如果准备上线运营、收费、接用户，就必须让 AI 帮你确认许可证是否允许商用。
如果你对某个 SDK 有疑问，也可以继续追问 AI。比如：这个项目是不是很久没更新了？它有没有明显风险？它适不适合商业项目？如果以后用户量变大，会不会有明显瓶颈？
你不需要自己变成技术专家，但你要学会让 AI 把这些风险讲清楚。
五、让 AI 给你唯一推荐方案
没有代码基础，也当然可以让 AI 推荐技术栈，而且应该让 AI 推荐。问题不在于能不能问 AI，而在于你怎么问。
不要只问：“这个项目用什么技术栈？”
你应该把前面已经整理好的立项文档、产品形态、功能范围、目标用户、部署要求和后期规划交给 AI，然后让它基于这些内容，给出当前项目的唯一推荐技术栈。
这里重点是“唯一推荐”。
因为对新手来说，最麻烦的不是 AI 不给方案，而是 AI 给太多方案。它列出三四套技术栈，每一套看起来都有道理，最后你反而不知道该选哪个。你没有足够的技术判断能力，就很容易在选择上来回摇摆。
所以你要让 AI 直接推荐一条最适合当前项目的主线，并说明为什么选它，为什么其他方案不适合当前项目，这套技术栈适合当前项目的哪些需求，后期可能会遇到哪些风险。
如果确实存在备选方案，也不要让 AI 把它们变成选择题。备选方案只用来说明取舍理由和潜在风险，不能影响当前主线。当前项目必须先收敛到一条清楚的技术路线。
你可以记住一句话：用 AI 做项目，最怕技术路线不稳。
今天用这个，明天换那个，后天又觉得另一个更高级。这样写到最后，项目很容易变成一堆拼起来的代码。
六、技术栈要写进项目文档
技术栈讨论完之后，一定要写进项目文档里。
不要只是口头聊完就让 AI 开始写代码。因为后面开发时间一长，对话上下文一乱，AI 很容易忘记当初为什么这么选，也可能在中途引入一堆不必要的新技术。
你应该让 AI 把技术选型写进立项文档或项目规划文档里。里面至少要说明：产品形态是什么，前端用什么，后端用什么，数据库用什么，主要框架和 SDK 是什么，为什么这么选，哪些技术不用，什么情况下才需要重新评估技术路线。
这份文档不是摆设。它后面会成为 AI 开发项目时的重要依据。每次 AI 想引入新框架、新库、新架构时，都应该先回到这份文档里看一眼：这是不是符合当前技术路线？有没有破坏项目边界？有没有让项目变复杂？
技术选型不是为了限制项目，而是为了让项目有一条清楚的主线。
七、最后
选择技术栈，本质上是在给项目选地基。
很多人刚开始 Vibe Coding，最容易犯的错误就是一上来让 AI 直接写。看起来很快，实际上项目很容易越写越乱。因为 AI 不知道你最终要做成什么产品，也不知道应该遵守哪套框架规范，更不知道哪些技术该用、哪些技术不该用。
所以在正式写代码之前，你至少要先确认三件事：产品形态是什么，技术栈是什么，框架规范是什么。
产品形态决定项目往哪里走。技术栈决定项目用什么工具做。框架规范决定 AI 不能乱写。
这一步做好了，后面写代码才不容易漂移。
