CCClaude Code中文喂饭教程

/verify：让 CC 验证结果

改完代码后，不要只听“完成了”。/verify 是让 CC 回到任务目标、检查 diff、选择最小验证方式，并明确告诉你哪些地方没有验证。

/verify 不是万能测试命令。它更像一个验收流程入口：让 CC 自己判断该跑什么、该看什么、哪些结果能证明修改有效。

什么时候必须用 /verify

/verify 的重点不是“跑一个命令”，而是让 CC 选择合适证据。不同任务需要不同证据：

任务类型验证证据
文案文档页面内容、链接、目录、学习路线
前端样式桌面端、移动端、交互、截图反馈
后端接口正常输入、异常输入、旧调用方
构建问题原失败命令重新通过
重构行为不变、测试通过、diff 范围干净
配置变更环境说明、回滚方式、最小运行验证

直接复制

/verify

请验证刚才的修改是否真的满足任务目标。

要求：
1. 回顾原始任务目标和验收标准。
2. 检查本次修改涉及哪些文件。
3. 判断是否有超出范围的修改。
4. 根据项目情况选择最小必要检查。
5. 如果检查失败，判断是否由本次修改引入。
6. 如果无法验证，请说明人工验收方法。

更严格的 /verify 模板

/verify

请严格验证本次修改。

请按顺序完成：
1. 重述原始任务目标。
2. 列出本次实际修改的文件。
3. 判断有没有超出范围。
4. 找出项目里已经存在的检查方式。
5. 选择和本次修改最相关的最小检查。
6. 执行检查，并解释结果。
7. 如果检查失败，判断是否由本次修改引入。
8. 如果不能自动检查，请给出人工验收步骤。

最后输出：
- 验收结论：通过 / 未通过 / 部分通过
- 已验证：
- 未验证：
- 需要继续处理：

前端任务要补什么

如果这是前端任务，请补充检查：
1. 桌面端布局是否正常。
2. 移动端布局是否正常。
3. 文字是否溢出、遮挡或换行异常。
4. 交互元素是否还能点击。
5. 是否需要我提供真实截图做二次反馈。

如果当前环境无法截图或打开浏览器，也要让 CC 给人工检查清单，不要直接算通过。

后端任务要补什么

如果这是后端任务，请补充检查：
1. 正常输入是否通过。
2. 异常输入是否返回合理错误。
3. 是否影响旧字段或旧调用方。
4. 有没有测试、日志或最小调用结果作为证据。
5. 无法调用时，请给出人工验证方式。

文档任务要补什么

文档和教程也需要验证，尤其是静态站：

如果这是文档任务，请补充检查：
1. 标题、左侧菜单和学习路线是否一致。
2. 文档链接是否可点击。
3. 是否有重复段落、错别字或口吻不一致。
4. 如果新增文章，是否更新学习路线。
5. 构建后的页面是否能生成。

验证报告要有证据

不要接受“看起来没问题”。让 CC 写成证据报告：

请把验证结果写成证据报告。

格式：
1. 原始目标：
2. 实际修改：
3. 执行的检查：
4. 检查结果：
5. 未验证项：
6. 是否建议进入 /code-review：

检查失败时别急着修

失败不等于马上让 CC 大改。先判断失败和本次修改有没有关系。

检查失败了，请先分类，不要直接修。

请判断：
1. 失败是否由本次修改引入。
2. 如果是本次引入，最小修复方案是什么。
3. 如果是历史问题，请说明证据，不要顺手修。
4. 如果不确定，请列出还需要读取或验证的信息。
5. 在我确认前不要扩大修改范围。

验收结论怎么读

部分通过怎么处理

“部分通过”不是失败，也不是完成。它表示还缺证据：

未验证原因处理方式
无法打开页面给人工页面检查清单
没有相关测试给最小人工验证步骤
环境变量缺失说明需要人工配置什么
历史测试失败标明和本次修改是否相关
需要真实数据用脱敏数据或测试环境验证

最后再问一句：

请把“部分通过”的未验证项按优先级排序。
请告诉我最应该补验的 1-2 项是什么。

验收结果

下一篇：代码审查