Lock-In Is Fine. Lock-Out Isn't.
所有人都怕错了锁定的对象。
恐惧的对象是模型。如果我们在供应商 X 的模型上构建，我们就被锁定了。如果供应商 X 改了价格、条款，或者模型本身，我们就卡住了。于是组织花了几个月去构建抽象层，以避免依赖任何单一模型——而在这个过程中，制造了真正有伤害的锁定：被挡在生态系统之外。
我直说：模型锁定大多是个迷思，而为防止它而构建的抽象层，通常才是真正的陷阱。模型在重要的方面是可以互换的。你真正应该害怕的，是被挡在让任何模型能运转的工具、评估和运营知识之外。
为什么模型锁定是错的恐惧
模型会变。这不是风险，而是事实，而且正是这个事实让模型锁定变得可以承受。你今天用的前沿模型，不是十八个月后你会用的那个，而这无论你建不建抽象层都一样，因为供应商自己也一直在改自己的模型。你早已站在一个移动的平台上。问题从来不是模型会不会在你脚下变。问题是你能否验证新模型仍然管用。
这就是消解锁定恐惧的那个洞察：你真正的依赖不是模型，而是评估。如果你能拿测试集跑一遍新模型，看看它是变好还是变坏，切换就是一个周末的活。评估集才是可迁移的资产。它是你对每个模型供应商的议价能力，因为它意味着你想走就能走。
真正被卡住的团队，不是那些用单一模型的。而是那些没有评估集的——他们无法判断新模型是不是更好，所以出于恐惧留在旧模型上。那才是锁定。这不是供应商造成的。是缺失的评估造成的。
抽象层保护不了你免于锁定。评估集才行。一个是一堆会腐烂的代码。另一个是让每个模型变成商品的资产。
真正存在的锁定：被挡在外面
值得担心的锁定，是被挡在外面：无法参与到这项技术周围的生态系统中。
AI 生态在快速前进，而它是通过工具前进的。评估框架、可观测性工具、编排标准、MCP 风格的连接器、社区实践——运营知识就住在这里。一个什么都自建、以规避锁定为名把自己隔绝在生态之外的团队，就是一个必须重新发明生态所交付的每一项改进的团队。
这才是昂贵的锁定。它不会出现在合同里。它表现为一个在每项实践上都落后六个月的团队，因为他们的自定义层连不上任何东西。他们不是被供应商锁定的。他们把自己锁在了外面。
什么该标准化，什么该联姻
这个划分是清晰的，而且和其他平台决策的划分一样。
把可迁移的层标准化：评估、提示词、遥测。这些是你的资产。它们编码了你的质量基准、领域知识和运营历史。它们应该用到处都能跑的格式——纯测试文件、纯提示词文件、纯日志。这些是你拥有的东西，也是让切换成为可能的东西。在这里放心投入。
把商品化的层联姻：模型 API、向量库、编排框架。这些是可以互换的。如果供应商改了价格或模型，你应该能用合理的工作量替换它们——而合理的量由你的评估集和提示词可迁移性来定义，而不是由一个试图把每个供应商藏在假想统一接口后面的抽象层来定义。
造成最多痛苦的抽象层，是那些试图让每个供应商变得一模一样的。它们做不到。它们只是加了一层 bug、一层版本漂移，以及一层用不上供应商最佳特性的团队，因为抽象不暴露那些特性。对每个供应商做尽可能薄的集成，保持评估和提示词可迁移，把供应商当成它们本来的样子：可替换的。
对你的设置的测试
问两个问题。你能这周把评估跑在另一个模型上吗？你的团队了解生态工具，还是只了解你们内部的封装？
如果评估能在另一个模型上干净地跑，你就没有被锁定。如果你的团队能不开培训课就走进一个新工具的文档，你就没有被挡在外面。第一个问题保护你的未来。第二个保护你的能力。
你今天用的模型，不会是你两年后用的那个。没关系。重要的是你构建的知识——评估集、提示词、运营实践——能否随你一起迁移。当你拥有评估时，锁定是迷思。当你把自己隔绝在生态之外时，被挡在外面才是真实。
标准化你拥有的。联姻可替换的。然后停止构建抽象层。它在保护你免受一个评估集早已解决的恐惧。