AI 改完代码，用五类检查证明它真的改对了

Claude Code 交来一份完成报告：构建通过，lint 通过，已修复。你打开页面刷新一下，会话还是丢了。同一个任务里还可能冒出另一个毛病：发布流程引用的测试命令，早就被删掉了。

这几种“不对劲”听上去都是“没做好”，原因却各不相同。

分开看会清楚很多：

响应变慢变贵，是缓存和效率的问题
说完成了行为却不对，是验收的问题
规则和工具越用越难维护，是配置老化的问题

最容易被忽略的是验收。构建通过、lint 通过、单元测试通过，各自只说明一部分事实，目标行为恢复了没有，要看有没有哪个检查真的覆盖了它。

后两类问题，这里一并讲透：

命令退出码、单元测试、集成测试、截图、日志监控这五类检查，各自提供什么证据、还差什么
“刷新后会话仍然保留，主动退出后仍被清除”这样的验收条件，怎样落到可以观察的行为上
验证要求按作用范围放进 Prompt、Skill 和 CLAUDE.md

最后用一张体检表检查长期配置哪里失效，再用三条记录练习怎样排优先级。每一次调整，都应该有对应的证据和复查的办法。

01 变慢、做错、过期，先分清是哪一类

问题	主要观察	调整方向
重复读取长上下文变贵或变慢	缓存读取、写入、请求变化与耗时	减少不必要的前缀变化，详见缓存前缀
Claude 说完成，但行为不对	原症状、测试、日志和人工检查	补充或修正验收方式
规则与工具越来越难维护	加载内容、冲突规则、闲置扩展、权限范围	更新具体失效配置

小黑分别检查重复前缀、目标行为验证和过期配置，区分变慢、做错与配置老化

目标行为仍失败，说明需要检查实现与验证；已删除的命令仍被调用，则要更新对应流程。缓存命中说明的是效率，测试通过说明的是被测行为，权限配置是否合理要另行检查。下面讲后两类：怎么证明改对了，以及长期配置怎么体检。

02 Verifier：能证明目标行为的检查

Verifier 是用于验收任务的检查方法与判断标准。它可以是自动测试，也可以是有明确步骤和预期结果的人工检查。Anthropic 的最佳实践页把“给 Claude 一个可以运行的检查”当作主线之一。关键是观察结果能否支持任务目标。

就拿登录会话来说：修复刷新后丢失会话。构建成功说明代码能构建；刷新行为是否恢复，要有对应的证据。需要覆盖恢复流程的测试或浏览器操作，并检查刷新前后的会话状态。

检查	能提供什么证据	还需另行证明什么
命令退出码、lint、typecheck、构建	工具是否成功，代码是否满足对应静态或构建约束	所有业务行为正确
单元测试	给定条件下某段逻辑符合断言	未覆盖的集成路径成立
集成测试、contract test、smoke test	模块协作、接口契约或关键路径符合预期	其他未测路径无问题
截图、视觉与交互检查	指定状态下的布局、显示或操作结果	后端事实、权限或所有交互正确
日志、监控、人工审查	指定环境与时间窗口内的运行表现或审查判断	没有观察到的情况也已验证

验证的价值取决于实际覆盖，不取决于数量或名称。无关测试再多，也覆盖不到刷新后的会话恢复；静态检查通过后，目标行为仍要单独验证。

表中的 contract test 检查接口双方约定的输入、输出和错误行为，smoke test 用少量检查确认关键路径能否基本走通。选择前先写出要观察的条件，再看现有检查实际覆盖什么，以覆盖范围判断哪种检查更可靠。

03 把验收条件落到可观察的行为

本例可直接把验收条件定为“已有有效匿名会话刷新后仍保留，主动退出后仍被清除”，再选择能观察这些条件的检查：

要证明的行为	观察方式	可采用的结论
有效会话刷新后恢复	记录刷新前后会话标识，并检查恢复链路	在该条件下恢复行为符合预期
主动退出仍清除会话	退出后检查会话状态与后续访问	这项检查未发现原有退出行为受到破坏
改动满足类型约束	运行项目类型检查	类型检查通过，前两项行为验证仍要做

如果现有自动测试覆盖这些条件，就使用相应测试；覆盖不足时，补充获准范围内的测试或明确的手工检查。截图只显示页面状态时，服务端会话是否仍是原来的对象，要用会话标识来确认。

最终记录应具体到命令或操作、环境、结果与未覆盖项。自动测试通过而浏览器复验被环境阻断时，应分别说明。“没有报错记录”要配上已执行的证据才算数。

