计划执行完毕后的结果确认与交付方法
一个标准的完成汇报
"Plan jp050 executed to completion. All 4 tasks done; state moved to review."
这是助手在完成某个计划后给出的标准汇报。紧接着，它列出了具体的交付内容：
"Delivered: scripts/qclaw_upgrade_doctor.py — new read-only script supporting --before, --after --before-file, --format text|json, --write-report, with diff and smoke integration across apple64/apple/mac."
这个场景看起来简单——助手完成了任务，汇报结果。但如果我们深入分析，会发现这是一套经过设计的协作模式，包含了任务执行、状态管理、结果交付等多个环节。
问题背景：任务完成的"黑盒"问题
在 AI 辅助工作中，一个常见的问题是：用户不知道任务是否真正完成了。
用户可能会说："帮我写一个脚本"。助手可能会回复："我已经写好了，保存在某个位置。"但是：
- 脚本是否真的能运行？
- 是否符合用户的所有要求？
- 用户如何验收？
如果助手只是说"我完成了"，而没有提供具体的验证方法，用户就难以确认任务的实际完成度。这就是任务完成的"黑盒"问题。
这个案例中的汇报结构
让我们拆解这个案例中助手的汇报结构：
要素一：计划标识
"Plan jp050 executed to completion" —— 这里明确指出是哪个计划完成了。当用户同时推进多个任务时，清晰的标识能避免混淆。
要素二：任务统计
"All 4 tasks done" —— 提供具体的任务数量，让用户对工作量有直观感知。这不是模糊的"我完成了任务"，而是可量化的"4个任务全部完成"。
要素三：状态变更
"state moved to review" —— 这揭示了计划的状态管理机制。完成不是终点，而是进入下一个阶段：用户审核。这种状态机的设计，让协作更有节奏感。
要素四：交付清单
"Delivered:" 之后列出了具体的产出物。不只是说"我写了一个脚本"，而是详细描述了这个脚本的功能：
- 文件路径：
scripts/qclaw_upgrade_doctor.py - 功能特性：支持
--before、--after --before-file等参数 - 格式支持：
--format text|json - 集成范围：覆盖 apple64/apple/mac 三个环境
这种详细的交付说明，让用户能够立即评估产出是否符合预期。
从单次汇报到工作方法
这个场景揭示了一种可复用的工作方法：execute-to-completion 模式。
这种模式的核心是：任务执行不是以"助手说自己完成了"为终点，而是以"用户提供验收确认"为终点。
让我们拆解这个模式的完整流程：
阶段一：执行前确认
在开始执行前，明确任务的目标、范围、验收标准。这个阶段建立的是"契约"。
阶段二：执行中跟踪
执行过程中，提供进度反馈。不是等到最后才说"完成了"，而是在关键节点更新状态。这样用户可以及时发现问题，避免偏离预期。
阶段三：执行后汇报
这就是本案例展示的内容。汇报要包含：计划标识、任务统计、状态变更、交付清单。这个汇报的质量决定了用户能否高效验收。
阶段四：用户验收
用户根据交付清单进行验收。可能通过测试脚本、检查输出、阅读代码等方式确认结果。如果发现问题，返回修改；如果通过验收，计划才真正"完成"。
阶段五：状态归档
验收通过后，计划进入"完成"状态，相关信息归档保存。这为未来的复盘和复用提供基础。
为什么这种模式有效？
这种 execute-to-completion 模式之所以有效，是因为它解决了协作中的几个核心问题：
问题一：信任问题
用户如何相信助手真的完成了任务？详细的交付清单提供了验证依据，用户可以据此检查产出。
问题二：验收问题
用户如何验收？明确的状态（review）告诉用户"现在轮到你检查了"。这不是助手的自说自话，而是邀请用户参与的协作流程。
问题三：连续性问题
如果任务没有完成，后续怎么处理？状态管理机制（如 review → completed 或 review → in_progress）提供了明确的流转路径。
问题四：复用问题
完成后，这些信息有什么用？归档的交付记录可以作为未来类似任务的参考，形成知识积累。
可以提炼的工作原则
从这个案例中，我们可以提炼出几个通用的协作原则：
原则一：完成汇报要有结构
不是简单说"我完成了"，而是遵循"标识 + 统计 + 状态 + 交付"的结构。这种结构化的汇报，便于用户快速获取关键信息。
原则二：交付物要有详细说明
不只是列出文件名，还要说明功能特性、使用方法、覆盖范围。这样用户才能判断产出是否符合预期。
原则三：明确"下一步是什么"
状态变更为 review，暗示了用户需要做什么。好的协作不只是汇报结果，还要引导后续行动。
原则四：建立状态机思维
任务不是"完成"或"未完成"的二选一，而是有多个中间状态。这种状态机思维，让协作更有节奏感和可控性。
一个更大的启示
这个场景还揭示了协作中的一个深层问题：责任的边界。
在传统的"帮手"模式中，助手完成任务后就结束了，验收是用户的事。但在 execute-to-completion 模式中，助手承担了更多责任：不仅要执行任务，还要提供验收依据，甚至引导验收流程。
这种模式要求助手不只是"执行者"，更是"协作者"。它需要站在用户的角度思考：用户需要什么信息才能高效验收？我如何降低用户的认知负担？
这，就是从"完成任务"到"交付价值"的升级。
结语
"Plan jp050 executed to completion" 这句话，看起来只是一个简单的完成汇报。但它背后体现的是一套完整的协作方法：结构化的汇报、详细化的交付、状态化的管理。
这种方法的价值在于：它让任务完成不再是模糊的"我做好了"，而是可验证、可追踪、可复用的协作节点。
每一次这样的汇报，都是一次工作方法的示范。理解了背后的逻辑，就能在其他协作场景中应用这套方法，提升整体的协作效率和质量。
从单次汇报到工作方法，这就是协作经验的沉淀过程。