CCClaude Code中文喂饭教程

怎样写一个合格的 CC 任务

很多人用 CC 不稳定，不是因为 CC 不会，而是任务描述只有“帮我改一下”。合格任务的目标是让 CC 明确知道：做什么、不做什么、做到什么程度、怎么证明完成。

写任务时不要追求长，追求“可执行”。CC 最怕目标模糊、范围无限、验收缺失。

合格任务的 7 个部分

  1. 任务目标：最后要变成什么样。
  2. 背景上下文：这是哪个项目、哪个页面、哪个问题。
  3. 修改范围：优先改哪里，最多改到哪里。
  4. 禁止事项：不要装依赖、不要提交、不要删文件。
  5. 验收标准：什么叫完成。
  6. 不确定时怎么处理：先问，别猜。
  7. 汇报格式：最后按固定格式总结。

任务不是越长越好，而是越清楚越好。可以用这张表自查：

部分不合格写法合格写法
目标优化首页把首页主按钮文案改成“开始学习”
背景页面怪怪的375px 宽度下按钮换行溢出
范围你看着改优先只改首页组件和样式
禁止无不改路由、不装依赖、不提交 Git
验收好看点移动端按钮不溢出，桌面端不变
不确定无不确定先问，不要猜

最小可用任务公式

不会写长模板时，先用这一句公式：

请在【范围】内，把【当前问题】改成【期望结果】。

限制：
1. 不要改无关文件。
2. 不要安装依赖。
3. 不要提交 Git。
4. 不确定先问。

完成后请说明改了什么、怎么验收、还有什么风险。

通用模板

请完成下面这个 Claude Code 任务。

## 任务目标
请把【这里写具体目标】。

## 背景上下文
- 当前项目是：【项目类型】
- 当前问题/需求是：【现象或需求】
- 期望结果是：【完成后应该看到什么】

## 修改范围
1. 优先修改：【文件或目录】
2. 如果必须修改其他文件，请先说明原因。
3. 不要修改和任务无关的代码。

## 禁止事项
1. 不要提交 Git。
2. 不要安装新依赖。
3. 不要删除文件。
4. 不要把 API Key、token、账号信息写进文件。
5. 不要扩大任务范围。

## 执行方式
1. 请先阅读相关文件。
2. 先给出计划，不要立刻修改。
3. 我确认计划后再动手。
4. 修改后请检查 diff 和最小必要验收。

## 验收标准
1. 任务目标已经实现。
2. 修改范围符合限制。
3. 没有无关文件变化。
4. 如果检查失败，请区分是历史问题还是本次修改引入。

## 不确定时
如果你不确定原因、入口文件或修改范围，请先提问或列出判断依据，不要猜。

## 汇报格式
完成后请按下面格式回复：
- 修改摘要：
- 修改文件：
- 验收结果：
- 剩余风险：
- 是否建议进入提交前检查：

不同任务应该怎么写

修 Bug

请修复这个 Bug。

现象：
【页面/接口/操作】出现【具体错误】

复现步骤：
1. 【第一步】
2. 【第二步】
3. 【看到的问题】

期望结果：
【应该看到什么】

要求：
1. 先只读分析原因，不要直接改。
2. 找到最可能的相关文件。
3. 给出最小修复方案。
4. 我确认后再修改。
5. 修改后复查是否影响其他流程。

Bug 任务最重要的是复现步骤。没有复现步骤时，先让 CC 帮忙反问，不要直接修。

我现在还没有完整复现步骤。

请先帮我整理需要补充的信息：
1. 需要哪个页面、接口或操作入口。
2. 需要什么设备、账号、参数或环境。
3. 需要截图、日志还是返回结果。
4. 哪些信息不能包含密钥或隐私。
5. 信息补齐前不要修改文件。

新增小功能

请新增一个小功能：【功能名称】。

功能目标：
【一句话说明用户能做什么】

范围：
1. 优先修改：【页面/组件/接口】
2. 不要改数据库结构，除非先说明必要性。
3. 不要引入新依赖，除非先说明替代方案。

验收标准：
1. 用户可以完成【动作】。
2. 错误状态有提示。
3. 移动端不溢出。
4. 现有功能不受影响。

新增功能要先拆出最小版本：

请先把这个功能拆成最小可交付版本。

要求：
1. 哪些是本次必须做。
2. 哪些可以下一次再做。
3. 本次最多影响哪些文件或模块。
4. 最小验收标准是什么。
5. 如果范围太大，请建议先做第一步。

解释项目

请只读解释当前项目，不要修改文件。

请输出：
1. 项目是做什么的。
2. 技术栈和主要入口。
3. 目录结构怎么理解。
4. 启动、构建、测试命令从哪里确认。
5. 如果我要做第一个低风险任务，建议是什么。

请区分“从文件确认”和“推测”。

改文档

请修改这篇文档。

目标：
【写清楚要补什么内容】

要求：
1. 保持用户视角，不要出现面向作者的解释。
2. 保持当前站点的学习顺序。
3. 如果新增文章或链接，请同步更新学习路线。
4. 不要编造官方功能或未经验证的截图。
5. 修改后检查链接和构建。

坏任务和好任务

坏任务：

帮我优化首页。

好任务：

请只优化首页首屏按钮文案和按钮间距。

目标：
1. 主按钮文案改成“从 0 开始学习”。
2. 次按钮文案改成“查看模板库”。
3. 移动端两个按钮上下排列，不能溢出。

范围：
优先只改首页文件和必要样式，不要改路由、依赖、构建配置。

请先给出修改计划，我确认后再动手。

任务写完后先自查

任务太大时先拆

看到这些词，优先拆任务：

可复制：

这个任务可能太大，请先拆分，不要修改文件。

请输出：
1. 可以独立完成的子任务。
2. 推荐执行顺序。
3. 每个子任务的风险等级。
4. 第一轮最小任务是什么。
5. 每个子任务怎么验收。

CC 回答含糊时怎么追问

你的回答还不够可执行。

请补充：
1. 你基于哪些文件得出这个结论。
2. 哪些是事实，哪些是推测。
3. 最小修改范围是什么。
4. 如果按这个方案执行，可能影响什么。
5. 验收方式是什么。

补充完之前不要修改文件。

验收结果

下一篇：大任务拆分