用 CodeArts Doer 的六个 Agent 走通从需求到部署的开发流程

CodeArts Doer 是华为云推出的 AI 智能开发助手，它的组织方式不是「一个对话框包打天下」，而是把开发流程拆给六个 Agent 分别负责：团队助理、项目助理、产品助理、开发助理、测试助理、提交助理。每个 Agent 对应流程里的一个环节，Agent 之间可以传递上下文，从而把需求管理、代码生成、测试用例生成、代码评审、自动化部署这些原本分散的动作串成一条线。如果你所在的团队已经在用华为云 CodeArts 的一站式开发生产线，这套 Agent 是在原有流程上加的一层智能协作；如果你是刚接触这套工具的个人开发者，也可以只挑其中一两个 Agent 用起来，比如只用开发助理做代码生成与补全，或者只用测试助理生成测试用例。想先看工具条目，可以从 CodeArts Doer 进入。

这篇教程面向三类读者：刚入门的开发者，希望少写基础样板代码、顺便学到更规范的写法；有经验的开发者，希望把重复性的代码生成、优化建议、质量检查交给助手，自己专注在难的问题上；以及测试、项目管理、产品岗位的协作方，希望用对应的 Agent 把需求文档、测试用例、进度风险这些产出物快速成型。下面按「准备工作 → 操作步骤 → 完整示例 → 注意事项」的顺序展开，每一步都给出该填什么、该看什么。

准备工作

账号与服务开通

使用 CodeArts Doer 的前提是一个可用的华为云账号。整个准备过程分三步，顺序不能颠倒：

注册并登录华为云。访问华为云站点完成账号注册，然后用该账号登录控制台。企业用户通常还需要完成实名认证，具体以控制台提示为准。
开通 CodeArts Doer 服务。在华为云控制台中检索 CodeArts Doer 服务条目，进入后按页面指引开通。服务是否收费、有哪些套餐与配额，各区域可能不同，请以官网当前信息为准。
创建项目。在 CodeArts Doer 控制台新建项目，填写项目名称，例如「Web 应用开发」。项目是后续所有 Agent 共享上下文的容器，名称建议能一眼看出业务范围。

环境与角色准备

除了账号，还有两件事建议在动手前想清楚：

IDE 侧的准备。开发助理的代码生成发生在 IDE 内，所以你需要有一个可用的 IDE 环境，并确认当前项目已经接入 CodeArts 的开发能力。具体支持哪些 IDE、如何安装插件，以官网当前信息为准。
角色分工。六个 Agent 分别对应不同岗位的产出物，如果团队里产品、测试、开发是不同的人，最好在开工前约定好谁负责跟哪个 Agent 对话、产出物放在哪里，否则上下文容易断在交接处。

先理解六个 Agent 的分工

动手之前先把这张分工表记住，后面所有步骤都是围绕它展开的：

Agent	代号	负责的环节	典型输入	典型产出
团队助理	Timmy	目标定义与任务拆解	项目目标描述	拆解后的任务清单
产品助理	Pony	需求整理	需求描述	需求文档、用户故事、交互设计草图
开发助理	David	编码	IDE 中的需求说明	生成的代码
测试助理	Cindy	测试	测试需求	测试用例并执行测试
提交助理	Oliver	提交前质量把关	待提交的代码	代码质量检查结果
项目助理	Mike	进度跟踪与风险监控	项目状态	进度报告、风险预警

这张表的价值在于：当你发现某个环节卡住时，能立刻判断该找哪个 Agent，而不是在一个对话框里反复描述上下文。

操作步骤

第一步：用团队助理（Timmy）定义目标并拆任务

项目建好之后，第一个对话对象是团队助理。它的职责是把一个模糊的项目目标变成可执行的任务分解。操作上就是向 Timmy 描述项目目标，例如要做什么系统、服务哪些用户、大致的时间边界，然后让它输出任务拆解。

这一步的产出质量直接决定后面几步顺不顺。建议在描述目标时把范围说窄一点，比如「做一个内部使用的报销单提交与审批的 Web 应用」，而不是「做一个企业管理系统」。范围越窄，拆出来的任务越具体，产品助理和开发助理接手的成本越低。

第二步：用产品助理（Pony）生成需求文档

拿到任务拆解后，把需求描述输入给产品助理 Pony。它会整理出需求文档，并可以基于你输入的需求描述自动生成初步的用户故事和交互设计草图。

对产品岗位的读者，这一步能显著缩短从想法到可评审文档的时间；对开发岗位的读者，即使你手上没有正式的产品文档，也可以先用 Pony 把需求结构化，再交给开发助理，避免直接对着几句话写代码。产出物建议落盘保存，因为后续开发助理和测试助理都会引用它。

第三步：用开发助理（David）在 IDE 中生成代码

这是大多数开发者最关心的一步。开发助理工作在 IDE 内，操作方式是把需求输入到 IDE 中，由它生成对应代码。除了整段生成，它也提供代码补全能力，适合边写边补。

使用时有几个实践要点：

一次只喂一个可验证的需求点。把整份需求文档一次性丢进去，生成的代码往往难以逐段核对；按接口、按页面、按函数拆开喂，生成结果更容易验证。
把已有代码风格作为上下文。生成前先让 IDE 里存在同类文件的样例，生成结果会更贴近项目现有风格。
生成后立刻跑一遍。CodeArts Doer 内置了代码保护与安全规则检查，也支持智能测试与自动修复，但这些机制不能替代你自己对生成代码的审阅。

第四步：用测试助理（Cindy）生成并执行测试

代码写完后，把测试需求输入给测试助理 Cindy。它会根据需求自动生成测试用例，并支持自动化测试执行。

