loop

循环

概述

将请求的任务作为迭代式实现流程执行。实现更改、审查结果、修复所有可处理的问题，然后重复上述过程，直到审查通过，或出现确实阻碍后续工作的因素。

操作规则

• 由协调 Agent 负责整个流程。可让审查者进行独立检查，但由主 Agent 决定要修复的问题、执行修复并验证最终状态。
• 发现审查问题后不要停止。先修复，再进行新一轮审查。
• 除非能够证明审查发现不正确、重复、在现有上下文中无法处理或超出用户请求范围，否则都应视为可处理的问题。
• 只要仍存在已知的正确性、安全、数据丢失、回归、构建、测试或用户可见缺陷，就不要声称流程已完成。
• 保留与任务无关的用户更改。如果审查发现涉及无关的未提交工作，应指出这一点，而不是重写相关内容。
• 如果执行环境支持待办列表、计划或任务清单，应在实现前创建清晰、详细的待办列表，并在每一轮审查和修复中及时更新条目状态。
• 长时间执行流程时应持续向用户同步进展，尤其是在进行重大修改前以及每轮审查后。

工作流

1. 理解任务并检查相关仓库上下文。
2. 如果执行环境支持，应创建有用的待办列表，详细跟踪实现、验证、审查和后续修复。
3. 使用仓库现有模式实现请求的更改。
4. 执行与更改最相关的验证。
5. 对实现进行一轮审查。
6. 如果审查发现可处理的问题，修复这些问题。
7. 重新运行受影响的验证。
8. 再次进行审查。
9. 持续重复步骤 6–8，直到审查不再发现可处理的问题。
10. 总结最终状态、已执行的验证，以及任何剩余阻碍或明确暂不处理的问题。

审查模式

选择能提供可靠覆盖范围的最精简审查方式：

• 对范围小、风险低且仅涉及单一区域的更改，进行自我审查。
• 对范围广、安全敏感、涉及多处改动、代码不熟悉的更改，或用户要求独立审查时，可并行使用一个或多个审查 Agent。
• 如果按关注点拆分能提升审查质量，可让审查者分别检查正确性、测试、用户体验、性能、安全或文档等方面。
• 向审查者提供任务、已更改的文件或差异，以及验证结果。不要暗示期望的答案，也不要要求他们敷衍认可。

审查标准

每轮审查都应检查：

• 是否完整满足用户请求。
• 更改是否符合现有架构、命名、风格和职责边界。
• 错误处理、边界情况以及回滚或失败处理是否合理。
• 测试或验证是否覆盖此次更改涉及的高风险行为。
• 是否引入无关编辑、机密信息、生成文件噪声或仅适用于本地的假设。
• 行为发生变化时，是否更新了文档或面向用户的文本。

修复审查发现的问题

对于每项可处理的问题：

• 通过复现或检查，充分了解问题。
• 修复根因，而不仅仅是表面症状。
• 如果这是行为缺陷，且仓库中有合适的测试入口，则添加或更新测试。
• 首先重新运行范围最小且有效的验证；根据风险或仓库规范，再运行更全面的检查。
• 维护简短的内部问题记录，跟踪每项问题的状态，避免在反复审查中遗漏。

如果问题未修复，必须说明具体原因：误报、重复、超出范围、缺少必要前提而受阻，或需要用户决定产品方向。应在最终回复中明确说明。

停止标准

仅在满足以下条件之一时停止：

• 一轮审查未发现可执行的问题，且相关验证已通过，或已如实说明无法进行验证。
• 经过认真尝试仍无法解决同一阻碍，导致工作无法推进，例如缺少凭据、服务不可用、外部依赖故障，或无法安全推断的产品决策存在歧义。
• 用户明确要求暂停、停止或改变方向。

不要仅仅因为完成了一轮审查和修复就停止。只有工作已无问题时，循环才算结束，而不是首次解决审查意见时。

最终回复

总结以下内容：

• 做了哪些更改。
• 进行了多少轮审查，以及最后一轮审查的结论。
• 验证命令及结果。
• 尚未解决的问题、阻碍或有意推迟的事项。