任务结果与验收

Heicode 中的 completed 只能表示执行流程已经结束，不能单独证明代码正确、测试通过或原始问题已经解决。

四种不同的成功

这四个状态不能互相替代。Agent 可以完成执行但没有修改文件，也可以修改代码但测试失败，还可能测试通过但没有覆盖真正的问题。

最低验收证据

每个开发任务至少应提供以下证据：

• 修改文件列表；
• 关键 Diff 摘要；
• 实际执行的验证命令；
• 命令退出码；
• 测试通过、失败和跳过数量；
• 未验证的平台或场景；
• 人工介入记录；
• 已知风险与回滚方式。

推荐结果卡

任务状态：已完成
代码修改：7 个文件
测试执行：42 项
测试通过：40 项
测试失败：2 项
未验证内容：Windows 构建
人工介入：1 次
结论：需要复核，不应直接发布

验收顺序

1. 检查是否真的修改代码

确认工作区存在 Diff，并排除只生成报告、只修改注释、只更新锁文件或只输出建议但没有实际实现的情况。

2. 检查修改范围

将变更文件与任务范围逐一对照。若任务只要求修复一个接口，却修改了大量无关模块，应视为高风险结果。

3. 检查测试是否真实执行

不要只接受自然语言总结。应查看：

• 完整命令；
• 工作目录；
• 开始和结束时间；
• 退出码；
• 标准输出和错误输出摘要。

若测试命令未找到、超时、被跳过或因环境错误中断，不能记为通过。

4. 检查测试是否覆盖原问题

新增测试应能够在修复前失败、修复后通过。只验证内部实现细节、固定返回值或模拟全部依赖的测试，可能无法证明真实问题已解决。

5. 检查回归风险

除目标测试外，还应执行受影响模块的测试、构建、类型检查、静态检查或人工场景验证。

无测试仓库的处理

无自动化测试时，应至少记录：

• 使用了哪些人工验证步骤；
• 验证了哪些输入与输出；
• 哪些场景无法覆盖；
• 为什么认为风险可接受。

此类任务的结果应标记为“人工验证”或“需要复核”，不应伪装成自动测试通过。

Agent Swarm 的额外验收

多 Agent 场景还应检查：

• 各 Agent 是否重复修改同一文件；
• 聚合结果是否遗漏某个 Agent 的有效修改；
• 冲突是否被正确处理；
• Team Lead 的总结是否与最终工作区一致；
• 失败 Agent 的部分结果是否被误判为成功。

发布前要求

生产发布前，应由独立于执行 Agent 的人员或流程完成代码审查、测试和发布审批。Heicode 的任务状态不能替代团队现有的 CI、Review 和发布门禁。