不止于编码
让 AI 贯穿构建全流程

TRAE 使用教程：从创建到迭代的最佳实践

许多开发者初次接触 TRAE 时，容易把它当作一个带聊天窗口的编辑器。实际上，TRAE 的设计哲学是让 AI 成为开发流程的协作者，而非被动的问答机器。要发挥它的真正效能，关键在于理解几个核心机制之间的配合关系，并建立起适合自己的迭代节奏。

一、项目初始化：先定规则，再写代码

在创建任何文件之前，花五分钟配置项目规则，是后续一切高效协作的基础。TRAE 的 Rules 系统允许你将技术栈偏好、代码风格、甚至业务约束以 Markdown 形式固化下来。

在项目根目录创建 .trae/rules/project_rules.md，写入类似内容：

当 alwaysApply: true 生效后，Agent 在每一次生成或修改代码时都会自动参照这些约束。相比每次对话重复交代要求，规则文件让 AI 的行为具备了可预期的一致性。

二、Agent 与 Chat 的分工：把任务交给对的人

IDE 模式下的 AI 面板提供两种内置智能体，它们的主动性差异决定了适用场景截然不同。

Chat 适合“问”：解释一段陌生的代码、询问某个 API 的用法、或者快速生成一个小片段。它不会主动修改文件，你完全掌控下一步。

Agent 适合“做”：当你需要跨文件重构、实现一个完整功能、或者修复一个涉及多处改动的 Bug 时，选中 Agent 并给出明确指令。它会自主读取相关文件、执行编辑、甚至调用终端命令验证结果。

一个常见的失误是：用 Chat 去完成本该 Agent 做的多文件任务，结果得到一堆需要手动粘贴的代码块。判断标准很简单——**如果任务需要改动超过一个文件，或者需要理解文件之间的关联，就交给 Agent**。

三、SOLO 模式的正确打开方式

SOLO 是 TRAE 中最具“放手”意味的模式。你描述需求，AI 自主规划步骤、创建文件、安装依赖、运行测试，直到交付可验收的结果。但它并非万能，用对场景才能体现价值。

SOLO 最适合的场景是：从零搭建原型、按明确规格实现独立模块、以及执行机械性的重复修改。例如，你可以说：“参照 src/pages/user/ 的写法，新建一个订单列表页，包含筛选、分页和导出功能。” SOLO 会自行读取参照文件、理解项目结构、然后生成完整的页面代码。

需要注意的是，SOLO 的执行结果需要你进行验收。建议在启动前先确保项目有可运行的基线版本，这样一旦生成结果不符合预期，可以方便地回退或对比。

四、迭代的节奏：小步验证，而非一次到位

AI 生成的代码质量与任务描述的粒度直接相关。一个常见的反模式是：一次性给 Agent 一个庞大而模糊的需求，然后期望它输出完美结果。更有效的做法是拆解为可验证的小步骤。

例如，不要直接说“实现用户管理系统”。可以拆为：

• 第一步：创建 User 模型和数据库迁移
• 第二步：实现列表接口与分页查询
• 第三步：添加创建/编辑表单页面
• 第四步：接入权限校验

每完成一步，运行一次或检查一次 diff，确认无误后再进入下一步。TRAE 的 Agent 支持在对话中携带上下文，你可以在同一条会话中连续发出指令，它会记住之前的修改轨迹。这种“小步快跑”的方式，远比一次生成数千行代码后再调试要高效。

五、善用上下文引用与外部工具

TRAE 的输入框支持 @ 引用文件、文件夹或联网搜索。当你提出一个涉及特定模块的问题时，用 @ 精确指向相关文件，比让 AI 自行猜测要准确得多。

此外，通过 MCP 协议接入外部工具（如数据库客户端、API 调试工具），可以让 Agent 在任务中直接调用这些能力。例如，接入一个数据库 MCP 后，你可以让 Agent 直接查询表结构来生成对应的 TypeScript 类型定义，省去手动对照的环节。

结语

TRAE 的效能不取决于你按了多少次“生成”，而取决于你是否建立了一套与 AI 协作的节奏：用 Rules 定下基调，用 Chat 快速获取信息，用 Agent 执行具体改动，用 SOLO 推进独立任务，并在每一步保持验证的习惯。这套流程一旦形成，AI 才真正从一个“工具”变成了工作流中自然的一部分。