你以为是在“用框架”，其实是在“被框架塑形”
几乎所有微调项目，在最开始选框架的时候，心态都是一样的：
“先把模型跑起来最重要。”
于是大家会选择一个：
- 文档齐全
- Demo 好跑
- 社区活跃
- 看起来“什么都支持”的框架
这在项目早期，完全正确。
但如果你回头看那些：
- 做了一年
- 微调了多轮
- 业务不断变化
的项目，会发现一个非常残酷的现实：
很多项目并不是“做不下去了”，
而是“换不动了”。
这就是所谓的——
被框架锁死。
先给一个总判断（很重要）
在展开之前，我先把这篇文章的核心判断写出来：
框架锁死项目，很少是因为框架“做错了什么”，
而是因为项目在不知不觉中，把“工程判断权”让渡给了框架。
接下来我们要拆的，是这个“让渡”是如何一步步发生的。
第一阶段：框架解决的是“能不能跑”，不是“该不该这样跑”
在项目初期，框架最大的价值非常明确：
- 屏蔽复杂细节
- 提供统一接口
- 快速验证方向
这时候，框架帮你解决的是：
“能不能跑起来”
而不是：
“这个系统结构是不是合理”
问题在于：
很多项目，会把“能跑”误当成“正确”。
当你第一次跑通微调，
第一次看到 loss 下降，
你很容易产生一种错觉：
“这个方向是对的。”
而这，正是后面锁死的起点。
第二阶段：你开始围绕框架“适配问题”，而不是拆问题
这是一个非常关键、但非常隐蔽的转折点。
一开始你问的是：
- “这个问题到底该怎么解决？”
慢慢地，你开始问：
- “这个框架支不支持？”
- “按框架的方式怎么做？”
比如：
- 数据格式要不要改成框架推荐的？
- reward 能不能塞进现有接口？
- 评估能不能先用框架自带的？
这些问题在当下都非常合理。
但它们共同在做一件事：
把问题空间，压缩到框架允许的形状里。
久而久之，
你解决的已经不是“业务问题”，
而是“如何在框架里实现业务”。
第三阶段：你开始用“框架限制”解释工程妥协
当项目推进到一定阶段，你会开始听到一些熟悉的话：
- “这个框架目前不太好支持”
- “如果要改，成本有点高”
- “大家一般都这么用”
注意这些话的共同特点：
它们听起来都像“技术事实”，
但本质上是“工程妥协的理由”。
当这些理由开始频繁出现时，
你其实已经默认了一件事：
不是我们在选择方案，
而是框架在决定我们能选什么。
这一步，往往是锁死真正发生的地方。
第四阶段：评估、数据、训练流程开始被“捆绑”
这是很多项目真正失去灵活性的阶段。
你会发现：
- 数据准备必须符合某种格式
- 训练流程只能按某个 pipeline 走
- 评估结果只能从某几个指标看
一开始你可能觉得：
“统一一点，也挺好的。”
但问题在于：
当评估、训练、数据被捆在一起，
你就很难单独调整其中任何一环。
比如：
- 你想换一种评估方式
- 你想冻结模型，只跑评估
- 你想对比不同训练策略
结果发现：
“要改这个，得把那一整套都改了。”
这时候，
你已经不再是“使用框架”，
而是被它整体托管了。
第五阶段：你开始为“离开框架”计算心理成本
这是一个非常真实、但很少被正面说的阶段。
你心里可能已经隐约觉得：
“这个框架，好像不太适合我们现在了。”
但紧接着，你会想到：
- 迁移成本
- 重写代码
- 重新验证
- 团队学习曲线
然后你会告诉自己：
“算了，先凑合用吧。”
注意：
锁死从来不是技术决定，
而是心理决定。
当你开始把“离开框架”视为不可承受的风险，
框架就已经完成了对项目的锁定。
第六阶段：框架开始影响你对“问题本身”的理解
这是最危险、也最不容易被察觉的一步。
你会发现：
- 你描述问题时，用的是框架术语
- 你讨论方案时，默认某些“不可变前提”
- 你已经很难脱离框架，重新想一遍系统
比如：
- “这个只能这样做，因为框架就是这么设计的”
- “这个不是问题，框架里都是这么用的”
这时候，框架已经不只是工具，
而是：
你理解世界的方式本身。
一个非常真实的“被锁死”路径总结
先选框架 → 快速跑通
↓
问题开始围绕框架拆
↓
工程妥协被合理化
↓
流程被强绑定
↓
迁移成本心理放大
↓
项目被锁死
注意：
这里面没有哪一步是“明显错误”的。
这也是为什么它如此普遍。
框架真的“有错”吗？
说一句公道话：
绝大多数框架，都完成了它们该完成的使命。
问题不在框架，
而在于：
项目把“阶段性工具”，
当成了“长期系统基石”。
框架设计的目标通常是：
- 快
- 通用
- 覆盖常见场景
而不是：
- 长期演进
- 深度定制
- 承担业务责任
当你用一个“验证工具”跑“生产级系统”，
锁死几乎是必然结果。
一个非常实用的自检问题（强烈建议）
你可以问自己一句话：
如果明天这个框架停止维护，
我们的项目还能不能清楚地描述自己在做什么？
- 如果不能 → 项目已经被锁死
- 如果可以 → 你只是“在用框架”
这个问题，比任何技术评估都真实。
那该怎么避免被框架锁死？
这篇文章不是要你：
- 一开始就自研
- 或拒绝所有框架
而是给你一个更健康的工程态度：
把框架当“加速器”，
而不是“方向盘”。
几个非常现实的做法：
- 在框架之外，保留对问题的原始描述
- 关键决策不完全依赖框架默认流程
- 定期问一次：如果不用框架，这件事还能怎么做？
这不是浪费时间，
而是在为未来留选择权。
很多微调项目之所以被框架“锁死”，并不是选错了工具，而是缺少一个能让你始终看清“模型行为、评估逻辑和系统边界”的统一视角。像 LLaMA-Factory online 这种把训练、评估、版本对照拆得足够清晰的平台，更容易帮助团队在利用框架效率的同时，保留对工程判断的主动权。
总结：项目被锁死的那一刻，通常没人宣布
我用一句话，把这篇文章彻底收住：
项目被框架锁死时，
你并不会立刻发现，
只是有一天你突然意识到：
你已经很久没有真正“选择过”了。
框架不是敌人，
但它永远不该替你做决定。
真正成熟的工程团队，
不是“不用框架”，
而是永远知道自己为什么在用它。
