AI 协作编程指南（以Trae示例）
1. 使用场景与目标
本指南面向已经或准备在团队中采用 Trae IDE + AI 助手 的开发模式的团队，目标是：
• 让开发者从「自己写所有代码」升级为「指挥 AI 团队干活」
• 通过明确的人机分工与流程约束，避免 AI「瞎写代码」、需求理解跑偏、质量不可控
• 充分利用 Trae 的 Rules（规则）、双模式（Chat / Builder）、SOLO / Agent 团队 等能力，把 AI 变成一个「有流程、有纪律的协作工程师」
---
2. Trae 协作模式总览（人机如何一起工作）
在 Trae 中，典型的一次协作开发从想法到上线，大致分为 6 个阶段（对应 6A 工作流的简化视角）：
1. 对齐需求（Align）：人负责讲清业务目标和约束，AI 负责提炼成可执行规范和问题清单
2. 架构设计（Architect）：人拍板架构思路，AI 负责给出候选架构、接口设计和权衡分析
3. 任务拆分（Atomize）：AI 负责把需求拆成「AI 能稳妥完成的原子任务」，人负责审批
4. 执行开发（Automate）：AI 按任务清单写代码、补测试、人做代码审查和关键实现
5. 评审与验收（Assess）：AI 辅助自检和生成报告，人做最终验收、合并与上线决策
6. 迭代优化（Improve）：AI 总结本次开发的经验、遗留 TODO，人结合监控与反馈做后续规划
接下来用更细粒度的「角色与阶段」说明人机协作细节。
---
3. 角色与职责：谁管什么
3.1 程序员角色职责（人类工程师）
聚焦 决策、约束和验收，而不是「每一行代码都亲手敲」。
核心职责：
1. 需求与范围
◦ 把业务目标写清楚：做什么、不做什么、成功标准是什么
◦ 负责最终确认 AI 生成的 ALIGNMENT / CONSENSUS 文档（需求对齐文档）
2. 技术架构与规范
◦ 决定技术栈、架构风格（单体/微服务、分层结构等）
◦ 审核并修改 AI 给出的架构设计（DESIGN 文档、接口契约、数据模型）
◦ 定义 / 维护团队统一的 编码规范、安全规范、性能要求
3. 核心与关键代码
◦ 关键业务流程、复杂算法、安全敏感逻辑，由人类主导实现或深度 review
◦ 对 AI 写出的代码负最终责任（包括性能、可维护性、安全性）
4. 质量与风险
◦ 审核 AI 生成的测试用例，补充边界条件和非功能测试（性能、容灾等）
◦ 对迭代节奏、质量门控（何时可以上线）做决策
◦ 识别 AI 方案中的不合理假设、技术债并标记 TODO
5. 项目节奏与协作
◦ 拍板每一阶段是否「通过」：需求对齐是否够清晰、设计是否可行、任务拆分是否合理
◦ 在多人协作场景下，协调不同成员与 AI 使用的一致规范（统一 Rules）
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：从日志、代码、配置中给出可能原因排序和检查步骤
◦ 程序员：逐条验证、落地修改、回归测试并更新知识（写入 Rules 或文档）
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 按任务清单和规则执行，而不是自由发挥。
推荐工作流（在 Trae Builder / SOLO 中）：
1. 按任务顺序执行
◦ 每次只让 AI 聚焦一个原子任务（来自 TASK_任务名.md）
◦ AI 实现前，会先检查输入契约是否满足（相关文件 / 配置是否就绪）
2. 由 AI 完成的具体工作：
◦ 生成 / 修改代码文件
◦ 同步生成 / 更新对应测试文件
◦ 补充必要注释和文档片段
◦ 在 ACCEPTANCE_任务名.md 里记录完成情况和已写的测试
3. 程序员介入点：
◦ 每完成一个任务：
▪ 通过 Trae 的 diff 视图快速审查变更
▪ 对可接受的部分点击「接受」，对不合理之处要求 AI 调整
◦ 对「关键业务 / 安全相关」任务：
▪ 甚至可以要求 AI 只生成伪代码或详细步骤，由人来真正实现
人机分工要点：
• AI 是「执行者」：按清单来，写代码 + 写测试 + 写文档
• 程序员是「审查者」：有权拒绝任何自动修改，必要时亲自重写关键部分
---
4.5 阶段五：评估与验收（Assess）
目标： 在合并上线前，确保 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 程序员须遵守的 5 条底线
1. 不允许在需求未对齐时开写代码
◦ 没有 ALIGNMENT / CONSENSUS 文档时，拒绝让 AI 直接生成项目大块代码
2. 不盲信 AI 输出
◦ 所有关键变更都必须通过 diff + 手工验证
◦ 安全 / 钱 / 隐私相关逻辑，必须人工把关
3. 所有修改要有文档跟踪
◦ 任何功能、接口变更，都要让 AI 帮忙更新文档，而不是「写完就拉倒」
4. 遇到不确定决策，AI 必须询问人
◦ 在 Rules 里写明：遇到涉及业务规则 / 历史兼容 / 法规合规问题，不得自作主张，必须中断询问
5. 保持任务原子化与可回滚
◦ 不允许一次 Builder / SOLO 任务大规模重构整仓库而无人审核
5.2 AI 一般应遵守的行为约束（写入 project_rules.md 的要点示例）
可以在项目规则中写入类似条款，让 Trae 中的 AI 一直遵守：
• 优先阅读项目现有代码与文档，再提出方案
• 严禁引入未经确认的新依赖或新技术栈
• 所有新增公开接口都必须有：
◦ 注释说明
◦ 示例调用
◦ 简单测试用例
• 任何时候遇到如下情况必须立刻中断并向用户提问：
◦ 不确定业务规则
◦ 可能带来数据丢失 / 安全风险的修改
◦ 无法确认向下兼容性的变更
---
6. 可以直接落地的团队约定（模板式总结）
可以把下面这段，稍作修改后贴进团队 Confluence / 项目 README，作为「Trae AI 协作开发公约」：
本项目使用 Trae 作为 AI 协作 IDE，AI 不代替人决策，只作为高效执行者和智能顾问。
任何功能开发必须经历：需求对齐 → 架构设计 → 任务拆分 → AI 执行 → 人工审核 → 验收 6 个步骤，禁止跳步。
程序员负责：需求、架构、关键逻辑、安全与性能、最终上线决策。
AI 负责：在既定规则下生成代码 / 测试 / 文档、执行重构和排查问题，遇到不确定情况必须停下询问。
所有与 AI 协作产生的成果，必须通过文档和规则（project_rules.md / user_rules.md）进行沉淀，避免重复踩坑。
任何时候，只要有疑问，以人类工程师判断优先，AI 的输出只作为参考和草稿。
---
版权声明：本文转载于今日头条，版权归作者所有，如果侵权，请联系本站编辑删除
