迭代优化工作流

提示、观察、再提示，直到满意为止。这是高效 AI 辅助开发的核心循环。

TL;DR

Plain

1. 初始提示，明确目标
2. Claude 产出结果
3. 对照标准评估
4. 具体反馈："因为 Y，所以修改 X"
5. 重复直到完成

核心洞察：具体反馈 > 模糊反馈

循环流程

步骤 1：初始提示

以清晰的意图和约束开始：

Plain

创建一个用户个人资料卡片的 React 组件。
- 显示头像、姓名、个人简介
- 包含编辑按钮
- 使用 Tailwind CSS
- 适配移动端

步骤 2：评估输出

Claude 产出代码。评估：

是否满足需求？
缺少什么？
有什么问题？
哪里可以改进？

步骤 3：具体反馈

提供有针对性的修正：

Plain

好的开始。需要以下改动：
1. 头像应为圆形，而非方形
2. 编辑按钮只对自己的主页显示（添加 isOwner prop）
3. 个人简介超过 3 行后截断，显示"展开更多"

步骤 4：重复

继续直到满意：

Plain

更好了。再改一个地方：
- 添加数据加载时的骨架屏状态

反馈模式

有效反馈

模式	示例
具体位置	"第 23 行：将 `===` 改为 `==`"
明确操作	"在表单外添加错误边界"
给出原因	"删除 console.log，因为它会泄露用户数据"
标记优先级	"关键：修复 SQL 注入。可选：添加分页。"

无效反馈

反模式	为何失效	更好的替代
"改好一点"	没有方向	"通过提取验证逻辑来提升可读性"
"这个不对"	没有具体说明	"日期格式应为 ISO 8601，而非 Unix 时间戳"
"我不喜欢"	太主观	"使用函数组件而非类组件"
"修复 bug"	太笼统	"修复：1) 第 12 行的 null 检查，2) 循环中的差一错误"

自主循环

通过明确的完成标准，Claude 可以自我迭代。

Ralph Wiggum 模式

以自我改进循环模式命名：

Plain

持续提升代码质量，直到：
1. 所有测试通过
2. 无 TypeScript 错误
3. ESLint 显示零警告

每次迭代后，运行检查并修复所有问题。
满足所有标准后停止。

完成标准示例

Plain

迭代直到：
- 第 95 百分位响应时间 < 100ms
- 测试覆盖率 > 80%
- 所有可访问性检查通过
- 包体积 < 200KB

迭代限制

始终设置限制以防止无限循环：

Plain

提升算法性能。
最多 5 次迭代。
如果两次迭代间提升 < 5%，提前停止。

与 Claude Code 集成

与任务工具配合

使用 TaskCreate 和 TaskUpdate 追踪优化迭代：

Plain

TaskCreate: "实现初始版本"
TaskCreate: "修复：处理空数组"
TaskCreate: "修复：添加输入验证"
TaskCreate: "优化：对昂贵计算进行 memoize"
# 进展时用 TaskUpdate 标记已完成

与 Hooks 配合

通过 Claude Code Hooks 在每次修改后自动验证（通过 /hooks 命令或 settings.json 配置）。例如，在编辑工具的工具后钩子（PostToolUse）上可以自动运行代码检查和测试。Claude 看到失败后可以自我修正。

与 /compact 配合

当迭代过程中上下文增长时：

Plain

/compact

继续优化搜索算法。
我们已取得良好进展，专注于剩余的问题。

检查点

在取得重要进展后：

Plain

进展不错。让我们做一个检查点：
- 提交当前的成果
- 列出剩余的问题
- 继续处理下一个优先项

脚本生成工作流

脚本和自动化生成在迭代优化中带来最高回报——实践者报告显示可节省 70-90% 的时间。脚本是自包含的，可独立测试，能立即产生价值。

3-7 次迭代模式

大多数生产就绪的脚本在 3-7 次迭代后成型：