目标还不能观察时，先澄清完成标准并小范围尝试，验收看证据，自我声明只作参考。完成报告应说明证据实际支持什么，缺失的验证单独保留。任务说明里怎么把目标、范围、约束和验证写清楚，见Claude Code 报告已修好，问题却还在。

04 按作用范围保存验证要求

当前任务的具体检查可以写进 Prompt：

修复后请运行 `npm test -- auth`，并说明失败或通过情况。

这里的参数是否筛选 auth 测试，取决于项目脚本，使用前需确认。目标行为、命令入口和判定结果要对应。

同类任务反复出现时，将方法写入 Skill：

## Verification

1. Run unit tests for changed module.
2. Run typecheck.
3. Record failures and distinguish task-related defects from existing or environment issues.
4. Fix task-related defects within the authorized scope, then recheck.
5. Report passed, failed, not-run, and blocked checks with supporting results.

这是一段流程骨架，落到项目时还需给出真实检查入口。它把验证状态与后续动作连起来：任务相关缺陷需要修复并复验；无关既有失败或环境阻塞则保留证据、说明影响，不无限扩大任务。

长期协作要求可以写入 CLAUDE.md：

Backend changes require tests or an explicit reason why tests cannot run.
UI changes require visual verification when layout changes.

Prompt 指定本次目标，Skill 组织取得证据的方法，CLAUDE.md 保留持续约定。必须在固定事件执行的轻量检查，再交给相应 Hook。各层应引用一致标准，避免复制成三套不同要求，分层写法见CLAUDE.md 越写越长，用三个问题把规则拆开。

05 从实际失效检查配置

项目变化后，旧命令可能失效，Skill 描述可能覆盖过宽，Hook 输出可能增长，MCP 可能闲置，allowlist 也可能超出当前需要。维护需要回到实际使用，不以文件数量或总行数直接判优劣。

检查对象	要找的具体问题
`CLAUDE.md`	无必要常驻内容、过期命令、冲突约定
rules	路径条件缺失、模式不匹配、局部规则仍无条件加载
Skills	描述误触发、主体混杂、副作用启动边界不清
Hooks	检查过慢、输出过长、拒绝与错误语义混淆
MCP / Plugin	闲置能力、重复工具、版本或加载变化
permissions / sandbox	超过任务需要的访问或未覆盖的外部操作
Subagents	工具与输出无边界、共享文件缺少唯一写入者
验证入口	命令已变、测试未覆盖当前行为、结果无法回查

可以先做一次只读审查：

请审查当前 Claude Code 配置。
重点检查 `CLAUDE.md`、rules、skills、hooks、MCP 和 permissions。
输出：必须立刻修、结构性问题、可以以后优化。
不要直接修改文件，先给建议。

每条建议应附具体位置、实际影响和最小修正。例如“规则太长”让人无从下手；“课程规则没有 paths，导致无关代码任务也加载全文”就能指向明确改法。反复需要这套检查时，再写成健康检查 Skill。

06 三条记录，怎么排优先级

团队在一次会话里观察到三件事：

记录 A：切换模型后第一轮缓存写入增加，后续轮次恢复读取。
记录 B：构建通过，但刷新后会话仍然丢失。
记录 C：发布检查 Skill 仍引用已经删除的测试命令。

对 A，现象与一次缓存重建相符；如果新模型确实更适合当前任务，先看后续是否稳定，再判断是否需要调整。

对 B，构建证明的是构建约束，原症状仍存在说明目标没有达到。这里应优先处理仍未解决的行为问题：回到恢复路径定位原因，再验证修复效果。“证据 → 判断 → 最小下一步”仍然适用。

对 C，先确认项目现有的测试入口，再更新负责这条流程的唯一维护位置。只在一个位置维护这条命令，根说明、Skill 和 Hook 引用同一份。修正后运行对应检查，确认能找到规则，命令也确实覆盖需要验证的行为。

优先处理尚未达标的行为、阻断验收的失效入口，以及实际权限风险。必要的能力调整或权限收紧，照样优先做，缓存损失可以接受。每项调整都要有相应的证据和复查方式。

回头看这一整套做法，主线只有一条：上下文提供判断依据，规则和 Skill 组织方法，工具执行动作；权限与隔离限定影响，验证判断结果是否可用，维护让这些约定继续适用于项目。缓存帮助减少重复处理，但可靠性仍取决于整条工作过程是否有正确依据。