loop-readiness

循环就绪度评审

这是一项就绪度评审，不是门槛。它不会给出通过／不通过的判定，也不会提供单一的总体评分——而是按各个维度报告已有内容、缺失内容以及值得考虑的事项，让决定是否启动循环的人全面了解情况。

这里的“循环”是指任何在无人逐步检查的情况下运行多轮迭代的 Agent／进程——例如自动驾驶流程、定时作业、长时间运行的 Agent 工作流或类似机制。本评审关注的是该循环的计划，而非循环本身——评审期间不会执行任何操作。

步骤 1：获取计划

• 如果用户已提供计划（文本或文件路径），就使用该计划。
• 如果没有，且有 grill-design 技能可用，就使用该技能。否则，每次只问用户一个问题，逐步了解计划——它要做什么，以及如何判断运行是否正常。每轮只问一个问题，绝不提出多个问题。

步骤 2：评审各个维度

逐一检查以下四个维度。对每个维度，记录已有内容、缺失内容以及覆盖深度——没有固定的清单需要机械地逐项填写；应根据这个特定循环实际需要的深度作出判断。

2.1 就绪定义（DoR）

是否有书面内容定义了这个循环的用途和边界？根据循环的不同，这可能包括：目标说明、明确的非目标／范围外事项、契约（数据结构、API 边界）、UI 模型或示意图——应根据相关风险深入评审。对于简单的循环，一句话说明目标可能就够了；而涉及生产数据的循环可能需要更多内容。

2.2 前馈

前馈是指在每次迭代之前或期间提供给循环的指导，旨在提高其一开始就采取正确行动的概率——例如规范文档、技能、契约、引导脚本、代码修改工具，以及循环运行时会读取或受其约束的任何内容。请说明这些指导属于：

• 计算型——必须经由确定性工具／脚本／生成器执行
• 推断型——循环会读取文档／技能并作出判断
• 两者皆有，或两者皆无

2.3 反馈

反馈是指在一次迭代／操作之后进行验证，以便发现不良结果。健康的循环通常至少需要一种反馈；具体需要哪些类型、多少种，则应根据该循环实际可能造成的影响作出判断。请检查以下内容：

• 计算型／模拟／试运行——单元测试、代码检查工具、类型检查、结构检查。这类检查成本低、速度快，可在每次迭代中运行，但即使遗漏了真实环境中的故障，也可能通过——如果这是唯一的反馈机制，请注明这一权衡。
• 真实环境——针对循环将要操作的实际系统进行验证。请说明是否存在，以及是否适合在无人值守的情况下安全运行（参见步骤 3 中的具体检查——这些检查同样适用）。
• 推断型——由大模型充当评判者，或执行评审步骤，对结果作出语义判断，而非进行确定性检查。

2.4 完成定义（DoD）

计划是否说明了循环实际上会如何停止？无需使用特定术语，也没有固定的一组终止状态——循环可以按照其作者定义的任何方式结束。请说明计划是否考虑了正常成功路径以外的情况：失败时会发生什么？如果循环无法判断是否成功（结果不明确、缺少前置条件等），又会发生什么？如果没有考虑这些情况，应指出这是一个缺口，但不必要求采用任何特定的解决办法。

第 3 步：报告

对于上述 4 个维度中的每一个，提供：

• 一份简短清单，列出已有 / 缺失 / 部分具备的内容
• 针对该维度的一句定性说明（例如“扎实”“薄弱”“缺失”）

不要将这些内容综合成一个总体评分或标签——四条说明各自独立，由读者自行权衡。

然后根据发现的具体差距，补充可执行的建议——给出具体的后续步骤，而不只是说“缺少某项内容”。对于在 2.3 中发现的任何真实环境反馈机制，直接核查（这适合静态审查——通常根据计划中的描述就能明确判断是或否），并针对缺失项提出改进建议：

• 是否有一个预检步骤，能在循环开始执行实际工作之前验证凭据 / 权限确实有效（而非假定它们有效）？如果没有，建议添加一个——在循环无人值守运行之前，先针对真实系统测试一次。
• 对于计划视为已存在的任何反馈机制（例如门禁脚本、测试套件、从先前工作继承的检查）——而非循环将新建的机制——自计划编写以来是否做过冒烟测试？静态审查时，计划对门禁的描述可能完全准确，但计划制定与执行之间发生的无关变更，仍可能悄悄破坏它（例如，其他地方的硬编码路径被重命名）；只有实际运行门禁才能发现这一点，而静态审查有意无法发现。如果没有，建议先对其运行 loop-preflight 技能，再将其视为可用的反馈机制——该技能会实际运行它，因此本次审查本身仍无需违反下方的“绝不执行计划”规则。
• 访问权限是否按最小权限原则设定——不超出任务所需范围？如果不是，建议缩小权限范围。
• 是否默认只读？如果循环只需观察，却仍持有写入权限，建议移除该权限。
• 如果循环确实需要写入，写入权限是否限定在实际安全的环境中（例如沙箱、非生产目标或类似环境），而不是在面向读取的检查上附加写入能力？如果不是，建议在循环开始无人值守运行之前修正权限范围。

其他建议示例：

• 没有记录循环的目标或边界（DoR）→ 建议在开始前至少写明一句目标和明确的非目标，以免范围在运行过程中逐渐偏移
• 没有循环可遵循的指导 / 规范（前馈）→ 建议指向现有文档 / 技能 / 契约；若不存在，则编写一份简短说明
• 只有模拟 / 空运行反馈，没有针对真实目标的反馈 → 建议至少添加一项真实环境检查；如果循环影响较小，也可以明确接受这一风险
• DoD 中没有升级处理 / 阻塞状态 → 建议定义一种方式，让循环在无法判断是否成功时停止并交由人工处理

建议仅供权衡，并非继续执行前必须满足的要求。

规则

• 绝不执行待审查计划中的任何内容——这是对计划描述的静态审查，不是对计划能否实际运行的测试。
• 绝不作出通过 / 不通过的判定，也不提供单一的总体评分 / 标签——只提供各维度的说明。
• 绝不要求 DoD 终止状态使用特定术语，也不要求 DoR 采用固定清单——应根据该循环的具体风险评估已有内容是否充分。
• 绝不写入任何其他文件——例如 grill session；除非用户明确要求保存到某处，否则本次审查应留在对话中（或作为回复返回）。