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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_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路径结果请求打到首页返回 HTMLTrae 报解析错误。记住 API 入口是带/api的。Model ID 这块Plan 模式建议用 GLM-4.7它的长上下文能力适合把项目代码片段一起塞进规划上下文。Model ID 的准确写法以 TaoToken 文档为准去 https://taotoken.net/doc 查当前支持的模型列表别凭记忆写。写错 Model ID 的典型报错是 404 或者model not found。Trae 的配置入口在设置里的模型管理选择「自定义模型」或「OpenAI 兼容」然后填三个字段字段填写值说明Base URLhttps://taotoken.net/api必须带 /apiAPI Key控制台创建的 Key按工具命名便于排查Model IDGLM-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 - [ ] 任务3loading 状态改为与请求 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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 适合高频使用 Plan 模式的场景。模型对话入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 可以用来快速验证模型是否正常响应。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 配置遇到不确定的字段去这里核对。控制台在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理 Key 和用量。最后说个踩过的坑别把 Plan 模式当万能。它适合有明确边界、可拆解的任务。需求本身还在探索阶段时先用人机对话把需求聊清楚再进 Plan。硬把模糊需求塞进 Plan拆出来的任务树看着完整执行时全是返工。Plan 模式的上限是你对问题的理解深度。