一、Code 模式是什么

Code 模式是 TRAE Work 中面向代码工程和应用开发的工作模式。它不只是“帮我写一段代码”，而是更适合在真实项目里理解代码、修改文件、运行命令、调试问题、补充测试，并交付可验证的代码结果。

你可以把它理解为一个工程开发助理：你描述目标，提供项目或需求上下文，AI 会先理解任务，再规划实现路径，必要时读取文件、修改代码、运行测试，并根据反馈继续调整。

它适合做什么

• 应用开发：从需求出发开发页面、功能、接口、脚本或小工具。
• 项目理解：阅读已有项目结构，解释模块关系、关键文件和运行方式。
• Bug 修复：根据报错、日志或复现步骤定位问题，并修改代码验证。
• 工程优化：优化性能、补充测试、重构代码、改善类型和异常处理。
• 工具脚本：批量处理文件、转换数据、自动生成内容或连接外部服务。

它不适合做什么

• 只整理资料、写纪要、做调研或分析表格，这类任务优先用 Work。
• 只生成页面视觉稿、探索视觉风格或还原 UI 截图，这类任务优先用 Design。

适用人群

Code 模式主要面向需要处理代码和工程结果的人。你不一定必须是专业工程师，但至少任务最终会落到代码、项目、脚本、页面或可运行应用上。

举例子：

• 开发者：开发功能、修 Bug、补测试、接入服务、优化代码。
• 技术型产品 / 运营：做内部工具、自动化脚本、数据处理小页面。
• 设计到开发一体的用户：先用 Design 出页面，再到 Code 中继续实现。
• 学习者：理解项目结构、学习代码实现、让 AI 解释和改造示例项目。

二、进入 Code 模式

打开 TRAE Work 后，在左上角模式切换处选择 Code。进入后，中间会出现 “Code with TRAE” 输入区。

你可以直接描述开发任务，也可以先选择下方的快捷入口，例如：应用开发、项目理解、游戏创意、工具脚本。

三、Code 模式能做什么

场景举例

判断一个任务要不要用 Code，可以先问自己一句话：这件事最后是否需要修改代码、运行项目、调试错误或交付一个可运行产物？

如果是，优先考虑 Code 模式。

Code 模式 VS Work 模式

很多任务看起来 Work 和 Code 都能做，关键区别不在“能不能回答”，而在任务最后是否需要进入真实工程执行。

三个模式如何联动

Work To Code：从需求文档到开发实现

Work 模式产出的需求文档、竞品分析、用户反馈归类和功能清单，都可以作为 Code 模式的输入。

你可以把 Work 里整理好的需求复制过来，或附上对应文档，让 Code 根据它拆开发任务。

请基于这份需求文档开发功能。
先阅读需求，提炼功能范围、用户路径、数据结构和验收标准。
然后给出实现计划，确认后再修改代码。
如果需求里有不清楚的地方，请先列出问题，不要直接猜。

Design To Code：从设计产物到页面开发

Design 模式生成的页面原型或导出的设计产物，可以继续交给 Code 模式开发。这个链路适合自己出设计、自己开发，或希望快速把设计草稿变成可运行页面的用户。

请根据这个设计稿实现页面。
要求：尽量还原布局、组件层级、颜色、间距和交互状态。
请先检查当前项目的技术栈和组件库，再给出实现计划。
如果设计稿中有无法直接实现的部分，请说明替代方案。

Code To Work / Design：沉淀和继续迭代

Code 完成开发后，也可以把结果回流到 Work 或 Design：用 Work 生成变更说明、测试记录、上线文档；用 Design 继续调整界面体验或补充视觉状态。

四、创建第一个 Code 任务

最简单的开始方式，是选择一个小而明确的开发任务。比如：修改一个页面文案、添加一个按钮、修复一个报错、写一个简单脚本。

推荐提示词公式

你可以按照这个公式来写：

示例：

请帮我在当前项目中新增一个“反馈提交”页面。
目标：用户可以填写姓名、联系方式和反馈内容。
上下文：请先阅读项目结构，复用现有 UI 组件和样式。
验收标准：页面能正常打开，表单有基础校验，提交后显示成功提示。

提供上下文

如何希望需求被更好地实现，可以提供丰富的上下文。你可以选择上传附件，提供需求文档、贴出报错日志，或说明你期望它如何验证结果。

• 项目上下文：项目目录、技术栈、已有组件、运行命令。
• 任务上下文：需求文档、设计稿、接口说明、复现步骤。
• 验收方式：运行测试、启动页面、检查截图、通过 lint 或类型检查。

选择 Spec 或 Plan

Code 模式里除了直接输入需求，还可以使用更有规划的命令。复杂任务建议优先用 Spec 或 Plan，让 AI 先把任务想清楚，再进入执行。

