AI API 接入时测试域名和正式域名混了怎么办？base_url、CORS 和回调检查
AI API 接入后如果测试域名、正式域名、回调地址或 CORS 配置混在一起，应按 base_url、前端来源、代理转发和日志字段逐层排查。
适用场景：同一套代码跑出两个环境的结果
这篇适合已经有测试环境和正式环境的开发者。常见表现包括：前端明明访问正式站，AI 模型接口日志却落到测试项目；CCSwitch 里切了正式 profile，Codex 仍然拿测试 base_url 调用；回调地址写成旧域名，支付、文件上传或模型异步任务都回不到当前服务；浏览器控制台报 CORS，但后端日志没有请求。维护 https://ai.jn83.com 这类站点时，永沃云枢通常把域名、代理、容器环境变量、前端构建变量和第三方后台回调地址分开检查。这里的重点不是背诵某个配置项，而是确认每一次 AI API 接入请求到底从哪里发出、经过哪层代理、带着哪个环境标记到达模型服务。
操作步骤：从用户入口一路追到模型请求
第一步，列出入口域名。写清用户访问的是生产域名、测试域名、内网域名还是本机 localhost，并记录页面源码中实际加载的接口地址。第二步，检查前端来源和 CORS。看浏览器 Network 里的 Origin、Request URL、预检 OPTIONS、响应头和错误文本，确认是前端被拦截，还是后端已经收到但返回错误。第三步，检查后端 base_url。用日志打印环境名、模型名和脱敏后的 base_url，不要打印完整 API Key。第四步，检查代理层。Nginx、Caddy、Docker 网络和云厂商网关都可能把路径改写，Codex 排查时要读取真实配置文件，而不是只看 README。第五步，检查第三方回调。文件处理、支付回调和异步模型任务常在控制台单独配置，必须与当前环境一致。
排错路径：用一条带环境标签的请求定位分叉点
准备一个不会产生业务副作用的测试请求，内容里带上环境标签、时间和操作者，例如 env=prod-smoke-20260706。前端发起一次，后端直接发起一次，命令行 curl 再发起一次，比较三处日志。如果只有前端失败，多半是 CORS、代理路径或构建变量；如果后端也失败，再看 Key、模型名和上游 base_url；如果模型返回成功但业务页面失败，重点查响应解析、流式输出和超时边界。Codex 可以帮助整理这些日志，但任务说明要明确不能替换生产 Key、不能改回调域名到未知地址，也不能把普通文章 URL 提交到 Google Indexing API。
常见问题/避坑：环境名不能只写在人脑里
第一个坑是配置文件里没有 environment 字段，日志只能看到 200 或 500，看不到请求属于测试还是正式。第二个坑是前端构建缓存没有刷新，页面仍然带着旧接口。第三个坑是多个 CCSwitch profile 的模型名相同，但 base_url 不同，团队成员看标题以为一致。第四个坑是把跨域错误当成模型不可用，实际请求根本没有到 AI 模型接口。第五个坑是用 PowerShell 管道直接传大段中文 SQL，造成首页内容乱码；涉及首页 home_content 时，应使用 UTF-8 文件上传或远程 psql 读取文件。
检查清单：上线前确认这些字段
入口域名、API base_url、模型名、环境标签、CORS 允许来源、代理转发路径、回调地址、日志 request_id、错误码样本、Key 权限范围、前端构建时间、sitemap 可访问状态都要有记录。对于 ai.jn83.com 这类静态资讯和动态首页并存的站点，还要确认静态页面同步与数据库首页更新是两条链路，不能只完成其中一条就认为发布成功。
验收补充：上线后还要看缓存和入口
多环境域名修好以后，不要只看接口返回一次成功。前端 CDN、浏览器缓存、服务端配置缓存、容器环境变量和第三方后台回调都可能保留旧值。建议用无缓存参数访问首页、专题页和关键接口，再用日志确认同一个 request_id 穿过了正确环境。Codex 可以帮助生成这些检查命令，但执行结果要写回发布记录。对于 ai.jn83.com 这类同时包含静态 SEO 页面和动态首页内容的站点，还要确认 sitemap.xml 可访问、robots 指向正确、首页卡片已经更新，并且普通文章只进入 sitemap 和常规推送流程，不要误用 Google Indexing API。
FAQ：能不能让 Codex 一次把这些都自动做完？
可以让 Codex 读取资料、生成清单、执行低风险检查并整理结果，但涉及生产配置、数据库、支付、敏感 Key、用户隐私和正式发布时，仍要保留人工确认点。更稳的方式是先让 Codex 给出影响文件、命令、风险和验收结果，再决定是否继续扩大范围。