1. 为什么 Plan 模式总在第二步就翻车
AI Coding 的 Plan 模式，说白了就是让模型先把「要改什么、按什么顺序改、改完怎么验」写成一份施工图，再交给执行器动手。Trae 里的 Plan 模式配合 GLM-4.7 这类长上下文模型，理论上能把一个模糊需求拆成可执行的任务树，再由 @SOLO Coder 逐步落地。但实际用下来，很多人卡在同一个地方：计划看着挺像样，一执行就偏，改完还得手动回滚。
我复盘了自己最近十几个 Plan 模式任务，翻车点集中在三处。第一是输入太糊，比如「优化一下登录流程」，模型只能猜，拆出来的任务要么太粗要么跑偏；第二是计划没有验收标准，@SOLO Coder 改完你不知道算不算成功，只能靠肉眼扫 diff；第三是模型上下文里缺项目约束，它按通用最佳实践改，结果和你项目里的状态管理、请求封装风格打架。
这篇就围绕 Trae + GLM-4.7 + @SOLO Coder 这条链路，把 Plan 模式从触发到验收的完整流程拆开讲。核心思路是：用 TaoToken 的统一 Key 把模型接入固定下来，让 Base URL、Key、Model ID 三件套稳定可复现，然后把精力全花在 Plan 的输入结构和验收动作上。适合已经在用 Trae 但 Plan 模式时灵时不灵、想把它变成稳定工作流的同学。
先说清楚 TaoToken 在这里的角色。它是一个模型 API 聚合入口，提供统一的 Base URL 和 Key，让你在 Trae、Cline、Codex 这类工具里用同一套凭证切换不同模型。对 Plan 模式来说，价值在于：你不用每个工具单独配一遍 Key，模型 ID 写错、Base URL 漏斜杠这类低级错误能一次性规避。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 路径不带 UTM 参数，配置时别把推广参数拼进去。
Plan 模式的本质是「先规划后执行」的两段式。GLM-4.7 负责规划，@SOLO Coder 负责执行。规划质量决定执行上限。我试过把同一个需求分别用糊描述和结构化描述喂进去，前者拆出 3 个任务还漏了边界情况，后者拆出 7 个任务且每个都带验证点。差距不在模型，在输入。
所以这篇的重点不是教你注册，而是教你写出一份 @SOLO Coder 能照着干、你也能照着验的 Plan。下面从接入配置开始，一步步来。
2. TaoToken 统一 Key 接入 Trae 的前置配置
在写 Plan 之前，得先把模型通道打通。Trae 支持自定义模型接入，你需要准备三样东西：Base URL、API Key、Model ID。这三件套在 TaoToken 的控制台里都能拿到。
先拿 Key。打开 https://taotoken.net/api-keys ，登录后创建一个新的 API Key。建议按工具命名，比如trae-plan-glm，这样后面排查问题时能一眼看出是哪个工具在用。Key 创建后只显示一次，复制下来存到密码管理器里。注意不要把它硬编码进会提交到 Git 的配置文件，用环境变量或者本地 settings 文件。
Base URL 用https://taotoken.net/api。这里有个常见坑：有人会把官网地址https://taotoken.net直接填进去，少了/api路径，结果请求打到首页返回 HTML，Trae 报解析错误。记住 API 入口是带/api的。
Model ID 这块，Plan 模式建议用 GLM-4.7，它的长上下文能力适合把项目代码片段一起塞进规划上下文。Model ID 的准确写法以 TaoToken 文档为准，去 https://taotoken.net/doc 查当前支持的模型列表，别凭记忆写。写错 Model ID 的典型报错是 404 或者model not found。
Trae 的配置入口在设置里的模型管理，选择「自定义模型」或「OpenAI 兼容」，然后填三个字段：
| 字段 | 填写值 | 说明 |
|---|---|---|
| Base URL | https://taotoken.net/api | 必须带 /api |
| API Key | 控制台创建的 Key | 按工具命名便于排查 |
| Model ID | GLM-4.7 对应 ID | 以文档为准 |
如果你用的是 Trae 的 settings 文件方式配置，可以写成这样：
{ "models": [ { "name": "glm-4.7-plan", "provider": "openai-compatible", "baseUrl": "https://taotoken.net/api", "apiKey": "${TAOTOKEN_API_KEY}", "model": "glm-4.7", "maxTokens": 8192, "temperature": 0.3 } ] }这里apiKey用环境变量引用，避免明文。temperature设 0.3 是因为 Plan 模式要的是稳定拆解，不需要发散。maxTokens给大一点，规划阶段输出任务树比较长。
配好之后先别急着跑 Plan，做个最小连通性验证。在 Trae 的模型对话里发一句「回复 ok」，能正常返回就说明通道通了。如果报 401，检查 Key 是否复制完整、有没有多余空格；如果报local proxy failed，检查 Base URL 是不是被本地代理拦截了，把/api路径补全。
这一步做完，模型通道就固定了。后面所有 Plan 任务都走这套配置，不用每次重配。这也是统一 Key 的意义：一次配好，Trae、Cline、Codex 都能复用同一套凭证，换工具不用重新折腾。
3. 可复制的 Plan 模式配置与 CRISP 输入模板
通道通了，接下来是 Plan 模式的核心：怎么把需求写成模型能规划、@SOLO Coder 能执行的输入。我把它总结成 CRISP 五要素，每个要素对应 Plan 质量的一个维度。
Context 是项目上下文。你得告诉模型这是什么项目、什么技术栈、当前架构长什么样。比如「这是一个 Taro + React 的微信小程序，用 Zustand 管状态，试衣功能调后端 GLM-Vision API」。没有这段，模型只能按通用 React 项目猜，拆出来的任务可能用 Redux 方案，和你项目冲突。
Role 是角色设定。让模型扮演「资深前端架构师」还是「时序逻辑专家」，思考角度不一样。Plan 模式建议用架构师角色，因为它更关注任务拆解和依赖顺序，而不是单点代码怎么写。
Issue 是问题描述。用「当…时，出现…，预期应为…」的句式，避免「优化一下」「有点卡」这种模糊词。模糊词会让模型拆出泛泛的任务，比如「提升性能」，@SOLO Coder 拿到这种任务只能瞎改。
Scope 是影响范围。明确限定涉及哪些文件或模块，比如「仅涉及 pages/tryon/index.tsx 和 hooks/useTryOn.ts」。不限定范围，模型可能把整个项目都纳入规划，任务树爆炸，执行时改一堆无关文件。
Preference 是偏好约束。比如「不引入 Redux」「优先用 React 原生机制」「异步操作必须用 AbortController」。这些约束会直接写进 Plan 的风险点和任务分解里，@SOLO Coder 执行时会遵守。
把这五要素拼成一个 Plan 请求模板，可以直接复制用：
你是一名精通小程序性能优化的前端架构师。 【Context】 项目：Taro + React 微信小程序 状态管理：Zustand 相关功能：AI 试衣，调用后端 GLM-Vision API 【Issue】 当用户快速连续上传两张图片时，第二张的试衣结果会覆盖第一张的加载状态， 导致 UI 卡在「处理中」。预期应为：每次上传独立管理状态，前一次请求被取消。 【Scope】 仅涉及 pages/tryon/index.tsx 和 hooks/useTryOn.ts 【Preference】 - 不引入 Redux - 优先使用 React 原生机制 - 异步操作必须使用 AbortController 防止内存泄漏 【输出要求】 请按以下结构输出 Plan： 1. 根因假设 2. 任务分解（每个任务标注涉及文件） 3. 验证方案（可测试的验收标准） 4. 风险点 请逐步推理，以 Markdown Task List 格式输出。这个模板的关键在最后的输出要求。强制分阶段输出，让模型把「根因假设」和「任务分解」分开，你能快速判断它的分析对不对。要求标注涉及文件，是为了让 @SOLO Coder 精准定位。要求可测试的验收标准，是为了后面验收有依据。
GLM-4.7 的长上下文能力在这里能派上用场。你可以把useTryOn.ts的全文作为上下文一起传进去，模型理解精度会明显提升。做法是在 Context 段后面附上代码片段，标注清楚文件路径。
输出格式约束成 Markdown Task List，好处是你可以直接把它贴进 Trae 的任务面板，或者导入项目管理工具。YAML 也行，但 Markdown 可读性更好，人工 review 时更顺眼。
配好这个模板后，每次 Plan 任务就是填空：改 Context、改 Issue、改 Scope、改 Preference。填完发出去，等模型输出任务树。这一步的质量直接决定后面 @SOLO Coder 的执行效果，值得多花两分钟把输入写清楚。
4. 一次 Plan 任务从触发到验收的完整验证
光说模板不够，得跑一遍完整流程。我拿一个真实场景走一遍：修复「连续上传图片导致状态错乱」的问题。
第一步，触发 Plan。在 Trae 里新建一个 Plan 任务，把上一节的模板填好发出去。GLM-4.7 返回的任务树大概长这样：
## 根因假设 useTryOn hook 中 loading 状态是单一布尔值，未与请求实例绑定。 第二次上传时直接覆盖 loading，第一次请求的响应回来后错误地清除了第二次的 loading。 ## 任务分解 - [ ] 任务1：在 useTryOn 中引入请求 ID 或 AbortController 实例，绑定每次上传 - 文件：hooks/useTryOn.ts - [ ] 任务2：上传前取消上一次未完成的请求 - 文件：hooks/useTryOn.ts - [ ] 任务3：loading 状态改为与请求 ID 关联，响应回来时校验 ID 匹配 - 文件：hooks/useTryOn.ts - [ ] 任务4：组件层在卸载时清理未完成请求 - 文件：pages/tryon/index.tsx ## 验证方案 - 连续上传 3 次图片，每次结果正确对应，无状态残留 - 取消上传后，loading 状态在 100ms 内清除 - 组件卸载后无「setState on unmounted component」警告 ## 风险点 - AbortController 在部分小程序环境兼容性需确认 - 请求 ID 方案需保证唯一性，避免并发冲突第二步，人工 review。这一步别省。看根因假设是否合理，任务分解有没有漏，验证方案能不能测。我一般会追问一轮，比如「任务 2 的取消逻辑，如果第一次请求已经返回但状态还没更新，取消还有意义吗？」模型会补充边界处理。追问机制是 Plan 模式质量的关键，别拿到第一版就执行。
第三步，交给 @SOLO Coder 执行。把确认后的任务树贴进 @SOLO Coder 的输入，它会按任务顺序改代码。执行过程中你可以看到每个任务的 diff。这里注意：@SOLO Coder 执行时用的模型通道也是同一套 TaoToken 配置，所以 Base URL、Key、Model ID 三件套保持一致，不会出现规划用 A 模型、执行用 B 模型导致的风格断裂。
第四步，验收。按 Plan 里的验证方案逐条测。连续上传 3 次，看结果是否对应；取消上传，看 loading 是否及时清除；卸载组件，看控制台有没有警告。三条都过，任务算完成。有一条不过，回到 Plan 阶段补任务，而不是直接让 @SOLO Coder 瞎改。
这套流程跑下来，最大的感受是：Plan 模式的价值不在模型多聪明，而在它把「想清楚」和「动手改」分开了。想清楚阶段你投入的每一分钟，都在减少执行阶段的返工。@SOLO Coder 执行得准不准，八成取决于 Plan 拆得细不细。
验证动作里有个细节值得说：验收标准要可测试。像「提升性能」这种没法测，「loading 在 100ms 内清除」就能测。写 Plan 时就要求模型输出可测试的标准，验收时你才有依据，不然只能凭感觉说「好像好点了」。
5. Plan 模式常见报错与排查对照
跑 Plan 模式的过程中，报错基本集中在接入层和执行层。下面按真实遇到的报错整理排查路径。
401 Unauthorized。这是最常见的。原因通常是 Key 复制不完整、有多余空格，或者 Key 被禁用。排查：去 https://taotoken.net/api-keys 重新复制一次，确认没有首尾空格。如果用的是环境变量，检查变量名拼写和是否已 export。
local proxy failed。这个报错说明请求被本地网络层拦截了。排查：确认 Base URL 是https://taotoken.net/api，带/api路径。如果本地有网络工具在跑，检查它是否拦截了这个域名。把 Base URL 补全后重试。
reading choices 相关报错。通常是响应格式不符合预期，比如模型返回了非 JSON 结构，或者 Model ID 写错导致返回了错误页。排查：确认 Model ID 和文档一致，去 https://taotoken.net/doc 核对。另外检查maxTokens是否设得太小，导致响应被截断。
OAuth 相关报错。如果你在 Trae 里同时配了官方登录和自定义模型，可能出现凭证冲突。排查：在 Trae 的模型设置里，确认当前 Plan 任务用的是自定义模型通道，而不是残留的 OAuth 凭证。把自定义模型设为默认，或者显式在任务里指定。
Codex auth.json 报错。如果你同时用 Codex，它的auth.json里存了旧凭证，和 TaoToken 的 Key 冲突。排查：检查~/.codex/auth.json，确认里面的 Base URL 和 Key 与 TaoToken 配置一致。三件套（Base URL + Key + Model ID）必须成套改，只改一个会出问题。
Cline MCP 报错。Cline 通过 MCP 协议接入时，如果 MCP server 配置里的 Base URL 没带/api，会报连接失败。排查：检查 MCP 配置文件里的 endpoint，补全路径。Cline 的配置和 Trae 类似，也是三件套对齐。
CC Switch 切换模型后报错。用 CC Switch 在多个模型间切换时，如果切换后没刷新 Trae 的模型列表，可能还在用旧 Model ID。排查：切换后重启 Trae，或者在模型设置里手动刷新。
除了报错，还有一类「不报错但结果不对」的情况。比如 Plan 拆出来的任务执行后没效果。这通常不是接入问题，是 Plan 输入太糊。回到第 3 节，检查 CRISP 五要素是否齐全，尤其是 Scope 和 Preference 有没有写。
排查顺序建议：先确认三件套（Base URL + Key + Model ID）对齐，再看网络层有没有拦截，最后看 Plan 输入质量。八成问题在前两步，剩下两成在输入。
6. 把 Plan 模式变成稳定工作流的几个习惯
跑顺之后，Plan 模式会变成一种习惯：遇到稍复杂的改动，先让它规划，review 后再执行。这里分享几个我固定下来的做法。
第一个习惯是 Plan 和 Execute 用同一套模型配置。TaoToken 统一 Key 的好处在这里体现：规划和执行走同一个 Base URL、同一个 Key，模型行为一致，不会出现规划用 GLM-4.7、执行用别的模型导致的风格断裂。配置一次，Trae、Cline、Codex 都能复用。
第二个习惯是 Plan 输出必须带验收标准。没有验收标准的 Plan 不执行。这条规则逼着你在输入阶段就把「怎么算成功」想清楚，而不是执行完再补测试。
第三个习惯是追问至少一轮。第一版 Plan 很少是完美的，追问能挖出边界情况。追问的问题可以固定几个：并发场景考虑了吗？异常路径怎么处理？回滚方案是什么？
第四个习惯是任务粒度控制在「一个任务一个文件改动」。太粗的任务 @SOLO Coder 容易改多，太细的任务树又太长。一个任务对应一个文件或一个函数，执行和验收都清晰。
长期做 AI Coding 的话，可以考虑 Coding Plan 这类按周期计费的方式，把模型调用成本固定下来，不用每次算 token。入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，适合高频使用 Plan 模式的场景。
模型对话入口在 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，可以用来快速验证模型是否正常响应。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，配置遇到不确定的字段去这里核对。控制台在 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，管理 Key 和用量。
最后说个踩过的坑：别把 Plan 模式当万能。它适合有明确边界、可拆解的任务。需求本身还在探索阶段时，先用人机对话把需求聊清楚，再进 Plan。硬把模糊需求塞进 Plan，拆出来的任务树看着完整，执行时全是返工。Plan 模式的上限，是你对问题的理解深度。
