中国AI模型最大短板：必须依赖框架才能好用

核心观点

近日，有开发者在Twitter上指出了中国AI模型（如DeepSeek、Qwen等）在实际使用中的一个关键问题：你绝对需要一个有主见的（opinionated）工具框架来让它正常工作。

Twitter讨论截图

这条推文引发了开发者社区的广泛关注，作者提到自己正在尝试多个工具框架，包括Droid、OpenCode等，并向社区征求更多建议。

什么是"Opinionated Harness"？

在软件工程中，"opinionated"（有主见的）工具指的是那些对使用方式有强烈预设和约束的框架。与之相对的是"unopinionated"（无主见的）工具，后者给用户更多自由度但也需要更多配置。

这一对概念源自软件工程领域的经典设计哲学之争。最典型的例子是Web框架领域：Ruby on Rails是"opinionated"框架的代表，它预设了项目结构、数据库命名规范、路由约定等大量"约定优于配置"（Convention over Configuration）的规则，开发者只要遵循这些约定就能快速开发；而Express.js则是"unopinionated"的代表，它只提供最基础的HTTP处理能力，项目结构、中间件选择、ORM工具等全由开发者自行决定。在AI工具链领域，一个opinionated的harness会预设好系统提示模板、输出解析规则、错误重试策略、上下文窗口管理方式等，开发者只需要"填空"即可。这种设计在模型行为不够稳定时尤为重要——框架的"主见"本质上是社区最佳实践的结晶，它用约束换取了可靠性。

从技术实现角度看，一个典型的opinionated AI harness通常包含以下核心组件：提示模板引擎（将用户输入嵌入经过验证的提示结构中）、输出解析器（用正则表达式或JSON Schema验证模型输出的格式合规性）、重试与降级策略（当模型输出不符合预期时自动重新请求或切换策略）、以及上下文窗口管理器（在多轮对话中智能裁剪历史消息以适应模型的token限制）。这些组件协同工作，将一个行为可能不够稳定的模型"驯化"为一个可预测的工具。

对于中国AI模型而言，这意味着：

原始API调用往往不够：直接使用模型的API，不加额外的提示工程和结构化约束，输出质量可能不稳定
需要额外的编排层：必须通过专门设计的工具链来规范模型的输入输出格式、工具调用方式和上下文管理
框架选择成为关键决策：不同的harness对模型行为的约束方式不同，直接影响最终效果

为什么中国模型更依赖框架？

训练目标的差异

以Claude、GPT-4等模型为代表，它们在RLHF阶段投入了大量资源来优化"开箱即用"的体验——即使用户给出模糊指令，模型也能产出结构化、可预测的输出。而中国模型在原始推理能力上可能很强，但在指令遵循的一致性和输出格式的规范性上，往往需要外部框架来补足。

RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是当前大语言模型对齐的核心技术路线。其基本流程包括三个阶段：首先用监督微调（SFT）让模型学会基本的指令遵循能力；然后训练一个奖励模型（Reward Model），用人类标注员的偏好排序数据来学习什么样的输出更好；最后用PPO（Proximal Policy Optimization）等强化学习算法，让模型的输出策略向奖励模型认为更好的方向优化。OpenAI和Anthropic在这一环节投入了大量人力和计算资源，尤其是在"指令遵循的鲁棒性"和"输出格式的一致性"方面进行了精细调优。这意味着即使用户的提示词写得不够精确，模型也能推断出用户意图并给出结构化的回答。中国模型在预训练阶段的数据规模和推理能力上已经达到了很高水平，但RLHF阶段的精细打磨——特别是针对英文开发者生态的工具调用场景——仍有提升空间。

值得补充的是，RLHF的效果高度依赖标注数据的质量和多样性。OpenAI据报道雇佣了数千名标注员，覆盖了从简单问答到复杂代码生成、从结构化输出到创意写作等极其广泛的场景。Anthropic则发展出了"Constitutional AI"（宪法AI）方法，通过让模型自我批评和修正来减少对人类标注的依赖，但仍然需要大量人类偏好数据作为基础。这种在对齐阶段的"精细打磨"是一项需要长期积累的系统工程，不仅需要计算资源，更需要对开发者使用场景的深刻理解——而这正是中国模型团队正在快速补课的领域。

工具调用（Function Calling）的成熟度

