五个Claude Code提示词，把小改动变成项目事故之前拦住它

Claude Code写代码确实快，但快有个副作用：它经常还没搞懂项目就开始动手。你提一个小需求，它能给你改出一堆无关文件、弄坏原本好好的功能、把已有逻辑重复实现一遍，还顺手加几个新依赖——最后告诉你「完成了」，其实根本没跑过完整流程。

我现在的做法是：不让它直接动手，强制它按这个顺序来——先理解 → 再定范围 → 然后调查 → 最后构建 → 验证。下面是五个可以直接复制进Claude Code的完整提示词，亲测有效。

---

一、动手前先理解项目

适合在给老代码库加功能或修东西之前用。这招能在误解变成代码之前就拦住它。

让Claude充当刚加入现有项目的高级工程师：

Act as a senior software engineer joining an existing project.

Before writing or editing any code, inspect the project and explain how it currently works.

Current task:
[DESCRIBE WHAT YOU WANT TO BUILD OR FIX]

Protected functionality:
[LIST FEATURES, PAGES, DATA OR INTEGRATIONS THAT MUST NOT CHANGE]

Review:
1. The folder and file structure.
2. Application entry points.
3. Frontend and backend architecture.
4. Database models and relationships.
5. API routes and external services.
6. Authentication and permissions.
7. State management.
8. Shared components and utilities.
9. Existing features related to the task.
10. Tests and project documentation.

Then provide:

PROJECT SUMMARY
Explain what the application currently does.

RELEVANT FILES
List the files connected to the requested task and explain what each one controls.

EXISTING PATTERNS
Identify components, utilities and conventions that should be reused.

RISKS
Explain what could break if the task is implemented incorrectly.

MISSING CONTEXT
List anything you cannot confirm from the project.

Do not edit any files yet.
Do not invent missing information.
Wait for me to confirm your understanding before creating an implementation plan.

核心就是逼它在写第一个字之前先给你交一份「项目现状报告」，明确哪些文件相关、哪些是雷区。

---

二、动手前锁定范围

适用于Claude总爱把小改动升级成大重写的情况。让它先签一份「实施合同」：

Create an implementation contract for the following task.

Requested change:
[DESCRIBE THE FEATURE, FIX OR UPDATE]

Expected user experience:
[DESCRIBE WHAT THE USER SHOULD SEE AND DO]

Protected functionality:
[LIST EVERYTHING THAT MUST REMAIN UNCHANGED]

Do not edit any code yet.

The contract must include:
1. Your exact understanding of the request.
2. The current user flow.
3. The proposed user flow.
4. Every file expected to change.
5. Why each file needs to change.
6. Any new files required.
7. Existing components and utilities that should be reused.
8. Validation, loading, success and error states.
9. Authentication or permission requirements.
10. Possible regressions.
11. The smallest safe implementation.
12. A step-by-step plan.
13. A testing plan.
14. A rollback plan.

Create two explicit sections:

APPROVED SCOPE
List every file and area you will be allowed to modify.

OUT OF SCOPE
List unrelated refactors, styling changes and improvements that will not be included.

Wait for my approval before editing any code.

After approval, stop and ask before touching any file outside the approved scope.

关键是「OUT OF SCOPE」那一栏——它得明确列出哪些东西不许碰，之后只要敢越界，你立刻能指出来。这也给了你一个具体的对照物，等它干完活后逐条验收。

---

三、带证据排查Bug

Claude很容易凭第一次猜测就直接改代码。这个提示词强迫它先调查再动刀：

Act as a staff software engineer investigating a bug.

Bug:
[DESCRIBE THE PROBLEM]

Expected behaviour:
[WHAT SHOULD HAPPEN]

Actual behaviour:
[WHAT CURRENTLY HAPPENS]

Reproduction steps:
[LIST THE STEPS OR WRITE UNKNOWN]

Error messages:
[PASTE ERRORS OR WRITE NONE]

Recent changes:
[LIST RECENT CHANGES TO THE PROJECT]

Before proposing any fix, investigate and provide a root cause analysis.
Show the evidence that supports the root cause.
Then propose the minimal fix.
Do not modify any code until I approve the fix.

让它先交证据、再给根因、最后提最小修复方案——没你批准不许写代码。这一下能省掉多少「我都改完了你才发现方向不对」的崩溃时刻。

---

四、最小改动清单

这个更简单粗暴，适合那种已经跑得不错的项目，你只想要一个很小的增量变化：

You are about to make a change to this codebase.

Required change:
[DESCRIBE THE SMALL CHANGE]

Constraints:
1. Only modify files that are strictly necessary for this change.
2. Do not refactor unrelated code.
3. Do not add new dependencies unless absolutely required.
4. Do not duplicate existing logic - reuse existing components and utilities.
5. List every file you will change and explain why it's necessary.
6. Show your plan before writing any code.

第五点是关键——先列清单再动手，逼它把「必须改的文件」和「它想顺手改的文件」区分开。

---

五、验收标准清单

每次Claude说「改好了」之前，先让它自己照这份清单过一遍：

Before claiming completion, verify:

1. The exact requested behavior works.
2. Existing related features still work.
3. No unrelated files were modified.
4. No new dependencies were added.
5. The code follows existing patterns in the project.
6. Authentication and authorization flows are not broken.
7. Error states are handled properly.
8. No debug code, console.log, or commented-out code is left behind.
9. The change is backward compatible.
10. Tests (if any) have been run and updated.

If any item fails, fix it before reporting completion.
After verification, provide:
- What was changed
- How it was tested
- Any remaining risks

自从让它先自检再交活，基本没再出现过「说完成了结果一跑就炸」的情况。

---

这套流程本质上是把「先问清楚再干活」变成了Claude Code的强制行为。前三个提示词负责阻止它误解需求、扩大范围、瞎猜根因，后两个负责控制改动面积和验收质量。合起来就是一套完整的防炸护栏——用的时候按顺序过一遍，小改动再也不会变成项目事故了。