kscz0000 AI-Loop 技能
概述
ai-loop 技能为智能体工作流构建一个有界的开发循环。它将流程划分为明确的规划（Spec）、实现（Build）与验证（Review）三个阶段，使智能体在保持需求、风险门槛与停止条件都清晰可见的前提下，构建并修正范围明确的代码改动。
何时使用本技能
- 当你需要从零或大幅改动地构建一个功能，并希望智能体在一个清晰有界的工作流中完成整个生命周期（规格、实现、验证）时使用。
- 当你处理的是具有明确范围与约束的独立组件、模块或功能时使用。
- 当用户要求完成一次完整的开发闭环，但工作本身仍然具备清晰的成功标准、合理的验证路径，且不存在悬而未决的安全或产品决策时使用。
工作原理
本技能执行一个由规格、构建、评审三个阶段构成的可控开发循环。一旦被调用，智能体将依次推进这些阶段，直到范围内的需求通过验证、触达停止条件或需要人工审批为止。
在开始之前，先定义：
- 构建—评审迭代的最大次数。
- 哪些验证命令或人工检查可作为有效证据。
- 哪些动作需要显式审批，例如破坏性命令、生产变更、对外服务写入或大范围的架构调整。
阶段一：规格（规划）
- 就用户希望构建的功能或应用进行访谈。一次只问一个聚焦的问题，直到你完全理解目标、必备需求、约束以及"完成"的定义。
- 不要立刻开始构建。
- 当你收集到足够信息后，编写一份清晰、详尽的规格说明，并保存到
specs/<feature-name>.md。 - 规格说明必须包含：
- 目标
- 精确的需求清单
- 需要处理的边界情况
- 一份具体可查的"完成定义"，让别人能据此核对构建结果
- 迭代预算、验证命令与审批门槛。
阶段二：构建（实现）
- 阅读你刚刚在
specs/<feature-name>.md中创建的规格。 - 严格按照规格描述进行构建。
- 不要新增功能，不要重构无关代码，也不要编造规格中没有的需求。
- 严格聚焦于兑现规格。列出你覆盖了哪些规格需求，方便后续评审环节核对。
阶段三：评审（验证）
- 将你的实现与
specs/<feature-name>.md进行对照。 - 逐条核对每项需求是否被满足。列出所有差距、缺陷或缺失片段，并指出每条未通过项对应的具体规格条目。
- 若存在未通过项且迭代预算尚未耗尽，写出明确的修复方案，然后**回到阶段二（构建）**进行修复。
- 当下一步修复会改变规格、超出迭代预算、需要执行风险操作，或依赖于规格中未捕获的产品决策时，停下来请求人工介入。
- 只有当规格中的每条需求全部满足、且所声明的验证证据全部通过时，才能宣告构建通过并结束技能执行。
示例
示例一：创建一个基础统计工具
用户：
我想添加一个工具，用于计算一组数字的基础统计量（均值、中位数、众数）。
智能体（阶段一 - 规格）：
没问题。我们先开始：请问这个统计计算器应该用哪种编程语言实现？另外，对空数组或非法输入应当如何处理？
用户：
JavaScript。数组为空时返回 null。遇到非数字时直接忽略。
智能体（阶段一 - 规格）：
收到。我已在
specs/stats-calculator.md中写入了我们讨论的需求规格。接下来我会开始实现。
智能体（阶段二 - 构建）：
（创建
stats_calculator.js，严格按照规格实现mean、median与mode） 我已完成计算器的实现，接下来进入验证环节。
智能体（阶段三 - 评审）：
正在对照
specs/stats-calculator.md检查实现：
- 需求：均值计算 -> 通过
- 需求：中位数计算 -> 通过
- 需求：众数计算 -> 通过
- 需求：空数组返回 null -> 通过
- 需求：忽略非数字 -> 未通过（发现
mode没有过滤非数字）。现在回到阶段二，修复
mode函数。
智能体（阶段二 - 构建回退）：
（修复
mode，使其过滤掉非数字） 已更新实现，重新进行验证。
智能体（阶段三 - 评审）：
- 需求：
mode过滤非数字 -> 通过
所有需求已全部通过！统计计算器已完成并通过验证。
最佳实践
- ✅ 在规划阶段，每次只问一个澄清问题，避免让用户不堪重负。
- ✅ 在动手写代码前，于
specs/<feature-name>.md中明确记录边界情况。 - ✅ 在构建阶段严格遵循已批准的规格。
- ✅ 为循环设定一个较小的迭代预算，预算耗尽时如实汇报剩余事项。
- ✅ 在执行破坏性、生产环境、涉及凭据或对外可见的操作前暂停，等待显式审批。
- ❌ 不要实现规格之外的多余功能，也不要进行无关的重构。
- ❌ 不要跳过评审环节，更不要在未逐条核对所有需求的情况下让其通过。
- ❌ 不要在没有新证据或新思路的情况下，对同一处失败修复反复重试。
局限性
- 本技能要求在规格阶段提供充分的功能上下文。
- 它最适用于边界清晰的独立功能或任务，而非开放式的大规模架构重构。
- 评审阶段依赖智能体对照生成的规格进行自评；对于关键系统，仍建议人工复核。
- 它不能替代人类对安全敏感、破坏性、生产、合规或对外可见变更的审批。
- 当需求互相冲突、测试无法运行、或验证依赖于不可用的凭据或系统时，应停止而非继续。
安全提示
- 在执行或测试构建阶段生成的代码时务必谨慎，所有测试都应在安全、沙盒化的环境中运行。
- 避免未经安全性校验就直接执行用户提供的任意 shell 命令。
- 确保不会向代码或规格说明中加入硬编码的密钥、密钥串或凭据。
- 将生产部署、数据迁移、支付流程、凭据变更以及对外写入操作视为需要审批门槛的工作。
常见陷阱
- 问题： 智能体试图一次性构建一个庞大的系统，导致规格过度复杂、实现残缺。
对策： 将
ai-loop的范围控制在小型、模块化的功能上。把更大的系统拆解成多个相互独立的循环。 - 问题： 规格含糊不清，使构建阶段不得不依赖猜测。 对策： 在规划阶段多花时间提出有针对性的问题，把需求钉死。
相关技能
@plan-writing- 用于为更大的项目撰写更详尽的实施计划。@ask-questions-if-underspecified- 关于如何向用户进行访谈的标准指南。