• Spec：根据需求细化完整的规范、任务和验收文档，用户确认后再严格执行，适合复杂的长线任务。
• Plan：优先规划任务的执行方向，用户确认后再执行，适合中等复杂度、需要先看路径的任务。

五、预览、修改和验收

查看计划和执行过程

提交任务后，先看 TRAE Work 的计划。尤其在 Code 模式里，你要关注它准备改哪些文件、运行哪些命令、如何验证结果。

如果计划偏了，尽早打断并补充：

先暂停。这个方向不对。
请不要修改【某些文件 / 某个模块】。
请先重新阅读【文件 / 文档】，然后给出新的实现计划。

继续修改

第一次结果不需要完美。你可以像做代码评审一样，指出具体问题，让它继续改。

• “这版实现太重，请优先复用已有组件。”
• “请补充空状态和错误状态。”
• “请不要改公共工具函数，改成在当前页面内处理。”
• “请补充测试，并说明覆盖了哪些场景。”

结果验收

Code 模式的结果要尽量可验证。你可以要求它说明改了哪些文件、为什么这么改、运行了哪些检查、还有哪些风险。

六、常见问题

Q1：Code 模式是不是只适合专业工程师？

A：不是。只要任务最终要落到代码或可运行工具上，就可以用 Code。非工程用户也可以从小脚本、小页面、项目理解开始。

Q2：Work 已经能帮我做开发，为什么还要 Code？

A：轻量任务 Work 也可能跑通。但 Code 更适合真实项目里的文件修改、运行调试、测试验证和长期维护，尤其适合需要严格工程过程的任务。

Q3：什么任务 Work 和 Code 都可以做？

A：需求拆解、技术方案、简单脚本思路、页面文案和数据处理方案都可能两边都能做。区别是 Work 更偏“整理和规划”，Code 更偏“落地实现和验证”。

Q4：什么时候一定要用 Code？

A：当你需要改代码仓库、运行命令、修 Bug、接入接口、补测试、处理依赖或生成可运行应用时，优先用 Code。

Q5：Spec 和 Plan 怎么选？

A：复杂、长期、多阶段任务优先用 Spec；中等复杂度、想先确认执行路径时用 Plan；很小的修改可以直接描述需求。

七、练手小作业

附｜常见 Code 场景提示词

架构梳理

根据服务、接口的调用关系和真实的代码实现等信息，帮我梳理下当前 【功能范围描述：xx功能、xx产品】的架构图，结果通过飞书文档的方式呈现，要求如下：
整体架构图（C4 Container 或系统上下文图）
核心模块 & 接口清单
数据模型快照（ER 或类图）

应用开发

请基于当前项目开发【功能名称】。
目标用户：【谁使用】。
核心流程：【用户如何使用】。
请先阅读项目结构和现有组件，再给出实现计划。
验收标准：【页面可打开 / 功能可用 / 测试通过】。

项目理解

请帮我理解当前项目。
请输出：项目用途、技术栈、目录结构、核心模块、启动方式和我应该优先阅读的文件。
如果有不确定的地方，请标注“待确认”。

编写技术方案

根据需求生成对应的技术方案，方案文档的格式需以下格式。
需求描述：【链接】
业务需求
现状与目标
2.1 现状梳理
2.2 业务目标
方案设计
3.1 方案描述
3.2 模块图 & 模块介绍
3.3 时序图、流程图 & 流程说明
需求拆解
详细设计

Bug 修复

当前问题是：【描述现象】。
复现步骤：【步骤】。
报错信息：【日志或截图说明】。
请先定位可能原因，再提出修改计划。
修改后请运行相关检查，说明你如何验证。

生成测试用例

【链接】
输出文档格式
一、项目相关信息(待确认是否需要)
以表格形式整理如下信息，获取对应文档或链接，获取不到的可留空
二、影响范围说明
这一部分主要说明本次需求改动影响模块，及判断影响的原因，例如影响了 xxx、xxx、xxx模块，主要因为PRD中描述了XX模块需要改动，技术方案也有接口改动等，同时还需要包含历史用例集参考情况
功能影响
【待补充】
【待补充】
稳定性风险
【待补充】
【待补充】
变更影响范围
直接影响
【被影响的功能模块】
间接影响
【可能被关联到的模块，不用列太多】
历史用例集参考
三、测试用例
按照表格形式生成。

测试补充

请为【模块 / 函数 / 页面】补充测试。
请先说明需要覆盖哪些场景，再新增测试用例。
测试至少覆盖：正常路径、异常输入、边界情况和关键状态。
完成后请运行测试并汇总结果。

工具脚本

请写一个脚本完成【任务】。
输入是：【文件 / 数据 / 目录】。
输出是：【结果格式】。
要求：保留原始文件，先生成预览结果；确认后再执行批量修改。