CCClaude Code中文喂饭教程

完整案例：从前端 Bug 到验收交付

Claude Code 完整前端 Bug 案例：从现象描述、Plan Mode、最小修复、截图反馈、diff 审查、/verify、/code-review 到交接总结，跑通一次可控闭环。

这篇不是再讲一遍“怎么修前端 Bug”，而是把一次真实任务拆成完整闭环：怎么描述问题、怎么让 CC 先分析、怎么限制修改范围、怎么审查 diff、怎么截图反馈、怎么验收，最后怎么形成可交接的总结。

适合跟着演练的场景：

案例背景

假设现在有一个商品卡片页面，在桌面端正常，但在 390px 宽度的手机页面里，按钮会换行并遮挡价格。

这个问题看起来只是样式 Bug，但如果处理方式不对，很容易出现三种风险：

风险结果
描述太模糊CC 只能猜，可能改错组件
范围没限制一个局部卡片问题被改成全局布局调整
不做验收桌面端修好了，移动端另一个宽度又坏了

所以这类任务要按“现象 -> 计划 -> 最小修复 -> diff 审查 -> 页面验收 -> 总结交付”的顺序走。

第 0 步：先把任务边界说清楚

不要一上来就说“这个页面帮我优化一下”。先把问题压成一个可验证的 Bug。

我有一个前端 Bug，请先进入 Plan Mode，不要直接修改文件。

问题现象：
商品卡片在移动端 390px 宽度下，购买按钮会换行，并且遮挡价格区域。

页面位置：
【填写页面路径或组件位置】

复现方式：
1. 打开【页面路径】
2. 切到移动端宽度 390px
3. 查看商品卡片底部价格和按钮区域

期望结果：
价格和按钮在移动端都完整可见，不遮挡、不横向溢出，桌面端原布局不受影响。

限制：
1. 先只读分析原因。
2. 不要改全局主题和全局布局。
3. 不要重构无关组件。
4. 不要引入新依赖。
5. 修复方案必须能说明验收方式。

这段话的关键不是“写得长”，而是让 CC 明确知道：问题在哪里、怎么复现、什么算修好、哪些地方不能碰。

第 1 步：让 CC 先给计划

CC 的计划里至少要包含 5 件事。

计划项为什么重要
可能原因判断是布局、样式、数据还是交互问题
准备查看的文件防止它乱翻或漏看关键组件
最小修改点防止顺手重构
风险点提前知道可能影响桌面端、其他卡片或复用组件
验收方式修完后有明确检查标准

如果 CC 的计划只说“我会检查并修复样式”，还不够。继续追问：

这个计划还不够具体。

请补充：
1. 你准备优先查看哪些组件和样式文件。
2. 你判断问题更可能来自父容器、卡片布局、按钮宽度、文字换行还是断点规则。
3. 你打算如何避免影响桌面端。
4. 修复后需要检查哪些宽度。
5. 哪些结论来自代码，哪些还只是推测。

计划阶段的目标，是让 CC 把“猜”变成“有依据地判断”。

第 2 步：批准最小修复

计划合理后，再允许它改。批准时不要说“可以改”，而是带着边界批准。

可以按你给出的最小方案修复。

执行要求：
1. 只修改和商品卡片移动端布局直接相关的文件。
2. 如果必须改公共组件，请先说明原因。
3. 不要改变桌面端视觉风格。
4. 不要改文案、接口、数据结构和业务逻辑。
5. 完成后请给出 diff 说明和验收清单。

这里的“最小方案”不是让 CC 少干活，而是让它只解决已定义的问题。前端任务最怕的是本来修一个按钮，最后全站间距都变了。

第 3 步：先审查 diff，再看页面

修完后先不要急着接受结果。先让 CC 解释 diff。

请先解释这次 diff，不要继续修改。

请按下面格式输出：
1. 修改了哪些文件。
2. 每个文件为什么要改。
3. 是否改到了全局样式、公共组件或复用组件。
4. 是否有超出这个 Bug 的改动。
5. 桌面端和移动端分别怎么验收。

审查时重点看 4 类信号：

信号判断方式
文件范围是否只改了目标组件附近的文件
全局影响是否动了全局 CSS、主题变量、基础布局
业务变化是否改了接口、状态、文案、数据字段
验收清晰度是否能说出哪些宽度、哪些交互要检查

如果 diff 里出现不该有的改动，直接让 CC 收回：