迭代	重点	提示模式
1	基本功能	"创建一个能做到 [目标] 的脚本"
2-3	约束 + 边界情况	"添加 [约束]。处理 [边界情况]。"
4-5	强化	"添加错误处理、日志记录、输入验证"
6-7	打磨	"针对 [指标] 优化。添加使用文档。"

示例：Kubernetes Pod 管理器（PowerShell）

迭代 1 — 基础功能

Plain

创建一个 PowerShell 函数，用于列出 Kubernetes 命名空间中的 Pod。

迭代 2 — 添加过滤

Plain

添加：按标签选择器和 Pod 状态过滤。
显示：Pod 名称、状态、存活时间、重启次数。

迭代 3 — 添加操作

Plain

添加：能够删除匹配过滤器的 Pod。
要求：删除前需要确认。

迭代 4 — 错误处理

Plain

处理：未找到 kubectl、无效命名空间、权限被拒的情况。
添加：带 -Verbose 标志的详细日志记录。

迭代 5 — 生产就绪

Plain

添加：空运行模式、输出到 JSON 便于管道传输、帮助文档。
确保：在 Windows、Linux、macOS 上均可运行。

常见陷阱

陷阱	示例	缓解措施
幻觉命令	macOS 上使用 `apt-get`	指定操作系统："仅限 Ubuntu 22.04"
安全漏洞	无输入验证	始终要求："验证所有用户输入"
过度设计	添加不必要的库	要求："最少依赖，优先使用标准库"
上下文偏移	第 5 次迭代后遗忘需求	检查点提示："在进行下一次修改前先回顾当前需求"
平台假设	在 sh 中假设 bash 特性	指定："POSIX 兼容" 或 "bash 4+"

脚本迭代模板

Plain

当前脚本：[粘贴或引用]

本次迭代目标：[具体改进]

约束：
- 必须保留：[需要保留的现有行为]
- 不得：[需要避免的事项]
- 目标环境：[操作系统、Shell、运行时]

成功标准：[如何验证本次迭代有效]

迭代策略

广度优先

在深入之前修复同一层级的所有问题：

Plain

第一轮：修复所有类型错误
第二轮：修复所有 lint 警告
第三轮：提升测试覆盖率
第四轮：优化性能

深度优先

在移至下一个区域之前完整地完成一个区域：

Plain

1. 完善认证流程（所有方面）
2. 然后转到用户管理
3. 再转到设置

优先级驱动

按重要性处理：

Plain

按此顺序迭代：
1. 安全问题（关键）
2. 数据完整性 bug（高）
3. 用户体验问题（中）
4. 代码风格（低）

反模式

移动目标

Plain

# 错误做法
"其实，让我们完全改变方法……"
（重复 5 次）

# 正确做法
坚定一个方案，在其范围内迭代。
如果方案错误，明确重新开始。

完美主义循环

Plain

# 错误做法
无休止地持续改进

# 正确做法
设置明确的"够好"标准：
- 测试通过
- 处理主要用例
- 无关键问题
→ 发布，之后再改进

迷失上下文

Plain

# 错误做法
经过 50 次迭代后，忘记了目标是什么

# 正确做法
定期重述目标：
"提醒：我们正在构建速率限制器。
当前状态：基础实现可用。
下一步：添加 Redis 后端。"

审查自动修正循环

代码审查的专项迭代模式：Claude 审查 → 修复 → 再审查，直到收敛。

模式

Plain

┌─────────────────────────────────────────┐
│         审查自动修正循环                  │
│                                          │
│   审查（识别问题）                        │
│        ↓                                 │
│   修复（应用修正）                        │
│        ↓                                 │
│   再审查（验证修复）                      │
│        ↓                                 │
│   收敛（微小改动）→ 完成                  │
│        ↑                                 │
│        └──── 重复（最大迭代次数）         │
└─────────────────────────────────────────┘

提示模板

Plain

对此 PR 进行自动修正审查：
1. 多智能体审查（3 个专注范围的智能体）
2. 修复所有 🔴 必须修复的问题
3. 再审查，确认修复没有引入新问题
4. 修复所有 🟡 应该修复的问题
5. 最终再审查一次
6. 当只剩 🟢 可跳过时停止

