Task 运行结束后，需要了解究竟发生了什么—改动了什么、是否奏效，以及如果出了问题，该如何继续推进。

查看结果与 Archive

打开已完成 Task 的结果

点击任意 Task 卡片—无论是运行中、已完成还是已归档—即可打开其结果视图。其中包含：

• 对所做工作及其原因的摘要
• 被更改文件的完整列表
• Pipeline 各步骤的结果（每步通过/失败）
• 运行期间捕获的所有截图（如果启用了可选的 Snapshot 步骤）
• 元数据：耗时、由哪个 AI 提供商/模型处理，以及指向 Git 提交的链接

理解判定结果

有两类自动化检查会产生判定。单元测试判定很直接，即通过或失败，依据的是项目现有的测试套件。端到端 (E2E) 判定的可能结果更多一些，因为 E2E 测试针对的是真实运行的应用：

处理失败的 Task

failed 状态表示 Pipeline 遇到了无法在重试预算内自行解决的问题。打开该 Task 即可看到是哪个步骤失败、记录的原因，以及 Watchdog 若先尝试过自动恢复时给出的诊断。从这里通常可以从失败的步骤恢复该 Task（如果修复需要从更早的位置开始，则从更早的步骤恢复），而不必从头重新开始—AITM 会保留所有已成功的内容。

处理冲突

conflict 状态表示 AITM 的自动 Git 合并遇到了真正的冲突—两处更改以不兼容的方式修改了相同的行—而其 AI 辅助的解决尝试无法安全地自行处理。出现这种情况时，AITM 会准确显示哪些文件发生了冲突，以便您解决；当两处更改看起来都是有意为之时，它绝不会猜测并悄悄地选择其中一方。

Archive

Task 完成且其更改已合并到 dev 后，就会归入 Archive—这是一份可搜索的记录，涵盖每个已完成的 Task，按时间倒序排列，包含标题、项目、完成日期和最终状态。它是您永久的审计轨迹。

在 Archive 中可以搜索和筛选 Task（按项目、日期或状态），并打开其中任意一个的完整记录：原始提示词、Pipeline 步骤、审查判定、测试结果，以及由 Docs 步骤撰写的、用通俗语言描述更改内容的摘要。已归档的 Task 并未被锁死—Restore 会将其放回队列。若要在旧工作的基础上做变体，通常以归档的提示词为起点创建一个新 Task 会更干净。