交付不只是一句“已完成”。
将工作目标、已有资料与执行过程放在同一条可核对的路径上。团队查看变更、检查与产物，再决定是否接受结果，而不是只依赖 Agent 的最后一条回复。
一次明确工作，需要哪些对象
输入决定这次要完成什么
任务要求记录目标、不应改变的行为与验收条件。按权限添加知识库资料、Markdown 或当前部署启用的来源；研发任务还需要已授权的仓库、基线分支和流程输入。
对话、研发 Task 与 Automation Run 是不同入口。这里的节点、变更与 PR/MR 审阅，主要说明研发任务的交付路径，不能套用到全部日常会话。
证据说明实际发生了什么
任务详情将节点进度、会话、上下文、变更、冻结修订、产物和 Trace 分开呈现。检查时先对应同一节点与执行尝试，再判断证据是否支持交付说明。
流程与能力的发布版本为执行提供依据；中间节点的冻结文件与最终分支代表不同时间点，不能相互替代。
从目标到审阅，让每一步有判断依据
明确目标和验收条件
缩小工作范围，写清输入、约束和预期结果。先确认资料版本、仓库与分支，而不是让执行自己猜测业务边界。
准备并检查执行条件
选择适用的已发布流程或智能编排，补齐必填输入。创建检查通过后再准备运行环境；授权失败与执行失败分别处理。
跟随进度，核对执行证据
查看当前节点与等待输入的问题。需要定位偏差时，结合上下文、变更和 Trace，而不是只阅读结果摘要。
审阅产物，保留人的决定
确认修改范围、实际检查结果与交付链接，再按团队流程决定是否接受、合并或发布。平台记录执行完成，不代表人已经验收。
真实界面如何呈现交付
查看原图 ↗先区分执行完成、验收和上线
检查通过只支持对应检查项。PR/MR 存在还需要核对目标仓库、分支与差异；合并、部署和真实业务验收是后续独立决定。本页不承诺无人审阅或自动上线。
出现问题时，保留历史而不是改写历史
授权或预检失败，先修正创建条件；等待输入时，回复当前执行的问题。对具备恢复条件的任务，可以从明确节点继续，产生新的执行尝试并保留旧记录。
恢复不会自动撤回已经发生的外部操作。需求、仓库基线或流程需要改变时，应核对重建或新任务的输入，不假定一次重试就能安全覆盖全部状态。
继续了解
从一项真实工作开始
看看 AI 如何成为
你们的工作能力。
围绕工作场景、现有系统与治理要求，梳理值得验证的第一步。
仅在本地预览预约信息，
不发送、不保存，不构成实际预约。