最大迭代次数：3 次
如果某次迭代修改量 <5 行，提前停止

安全措施

安全措施	目的	实施方式
最大迭代次数	防止无限循环	硬限制：3 次迭代
质量门控	确保修复有效	每次迭代前运行 `tsc && lint`
受保护文件	防止风险性修改	跳过自动修复：package.json、迁移文件、.env
变更阈值	收敛时停止	迭代修改量 <5 行时退出
回滚能力	从错误修复中恢复	每次迭代前 git 提交

示例会话

迭代 1：初始审查

Plain

Claude：发现 8 个问题：
- 🔴 3 个必须修复（SQL 注入、空 catch、缺少认证）
- 🟡 4 个应该修复（DRY 违反、N+1 查询）
- 🟢 1 个可跳过（命名风格）

迭代 2：修复必须修复 + 再审查

Plain

Claude：已修复 3 个必须修复问题。
再审查：所有 🔴 已解决。无新问题引入。
剩余：4 个 🟡 应该修复，1 个 🟢 可跳过

迭代 3：修复应该修复 + 再审查

Plain

Claude：已修复 4 个应该修复问题。
再审查：所有 🟡 已解决。无新问题。
剩余：1 个 🟢 可跳过（可选改进）

收敛

Plain

Claude：已收敛。仅剩可选改进。
本次迭代修改量：2 行（低于阈值）。
审查完成。✅

对比：单轮审查 vs 收敛循环

方面	单轮审查	收敛循环
检测	一次性找出所有问题	找出问题 → 修复 → 验证 → 重复
后续感知	检查 git 日志的"Co-Authored-By: Claude"	每次迭代都感知前一次
误报	可能对已修复代码建议修复	再审查能捕获此情况
置信度	单次验证	多次验证通过
时间成本	最快（1 次审查）	较慢（3+ 次审查）
质量	适合有经验的开发者	更适合关键代码

何时使用：

单轮：简单 PR、有经验的团队、时间敏感
收敛循环：安全关键代码、初级团队、高风险生产

与多智能体审查集成

将收敛循环与多智能体审查结合，获得最高质量：

Plain

每次迭代：
├─ 智能体 1：一致性审计员
├─ 智能体 2：SOLID 原则分析师
└─ 智能体 3：防御性代码审计员
     ↓
  修复问题
     ↓
  重新运行 3 个智能体
     ↓
  验证修复 + 检查新问题
     ↓
  重复直到收敛

收敛标准

满足以下任一条件时停止迭代：

无剩余问题（理想结果）
达到最大迭代次数（默认 3 次迭代）
达到变更阈值（迭代修改量 <5 行）
质量门控失败（修复后 tsc/lint 失败）
手动停止（用户要求停止）

审查循环中的反模式

反模式	问题	解决方案
无限循环	无收敛标准	设置最大迭代次数 + 变更阈值
范围蔓延	每次迭代增加新需求	在开始循环前锁定范围
破坏性修复	修复引入新 bug	修复后再审查 + 质量门控
受保护文件修改	修改 package.json、迁移文件	受保护文件明确跳过列表
上下文丢失	第 3 次迭代后忘记原始问题	跨迭代维护问题追踪器

示例会话

初始需求

Plain

用 TypeScript 创建一个防抖函数。

迭代 1

Plain

看起来不错。添加：
- 对任意函数签名的泛型类型支持
- 在前缘执行的选项

迭代 2

Plain

更好了。问题：
- 返回类型应该保留原始函数的返回类型
- 添加取消支持

迭代 3

Plain

快完成了。最后打磨：
- 添加 JSDoc 注释
- 单独导出类型
- 添加单元测试

完成

Plain

完美。以"feat: add debounce utility with full TypeScript support"提交这份代码

社区模式与已知局限

社区已在 Claude Code 的迭代循环之上构建了多种模式。有些真正解决了痛点，有些则暴露了值得了解的当前局限。

