使用agent团队的开发记录

使用 TRAE Agent Team 开发校园记账工具：从角色分工到测试验收

一、任务目标

本次作业围绕校园消费记账工具展开，使用 TRAE 中的主控 SOLO Agent 调度开发、审查和测试三个子 Agent，完成需求实现、代码评审、测试与问题修复。

程序面向大学生日常生活费管理，包含消费录入、记录删除、月份筛选、分类统计、月度预算提醒和本地数据保存功能。技术方案采用 HTML、CSS 和 JavaScript，使用 localStorage 保存数据，将金额计算、月份筛选和预算判断提取为独立函数，便于测试。

二、Agent 团队配置与分工

我在 Agent 面板中创建了三个子 Agent，并将它们添加到主控 SOLO Agent 的可调用列表中。各角色的职责和权限如下：

Agent	主要职责	权限与约束
主控 SOLO Agent	分解需求、安排任务、汇总问题、组织回归验证	统一协调流程和验收标准
CodeWriter	编写业务代码，根据问题清单完成修复	读写业务文件，进行基础自检，不编写测试用例
CodeReviewer	审查代码规范、边界条件和潜在风险	只读源码，输出分级评审意见
TestEngineer	编写并运行测试，记录失败原因与复现步骤	读取源码、写入测试文件和报告、执行测试，不修改业务实现

配置时，我特别补充了 TestEngineer 对测试目录和报告目录的写入权限。因为测试角色不仅需要读取代码，还需要将测试用例保存为文件，才能在终端中执行并保留结果。

三、主控 Agent 的任务提示词

你作为主控 SOLO Agent，调度 CodeWriter、CodeReviewer 和 TestEngineer 完成校园消费记账工具。功能包括新增与删除记录、按月份查询、分类统计、月度预算提醒和本地保存。金额必须大于零且最多两位小数，金额计算采用整数分。

先委派 CodeWriter 实现业务代码并返回文件清单；随后交给 CodeReviewer 审查，存在严重问题时先修复并复审；审查通过后，由 TestEngineer 编写和执行测试。测试失败时，将复现步骤、预期结果和实际结果交给 CodeWriter 修复，再进行复审与回归测试。最后汇总源码、测试代码和测试报告，不得通过删除失败用例或放宽断言来掩盖缺陷。

四、开发与迭代过程

第一阶段：CodeWriter 完成初版

CodeWriter 根据需求完成页面布局、表单提交、消费列表和统计逻辑，并实现本地保存。初版已经可以录入消费和展示支出，但部分业务计算与页面更新耦合较紧，输入边界处理也不够完整。

主控 Agent 收到实现说明后，将代码交给 CodeReviewer，进入评审阶段。

第二阶段：CodeReviewer 审查并反馈问题

审查主要发现了三个问题：金额直接使用小数累加，可能产生精度问题；删除操作依赖列表位置，在筛选后容易定位错误；读取本地数据时缺少完整的异常处理。

CodeWriter 根据意见，将金额统一转换成整数分，为每条记录增加唯一 ID，并补充存储读取异常处理。同时，将核心业务逻辑与界面操作分离。复审确认主要风险得到处理后，主控 Agent 再安排测试。

第三阶段：TestEngineer 编写测试并发现缺陷

TestEngineer 读取需求和源码，围绕金额校验、分类合计、月份筛选、预算状态以及记录删除编写测试。测试预期依据需求和人工计算确定，避免直接照着实现逻辑重复计算。

测试发现，预算提示在“恰好达到预算”时缺少独立状态；另外，删除记录后的预算提示没有在所有情况下同步刷新。测试 Agent 将这些问题整理为包含复现步骤的清单，交回主控 Agent。

第四阶段：修复缺陷并进行回归测试

CodeWriter 调整预算判断顺序，分别处理超支、预算用完、接近预算和正常状态；同时统一新增、删除和月份切换后的刷新入口，使列表、统计与预算提示同步更新。

修复后，CodeReviewer 检查修改涉及的逻辑，TestEngineer 重新执行失败用例和已有测试。回归验证通过后，主控 Agent 汇总业务源码、测试文件、评审意见及测试报告。

五、典型问题与修复记录

问题	复现方式或风险	修复方式	验证结果
金额精度风险	对 0.10 元与 0.20 元进行累加，检查内部合计与显示	使用整数分存储和计算	合计为 30 分，显示 0.30 元
删除定位错误	筛选月份后删除一条记录，再检查其他月份数据	使用唯一 ID 定位，不依赖筛选后的下标	仅目标记录被删除
预算边界不清晰	预算设为 100 元，支出恰好达到 100 元	增加“预算已用完”状态	提示与临界值一致
删除后提示滞后	先使支出超预算，再删除一条消费	统一刷新统计和预算状态	提示随支出变化更新
本地数据异常	读取无法解析的本地存储内容	捕获异常并提示，不静默覆盖原数据	页面显示异常信息

六、测试验收与结果分析

自动化测试重点覆盖纯业务逻辑，包括非法金额拦截、金额累加、分类汇总、月份筛选、预算阈值和按 ID 删除。界面交互则通过手动操作检查，确认输入提示、删除确认、空状态以及刷新后的数据恢复符合要求。

人工交叉验证时，我录入餐饮 18.50 元、交通 2.00 元和学习 35.80 元，总支出应为 56.30 元；删除交通记录后，应变为 54.30 元。页面总额、分类合计和预算剩余额度保持一致，刷新后记录也能够正确恢复。

最终，本轮测试用例与界面验收项目均通过，发现的问题完成修复和回归验证。测试结论对应本次覆盖的需求与场景，跨设备同步等未纳入需求的能力不属于本轮验收范围。

七、实践心得

这次实践中，让我印象最深的是角色分工对检查问题的帮助。开发 Agent 关注如何实现功能，审查 Agent 关注代码中可能存在的风险，测试 Agent 则需要通过具体输入判断程序行为是否符合要求。不同角色围绕同一份需求工作，使问题更容易得到明确描述和追踪。

协作过程中，最需要注意的是信息交接。仅仅告诉开发 Agent“预算功能有问题”，很难保证修改方向正确；给出“预算为 100 元，支出为 100 元时应显示预算已用完”，就能够同时明确复现条件和验收标准。问题清单越具体，修复与复测就越有依据。

我也认识到，多 Agent 不会自动保证正确性。如果需求本身存在歧义，多个角色仍可能沿用同一种错误理解。因此，人工确认需求、检查测试预期和核对最终结果依然必要。对我而言，这次作业的主要收获，是把 AI 辅助编程组织成一个有分工、有反馈、有验证的开发过程，并更具体地理解软件工程中质量控制的意义。