1. 为什么要在 Claude Code 里给 product-flow 配一条统一通道
product-flow 是一个把产品决策拆成 5 段闭环的 Claude Code plugin：spark 收敛灵感、audit 审方向、frame 出 5 件套、spec 写 PRD、verdict 做上线后判决。它本身不产出模型能力，所有推理都发生在 Claude Code 会话里。问题也正出在这里——当你把 product-flow 以 plugin 形式挂进 Claude Code，会话里的每一次 skill 调用、每一次 sub-agent dispatch、每一次 PRD 生成，都要走一条模型 API 通道。如果这条通道的 Key 散落在环境变量、shell profile、项目级.env里各写一份，你会在三个地方反复踩坑：换机器要重新配、团队协作时 Key 对不上、PRD 生成到一半报 401 却不知道是哪层配置没生效。
这篇要解决的就是这一件事：给 product-flow 在 Claude Code 里落一份可复制的config.toml骨架，把统一 Key 和 API 通道的填写位置固定下来，再用一次 PRD 生成链路验证整条路是通的。适合已经在用 Claude Code、想跑产品决策流程、但被多套 skill 切换和 Key 管理搞烦的人。读完你可以直接复制配置，跑通一次从 spark 到 spec 的产品决策流程。
我试过把 Key 分别塞进四个 skill 的独立配置里，结果是 audit 段能跑、spec 段报错，排查了半小时才发现是 sub-agent dispatch 那层读的是另一个变量。所以下面这份骨架的核心思路是：通道只配一次，所有段共用。
2. TaoToken 前置：通道、Key 与 plugin 的关系
TaoToken 在这里扮演的角色是 Claude Code 会话背后的统一模型 API 通道。product-flow 的 5 段 skill 本身是 prompt 编排逻辑，它们不关心模型从哪来，只关心调用能不能通、返回稳不稳。你把通道配在 Claude Code 这一层，product-flow 的所有段就自动继承。
需要先明确三个概念的位置关系：
- plugin 层：product-flow 以 plugin 形式被 Claude Code 加载，提供 5 段 skill 和触发词。
- 通道层：Claude Code 通过
config.toml里的 provider 配置决定请求发往哪个 API 端点。 - Key 层：API Key 是通道的凭证，配一次，plugin 内所有 skill 共用。
所以配置顺序是：先在 TaoToken 控制台拿到 Key，再把 Key 和 API 端点写进 Claude Code 的config.toml，最后确认 product-flow plugin 已被加载。三步里任何一步错位，PRD 生成链路都会断。
拿 Key 的入口在控制台，创建后复制那串以sk-开头的字符串，先存到安全的地方。注意 Key 只在创建时完整显示一次，关掉页面就看不到了，这是很多人第一次配就卡住的原因。
提示：不要把 Key 直接写进会提交到 git 的
config.toml。下面骨架里我用环境变量占位，实际填写时替换成你的读取方式。
3. 可复制配置：config.toml 骨架与填写位置
Claude Code 的配置文件通常放在用户目录下的.claude/config.toml（不同版本路径可能略有差异，以你本地claude --version对应的文档为准）。下面这份骨架把通道、Key、plugin 三块分开写，方便你定位。
# ~/.claude/config.toml # product-flow 产品决策 plugin 的统一通道配置骨架 [provider] # 统一 API 通道，所有 skill 共用这一条 name = "taotoken" base_url = "https://taotoken.net/api" # Key 从环境变量读取，避免明文入库 api_key_env = "TAOTOKEN_API_KEY" # 请求超时，PRD 生成链路较长，给足时间 timeout_seconds = 120 # 失败重试次数，sub-agent dispatch 场景建议 >= 2 max_retries = 2 [model] # 默认模型，product-flow 各段共用 default = "claude-sonnet-4-5" # spec 段生成 PRD 时可用更强模型，按需覆盖 spec_override = "claude-sonnet-4-5" [plugins.product-flow] enabled = true # plugin 加载路径，按你 clone 的位置改 path = "~/plugins/product-flow" # 5 段 skill 的触发词前缀，保持默认即可 trigger_prefix = "product-" [plugins.product-flow.skills] spark = "product-spark" audit = "product-audit" frame = "product-frame" spec = "product-spec" verdict = "product-verdict"填写位置说明，逐块对照：
[provider]块是通道层，base_url固定填https://taotoken.net/api，不要带尾部斜杠。api_key_env写的是环境变量名，不是 Key 本身。你在 shell 里这样导出：
# 写入 shell profile，重启终端生效 export TAOTOKEN_API_KEY="sk-你的Key"[model]块决定 product-flow 各段用哪个模型。default覆盖 spark/audit/frame/verdict，spec_override单独给 spec 段，因为 PRD 生成对上下文长度和指令遵循要求更高。两个都填同一个模型也能跑，先跑通再调优。
[plugins.product-flow]块是 plugin 层。path指向你 clone 下来的 product-flow 仓库目录，enabled = true才会被 Claude Code 加载。[plugins.product-flow.skills]把 5 段触发词映射到具体 skill 名，保持默认即可，除非你改过 skill 文件名。
注意：
config.toml里所有路径用绝对路径最稳，~展开在某些版本下不生效，建议直接写/Users/你的用户名/plugins/product-flow这种形式。
配完保存，重启 Claude Code 让配置生效。这一步不做，后面验证会一直读到旧配置。
4. 验证请求：跑通一次 PRD 生成链路
配置写完不算通，要跑一次真实链路。product-flow 的验证动作我建议直接走 spec 段，因为它会触发 sub-agent dispatch，能同时验证通道、Key、plugin 加载三层。
第一步，确认 plugin 被加载。在 Claude Code 会话里输入：
/product-flow status预期返回 5 段 skill 的加载状态，每段显示loaded。如果某段显示not found，回去检查config.toml里path和skills映射。
第二步，触发 spark 段做一次轻量调用，验证通道通不通：
我有几个 AI 工具想法不知道做哪个，帮我收敛一下预期返回：spark 段会输出 2-3 个候选方向，并提示你选一个进入 audit。这一步如果报 401，说明 Key 没读到，检查TAOTOKEN_API_KEY是否在当前 shell 生效；如果报连接超时，检查base_url是否写成了带斜杠或带路径的形式。
第三步，直接跳到 spec 段验证 PRD 生成链路：
写需求 / 写 PRD预期返回：spec 段进入 5 个 phase，输出一份约 1.5 页的 PRD，每个 MUST story 带sub_agent_hints块，包含type、primary_skill、acceptance_check等字段。看到这个结构，说明通道、Key、plugin、sub-agent dispatch 四层全通。
第四步，验证 verdict 段的历史读取能力，因为它要读磁盘上的docs/verdicts/<产品名>-history.md：
上线 1 个月了，跑一次 verdict预期返回：verdict 段会先读历史文件，如果不存在会提示你创建，存在则输出持守/调整/杀三档判决。这一步验证的是 plugin 对本地文件系统的访问权限，和 API 通道无关，但属于完整链路的一部分。
四步跑完，你就有了一条可复现的验证路径。下次换机器，复制config.toml、导出环境变量、clone plugin，重跑这四步即可。
5. 本篇常见错排查
配置类问题大多集中在几个固定位置，我按出现频率排一下。
报 401 Unauthorized：九成是 Key 没读到。先确认echo $TAOTOKEN_API_KEY有输出，再确认config.toml里api_key_env拼写和导出的变量名完全一致，大小写敏感。如果用了.env文件，确认 Claude Code 启动时加载了它。
报连接超时或 DNS 失败：检查base_url是否写成了https://taotoken.net/api/（多了尾部斜杠）或https://taotoken.net/api/v1（多了路径）。正确形式就是https://taotoken.net/api。
plugin 显示 not found：path用了~没展开，或路径指向了仓库的父目录而不是仓库根目录。product-flow 的根目录下应该有README.md和skills/文件夹，path指到这一层。
spec 段跑到一半中断：timeout_seconds太短。PRD 生成链路涉及多轮 sub-agent dispatch，默认 120 秒对复杂方向可能不够，调到 180 或 240 再试。同时确认max_retries至少为 2，网络抖动时能自动重试。
sub_agent_hints 字段缺失：说明 spec 段没走到 Phase 5，通常是前面 phase 的 HARD-GATE 没过。检查会话里有没有出现「退回」提示，按提示回到对应 phase 重写，不要强行跳过。
verdict 段读不到历史：确认docs/verdicts/目录存在且当前工作目录正确。verdict 段读的是相对路径，如果你在别的目录启动 Claude Code，它会找不到文件。
改了 config.toml 不生效：Claude Code 不会热加载配置，必须重启进程。改完保存后完全退出再启动，不要只开新会话。
提示：排查时优先看 Claude Code 的日志输出，它会打印实际请求的
base_url和是否读到 Key，比猜快得多。
6. 接下来怎么用：从验证到长期编码
跑通上面四步验证后，product-flow 的 5 段就可以正常用了。日常触发词保持默认：spark 段说「我有几个想法不知道做哪个」，audit 段说「这个方向值不值得做」，frame 段说「frame 一下」，spec 段说「写需求 / 写 PRD」，verdict 段说「跑一次 verdict」。
如果你打算把 product-flow 用在长期的产品迭代上，尤其是 spec 段频繁触发 sub-agent dispatch 的场景，建议把通道配置和 Coding Plan 结合看。Coding Plan 面向的是持续编码和 Agent 类调用，product-flow 的 PRD 生成链路正好属于这一类，配好之后不用每次担心额度。
需要创建或轮换 Key 时，入口在 API Keys 页面，建议给 product-flow 单独建一个 Key，方便按 plugin 维度追踪用量。接入细节和参数说明在接入文档里，遇到本文没覆盖的报错可以对照查。
想先不配 Claude Code、直接在网页里试一下模型对话效果，可以用模型对话页面验证通道是否正常，确认没问题再回到本地配config.toml。
配置这件事的诀窍就一句：通道只配一次，Key 只存一处，plugin 只指一个路径。三样对齐，product-flow 的 5 段就能串起来跑，不用再在 47 个 PM skill 之间手动切换。
