AI 编码助手写不出一个好框架：为什么"会写代码"和"能做产品"是两回事

2025 年初，"Vibe Coding"这个词火遍全网。前 OpenAI 联合创始人 Andrej Karpathy 发了一条推，大意是：你不用会写代码了，只要能用自然语言描述你想要什么，AI 就能帮你写出来。

这条推被转了几万次，无数人开始畅想"人人都是程序员"的未来。一年多过去了，Cursor、Claude Code、GitHub Copilot 这些 AI 编码工具确实越来越强，日常写代码的效率提升是实实在在的。但如果你真的用这些工具从零开始搭建一个面向企业的 AI 应用，很快就会发现一个尴尬的现实：AI 编码助手可以帮你写代码，但它写不出一个好框架。

一、编码助手和开发框架，根本不是同一个东西

先厘清两个概念。

AI 编码助手（Cursor、Copilot、Claude Code 等）是帮你"写代码"的工具。你告诉它要实现什么功能，它帮你生成代码片段、补全逻辑、甚至写一整个文件。它的核心能力是代码生成——把人的意图翻译成机器能执行的指令。

AI 应用开发框架（如 Spring Boot、LangChain、Dify，以及面向企业 AI 的 JBoltAI 等）是一套已经设计好的"骨架"。它定义了项目的目录结构、配置规范、核心组件的协作方式、安全策略、部署流程等。你基于这个骨架来填充具体的业务逻辑，就像在毛坯房里做装修，而不是从打地基开始盖房子。

这两者的区别可以用一句话概括：编码助手解决的是"怎么写"的问题，开发框架解决的是"怎么组织"的问题。

AI 编码助手可以帮你快速写出一个 API 接口、一段数据处理逻辑、一个前端页面的代码。但它不会帮你决定这个接口应该放在哪个模块、数据应该在哪个层级处理、前端和后端怎么分工、出了异常怎么兜底——这些是框架和架构该做的事。

二、Vibe Coding 的蜜月期已经结束了

2025 年是 Vibe Coding 的蜜月期，很多人用它快速搭出了 demo、原型、个人小工具，感觉"开发变得太简单了"。但到了 2026 年，问题开始集中爆发。

Reddit 的 r/vibecoding 社区有一条高赞讨论：“2025 年 introduced vibe coding. 2026 will expose weak foundations.”（2025 年引入了 vibe coding，2026 年将暴露薄弱的基础）。这条讨论引发了大量共鸣——很多用 Vibe Coding 快速搭建的项目，到了需要扩展、维护、多人协作的阶段，基本上都崩了。

知名技术博主 Tony Bai 在 2026 年初写了一篇深度文章《停止 Vibe Coding，拥抱新一代软件工程》，核心批评了 Vibe Coding 的两个致命缺陷：

没有任何架构直觉。AI 编码助手在生成代码时，完全不顾及系统未来的可维护性。它不知道这段代码三个月后会不会成为技术债务，不知道当前的模块划分会不会在未来扩展时变成瓶颈。它只管"现在能跑"，不管"以后能改"。

极其盲目自信。AI 编码助手会在没有彻底理解业务意图时就匆忙输出代码。你以为它在帮你，实际上它可能把你的业务逻辑搞反了。更危险的是，它输出的代码看起来很"像那么回事"，但如果你的团队没有足够的判断力去审查，bug 和技术债就会悄悄堆积。

Karpathy 本人在 2026 年 2 月也更新了他的观点：随着 LLM 能力的飞跃，早期的 Vibe Coding 已经略显过时，未来的方向属于 Agentic Engineering（智能体工程）——也就是人类和 AI 之间要有更规范的协作流程，而不是"我随便说，AI 随便写"。

钛媒体的报道也提出了类似的方向：2026 年更需要的是Spec Coding（规约编程）范式——在动手之前，人类和 AI 必须先达成一套关于架构、边界和逻辑的规约。而这套规约，本质上就是一个框架的定义。

三、框架到底提供了什么，是编码助手给不了的

具体来说，一个成熟的 AI 应用开发框架提供了以下几个层面的能力，这些是 AI 编码助手目前无法替代的：

约定优于配置（Convention over Configuration）

框架通过预先定义好的约定，让开发者不用在"每个项目都重复做"的决策上浪费时间。比如数据库连接怎么管理、日志怎么输出、异常怎么统一处理、API 返回格式怎么规范。这些约定一旦确定，团队里所有人（包括 AI 助手）都在同一个标准下工作。