Ralph 循环（测试驱动的自主迭代）

来源：nathanonn.com，2026 年 2 月。

Ralph 循环将自主迭代约束为每个周期只处理一个测试用例，而非每次运行完整的测试套件。这使每个周期保持专注，防止智能体同时追逐多个失败。

工作原理：

选择一个失败的测试用例
修复它，验证它通过
将进度保存到 JSON 状态文件
继续处理下一个失败的测试用例
同一用例失败 3 次后，将其标记为 known_issue 并跳过

JSON

{
  "current_case": "test_auth_token_refresh",
  "attempts": 2,
  "known_issues": ["test_legacy_migration_edge_case"],
  "completed": ["test_login", "test_logout", "test_session_timeout"]
}

这里的关键创新是状态文件。它能在上下文重置、/compact 操作甚至整个会话重启后存活。智能体在每个周期开始时读取文件，精确知道上次停在哪里、哪些用例已完成、哪些该跳过。

3 次尝试限制防止了困扰简单自主循环的无限循环陷阱。智能体不会在一个顽固的测试用例上无谓消耗 Token，而是继续前进，将问题标记为待人工审查。

自动继续技能

来源：mcpmarket.com。

一个基于置信度的继续系统，决定智能体是继续运行还是停下来等待人工输入。它不使用固定的迭代次数，而是在每个周期后评估情况：

自动继续的条件：

测试通过
构建成功
未检测到新错误类型
置信度分数保持在阈值以上

停止等待人工输入的条件：

置信度降至阈值以下
出现新类别的错误（而非已知错误的新实例）
构建或类型检查以智能体之前未见过的方式失败

这与 Claude Code 的停止钩子配合良好。技能可以触发任务后验证，并根据结果决定是否恢复。

用于自动验证的停止钩子

一种将 Claude Code 的钩子系统变为迭代间自动质量门控的模式：

Claude 完成一个任务（或一次迭代）
TodoWrite 上的工具后钩子（PostToolUse）触发验证脚本
脚本运行类型检查、lint 和测试
错误自动反馈给 Claude
Claude 无需人工干预即可自我修正

JSON

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "TodoWrite",
        "command": "bash -c 'npm run typecheck 2>&1; npm run lint 2>&1; npm test 2>&1'"
      }
    ]
  }
}

每次 Claude 将任务标记为完成时，钩子就会触发。如果验证发现了问题，Claude 会看到输出，并可以在进入下一个任务之前自我修正。

升级策略

当同一个问题在 3 次迭代后仍然失败时该怎么办。不要无休止地循环或放弃，而是遵循结构化的升级路径：

分解：将失败的任务拆解为 2-3 个可独立处理的子任务
收集上下文：将所有错误消息、堆栈跟踪和尝试过的修复整理到结构化文件中
模型升级：如果使用的是 Sonnet，用 Opus 重试特定的失败用例以进行更深层的推理
人工升级：如果模型升级也没有帮助，创建一个包含完整错误上下文的 GitHub issue，并将任务标记为 known_issue

Bash

# 实际中的升级操作
if [ "$ATTEMPT_COUNT" -ge 3 ]; then
    # 收集上下文
    cat errors.log attempts.log > escalation-context.md

    # 用 Opus 重试
    claude --model claude-opus-4-6 \
        "修复这个失败的测试。上下文：$(cat escalation-context.md)"

    # 如果仍然失败，创建 issue
    if [ $? -ne 0 ]; then
        gh issue create \
            --title "自动升级：$TEST_NAME 在 3 次尝试后仍失败" \
            --body "$(cat escalation-context.md)" \
            --label "known_issue,needs-human"
    fi
fi

目标是永远不会静默地丢弃工作。每个失败要么被解决，要么被升级，要么被明确追踪。

已知局限

坦诚说明目前还不奏效的东西，省得你浪费时间重新发明不存在的解决方案。

