掌握AI协作编程：Trae示例全解析

AI 协作编程的实用指南（以Trae为例）

1. 使用场景与目标

这份指南是专门为那些已经在团队内使用或打算引入 Trae IDE + AI 助手的开发团队设计的，主要目标是：

• 帮助开发者从“自己动手写代码”转变为“指挥AI团队执行任务”

• 通过清晰的人机分工和流程管理，避免AI“乱写代码”、需求理解偏差以及产品质量不达标

• 充分发挥Trae的规则、双模式（聊天/构建）以及SOLO/Agent团队等功能，让AI成为一个“有条理、守纪律的协作工程师”

—

2. Trae的协作模式概览（人机如何协同工作）

在Trae的环境下，一次典型的协作开发从创意到上线，大致可以分为六个阶段（对应6A工作流的简化视角）：

1. 需求对齐（Align）：人负责明确业务目标和约束，AI则负责提取成可执行的规范和问题列表

2. 架构设计（Architect）：人负责架构思路的确认，AI则给出候选架构、接口设计和权衡分析

3. 任务拆分（Atomize）：AI将需求拆分为“AI能稳妥完成的原子任务”，人则负责审批

4. 执行开发（Automate）：AI根据任务清单编写代码、补充测试，人负责代码审查和关键部分的实现

5. 评审与验收（Assess）：AI协助自检和生成报告，人做最终验收、合并和上线决策

6. 迭代优化（Improve）：AI总结本次开发的经验和遗留问题，人结合监控和反馈进行后续规划

接下来，我们将深入探讨“角色与阶段”，更详细地说明人机协作的细节。

—

3. 角色与职责：各司其职

3.1 程序员的职责（人类工程师）

主要关注决策、约束和验收，而不是“每一行代码都亲手敲”。

核心职责：

1. 需求与范围

◦ 清晰描述业务目标：做什么、不做什么、成功标准是什么

◦ 负责确认AI生成的对齐文档（ALIGNMENT / CONSENSUS 文档）

2. 技术架构与规范

◦ 决定技术栈和架构风格（单体/微服务、分层结构等）

◦ 审核和修改AI提供的架构设计（包括设计文档、接口契约、数据模型）

◦ 定义并维护团队的编码规范、安全规范和性能要求

3. 核心与关键代码

◦ 关键业务流程、复杂算法和安全敏感逻辑，由人主导实现或深度审查

◦ 对AI编写的代码负最终责任（包括性能、可维护性和安全性）

4. 质量与风险

◦ 审核AI生成的测试用例，补充边界条件和非功能测试（性能、容灾等）

◦ 决定迭代节奏和质量门控（何时可以上线）

◦ 识别AI解决方案中的不合理假设和技术债，并标记TODO

5. 项目节奏与协作

◦ 确定每一阶段是否“通过”：需求对齐是否清晰、设计是否可行、任务拆分是否合理

◦ 在多人协作的场景中，协调不同成员与AI使用的一致规范（统一规则）

3.2 AI助手的职责（Trae中的AI/Agent）

AI不负责“拍板”，而是专注于高效执行和智能建议：

1. 代码生产与重构

◦ 根据约束规范（project_rules.md、user_rules.md）自动生成代码骨架和实现

◦ 批量重构（提取方法、重命名、模块拆分）并提供说明

◦ 自动生成迁移脚本、配置文件和简单脚本工具等

2. 规范与格式

◦ 根据项目规则自动进行格式化、命名规范和文件组织建议

◦ 检查代码是否符合既定的规范（例如必须加注释、禁止硬编码API Key）

3. 错误诊断与修复建议

◦ 基于运行日志和报错堆栈，推测可能的错误原因并提供修改建议

◦ 提示潜在的空指针、并发问题和SQL注入风险等

4. 测试与文档

◦ 为已有代码生成单元测试和集成测试样例（覆盖正常、异常和边界情况）

◦ 自动生成或更新接口文档、README和变更记录

◦ 从对话和代码变更中提炼出“开发日志”或“发布说明”

5. 知识与调研

◦ 快速检索语言/框架的官方文档、典型用法和社区最佳实践

◦ 在多种方案之间提供对比表和选型建议，供程序员做决策

3.3 混合职责（人机协作区）

这类任务需要人机合作，单靠AI或人都难以达到最佳效果：

