日常建议

让 Claude 改代码前，先让它说明理解和计划。这样更容易控制修改范围。

一个稳妥的修改流程

日常改 bug 或小需求，可以按这个顺序来：

1. 说明目标和现象
2. 让 Claude 先定位相关文件
3. 让 Claude 给出最小修改方案
4. 确认后再让它改
5. 查看改动摘要和 diff
6. 运行测试或构建验证

可以直接这样说：

帮我修复这个问题：点击保存后没有提示成功。

要求：
1. 先定位相关代码，不要马上改。
2. 找到原因后说明最小修改方案。
3. 只改和这个问题直接相关的文件。

三种模式

Claude Code 有三种工作模式，通过 Shift + Tab 循环切换。底部状态栏会显示当前模式。

模式	界面提示	核心行为	适用场景
默认模式	? for shortcuts	安全优先。每次修改文件或执行命令，都会请求批准。	日常编码，需要对操作保持审阅。
自动接受编辑	⏵⏵ accept edits on	高效。自动批准文件编辑，部分危险 shell 命令仍需确认。	AI 表现稳定、希望快速迭代代码。
计划模式	plan mode on	只读。只分析和制定计划，不执行任何文件修改。	需求分析、重构规划、学习探讨。

默认模式

这是启动后的默认状态。Claude 每次要读写文件或执行命令时，都会弹出确认提示让你审批。

适合你对 AI 还不够信任、或改动比较关键的时候使用。随时可以通过 /permissions 调整哪些操作可以自动允许。

自动接受编辑模式

当你对 Claude 的表现已经很放心、需要快速迭代时，切换到自动接受编辑模式：

• 文件编辑不再逐一确认，直接执行。
• 危险操作（如 rm、git push）仍然会提示。

建议先用默认模式确认 Claude 理解了需求，再切换到自动接受模式执行。

计划模式

对于复杂改动，先切换到计划模式或直接输入：

/plan 给订单列表增加一个按日期范围筛选的功能。保持现有分页和排序不变。

Claude 会只读分析，给出方案和影响范围，等你确认后再切换到其他模式执行。这种方式的好处：

• 修改前就知道会改哪些文件、怎么改。
• 可以在改代码前调整方向。
• 减少"改完才发现不对"的情况。

适合计划模式 vs 可以直接改：

适合计划模式	可以直接改
新功能或新页面	修个文案、改个颜色
改动超过 2-3 个文件	加个 console.log
不确定实现方式	目标非常明确的小改动
需要选技术方案	单文件的小调整

不需要时直接用自然语言即可。Shift + Tab 切回默认或自动接受模式后，Claude 才会动手改代码。

小需求怎么提

描述需求时，最好同时说明“要什么”和“不要什么”：

给设置页面增加一个“复制 API Key”的按钮。

要求：
- 保持现有样式。
- 只在已有 API Key 时显示。
- 点击后显示一个简单成功提示。
- 不要重构整个设置页面。

Bug 怎么提

Bug 信息越具体，Claude 越容易定位：

有个 bug：用户退出登录后，刷新页面又显示为已登录。

我观察到：
- 点击退出后页面会跳到登录页。
- 刷新后又回到首页。
- 浏览器里好像还有 token。

请先分析原因，不要改代码。

让 Claude 改得更小

如果你担心它改太多，可以明确限制：

请用最小改动修复，不要做额外重构。

除非必须，不要修改公共组件。

如果需要改超过 3 个文件，请先停下来告诉我原因。

改完后检查

修改完成后，继续问：

总结一下你改了哪些文件，每个文件为什么要改。

请检查这次改动有没有明显风险。

我应该运行哪些命令来验证这次修改？

如果项目使用 git，也可以让 Claude 帮你看当前改动：

帮我看一下当前 git diff，指出有没有不必要的改动。

提交前检查

提交前可以这样问：

请按代码审查的角度检查当前改动，重点看 bug、遗漏测试和不必要的修改。

帮我写一个简洁的 commit message。

请根据这次改动整理 PR 描述，包括变更内容和验证方式。

常用验证提示

场景	可以这样问
不知道跑什么	请根据项目配置告诉我应该跑哪些验证命令
测试失败	解释这个失败原因，先不要改代码
构建失败	帮我定位构建失败和本次改动是否有关
担心影响范围	这次改动可能影响哪些页面或功能？