6.1 认识 Trae 与代码审查方式

第五章的博客已经能够运行，第六章继续在它的基础上增加功能。这里选择 Trae 演示如何阅读已有项目、审查文件修改和验证改造结果。界面与套餐会随版本变化，学习重点放在这些能够迁移到其他工具的工作方法上。

---

先确认工具适合当前任务

本章使用 Trae演示已有项目改造，重点是目录浏览、修改审查、运行测试和浏览器检查。可以把这些能力看成工作台上的不同工具：是否顺手，要通过一次实际修改判断。

1. 使用前检查

项目	要确认的内容
产品版本	当前使用的地区版本与客户端类型
模型可用性	当前账号能选择哪些模型
用量	任务消耗如何统计，是否有上限
工作目录	任务在哪台设备、哪个目录执行
修改审查	能否查看差异、保留或撤销修改

本节不把限时优惠写成学习前提。免费额度、折扣和套餐内容应在 Trae 官网或国内官网查看当前说明；先完成一项小任务，再判断是否需要更多用量。

2. 终端与编辑器怎样选择

终端适合熟悉命令、需要远程操作或串联脚本的场景；图形编辑器适合边读文件边审查修改。两者都可以配合版本控制和测试，没有“用了 IDE 就自动更可靠”的结论。本章选择编辑器，是为了把已有项目的变化展示得更直观。

Trae 的双模引擎（Work vs. Code）

Trae 的不同入口面向不同任务：代码工作区用于编辑和审查项目，其他工作区侧重通用任务或设计相关流程。具体入口和开放范围可能随版本变化，应以当前客户端与官方说明为准。

• Trae Work：侧重通用任务、跨应用操作和任务调度，可用能力取决于当前版本、设备和授权范围。
• Trae Code：面向代码项目的集成开发环境，提供代码编辑、目录浏览、扩展和 AI 协作能力；
  • 界面左侧是完整的文件目录树，中间是代码编辑器与实时预览，右侧是 AI Agent 智能助手；
  • 修改完成后可以逐行查看代码差异，也可以按文件保留或撤销。撤销前仍要检查其他文件是否依赖这项修改。

---

Trae Work 的功能范围

不同入口的适用范围

下文结合案例截图介绍工作台、代码编辑和远程操作入口。入口名称与开放范围可能随版本变化；以当前客户端显示为准。后续博客实战主要使用代码工作区，不依赖远程或移动端功能。

1. 主工作台与多场景切换

在主界面顶部，提供了 Work、</> Code 和 Design 三大核心工作区切换，支持自然语言对话、代码生成、多模态图片识别以及语音输入：

• 应用开发 / 项目理解 / 游戏创意 / 工具脚本：快捷标签提供相应的任务入口或提示模板；
• 智能模型中枢：原生接入多款主流大模型（国内版内置豆包 Doubao、DeepSeek、Kimi、通义千问、GLM 等，国际版另有 Claude / GPT 可选），可用模型以当前账号显示为准。

2. 模型管理与能力外挂中心

进入设置面板中的 “模型” 与能力选项，我们可以直观地配置与扩展 Trae 的大脑与外挂工具：

• 多模型灵活接入：支持火山引擎预置模型（豆包 Seed 系列等），同时允许开发者通过 + 添加模型 自由接入自己的 API Key；
• 丰富的能力侧边栏：内置 MCP 协议、对话流、外部应用授权、浏览器操作、电脑控制、云端运行环境 与 规则与记忆 模块，具体可调用范围取决于连接与权限配置。

3. 移动端与远程任务

如果当前版本提供移动端或远程任务功能，可以在确认设备授权和运行环境后使用：

• 📲 扫码下载 TRAE 移动端：在手机上登录相同账号，授权开启“允许 TRAE 移动端控制当前设备”；
• ☕ 保持电脑唤醒（Keep-Awake）：打开该开关后，Trae 运行期间会自动防止操作系统进入睡眠，确保耗时较长的重构、打包或自动化测试任务持续稳定推进；
• 远程发起任务：可以从移动端提交任务并查看进度。涉及文件修改和命令执行时，仍应检查目标设备、权限与最终差异。

📌 本章范围：后续案例主要使用 Trae Code 阅读和修改博客项目，Trae Work 的通用任务能力不在本章展开。

---

Trae Code：编辑、审查与运行项目

对于严肃的软件工程与日常编码开发，我们点击左上角的 </> Code 即可瞬间切入 Trae Code 专业编程模式：

1. 编辑器布局与迁移检查