这一步的关键是「测试需求」要写清楚边界。只写「测试登录功能」，生成的用例大概率只覆盖正常路径；把异常输入、权限边界、并发场景一并写进去，用例覆盖才会完整。执行结果出来后，把失败的用例连同报错信息回传给开发助理，形成修复闭环。

第五步：用提交助理（Oliver）做提交前质量检查

在代码真正提交之前，交给提交助理 Oliver 做一轮代码质量检查。它承担的是「提交前最后一道闸」的角色，把明显的问题挡在主干之外。

建议把这一步固定在团队的提交规范里：任何一次合并请求之前都先过一遍 Oliver，检查结果作为评审材料的一部分。这样代码评审时人只需要关注设计与逻辑，格式与常见缺陷交给助手先筛一遍。

第六步：用项目助理（Mike）跟踪进度与风险

项目助理 Mike 负责项目进度跟踪与风险控制，提供项目进度报告和风险预警。它适合在固定节奏上使用，比如每周固定时间让它出一份进度报告，对照任务拆解看哪些项滞后、哪些风险已经浮现。

对项目管理者来说，这一步的产出可以直接用于站会或周会；对开发者来说，它提供了一个不依赖人工汇报的项目视图。

第七步：配置 CI/CD 完成构建、测试与部署

最后一步是把前面的人工环节接上自动化流水线。在 CodeArts 中配置 CI/CD 流程，让代码的构建、测试、部署自动执行。配置完成后，开发助理产出的代码在通过提交助理检查后进入流水线，测试助理的用例在流水线中自动跑，部署环节自动完成发布。

流水线的具体配置项、支持的目标环境与部署方式，随产品版本变化较大，请以官网当前信息为准。配置时建议先把「构建 + 测试」两段跑通，再接入部署，避免一上来就把问题混在一起排查。

一个完整示例

下面用一个最小可跑通的场景，把六个 Agent 串一遍。假设要做一个「待办事项管理」的 Web 应用，只有增删改查四个功能。

场景设定

项目名称：待办事项管理
目标用户：个人使用者
功能范围：新增待办、标记完成、编辑内容、删除待办

第 1 步：Timmy 拆任务

向团队助理描述目标：「做一个个人使用的待办事项管理 Web 应用，支持新增、标记完成、编辑、删除四项操作，单用户，不需要登录体系。」让它输出任务拆解。预期得到类似这样的任务清单：数据模型设计、后端接口（四个）、前端列表页与表单、测试用例、部署配置。

第 2 步：Pony 出需求文档

把上面的任务清单和功能范围输入产品助理，让它生成需求文档与用户故事。检查产出时重点看两件事：四个操作是否都有明确的输入输出定义；「标记完成」是否有状态回退的说明。缺的部分直接补充后再让它重出一版。

第 3 步：David 生成代码

在 IDE 中按接口逐个喂需求。例如先喂「新增待办：接收标题与截止时间，返回新建记录的 ID」，确认生成结果后再喂下一个。四个接口生成完毕后，再喂前端列表页的需求。每生成一段就本地跑一次，确认能编译、能返回预期结构。

第 4 步：Cindy 生成并执行测试

向测试助理输入测试需求，把正常路径和异常路径都写进去：标题为空时应拒绝创建；删除不存在的记录应返回明确错误；编辑后再次查询应返回新内容。让它生成用例并执行，把失败项连同报错回传给开发助理修复。

第 5 步：Oliver 检查后提交

四个接口与前端页面都通过测试后，交给提交助理做提交前质量检查。检查通过再发起合并，检查不通过就按提示修完再走一遍。

第 6 步：Mike 跟踪，流水线部署

项目进入开发后，定期让项目助理输出进度报告，对照第 1 步的任务清单看偏差。同时在 CodeArts 中配置 CI/CD，把构建、测试、部署串起来，让后续每次提交都自动走一遍。

这个示例刻意做得很小，目的是让每个 Agent 的输入输出都能被人工核对。真实项目里流程一样，只是每一步的产出物更多、需要拆得更细。

注意事项

关于能力边界

CodeArts Doer 的定位是提升开发效率与软件质量，不是替代评审。它内置了代码保护与安全规则检查，也支持智能测试与自动修复，但生成结果仍然需要人来看。尤其是涉及权限、金额、数据删除这类逻辑，生成代码必须逐行确认。

关于上下文与记忆

这套工具使用了动态记忆算法与「有动机的遗忘」机制，用来关联关键知识、剔除无效信息，从而让代码生成更准确。这意味着上下文不是越多越好：把无关的历史讨论、废弃的需求塞进对话，反而会稀释有效信息。每次切换 Agent 时，只带当前环节需要的那部分产出物。

关于多 Agent 协作

Agent 之间的连通是为了打破沟通壁垒、提高信息传递的准确性与效率。但连通不等于自动同步，交接时仍然要明确「上一步的哪份产出物交给下一步」。团队协作中建议约定统一的产出物存放位置，避免不同角色各自留一份。

关于版本、价格与配额

服务的可用功能、套餐、配额、支持的区域与部署目标环境都会随时间调整，本文不给出具体数字。开通前、扩容前、接入流水线前，请以官网当前信息为准。

关于适用人群的选择

不同角色不必把六个 Agent 全用上。刚入门的开发者从开发助理的代码生成与补全入手，收益最直接；有经验的开发者更适合用代码优化建议与质量检查；测试人员重点用测试助理；项目管理者用项目助理的进度报告与风险预警；产品人员用产品助理整理需求文档、生成用户故事与交互草图。按角色取用，比全流程硬套更省时间。