Vibe Coding实战：用Codex与Claude Code从零构建AI模型聚合平台

1. 写在开工之前为什么是Vibe Coding OpenRouter这个组合2026年再聊Vibe Coding已经不是什么新奇概念了。过去一年里我用Codex和Claude Code这俩工具完成了好几个从零到一的项目其中一个最典型的、也最适合拿出来复盘的就是OpenRouter AI模型聚合平台。简单说它就是一个“模型中转站”用户在平台上充值拿到一个统一的API Key然后用OpenAI兼容的接口格式调用GPT、Claude、Gemini等各种模型平台负责转发、计费、配额管理。这个项目特别适合作为Vibe Coding实战范本因为它同时踩中了三件事一个是多Agent协作开发模式Codex Claude Code各管一摊一个是典型的SaaS付费系统用户、订单、用量、对账还有一个是模型网关这类对稳定性要求极高的基础设施组件。想做AI工具集成、想跑通API聚合商业模式、或者只是想看看2026年双AI结对编程到底效率多高的朋友这篇内容都能给你一个完成的参考。先说结论纯靠自然语言把整个平台“聊”出来完全可行但没有章法地聊会让你在后面维护时痛不欲生。我中间重写了两次数据模型经历过转发层并发问题、余额校验漏掉临界态、还有各种鉴权报错这些坑后面会逐一拆开讲。1.1 Vibe Coding在2026年的真实定位很多教程把Vibe Coding形容成“你只要会说话就能写程序”这个说法害人不浅。真实定位应该是AI从“帮你补全几行代码的助手”升级成了“能独立承接功能模块的初级工程师”但这个人需要你给需求、给边界、给验收标准还需要你在关键时刻拍板架构方向。我用下来的体会是Codex和Claude Code都具备读取代码库、主动修改文件、执行命令、跑测试的能力。你把它们当成两个远程协作者一个是全栈手速极快的“铺量型”选手一个是逻辑细腻的“打磨型”选手搭配得当的话整个开发节奏可以做到“上午定方案、下午出能跑的Demo、晚上补测试和文档”这种离谱速度。但这不等于没有门槛。至少你得懂项目大概的目录结构、知道哪些配置容易踩坑、看得懂报错、能判断AI改错了哪个文件。换句话说Vibe Coding把“编码能力”的权重降低了把“拆解需求、审查代码、拍板方案”的能力提到了最前面。你要是完全不懂编程就会翻车——AI的幻觉会一本正经地给你错误代码你没有基本判断力就全盘接受那项目就废了。1.2 OpenRouter聚合模式在项目里的真实价值OpenRouter本身是一个AI模型统一接入服务它对外提供OpenAI格式兼容的接口你只要接一次背后就能调几百个模型。它真正的价值不是“接口格式统一”——这个各家都做——而是它把定价、限流、模型白名单这些运营层面的逻辑也一起聚合了。做一个类似OpenRouter的聚合平台核心要搞清楚的是三笔账成本账你从上游拿模型API的成本是多少决定你给用户的定价下限。配额账用户充值后能调用多少token按什么倍率折算到不同模型。结算账每次请求实际用了多少token怎么扣费怎么防止并发场景下把余额扣成负数。我做的这个平台用户侧是一个简洁的控制台能创建API Key、看用量、充值、开订阅管理侧能配模型列表、调倍率、看全站流水。整个项目下来代码量大概两三万行按照以前的开发方式怎么也得一个团队忙两三个月用双AI辅助我一个人在正常上班之外花了大概三周就到了上线标准。文章后面我会把命令行工具、环境变量、数据库表结构这些具体配置全部摊开写方便你照着搭。2. 环境搭建绕坑实录Codex与Claude Code的安装、登录与联动开工第一步永远是搭环境。别小看这一步我在这一步上消耗的时间几乎占了整个项目里的1/4。原因很简单这两个工具更新太快网上的教程版本经常对不上报错信息五花八门你按照A教程装完B工具又连不上C服务特别消磨耐心。2.1 两种工具的定位差异与互补场景先说角色分配。我的用法是Codex负责“从0到1”的骨架搭建和大面积代码铺量Claude Code负责“从1到N”的逻辑打磨和细节修复。Codex的优势在于当你给它一个清晰的功能需求时它能一次性生成一大片结构完整的代码尤其适合搭项目脚手架、建数据库表结构、写CRUD接口这种重复性高的活。你给它一个“用户系统包括注册登录、JWT鉴权、个人资料修改”的需求它能直接吐出全套代码文件目录合理、命名规范、连注释都给你写到位。Claude Code的强项则是面对已有代码的上下文理解它更擅长“只改某个文件里某段逻辑”这类精细操作。比如你告诉它“用户余额扣减方法里有并发问题改成事务加行锁”它能读懂现有的代码结构把改动控制在一个很小的范围内。而且它在解释报错信息时更细致经常能给出根因分析遇到难缠的bug我都丢给它。另外我强烈建议在VS Code里同时装好Claude Code插件和Codex插件。插件版和终端版的区别在于插件版可以直接框选代码片段丢给AI省去反复描述上下文的时间。用起来你会发现这个交互模式在改bug时效率极高——选中报错代码右键让AI解释再右键让AI修复全程不用切窗口。2.2 安装与鉴权配置中的高频报错修复下面列几个我实际遇到、并且搜索量很高的报错都是2026年安装配置阶段最容易卡住的点。报错一codex auth token is unavailable这个报错基本就是登录态丢了。Codex的登录凭证有有效期过期之后你在终端里跑任何命令都会提示token不可用。解决办法是重新登录命令一般就是codex login但这里有个坑如果你在代码里手动设置了OPENAI_API_KEY之类的环境变量它会优先于Codex自带的登录态而且一旦文件里写了环境变量、之后又删掉了Codex可能还是会去找旧的登录凭证导致“登录已经成功但依然报错”。我的建议是unset OPENAI_API_KEY codex logout codex login一套下来基本能解决。如果是在公司电脑上可能还要看一下代理设置是否影响了登录请求。报错二cc switch local proxy failed while handling codex endpoint /responses这个报错看起来像Codex起的服务连不上但其实问题出在一个很隐蔽的地方Codex在2026年的版本里支持通过一个本地代理来转发AI请求这个本地代理的地址和Claude Code或系统全局代理冲突了。我当时反复排查了很久最后发现是系统里装了另一个代理工具占用了Codex配置的本地端口。如果你也遇到类似报错先检查Codex的配置文件里proxy相关的设置确认端口没有冲突然后重启下Codex的本地服务就行。还有一个常见原因是当前代码目录没有初始化Codex根本不知道要在哪个项目上下文里工作也会报类似的连接类错误。报错三gpt-5.6-sol model is not supported when using codex with a provider这个报错的意思是你通过某个API转发服务调用Codex时对方不支持当前指定的模型。很多人用的是配置了第三方模型的Codex——比如接DeepSeek、接OpenRouter或者其他网关——但模型名写成了OpenAI官方模型名而第三方服务并不提供这个模型于是Codex在启动时就报错。解决方法分两步第一步去你用的API服务商页面确认它支持的模型名列表比如DeepSeek要用deepseek-chatOpenRouter要用openrouter/auto这类路径第二步修改Codex配置文件里的model_provider和model字段。这方面接DeepSeek的人特别多报错也最多核心思路就是别想当然一切以服务商文档为准。这三个报错正好代表了Vibe Coding环境配置里最典型的三个坑凭证问题、端口冲突问题、模型不匹配问题。你只要把这三类问题都消化了其他配置基本就是顺水推舟的事。3. 电商版AI网关的架构拆解我都让AI干了哪些活环境跑通之后正式进入开发。这里先交代一下整体架构因为我自己第一次做的时候是边做边想结果后期返工不少。你如果也想做一个类似的模型聚合平台建议动手前先把模块划分和表结构设计清楚这会省掉后面80%的修改成本。3.1 平台核心模块清单与数据模型设计一个完整的聚合平台至少要包含下面六个模块。用户与认证模块注册、登录、JWT刷新、个人信息。这个模块不要自己造轮子直接用现成的用户系统框架AI写起来也快不易出错。API Key管理模块用户创建Key、删除Key、查看Key的使用统计。这里有一个容易被忽略的点API Key需要支持“部分掩码展示”比如只显示前四位和后四位。AI生成代码的时候经常默认把完整Key回显这在安全审计里是大忌。模型路由模块平台要对上游模型做聚合和映射。用户传来的模型名和上游实际模型名往往不是一一对应需要做一层翻译。比如用户请求claude-sonnet-4平台翻译成上游的anthropic/claude-sonnet-4再进行转发。转发代理模块核心中的核心。接收用户请求补全认证信息转发到OpenRouter或直接到各模型厂商再把响应流式返回给用户。这里要处理流式SSE和非流式两种模式超时、重试、错误映射也都在这一层。计费与用量模块每次请求完成后根据用量记录扣除用户余额、更新平台成本统计。要支持按倍率定价、赠送额度、包月订阅等多种计费模式。管理后台模块平台运营人员用的能看用户列表、模型列表、价格配置、充值订单、异常请求。数据模型这部分我贴一下我最终定稿的核心表给个直接能参考的版本按PostgreSQL方言写的改改也能用在MySQL上-- 用户表 CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, email VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, balance_cents INTEGER NOT NULL DEFAULT 0, subscription_tier VARCHAR(50) NOT NULL DEFAULT free, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); -- API Key表 CREATE TABLE api_keys ( id BIGSERIAL PRIMARY KEY, user_id BIGINT REFERENCES users(id) NOT NULL, key_prefix VARCHAR(16) NOT NULL, key_hash VARCHAR(255) UNIQUE NOT NULL, is_active BOOLEAN NOT NULL DEFAULT TRUE, last_used_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); -- 模型定价表 CREATE TABLE model_pricing ( id BIGSERIAL PRIMARY KEY, model_key VARCHAR(255) UNIQUE NOT NULL, display_name VARCHAR(255) NOT NULL, input_price_per_million INTEGER NOT NULL, output_price_per_million INTEGER NOT NULL, is_active BOOLEAN NOT NULL DEFAULT TRUE ); -- 用量记录表 CREATE TABLE usage_logs ( id BIGSERIAL PRIMARY KEY, user_id BIGINT REFERENCES users(id) NOT NULL, api_key_id BIGINT REFERENCES api_keys(id) NOT NULL, model_key VARCHAR(255) NOT NULL, input_tokens INTEGER NOT NULL DEFAULT 0, output_tokens INTEGER NOT NULL DEFAULT 0, cost_cents INTEGER NOT NULL DEFAULT 0, prompt_log JSONB, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); -- 充值订单表 CREATE TABLE orders ( id BIGSERIAL PRIMARY KEY, user_id BIGINT REFERENCES users(id) NOT NULL, amount_cents INTEGER NOT NULL, status VARCHAR(20) NOT NULL DEFAULT pending, provider VARCHAR(50), created_at TIMESTAMPTZ NOT NULL DEFAULT now(), paid_at TIMESTAMPTZ );这里说一个关键设计思路用户的balance字段故意用整数存储的“分”而不是浮点数“元”。因为金额计算最忌讳浮点误差哪怕是Python的Decimal也在数据库层面不如整数稳妥。所有涉及钱的计算全用整数、全用分。3.2 接口转发层、计费系统与用户中心的实现思路接口转发层是整个平台的技术核心。我把它设计成了一个独立的服务输入是用户请求输出是上游响应流。大致流程是用户请求到达网关先校验API Key是否有效取到user_id。根据请求里的模型名查model_pricing表或内存缓存拿到定价倍率预估本次最高消耗检查余额是否充足。把请求转发到上游OpenRouter或其他模型厂商用平台的统一账号请求同时标记该请求归属的用户。拿到上游响应后解析用量数据计算实际扣费金额在事务里更新用户余额、写入用量记录。这里“先冻结再结算”的模式值得强调。如果不做额度冻结高并发场景下容易出现“余额只有5块但用户同时发起了10个请求每个4块”的情况等结算时余额直接变负数。正确做法是请求开始时先预冻结一个最大值请求结束再按实际用量解冻或扣减。这个逻辑AI第一次写的时候大概率会漏掉我是在压测阶段发现余额出现负数才补上的务必提前盯好。用户中心部分相对简单主要就是控制台页面。用户登录后能看到可用余额、API Key列表含创建/删除、调用历史、模型价格表。这些页面用React或Vue写都行重点是让AI按照你给的组件结构批量生成别一页一页零散地写那样上下文会乱AI经常会重复造轮子。4. 双AI结对编程的实战节奏如何让Codex和Claude Code各司其职这部分是全文最实战的内容。工具都装好了架构也定了接下来就是整个开发过程里怎么把两个AI的产能发挥到最大同时避免两边的活儿互相打架。4.1 任务分工方法论什么样的活交给谁先说结论再解释原因Codex适合“批量铺量”Claude Code适合“单点攻坚”。具体分工可以这样参考Codex负责从空目录初始化项目骨架、装依赖、建目录结构。按模块批量生成CRUD接口用户表、Key表、订单表的增删改查。生成控制台页面的基础版表单、列表、弹窗等重复性组件。Claude Code负责修复Codex生成的代码里的bug和运行报错。实现转发层、计费事务、并发扣减这类需要精细逻辑的地方。优化代码结构、处理边界情况、补充安全校验。为什么这样分因为Codex生成代码的特点是“量”优先让它一口气处理七八个相关的CRUD接口它能把文件都建好、函数都写全虽然偶尔细节会出错但整体框架是对的。而Claude Code的优势在于“质”它对已有代码的理解能力更强让它在那个框架上精修比让它从零铺量更合适。一个很重要的原则同一时间段内只让一个AI负责同一个文件集。如果Codex刚生成了用户接口的文件Claude Code同时也在改用户接口两边同时写后写的一方会把先写的一方改动冲掉。这个坑我踩了不止一次。你可以在项目根目录加一个AGENTS.md文件里面写清楚职责和文件边界# Project Map - backend/src/routes/ 由 Codex 维护生成CRUD接口 - backend/src/services/ 由 Claude Code 维护负责业务逻辑 - frontend/src/pages/ 由 Codex 维护生成基础页面 - frontend/src/components/ 由 Claude Code 维护负责交互细节AI工具现在都能自动读取这个文件作为项目级指令。相当于给两个“临时工”各分工牌避免他们抢同一块领地。4.2 上下文管理与提示词工程的关键细节Vibe Coding最容易犯的错误是把一个会话拖太长聊着聊着AI就忘了前面的需求。我的做法是按功能拆会话。每次打开新会话前明确这次要干的活是什么比如“本次目标实现API Key创建接口要求校验用户登录态、生成sk-开头的随机Key、存哈希不存明文”。每次给足当前数据模型。别指望AI自动记住之前的表结构每次都把相关的表定义贴给它它生成的代码才贴得上现有的数据库。遇到跨模块改动先把目标文件的核心代码贴给AI看。有时候AI改了A文件没同步改B文件的调用方式你就把B文件里相关的函数贴给它让它全盘考虑再动手。提示词也有一套规范。与其说“写一个用户列表页”不如说“写一个用户列表页展示id、email、注册时间、余额支持按email模糊搜索前端使用React Antd参考已有orders页面的风格”。需求里包含三个要素功能是什么、数据源在哪、风格参照谁。这里推荐一个高效的工作流在项目根目录维护一个TODO.md文件把任务拆成一条条可勾选的小项。每次跟AI开新会话先让它读这个文件然后把当前要做的一条单独提出来讨论。这样即便中间断了好几天重新打开也能快速续上状态。5. 踩坑全记录那些“没有报错却悄悄出错”的时刻前面说了不少配置和开发中的坑这一节集中说说我上线前后遇到的最揪心的几个问题。这些问题不是立刻报错的那种而是会让数据出错、用户体验变差、或者让你在半夜收到告警的隐性坑排查起来费时费力。5.1 模型路由与余额校验的边界问题模型路由的第一个坑是别名映射不完整。OpenRouter上同一个模型可能有多个版本标识比如Claude 3.5 Sonnet在OpenRouter里的标识是anthropic/claude-3.5-sonnet但对用户展示时你可能想用简称claude-3.5-sonnet。如果映射表漏配了某个别名用户请求就会走到默认的分支往往直接报“model not found”。这里要加一个严格的校验逻辑收到请求后先查模型映射表查不到的模型名直接返回400错误码和明确提示而不是放行。放行会有更大的隐患——让用户猜你的上游配置等于是把内部结构暴露出来了。余额校验也有边界问题。前面提到“先冻结再结算”的方案能避免并发下余额变成负数但还有一个细节冻结额度该怎么算如果你按“输入token上限100k 输出token上限100k”去冻结那一个5块钱余额的用户可能同时被冻结好几笔大额预估费用导致他实际还能用的额度被过度锁定体验很不好。我的解法是给平台设置一个“预估最大消耗上限”比如单次请求最多冻结2美元超出部分直接拒绝并提示用户分段请求。同时在结算阶段把“冻结”转化为“扣费”并在事务边界做余额的最终校验双保险。这里插入一段伪代码方便你理解整个流程def handle_chat_request(user, api_key, model_key, payload): # 1. 校验API Key # 2. 检查模型是否在白名单中 # 3. 计算预估费用并冻结 estimated_cost estimate_max_cost(model_key, payload) with db.transaction(): user lock_user_row(user.id) if user.balance_cents estimated_cost: raise InsufficientBalance() user.balance_cents - estimated_cost user.save() # 4. 转发到上游 response forward_to_upstream(model_key, payload) # 5. 按实际用量结算 actual_cost calculate_cost(model_key, response.usage) with db.transaction(): user.balance_cents estimated_cost user.balance_cents - actual_cost user.save() update_usage_log(user.id, actual_cost)这段代码虽然简短但保证了整个计费过程里余额绝不会为负也不会因为并发而重复扣费。5.2 部署环境中的限流、并发与数据一致性部署到生产环境后的第一个教训是上游API的限流策略跟本地完全不是一回事。本地测试时你并发很低上游不会限流一旦上线几十个用户同时请求上游每天都会定期给你429限流报错。解决思路是多层限流用户维度限流 全站维度限流。用户维度限制每个Key的QPS和每分钟token数全站维度限制整个平台在上游的并发请求数。这个用来保护你的上游账号不被封禁也保护你的下游用户不会因为别人的流量太大而集体超时。数据一致性方面最大的问题出在回调对账。有些上游接口支持异步回调用量统计不是在HTTP返回体里而是通过回调通知过来。如果你只处理了同步返回的用量、忽略了异步回调的用量就会导致一个用户的实际消耗远大于账单记录平台一直在亏钱。我的建议是把用量记录设计成“多态”结构每条用量都记录usage_source字段来标记它是同步返回还是异步回调定期有个对账任务去汇总两边的数据发现异常差额时发告警。这样即便回调偶尔延迟也不至于完全漏掉。还有一个小坑是幂等性。用户客户端如果网络抖动同一条请求可能会重发好几遍。如果平台没有幂等机制用户会被扣好几次费用引来大量投诉。解决方案是支持可选request_id字段同一个request_id在固定时间窗口内的重复请求直接返回第一次的结果或去重错误提示。这个逻辑要在转发之前就拦下来否则你无法判断是“用户手动重试”还是“客户端自动重试”。6. 从能用到好用上线后的性能优化与运营细节项目跑起来只是第一步真正拉开差距的是上线后的性能表现和运营细节。这一部分我讲讲自己是怎么让平台从“能跑”变成“好用”的。6.1 流式响应SSE与缓存策略用户调用大模型最在乎的是首字延迟。如果等大模型完整生成再一次性返回用户盯着空白加载看着十几秒体验会很差。所以平台必须支持流式响应SSE。转发层的流式实现并不复杂当你调用上游API时带上stream: true上游就会把token逐块返回你作为一个中转站把每个块原样转发给用户。但难点在于中间要记录token用量。SSE模式下最后一个块往往包含完整的usage统计你要把这个块解析出来再结算费用才算闭环。很多初学者一启用流式就忘了计费结果用户疯狂调用平台却不扣费这种亏我吃够了。缓存策略方面不是所有请求都适合缓存。对于Chat Completions这种带随机性的生成任务不建议做全量缓存。但可以对“模型列表”“价格表”这类静态配置做内存缓存或Redis缓存避免每次用户刷新控制台都打数据库查询能显著降低数据库压力。6.2 告警监控与异常费用巡检上了生产之后一定要有监控否则你都不知道平台在某个深夜悄悄损失了多少钱。我从第一天起就接了一套最简单的告警规则给你参考告警规则触发条件处理方式上游API错误率突增上游返回5xx比例超过5%切换备用上游单用户单日消费突增超过该用户历史日均消费10倍冻结Key并人工审核全站余额入账与Usage对不上订单金额之和 - 消耗金额之和 阈值跑对账任务检查回调遗漏请求耗时P95过高超过10秒检查上游路由是否失效这套规则不仅能防止技术故障还能防薅羊毛。比如有用户注册后恶意刷模型生成大量内容卖给第三方单日消费量会异常高告警就能在金额变大之前把账户冻结。6.3 给运营留的灵活口子最后说一个产品层面的细节。聚合平台本质上是做“模型转售”所以定价策略要灵活否则上游一调价你就得改代码。我的做法是把“模型定价”全部挪进数据库并且支持两种计价单位一种是按token计费一种是按次计费——像图像识别这种无法简单按token记账的场景就按每次固定价格。让AI在管理后台做一套价格配置界面运营人员自己就能调倍率、上下架模型不需要每次找开发改版本发布。这个“灵活性”直接决定了平台能不能长久经营下去。我在实际运营中还发现一个规律用户翻车的高峰期往往在“充值后第一次调用”和“余额快用完的时候”。前者是用户不知道选哪个模型建议做一个按用途推荐模型的引导页后者是用户感觉突然不能用建议做余额不足时的友好提示并引导小额充值。这些小细节AI不一定会主动帮你想到你得自己提需求这恰恰是2026年做Vibe Coding最核心的能力——你不是代码的书写者但你是产品体验的最终负责人。