1. 代码实现

◦ AI：根据需求和设计文档，先生成“完整但可能粗糙”的实现

◦ 程序员：从业务正确性、性能和安全等方面进行二次打磨和重构

2. 问题排查

◦ AI：根据日志、代码和配置提供可能原因的排序和检查步骤

◦ 程序员：逐条验证、实施修改、回归测试并更新知识（记录在规则或文档中）

3. 方案设计与选型

◦ AI：提出多种实现方案（包括优缺点、复杂度和成本评估）

◦ 程序员：基于业务背景、团队技能和长期维护成本做出最终选择

4. 任务拆分与排期

◦ AI：根据需求，将一个大任务拆分为多个原子任务，推导出依赖关系图

◦ 程序员：确认优先级、合并或拆分任务，决定哪些是由AI主攻，哪些是由人来负责

—

4. 基于Trae的人机协作开发流程（从0到1）

下面我们将按一个完整项目的流程，从需求到交付，分阶段说明：什么时候该用AI，什么时候必须由人来做决策。

4.1 阶段一：需求对齐（Align）

目标：将“一句话的想法”转化为“清晰可执行的任务说明”。

操作步骤（建议在Trae Chat / SOLO模式中进行）：

1. 程序员用自然语言描述需求，比如：

“做一个带用户登录/角色权限的后台管理系统，前端使用React，后端用Spring Boot，要求支持多租户。”

2. AI根据6A规则：

◦ 自动分析现有项目结构和已有模块（如果是迭代项目）

◦ 生成docs/任务名/ALIGNMENT_任务名.md，包括：

▪ 项目背景和目标

▪ 范围和不做的内容

▪ 已知的约束（技术栈、兼容性等）

▪ 疑问列表（例如：是否需要第三方登录、多租户策略等）

3. 程序员：

◦ 必须逐条确认/修改AI总结的需求与边界

◦ 对AI无法确定的地方给出明确的回答（比如多租户策略选哪种）

◦ 确认后，由AI生成CONSENSUS_任务名.md（共识文档）

人机分工要点：

• AI负责：

◦ 将模糊的自然语言结构化为文档和问题清单

• 程序员负责：

◦ 对每一个歧义做出决策，绝不能跳过这一步直接让AI开始写代码

—

4.2 阶段二：架构设计（Architect）

目标：先有可行的架构与接口设计，然后再进行编码。

推荐做法：

1. 在Trae中，基于CONSENSUS文档，让AI：

◦ 生成DESIGN_任务名.md：

▪ 整体架构图（Mermaid）

▪ 模块/服务划分

▪ 核心接口契约及数据模型

▪ 错误处理、权限校验、日志策略等

2. 程序员：

◦ 审查这些设计，特别关注：

▪ 是否与现有系统架构冲突

▪ 关键非功能需求（性能、安全、可扩展性）是否被考虑

◦ 如有必要，要求AI调整架构并重新生成设计文档

人机分工要点：

• AI负责：草拟和提供备选方案（生成多种架构/接口设计）

• 程序员负责：决策与修正（选择其中一种或混合方案，并写入项目规范中）

—

4.3 阶段三：任务拆分（Atomize）

目标：让AI可以“分块”稳妥完成任务，而不是一次性吞下整个大项目。

操作步骤：

1. 让AI根据DESIGN文档生成TASK_任务名.md：

◦ 对每个任务描述清楚：

▪ 输入：依赖哪些模块/文档/配置

▪ 输出：预期成果（代码文件、接口、测试）

▪ 验收标准：什么条件算完成

▪ 依赖图（Mermaid）

2. 程序员：

◦ 检查是否出现“一项任务过大、跨多个关注点”的情况

◦ 检查任务依赖是否存在循环，是否符合团队分工

◦ 可标注哪些任务由AI主动实现，哪些需要人主导

人机分工要点：

• AI负责：尽可能细致地拆分任务，提供依赖拓扑

• 程序员负责：划定“AI可以全权执行”的任务范围及优先级

—

4.4 阶段四：自动化执行（Automate + Coding）

这是大家最关注的“谁来写代码”阶段，也是最容易失控的地方。关键在于 要让AI按照任务清单和规则执行，而不是随意发挥。

让AI与程序员更顺畅合作的工作流

在使用Trae Builder或SOLO的过程中，有一些推荐的工作流，大家可以参考一下：

