AI开发中是否应该使用框架

在 B 站看到一个视频：不要用 AI 框架，作者的观点和观众的评论很有意思，因此我用 AI 将其整理了一下。

视频核心观点

视频《【AI 开发避坑指南】为什么现在不要用 AI 框架？资深工程师深度解析框架弊端》主要观点包括：

反对使用 AI 框架的主要理由：

  • 框架的致命缺陷：过度抽象化导致系统僵硬、黑盒操作难以调试追踪、性能瓶颈无法精准定位、框架升级带来架构不稳定
  • 主流框架实战问题：抽象概念增加不必要复杂度、生产环境扩展性差
  • 推荐方案：直接调用 API 进行透明化编排、使用 Python 原生数据结构管理状态、传统日志系统实现全链路追踪、聚焦业务逻辑而非框架概念
  • 从零搭建的优势：完全可维护的代码、精准的错误处理、清晰的性能优化路径、灵活的扩展能力
  • 特别提醒：DIfy 等工具虽适合 demo 演示，但在生产环境中存在链路修改困难、扩展受限等问题

评论区观点争鸣

反对使用 AI 框架的观点

1. 框架本质缺陷论

  • 不稳定性和过度抽象：早期 LangChain 一天一个新版本，文档与版本不匹配，不稳定的东西不能称为框架
  • 黑盒调试困难：框架集成度高，出 bug 后需要翻源码 debug，非常痛苦
  • 过度封装问题：过度封装而非过度抽象，设计向小白倾斜，工程师无法从正确节点入手修改，二次开发更累
  • 迭代太快：框架迭代太快，查的东西或用的方法过几天就弃用，控制台一堆警告

2. 团队协作与维护视角

  • 人员流动风险：手搓代码往往只考虑项目开始时的需求，随着项目复杂度增加，后期维护困难
  • 技术债务积累：一开始觉得简单的代码会变得越来越复杂，手搓的东西往往只会考虑初期需求
  • 团队协作成本：对日后加入项目的人来说，手搓的代码就是一坨屎，学习成本高

3. 实际开发体验

  • AI 项目特殊性：给 AI 铲屎的恶心程度大于人工代码，AI 项目风格没有定式，读起来更累
  • 调试难度：用 AI 框架稍微深入之后，去 debug 黑盒就极其难受
  • 技术栈锁定：框架暴毙或被新框架取代时，迁移成本极高

4. 替代方案优势

  • AI 辅助开发：有了 AI 之后，软件开发逐渐进入”源码模式”，看懂和修改开源项目不再困难
  • 轻量级自研：用大模型构建白盒类框架，改造成本小于重新定制一套公用的
  • 直接 API 调用：大模型领域归根到底就是成语接龙，用好 openai 包和 vllm 就行了
  • 技术稳定后再用：等技术稳定后小范围使用，现在为时过早

支持使用 AI 框架的观点

1. 团队协作与标准化

  • 沟通语言统一：框架的抽象让大家有同样的沟通语言，上手难度低
  • 开源框架优势：能发布的开源框架设计都经过社区讨论，比个人手搓的东西要强
  • 最大公约数：考虑团队协作、时间、成本控制、资源、沟通成本、稳定性、可扩展性、迭代速度等因素，大型框架是共识中的最好解决方案

2. 实际功能价值

  • 复杂度管理：AI 应用开发复杂，涉及 API、workflow、function call、记忆模块等，工作量不少
  • 具体功能便利：LangChain 的 splitter、messages、template 等类，LangGraph 的图结构，比自己实现方便且功能完善
  • 减少重复造轮：message 持久化、上下文管理、RAG 轮子解析等，框架能大幅减少代码量

3. 生产环境需求

  • 状态管理：框架能自动持久化一些记录状态，大模型输出不可预测，能尽可能观测就很重要
  • 成熟框架价值：Spring 等成熟技术之后的抽象比较合理，传统 IT 框架有必要
  • 商业风险控制：国内企业做 AI 落地商业化尽量不要用国外框架，无法保证未来框架的商业收费

4. 实用主义立场

  • 按需选择：根据问题复杂度选择，”杀鸡用牛刀”，合适是第一原则
  • 都用主义：既用手搓也用框架工具，根据具体情况选择
  • 框架是生态环节：了解框架和了解 AI 不冲突，作为了解不冲突

典型案例与具体框架评价

负面案例：

  • LangChain：被点名批评为过度设计的典型案例，历史原因有很多过度封装的东西
  • DIfy/FastGPT：适合 demo 演示，生产环境链路修改困难、扩展受限
  • 不稳定框架：Node.js 和 C++打通的框架出现提前回收对象问题，影响信任

正面案例：

  • LangGraph：基本没啥抽象，比起自己手搓方便很多，但也有内存泄漏问题
  • PocketFlow：源码才 100 行，老少咸宜，很适合新手学者手搓一遍
  • Spring AI：作为成熟技术之后的抽象，比较合理
  • PyTorch/VLLM：被认为是必要的 AI 框架

折中与理性观点

1. 区分对待论

  • 成熟度区分：已成标准的东西可以用，尽量用容易理解学习的”库”，少用大包大揽的”框架”
  • 技术类型区分：传统 IT 框架有必要，但 AI 还在发展，过早的抽象不好
  • 稳定性区分：不稳定的抽象形成的框架不应该使用

2. 实用主义论

  • 白盒优先：起码要是白盒的，能够理解和控制
  • 按需使用：体量小的可以手搓，体量大的做着做着就会发现要么做不下去，要么自己搞了一套框架雏形
  • AI 时代变化：AI 降低了源码阅读门槛，可以基于 AI 构建轻量级框架满足当前需求

3. 发展阶段论

  • 技术发展阶段：AI 技术还在快速发展，框架抽象过早
  • 个人发展阶段：对新手来说框架会隐藏部分细节，不适合学习；对老手来说框架自由度低，难以满足高度定制化需求
  • 最佳实践：手搓是最佳实践，等 AI 发展稳定后再小范围使用框架

总结

这场争论反映了 AI 开发领域的现状：技术快速发展与工程化需求之间的矛盾。反对者强调当前 AI 框架的不成熟性、黑盒特性和对技术栈的锁定，支持者则看重框架在团队协作、标准化和复杂度管理方面的价值。

双方观点都有合理之处，关键在于根据具体场景、团队规模、项目复杂度和技术成熟度来做出合适的选择。在 AI 技术仍在快速迭代的现阶段，保持技术选型的灵活性和理性判断显得尤为重要。