2026年开发实录：AI写代码还用得着指定技术栈吗？

:joy:

从零开始的项目，是指定技术栈好使？还是以结果为导向让AI出方案？

最近在折腾几个新项目，突然发现一个很有意思的现象：以前我们写代码，首选是找个成熟的脚手架，比如若依、go-admin这种，图的就是个结构稳、心里踏实。但自从现在的IDE里都塞进了强力的AI助手，事情好像开始变味了。

到底是从零开始指定技术栈更靠谱，还是把需求扔给AI，让它自己看着办？今天就来聊聊这背后的“坑”与“解”。

在AI彻底接管IDE之前，不管是做中大型项目还是小工具，我几乎都会绑定一个固定的技术栈框架。

这么做的好处显而易见：

这种模式虽然被诟病“过度设计”，但在商业项目中，稳定性往往比新颖性更重要。但问题是，这种模式有时候显得不够“快”，尤其是应对那些逻辑简单、变化极快的小需求。

现在的AI编程助手（比如Cursor之类）已经强得离谱。于是我开始尝试一种新策略：

听着很美好，对吧？实际跑下来，情况有点失控。

在尝试“让AI全权负责”时，我踩了几个坑，大家可能也会遇到：

1. 框架约束形同虚设 即使在指定了框架的项目里，如果你不盯着AI的每一个输出，它非常有可能会“自作聪明”地引入一堆你不需要的第三方库，或者用一种非官方推荐的奇怪方式实现功能。结果就是代码能跑，但跟项目整体风格格格不入，像个补丁。

2. “梦游式”代码结构 在那些完全放手的小型项目里，情况更糟。AI往往是想到哪写到哪。今天它觉得这个功能适合放utils，明天它可能觉得新建个helpers更顺手。一段时间后，项目结构变得像一团乱麻，维护成本甚至高于从手写。

3. Review 的噩梦 最痛苦的不是写代码，而是Review AI生成的代码。人类Review人类代码，是看逻辑漏洞；人类Review AI代码，除了看逻辑，还得时刻提防它是不是又引入了安全漏洞，或者把复杂的循环写成了O(n²)的炸弹。

有观点认为，“既然是AI写的，应该没问题，就不需要看了吧？”

千万别信这个邪。

如果不了解业务实现流程，不进行人工Review，上线出Bug了你都不知道去哪查。就像有位大牛说的：“不了解业务，线上bug你都不知道是什么，除非是想背锅。”

AI目前最大的短板在于“上下文遗忘”和“缺乏业务理解”。它能写出完美的排序算法，但它不知道你的业务里这个排序字段在某些特殊情况下可以是空的。这些边缘情况，必须靠懂业务的人去把关。

结合最近的踩坑经验，我觉得目前的最佳实践应该是这样的：

框架依然是“锚点”：不管AI多强，对于需要长期维护的项目，一定要先定好骨架（Tech Stack & Architecture）。让AI在骨架里填肉，而不是让它自己长骨头。
Strict Prompting (严格提示词)：不要只说“帮我实现一个登录功能”。要说“在现有的Laravel项目中，使用中间件验证，遵循PSR-4规范，实现一个基于JWT的登录功能”。约束越细，跑偏概率越低。
分层Review策略：
- 关键路径/核心业务：必须由资深开发者逐行Review。
- 通用工具/UI组件：可以放宽标准，甚至部分依赖自动化测试来验证。
别丢了业务感：开发不再是纯粹的翻译器。我们现在的角色更像是“架构师 + 审核员”。你必须清楚业务数据的流向，才能在AI给出的方案里做正确的取舍。

AI确实极大地提升了编码效率，但它还没聪明到能完全替代“项目管理”和“架构设计”的层面。从零开始的项目，指定技术栈依然是目前平衡“速度”与“可控性”的最优解。

至于全放手交给AI？至少在现阶段，那无异于在沙子上盖楼。

你在最近的开发中有遇到AI“乱来”的情况吗？欢迎在评论区分享你的解决方案。