• 迁移检查：界面和操作方式与 VS Code 类编辑器接近。快捷键、主题和扩展是否可用，应在当前版本中逐项确认；
• 经典三栏布局：
  • 左侧：项目资源管理器（工作区文件树、大纲、时间线）；
  • 中间：多标签代码编辑器，支持 Markdown 实时双栏预览与语法高亮；
  • 右侧：TRAE Agent 专属智能体协作交互抽屉，随时向 AI 发出指令。

2. 图形编辑器怎样帮助审查

图形编辑器把文件树、代码和修改差异放在同一界面中，适合逐项检查多文件任务：

1. 可视化代码审查（Visual Diff Review）：AI 生成的修改会以高亮红绿色彩块直接呈现在编辑器中，增删变动一清二楚；
2. 细粒度单文件撤销（Granular Revert）：
   • 设想一个真实场景：你让 AI 重构用户认证模块，AI 一口气改动了 12 个文件；
   • 审查后发现，其中 2 个文件的路由逻辑偏离需求；
   • 可以针对这 2 个文件撤销或继续修改，但要先检查其余文件是否调用了新接口或新字段。

3. CUE 智能补全：仓库级“编辑序列预测”

Trae Code 原生内置了新一代代码补全引擎 CUE，它比传统“猜下一行”的 Tab 补全强大得多：

• 仓库级上下文感知：CUE 不只是看你光标前后的几行，而是理解整个代码仓库中函数、变量与调用关系的编辑模式；
• 编辑序列预测：能够预测你接下来会做的一连串修改（例如你刚给某个函数加了参数，CUE 会预判你可能还要修改它的调用点、测试用例与文档），按 Tab 即可一键跳转采纳；
• 链式补全与多行修改：可完成多行补全、修改点建议、导入和重命名；实际效果应在当前语言和项目中验证。

CUE 的重点是根据当前修改建议后续关联位置。建议出现后仍要确认调用点、测试和文档是否确实需要同步修改。

4. 内置 Git 工作流与智能代码审查

Trae Code 内置了完整的 Git 工作流，并加持 AI 的智能审查能力：

• 智能 Commit Message：一键让 AI 根据你的代码变更生成符合 Conventional Commits 规范的提交信息；
• 智能代码审查（Code Review）：对未提交变更、单次提交或分支差异进行总结与审查，通过摘要、流程图与 Diff 视图辅助你快速理解改动内容；
• 远程开发：支持通过 Remote SSH 或 WSL 连接远程主机，在远程环境中完成开发。

5. 隐私与命令执行设置

• 隐私设置（Privacy）：使用前查看当前版本的隐私说明、数据保存位置和相关开关，企业或敏感项目还应遵守组织自己的数据要求；
• 命令执行限制：若当前版本提供沙箱或审批设置，应按项目范围配置文件访问和命令权限。受限环境可以降低部分误操作风险，但不能替代差异审查和备份。

---

Solo 模式：连续执行多步骤任务

Solo 模式用于连续推进包含多个步骤的任务，例如先读取项目、修改代码、运行检查，再根据结果修正。它能减少手工切换，但任务边界和验收条件仍要提前说明：

Solo 模式核心特性拆解：

1. 📋 智能任务规划与拆解（Smart Task Planning）：
   • 擅长应对复杂项目迭代、大型 Bug 修复与架构重构；
   • 当你输入一段宏观意图后，Solo 模式会自动将其拆解为若干个清晰的小步骤，并在左侧面板形成结构化的执行清单。
2. ⏱️ 清晰的任务流与状态看板：
   • 左侧面板清晰呈现每个历史任务的执行状态与耗时（例如：完善技能列表 任务完成 · 00:55、控制图片插入大小 任务完成 · 02:07 等）；
   • 即使任务发生意外中断（如网络抖动），也可以一键查看中断上下文并随时恢复重试。
3. 🚦 手动审批（Manual Approval） vs 自动执行（Auto-Run）自由切换：
   • 底部输入框贴心提供了权限模式切换；
   • 新手/谨慎场景：选择“手动审批”，AI 每次创建文件、修改关键代码或在终端执行 Shell 命令前，都会弹窗等待你的确认；
   • 快速高效/熟练场景：开启“自动执行”，AI 将继续执行任务，自测自修，直到交付最终产物。
4. 📱 三端同步与移动指挥（App / Web / PC）：
   • 手机端、桌面端与 Web 端共享同一个 Agent 会话与任务进度：在地铁上发起任务、途中实时查看看板，到家直接验收成果；
   • 还可切换到云端运行环境，即使电脑不在身边或处于休眠，Agent 也能在云端拉取仓库、跑测试并自动产出 Pull Request。