在AI编程和Agent场景中，工具调用能力至关重要。中国模型的工具调用协议和格式可能与OpenAI生态不完全兼容，需要适配层来桥接。这也是开发者在集成DeepSeek或Qwen时经常遇到的痛点。

Function Calling（函数调用/工具调用）是大语言模型从"对话助手"进化为"智能Agent"的关键能力。OpenAI在2023年6月率先在GPT-3.5和GPT-4的API中引入了这一功能：开发者可以在API请求中定义一组函数的JSON Schema描述（包括函数名、参数类型、参数说明等），模型在生成回复时会判断是否需要调用某个函数，并以结构化的JSON格式输出函数名和参数值，而非自然语言。这一机制已经成为构建AI Agent、RAG系统和自动化工作流的基础设施。OpenAI的Function Calling格式已经成为事实上的行业标准，Anthropic的Claude也采用了类似但略有不同的Tool Use协议。中国模型如DeepSeek和Qwen虽然也支持工具调用，但在协议格式、并行调用支持、嵌套调用处理等细节上可能与OpenAI标准存在差异，这就需要中间适配层来进行格式转换和错误处理。

具体来说，开发者在实践中常遇到的兼容性问题包括：参数格式差异（某些模型可能输出非标准JSON，如使用单引号而非双引号、遗漏必填字段等）；调用时机判断不一致（模型可能在不需要工具调用时仍然尝试调用，或在需要时未能识别调用意图）；多工具协调问题（当定义了多个可用工具时，模型选择正确工具的准确率可能下降）；以及流式输出兼容性（在streaming模式下，工具调用的JSON可能被拆分成多个chunk，不同模型的拆分方式各异）。这些看似细小的差异在生产环境中会被放大为严重的可靠性问题，而一个好的harness正是通过统一处理这些边界情况来提供稳定的开发体验。

系统提示的敏感度

部分中国模型对系统提示（System Prompt）的响应方式与其他主流模型存在差异，一个精心设计的harness可以通过标准化的提示模板来消除这些差异。

系统提示是开发者在API调用中设置的特殊指令，用于定义模型的角色、行为边界和输出规范。在技术实现上，系统提示通常作为对话历史中的第一条消息（role: system），其权重和影响力在不同模型的训练过程中被赋予了不同的优先级。不同模型对系统提示的权重分配和遵循程度各不相同——有些模型会严格遵循系统提示中的格式要求，而有些模型则可能在多轮对话中逐渐"遗忘"系统提示的约束，这种现象被称为"指令漂移"（Instruction Drift）。

造成这种差异的技术原因在于注意力机制的实现细节：随着对话轮次增加，系统提示在注意力窗口中的相对位置越来越远，其对后续token生成的影响力可能逐渐衰减。一些模型通过特殊的位置编码策略或注意力偏置来缓解这一问题，但效果因模型而异。一个好的harness会采用多种策略来对抗指令漂移：在每次交互中动态注入和强化关键指令（即"提示注入"技术）、在对话历史中周期性地重复核心约束、或者通过输出验证器在后处理阶段检测并纠正偏离系统提示要求的输出。

当前可用的工具框架

推文作者提到了几个正在尝试的选项：

Droid：专为AI编程设计的终端工具
OpenCode：开源的代码生成框架
其他社区工具：如Aider、Continue等也在积极适配中国模型

这些框架的核心价值在于：它们预设了与模型交互的最佳实践，包括提示格式、重试策略、输出解析规则等，让开发者不必从零摸索。值得注意的是，这些工具大多采用了"适配器模式"（Adapter Pattern）的架构设计——通过一个统一的抽象接口屏蔽不同模型之间的差异，让开发者可以用相同的代码逻辑切换不同的底层模型，同时由框架内部处理各模型特有的格式转换和异常处理逻辑。

适配器模式是经典的面向对象设计模式之一，其核心思想是在不修改现有代码的前提下，通过一个中间转换层让原本接口不兼容的组件能够协同工作。在AI工具框架中，这意味着框架会定义一套标准化的"模型接口"（如统一的消息格式、工具定义格式、响应解析方式等），然后为每个具体模型实现一个适配器，负责将标准格式转换为该模型特有的格式，并将模型的原始响应转换回标准格式。这种架构的优势在于：当新模型出现或现有模型API发生变更时，只需要修改对应的适配器，而不需要改动上层业务逻辑。例如，Aider框架就维护了一个模型元数据文件，记录了每个支持模型的token限制、特殊格式要求和已知quirks，框架在运行时根据这些元数据自动调整交互策略。

