这不是一次失败的复盘，而是一段完整工程实践后的清醒选择。

最近一段时间，我从零开始设计并实现了一个 OpenAI-compatible 的 AI Gateway。它支持 streaming、usage 观测、quota 治理、Admin 可视化，甚至已经能做到“可解释的治理闭环”——你可以清楚看到一次请求是如何发生的、token 是怎么被消耗的、配额为何变化，以及管理动作最终带来了什么结果。

从技术角度看，这个项目是成立的。但我最终还是选择停下。

这篇文章，不是总结“我哪里做错了”，而是记录一个更重要的问题：

为什么一个技术上成立、工程上完整的系统，依然不值得继续推进？

一、最初的动机：一个看起来“非常正确”的问题

一开始的出发点并不复杂。随着公司内部越来越多团队开始使用大模型，问题逐渐显现出来：

  • Key 分散在各个项目里
  • 用量不可见、成本不可控
  • 没有统一的治理与解释能力

于是，一个几乎是“工程师本能”的想法出现了：

能不能做一个统一的 AI Gateway？

  • 统一 Key
  • 统一 usage
  • 统一 quota
  • 统一治理

从架构视角看，这个方向非常合理，甚至有点“教科书式正确”。

二、我不是停在想法阶段，而是真的把它做完了

这个项目并不是写在文档里，或者停在 Demo。我实际完成了它的关键闭环。

1. 一个完整的 Streaming Runtime

  • OpenAI-compatible 的 SSE
  • Streaming 生命周期被明确拆分
  • 支持中途 quota enforcement
  • 能区分首 chunk 前失败、首 chunk 后中断等边界语义

2. 一个“事实优先”的 Usage 模型

  • 每个请求都会生成 UsageRecord
  • completed / partial / end_reason 都是明确事实
  • usage 不是统计，而是解释源

3. 最小但自洽的 Quota 治理

  • Admission 与 Streaming 共用一份预算
  • 接受“看起来不直觉”的中间状态
  • 明确这是阶段性治理语义，而不是最终计费模型

4. 一个真正“能讲清楚发生了什么”的 Admin

我甚至没有停在“接口完成”这一层，而是：

  • 写了 Admin 后端
  • 写了 Admin 前端
  • 把 Usage Impact、Estimated Cost（展示用）做出来
  • 做了 Governance Explanation（为什么是 active / limited）

当你打开页面时，能一眼看到：

  • 请求发生了
  • token 被消耗了
  • quota 改变了
  • 管理动作有了后果

从完成度来说，这已经超过很多内部平台的演示水平。

三、真正让我停下的，不是技术，而是“系统级现实”

让我停下的原因，不是“太难做”，而是太清楚继续做下去会发生什么。

1. 这是一个必须被“强制收口”的系统

AI Gateway 的前提其实非常苛刻：

所有模型调用，都必须经过你。

但现实是：

  • 团队可以随时直连第三方
  • 没有组织层面的强制力
  • 你无法真正阻止绕过

在这种情况下，治理系统很容易变成：

看起来很完整，但实际上只覆盖了一部分真实流量。

这不是技术能解决的问题。

2. 它的价值释放周期，与现实节奏严重不匹配

平台型系统的收益曲线，通常是：

  • 前期：几乎看不到收益
  • 中期：开始规范，但会被嫌麻烦
  • 长期：才真正体现价值

而现实环境更关心的是：

  • 能不能马上用？
  • 能不能马上省钱？
  • 能不能立刻对业务产生影响？

这并不是谁对谁错，而是节奏天然不一致。

3. 市场已经把“通用解”卷得足够成熟

当我把这个方向拿去和领导沟通时，有一句话让我彻底冷静下来：

“现在已经有很多成熟的 hub 可以直接接。”

这句话非常现实。

市面上已经存在不少平台，把：

  • 多模型接入
  • usage 观测
  • quota 管理
  • cost 统计

这些通用能力做得足够好。

如果你要自己做，只有两条路：

  • 深度绑定组织流程（这不是我能决定的）
  • 或者做一个“比所有人都更通用的通用平台”（几乎不可能）

四、这段经历并没有浪费，反而非常值钱

我并不觉得这是“白做了”。

因为我真正走完了很多人只在文章里读过的阶段。

1. 我第一次真正理解了“事实源”有多重要

  • Admin 看到的，不一定是真实发生的
  • In-memory 在多进程下会制造“观测幻觉”
  • 必须明确：谁是 Source of Truth

2. 我真正体会到“治理 ≠ 执行”

  • Gateway 负责执行和事实生产
  • Admin 只是观察、解释和展示
  • 治理不是多写几个 if，而是边界设计

3. 我第一次完整感受到“平台为什么难”

难的不在代码，而在：

  • 收口权
  • 推进成本
  • 组织协同
  • 价值滞后

这些东西，只有亲自做过一次，才会真正理解。

五、这次项目里，我也在尝试一种新的 AI 协作方式

这次项目里，我并不是“让 AI 帮我写代码”那么简单。

我刻意做了一件事：

让不同的 AI 对我的设计互相评价。

我会把同一个阶段性的设计，交给多个模型分析，让它们指出风险、盲点和潜在偏差。

这让我不断想到计算机科学里一个很经典的概念：停机问题（Halting Problem）。

你永远无法仅靠系统自身，判断它是否“已经完成”或“是否会跑偏”。

这在工程实践中非常真实。

AI 也是一样：

  • 一个模型很容易沿着某条路径无限优化
  • 看起来越来越复杂，但不一定越来越正确

而让 AI 互相评价，本质上是在引入外部约束，帮助我：

  • 校准方向
  • 防止沉没成本效应
  • 更早意识到“继续做下去是否值得”

这不是为了让 AI 做决策，而是为了让我自己更清醒地决策。

六、为什么我选择在这个节点停下

我停下，不是因为做不下去，而是因为我能清楚地判断：

接下来投入的时间，和可能产生的价值，已经不成正比。

继续做，大概率会变成：

  • 技术上更精致
  • 现实中更边缘
  • 最终被更成熟的平台替代

这是一个非常典型的应该止损的工程节点。

最后

现在回头看，我对这个项目的评价是：

它是一个技术上成立、工程上完整，但在当前环境下不值得继续推进的系统。

而能在这个节点上停下，本身就是一种能力。

  • 有些系统，值得做；
  • 有些系统，值得做到一半；
  • 而知道什么时候该停，本身也是工程师成长的一部分。