无内置重试/验证/恢复机制（GitHub issue #28489）：Claude Code 的无头模式自动化原生缺乏重试逻辑、验证门控和会话恢复的支持。每个实现自主循环的团队都在自己构建这些功能。状态文件、基于钩子的验证和升级脚本都是社区针对平台空白的变通方案。

智能体迭代可能丢失（GitHub issue #28843）：在跨多天的工作流中，智能体的迭代及其积累的上下文可能被销毁。如果你运行跨多个会话或多天的工作流，每 N 次迭代就要保存明确的状态文件。不要将 Claude 的对话记忆作为唯一的真相来源。

长时间工作流的脆弱性：长时间运行的自动化需要检查点纪律。定期将状态保存到磁盘（JSON 文件、git 提交、issue 评论）。模式很简单，但容易被遗忘：如果你无法仅凭磁盘上的文件重建智能体的进度，你的工作流就会在会话边界处中断。

参见

实现前先探索 — 迭代前先探索替代方案
使用 Claude Code 进行 TDD — TDD 是带测试的迭代优化
计划驱动开发 — 迭代前先计划
开发方法论参考 — 迭代循环方法论

来源：飞书 · AI Spark 知识库｜原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/LrI0wjsAQitdySk6LWWcI0MyneK ｜归档：2026-06-04

自媒体人 AI 入门路径：从选题到复盘的完整工作流

Claude Code 深度全解

底层原理精讲

可视化图解

零到精通：七步上手路径

企业级安全与治理

生态与工具链全景

实战工作流手册

迭代优化工作流 ​

目录 ​

TL;DR ​

循环流程 ​

步骤 1：初始提示 ​

步骤 2：评估输出 ​

步骤 3：具体反馈 ​

步骤 4：重复 ​

反馈模式 ​

有效反馈 ​

无效反馈 ​

自主循环 ​

Ralph Wiggum 模式 ​

完成标准示例 ​

迭代限制 ​

与 Claude Code 集成 ​

与任务工具配合 ​

与 Hooks 配合 ​

与 /compact 配合 ​

检查点 ​

脚本生成工作流 ​

3-7 次迭代模式 ​

示例：Kubernetes Pod 管理器（PowerShell） ​

常见陷阱 ​

脚本迭代模板 ​

迭代策略 ​

广度优先 ​

深度优先 ​

优先级驱动 ​

反模式 ​

移动目标 ​

完美主义循环 ​

迷失上下文 ​

审查自动修正循环 ​

模式 ​

提示模板 ​

安全措施 ​

示例会话 ​

对比：单轮审查 vs 收敛循环 ​

与多智能体审查集成 ​

收敛标准 ​

审查循环中的反模式 ​

示例会话 ​

初始需求 ​

迭代 1 ​

迭代 2 ​

迭代 3 ​

完成 ​

社区模式与已知局限 ​

Ralph 循环（测试驱动的自主迭代） ​

自动继续技能 ​

用于自动验证的停止钩子 ​

升级策略 ​

已知局限 ​

参见 ​

迭代优化工作流

目录

TL;DR

循环流程

步骤 1：初始提示

步骤 2：评估输出

步骤 3：具体反馈

步骤 4：重复

反馈模式

有效反馈

无效反馈

自主循环

Ralph Wiggum 模式

完成标准示例

迭代限制

与 Claude Code 集成

与任务工具配合

与 Hooks 配合

与 /compact 配合

检查点

脚本生成工作流

3-7 次迭代模式

示例：Kubernetes Pod 管理器（PowerShell）

常见陷阱

脚本迭代模板

迭代策略

广度优先

深度优先

优先级驱动

反模式

移动目标

完美主义循环

迷失上下文

审查自动修正循环

模式

提示模板

安全措施

示例会话

对比：单轮审查 vs 收敛循环

与多智能体审查集成

收敛标准

审查循环中的反模式

示例会话

初始需求

迭代 1

迭代 2

迭代 3

完成

社区模式与已知局限

Ralph 循环（测试驱动的自主迭代）

自动继续技能

用于自动验证的停止钩子

升级策略

已知局限

参见