对开发者的启示

框架选型建议

如果你计划在项目中使用中国AI模型（尤其是DeepSeek、Qwen系列），不要期望像使用Claude那样"即插即用"。提前评估和选择合适的框架工具，将显著降低集成成本。

具体而言，选型时应重点关注以下维度：

框架对目标模型的适配深度：是否针对特定模型做过优化，是否有该模型的专属配置文件或提示模板。一些框架可能只是简单地将OpenAI格式的请求转发给兼容API，而没有针对模型特性做深度优化。
社区活跃度和更新频率：模型API经常变动（如DeepSeek在2025年初多次更新其API规范），框架需要及时跟进。GitHub上的commit频率、issue响应速度和PR合并效率都是重要参考指标。
回退策略支持：当主模型不可用时（如遭遇限流、服务降级或区域性网络问题）能否自动切换到备选模型。在生产环境中，单一模型依赖是一个显著的风险点。
可观测性：框架是否提供详细的日志、token使用统计和延迟监控。在调试模型行为异常时，能够看到完整的请求/响应链路至关重要。
许可证和长期维护承诺：开源框架的许可证类型（MIT、Apache 2.0等）决定了你能否在商业项目中自由使用，而项目背后是否有公司或稳定团队支持则影响其长期可持续性。

生态成熟度的信号

这个问题本质上反映了中国AI模型生态的一个发展阶段——模型本身的能力已经很强，但围绕模型的开发者体验（DX）和工具链还在追赶中。随着社区的持续投入，这个差距预计会逐步缩小。

开发者体验（Developer Experience，简称DX）是衡量一个技术平台或工具生态成熟度的重要维度，涵盖了从API设计、文档质量、SDK完善度、错误信息可读性到社区支持等方方面面。在AI模型领域，DX的好坏直接决定了模型的实际采用率——一个能力稍弱但DX优秀的模型，在实际项目中的表现可能优于一个能力更强但难以集成的模型。

OpenAI之所以能在开发者社区建立起强大的生态护城河，很大程度上归功于其在DX上的持续投入：统一且向后兼容的API格式、详尽的文档（包含大量实际代码示例）、丰富的官方SDK（覆盖Python、Node.js、Go、Java等主流语言）、Playground调试工具（让开发者无需写代码就能测试模型行为）、以及活跃的社区论坛和开发者大会。这种生态投入形成了强大的网络效应：更多开发者使用→更多第三方工具和教程→更低的学习门槛→更多开发者使用。

中国AI模型在DX方面的差距并非能力问题，而是生态建设的时间差——OpenAI从2020年GPT-3 API发布至今已经有五年的生态积累，而DeepSeek、Qwen等模型的开放API历史要短得多。好消息是，中国AI社区正在快速弥补这一差距：DeepSeek提供了兼容OpenAI格式的API接口降低迁移成本，Qwen团队持续完善其开源模型的文档和示例，越来越多的开源工具和适配框架正在涌现。从历史经验看，中国技术社区在追赶阶段往往展现出惊人的速度——正如移动互联网时代中国开发者生态在短短几年内从追赶到并跑甚至局部领先的经历。

总结

中国AI模型在性价比和推理能力上已经展现出强大竞争力，但"好用"和"能用"之间的距离，往往就是一个好框架的距离。对于追求效率的开发者来说，选对harness可能比选对模型更重要。

这也揭示了AI行业的一个更深层趋势：随着基础模型能力趋于同质化，竞争的焦点正在从"谁的模型更强"转向"谁的生态更完善"——工具链、开发者体验和社区生态将成为决定市场格局的关键变量。这一趋势在技术史上并非首次出现：PC时代的Windows之所以击败技术上更优秀的OS/2和Mac OS，很大程度上靠的是更丰富的软件生态；移动时代iOS和Android的竞争也最终演变为开发者生态的竞争。在AI时代，模型能力是必要条件，但生态完善度才是充分条件——而opinionated harness正是连接模型能力与开发者生产力之间的关键桥梁。