---

name: closed-loop-delivery description: 当编码任务必须根据明确的验收标准完成，且在实现、审查反馈、部署和运行时验证过程中需要最少用户重新干预时使用。 risk: safe source: community date_added: "2026-03-12"

闭环交付

概述

将每个任务视为未完成，直到验收标准通过证据验证——而非仅仅代码被修改。

核心规则：根据 DoD（完成定义）交付，而非根据代码差异大小。

何时使用

在以下情况使用本技能：

• 用户给出编码/修复任务并期望端到端完成
• 任务跨越代码 + 测试 + PR 评论 + 开发部署 + 运行时检查
• 应避免重复的手动提示如"现在测试"、"现在部署"、"现在重新检查 PR"

不要在以下情况使用本技能：

• 纯问答/解释
• 没有明确人工批准的生产部署请求
• 被缺失的密钥/账户访问阻塞且无法推断的任务

必需输入

执行前定义一次：

• 任务目标
• 验收标准（DoD）
• 目标环境（默认 dev）
• 最大迭代轮数（默认 2）

如果缺少验收标准，请求一次。如果用户不提供，提出具体默认值并继续。

Issue 门控依赖

执行前，优先使用 create-issue-gate。

• 如果 issue 状态为 ready 且执行门控为 allowed，继续。
• 如果 issue 状态为 draft，不执行实现/部署/审查循环。
• 在开始执行前要求用户提供可测试的验收标准。

默认工作流

1. 定义 DoD

   • 将请求转换为可测试的标准。
   • 示例：结账任务 DoD = "结账端点在 dev 中返回有效的、可打开的第三方支付 URL"。

2. 实现最小变更

   • 保持范围紧贴任务目标。

3. 本地验证

   • 先运行聚焦测试，需要时再运行更广泛的检查。

4. 审查循环

   • 获取 PR 评论/审查。
   • 分类有效 vs 不可操作的。
   • 修复有效项，重新运行验证。

5. 开发部署 + 运行时验证

   • 当运行时行为重要时部署到 dev。
   • 通过真实 API/Lambda/日志证据对照 DoD 验证。

6. 完成决策

   • 仅在所有 DoD 检查通过时报告"完成"。
   • 否则继续循环直到通过或达到停止条件。

PR 评论轮询策略

默认避免嘈杂的短轮询。使用批量窗口：

• 第 1 轮： 等待 3m，收集增量评论/审查
• 第 2 轮： 等待 6m，再次收集增量
• 最后一轮： 等待 10m，收集所有剩余可见评论/审查

每轮：

• 批量处理所有新评论
• 避免每条评论后立即重新轮询
• 10m 轮后，停止等待并处理该时间点所有可见评论

如果 CI 仍在运行，将轮询对齐到完成边界而非固定快速轮询。

人工门控规则（必须询问）

以下情况需要明确的用户确认：

• 超出约定范围的生产/预发布部署
• 破坏性操作（历史重写、强制推送、数据破坏性操作）
• 涉及计费/安全态势变更的操作
• 仓库/运行时中不可用的密钥值
• 实质性改变结果的模糊 DoD

迭代/停止条件

在以下情况停止并升级，附带简洁的阻塞报告：

• 最大轮数后 DoD 仍然失败（默认 2）
• 外部依赖阻塞进展（提供商故障、缺失凭证、账户权限）
• 冲突的审查指令无法同时满足

升级报告必须包含：

• 通过了什么
• 失败了什么
• 证据（命令/日志/API 结果）
• 用户需要做的最小决策

输出契约

声称完成时，始终包含：

• 验收标准检查清单及通过/失败状态
• 运行的命令/测试
• 运行时证据（端点/Lambda/日志关键行）
• PR 状态（新的可操作评论数量）

没有证据不要声称成功。

限制

• 仅在任务明确匹配上述范围时使用本技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需输入、权限、安全边界或成功标准，请停下来要求澄清。