TRAE Bot 上手实测：任务级模型固定 DeepSeek-V4.1-Flash，九步流程只留两步工件
TL;DR
- TRAE Bot 是控制最少的一档：不提供模型选择，任务层实测固定
DeepSeek-V4.1-Flash；编排层模型不可见，本文不猜。 - 文档任务翻出
docs/Engineering/与docs/engineering/的大小写目录冲突（39 + 2 个跟踪文件 + 1 个符号链接），结果不错。 - 编码任务默认九步只留第 1、2 步工件，5 次提交直落 master；强制九步后跑 4 轮评审，第 1 轮翻出 2 个阻断级问题，最后仍缺零问题确认。
- 结论：文档、仓库巡检、代码骨架可以用；复杂编码别交给它。免费只覆盖 Bot 任务，飞书 IM 查状态会扣 credits。
背景与问题
我想验证的问题不是「TRAE Bot 能不能写出代码」，而是：当模型选择和流程编排都收归内部，交付结果还剩下多少可审计性？
TRAE 现在有三个入口，我按「控制权让渡程度」排序：
| 入口 | 面向谁与任务 | 留给人的控制 |
|---|---|---|
| TRAE IDE | 技术专家，复杂任务 | 最多：细节逐项可控 |
| TRAE Agent | 领域用户，AI 技术了解有限，仍想管一部分 | 一部分：能选模型、能让提示词规则生效 |
| TRAE Bot | 普通用户，不要求技术背景，简单日常任务 | 最少：说目标、看结果 |
TRAE IDE（控制最多 · 门槛最高） → TRAE Agent（留一部分控制） → TRAE Bot（控制最少 · 门槛最低）
这不是官方划分，是我自己用来决定「该开哪个入口」的心智模型。TRAE Bot 把「用哪个模型」和「按谁的流程走」一起收走，是这一档的产品取舍，不是偶发问题。
运行环境与任务
- 客户端：最新版 TRAE 桌面端，从 TRAE Agent 入口进入 TRAE Bot。
- 入口形态：限免弹窗「TRAE Bot: Limited-time Free for All」，按钮 Try Free Now。
- 任务层模型：两次任务均为
DeepSeek-V4.1-Flash（输入框右下角显示）。 - 文档任务：
Docs sync: CeXia + LianXia。 - 编码任务：
SenBox TODO-005 task-implementer。 - 权限档位：输入框左下角
Full Access。
入口与免费边界
我之前写过 xWork 的复盘，因为它容易跑到沙箱之外，所以一直只用 IDE；这次是为了试新功能才破例，从 TRAE Agent 入口用上了新的 TRAE Bot。
据公开介绍，中文界面叫「TRAE 宝」，是面向开发者的个人助理，分全局助理与项目助理两层，能跨项目读历史任务、对话与产物；工牌下方还有 IM 连接入口，可以按需绑定。
免费边界要说清楚：限免只覆盖 Bot 任务——派一条任务、它跑完交付，这条路径免费。IM 连接可以用，但不免费：绑定飞书之后，在聊天里问一句「当前任务什么状态」，这种对话式调用会扣 credits。我这次两次查询分别扣了 8.32 和 0.58 credits，同一天的 Bot 任务记录则都是 Free 0：
所以更准确的说法是「Bot 任务免费」，不是「整个 Bot 免费」。
任务 A：文档巡检翻出大小写目录冲突
文档任务的价值不在生成文字，而在它愿意把整个仓库翻一遍。它发现仓库里同时存在两个只差首字母大小写的目录：docs/Engineering/ 跟踪 39 个文件，docs/engineering/ 2 个文件加一个符号链接。
为什么本地看不见？因为日常开发环境大多大小写不敏感：
- Git 大小写敏感：两个目录在仓库里是两条完全不同的路径，两套文件都存着；GitHub 后端也大小写敏感，网页上能同时看到两个文件夹。
- Windows NTFS 与 macOS 默认 APFS 大小写不敏感（但保留大小写）：系统眼里它们是同一个文件夹，checkout 时内容被合并进一个目录，Finder / 资源管理器里只看到一个。
- Linux（ext4 等）大小写敏感：CI runner 上会真的生成两个并列目录，原先那个符号链接的指向就可能对不上，变成悬空链接。
这是一个典型的「只在大小写敏感的 Linux / CI checkout 上才暴露」的问题。修法是用 git mv 重命名再修正符号链接；但它会碰到 39 个已跟踪路径，必须人工点头。Bot 没擅自动手，而是把问题和建议摆出来等确认。
这类任务真正值钱的地方，是把「文件系统语义差异」这种没人会主动去查的边角问题，翻译成一句人能看懂的风险提示。
任务 B：模型栏固定 DeepSeek-V4.1-Flash
为了不被打断地把结果做出来，它把「用什么做」也收走了。TRAE Bot 没有选模型的入口，只能看到当前任务正在用哪个。
模型名不直接显示在任务卡片上。Bot 的聊天窗口里先看到的是一张张任务卡片：
双击卡片进入该任务的聊天窗口，输入框右下角才会显示这条任务实际使用的模型。TRAE Bot 这一档不提供模型选择，这个位置只用于显示；旁边虽然有个下拉箭头，但没有可切换的模型。我这两个任务，不管编码还是文档，那个框里都是 DeepSeek-V4.1-Flash，一次都没换过：
需要说明的是，这个位置标的是任务级（task）的 AI 模型。至于 Bot 编排层（Bot Orchestration）用什么模型来做拆解、派发与调度，界面上看不到，我们并不知道。所以这里说的「恒为 DeepSeek-V4.1-Flash」，指的都是任务层。
想锁定模型也不在 Bot 里：公开资料里能看到，TRAE 的 Auto 模式会按任务自动调度模型并覆盖手动选择，真要指定模型，通常得关掉 Auto、回到可选模型的 TRAE Agent，或改用自定义智能体。
所以「模型不给选」更准确的版本是：任务层默认钉在 DeepSeek-V4.1-Flash 上，不打算让你为选模型分心。 对习惯自己调参的技术专家，这正是三档里最需要适应的地方。
另外，左下角的 Full Access 权限档位也值得留神。
流程审计：默认九步只剩两步
我让它按九步工作流执行，它走了自己的路。事后的审计把这一点说得很直白：只有第 1、2 步留下了痕迹，第 3、5、6、7、8、9 步没有任何工件；git 里只有 master、一个工作树，五次提交直接落在默认分支上，没有分支、没有 PR、没有独立评审，也没有逐阶段小结与清理门禁。
对照 TRAE Agent 那一档会遵循提示词规范，这个反差更明显：结果交出来了，过程却没法复查。对文档类任务这也许可以接受，对要进主分支的代码，这就是缺口。
这不是「能力不够」，而是目标不同——它优化的是「不被打断地把结果做出来」，不是「按你规定的路径把过程留下来」。
强制九步：四轮评审仍缺最后一签
我后来强制它必须按九步走，它照做了。第 5 步的独立子代理代码评审确实揪出了几个关键缺陷，还找出一处被漏掉的功能实现。但事后把这个编码任务通盘看一遍，结论只能算 just so so：「全部做完」并不等于「没有问题」，问题是一路冒出来的，第 1 轮就翻出 2 个阻断级问题。
留痕显示一共跑了四轮独立评审：第 1 轮 2 个阻断项、4 个重要项、4 个次要项全部修掉，第 2 轮又清掉 4 个重要项与 3 个次要项，第 3 轮的 2 个次要项按外观性问题接受，第 4 轮由 CI 触发又补掉 1 个阻断项。
更值得注意的是：第 4 轮修完后没有再跑「零问题」确认评审就直接发版；那次修复靠 CI 全绿和 macOS 二进制运行检查，不是独立评审签字。所以「无遗留问题」只在第 3 轮成立，最终状态只到「可修即修 + 发布验证通过」。
流程确实把关键缺陷挖出来了，但一个需要四轮评审、最后还缺一轮确认签字就发版的实现，谈不上让人放心。同一个 Bot，流程强制与否有明显差别，但差别有上限。把「愿望」改成「约束」的最小写法是：
愿望：请用我的九步工作流执行这个任务。
约束：严格按九步执行；每步必须产出可核对的工件，缺一步
即视为未完成并回到该步重做；第 5 步必须由独立子代理
评审，改码之后重新评审。
两条交付路径的差别：
默认：目标 → Auto 路由 → 内部规则/技能/工具 → 直接交付
（无分支、无 PR、无评审留痕）
强制：目标 → ①读上下文 ②写计划 ③隔离实现 ④自验证
→ ⑤独立子代理评审 ⑥唯一摘要 ⑦推分支开 PR
→ ⑧更新状态 ⑨清理核对 → 留痕交付（收尾仍需人工）
四种用法对比
| 方式 | 模型 | 人工介入 | 流程 | 适合 |
|---|---|---|---|---|
| TRAE IDE（侧边对话，关掉 Auto） | 手动可选 | 每步可控 | 听提示词 | 小改、答疑、调研 |
| TRAE Agent（原 TRAE Work） | 可选模型 | 留有交互点 | 遵循提示词规范 | 领域用户想留一部分控制 |
| TRAE Bot 默认 | Auto（任务层实测 DeepSeek-V4.1-Flash） | 几乎为零 | 内部 harness 规则 | 一次性文档、探索型任务 |
| TRAE Bot ＋ 强制流程 | Auto（任务层实测 DeepSeek-V4.1-Flash） | 少 | 按编号步骤留痕 | 需要留痕的代码任务，收尾仍需人工 |
把中间两行并排看，差别就很清楚：TRAE Agent 那一档把模型选择和提示词规范都留给人，Bot 默认态则把这两样连同交互点一起收走，换成内部 harness 规则。表里「模型」一栏说的都是任务层；Bot 编排层用什么模型，界面上看不到，这里不做猜测。
所以选型问题很简单：你要的是一次干净的交付，还是一条能被复查的交付路径？
生产落地建议
这次之后，我给自己定了四条不变式：
- 结果好看不等于过程合规——数工件，不看汇报。
- 模型选择和流程编排是两件事，Auto 更稳也不代表流程可以一起交。
- 任何进默认分支的改动，改完必须再跑一轮「零问题」评审；CI 全绿不算签字。
- 复杂编码实现不交给控制最少的这一档；最多让它写骨架。
不该用它的场景：
- 复杂的编码实现；写写代码骨架可以。
- 技术专家、复杂工程、需要逐项控制细节——回 TRAE IDE。
- 任务要落到默认分支、开 PR、留下可审计记录，而流程还没强制回去。
- 需要锁定某个模型做对比测试、复现实验或成本评估。
- 团队规范只写在提示词里，没有脚本或工件去校验。
- 对沙箱边界有顾虑，却想因为「限免」放宽权限范围。
- 把限免当无限额度——IM 对话式查询会扣 credits。
- 验收标准只有「看起来完成了」，没有可核对的产物清单。
结果与数字
| 场景 | 结果 | 关键数字 |
|---|---|---|
| 文档任务 | 不错，翻出大小写目录冲突 | 39 + 2 个跟踪文件，1 个符号链接；修复触及 39 个路径 |
| 编码任务（默认路径） | just so so | 9 步只留 2 步工件；5 次提交直落 master，无分支、无 PR、无独立评审 |
| 编码任务（强制九步） | 可用，但收尾未兜住 | 4 轮评审；首轮 2 个阻断 / 4 个重要 / 4 个次要全修；第 4 轮后缺一轮「零问题」确认 |
三个后续信号仍值得记：同一任务在默认与强制路径下的返工次数；每次交付的「被跳过步骤数 / 应执行步骤数」；以及交付后仍被翻出的阻断级问题数。最后一个数字不降到 0，复杂编码就不该放手。
写在最后
TRAE Bot 在简单任务上的「说目标 → 拿结果」确实顺滑，文档任务的仓库巡检甚至给了我一个本地永远看不到的信号。但复杂编码不是它的战场：流程能救回一部分，救不了最后那道人工签字。
你会在什么任务上接受「结果没问题但过程不可复查」？ 评论区聊聊。
