AI 知识库

反馈循环：让 Claude Code 少盯着也能完成有野心的任务

Properties1
tagsclippings, ai/claude-code, ai/工作流, ai/agent

9分钟阅读

核心思想

把人工检查变成 Claude 能自己跑的「反馈循环」，是让它少盯着也能干完活的关键。作者给出三层做法：先把流程写下来、再编码成技能(skill)、最后在合并前让一个无偏见的「第二个智能体」做审查——自我验证越充分，智能体就越自主、来回越少、最终质量越高。

随着我们把越来越有野心的任务交给 Claude，让它能验证自己的工作就变得越来越重要。Claude 越能自我验证(self-verify)：

  • 就越能独立处理长时间运行的任务
  • 最终结果的质量就越高
  • 走到那一步要花的来回也越少

当这些检查都得靠你来做时，编码会话就变成了一场回合制游戏——你出一手、它出一手，于是智能体最宝贵的东西也随之丢了：自主性。

好消息是，对于类型错误、lint 报错、测试失败、运行时错误这类确定性信号(deterministic signals)，Claude 本来就会自我验证。而且随着模型不断进步，这一点只会越来越强。

Claude 并不总能推断出来的，是你在它回复之后手动跑的那些检查，以及更靠后、在你把代码合并(merge)进生产环境之前要做的检查。这些检查，你能编码下来的越多，Claude 的首次回复就越接近你心里那个最终结果。

你盯着它的时间更少，而 Claude 也能在你忙别的事情时一直干下去。

把你的流程写下来

不妨从一个简单的起点开始：把你或你的团队已经在做的事情，按最佳实践的样子写下来。

拿前端来说，通常是这样：启动开发服务器、打开浏览器、检查控制台有没有报错、像真实用户那样点点看，留意诸如布局抖动、导航变慢之类的问题。

每个领域都有自己的一套流程。而对其中的每一步，多半都能找到一个 Claude 可以拿来做验证的工具：

把流程编码成一个技能

流程一旦理清，就尽可能多地把它编码成一个技能(skill)。先安装 skill-creator 插件，然后让 Claude 来访谈你：

/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.

如果你一时说不清自己的流程，可以先让 Claude 给出这个领域的最佳实践，让它先示范一套端到端的验证流程大概长什么样。品味和判断力很难被编码下来，但很多检查都有可供 Claude 衡量的标准：一份性能预算、一份无障碍检查清单、一套设计系统规则、一些好与坏的对照示例。

举个例子，一个前端技能里可能会包含这样的指令：通过 Chrome DevTools MCP 或 Agent browser 抓取一份性能追踪记录。

---
name: frontend-verify
description: Verify frontend changes in a browser. Run whenever 
a UI (page, component, typography, CSS style) change is made.
---
 
# Frontend verify
 
- Run a two-step verification pass in a real browser. 
- Fix issues and re-verify before responding to the user. 
 
## Step 1 — Verify the change behaves as expected
 
1. Open the URL in a browser:
   - In the Claude Code desktop app, use the embedded preview.
   - In the CLI, use the Chrome DevTools MCP.
2. Interact with the new element and confirm it renders and 
   behaves as expected.
 
## Step 2 — Verify the change passes a mobile audit
 
1. Open the URL in a new page via the Chrome DevTools MCP
2. Run a performance trace and audit Core Web Vitals

还有一些检查更偏定性、而不是简单的通过/不通过，比如把数据和历史常态做对比。对这类检查，你可以和 Claude 一起定一份评分量表(rubric)，用来评估输出。

合并前，用第二个智能体审查代码

上面这些都发生在智能体循环(agentic loop)内部。其实还有第二道验证——就在你合并之前，你可以请另一个智能体来做审查。

一个全新的智能体，不会带着写代码那个智能体的同样偏见。它有自己独立的上下文，也不受之前那场对话的影响。正是这种隔离，让审查更诚实，也能抓出第一个智能体可能漏掉的东西。

这里有几个选择，从手动到自动：

  • /review（内置技能）—— 在终端里对一个 PR（拉取请求）做一次快速的单遍通读。
  • /code-review（可安装插件）—— 并行启动多个子智能体，每个从不同角度去读这份 diff，按置信度为发现的问题打分，再把结果发到 PR 上。
  • Claude Code Review —— 一项托管服务，面向 Team 和 Enterprise 套餐，通过 GitHub 在每个 PR 上自动运行。

无论你选哪一个，在合并到生产环境之前有这么一道最后防线，总归是有帮助的。

把它们拼到一起

现在你有了两层：

  • 在 Claude 构建过程中运行的验证
  • 合并前，由一个没写过这段代码的智能体来审查。

这两层都属于同一个开发生命周期。想一想你眼下那些手动步骤：你改一处代码、把它收拾干净、确认它能跑、提交、开一个 PR、找人审查、然后盯着持续集成(CI)。

你可以把所有这些步骤整合成一条工作流——写一个去调用其他技能的技能。比如，Claude Code 团队就有这么一个在做功能开发时会运行的技能，它打包了：

  1. 用 /simplify 技能来清理 diff
  2. 一个自定义的 /verify 技能，端到端地确认改动有效
  3. 如果 diff 动到了 UI，就做一次设计检查
  4. 一步去开一个 PR 并订阅它
  5. 一个用来盯着 CI、一有失败冒出来就随手修掉的技能

你的工作流也许长得不一样，但构建反馈循环、把技能打包到一起，能让 Claude 端到端地验证并完成更多工作。

相关笔记