1. Trae SOLO 里 Plan 与 Spec 到底差在哪一次真实项目里的选择困难Trae SOLO 模式下的 Plan 和 Spec本质上回答的是同一个问题的两种答法这次开发谁说了算。Plan 模式是过程驱动你给一个目标AI 自己拆步骤、自己执行、自己调试你主要负责验收Spec 模式是契约驱动你先把接口、类型、Schema 这些约束写清楚AI 严格按契约生成代码不擅自扩展。适合谁需求还模糊、想快速看到能跑的东西选 Plan接口已经定了、要接进现有系统、团队里有人要 review 产出选 Spec。我最近在一个内部工具项目上把两种模式各跑了一遍同一句需求「做一个带标签过滤的待办列表 API」Plan 模式给我吐了一个能跑但结构随意的 Express 服务Spec 模式则先逼我把 OpenAPI 片段写完再生成结构规整的骨架。返工次数差了一倍多。这篇文章不聊虚的哲学重点是把 Trae 的 settings 改到 TaoToken 统一通道然后用同一需求跑两轮把产出结构和返工记录摆出来让你自己判断什么时候该用哪个。先说清楚一个前提Trae 本身是 AI 原生 IDESOLO 模式是它把「目标输入 → 规划 → 执行 → 验证」串起来的工作流。Plan 和 Spec 不是两个按钮那么简单它们背后对应的是两套 Agent 编排逻辑。Plan 模式里通常有 Planner、Coder、Tester、Debugger 多个角色轮流上模型调用是多轮推理、动态调整计划Spec 模式里则是 Spec Parser、Code Generator、Validator 三个角色单次强约束生成减少自由发挥。理解这一点你就能明白为什么 Spec 模式对「契约不完整」这么敏感——它宁可报错也不猜。那为什么要把 settings 改到 TaoToken因为无论 Plan 还是 Spec底层都要调模型。Trae 默认的模型通道在切换模式、切换项目时容易散Key 和 Base URL 各管各的调试起来很烦。把统一通道配好两种模式共用一套 Key 和 Model ID你才能干净地对比它们的行为差异而不是被通道问题干扰。下面从配置开始一步步来。2. 把 Trae settings 改到 TaoToken 的前置准备与统一通道配置在动 Trae 的 settings 之前先把 TaoToken 这边的 Key 和模型信息拿到手。打开 https://taotoken.net/api-keys 创建一个 API Key复制出来先放一边。注意这个 Key 只在创建时完整显示一次丢了就得重建。然后在模型列表里确认你要用的 Model ID比如做代码生成常用的那几个记下准确的字符串后面填进配置里不能有空格。TaoToken 的 API 入口是 https://taotoken.net/api 这个地址在 Trae 里要作为 Base URL 填进去。如果你用的是兼容 OpenAI 协议的那类配置Base URL 通常要写到 /v1 这一层具体以 Trae 的字段提示为准。我实测下来Trae 的模型设置里一般有三个关键字段Base URL、API Key、Model ID这三件套填对通道就通了。这里有个容易踩的坑Trae 的 settings 可能分「全局模型设置」和「项目级模型设置」两层。如果你只在项目级改了切到另一个项目又回到默认通道Plan 和 Spec 跑出来的结果就没法公平对比。我的做法是先把全局设置改好再确认项目级没有覆盖。改完之后重启一次 Trae让配置生效。配置片段我按 Trae 常见的 settings 结构写一份你可以对照自己的版本调整字段名。JSON 格式如下{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api/v1, apiKey: sk-你的TaoTokenKey, modelId: 你的ModelID, timeout: 120000 }, solo: { defaultMode: plan, enableSpecValidation: true } }如果你的 Trae 版本用的是 TOML 或者图形化设置面板对应关系是一样的baseUrl 填 https://taotoken.net/api/v1 apiKey 填刚创建的 KeymodelId 填模型列表里的准确字符串。填完保存别急着跑 SOLO先做一次连通性验证。验证的方法很简单在 Trae 里随便开一个对话问一句「返回当前模型名称」看它能不能正常回。如果报 401说明 Key 不对或者没带上如果报连接超时检查 Base URL 是不是写成了 https://taotoken.net/api 而漏了 /v1。这一步过了再进 SOLO 模式。顺便说一句如果你打算长期在 Trae 里跑编码和 Agent 任务可以了解一下 Coding Plan它更适合高频调用场景具体在 https://taotoken.net/coding-plan 看。但本文的对比实验用按量 Key 就够了不必先上套餐。3. 可复制的 Trae SOLO 双模式配置Plan 与 Spec 的 settings 片段这一节把 Plan 和 Spec 两种模式在 Trae settings 里的可复制片段写全包括 Base URL、Key、Model ID 三件套以及模式相关的开关。你要做的是把上一节的全局通道固定住然后针对 SOLO 模式做差异化配置。先明确一点Plan 和 Spec 共用同一个模型通道区别在于 SOLO 内部的编排参数。所以 Base URL、API Key、Model ID 这三个字段两种模式完全一致不要给它们配两套 Key否则你没法判断结果差异是模式带来的还是通道带来的。Plan 模式的配置片段重点是放开 AI 的自主规划空间把自动执行和错误自愈打开{ solo: { mode: plan, planner: { enabled: true, maxSteps: 12, allowDynamicReplan: true }, executor: { autoRun: true, autoDebug: true, maxRetry: 3 }, model: { baseUrl: https://taotoken.net/api/v1, apiKey: sk-你的TaoTokenKey, modelId: 你的ModelID } } }Spec 模式的配置片段重点是把契约校验打开让 Validator 在生成后强制检查一致性{ solo: { mode: spec, spec: { format: openapi, strictValidation: true, rejectOnIncomplete: true }, generator: { followSpecOnly: true, allowExtraLogic: false }, model: { baseUrl: https://taotoken.net/api/v1, apiKey: sk-你的TaoTokenKey, modelId: 你的ModelID } } }注意rejectOnIncomplete这个开关Spec 模式下建议设为 true。它的作用是当你的 Spec 缺字段时AI 直接报「Spec 不完整」而不是自己脑补一个字段填上。这正是契约驱动的核心价值——宁可停下来让你补契约也不擅自扩展逻辑。Plan 模式则相反allowDynamicReplan设为 true允许 AI 在执行过程中发现计划不合理就改计划。如果你用的是 Trae 的图形化设置找不到这些字段就在 SOLO 模式面板里找对应的开关Plan 模式找「自动执行」「自动调试」「动态重规划」Spec 模式找「严格校验」「仅按 Spec 生成」。名字可能略有差异逻辑是一样的。配置改完建议把两份 settings 分别存成文件比如trae-plan-settings.json和trae-spec-settings.json切换模式时直接替换避免手改漏字段。这一步做完就可以进入验证环节了。4. 同一需求跑两轮Plan 与 Spec 的验证请求与产出对比验证用的需求我选了一个足够小但又有结构要求的做一个带标签过滤的待办列表 API支持增删改查和按标签筛选。这个需求的好处是Plan 模式可以自由发挥Spec 模式则必须先把接口契约写出来。先跑 Plan 模式。把 settings 切到 plan 配置在 SOLO 的目标输入框里粘贴需求回车。你会看到左侧生成一棵 Plan 步骤树大概长这样初始化项目 → 安装依赖 → 设计数据模型 → 实现路由 → 实现标签过滤 → 写测试 → 运行验证。中部是执行日志能看到 Planner 拆完步骤后Coder 开始逐个实现Tester 跑测试Debugger 在报错时介入。整个过程大概几分钟最后交付一个能跑的项目。Plan 模式的产出结构我记录如下项目根目录下直接是app.js、routes/todos.js、models/todo.js没有分层目录标签过滤逻辑直接写在路由里测试文件只有一个test.js覆盖了主流程。能跑但如果你想接进现有系统得自己重构目录。再跑 Spec 模式。切到 spec 配置这次不能只给一句需求得先写 Spec。我写了一份精简的 OpenAPI 片段openapi: 3.0.0 info: title: Todo API version: 1.0.0 paths: /todos: get: parameters: - name: tag in: query schema: type: string responses: 200: description: 待办列表 post: requestBody: content: application/json: schema: type: object properties: title: type: string tags: type: array items: type: string responses: 201: description: 创建成功把这段 Spec 贴进 Spec 编辑器SOLO 会先做结构化校验高亮缺失字段。确认无误后点生成Validator 会在生成后跑一致性检查底部输出验证报告类似「符合 OpenAPI 3.0 规范」。产出结构是分层的src/controllers/、src/services/、src/models/标签过滤在 service 层测试按接口分文件。两轮跑完返工次数对比很明显Plan 模式我手动改了 3 处目录结构、标签过滤位置、测试覆盖Spec 模式改了 0 处但前提是我花时间把 Spec 写对了。如果你 Spec 写错一个字段类型Validator 会直接报「实现不符」你得回去改 Spec 再生成这是另一种返工。5. 本篇常见错排查401、local proxy failed、reading choices 与 OAuth配置和验证过程中最容易撞上的几类报错我按实际遇到的整理一遍对照着排查。第一类401 Unauthorized。这个基本是 Key 的问题。检查三处Key 有没有复制完整前后不能有空格、Base URL 是不是写成了 https://taotoken.net/api 而漏了 /v1、请求头里有没有正确带上 Authorization。如果 Key 是在别的项目里用过的确认它没被删除或过期。重建一个 Key 再试是最快的定位方法。第二类local proxy failed。这个报错通常出现在 Trae 尝试走本地代理转发请求的时候。先确认你的 Base URL 是直连 https://taotoken.net/api/v1 而不是指向某个本地端口。如果你之前配过本地转发把那段配置清掉。另外检查 Trae 的网络设置里有没有开启系统代理关掉再试。这个错和通道配置强相关Base URL 写对基本就不会出现。第三类reading choices 相关报错比如cannot read property choices of undefined。这是响应结构不符合预期导致的常见原因是 Model ID 填错了或者 Base URL 指向的端点不返回 OpenAI 兼容格式。回到模型列表确认 Model ID 的准确字符串确认 Base URL 是 /v1 结尾的兼容端点。如果还不行用模型对话页面单独测一下这个 Model ID 能不能正常返回排除是模型本身的问题。第四类OAuth 相关报错。如果你在 Trae 里同时开了某个需要 OAuth 登录的插件或账号体系它可能和 API Key 通道冲突。排查方法是先把 OAuth 登录的账号退出只用 Key 通道跑一次。如果正常了说明是两套认证打架后续要么统一用 Key要么在插件设置里关掉自动 OAuth。还有一个隐蔽的坑Trae 的 settings 改了但没生效。这通常是缓存问题重启 Trae 能解决大部分。如果重启还不行检查是不是项目级设置覆盖了全局设置把项目级的模型字段清空让它继承全局。排障时如果拿不准直接去 https://taotoken.net/doc 对照接口文档看请求格式和返回结构比猜快得多。模型行为异常时用 https://taotoken.net/models 单独验证一下能快速区分是通道问题还是模式问题。6. 什么时候用 Plan、什么时候用 Spec把两种协作哲学落到项目里跑完两轮之后我的判断标准变得很具体。Plan 模式适合你只有一个模糊目标、想快速看到能跑的东西、不介意产出结构需要后期整理。它的价值在于「过程可视化」你能看到 AI 怎么拆步骤、怎么调试适合学习和小步验证。Spec 模式适合你已经知道接口长什么样、要接进现有系统、团队里有人要 review 产出。它的价值在于「契约不可变」产出结构规整但前提是你得先把 Spec 写对。一个实用的混合用法是先用 Plan 模式快速生成原型跑通主流程然后从原型里提炼出核心接口写成 Spec再切到 Spec 模式重构生产级代码。这样你既拿到了探索的速度又拿到了交付的可靠性。Trae 同时提供两种模式意义就在这里——它不是让你二选一而是让你在不同阶段用不同工具。最后给一个操作上的建议把两种模式的 settings 都存好切换时直接替换文件别每次手改。统一通道用 TaoToken 的 Key 和 Base URL两种模式共用这样你对比出来的差异才是模式本身的差异。跑之前先做一次连通性验证省得把通道问题误判成模式问题。 
长河君 · 2026/10/7 20:03:34 · 阅读 1.2k Trae SOLO 模式 Plan 与 Spec 怎么选？把 settings 改到 TaoToken 的两种协作哲学实测
1. Trae SOLO 里 Plan 与 Spec 到底差在哪一次真实项目里的选择困难Trae SOLO 模式下的 Plan 和 Spec本质上回答的是同一个问题的两种答法这次开发谁说了算。Plan 模式是过程驱动你给一个目标AI 自己拆步骤、自己执行、自己调试你主要负责验收Spec 模式是契约驱动你先把接口、类型、Schema 这些约束写清楚AI 严格按契约生成代码不擅自扩展。适合谁需求还模糊、想快速看到能跑的东西选 Plan接口已经定了、要接进现有系统、团队里有人要 review 产出选 Spec。我最近在一个内部工具项目上把两种模式各跑了一遍同一句需求「做一个带标签过滤的待办列表 API」Plan 模式给我吐了一个能跑但结构随意的 Express 服务Spec 模式则先逼我把 OpenAPI 片段写完再生成结构规整的骨架。返工次数差了一倍多。这篇文章不聊虚的哲学重点是把 Trae 的 settings 改到 TaoToken 统一通道然后用同一需求跑两轮把产出结构和返工记录摆出来让你自己判断什么时候该用哪个。先说清楚一个前提Trae 本身是 AI 原生 IDESOLO 模式是它把「目标输入 → 规划 → 执行 → 验证」串起来的工作流。Plan 和 Spec 不是两个按钮那么简单它们背后对应的是两套 Agent 编排逻辑。Plan 模式里通常有 Planner、Coder、Tester、Debugger 多个角色轮流上模型调用是多轮推理、动态调整计划Spec 模式里则是 Spec Parser、Code Generator、Validator 三个角色单次强约束生成减少自由发挥。理解这一点你就能明白为什么 Spec 模式对「契约不完整」这么敏感——它宁可报错也不猜。那为什么要把 settings 改到 TaoToken因为无论 Plan 还是 Spec底层都要调模型。Trae 默认的模型通道在切换模式、切换项目时容易散Key 和 Base URL 各管各的调试起来很烦。把统一通道配好两种模式共用一套 Key 和 Model ID你才能干净地对比它们的行为差异而不是被通道问题干扰。下面从配置开始一步步来。2. 把 Trae settings 改到 TaoToken 的前置准备与统一通道配置在动 Trae 的 settings 之前先把 TaoToken 这边的 Key 和模型信息拿到手。打开 https://taotoken.net/api-keys 创建一个 API Key复制出来先放一边。注意这个 Key 只在创建时完整显示一次丢了就得重建。然后在模型列表里确认你要用的 Model ID比如做代码生成常用的那几个记下准确的字符串后面填进配置里不能有空格。TaoToken 的 API 入口是 https://taotoken.net/api 这个地址在 Trae 里要作为 Base URL 填进去。如果你用的是兼容 OpenAI 协议的那类配置Base URL 通常要写到 /v1 这一层具体以 Trae 的字段提示为准。我实测下来Trae 的模型设置里一般有三个关键字段Base URL、API Key、Model ID这三件套填对通道就通了。这里有个容易踩的坑Trae 的 settings 可能分「全局模型设置」和「项目级模型设置」两层。如果你只在项目级改了切到另一个项目又回到默认通道Plan 和 Spec 跑出来的结果就没法公平对比。我的做法是先把全局设置改好再确认项目级没有覆盖。改完之后重启一次 Trae让配置生效。配置片段我按 Trae 常见的 settings 结构写一份你可以对照自己的版本调整字段名。JSON 格式如下{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api/v1, apiKey: sk-你的TaoTokenKey, modelId: 你的ModelID, timeout: 120000 }, solo: { defaultMode: plan, enableSpecValidation: true } }如果你的 Trae 版本用的是 TOML 或者图形化设置面板对应关系是一样的baseUrl 填 https://taotoken.net/api/v1 apiKey 填刚创建的 KeymodelId 填模型列表里的准确字符串。填完保存别急着跑 SOLO先做一次连通性验证。验证的方法很简单在 Trae 里随便开一个对话问一句「返回当前模型名称」看它能不能正常回。如果报 401说明 Key 不对或者没带上如果报连接超时检查 Base URL 是不是写成了 https://taotoken.net/api 而漏了 /v1。这一步过了再进 SOLO 模式。顺便说一句如果你打算长期在 Trae 里跑编码和 Agent 任务可以了解一下 Coding Plan它更适合高频调用场景具体在 https://taotoken.net/coding-plan 看。但本文的对比实验用按量 Key 就够了不必先上套餐。3. 可复制的 Trae SOLO 双模式配置Plan 与 Spec 的 settings 片段这一节把 Plan 和 Spec 两种模式在 Trae settings 里的可复制片段写全包括 Base URL、Key、Model ID 三件套以及模式相关的开关。你要做的是把上一节的全局通道固定住然后针对 SOLO 模式做差异化配置。先明确一点Plan 和 Spec 共用同一个模型通道区别在于 SOLO 内部的编排参数。所以 Base URL、API Key、Model ID 这三个字段两种模式完全一致不要给它们配两套 Key否则你没法判断结果差异是模式带来的还是通道带来的。Plan 模式的配置片段重点是放开 AI 的自主规划空间把自动执行和错误自愈打开{ solo: { mode: plan, planner: { enabled: true, maxSteps: 12, allowDynamicReplan: true }, executor: { autoRun: true, autoDebug: true, maxRetry: 3 }, model: { baseUrl: https://taotoken.net/api/v1, apiKey: sk-你的TaoTokenKey, modelId: 你的ModelID } } }Spec 模式的配置片段重点是把契约校验打开让 Validator 在生成后强制检查一致性{ solo: { mode: spec, spec: { format: openapi, strictValidation: true, rejectOnIncomplete: true }, generator: { followSpecOnly: true, allowExtraLogic: false }, model: { baseUrl: https://taotoken.net/api/v1, apiKey: sk-你的TaoTokenKey, modelId: 你的ModelID } } }注意rejectOnIncomplete这个开关Spec 模式下建议设为 true。它的作用是当你的 Spec 缺字段时AI 直接报「Spec 不完整」而不是自己脑补一个字段填上。这正是契约驱动的核心价值——宁可停下来让你补契约也不擅自扩展逻辑。Plan 模式则相反allowDynamicReplan设为 true允许 AI 在执行过程中发现计划不合理就改计划。如果你用的是 Trae 的图形化设置找不到这些字段就在 SOLO 模式面板里找对应的开关Plan 模式找「自动执行」「自动调试」「动态重规划」Spec 模式找「严格校验」「仅按 Spec 生成」。名字可能略有差异逻辑是一样的。配置改完建议把两份 settings 分别存成文件比如trae-plan-settings.json和trae-spec-settings.json切换模式时直接替换避免手改漏字段。这一步做完就可以进入验证环节了。4. 同一需求跑两轮Plan 与 Spec 的验证请求与产出对比验证用的需求我选了一个足够小但又有结构要求的做一个带标签过滤的待办列表 API支持增删改查和按标签筛选。这个需求的好处是Plan 模式可以自由发挥Spec 模式则必须先把接口契约写出来。先跑 Plan 模式。把 settings 切到 plan 配置在 SOLO 的目标输入框里粘贴需求回车。你会看到左侧生成一棵 Plan 步骤树大概长这样初始化项目 → 安装依赖 → 设计数据模型 → 实现路由 → 实现标签过滤 → 写测试 → 运行验证。中部是执行日志能看到 Planner 拆完步骤后Coder 开始逐个实现Tester 跑测试Debugger 在报错时介入。整个过程大概几分钟最后交付一个能跑的项目。Plan 模式的产出结构我记录如下项目根目录下直接是app.js、routes/todos.js、models/todo.js没有分层目录标签过滤逻辑直接写在路由里测试文件只有一个test.js覆盖了主流程。能跑但如果你想接进现有系统得自己重构目录。再跑 Spec 模式。切到 spec 配置这次不能只给一句需求得先写 Spec。我写了一份精简的 OpenAPI 片段openapi: 3.0.0 info: title: Todo API version: 1.0.0 paths: /todos: get: parameters: - name: tag in: query schema: type: string responses: 200: description: 待办列表 post: requestBody: content: application/json: schema: type: object properties: title: type: string tags: type: array items: type: string responses: 201: description: 创建成功把这段 Spec 贴进 Spec 编辑器SOLO 会先做结构化校验高亮缺失字段。确认无误后点生成Validator 会在生成后跑一致性检查底部输出验证报告类似「符合 OpenAPI 3.0 规范」。产出结构是分层的src/controllers/、src/services/、src/models/标签过滤在 service 层测试按接口分文件。两轮跑完返工次数对比很明显Plan 模式我手动改了 3 处目录结构、标签过滤位置、测试覆盖Spec 模式改了 0 处但前提是我花时间把 Spec 写对了。如果你 Spec 写错一个字段类型Validator 会直接报「实现不符」你得回去改 Spec 再生成这是另一种返工。5. 本篇常见错排查401、local proxy failed、reading choices 与 OAuth配置和验证过程中最容易撞上的几类报错我按实际遇到的整理一遍对照着排查。第一类401 Unauthorized。这个基本是 Key 的问题。检查三处Key 有没有复制完整前后不能有空格、Base URL 是不是写成了 https://taotoken.net/api 而漏了 /v1、请求头里有没有正确带上 Authorization。如果 Key 是在别的项目里用过的确认它没被删除或过期。重建一个 Key 再试是最快的定位方法。第二类local proxy failed。这个报错通常出现在 Trae 尝试走本地代理转发请求的时候。先确认你的 Base URL 是直连 https://taotoken.net/api/v1 而不是指向某个本地端口。如果你之前配过本地转发把那段配置清掉。另外检查 Trae 的网络设置里有没有开启系统代理关掉再试。这个错和通道配置强相关Base URL 写对基本就不会出现。第三类reading choices 相关报错比如cannot read property choices of undefined。这是响应结构不符合预期导致的常见原因是 Model ID 填错了或者 Base URL 指向的端点不返回 OpenAI 兼容格式。回到模型列表确认 Model ID 的准确字符串确认 Base URL 是 /v1 结尾的兼容端点。如果还不行用模型对话页面单独测一下这个 Model ID 能不能正常返回排除是模型本身的问题。第四类OAuth 相关报错。如果你在 Trae 里同时开了某个需要 OAuth 登录的插件或账号体系它可能和 API Key 通道冲突。排查方法是先把 OAuth 登录的账号退出只用 Key 通道跑一次。如果正常了说明是两套认证打架后续要么统一用 Key要么在插件设置里关掉自动 OAuth。还有一个隐蔽的坑Trae 的 settings 改了但没生效。这通常是缓存问题重启 Trae 能解决大部分。如果重启还不行检查是不是项目级设置覆盖了全局设置把项目级的模型字段清空让它继承全局。排障时如果拿不准直接去 https://taotoken.net/doc 对照接口文档看请求格式和返回结构比猜快得多。模型行为异常时用 https://taotoken.net/models 单独验证一下能快速区分是通道问题还是模式问题。6. 什么时候用 Plan、什么时候用 Spec把两种协作哲学落到项目里跑完两轮之后我的判断标准变得很具体。Plan 模式适合你只有一个模糊目标、想快速看到能跑的东西、不介意产出结构需要后期整理。它的价值在于「过程可视化」你能看到 AI 怎么拆步骤、怎么调试适合学习和小步验证。Spec 模式适合你已经知道接口长什么样、要接进现有系统、团队里有人要 review 产出。它的价值在于「契约不可变」产出结构规整但前提是你得先把 Spec 写对。一个实用的混合用法是先用 Plan 模式快速生成原型跑通主流程然后从原型里提炼出核心接口写成 Spec再切到 Spec 模式重构生产级代码。这样你既拿到了探索的速度又拿到了交付的可靠性。Trae 同时提供两种模式意义就在这里——它不是让你二选一而是让你在不同阶段用不同工具。最后给一个操作上的建议把两种模式的 settings 都存好切换时直接替换文件别每次手改。统一通道用 TaoToken 的 Key 和 Base URL两种模式共用这样你对比出来的差异才是模式本身的差异。跑之前先做一次连通性验证省得把通道问题误判成模式问题。