用途
ai-loop 技能为智能体工作流构建一个有界的开发循环。它把过程划分为规划（Spec）、实现（Build）和验证（Review）三个不同阶段，帮助智能体在保持需求、风险门禁和停止条件明确的前提下，构建并修正限定范围的代码变更。
何时使用
- 需要从零构建或大幅修改某个功能，并希望智能体在一个清晰有界的工作流内处理完整生命周期（规格说明、实现和验证）时使用。
- 处理具有明确定义的范围和约束的独立组件、模块或功能时使用。
- 用户要求完成一次完整开发，但工作仍有清晰的验收标准、合理的验证路径，且没有未解决的安全或产品决策时使用。
工作原理
该技能执行一个由三个阶段组成的受控开发循环：Spec、Build 和 Review。被调用后，智能体会依次经过这些阶段，直到限定范围的需求通过验证、达到停止条件或需要人工批准。
开始前需定义：
- 构建-审查迭代的最大次数。
- 作为证据的验证命令或人工检查。
- 需要明确批准的操作，例如破坏性命令、生产变更、外部服务写入或大规模架构调整。
阶段一：Spec（规划）
复用当前请求、已接受的计划和现有产物。只询问必要的缺失范围或验收标准；不要重复已回答的问题。
此时不要开始构建。
当信息足够时，使用现有规格说明，或在需要时在 specs/<feature-name>.md 保存一份限定范围的新规格，且不覆盖用户的工作。
规格必须包含：
- 目标
- 确切需求
- 需要处理的边界情况
- 可供他人对照检查构建结果的具体完成定义
- 迭代预算、验证命令和批准门禁。
阶段二：Build（实现）
读取刚在 specs/<feature-name>.md 中创建的规格。
严格按规格描述构建。
不要添加功能，不要重构无关代码，不要发明规格中不存在的需求。
严格专注于满足规格。列出已覆盖的规格需求，以便审查步骤可以核对。
阶段三：Review（验证）
将实现与 specs/<feature-name>.md 对照。
逐条需求验证是否满足。列出每个缺口、缺陷或缺失部分，并指明其对应的具体规格条目。
如果有任何失败且迭代预算未耗尽，写出所需的具体修复，并循环回阶段二（Build）处理。
使用约定的迭代/资源限制和范围。对尚未解决的重大产品或后果性授权决策请求批准；已接受结果范围内的常规修复无需新的检查点。当依赖检查不可用时，继续独立工作。
只有当规格中的每项需求都完全满足且声明的验证证据通过时，才通过构建并结束技能执行。
示例
示例一：创建基础统计辅助工具
用户：
我想添加一个用于计算数字数组基础统计量（均值、中位数、众数）的工具。
智能体（阶段一 - Spec）：
我可以帮忙。首先，这个统计计算器应该用什么编程语言实现？另外，空数组或无效输入应如何处理？
用户：
JavaScript。如果数组为空，返回 null。如果有非数字，忽略它们。
智能体（阶段一 - Spec）：
谢谢。我已在 specs/stats-calculator.md 创建了包含我们讨论需求的规格文件。现在开始实现。
智能体（阶段二 - Build）：
（创建 stats_calculator.js 并严格按规格实现均值、中位数和众数） 我已经完成计算器的实现。现在进行验证。
智能体（阶段三 - Review）：
对照 specs/stats-calculator.md 检查实现：
- 需求：均值计算 -> 通过
- 需求：中位数计算 -> 通过
- 需求：众数计算 -> 通过
- 需求：空数组返回 null -> 通过
- 需求：忽略非数字 -> 失败（我注意到众数没有过滤非数字）。
现在循环回阶段二修复众数函数。
智能体（阶段二 - Build 循环返回）：
（修复众数以过滤非数字） 我已更新实现。重新验证。
智能体（阶段三 - Review）：
- 需求：众数过滤非数字 -> 通过
所有需求通过！统计计算器已完成并验证。
最佳实践
- ✅ 在规划阶段一次只问一个澄清问题，避免让用户不堪重负。
- ✅ 在编写任何代码之前，在 specs/<feature-name>.md 中明确记录边界情况。
- ✅ 在构建阶段严格遵守已批准的规格。
- ✅ 用较小的迭代预算限制循环，并在预算耗尽时准确报告剩余内容。
- ✅ 在破坏性、生产、凭据或外部可见操作之前暂停以获取明确批准。
- ❌ 不要实现规格之外的额外功能或进行无关重构。
- ❌ 不要跳过审查阶段，或在未验证每项需求的情况下通过它。
- ❌ 不要在没有新证据或改变方法的情况下反复重试同一个失败的修复。
限制
- 该技能要求在 Spec 阶段提供关于功能的足够上下文。
- 它最适合边界清晰的独立功能或任务，而非开放式架构重构。
- 审查阶段依赖智能体对照生成的规格进行自我评估；对于关键系统仍建议人工审查。
- 它不能替代人类对安全敏感、破坏性、生产、合规或外部可见变更的批准。
- 准确报告冲突需求或不可用的验证，并继续有用的独立工作；不要将缺失的测试标记为通过，也不要在聊天中请求凭据。
安全与安全说明
- 运行或测试 Build 阶段生成的代码时要谨慎。始终在安全、沙箱化的环境中运行测试。
- 避免在未验证安全性的情况下执行用户直接提供的任意 shell 命令。
- 确保代码或规格中不添加硬编码的机密、密钥或凭据。
- 将生产部署、数据迁移、支付流程、凭据变更和外部写入操作视为需批准门禁的工作。
常见陷阱
问题：智能体试图一次性构建庞大系统，导致规格过于复杂且实现不完整。 解决方案：将 ai-loop 的范围保持为小型、模块化的功能。将更大的系统拆分为多个独立循环。
问题：规格模糊，导致构建阶段依赖假设。 解决方案：在规划阶段多花时间提出有针对性的问题，以明确需求。
相关技能
- @plan-writing - 为更大项目编写更详细的实现计划。
- @ask-questions-if-underspecified - 关于访谈用户的标准指南。