5. 🗂️ 多任务并行（Multi-Task Parallel）：打破传统串行执行的限制，支持在同一个项目中同时管理多个任务，AI 可以像项目经理一样并行推进多条工作线，整体开发效率进一步提升；
6. 🧩 内置智能体 Agent + 自定义智能体编排：
   • Solo 模式内置 Agent 智能体，可独立承担“从需求迭代到架构重构”的全流程开发；
   • 更进一步，你还能自主编排多个智能体，组建属于你的 AI 团队（例如：一个负责前端、一个负责后端、一个负责测试），实现多角色协同开发，各有独立上下文、互不干扰；
   • 支持在 .trae/agents/ 目录下加载 Subagents 定义文件，将智能体配置纳入版本管理。
7. 🧰 工具面板（Tool Panel）：Solo 模式提供一套可视化工具面板，包括编辑器、文档、浏览器等，AI 可以借助它们完成真实环境下的操作与验收。

Plan 模式与 Spec 模式

对于需要先讨论范围或保存规格的任务，可以根据当前版本提供的入口选择相应模式：

模式	适用场景	工作方式
Plan 模式	中小型功能开发、模块级重构	AI 先分析需求、规划任务并生成规划文档，你确认后按计划逐项执行；不满意可直接在文档上修改或要求 AI 调整
Spec 模式	复杂系统级任务、从零搭建新模块/新系统、大规模架构重构	AI 一次性生成三件套——spec.md（大纲）/ tasks.md（任务清单）/ checklist.md（验收清单），存入项目根目录 .trae/specs/，可纳入 Git 版本管理，作为长期项目知识资产

💡 与我们教程的呼应：你在本章后续会看到，我们实战用的 docs/ 保存计划 + OpenSpec 规格演进，本质上就是 Spec 模式思想的“开源 DIY 版”——先规划再施工、先验收再交付，让 AI 编程从“自由发挥”走向“按图施工”。

---

为什么后续章节我们要基于已有项目做“二次开发”？

在接下来的实操章节中，我们将做出一项非常关键且贴近实战的教学决策：直接基于第五章搭建好的 FastAPI + SQLite 个人博客系统（project_03_个人博客系统），使用 Trae Code 进行二次开发与功能升级改造。

为什么我们不再从零（0 到 1）去新建一个简单的 Demo 呢？

已有项目往往已经包含接口、数据和使用习惯。新增功能时，需要同时理解这些约束，确认原来的操作仍然可用。

基于已有项目继续开发的四项训练目标

1. 培养真实生产体感：学会如何让 AI 快速阅读既有代码库、理解路由与数据库表结构，而不是每次都“白纸一张”；
2. 掌握代码审查与局部修补能力：在已有代码中改动，最考验 AI 的上下文关联能力与你的代码审查（Diff）功底；
3. 练习模块化扩展：为现有博客增加新功能时，识别需要同步修改的模型、接口、页面和测试；
4. 保持章节连贯：沿用第五章的全栈项目，观察同一系统在连续迭代中的变化。

---

场景化工具选型指南：你该怎么选？

选择入口时可以先看任务是否围绕代码仓库，以及是否需要逐文件审查：

• 💼 办公接入、数据处理与日常自动化：
  • 如果目标是整理表格、处理文档或执行跨应用任务，可以查看 Trae Work 及当前版本提供的相应能力；
• 👨‍💻 严肃编程、全栈开发与工程二次开发：
  • 如果需要阅读项目、重构模块、编写接口和调试问题，选择带文件树、差异审查和终端的代码工具更方便。
• 🎨 设计稿转代码、快速出前端原型：
  • 如果你希望把设计图（如 Figma / 效果图）直接转成可运行的页面，或想用“一句话 + 一张图”快速验证创意，可以直接使用 Trae Design 工作区。

---

高频疑问速答（FAQ）

问题	快速解答
Trae Code 与其他工作区怎样选择？	围绕代码仓库编辑、运行和审查时使用代码工作区；通用任务或设计流程则查看当前版本提供的其他入口。
国内版与国际版有什么区别？	可用模型、价格、账号和功能范围可能不同，使用前分别查看 国内官网与国际官网的当前说明。
免费用量是否够用？	取决于当前套餐、模型和任务长度。先用一个小项目记录实际消耗，再决定是否需要调整模型或套餐。
Solo 模式会不会改动过多文件？	任务范围不清时可能出现偏差。应先说明允许修改的目录和验收条件，并在完成后查看差异、测试结果与关联文件。
怎样判断代码和数据是否适合接入？	查阅当前隐私条款、数据保存方式与权限设置，再结合项目的保密要求决定；敏感密钥和生产数据不应直接放入普通对话。
语言和框架支持怎样确认？	用当前项目做一次小范围读取、修改和运行检查。模型列表、扩展与外部连接以客户端实际显示和官方说明为准。

