AI Native 开发的 4 大痛点

开发者往往在基准测试的适用性、理解语义化版本以及确定通用标准来有效利用合适的模型方面苦恼重重。

这些挑战往往直接出现在开发者工作流中——无论是在 IDE 内集成模型，还是部署一个依赖跨模型版本输出一致性的功能。

开发者在尝试改进结果时也面临挫折——特别是因为 prompt 技巧和优化机制仍未被完全理解。

除了成本与性能比作为模型选择的首要考量，AI Native 开发者工作流的未来在于对抽象层的呼声，这些抽象层能简化多模型集成。

GPT-4.1 的表现如何？

GPT-4.1 最近发布，OpenAI 公布了其在 SWE-bench Verified 上的 54.6% 成绩，相比 GPT-4o 提升 21.4%，相比 GPT-4.5 提升 26.6%——使其成为 OpenAI 内编码类模型的领先者：

这些结果意义重大吗？这些数字略低于 Google 和 Anthropic 在同一基准上公布的 Gemini 2.5 Pro（63.8%）和 Claude 3.7 Sonnet（62.3%）的成绩。更重要的是，这个新模型的发布激化了开发者对生态系统现状的一些挫折感。

更广泛的生态系统挫折

挫折 1：基准测试的一致性

"这些基准测试简直一塌糊涂，[GPT-4.1] 在 SWE bench 上的得分怎么这么高（几乎高 20%），在 [Aider Benchmark] 上却落后于 deepseek？"— Reddit 用户

基准测试（如 SWE-bench、Aider Polyglot 等）各有各的需求集，这使得理解和信任某个领域内真正表现最佳的模型变得困难。比如，当你在开发工具中切换到一个基准得分更高的模型时，它可能无法像前一个模型那样有效地执行你的需求——尽管指标提升了。因此开发者在对模型性能达成共识上苦苦挣扎，因为结果非常依赖于任务、代码库和 prompt。

内部基准测试正在成为一项关键实践，团队开发自定义的评估框架以适应他们的具体需求。比如，为了构建一个安全的 AI Native 开发平台，Tessl 既利用已知的基准，也借助自有的基准来评估最适合其用例的模型。虽然企业和开发者这样做有正当理由，但许多开发者只想完成工作——而不是管理模型的怪癖。

值得一提的是，OpenAI 的 Michelle Pokrass 提到"[GPT-4.1] 专注于真实工作用途和实用性，而非基准测试"，这进一步强调了基准测试不应被视为终极真理的理念。

挫折 2：标准化的缺乏

"4o 配定时任务"——为什么这是一个模型而不是其他模型都能使用的工具？！— HackerNews 用户

开发者对跨模型特性和接口缺乏标准化的抗议声日益高涨。功能碎片化迫使每个任务都要手动选择模型。如果你在构建一个使用图像生成、链式推理和代码补全的开发助手，这通常意味着要拼凑多个 API 并编写回退逻辑。这让人想起 2000 年代之前的浏览器战争——为 Internet Explorer、Netscape 以及后来的 Firefox 编写网站的不同版本，因为没有 HTML、CSS 或 JavaScript 的标准实现。

标准化往往不是来自厂商的同意，而是来自用户因为共同的痛点而团结。想想 SQL 出现前的锁定和互操作性困扰。好消息是我们已经在一些地方看到了这一点，比如 OpenAI 的 API 成为事实上的标准，以及 Anthropic 的 MCP。Prompt 路由也将是解决方案的重要组成部分。类似于 HTTP 路由加 HTML 标准，prompt 路由和标准化的结合可能是化解这些挫折的出路。

挫折 3：模型版本中的语义漂移

GPT-4.1 的发布突显了困惑。围绕 GPT-5 即将推出有很多炒作，在 GPT-4.5 令人失望的结果之后，OpenAI 发布了 4.1。为什么是 GPT-4.1？回归 4.1 这一举动感觉在语义上像是倒退了（GPT-4.1 对比 GPT-4o 对比 GPT-4 Turbo——这到底怎么回事？）。

虽然声称和早期结果显示有改进，且 4.5 和 4.1 之间的关注点不同，但它仍留下了困惑的余地。如果你一直在构建可重复的 prompt 流程，你至少会对"模型迷宫"感到有点不知所措——更高的更好？更快？更新？

话说回来，这种歧义并未被忽视。OpenAI 已经意识到了这些命名混乱，我们应该期待未来的迭代能为语义和分类框架带来更多清晰。

挫折 4：Prompt 和手工操作

OpenAI 发布推荐工作流是 prompt 变得系统化而非靠感觉的信号。然而，社区中存在一种挫折感，这些实践仍感觉更像是猜测而非真实、可量化的方法。

开发者报告说，微小的 prompt 改动会导致性能的巨大差异，这暴露了缺乏标准 prompt 指南的问题。另外，开发者需要以不同方式 prompt 不同的模型——这很难管理。当今的 prompt 因此类似于科学方法出现之前的炼金术——一部分直觉，一部分仪式，常常出人意料地有效，但缺乏通用原则。

话虽如此，DSPy 等工具已经提供了一条路径，将 prompt 设计转变为可重复、可测试和可改进的过程。如果你是读到这里的开发者，最后一条建议是采取"探险家"心态。我们处于一门新工程学科的原型设计阶段，需要相应地转变我们的心智模式。

最优的模型选择往往更多取决于实际约束（预算、速度、用例）而非纯粹的编码性能。成本与性能比将成为模型选择的首要考量——取代"最新最好"的心态。实际上，LLM 生态正进入"基础设施层战争"，优化和集成胜过了新颖性。

比如，Google 的 TPU 配 Gemini 2.5 不仅在 Aider 的编码基准上领先，而且服务成本更低、速度更快（在 Aider Polyglot 上得分 73%，成本约 $6，而 GPT-4.1 约 $10）。即使 GPT 后来用 GPT-5 反击，硬件战争涉及延迟和成本，最终可能会决定开发者和企业青睐哪个厂商。细心观察，这对开发者和组织而言是个好消息。我们正从成本底部竞争和服务效率提升的浪潮中受益！

与此同时，开发者在表达一个普遍趋势：开发者不喜欢手动挑选模型——他们希望抽象层自动处理这件事。这一转变优先考虑开发者体验，开发者期待多模型环境能承担这项工作——想想 Cursor 这样的工具，它能自动为你需要的任务挑选最合适的模型。

这种演进不只是关于基准性能——这是为了赋能开发者微调他们的基础设施：对常规任务使用更轻量、更便宜的模型，在关键时刻自动切换到更强大的模型。AI Native 开发的未来不在于手动挑选模型——而在于构建抽象层，让这些选择变得无形，使开发者能专注于构建，而非忙于调用 API。

总而言之，这是从工具匠向架构师的转变，完美对应 Patrick 的《AI Native 开发的 4 个模式》中的实现到意图的模式。如果你还没有探索过，这绝对值得一读——它为我们的前进方向提供了引人注目的蓝图。

如果你喜欢这篇文章，请务必订阅我们的通讯，以便及时获取 AI Native 开发领域的最新见解。

某些评论仅对已登录访问者可见。登录以查看所有评论。

如果需要进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。