Files

Your Name 687c4535f8 fix: P0-1 RateLimiter并发写安全 + P0-2工单操作错误码区分 + P1 rows.Close修复

P0-1 (limits.go): Allow()方法改为全程使用写锁保护counters map读写，避免RLock写入时的data race
P0-2 (ticket_workflow.go+ticket_handler.go): Assign/Resolve/Close操作先查询ticket存在性和状态，返回明确的CS_TICKET_4001/CS_TKT_4002/CS_TICKET_4092/CS_TICKET_4093错误码，handler根据错误前缀路由HTTP状态码
P1-1 (ticket_store.go): 移除GetStats中3处手动rows.Close()，只保留defer Close()

2026-05-01 20:56:25 +08:00

7.1 KiB

Raw Blame History

立交桥 V1 产品重设计草案

日期：2026-04-24
状态：讨论中草案
当前范围：已固化产品定位、协议策略、MVP 兼容边界；核心对象模型与信息架构为待确认草案

1. 产品定位与第一性目标

新立交桥不再定义为“可自部署的兼容网关程序”，而是定义为一个面向中小企业终端客户的 AI 接入 SaaS。其核心竞争对象不是底层模型厂商，而是 newapi、sub2api 这一类“可以快速部署运营但产品完成度不足”的兼容网关产品。对比这些竞品，立交桥 v1 不追求“支持最多功能”，而是明确以三类差异化为主：

更强的协议兼容与模型接入覆盖。
更好的用户端体验，降低首次接入和日常使用摩擦。
更强的管理端运维能力，尤其是可观测、诊断、告警和智能运维能力。

v1 的首要价值不是控制台有多复杂，而是用户在5 分钟内把现有客户端的 Base URL 改掉后直接跑通。因此，产品增长路径明确选择“开发者主导的自助式增长”，而不是传统企业采购路径。用户先以个人身份注册、充值、创建 Key、完成首次调用成功，再邀请团队成员进入工作区。工作区仍然是计费与治理主体，但首单和首次激活由开发者完成。

商业模式选择为预充值余额 + 按调用量扣费。这是因为 v1 需要同时支持多上游、多模型、动态成本与按能力矩阵定价。如果一开始就做固定套餐，会把后续模型接入、成本透传和账单解释能力锁死。账户治理模型采用“工作区是一等主体，个人是登录身份”的结构：成员、API Key、余额、账单、模型权限、审计和策略都挂在工作区下。

2. 协议策略、兼容承诺与模型语义

立交桥 v1 明确采用双协议核心产品策略：OpenAI 与 Anthropic 都进入 v1 的核心承诺面，不再是“OpenAI 主轴 + Anthropic 辅助适配”。但它也不是简单并排放两套网关，而是“外部双协议，内部单核心”：对外保留两套原生协议体验，对内统一收口到一套 canonical 模型目录、能力矩阵、路由策略、额度计量、账务、审计和运维真相层。

在 OpenAI 面，v1 的强兼容主链路至少包括：

GET /v1/models
POST /v1/chat/completions

在 Anthropic 面，v1 的核心兼容主链路至少包括：

POST /v1/messages
与模型发现、模型映射、错误语义、SDK 行为相关的核心配套能力

这两个协议面都进入 v1 核心承诺，且都要覆盖高频高级能力，而不只是最低配文本调用。当前已经确认的能力范围包括：

非流式文本输出
流式输出
tool calling / tool use
多模态输入

但平台不对所有模型做一刀切承诺。能力承诺必须按模型能力矩阵显式声明，避免出现“平台说支持，但具体模型一调就报错”的竞品式体验。为此，模型不能再被设计成一个普通字符串，而必须是一个产品契约对象。模型命名采用双层命名：

对外保留兼容名和迁移别名，支持用户“改 Base URL 就能跑”。
对内维护 canonical model ID、上游映射、价格、能力矩阵、可用区间和路由策略。

model 字段采用双模式语义：

默认模式下，用户使用兼容名或稳定公共名，优先保证迁移友好。
高级模式下，用户可以显式指定上游模型、模型别名或受控路由策略。

3. 核心对象模型与信息架构（待确认）

为了同时支撑双协议、双层模型命名、工作区计费和后续智能运维，v1 的核心对象建议收敛为以下几类：

Identity 表示登录用户，只负责认证、登录会话和成员关系，不直接承载账务。
Workspace 是一等业务主体，承载余额、充值、账单、成员、API Key、默认路由策略、模型权限和审计边界。
Credential 包括工作区下的 API Key、可能的子 Key、用途标签、状态、权限范围和调用限制。
Model Catalog 平台维护的模型目录对象，不只是模型列表，而是“外部名 - canonical ID - 上游映射 - 能力矩阵 - 价格 - 可用状态”的统一真相层。
Provider / Upstream 表示 OpenAI、Azure OpenAI、Anthropic、DeepSeek、阿里百炼、火山方舟等接入源，以及它们的区域、凭据、速率限制和健康状态。
Route Policy 表示当用户请求某个模型名时，平台如何解析、选择上游、失败时如何回退、何时熔断，以及是否允许智能切换。
Usage Ledger 表示调用级计量事实，记录协议面、模型名、解析后的 canonical model、上游、token/图片/工具调用等费用相关事实。
Billing Record 表示对工作区可解释的账务结果，包括预扣、结算、退款、调整和对账状态。
Audit Event 记录认证、Key 变更、充值、模型策略调整、异常调用、运维处置和权限操作。
Ops Incident 面向管理端与智能运维，记录上游故障、模型异常、路由抖动、错误突增和自动化处置结果。

基于这些对象，v1 的控制台信息架构建议按“用户完成任务的顺序”组织，而不是按内部模块组织。控制台一级导航建议优先有：

概览
API Keys
模型目录
在线调试
用量与账单
路由与策略
运维与诊断
成员与工作区设置

这样设计的核心原因是：用户首先要完成首次接入成功，其次才是理解模型能力差异，再之后才是成本、策略和运维。控制台必须服务这一条真实路径，而不是暴露内部模块名。

4. 当前已确认结论

截至本草案版本，以下决定已经确认：

新立交桥是面向中小企业终端客户的 AI 接入 SaaS。
v1 采用开发者主导的自助式增长路径。
工作区是一等业务与计费主体。
商业模式是预充值余额 + 按调用量扣费。
v1 同时把 OpenAI 与 Anthropic 纳入核心承诺面。
OpenAI 面至少强兼容 GET /v1/models 与 POST /v1/chat/completions。
Anthropic 面提升到接近 OpenAI 同级优先级，纳入 v1 核心能力承诺。
高级能力范围包括流式、tool calling / tool use、多模态输入。
平台必须按模型能力矩阵显式承诺，而不是统一口号式承诺。
模型采用双层命名，对外兼容名，对内 canonical model ID。
model 字段采用默认兼容名 + 高级显式指定的双模式语义。

5. 下一步待确认主题

后续设计需要继续确认至少以下几个主题：

OpenAI 面与 Anthropic 面的能力对等边界，到底哪些算 v1 强承诺，哪些算 v1.1。
模型目录与能力矩阵如何对外展示，是否允许用户自定义别名。
路由策略是“默认稳态优先”还是“默认智能优选优先”。
用户端控制台首页与首次接入流的具体结构。
管理端智能运维的 MVP 边界，到底做告警与诊断，还是直接做自动修复。

7.1 KiB Raw Blame History Unescape Escape