31 · 常见反模式

掉过这些坑，才叫真正用过 Trae。八个最常见的使用误区，以及如何绕开它们。

01 · 总览：反模式是什么？

反模式（Anti-Pattern）指的是那些看起来合理、但实际上会带来长期负面后果的做法。初看它们像是捷径——“让 AI 一口气把整个项目写完多快”——但很快你就会发现代码不可维护、需求对不上、改不动，最终时间反而花得更多。

Trae 是一个强大的 AI 编码工具，但正因为它强大，误用的代价也更高。本文整理了我们在社区和内部实践中见过的 八大反模式，按照从理念到实操的顺序逐一拆解：

每个反模式都包含：症状 -> 后果 -> 根治方案。你可以按顺序通读，也可以直接跳到最触动你的那一条。

02 · 反模式一：SOLO 过载 — 把整个项目塞进一个 SOLO 任务

症状

你在 Trae 中创建了一个 SOLO 任务，prompt 写道：

“帮我开发一个电商后台系统，包含用户管理、商品管理、订单管理、支付对接、数据看板，还有权限控制。使用 React + Node.js + PostgreSQL。”

然后点击执行，等待 AI 输出结果。

问题在哪

SOLO 的设计初衷是 精确、聚焦、可验证。它擅长在 30 分钟内完成一个有明确边界的编码任务——比如”实现用户列表页面的筛选功能”或”重构订单模块的类型定义”。它不擅长接手一个需要数十个文件、涉及多层架构、隐含大量设计决策的大型项目。

当你把整个项目描述塞进一个 SOLO 任务时，会发生几个连锁问题：

1. 上下文溢出 — SOLO 会尽力在上下文窗口中容纳你的需求，但它无法真实理解一个电商系统背后错综复杂的业务规则。它生成的代码看起来很完整，但细节处全是空洞——表结构没有索引、支付回调没做幂等、权限校验流于形式。
2. 无法迭代修正 — 如果第一次输出有 30% 不符合预期，你只能手动修改或重新提交整个需求。你失去了逐步引导 AI 的机会。
3. 验证失效 — SOLO 的自我验证机制建立在”任务边界清晰”的前提上。一个模糊的大任务，AI 自己都不知道什么算”完成”，验证也就形同虚设。

根治方案

把大任务拆成 Chat → Builder → 多个 SOLO 的递进链条：

电商项目（大）
 ├─ Chat 讨论 → 确定技术栈、目录结构、路由设计
 ├─ Builder → 生成项目骨架、数据库 Schema、API 路由
 ├─ SOLO 1 → 用户模块：注册、登录、权限中间件
 ├─ SOLO 2 → 商品模块：CRUD、图片上传、搜索
 ├─ SOLO 3 → 订单模块：创建、支付集成、状态机
 └─ SOLO 4 → 数据看板：图表组件、API 聚合

判断准则：如果 SOLO prompt 超过 300 字，或者你发现自己写了超过 5 个需求点，说明这个任务太大了。先退回到 Chat 做分解。

03 · 反模式二：不审查 SOLO 产物 — 生成即合并

症状

SOLO 任务跑完了，输出看起来不错——通过了自我验证，没有报错。你直接点了”应用所有变更”，把它合并进代码库。整个过程不到 30 秒。

问题在哪

SOLO 的自我验证机制检查的是技术正确性——代码能否编译、测试能否通过、边界值是否处理。但它不知道你的业务意图。

真实案例：一个团队用 SOLO 生成用户导出功能。SOLO 生成的 CSV 导出逻辑完全正确——文件格式规范、编码无误、大文件流式处理也到位。但导出字段少了一个非常重要的业务字段”用户来源渠道”。因为这个字段不在数据库主表中，SOLO 没有上下文去推断它的存在。

更隐蔽的问题：

根治方案

建立一个 “四步审查” 流程：

1. 读 diff — 打开变更文件列表，逐个文件看改动。不需要读每一行代码，但要理解每个文件为什么被改。
2. 看测试 — SOLO 生成的测试覆盖了哪些场景？边缘情况呢？如果 SOLO 只生了成测试骨架（it.todo），你需要补全。
3. 问自己 — “这个实现与我想的完全一致吗？有没有哪个细节让我觉得不对劲？” 相信你的直觉。
4. 集成运行 — 在本地把修改跑起来，验证功能。不要只看代码就合并。

