使架构图 Skill 在 Codex 里出图，API 地址填 TaoToken

1. 先看现象Codex 调架构图 Skill 出图为什么会满屏圆角框在 Codex 里让架构图 Skill 生成或修复架构图时最常见的翻车现场不是“画不出来”而是画出来一堆一模一样的圆角框网关、服务、数据库、消息队列、外部依赖全被塞进同一种形状里颜色接近、层级不清、连线交叉最后看起来像一张没有信息密度的流程图。作为架构图 Skill 的维护者我遇到这类反馈时通常不会先改提示词而是先检查模型出口Codex 到底把请求发到了哪里Skill 拿到的模型输出有没有结构化约束渲染层是不是用了同一个默认节点模板。接入前先到 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_intro 获取 KeyBase URL 用https://taotoken.net/api后面所有配置都围绕这个地址展开。整条链路大致是你在 Codex 里输入“根据当前仓库生成架构图”Codex 调用架构图 SkillSkill 组织上下文并请求模型模型返回节点、边、分组等图描述Skill 再交给本地渲染器输出 SVG、PNG 或其它格式。只要中间任意一段失配最终图就会退化成“满屏圆角框”。常见原因有四类第一Codex 的config.toml没有切换到目标模型出口Skill 实际调用的还是默认供应商模型对架构图 DSL 的遵循程度不稳定第二Skill 的提示词只说了“画一张架构图”没有要求节点类型、边方向、分组边界和输出格式第三模型没有读取仓库里的README、docker-compose.yml、package.json、pyproject.toml、src/等真实材料只凭一句话脑补第四渲染模板把 service、database、queue、external 全部映射成同一种圆角矩形。前两类属于接入与提示词工程后两类属于 Skill 作者要修的内部逻辑。所以正确顺序不是先吐槽模型而是先把 Codex 的模型出口固定到 TaoToken再给架构图 Skill 一套可验证的结构化输出协议。下面从拿 Key、写config.toml、改 Skill 提示词、本地渲染、排障、多工具边界几个部分拆开讲。所有命令都在本地终端执行不要连生产库也不要让 Agent 直接操作线上环境。2. 准备 TaoToken Key从官网控制台到环境变量只做最小改动在 Codex 里使用架构图 Skill 之前先准备一个可用的 API Key。打开 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_key完成登录后进入控制台在 API Keys 相关页面创建一个新 Key。复制出来的值不要写进 Git 仓库也不要提交到.env.example之外的地方。本文所有示例统一用YOUR_API_KEY占位实际执行时替换成你自己的 Key。Linux 或 macOS 终端可以这样设置环境变量export TAOTOKEN_API_KEYYOUR_API_KEYWindows PowerShell 用$env:TAOTOKEN_API_KEYYOUR_API_KEY如果你希望每次打开终端都生效可以把环境变量写进 shell 配置例如~/.zshrc或~/.bashrc。但更推荐只在当前项目会话里临时导出避免多个项目互相污染。Codex 读取的是TAOTOKEN_API_KEY不是OPENAI_API_KEY也不是ANTHROPIC_API_KEY。这三个 Key 不要混用后面第 5 节会专门讲 Claude Code、CC Switch 和 Codex 的配置边界。这里再强调一次地址工具配置里的 Base URL 使用https://taotoken.net/api不要加 UTM 参数。UTM 链接只用于官网访问和 CTA 跳转不用于config.toml、settings.json或环境变量。Key 只放在环境变量或本地私密配置中Skill 文件、SKILL.md、项目 README 都不要出现真实 Key。3. Codex 可复现配置config.toml 接入 TaoToken 后架构图 Skill 才拿到稳定模型出口Codex 的模型供应商配置在~/.codex/config.toml。如果你在项目里使用 profile也可以放到项目级配置或通过 profile 切换。核心思路是定义一个名为taotoken的 model provider把base_url指向https://taotoken.net/api让 Codex 从TAOTOKEN_API_KEY读取密钥。下面是一份最小可复现配置# ~/.codex/config.toml model YOUR_CODEX_MODEL_ID model_provider taotoken approval_policy on-request sandbox_mode workspace-write [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat其中model填你在 TaoToken 控制台模型列表里选定的代码模型 ID。不要凭记忆写一个不存在的模型名先在控制台确认可用模型再填进来。model_provider taotoken表示默认走下面定义的 provider。[model_providers.taotoken]里的base_url必须是https://taotoken.net/apienv_key写TAOTOKEN_API_KEY这样 Codex 启动时会从环境变量读取不会把 Key 写进配置文件。wire_api按你使用的 Codex 版本和 TaoToken 兼容说明选择示例用chat如果你的环境要求其它值以实际文档为准。配置完成后在终端里确认环境变量已生效echo $TAOTOKEN_API_KEYWindows PowerShellecho $env:TAOTOKEN_API_KEY然后启动 Codexcodex进入交互后先让它做一个最小验证不要一上来就生成整张架构图。可以让 Codex 执行请读取当前仓库的 README.md 和 docker-compose.yml用一句话说明系统入口、主要服务、数据库和消息队列分别是什么。不要画图只做事实提取。如果这一步能正常返回说明 Codex 已经通过 TaoToken 调到了模型架构图 Skill 的模型出口基本可用。如果返回 401优先检查 Key 是否正确、环境变量是否在当前终端生效如果返回 404检查base_url是否写成了https://taotoken.net/api以及model是否是 TaoToken 控制台里真实存在的模型 ID如果一直走默认供应商检查config.toml是否被其它 profile 覆盖。这里要特别说明Codex 使用config.toml不要在里面写ANTHROPIC_*。ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_MODEL属于 Claude Code 或 CC Switch 体系混进 Codex 配置不会生效还可能让排障方向完全跑偏。4. 架构图 Skill 出图链路让 Codex 输出结构化图描述而不是泛泛的“画一张架构图”模型出口打通后接下来要修的是架构图 Skill 的输出质量。满屏圆角框的根源通常是 Skill 只要求“生成架构图”但没有规定节点类型、分组方式、连线标签和渲染格式。作为 Skill 作者我建议把任务拆成两段第一段让 Codex 读仓库并抽取事实第二段让 Codex 输出 Graphviz DOT 或 PlantUML 这类可本地渲染的图描述。不要只输出一段自然语言描述否则渲染层只能套默认模板。下面是一段可以直接放进架构图 Skill 的提示词模板Codex 执行时会按这个结构约束模型你现在在 Codex 中执行架构图 Skill。请先读取当前仓库中的 README.md、docker-compose.yml、package.json、pyproject.toml、requirements.txt、src/、app/、services/ 等与架构相关的文件。不要猜测不存在的服务。 输出要求 1. 先用表格列出组件名、类型、职责、依赖、对外协议。 2. 再输出完整 Graphviz DOT 代码放在 dot 代码块中。 3. 节点类型必须区分 - serviceshapeboxstylefilled - databaseshapecylinderstylefilled - queueshapeparallelogramstylefilled - externalshapebox3dstylefilled - gatewayshapecomponentstylefilled 4. 分组使用 subgraph cluster_*至少区分接入层、业务服务层、数据层、外部依赖。 5. 边必须有 label必要时标注 protocol例如 HTTP、gRPC、SQL、AMQP。 6. 避免所有节点使用同一种圆角矩形模板颜色按层或按类型区分。 7. 如果仓库信息不足列出缺失文件不要编造组件。这份提示词的关键不是“画得好看”而是把图的结构先固定下来。模型一旦按service、database、queue、external分类输出 DOT渲染层就不会把数据库画成普通服务框也不会把消息队列画成圆角卡片。以下是 Skill 可能输出的 DOT 示例你可以保存为architecture.dot后本地渲染digraph architecture { rankdirLR; graph [fontnameInter, bgcolorwhite, splinesortho, nodesep0.6, ranksep0.8]; node [fontnameInter, fontsize11, stylefilled, color#CBD5E1, fillcolor#F8FAFC]; edge [fontnameInter, fontsize9, color#64748B, arrowsize0.7]; subgraph cluster_access { label接入层; color#E2E8F0; stylerounded; gateway [labelAPI Gateway, shapecomponent, fillcolor#DBEAFE]; web [labelWeb Client, shapebox, fillcolor#EFF6FF]; } subgraph cluster_service { label业务服务层; color#E2E8F0; stylerounded; user_svc [labelUser Service, shapebox, fillcolor#DCFCE7]; order_svc [labelOrder Service, shapebox, fillcolor#DCFCE7]; payment_svc [labelPayment Service, shapebox, fillcolor#DCFCE7]; } subgraph cluster_data { label数据层; color#E2E8F0; stylerounded; user_db [labelUser DB, shapecylinder, fillcolor#FEF3C7]; order_db [labelOrder DB, shapecylinder, fillcolor#FEF3C7]; mq [labelEvent Queue, shapeparallelogram, fillcolor#FCE7F3]; } subgraph cluster_external { label外部依赖; color#E2E8F0; stylerounded; pay_ext [labelPayment Provider, shapebox3d, fillcolor#F3E8FF]; } web - gateway [labelHTTPS]; gateway - user_svc [labelHTTP]; gateway - order_svc [labelHTTP]; order_svc - payment_svc [labelgRPC]; user_svc - user_db [labelSQL]; order_svc - order_db [labelSQL]; order_svc - mq [labelAMQP]; payment_svc - pay_ext [labelHTTPS]; }保存后在本地终端执行dot -Tsvg architecture.dot -o architecture.svg如果你更习惯 PlantUML也可以把提示词里的 Graphviz DOT 换成 PlantUML并让 Codex 按组件、数据库、队列、外部系统分别使用不同 stereotype。核心原则不变先结构化再渲染。只要 Skill 输出的是带类型、带分组、带边标签的图描述最终出图就不会只剩满屏圆角框。另外Codex 在生成图之前最好先做一次“仓库事实抽取”。很多架构图错误不是渲染问题而是模型根本没有读代码。可以在 Skill 里加一步请先列出你实际读取过的文件路径。如果 README 和 docker-compose.yml 都不存在请停止画图并说明原因。这一步能明显减少模型凭空编造服务名、数据库名和中间件的情况。5. Claude Code、CC Switch 与 Codex 的配置边界ANTHROPIC_* 不要写进 config.toml同一台机器上经常同时装 Codex 和 Claude Code两者都通过 TaoToken 走模型出口时配置必须分开。Codex 只认~/.codex/config.toml里的model_provider和[model_providers.*]Claude Code 使用settings.json和ANTHROPIC_*环境变量CC Switch 则通常围绕三件套做供应商切换。把ANTHROPIC_BASE_URL写进 Codex 的config.toml是无效的把 Codex 的model_provider写进 Claude Code 的settings.json也不会被识别。Claude Code 的settings.json可以这样配置{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_CLAUDE_MODEL_ID } }这里的ANTHROPIC_BASE_URL同样指向https://taotoken.net/apiANTHROPIC_API_KEY填你在 TaoToken 控制台创建的 KeyANTHROPIC_MODEL按控制台可用模型列表填写。这份配置只给 Claude Code 用不要复制到 Codex 的config.toml。如果你使用 CC Switch 管理多个供应商常见三件套是export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYYOUR_API_KEY export ANTHROPIC_MODELYOUR_CLAUDE_MODEL_ID执行前确认当前 shell 没有旧的ANTHROPIC_*残留。可以这样检查env | grep ANTHROPIC如果同时开着 Codex 和 Claude Code建议把两类配置放在不同终端会话里或者用不同的 shell profile、不同的项目目录、不同的启动脚本隔离。Codex 侧只保留model_provider taotoken [model_providers.taotoken] base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatClaude Code 侧只保留ANTHROPIC_*。两边都指向同一个 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_troubleshoot 获取的 Key 和同一个 Base URL但配置文件、环境变量名、工具入口必须分开。这样排障时才能快速判断问题出在 Codex 的模型供应商还是 Claude Code 的环境变量。对于架构图 Skill 来说最常见的使用路径还是在 Codex 里Codex 负责读仓库、调用模型、执行本地渲染命令Claude Code 可以作为辅助用来解释某个服务依赖或生成 PlantUML 片段。不要把两个工具的 Key、Base URL、模型名混在同一份配置里否则很容易出现“改了 A 工具B 工具报错修了 B 工具A 工具又走默认线路”的循环。6. 排障清单从 401/404 到“还是圆角框”按链路逐段排查当 Codex 里的架构图 Skill 没有按预期出图时建议按下面顺序排查不要一上来就重装工具。第一步确认 Codex 是否真的走 TaoToken。打开~/.codex/config.toml检查model_provider taotoken [model_providers.taotoken] base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY如果项目级配置、profile 或环境变量覆盖了它改回统一入口。Base URL 不要带 UTM也不要写成官网首页。第二步确认 Key 是否被正确读取。在当前终端执行echo $TAOTOKEN_API_KEY如果为空重新导出如果 Key 泄露过去控制台创建新 Key替换环境变量。不要把 Key 写入config.toml的明文字段。第三步确认模型 ID 是否存在。把model改成 TaoToken 控制台模型列表里的 ID不要用记忆中其它平台的模型名。如果返回 404优先怀疑模型 ID 或 Base URL 路径。第四步确认架构图 Skill 是否输出了结构化图描述。让 Codex 只做“读取仓库并输出 DOT”这一步不要同时渲染。如果 DOT 里所有节点都是shapebox, stylerounded问题在提示词或渲染模板如果 DOT 本身已经区分了cylinder、parallelogram、box3d但渲染出来仍是满屏圆角框问题在本地渲染命令或主题配置。第五步确认本地渲染器是否存在。Graphviz 可以用dot -V如果命令不存在先在本地安装 Graphviz。渲染命令由你在本地执行不要让 Agent 直接操作生产环境dot -Tsvg architecture.dot -o architecture.svg第六步确认上下文是否足够。如果仓库很大Codex 只读了少量文件架构图会不完整。可以在 Skill 里要求先输出“已读取文件列表”和“缺失文件列表”再生成图。对于大型仓库可以分模块生成子图最后合并。第七步确认不是多工具配置串台。检查当前终端有没有旧的ANTHROPIC_*变量Codex 不读它们检查 Claude Code 的settings.json有没有被复制进 Codex 配置。两边都使用https://taotoken.net/api但变量名和配置文件不同。如果以上都正常最后再调 Skill 的视觉规则。例如禁止所有节点使用同一种圆角矩形要求接入层、服务层、数据层、外部依赖使用不同颜色要求数据库用圆柱、队列用平行四边形、外部系统用立体框要求边标签写明协议。这些规则会直接改变最终图的形状分布而不是只改颜色。7. 文末 CTA把架构图 Skill 接进 Codex 后下一步怎么走当 Codex 的config.toml已经指向https://taotoken.net/api环境变量里放好YOUR_API_KEY架构图 Skill 也改成输出结构化 DOT 或 PlantUML满屏圆角框的问题通常就能收敛。接下来按这个顺序继续想先在浏览器里验证模型对话和基础连通性打开模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_chat准备把 Codex、Claude Code 或其它编码工具长期接入查看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_plan创建或管理 API Key回到控制台https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_keys如果你同时使用 Claude Code参考 Claude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_arch_skill_ccdoc最后再回到 Codex 侧config.toml里的base_url保持https://taotoken.net/apiKey 用YOUR_API_KEY占位架构图 Skill 先读仓库、再输出带类型的图描述、最后本地渲染。这样你拿到的就不是一张满屏圆角框的示意图而是能看清接入层、服务层、数据层和外部依赖的真实架构图。