---

先学会审查一次修改

审改稿时不能只数改了几个字，还要看含义是否变化。审查 AI 修改也一样：先看任务目标，再看受影响的行为，最后读具体差异。

例如“给删除文章加权限检查”，除了删除接口，还应检查登录状态如何取得、失败提示怎样展示、测试是否覆盖无权限访问。修改文件少并不一定完整，修改文件多也不一定过度。

审查角度	可直接提出的问题
范围	这次为何改动这些文件，是否包含无关调整？
行为	原来的正常操作是否仍然可用？
错误	未登录、数据不存在、请求失败时分别怎样处理？
证据	哪些情况已经运行验证，哪些仍未检查？

若发现其中一个文件有问题，撤销前先确认其他文件是否依赖它。单独撤回请求模型，却保留依赖新字段的接口，可能让原本能运行的修改变得不一致。

练习时可以先让工具只解释一个接口，不改代码，再让它提出一个小改动方案。经过一次讨论、实现和审查，你会更清楚自己需要哪种操作方式，而不必根据模式名称判断能力。

用同一任务比较不同工作模式

模式名称容易给人抽象印象，可以用同一个小任务观察差别。例如选择“为文章详情接口补充不存在时的说明”，先让普通问答只解释现状，再让 Plan 模式列出修改范围和验收方法，最后由 Solo 模式在明确约定下完成实现。

比较时关注四项：工具读取了哪些文件、是否先确认现有行为、实际改动范围、给出了哪些验证证据。回答更长或改动更多，不代表结果更好；与任务范围一致、失败行为清楚、能被复查，才是有效完成。

涉及数据库迁移、批量重命名或对外发布时，应把审批点和回退方式写进任务。模式可以改变执行节奏，但不会替你决定业务边界，也不会消除代码审查和测试的必要性。

第一次接手项目时，先完成只读检查

面对已有代码，第一条指令可以先要求工具回答几个可核对的问题：项目从哪个文件启动、文章数据保存在哪里、页面怎样调用接口、现有测试覆盖哪些功能。回答中应标出实际文件和代码位置；如果只能给出通用说明，就继续缩小问题，不要马上进入修改。

需要确认的内容	可以要求提供的证据	对后续任务的影响
启动入口	启动命令、入口文件、监听地址	决定从哪里运行和排错
数据保存	数据库配置、相对路径、初始化逻辑	避免连接到另一份空数据库
页面与接口	请求地址、方法和返回字段	判断改接口会影响哪些页面
项目规则	规则文件及适用目录	明确修改范围和禁止事项
当前检查	测试命令与现有结果	区分原有失败和新引入问题

只读检查完成后，再给出一次范围较小的改动。例如把一个含糊的错误提示改得更明确，同时要求说明受影响文件和验证方法。这个任务足以观察工具是否先读代码、是否修改无关内容、是否运行了合适的检查，也不会把项目同时带入多个未知变化。

根据动作影响设置审批范围

读取文件、改动练习目录、删除数据和向外发布，影响程度不同，不适合使用同一套默认权限。可以在任务开始前把动作分成三类：只读操作允许直接执行；项目内可恢复的修改在差异中统一审查；数据库迁移、删除文件、安装系统依赖和发布操作保留单独确认。

自动执行也应有清楚的停止条件。例如测试连续失败时先汇报原因，不反复改动不相关模块；发现需求与现有接口冲突时先更新计划；需要真实密钥时只读取环境变量，不把值写进代码。停止条件写得越具体，连续执行越容易控制。

用结果记录判断工具是否合适

试用后可以保存一张简短记录，而不是只凭操作感受决定长期使用：

观察项	记录方式
项目理解	关键入口与调用关系是否准确
修改质量	是否符合需求，是否引入无关调整
审查体验	差异是否清楚，能否定位到具体文件
运行能力	命令环境是否与项目一致，失败信息是否完整
用量与速度	以同一任务的实际结果比较

这份记录也能帮助选择普通问答、计划模式或连续执行模式。简单解释无需启动完整任务流程；跨文件修改需要先列范围；步骤明确且已有检查的任务，才适合连续执行。把工具选择建立在实际项目证据上，比根据宣传中的功能数量作判断更可靠。

---

本节回顾

本章接下来先导入博客并确认运行基线，再依次加入权限、评论点赞和 AI 生成。代码审查贯穿这些步骤，模式选择则按任务是否明确来决定。

继续阅读：6.2 导入已有项目并建立开发基线。