AI 编码助手可以帮你写一个数据库连接的代码，但它不会帮你建立"全项目统一使用这个连接方式"的约定。如果你不主动去约束它，它可能在这个文件里用一种方式，在另一个文件里用另一种方式。

组件化和抽象层

成熟的框架把常见的开发需求抽象成了可复用的组件。比如用户认证、权限控制、文件上传、消息队列、缓存管理——这些在框架里都是现成的模块，开箱即用。你只需要配置和使用，不需要每次都从头实现。

AI 编码助手当然也能帮你写这些模块的代码，但每次都要重新生成、重新调试、重新适配你当前的项目结构。而且它写出来的版本不一定考虑了边界情况、性能优化和安全防护。

工程化基础设施

一个完整的应用不只是代码，还包括构建流程、测试框架、部署方案、监控告警、配置管理等。这些工程化能力通常由框架或其生态提供，比如 Spring Boot 的 Actuator、Maven/Gradle 的插件体系、Docker 的标准化镜像构建。

AI 编码助手可以帮你写一个 Dockerfile，但它不会帮你设计一套适合你团队的 CI/CD 流程、不会帮你定义什么指标需要监控、不会帮你在凌晨三点出了线上问题的时候自动降级。

团队协作规范

框架不仅仅是技术工具，它还是团队协作的"共同语言"。当一个团队都基于同一个框架开发时，新人上手快、代码审查有标准、模块之间可以清晰分工。这种协作效率是任何编码助手都无法提供的。

四、AI 编码助手和开发框架的正确关系

理解了上面的区别，就能看清 AI 编码助手和开发框架之间的正确关系：不是替代，而是互补。

框架提供骨架和规范，编码助手帮你更快地填充血肉。就像有了建筑设计图和施工标准之后，电钻和搅拌机能大大提高施工效率——但电钻不会告诉你房子该怎么设计。

在实际开发中，这个关系体现为：

• 框架定义项目结构、模块划分、编码规范
• 编码助手在这个框架内生成符合规范的代码
• 框架提供可复用的组件，编码助手帮你正确地调用和组合这些组件
• 框架处理工程化问题（构建、部署、监控），编码助手帮你写业务逻辑代码

更进一步说，优秀的框架本身也在适应 AI 编码助手的时代。比如一些框架开始优化自身的"token 友好性"——让 AI 更容易理解框架的约定和模式，减少编码助手在理解框架时的"幻觉"。

山东向量空间人工智能科技推出的 JBoltAI 就是一个典型的例子——它作为面向 Java 企业团队的 AI 应用开发框架，内置了 RAG、Agent 编排、知识图谱等 AI 能力模块，开发者基于它的架构规范来开发，然后用 Cursor、Copilot 等编码助手来加速业务逻辑的编写。框架负责"该怎么组织"，编码助手负责"代码怎么写"，各司其职。

五、对普通开发者的实际建议

如果你正在考虑用 AI 编码工具来提升效率，这里有几条务实的建议：

先选框架，再选编码助手。不要一上来就让 AI 帮你从零搭项目。先确定你要用什么技术栈和框架，搭建好项目骨架，然后让编码助手在这个骨架内帮你写业务代码。这样产出的代码至少在结构上是可控的。

不要让 AI 做架构决策。“用什么数据库”“怎么分层”"接口怎么设计"这些架构层面的决策，应该由人来判断。AI 可以给出建议，但最终决策权和责任在你手里。把架构决策交给 AI，就像让一个没有施工经验的实习生来设计大楼的结构。

保持对 AI 生成代码的审查习惯。AI 编码助手输出的代码看起来"很像那么回事"，但不一定是对的。尤其是涉及并发、事务、安全等场景时，AI 经常会生成看似正确但暗藏 bug 的代码。审查不能省。

用框架的约定来约束 AI。越是成熟的框架，约定越明确，AI 生成代码时的"自由发挥"空间越小，产出的代码质量就越稳定。这就是为什么"框架+编码助手"的效果远好于"纯编码助手"。

AI 编码助手让写代码变得更快更轻松，这是好事。但它改变的只是软件开发的效率，不是软件开发的本质。软件开发的核心永远是"把复杂的问题用清晰的结构组织起来"，这个结构化的能力，目前只有成熟的框架和有经验的架构师能提供。工具再好，盖房子还是得先有图纸。