这次 diff 范围过大，请先不要继续扩展。

请只保留和移动端商品卡片遮挡问题直接相关的修改。
请撤回或改小下面这些无关改动：
【列出文件或改动点】

然后重新说明新的最小 diff。

第 4 步：用截图反馈做二次修正

如果第一次修完后，页面仍然有细节问题，不要说“还是不行”。把反馈变成可执行信息。

修复后还有一个细节问题，请只做二次修正。

当前现象：
390px 宽度下按钮不遮挡价格了，但按钮文字仍然换成两行，卡片高度变得不稳定。

期望结果：
按钮文字保持一行；如果空间不足，优先调整按钮区域布局，不要压缩价格文字。

限制：
1. 只处理这个二次问题。
2. 不改桌面端布局。
3. 不扩大到其他卡片样式。
4. 修完说明这次 diff 和上次 diff 的区别。

截图反馈的重点是“位置 + 当前现象 + 期望结果 + 不要动哪里”。只说“好看点”“紧凑点”“专业点”，CC 很容易把任务扩成设计重做。

第 5 步：用 /verify 做验收

页面看起来修好了，也要让 CC 做一次验收总结。

/verify

请按前端 Bug 的标准验收这次修改：
1. 原复现步骤是否通过。
2. 390px 宽度是否正常。
3. 375px、414px 和桌面端是否正常。
4. 是否仍有文字溢出、遮挡、横向滚动或按钮不可点。
5. 是否存在超出本 Bug 的修改。
6. 还需要人工重点复查哪些位置。

验收结果最好能落到具体判断，而不是一句“已修复”。例如：

检查项合格表达
原问题390px 下价格和按钮不再重叠
响应式375px、390px、414px、桌面端都保持布局稳定
交互按钮可点击，点击区域没有被遮挡
范围没有修改接口、数据、全局主题
风险复用该卡片的页面建议再抽查一次

第 6 步：用 /code-review 做二次把关

如果这次改动要提交，建议再让 CC 按审查视角看一遍。

/code-review

请审查这次前端 Bug 修复，重点看：
1. 是否有 AI 生成代码常见风险。
2. 是否过度修改或引入无关变更。
3. 是否破坏复用组件、响应式断点或交互状态。
4. 是否存在只在当前截图下成立、换个宽度就失效的问题。
5. 是否还有需要补充验证的地方。

只输出问题和风险，不要继续改代码。

这一步不是怀疑 CC，而是把“写代码”和“审代码”拆开。真实项目里，AI 生成代码更需要独立审查。

第 7 步：让 CC 写交付总结

最后要留下可交接记录。以后回看提交、写日报、给同事说明，都能直接复用。

请根据这次修复写一份交付总结。

格式：
1. 问题现象
2. 根因
3. 修改内容
4. 验收方式
5. 风险和后续建议

要求：
1. 不要夸大成果。
2. 不要写没有验证过的内容。
3. 如果有需要人工复查的地方，要明确写出来。

一份合格的总结应该像这样：

问题现象：
商品卡片在移动端 390px 宽度下，按钮区域换行并遮挡价格。

根因：
卡片底部区域在小宽度下没有足够的收缩规则，按钮最小宽度和父容器布局冲突。

修改内容：
仅调整商品卡片底部区域的响应式布局，未修改接口、数据结构、文案和全局主题。

验收方式：
已按原复现步骤检查 390px 宽度，并补充检查 375px、414px 和桌面端展示。

风险和后续建议：
该商品卡片如果在其他页面复用，建议再抽查一次列表页和详情页。

完整闭环检查表

阶段必须完成什么
描述问题页面、设备、复现步骤、当前现象、期望结果
计划分析原因判断、文件范围、最小方案、风险、验收方式
批准修改明确只修当前 Bug，不做无关重构
diff 审查看文件范围、全局影响、业务变化和验收说明
页面反馈用具体截图描述做二次修正
/verify检查原复现、响应式、交互和改动范围
/code-review识别 AI 生成代码风险和过度修改
交付总结留下根因、改动、验证和风险记录

什么时候不要继续让 CC 改

遇到下面情况，先停下来重新收敛任务：

这时更适合回到 Plan Mode，让 CC 重新读代码、重新拆范围，而不是继续在同一轮里让它越改越多。

相关教程

验收结果

上一篇：前端 Bug 基础流程下一篇：排查构建失败