「AI 替代 API?」开发者集体炸锅:你想用概率替代合同?连 OpenAI 都不敢保证!近5000人点赞

一句话点燃火药桶

5 月 2 日，Naval 在 X 上发了一句简短的断言：

“AIs replace UIs and APIs.”

「AI 会替代 UI 和 API。」

听起来很酷对吧？但开发者 Jake（@JustJake）看完直接急了，原帖引用回怼：

“Very wrong, very dangerous.”

「非常错误，非常危险。」

▲ Jake 引用回怼 Naval，近 5000 赞、22 万次浏览，201 条回复

他紧跟着甩出了核心论点：

“You want your APIs to do the exact same thing, every time.”

「你希望 API 每一次都做完全相同的事。」

“AI is great at many things; reproducibility is not one of them.”

「AI 很擅长很多事，但可复现性不在其中。」

近 5000 人点赞，22 万人围观。评论区直接炸了。

API 到底是什么？大多数人理解错了

很多人把 API 理解成「让机器知道该怎么做事的入口」——有输入、有输出，AI 也能做到，那 API 当然可以被替代。

大错特错。

在生产环境里，API 承担的是一整套工程合同：

• 相同请求，相同结果
  
  ——可测试、可回放、可 diff
• 错误语义稳定
  
  ——出错了你能定位、能追责
• 幂等控制
  
  ——重试不会重复扣款、不会重复写库
• 权限边界
  
  ——谁能调什么，白纸黑字
• 合规审计
  
  ——每一笔调用都有迹可查

评论区里一位开发者的说法非常精准：

“The contract is what makes an API an API. Swap in AI and you keep the call shape but lose the guarantee.”

「合同才是 API 之所以是 API 的原因。换成 AI，你保留了调用的样子，却丢掉了保障。」

另一位更直接：

“APIs are deterministic by design. Same input, same output, every time.”

「API 在设计上就是确定性的。相同输入，相同输出，每一次。」

连 OpenAI 自己都承认：确定性无法保证

有人可能会说：把 temperature 设成 0、固定 seed，不就稳定了吗？

OpenAI 自己的官方文档给出了答案：不行。

▲ OpenAI 官方 Cookbook：如何使用 seed 参数提高输出一致性

OpenAI Cookbook 白纸黑字写道：

“The Chat Completions and Completions APIs are non-deterministic by default.”

「Chat Completions 和 Completions API 默认就是非确定性的。」

即便你设了 seed、锁了参数、检查了 system_fingerprint，OpenAI 仍然留了一句：

“Determinism is not guaranteed.”

「确定性并不被保证。」

注意措辞——连「大部分一致」（mostly identical）都只是「尽力而为」（best effort）。后端配置一变、模型一更新，你之前所有的「稳定」可能瞬间归零。

ML6 的技术分析进一步解释了原因：在 sampling 机制里，即使 temperature=0，等概率 token 之间的随机选择、数值精度差异、后端基础设施变化，都会带来不可消除的漂移。

▲ ML6 技术文章：temperature=0 也无法保证完全确定性

他们的结论只有一句话：

“No seed-control, no determinism.”

「没有种子控制，就没有确定性。」

想想这些场景，你还敢让 AI 当边界吗？

支付系统——同一个请求，一会儿扣款成功，一会儿失败，一会儿金额解释变了。你跟用户怎么交代？

身份鉴权——权限边界靠「模型大概率理解正确」来保障。哪天概率不站在你这边，数据就泄了。

数据库写操作——写入行为没有幂等、没有回滚、没有审计。出了事，连责任都切分不清。

运维事故响应——runbook 交给 agent 执行，它「创造性地」跳过了两个步骤。P2 事故瞬间升级成 P1。

开发者 Jai Jalan 在评论区精准概括：在 incident response 里，runbook 本质上就是 API——一个会「创造性跳步」的 agent，能把 P2 变成 P1。

Brock Herion 补充：在银行、金融、医疗、法律这些行业，可复现和稳定行为就是底线，没有商量余地。

Jake 的真实态度：AI 很好，但请放对位置

Jake 后续的补充帖里说得很清楚——他反对的从来都不是 AI 参与软件系统：

“Use AI to iterate, to evolve, discrete logic (aka, code).”

「用 AI 来迭代、来演化离散逻辑（也就是代码）。」

“Handing the inconsistency to an end user is asking for pain and frustration for all involved.”

「把不一致性直接交给终端用户，等于给所有人制造痛苦。」

评论区里 Kaps 的观点最平衡：API 作为确定性合同不会消失，AI 更可能替代的是围绕 API 的文档、SDK 和集成胶水层；最终 endpoint 仍然返回确定的 JSON。

Tushar Khairnar 的补充也值得一提：AI 之所以真正变得实用，恰恰是因为 API 世界给了它结构化出口——JSON mode 这类约束能力出现后，很多应用才从「猫鼠游戏」走向可用。

AI 能力越强，越需要确定性边界来承接它的输出。

工程界已经开始动手了

争论还在继续，但工程界已经不止嘴上说说了。

Hacker News 上出现了关于 deterministic LLM 输出和 reproducible agent 系统的深度讨论。

▲ Hacker News：为什么从 LLM 获取确定性输出几乎不可能

▲ Hacker News：构建具有严格确定性保证的可复现 LLM agent

GitHub 上已经有人把理念付诸实践。一个名为 deterministic-agent-system 的项目，把 bounded tool loops、trace hash、replay bundle、capability-driven selection 这些机制打包成可运行的框架。

▲ GitHub：deterministic-agent-system，可审计、可回放、可约束的 agent 执行系统

它的 README 里有一句话特别有力：

“Integration boundaries are real.”

「集成边界是真实存在的。」

这个项目说明了一件事：如果 AI 真要往系统边界挤，路径绝对不是拿聊天输出硬顶上去。它必须先让自己变成有 trace、可回放、可约束、可验证的新型执行系统。

反方的声音也值得听

公平地说，另一边也有合理的观点。

HN 上有评论指出：如果是本地模型、固定权重、固定环境，并且没有人在背后偷偷升级，那么同样的输入可以得到更稳定的输出。问题的很大一部分来自 SaaS 提供商不断更新后端——这和「模型本身永远无法稳定」是两回事。

还有人提出了一个更深层的问题：determinism 不等于 correctness。一个系统即使每次都输出一模一样的结果，也可能是在稳定地犯错。所以把「可复现性」当唯一指标，同样会误导。

这两条反方都有道理。但从系统工程的视角看，可复现性仍然是正确性的基础设施——没有稳定行为，你无法复现 bug、做回归测试、做审计和责任切分。

Naval 那句「AI 替代 API」在大众语境里听起来像远见。但在开发者耳朵里，它的意思是：用概率分布去接管合同边界。

这就是近 5000 人点赞力挺 Jake 的原因。

AI 能替代的，是界面、说明书、胶水层。短期内难以替代的，是合同边界——那些要求可复现、可回放、可审计的系统核心。

未来如果 AI 真能继续往下吃技术栈，第一步一定是先把自己包进更严格的执行协议里——有 trace、有约束、有回放、有验证。直接替掉 API？没有这条路。

正如那个 GitHub 项目的 README 所说：

集成边界是真实存在的，不是可以被口号抹平的。

— END —