CCClaude Code中文喂饭教程

让 CC 完成任务验收

改完不等于完成。你要让 CC 自己检查、解释结果、区分历史问题和本次问题。验收的目标是让“我觉得好了”变成“有证据说明好了”。

验收要看 4 件事

  1. 目标是否完成：原始需求有没有真的满足。
  2. 范围是否干净：有没有改无关文件、顺手重构或引入新风险。
  3. 检查是否足够：有没有跑项目里已有的最小必要检查。
  4. 风险是否说明：没验证的地方有没有明确写出来。

验收不是让 CC 再夸一遍“已经完成”，而是让它把证据拿出来。一次合格验收至少要回答三个问题：改了什么、怎么证明、还有什么没证明。

修改后直接发

请对刚才的任务做验收。

要求：
1. 检查本次修改涉及哪些文件。
2. 解释每个文件为什么需要修改。
3. 判断是否有超出任务范围的改动。
4. 根据项目情况选择最小必要检查，并由你执行。
5. 如果检查失败，请判断失败是否和本次修改有关。
6. 如果无法执行检查，请说明原因和人工验收方法。

请按下面格式回复：

## 修改摘要
- 改了什么：
- 修改文件：

## 验收结果
- 做了哪些检查：
- 通过了什么：
- 失败了什么：
- 未检查什么，原因是什么：

## 风险判断
- 是否有超范围修改：
- 是否有敏感信息风险：
- 是否可以进入提交前检查：

按任务类型验收

任务类型必看证据常见遗漏
文案和文档页面内容、链接、目录、标题层级只改正文，忘了导航和学习路线
前端页面目标页面、桌面端、移动端、交互状态修了当前宽度，别的宽度溢出
后端接口正常输入、异常输入、调用方兼容只测成功流程，没测错误码
配置和脚本构建结果、环境变量说明、回滚方式本地能跑，换环境失败
重构任务行为不变证据、测试结果、diff 范围借重构偷偷改业务逻辑

文案和文档

前端页面

后端接口

如果 CC 没有检查

你刚才没有完成验收。

请补充：
1. 当前项目有哪些可以确认存在的检查方式。
2. 哪个检查最适合本次小改动。
3. 请执行这个检查并解释结果。
4. 如果你不能执行，请说明限制和人工检查方法。

如果检查失败

检查失败了，请先不要扩大修改。

请判断：
1. 失败是否由本次修改引入。
2. 如果是，请只修复本次修改相关问题。
3. 如果不是，请说明这是历史问题，并不要顺手修复。
4. 请给出下一步最小处理建议。

失败结果要分清三类：

失败类型怎么处理
本次修改引入先修本次相关问题，再重新验收
历史问题暴露明确记录，不要顺手扩大战场
环境或依赖问题说明限制，给人工验收方法

如果 CC 一看到失败就开始大面积改文件，马上让它停下来：

先停止修改。

请只分析刚才检查失败的原因，不要继续改文件。
请说明：
1. 失败日志中哪一行和本次修改直接相关。
2. 哪些失败是历史问题或环境问题。
3. 如果要修，只需要改哪些最小文件。
4. 如果不该在本次修，请给出记录方式。

如果 CC 说“我无法验证”

如果你无法自动验证，请给出人工验收步骤。

要求：
1. 告诉我应该打开哪个页面或触发哪个流程。
2. 告诉我应该看到什么。
3. 告诉我哪些结果表示失败。
4. 告诉我如果失败，下一步应该收集什么信息。
5. 不要把“无法验证”当成“已经完成”。

人工验收也要具体。不要接受“打开页面看看是否正常”这种说法，要让 CC 写成可执行清单：

通过、部分通过、未通过怎么判断

结论判断标准下一步
通过核心目标完成，最小必要检查通过，没有阻塞风险进入 /code-review 或提交前检查
部分通过主流程完成，但有未验证场景或低风险遗留记录风险，决定是否补验
未通过需求没完成、检查失败且和本次相关、存在高风险回到修复阶段

不要把“能打开页面”当成通过，也不要把“有一个无关测试失败”当成未通过。专业验收看的是证据和相关性。

验收报告应该长什么样

请输出最终验收报告：

## 结论
通过 / 未通过 / 部分通过

## 已验证
- 【检查项】：【结果】

## 未验证
- 【原因】

## 风险
- 【是否有超范围修改】
- 【是否有历史问题】
- 【是否需要人工复查】

## 下一步
- 可以进入 /code-review
- 或者需要先修复：【具体问题】

最后一轮追问

验收报告出来后，再补一句：

请基于本次验收，用一句话给出最终判断：

1. 是否建议进入 /code-review。
2. 如果不建议，唯一最该先处理的问题是什么。
3. 如果建议，请说明仍然需要人工留意的点。
专业使用 CC 的关键不是“让它做完”，而是“让它证明做完”。

验收结果

下一篇：/verify 验收