时间预期：审查一个 SOLO 任务的时间，应该大约是它生成时间的 30%50%。生成用了 10 分钟，审查 35 分钟是合理的。如果审查只用了 10 秒，你很可能跳过了关键步骤。

04 · 反模式三：模式错配 — 用 Chat 写大功能，拿 Builder 改生产代码

症状

这是最普遍的误用。两种典型表现：

• Chat 写大功能：你打开 Chat 窗口，说”帮我在支付模块加一个退款功能”，然后在 Chat 里来回十几轮对话，不断修正 AI 生成的代码。最后一团混乱——代码散落在对话中的多个代码块里，手动复制粘贴时漏了一半。
• Builder 改生产代码：你把 Builder 指向一个已经在生产环境跑了半年的代码库，让它”帮我优化一下性能”。Builder 重新生成了整个模块——新的文件结构、新的命名约定、新的数据流——把现有代码完全覆盖了。

为什么这是反模式

每种模式的设计目标不同：

Chat 的输出是对话式的，代码片段散落在聊天记录中。用它来完成一个完整功能，你最后的手动整合工作可能比从头写还累。

Builder 是面向生成而非面向修改的工具。它在拿到空目录或最小骨架时表现最好。一旦代码库已经有了生产代码，Builder 没有”保持现有代码不变”的意识——它可能重写你不想动的东西。

根治方案

三个简单的判断规则：

1. 如果需求可以一句话说清楚，而且只需要改动 1-2 个文件 → SOLO
2. 如果需求还在讨论阶段，需要反复试探方案 → Chat（记录结论后用 SOLO 执行）
3. 如果是一个新模块、新页面、新服务，从零开始 → Builder（生成骨架后交 SOLO 精修）

紧急修正：如果你已经在 Chat 里写了 5 轮以上还在生成代码——停。把 Chat 中讨论确定的方案复制出来，创建一个 SOLO 任务来执行它。Chat 负责”想清楚”，SOLO 负责”写干净”。

05 · 反模式四：忽视 .trae/rules — 规则文件形同虚设

症状

你的项目中有 .trae/rules 文件，但它是：

• 空的
• 只有一句”请写出高质量的代码”
• 是三个月前创建的，团队已经换过两轮技术栈了
• 没人知道它存在

结果就是：每次 SOLO 或 Builder 生成的代码风格都不一样——这个文件的缩进用 2 空格，那个用 4 空格；这个用 const，那个用 function；命名规范在这模块是 camelCase，在另一个模块是 PascalCase。

问题在哪

.trae/rules 是 Trae 理解你项目上下文的核心入口。它不只是一个风格配置文件——它是你告诉 AI “我们这个项目是怎么运作的”的声明文档。

AI 不会默认知道你的项目：

• 用了什么技术栈和版本
• 目录结构遵循什么约定
• 测试策略是什么（单元测试 vs 集成测试 vs E2E）
• API 错误处理用哪种格式
• 组件库和设计系统是什么
• 数据库迁移策略
• 代码审查的标准

没有规则文件，AI 在黑暗中猜测。它可能猜对大部分，但那些偶尔猜错的地方——正是你最头疼的 bug 来源。

根治方案

建立 三层规则体系：

.trae/rules/
 ├─ 00-global.md    ← 全局约定：编码风格、命名规范、注释要求
 ├─ 10-tech-stack.md ← 技术栈声明：框架版本、包管理器、构建工具
 └─ 20-architecture.md ← 架构约定：目录结构、数据流模式、API 设计规范

一个有效的 00-global.md 示例：

# 项目全局规则
 
- 语言：TypeScript (strict mode)
- 包管理器：pnpm
- 测试框架：Vitest + Testing Library
- 命名规范：文件名 kebab-case，组件名 PascalCase，函数名 camelCase
- 组件模式：函数式组件 + Hooks，禁止 class component
- CSS 方案：Tailwind CSS，所有样式写在内联 class 中
- 错误处理：统一使用 AppError 类，在 api 层捕获
- 提交规范：Conventional Commits（feat/fix/chore/docs）

时机：在新项目的第一天就创建 .trae/rules。如果是现有项目，花 30 分钟整理一份，然后告诉 Trae 重新加载规则。

06 · 反模式五：提示词模糊 — “帮我做一个登录页面”

症状

你在 Chat 或 SOLO 中写了一个二三十字的 prompt：

• “帮我做一个登录页面”
• “把这个列表改成卡片视图”
• “加一个搜索功能”
• “优化性能”

