总结之Vibe Coding：选择技术栈
Vibe Coding立项：选择技术栈 确定产品的呈现形式和技术栈
概览部分
内容摘要
本视频详细讲解了在Vibe Coding项目中，如何正确地进行技术选型和产品形态的确定。内容涵盖从立项阶段开始就避免AI直接写代码的误区，到明确产品形态、技术栈选择的原则、成熟框架的重要性、技术风险评估方法、让AI给出唯一推荐方案的技巧，以及将技术栈写入项目文档的必要性。通过这些步骤，确保项目有一个清晰的技术路线，避免后期出现混乱。
核心观点
- 技术栈选择应基于产品形态，而不是追求“高级”
- 成熟框架能提供规范、结构和最佳实践，帮助AI更有效地工作
- 技术选型不是越多越好，而是越合适越好
- 项目文档中必须明确记录技术栈选择的原因和边界
- AI不能随意发挥，需要有明确的框架和规范限制
目录
- 为什么不能一开始就让AI写代码
- 先确定产品形态
- 技术栈不是越高级越好
- 如何判断一个技术是否靠谱
- 让AI给出唯一推荐方案
- 技术栈要写进项目文档
- 技术栈选择的本质是给项目选地基
1. 为什么不能一开始就让AI写代码
如果你让AI上来就直接写代码，那这个项目大概率已经开始跑偏了。因为刚开始用AI做项目的人，最缺的往往不是代码能力，而是不知道该让AI按什么技术路线、什么框架规范去写。AI很强，但如果你不给他边界，他就很容易自己发挥，今天这样写，明天那样改，最后项目看起来能跑，里面却是一团乱。
关键观点: 在没有明确技术路线和产品形态的前提下，AI无法有效执行任务，反而容易导致项目失控。
技术栈的定义与重要性
所谓技术栈，你可以先简单理解成这个项目准备用哪些技术框架、工具和SDK来完成？你做的是网站、小程序、App？还是纯后端接口？对应的开发方式完全不一样。产品形态不同，技术栈就不同，后面的项目结构、开发流程、部署方式也都会不一样。
2. 先确定产品形态
你现在可以先问自己一个问题：你的产品最终是以什么形式呈现给用户的？它是一个网站？一个小程序？一个App？一个后台管理系统？还是一个只给其他系统调用的纯后端接口？
如果这个问题你答不上来，就先别让AI写代码。因为产品形态都没确定，后面的技术栈一定会乱。
不同产品形态对应的技术栈
| 产品形态 | 技术栈重点 |
|---|---|
| 网站 | Web前端技术栈（如React/Vue） |
| 小程序 | 微信/支付宝小程序开发规范 |
| App | 原生开发、跨平台框架（如Flutter） |
| 后端接口 | 接口设计、数据库、服务部署 |
关键观点: 产品形态决定了技术栈的选择方向，没有明确的产品形态，技术栈的选择会变得盲目。
你可以让AI根据前面的立项文档来分析。你要让它结合产品目标、用户场景、核心功能和后期规划，判断这个项目最适合做成哪一种形态，并说明理由。
3. 技术栈不是越高级越好
很多新手很容易被各种技术名词带偏，今天听说一个框架很火，明天看到一个工具很新，就觉得自己的项目也应该用。但做项目不是比谁用的技术更新，尤其是Vibe Coding，更不能为了看起来高级就乱选技术栈。
技术栈选择的原则
你可以想一下，如果一个项目只是普通官网，有没有必要一上来搞一套特别复杂的前后端架构？如果只是一个轻量工具，有没有必要引入一堆大型框架？
关键观点: 技术栈最重要的不是炫技，而是适合，要适合你的产品形态、项目复杂度、AI理解和维护能力，以及后期迭代需求。
所以选择技术栈时一定要克制，技术选型的目标是让项目结构清楚、边界清楚、后期能维护，而不是堆一堆听起来很厉害的名词。
4. 如何判断一个技术是否靠谱
如果你完全不懂代码，不需要自己硬查所有技术细节，但至少要知道怎么让AI帮你判断一个框架或SDK靠不靠谱。
你可以让AI帮你查几个关键点：
- 这个技术是不是有足够多的人在用？
- 项目是否还在维护？
- 文档是否完整？
- 社区里有没有大量讨论？
- 最近更新时间是不是太久远？
- 授权协议是否允许商业使用？
如果是开源项目，可以让AI帮你查看GitHub的Star数、活跃度、最近提交时间、发布记录和使用案例。Star数不是唯一标准，但它能说明这个项目有没有一定关注度。
关键观点: 技术选型前必须评估其稳定性和可维护性，尤其是对于商业项目。
社区活跃度也很重要。如果一个项目出了问题没人维护，后面你会很痛苦。授权协议也不能忽略。有些开源项目可以随便用，有些项目对商业使用有限制。你如果准备上线运营、收费接用户，就必须让AI帮你确认许可证是否允许商用。
5. 让AI给出唯一推荐方案
没有代码基础，当然可以让AI推荐技术栈，而且应该让AI推荐。问题不在于能不能问AI，而在于你怎么问。
不要只问“这个项目用什么技术栈”，你应该把前面已经整理好的立项文档——产品形态、功能范围、目标用户、部署要求和后期规划——交给AI，然后让他基于这些内容给出当前项目的唯一推荐。
为什么不能让AI列出多个方案
因为对新手来说，最麻烦的不是AI不给方案，而是AI给太多方案。他列出三四套技术栈，每一套看起来都有道理，最后你反而不知道该选哪个。你没有足够的技术判断能力，就很容易在选择上来回摇摆。
关键观点: 新手最需要的是一个明确的主线，而不是多个看似合理但难以取舍的选项。
你要让AI直接推荐一条最适合当前项目的主线，并说明为什么选它，为什么其他方案不适合当前项目？这套技术栈适合当前项目的哪些需求？后期可能会遇到哪些风险？
如果确实存在备选方案，也不要让AI把它们变成选择题。备选方案只用来说明取舍理由和潜在风险，不能影响当前主线。
6. 技术栈要写进项目文档
技术栈讨论完之后，一定要写进项目文档里，不要只是口头聊完就让AI开始写代码。因为后面开发时间一长，对话上下文一乱，AI很容易忘记当初为什么这么选，也可能在中途引入一堆不必要的新技术。
你应该让AI把技术选型写进立项文档或项目规划文档里，里面至少要说明：
- 产品形态是什么
- 前端用什么
- 后端用什么
- 数据库用什么
- 主要框架和SDK是什么
- 为什么这么选
- 哪些技术不用
- 什么情况下才需要重新评估
关键观点: 技术选型不是为了限制项目，而是为了让项目有一条清楚的主线。
这份文档不是摆设，它后面会成为AI开发项目时的重要依据。每次AI想引入新框架、新库、新架构时，都应该先回到这份文档里看一眼，这是不是符合当前技术路线？有没有破坏项目边界？有没有让项目变复杂？
7. 最后选择技术栈本质上是在给项目选地基
很多人刚开始Web coding最容易犯的错误就是一上来让AI直接写，看起来很快，实际上项目很容易越写越乱。因为AI不知道你最终要做成什么产品，也不知道应该遵守哪套框架规范，更不知道哪些技术该用，哪些技术不该用。
所以，在正式写代码之前，你至少要先确认三件事：
- 产品形态是什么
- 技术栈是什么
- 框架规范是什么
产品形态决定项目往哪里走，技术栈决定项目用什么工具做，框架规范决定AI不能乱写。这一步做好了，后面写代码才不容易漂移。
总结与行动建议
全文总结
本文详细阐述了在Vibe Coding项目中，如何正确地进行技术选型和产品形态的确定。从一开始就要避免让AI直接写代码，而是先明确产品形态，再选择合适的框架和工具。技术栈的选择应以实际需求为导向，而不是追求“高级”。同时，要让AI给出唯一的推荐方案，并将技术栈写入项目文档，作为后续开发的依据。
核心收获
- 技术栈选择应基于产品形态，而非技术热度
- 成熟框架能提高开发效率并减少风险
- 技术选型需考虑稳定性、可维护性和商业适用性
- AI不能随意发挥，需有明确的框架和规范限制
- 技术栈应写入项目文档，确保开发一致性
- 项目初期明确技术路线是防止后期混乱的关键
行动建议
- 在项目立项阶段，明确产品形态和目标用户
- 避免盲目追求新技术，优先选择成熟稳定的框架
- 使用AI时，明确技术路线和规范要求
- 将技术栈和决策原因写入项目文档
- 定期回顾技术栈，评估是否需要调整
延伸思考
- 如何平衡技术先进性与实用性？
- 如果项目后期需求变化，如何灵活调整技术栈？
- 如何评估AI生成代码的质量与规范性？
附录
术语表
- 技术栈（Tech Stack）：用于构建和运行应用程序的一组技术和工具的集合。
- 框架（Framework）：为开发提供基础结构和规范的软件平台。
- SDK（Software Development Kit）：用于开发特定平台或系统的工具集。
- MVP（Minimum Viable Product）：最小可行产品，指能验证市场需求的最简版本。
- CI/CD（Continuous Integration / Continuous Delivery）：持续集成与交付，指自动化测试和部署流程。
参考资料
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
5
0- 0
已为社区贡献12条内容
所有评论(0)