当我们把更复杂的任务委托给 Claude 时，确保它能够自我验证变得愈发重要。
Claude 自我验证的能力越强：
- 它就越能独立地处理长期任务
- 最终结果的质量就越高
- 达成目标所需的来回沟通就越少
当验证依赖于你时，编码会话就会变成回合制游戏，而 Agent 最有用的自主性也就丧失了。
好消息是，Claude 已经可以针对确定性信号进行自我验证，比如类型错误、lint 错误、测试失败和运行时错误。随着模型的改进，这一点只会变得更好。
Claude 无法总是推断出来的是那些你在它回复后、以及在将代码合并到生产环境之前手动执行的检查。
你能够编码的检查越多，Claude 的首次回复就越接近你心中想要的结果。
你花在监督上的时间就会减少，而 Claude 可以在你处理其他事情的同时继续工作。
写下你的流程
一个好的起点是写下你或你的团队已经在执行的最佳实践版本。
对于前端来说，这通常包括：运行开发服务器、打开浏览器、检查控制台是否有错误、像用户一样点击浏览、并留意布局偏移或导航缓慢等问题。
每个领域都有自己的版本。对于这些步骤中的每一步，很可能都有 Claude 可以使用的工具来进行验证：
把你的流程编码为技能
一旦流程明确了，就尽可能多地将其编码为技能。安装 skill-creator 插件，然后让 Claude 对你进行访谈：
1/skill-creator 创建一个用于端到端验证前端变更的技能。采访我的工作流程。
如果你很难用语言描述你的流程，先让 Claude 给出领域最佳实践，让它向你展示一个端到端验证流程大概是什么样子。
品味和判断力很难代码化，但许多验证都有 Claude 可以衡量的标准：性能预算、无障碍检查清单、设计系统规则、好的与坏的例子。
例如，一个前端技能可能包括通过 Chrome DevTools MCP 或 Agent browser 捕获性能追踪的指令。
1---2name: frontend-verify3description: 在浏览器中验证前端变更。每当 UI（页面、组件、排版、CSS 样式）发生变更时运行。4---56# 前端验证78- 在真实浏览器中执行两步验证流程。9- 在回复用户之前修复问题并重新验证。1011## 步骤 1 — 验证变更行为符合预期12131. 在浏览器中打开 URL：14 - 在 Claude Code 桌面应用中，使用内嵌预览。15 - 在 CLI 中，使用 Chrome DevTools MCP。162. 与新的元素交互，确认其渲染和行为符合预期。1718## 步骤 2 — 验证变更通过移动端审核19201. 通过 Chrome DevTools MCP 在新页面中打开 URL212. 运行性能追踪并审核 Core Web Vitals
其他验证比单纯的通过/失败更偏定性，比如将数据与历史标准进行对比。对于这些情况，你可以与 Claude 一起设定评估输出的标准。
在合并前使用第二个 Agent 审查代码
以上所有操作都在 Agent 循环内部进行。在合并之前还有一个第二步验证环节，你可以让另一个 Agent 进行审查。
一个新的 Agent 不会带有编写代码的那个 Agent 的偏见。它有自己的上下文，并且不受之前对话的影响。这种隔离使得审查更加诚实，能够捕捉到第一个 Agent 可能遗漏的问题。
以下是几个从手动到自动的选项：
- /review（内置技能）——在终端中对 PR 进行快速单遍阅读。
- /code-review（可安装插件）——同时启动多个子 Agent，每个从不同角度读取差异，对发现进行置信度评分，并将结果发布在 PR 上。
- Claude Code Review ——一项托管服务，在 Teams 和 Enterprise 计划中，每次 PR 通过 GitHub 自动运行。
无论你选择哪个，在合并到生产环境之前设置最后一道防线都是有帮助的。
整合在一起
现在你有了两个层次：
- 在 Claude 构建过程中运行的验证
- 在合并前由未编写代码的 Agent 进行的审查
两者都属于同一个开发生命周期。思考一下你当前的手动步骤：你进行变更、清理代码、确认工作正常、提交、打开 PR、获得审查、并观察 CI。
你可以将所有这些步骤整合到一个工作流中，通过编写一个调用其他技能的技能来实现。例如，Claude Code 团队在开发功能时运行一个技能，它包含：
/simplify技能以清理差异- 自定义
/verify技能以确认变更端到端工作正常 - 如果差异触及 UI，则进行设计检查
- 打开并订阅 PR 的步骤
- 观察 CI 并实时修复失败的技能
虽然你的工作流可能有所不同，但创建反馈循环和捆绑技能可以让 Claude 验证并端到端地执行更多工作。