然后 AI 给了你一个通用方案——一个带用户名和密码输入框的简单表单，没有验证码、没有社交登录、没有错误状态处理、没有忘记密码链接。你开始在一轮又一轮的对话中补充细节：“再加一个记住我功能""表单验证呢""密码强度提示呢”……

为什么这是反模式

AI 不是读心者。你的模糊需求给它留下了过多的自由空间，而它的选择几乎一定不是你想要的。

你把认知负荷从”写代码”转移到了”纠错”上。原本可以一次性描述清楚的需求，变成了 8 轮对话 + 6 次手动修复。总时间可能是清晰提示的 3 倍。

而且模糊提示产生的代码往往是”最通用”的——也就是最平庸的。它不会使用你项目的设计系统，不会遵守你的约定，不会考虑你的业务特殊性。

根治方案

用”STAR 框架”写提示词：

反例 → 正面对比：

❌ "帮我做一个登录页面"

✅ "在 /pages/login 下创建登录页面组件：
   - 邮箱 + 密码 + 记住我（checkbox）三个字段
   - 表单验证：邮箱格式、密码最少 8 位
   - 调用 /api/auth/login 接口
   - 成功时跳转到 /dashboard，失败时显示错误提示
   - 使用项目现有的 Button、Input、Card 组件
   - 移动端适配
   - 添加 Cypress E2E 测试覆盖成功和失败场景"

经验法则：写 prompt 的时间应该是你预估 AI 执行时间的 10%。一个 10 分钟的 SOLO 任务，花 1 分钟写好 prompt 是值得的。节省的是后面 3 轮修正的 20 分钟。

07 · 反模式六：不利用免费模型 — 所有任务都用付费模型

症状

你在 Trae 的模型选择器中，每次都选最贵的模型。不管任务大小——写一个简单的工具函数、解释一段错误日志、代码格式化——全走顶级模型。

问题在哪

Trae 在开发机上提供免费模型，其能力足以胜任大量日常开发任务。全部任务走付费模型有几个隐形成本：

1. 速度降低 — 付费模型随着并发用户增加，响应时间可能更长。简单任务用免费模型几乎即时响应。
2. 唤醒成本 — 付费模型有唤醒等待时间。如果你一整天频繁发送 prompt，这些等待时间累计起来很可观。
3. 不必要的算力消耗 — 大模型在做”将驼峰命名改为下划线命名”这种任务时，99% 的神经元都是闲置的。杀鸡用牛刀。

任务分层模型

一句话原则：需要深度推理和复杂代码生成时用付费模型；结果可以预判、任务边界清晰的日常操作，把免费模型用起来。

08 · 反模式七：无脑信任 — AI 生成什么就合并什么

症状

AI 生成了代码，通过了编译，测试跑过了——完美，合并吧。几周后，你发现：

• 某段生成的代码引入了 Node.js 内置但浏览器端没有的 API，前端打包直接炸了
• AI 用了 一个人的开源库，这个库有已知的安全漏洞
• 生成的 API 路由没有做速率限制，上线后被爬虫扫爆了
• AI 把 硬编码的 API Key 写进了代码（虽然它 usually 会加个 TODO 注释提醒你）

为什么这是反模式

AI 模型是被训练来”看起来正确”的，而不是”实际上正确”的。它们擅长生成语法正确的代码，但在以下方面有系统性弱点：

根治方案

信任但验证（Trust but Verify） 模型：

AI 输出
  ↓
编译 / 类型检查（工具自动）
  ↓
单元测试 / 集成测试（工具自动）
  ↓
安全审查（人工重点 — 检查：依赖、权限、密钥、SQL、XSS）
  ↓
业务逻辑审查（人工重点 — 问：这是我们要的吗？）
  ↓
集成测试 / 手动验证（人工 + 工具）
  ↓
合并

关键的安全清单（每次 AI 生成代码后必须检查的项目）：

• 新增的依赖项是否可信？版本是否锁定？
• 是否有任何 API Key、Token、密码硬编码？
• 用户输入是否经过验证和清理？
• 文件操作是否有路径遍历风险？
• 错误信息是否泄露了内部实现细节？

核心理念：AI 是你的高级初级工程师——思路很好，速度极快，但你不能让它在没有 review 的情况下直接部署到生产环境。

09 · 反模式八：巨型提交 — 一天的工作一个 commit

症状

晚上 11 点，你准备提交一天的工作。git diff --stat 显示：

18 files changed, 3407 insertions(+), 892 deletions(-)

