1. 先解决 Key 和 Base URLClaude Code 接 TaoToken 的最短路径在 Claude Code 里让模型一次性吐出一套 FICC 场外衍生品平台的四层功能架构最先卡住的往往不是提示词写得够不够细而是 Key 和 Base URL 到底该往哪里填。这篇用 TaoToken 做供应商先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 拿到 KeyBase URL 填https://taotoken.net/api后面所有配置里的YOUR_API_KEY都换成它。上一轮我用 Claude Code 推进一个金融交易平台项目踩过一个顺序问题架构文档一铺开、上下文一涨请求量和 token 消耗比预想快得多如果供应商入口不稳定中途换 Key 会把已经养起来的对话链路整段打断。所以这一轮我改了做法——先把配置钉死再进正式对话。顺序是拿 Key → 写配置文件 → 跑一次连通性验证 → 再开始让模型产出架构清单。反过来做的话架构没生成出来你根本分不清是提示词的问题、上下文的问题还是 Key 压根没生效。这一篇的产出目标很具体在 Claude Code 里用 TaoToken 提供的 Key产出用户入口、核心系统、风控分析、集成服务四层架构清单并且把模块边界写清楚。视角仍然是产品经理先立系统结构一期只做对客门户但架构必须站在全平台视角搭否则后面每加一个模块、每扩一个品种都可能伤筋动骨。下面按“配置 → 提示词 → 四层架构核对 → 引擎边界 → 接口契约 → 排障”的顺序展开每一步都可以跟着做一遍。2. settings.json 与 ANTHROPIC_*把供应商切换写成可复制的三份配置Claude Code 的供应商切换本质上就是让ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN指向 TaoToken。推荐用项目级或全局的settings.json好处是配置跟着项目走不需要每次开终端都 export 一遍。全局配置放在~/.claude/settings.json项目级放在项目根目录的.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY } }如果你更习惯用环境变量macOS / Linux 下这样写export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEYWindows PowerShell$env:ANTHROPIC_BASE_URL https://taotoken.net/api $env:ANTHROPIC_AUTH_TOKEN YOUR_API_KEY这里要强调一句上面这套ANTHROPIC_*是 Claude Code 的写法不要套到 Codex 上去。Codex 走的是config.toml两者字段完全不通用。Codex 的配置放在~/.codex/config.tomlmodel_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY对应的环境变量单独设一个export TAOTOKEN_API_KEYYOUR_API_KEY如果你同时用 Claude Code、Codex还想在两者之间快速切换就用 CC Switch 三件套的思路来管理Base URL、API Key、默认模型各自存成一份 profile切换的时候只改引用不改内容。这样切供应商不会把手写好的架构对话上下文搞乱也不会出现“Claude Code 里能跑、Codex 里报 401”这种莫名其妙的错位。Key 从哪来统一走官网控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 注册后进 API Keys 页面创建。创建完先别关页面把 Key 粘到配置文件里再跑一次连通性检查。连通性验证建议用一次最简单的模型对话而不是直接上架构提示词。进 https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 发一条短消息能正常返回说明 Base URL 和 Key 都通了如果报 401多半是 Key 复制带了空格如果报 404检查 Base URL 有没有多写/v1或结尾斜杠。这一步排掉之后再进正式对话。3. 提示词骨架让 Claude Code 先输出四层架构清单再谈模块边界配置通了之后第二步是提示词。很多人一上来就让模型“设计一套 FICC 平台架构”结果拿到一份看起来完整、但层级混乱、模块互相重叠的文档。问题不在模型能力而在约束给得太松。我这一轮的提示词骨架是这样的可以直接复制去用你现在扮演 FICC 场外衍生品平台的产品架构师。 请基于以下约束输出一份四层功能架构清单 1. 分层固定为用户入口层 / 核心系统层 / 风控与分析层 / 系统集成与基础服务层 2. 每层必须列出模块名、一句话职责、上游依赖、下游被依赖方 3. 一期范围只做对客门户其余入口保留占位并标注二期 4. 单独拆出对冲撮合引擎作为核心系统层的一个模块 并说明它为什么需要横跨客户订单、自营订单、做市订单 5. 不允许虚构监管报送字段只写模块边界 6. 输出格式按层用 Markdown 表格 列依次为 模块名 / 职责 / 上游 / 下游 / 本期是否实现这个提示词的关键在于第 2 条和第 5 条。第 2 条逼模型把“上游依赖”和“下游被依赖方”显式写出来模块边界就藏在这两列里第 5 条是防止模型为了“看起来完整”而编造字段。AI 输出东西快、结构完整特别容易给人一种“看起来没问题”的错觉你如果不在提示词里提前封口它就会把没核实的内容整齐地包进文档里。跑完这一轮你会拿到一份四层表格。但拿到表格只是开始真正的活是逐条核对边界。这一步别偷懒下面单独讲。4. 四层架构逐层体检用户入口 / 核心系统 / 风控分析 / 集成服务对照模型产出的表格逐层过一遍看它有没有把该留的占位留出来、该拆的模块拆开。用户入口层最终应该包含对客门户、交易员工作台、销售工作台、风控工作台、运营管理台、产品管理台六个入口。一期只实现对客门户但其余五个必须留在架构图里作用是让一期位置一目了然——否则你后面加交易员工作台的时候会发现它不知道该挂在哪一层。核心系统层应该包含对客门户系统、产品管理系统、业务管理系统、交易子系统以及一个必须单独拎出来的模块对冲撮合引擎。前四个是常规拆分第五个是这套平台和市面上常见平台最核心的差异点后面单独一节讲。风控与分析层负责实时风控、日终风控、压力测试与情景分析、报告与分析。这里最容易出的问题是模型把“实时风控”和“事前风控”混成一件事。事前风控是订单提交时的校验动作属于交易链路实时风控是对存续敞口的持续监控属于风控层。核对的时候把这两个拆开否则接口契约会跟着错。系统集成与基础服务层包含用户中心与权限服务、参考数据服务以及若干周边系统客户管理系统、行情系统、外部交易通道、清结算平台、监管报送。这一层的模块大多不是一期要实现的但必须在清单里列清楚因为对客门户系统要依赖它们。我在核对这一层的时候发现过一个典型问题模型在“直接下单”这个场景下又自己拆出了两个子场景我当时扫了一眼觉得结构对就放过去了。直到后来输出功能列表发现下单模块里多出来一个页面倒查回去才发现问题出在架构文档。这个坑不大但提醒我一件事——AI 不会主动告诉你“这里我多拆了一层”它只会把多拆的内容整齐地包进文档里。如果你不逐条核对边界后面的设计会一层一层把错误放大。所以这一层的核对动作要具体拿一张纸把模型输出的模块名逐个抄下来对着四层结构问三个问题——它属于哪一层它的上游是谁它的下游是谁答不上来的模块要么是多余要么是边界没写清回去让模型重写那一段。5. 对冲撮合引擎为什么必须被单独拎出来四层架构里最值得单独讲的是核心系统层的对冲撮合引擎。很多平台的架构会把“订单匹配”当成交易子系统的一部分但场外衍生品的场景不一样。它真正要处理的是跨业务条线、跨品种、跨市场的综合对冲与流动性寻优。A 账户的债券卖出需求可以和 B 账户的买入需求匹配代客业务里的利率风险敞口也可能和自营盘里的外汇风险形成内部抵消。有些情况下甚至不需要发生实质的持仓和资金划转只在合并报表层面形成内部承诺把风险敞口抵消掉。它的目的只有一个最大化内部消化风险减少不必要的外部交易从而节约交易成本、资金占用和风险指标占用。在 Claude Code 的提示词里我把“生成对冲单的规则”也合并进了这个模块的描述而不是放在交易子系统里。原因是生成对冲单和撮合对冲单本质上是同一个优化问题的两个阶段拆到两个模块里会导致规则分散、边界模糊。让模型明白这一点它输出的接口契约才会把这两个动作放在同一条链路上。核对这一层的时候重点看三件事这个模块的输入是不是包含客户订单、自营订单、做市订单三类它的输出是不是明确区分了“内部撮合成交”和“转外部通道报盘”两条路径它和交易子系统之间的调用方向是同步还是异步。这三条对上了后面写接口契约才不会返工。6. 接口契约只做到粗粒度给 AI 划边界的四个层级接口契约这个阶段不需要做到字段级。我在提示词里明确要求模型只输出粗粒度契约哪些系统之间存在接口、每个接口解决什么业务问题、关键输入输出是什么、同步还是异步。字段类型、校验规则、错误码、状态机全部留到后续功能设计时再补——那时候需求已经收敛现在硬写会浪费工作量而且大概率会被推翻。按与一期工作的关联度接口分成四层来列。第一层是对客门户前端和对客门户系统之间的接口包括登录、产品浏览、下单、查询持仓资金。这一层是一期最直接要实现的必须逐条列清楚。第二层是对客门户系统与周边系统的接口包括用户中心与权限服务、客户管理系统、产品管理系统、交易子系统、行情系统、业务管理系统。这些是一期对客门户必须依赖的外部服务任何一条缺失一期都跑不起来。第三层是核心系统层内部的接口比如对客门户系统到交易子系统、交易子系统到对冲撮合引擎、对冲撮合引擎到外部交易通道。这一层决定了核心链路的调用顺序建议让模型把同步/异步标注出来。第四层是业务运营链路服务日终运营、追保强平、清结算。对客门户一期不直接涉及所以只列清单不展开。让模型按这四层输出的时候加一句约束“每个接口必须写清楚它属于哪一层如果归类不确定单独列出来讨论。”这样能避免模型把不同层的接口混在一起导致后面拆任务的时候边界打架。粗粒度契约的价值在于它能让你在不动代码的情况下先把系统之间的握手顺序推演一遍。推演过程中如果发现两个接口形成循环依赖说明模块边界有问题回架构层改比等到写代码时再改便宜得多。7. 排障与落地顺序从模型对话到 Coding Plan配置和提示词都跑通之后常见的报错就那几个逐个排掉就行。一是 401Key 无效或没生效。先确认settings.json里的ANTHROPIC_AUTH_TOKEN是不是YOUR_API_KEY的占位符还没替换再确认环境变量和配置文件没有同时设置且值冲突。Claude Code 的优先级是环境变量高于配置文件两处值不一样时会用环境变量。二是 404Base URL 路径不对。TaoToken 的 Base URL 就是https://taotoken.net/api不要自己加/v1也不要留结尾斜杠。三是超时。先确认网络能通https://taotoken.net/api再确认当前对话上下文有没有过大。架构文档这种长文本任务建议拆成“先生成某一层、再生成下一层”而不是一次让它输出全部四层。四是 Codex 侧配置不生效。检查~/.codex/config.toml里的env_key和实际设置的环境变量名是否一致Codex 不会自动读取ANTHROPIC_*这是两个独立的配置体系。如果你同时用多个模型供应商建议按 CC Switch 三件套的方式把 Base URL、API Key、默认模型分别管理切换时只改引用。这样在架构设计、需求文档、技术文档几个阶段之间切换模型时不会把项目级的.claude/settings.json搞乱。回顾一下这一轮的进度对比上一阶段搭领域模型用了三天半这一轮做系统功能架构、核心业务流程、接口契约三项加起来四天。今天已经开始输出一期对客门户的功能列表。能明显感觉到前期做的知识库、spec、每日对话沉淀开始起作用先打整体地基、再建一期工程的路线也选对了。AI 对项目上下文的把握越来越稳很多方案第一版就能接近可用。但这个实验还在继续。接下来两周的重点是一期对客门户的需求文档需求定稿之后进入技术文档和代码阶段。如果你也在用 Claude Code 做复杂产品设计建议按下面的顺序把工具链搭好先去 https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 发一条短消息确认 Base URL 和 Key 通需要长期跑架构、需求、技术文档多阶段任务看 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 到 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 创建正式 Key替换掉YOUR_API_KEY配置细节和字段说明查 https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 最后回官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentficc_arch 确认账号和套餐状态。把这五步走完Claude Code 里的 Key 和 Base URL 就算彻底钉死了。剩下的就是拿第 3 节那段提示词把 FICC 的四层架构清单跑出来然后一层一层核对边界。