Claude Code 没按你的想法做？先别重来，试试这套纠偏方法
用 Claude Code 写代码时，最让人头疼的往往不是“它完全不会做”，而是另一种情况：
它做了一部分，而且看起来还挺像那么回事，但就是和你脑子里想的不一样。
比如：
- 你想改按钮文案，它改了，但文案不是你要的
- 你想加一句空状态提示，它却顺手改了列表结构
- 你想修一个小样式，它把整个区域的布局都调整了
这时很多人会下意识做两件事。
第一种是直接放弃：算了，我自己改。
第二种是重新开一轮：刚才不算，我重新写个 prompt 再来一次。
这两种做法都不太划算。
因为 Claude Code 已经产出了一部分可用结果，如果直接丢掉，相当于前面的等待和生成都浪费了；但如果每次都从头来，又很容易把已经做对的地方一起推翻。
更合适的方式是：
不要急着重做，先判断它错在哪里，然后针对性纠偏。
这篇文章不讲怎么写一个完美 prompt，而是讲另一件更实际的事：当 Claude Code 已经做偏了，应该怎么把它拉回来。
不要期待第一版就是最终版
很多人刚开始用 AI 写代码时，会有一个隐含期待：
我把需求告诉它，它应该一次就做对。
但真实开发不是这样。
即使是同事写代码，也很少第一次提交就完全符合你的想法。你通常会 review、提意见、让他改一轮，甚至再改一轮。
Claude Code 也是一样。
更合理的使用方式不是把它当成“自动交付机器”，而是把它当成一个能快速给出初稿的协作者。
它先帮你把大部分工作铺出来，你再通过明确反馈，把结果修到可用状态。
可以把过程理解成这样：
先拿到一版可修改的结果 → 找出偏差 → 明确告诉它怎么改 → 收敛到可用版本
所以，Claude Code 没有一次做对，并不代表它没用。
真正影响效率的是：你能不能快速判断它到底偏在哪里。
我通常把问题分成三类
当 Claude Code 的结果不符合预期时，可以先不要急着改 prompt，而是先分类型。
我一般会把它分成三类：
- 局部不准：大方向没问题，但小地方不对
- 理解跑偏：它选择了和你预期不同的实现方式
- 范围失控：它做了你没让它做的事情
这三类问题看起来都叫“没做对”，但处理方式完全不一样。
第一类：局部不准
所谓“局部不准”，就是它整体理解是对的，只是某些小细节没有按照你的要求来。
比如：
- 你要按钮文案是“确认提交”，它写成了“提交”
- 你要按钮是蓝色，它写成了绿色
- 你要输入框提示语是“请输入手机号”，它写成了“请输入内容”
- 你要弹窗标题居中，它只改了标题文字，没处理对齐方式
这类问题不用大动干戈。
你只需要告诉它：哪个地方错了、应该改成什么、其他地方别动。
例如：
把按钮文案改成“确认提交”，不要写成“提交”。
只改这个文案，其他代码不要动。
这里最重要的不是“文案改成什么”，而是最后一句：
其他代码不要动。
因为 Claude Code 有时会顺手整理周边代码。它可能觉得自己是在优化，但对你来说，这些额外改动会增加检查成本。
再举个简单例子。
你让它改一个表单按钮，它已经把按钮放对了位置，也保留了点击事件，只是按钮文案写错了。
这时不要说：
重新帮我写一下这个按钮。
这样很容易让它重新处理整个按钮，甚至重新生成附近代码。
更好的说法是：
只把按钮文案从“提交”改成“立即提交”。
按钮位置、点击事件、样式都保持不变。
这类问题的处理原则很简单：
只要主体没问题，就不要重来。指出具体错误，并限制修改范围。
第二类：理解跑偏
第二类问题更麻烦一点。
它不是某个字、某个颜色、某个样式写错了，而是 Claude Code 对任务的理解和你不一致。
比如：
- 你只是想改一个按钮文案，它却重写了整个表单
- 你只是想加一句“暂无数据”，它却新建了一个空状态组件
- 你只是想让标题居中，它却调整了整个头部布局
- 你只是想改一处间距，它却把页面布局重新排了一遍
这种情况下，如果你继续在它已有的方案上修，很容易越修越乱。
正确做法是先把它停住，然后重新说明你的真实意图。
例如：
停一下，不需要重写整个表单。
我的需求只是：把提交按钮的文案从“提交”改成“确认提交”。
保持以下内容不变：
- 按钮位置不变
- 点击事件不变
- 样式不变
- 其他输入框不变
只改按钮文案，不要改表单结构。
这个反馈里有几个关键信息。
第一，先明确否定它刚才的方向。
不需要重写整个表单。
第二，重新说清楚你真正要的结果。
只把提交按钮的文案从“提交”改成“确认提交”。
第三，列出不能动的部分。
按钮位置、点击事件、样式、其他输入框都不变。
第四，再用一句话收口。
只改按钮文案，不要改表单结构。
这类纠偏的重点不是“补一个小要求”，而是把它从错误方向里拉出来。
再看一个更常见的例子。
你让它给列表加一个空状态，它却新增了一个复杂组件，还调整了列表结构。
可以这样纠正：
停一下，不需要新增空状态组件。
我的需求只是：列表为空时，在当前列表区域显示一行“暂无数据”。
要求：
1. 列表长度为 0 时显示“暂无数据”
2. 有数据时继续展示原来的列表
3. 不改变现有列表结构
4. 不新增公共组件
这类问题的处理原则是：
如果方向错了，不要在错误方案上打补丁。先否定错误方向，再重新定义任务边界。
第三类：范围失控
第三类问题是：它做了你要的事，但顺手做了更多。
比如：
- 你让它改按钮文案，它顺手把按钮颜色也改了
- 你让它修一个错别字，它顺手改了整段文案
- 你让它加一句提示，它顺手调整了页面排版
- 你让它换一张图片，它顺手改了变量名
这种情况不是它完全没理解，而是它“发挥过头”了。
在个人小项目里，这种顺手优化可能问题不大；但在真实项目里，额外改动意味着额外风险。
尤其是样式、结构、命名这类改动，看起来很小，却可能影响到其他地方。
遇到这种情况，不要只说“你改多了”。要明确告诉它哪些改动撤回，哪些改动保留。
例如：
撤回按钮颜色和间距的修改，这两处不需要改。
只保留按钮文案从“提交”改成“确认提交”的改动。
之后再给 Claude Code 提需求时，可以提前加一句限制：
只处理本次需求，不要修改需求范围外的代码。
如果你希望更严格，可以写成：
严格只修改我指定的位置，其他文件和其他逻辑都不要动。
这类问题的处理原则是：
做多了，就让它撤回多余改动；下一次提前把修改范围说清楚。
怎么快速判断是哪一类问题
当你看到 Claude Code 的结果不对时，可以按下面这个顺序判断。
先看主体是否正确。
如果主体是对的，只是文案、颜色、提示语、间距这些小细节有问题，那就是局部不准。直接让它改具体位置，并强调其他部分不动。
如果主体不对，再看是不是它选错了做法。
比如你想要一个很小的修改，它却做成了一个完整重构；你想在原位置加一句提示，它却新建了一套组件。这就是理解跑偏。此时要先叫停，再重新说明你真正想要的方案。
如果主体和方案都还可以，但它额外改了很多东西，那就是范围失控。此时要让它撤回多余改动，只保留本次需求相关的部分。
如果你完全看不懂它在做什么，或者代码根本跑不起来，那就不要继续一条一条补救了。大概率是一开始的需求就没有讲清楚，需要重新整理需求再开始。
可以记住这四句话：
小地方错了：指出具体位置，只改那里
方向跑偏了：先停下来，重新说明目标
额外做多了：撤回多余改动，保留需要的部分
完全看不懂：重新整理需求，不要继续硬修
什么情况下应该重新开始
虽然很多问题都可以通过纠偏解决，但并不是所有情况都值得继续修。
下面几种情况，我更建议重新开始。
1. 已经改了几轮，结果越来越乱
如果你连续提醒了两三次，它还是没有回到正确方向，甚至越改越偏，说明当前上下文可能已经乱了。
继续追加指令，效果通常不会太好。
这时候不如开一个新对话，把前面踩过的坑整理成更明确的要求，再重新让它做。
2. 它已经生成了很多不需要的文件
如果你的需求本来只是改一个页面细节，但它新建了多个文件、组件、样式和工具函数，那么后续清理成本会很高。
这种情况下，与其一点点撤，不如重新开始，并在开头就限制：
不要新增文件，只在现有文件中修改。
3. 你的想法在过程中变了
有时不是 Claude Code 的问题，而是你自己在过程中发现：原来的需求不合适，想换一种做法。
这时旧结果已经不再服务于新目标，继续修只会越来越别扭。
更好的方式是重新描述新需求。
什么情况下适合继续纠偏
如果满足下面几个条件，就不必急着重来：
- 大体结果已经接近你想要的
- 需要修改的地方能说得很具体
- 改动范围比较小
- 每次反馈后结果都在变好
这时继续纠偏通常更高效。
可以给自己一个简单标准：
如果两三句话能说清楚怎么改，就继续纠偏；如果解释半天都说不清楚，不如重新整理需求。
可以直接复用的反馈句式
下面这些句式比较适合日常使用。
改一个小细节
把 [具体位置] 改成 [目标效果]。
只改这里，其他部分不要动。
示例：
把按钮文案改成“确认提交”。
只改这个文案，其他部分不要动。
同时改几个小问题
只调整下面几个点：
1. ……
2. ……
3. ……
除此之外，其他代码保持不变。
纠正错误方向
停一下，不需要 [它刚才做的事情]。
我真正需要的是 [你的目标]。
请保留 [不能动的部分]，只修改 [允许修改的部分]。
补充边界条件
刚才的方向不对。
这次请按下面范围处理：
- 可以改：……
- 不要改：……
- 最终效果：……
撤回多余改动
撤回对 [多余内容] 的修改。
只保留 [本次真正需要的改动]。
提前限制范围
这次只处理我描述的需求。
不要顺手优化、不要重构、不要修改无关代码。
把反复出现的问题写进规则里
如果某类问题只出现一次，靠当场纠偏就可以。
但如果同样的问题反复出现，就不应该每次都口头提醒。
比如：
- 它总是顺手改样式
- 它总是把简单需求做复杂
- 它总是新增不必要的文件
- 它总是改动需求范围外的代码
这些都应该沉淀成项目规则。
可以写到：
CLAUDE.md- 项目开发规范
- 组件生成模板
- 团队协作说明
这样下一次 Claude Code 在开始任务前就知道边界，而不是等它做完之后再返工。
最后总结
Claude Code 做得不符合预期时，先不要急着推倒重来。
先判断它属于哪种情况：
- 局部不准：具体指出哪里错，只改那里
- 理解跑偏：先叫停，再重新说明目标和边界
- 范围失控：撤回多余改动，只保留需要的部分
- 完全混乱：重新整理需求，不要继续硬修
AI 编程的重点不是“让它一次生成完美代码”，而是让它快速产出初稿，再通过清晰反馈逐步收敛。
如果你只会提需求，Claude Code 只能帮你开个头。
如果你会纠偏，它才能真正变成稳定的开发助手。
