# AI Loop

> 运行一个带明确范围、停止条件与人工审批门槛的有界"规格-构建-评审"开发循环，适用于高风险或模糊不清的工作。触发词：ai-loop、开发循环、规格构建评审、spec build review、有界循环、人工审批、迭代预算。

- Skill: `kscz0000/ai-loop` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/ai-loop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/ai-loop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/ai-loop

---


# AI-Loop 技能

## 概述

`ai-loop` 技能为智能体工作流构建一个有界的开发循环。它将流程划分为明确的规划（Spec）、实现（Build）与验证（Review）三个阶段，使智能体在保持需求、风险门槛与停止条件都清晰可见的前提下，构建并修正范围明确的代码改动。

## 何时使用本技能

- 当你需要从零或大幅改动地构建一个功能，并希望智能体在一个清晰有界的工作流中完成整个生命周期（规格、实现、验证）时使用。
- 当你处理的是具有明确范围与约束的独立组件、模块或功能时使用。
- 当用户要求完成一次完整的开发闭环，但工作本身仍然具备清晰的成功标准、合理的验证路径，且不存在悬而未决的安全或产品决策时使用。

## 工作原理

本技能执行一个由规格、构建、评审三个阶段构成的可控开发循环。一旦被调用，智能体将依次推进这些阶段，直到范围内的需求通过验证、触达停止条件或需要人工审批为止。

在开始之前，先定义：

- 构建—评审迭代的最大次数。
- 哪些验证命令或人工检查可作为有效证据。
- 哪些动作需要显式审批，例如破坏性命令、生产变更、对外服务写入或大范围的架构调整。

### 阶段一：规格（规划）

1. 就用户希望构建的功能或应用进行访谈。一次只问一个聚焦的问题，直到你完全理解目标、必备需求、约束以及"完成"的定义。
2. **不要立刻开始构建。**
3. 当你收集到足够信息后，编写一份清晰、详尽的规格说明，并保存到 `specs/<feature-name>.md`。
4. 规格说明必须包含：
   - 目标
   - 精确的需求清单
   - 需要处理的边界情况
   - 一份具体可查的"完成定义"，让别人能据此核对构建结果
   - 迭代预算、验证命令与审批门槛。

### 阶段二：构建（实现）

1. 阅读你刚刚在 `specs/<feature-name>.md` 中创建的规格。
2. 严格按照规格描述进行构建。
3. **不要新增功能**，不要重构无关代码，也不要编造规格中没有的需求。
4. 严格聚焦于兑现规格。列出你覆盖了哪些规格需求，方便后续评审环节核对。

### 阶段三：评审（验证）

1. 将你的实现与 `specs/<feature-name>.md` 进行对照。
2. 逐条核对每项需求是否被满足。列出所有差距、缺陷或缺失片段，并指出每条未通过项对应的具体规格条目。
3. 若存在未通过项且迭代预算尚未耗尽，写出明确的修复方案，然后**回到阶段二（构建）**进行修复。
4. 当下一步修复会改变规格、超出迭代预算、需要执行风险操作，或依赖于规格中未捕获的产品决策时，停下来请求人工介入。
5. 只有当规格中的每条需求全部满足、且所声明的验证证据全部通过时，才能宣告构建通过并结束技能执行。

## 示例

### 示例一：创建一个基础统计工具

**用户：**
> 我想添加一个工具，用于计算一组数字的基础统计量（均值、中位数、众数）。

**智能体（阶段一 - 规格）：**
> 没问题。我们先开始：请问这个统计计算器应该用哪种编程语言实现？另外，对空数组或非法输入应当如何处理？

**用户：**
> 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` - 关于如何向用户进行访谈的标准指南。