1. 任务按顺序来执行：

◦ 每次就让AI专注于一个小任务（从TASK_任务名.md中获取）

◦ 在AI动手之前，先确认输入的契约是否都准备好了（相关文件和配置是否到位）

2. AI需要完成的具体工作：

◦ 生成或修改代码文件

◦ 同时生成或更新相应的测试文件

◦ 补充必要的注释和文档片段

◦ 在ACCEPTANCE_任务名.md里记录完成情况以及已经写好的测试

3. 程序员的介入时机：

◦ 每当一个任务完成后：

▪ 可以通过Trae的diff视图快速查看变更内容

▪ 对满意的部分点击“接受”，不合理的地方则要求AI进行调整

◦ 对于“关键业务或安全相关”的任务：

▪ 甚至可以要求AI生成伪代码或详细步骤，最后由人来实现

人机分工的要点：

• AI是“执行者”：按照清单来做事，包括写代码、测试和文档

• 程序员是“审查者”：有权拒绝任何自动修改，必要时亲自重写关键部分

—

4.5 第五阶段：评估与验收

我们的目标是：在合并上线前，确保AI生成的成果真正符合需求。

AI能够做的事情：

• 根据ACCEPTANCE文档，汇总所有任务的完成状态

• 对照最初的CONSENSUS文档，逐一检查是否已实现

• 生成FINAL_任务名.md（总结报告）和TODO_任务名.md（遗留问题清单）

程序员需要做的事情：

• 手动核查关键用例（确保核心业务流程正常运转）

• 注意AI总结中标记的风险和TODO，评估是否允许带着这些上线

• 做出最终决策：是否合并分支或发布版本

—

4.6 第六阶段：迭代与知识沉淀

协作要点：

• 将这次开发过程中的“踩坑经验、架构约束、命名约定”记录在Trae的：

◦ project_rules.md（项目级规则）

◦ user_rules.md（个人习惯与5S规则）

• 下次AI再参与同一项目时，就会自动遵循这些约束，减少重复沟通的麻烦

—

5. 开发者与AI的行为规范

5.1 程序员必须遵守的五条底线：

1. 不允许在需求未对齐时写代码：

◦ 没有ALIGNMENT或CONSENSUS文档时，拒绝让AI直接生成大块代码

2. 不要盲目相信AI的输出：

◦ 所有关键变更都必须通过diff和手动验证

◦ 和安全、钱、隐私相关的逻辑，必须由人来把关

3. 所有修改都要有文档记录：

◦ 任何功能或接口变更，都要让AI更新文档，而不是“写完就算了”

4. 遇到不确定的决策，AI必须询问人：

◦ 在规则中明确：遇到涉及业务规则、历史兼容、法规合规的问题，不能擅自决定，必须暂停询问

5. 保持任务的原子化和可回滚性：

◦ 不允许一次性重构整个仓库而没有人审核

5.2 AI一般应遵守的行为约束：

可以在项目规则中写入类似条款，让Trae中的AI始终遵守：

• 优先阅读项目现有的代码与文档，再提出方案

• 严禁引入未经确认的新依赖或技术栈

• 所有新增公开接口都必须有：

◦ 注释说明

◦ 示例调用

◦ 简单测试用例

• 任何时候遇到如下情况必须立刻中断并向用户提问：

◦ 不确定的业务规则

◦ 可能带来数据丢失或安全风险的修改

◦ 无法确认向下兼容性的变更

—

6. 可直接落地的团队约定

可以将下面这段，稍作修改后贴进团队的Confluence或项目的README，作为“Trae AI合作开发公约”：

本项目使用Trae作为AI协作IDE，AI不代替人决策，而是作为高效的执行者和智能顾问。

任何功能开发必须经历：需求对齐→架构设计→任务拆分→AI执行→人工审核→验收这六个步骤，禁止跳步。

程序员负责：需求、架构、关键逻辑、安全与性能、最终上线决策。

AI负责：在既定规则下生成代码、测试、文档，执行重构和问题排查，遇到不确定情况必须停下询问。

所有与AI合作产生的成果，必须通过文档和规则（project_rules.md / user_rules.md）进行沉淀，避免重复踩坑。

任何时候，只要有疑问，以人类工程师的判断为优先，AI的输出仅供参考和草稿。

—