commit message 是：“更新了一些功能”。

问题在哪

巨型提交（Mega-commit）是代码库健康的慢性杀手。它直接造成了以下问题：

1. 审查困难 — 没有人能在一次审查中理解 3400 行变更。审查者要么囫囵吞枣地通过，要么要求你拆开——无论哪种，都没有达到代码审查的目的。
2. 回滚恐惧 — 如果其中一个变更导致了生产问题，你无法只回滚那一个变更。要么全回滚（丢失好的变更），要么硬着头皮修（累积技术债）。
3. 归因模糊 — git blame 变成了一团迷雾。三个月后，没人知道某行代码为什么存在——是 AI 生成的、是重构搬过来的、是修复某个 bug 加上的？无从判断。
4. SOLO 的天然敌人 — SOLO 的精髓是”小的、聚焦的、可验证的”。如果你把多个 SOLO 任务的输出合并为一个 commit，你就失去了 SOLO 的最大优势——每个 SOLO 任务本应是一个独立的、可追溯的变更。

根治方案

每个 SOLO 任务一个 commit，遵循 Conventional Commits：

feat(orders): 添加订单导出 CSV 功能
 ^    ^          ^
 │    │          └─ 具体描述（完成时态）
 │    └─ 模块/范围
 └─ 类型：feat / fix / refactor / chore / docs / test

一个良好的 commit 应该是：

• 原子性：只做一件事
• 可审查性：最好不超过 300 行变更
• 可回滚：如果这个 commit 有问题，回滚它不会丢失其他好的变更
• 可搜索：message 能让三个月后的你理解当时为什么改

与 Trae 的结合方式：

SOLO 任务 1: "添加 CSV 导出按钮和下载逻辑" → commit: feat(orders): 添加 CSV 导出入口
SOLO 任务 2: "实现后台导出任务队列"         → commit: feat(orders): 实现异步导出任务队列
SOLO 任务 3: "添加导出权限控制"              → commit: feat(orders): 为导出功能添加权限校验

这样，每个 SOLO 任务的产物都对应一个清晰的、可回溯的 commit。审查时逐 commit 看，逻辑清晰。有问题时只回滚那一个 commit。

怎么对付”今天来不及拆分了”：用 git add --patch 在提交前做一次人工拆分。花 5 分钟把变更按逻辑分组，分别提交。这 5 分钟会在未来队友（或未来的你）追查 bug 时节省 50 分钟。

10 · 小结与对照表

八大反模式速查

核心心智模型：AI 编码的黄金三角

       需求清晰度
          ↑
          │
   模糊 ──┼── 精确
          │
          └─────────→ 任务粒度
        小 ←───────→ 大

• 右上角（需求清晰 + 任务小）→ SOLO，最佳场景
• 左上角（需求模糊 + 任务小）→ Chat，快速探讨
• 右下角（需求清晰 + 任务大）→ Builder，从零生成
• 左下角（需求模糊 + 任务大）→ 先 Chat 拆解，不要直接让 AI 生成

AI 本身能力再强也架不住用错方法。多数”AI 不行”的结论，其实是使用模式有误。

11 · 实践清单

下次使用 Trae 时，跑一遍这个清单：

• 我的 prompt 是否超过 300 字？→ 拆成多个 SOLO
• 我选的模式是否匹配任务类型？
• .trae/rules 有没有针对这个任务的规则？
• prompt 是否包含 S（上下文）T（任务）A（方案）R（输出）？
• 这个任务用免费模型够不够？
• 我准备花多长时间审查 AI 的产出？
• 生成结果中有没有新增依赖、硬编码密钥、用户输入未过滤？
• 这个变更是否应该独立成一个 commit？

全部打勾？好，开始工作。

12 · 总结

Trae 不会因为模型强大就自动产出好代码——好的产出来自好的使用习惯。八个反模式看似分散，背后只有一条主线：

把 AI 当工具，不是当替身。工具的使用方法决定了产出质量。

• SOLO 要小，review 要细
• 选对模式比选对模型更重要
• 规则文件是 AI 读懂你项目的眼镜
• 好的 prompt 省去三轮回合
• 免费模型有它的位置
• 永远验证 AI 的输出
• 让 commit 历史成为文档，而不是垃圾堆

如果你发现自己正在做上面任何一条反模式的事，没关系——第一步是意识到它。下一步是改。

下一篇

30 · 项目迁移与适配 — 将现有项目迁入 Trae 工作流的最佳实践。