CCClaude Code中文喂饭教程

让 Claude Code 先澄清需求

需求模糊时不要急着让 Claude Code 写代码。先让它追问目标、边界、输入输出、验收标准和风险，把任务从“你看着办”变成可执行计划。

很多任务失败，不是因为 Claude Code 不会写代码，而是需求一开始就不清楚。

如果用户只说“优化一下”“改好看点”“帮我做个功能”，CC 会补很多脑。一旦它补错方向，后面写得越快，偏得越远。

需求越模糊，越不要马上进入修改。先让 CC 澄清需求，是高质量交付的第一步。

什么时候必须先澄清

遇到这些情况，不要直接批准修改：

这种任务先问清楚，比直接写代码更快。

先让 CC 复述需求

第一步不是让它提方案，而是让它复述理解。

请先不要修改文件。

请复述你对这个需求的理解：
1. 目标是什么。
2. 用户希望解决什么问题。
3. 你认为任务范围包括哪些内容。
4. 哪些内容不应该默认包含。
5. 你还需要我补充哪些信息。

如果复述都不对，计划一定也不稳。

让 CC 主动追问

好的 CC 使用方式，不是用户一次性把所有信息写完，而是让 CC 帮用户把缺口找出来。

在给方案前，请先向我提出必要的澄清问题。

要求：
1. 最多问 5 个关键问题。
2. 只问会影响实现方向的问题。
3. 不要问无关细节。
4. 每个问题后说明为什么需要确认。

如果问题太多，说明任务还需要拆分。

常见澄清维度

维度要确认什么
目标最终要解决哪个问题
用户谁会使用这个功能
范围本次做哪些，不做哪些
输入数据从哪里来
输出页面、接口或文件最终长什么样
边界空数据、错误、权限、移动端怎么处理
验收怎么证明任务完成
风险哪些文件或流程不能随便碰

每次不一定都问全，但至少要覆盖目标、范围和验收。

把模糊需求改成可执行任务

模糊说法：

帮我优化一下首页。

澄清后应该变成：

请优化首页 hero 区域的信息密度。

目标：
1. 让左侧文案更集中。
2. 让右侧视觉更大、更紧凑。
3. 保持 Claude Code 主题色。

范围：
1. 只修改首页 hero 区域。
2. 不改文档页。
3. 不改导航结构。

验收：
1. 桌面端首屏左右间距更紧凑。
2. 移动端不出现文字溢出。
3. 构建通过。

这才是 CC 能稳定执行的任务。

让 CC 区分事实和假设

需求澄清时，CC 很容易把猜测说得像事实。要强制它分开。

请把你的理解分成两类：

已知事实：
1. ...

需要确认的假设：
1. ...

在假设没有确认前，不要基于它修改文件。

这一步能减少“它以为”的问题。

如果用户也不确定

有时候用户确实不知道该怎么做。这时不要让 CC 直接决定，而是让它给选项。

我还不确定具体方案。

请给出 2 到 3 个可选方向：
1. 每个方向解决什么问题。
2. 适合什么场景。
3. 风险是什么。
4. 工作量大概如何。
5. 推荐哪个，并说明原因。

先不要修改文件。

这样用户是在做选择，而不是把控制权完全交出去。

澄清完成后的输出格式

需求确认后，让 CC 生成一份任务卡。

请把确认后的需求整理成任务卡：

任务目标：
范围：
不做内容：
涉及文件或模块：
实现步骤：
验收标准：
风险点：
需要人工确认：

这份任务卡就是后面 Plan Mode 和验收的依据。

需求变了怎么办

任务执行过程中，如果目标发生变化，不要让 CC 直接接着改。需求一变，原来的计划、验收标准和风险判断都可能失效。

可以这样处理：

需求发生变化，请先暂停当前实现。

请重新评估：
1. 新需求和原需求差异在哪里。
2. 当前已完成内容哪些还能保留。
3. 哪些改动可能需要回退。
4. 原验收标准哪些已经失效。
5. 是否应该把新需求拆成独立任务。

这一步能避免任务越改越乱。

澄清不充分的危险信号

如果 CC 的计划里出现这些话，要回到澄清阶段：

这些词说明边界还不够清楚。可以直接要求：

你的计划里仍有不确定表述。

请把所有“可能、顺便、一起处理”的内容改成：
1. 明确要做。
2. 明确不做。
3. 需要确认后再做。

任务越清楚，后面越省时间。

验收结果

下一篇：怎样写一个合格任务