用 Claude Code 接手别人的代码：第一个小时先画地图，再动手改

接手项目的第一天，我打开了前同事留下的一个内部工具仓库。README 只有三行，最后一次更新还是八个月前。我图省事，直接对 Claude Code 说「先把这个项目摸清楚，然后帮我改一下登录页的文案」。五分钟后，它不光改了文案，还「顺手整理」了认证相关的配置文件，甚至连那个谁都没碰过的生产部署脚本都被它动了。

幸好我跑 git status 时发现了，把改动全部还原了回去。但只要一想到：如果没发现就直接 git commit 了会怎样，现在还是后背发凉。问题不在模型够不够聪明，而在于我自己都不知道哪些地方能碰，就把活儿全交了出去。

接手别人的代码，第一个小时不该是「修改」的时间，而是「画地图」的时间。这篇文章就讲讲这张地图该怎么画，把它整理成一套即使第一次进陌生仓库也不会出事的步骤。

本文要点

• 第一个小时别急着「改」，先「画地图」。把能碰的地方和不能碰的地方提前分开。
• 交给 Claude Code 的只到「读完并列出清单」为止。哪些算保护区，由人来定。
• 动手改之前，一定先定好一条验证命令（构建或测试）。它才是「改好了」的证据。
• 第一个改动只挑那种用一条 git 命令就能还原的小事。
• 把摸清的内容写进一张备忘录。下一个进同一个仓库的人（包括未来的你自己）就不用把调查再做一遍。

为什么第一个小时最容易出事

进新仓库时栽的跟头，多半不是因为代码难，而是因为你看不清这个仓库长什么样。

哪个文件夹是页面，哪里是后端逻辑，哪个文件是生产环境的配置——这些都没看清就说「帮我改得好看点」，Claude Code 就会出于好意把一大片代码都改了。除非你明确说「这里别碰」，否则 AI 默认会把它当成可以改的地方。

接手别人的项目尤其危险。前同事的潜规则、命名习惯、不知道为什么留着的注释代码——这些上下文代码里一个字都没写。人接手第一天也搞不清全部。正因如此，第一件该做的事不是编辑，而是画地图。

画地图的四个步骤

顺序很重要：先定可读范围，再定保护区，接着定验证命令，最后才小心翼翼地改一个地方。就按这个顺序来。

步骤一：用一句话写下今天的目标

「理解这个项目」这个目标太大了。无论是 Claude Code 还是人，目标一大就找不到该停在哪里。

换成这样写：「只改登录页一处文案，并确认构建能通过」。一句话能说清的目标，做没做完一眼就能看出来。

步骤二：分清可读范围和绝对不能碰的范围

这是整张地图的核心。在把「全都可以读」交给 Claude Code 之前，先用文字写明哪些地方不能碰。

我每次都会放进保护区的，是认证、计费、环境变量文件（.env）、生产部署脚本。这些一旦改错损失大，而且很难还原。所以一开始我就明确：「这些可以读，但不准写」。

步骤三：提前定好验证命令

就算它跟你说「改好了」，凭什么算改好了？这个标准要提前定。

大多数项目里，构建命令或测试命令就是验证标准。npm run build 能通过，npm test 全绿。把这一条命令在动手前就定好，就不会盲信 Claude Code 的「搞定了」，而是用机器给出的通过与否来判断。

步骤四：只改一个能还原的小地方

地图画好了，第一个改动也别贪多。文案修改、补一行注释、改一个明显的拼写错误——挑一个用 git checkout 一条命令就能还原的来做。

忍住「顺便把那个也改了」的冲动。大的改动谁都审不动，出了事还原起来也麻烦。

哪些交给 Claude Code，哪些自己说了算

画地图时哪些交出去、哪些自己攥住，这两者一旦混在一起，开头那种事故就来了。

工作	负责人	理由
摸清文件清单和文件夹结构	Claude Code	机械式读取又快又准
「这个功能在哪里」之类的调查	Claude Code	它擅长搜索和总结
哪些算保护区	人	损失大小取决于上下文，AI 不知道
验证命令的最终拍板	人	项目特有的情况只有人清楚
对生产、计费、认证的改动	人	难以还原的操作由人来批准

原则很简单：读取、列清单的活儿交出去；难以还原的判断由人攥住。 只有确认过安全的操作，之后才逐步「升级」交给 Claude Code。

权限的细致设计我单独写了一篇。如果一开始不知道该先拦住什么，可以看 权限指南。

可以直接复制的画地图提示词

下面是第一个小时里我实际会发的提示词。直接贴过去，只把仓库名改成你自己的。

我是第一次接触这个仓库。请先不要做任何编辑。
请按顺序调查下面这些内容，并用列表把结果汇报给我。

1. 顶层文件夹结构，以及各自的作用（可以推测，但要标明是推测）
2. 构建、测试、启动用的命令（从 package.json 或 README 里找）
3. 与认证、计费、环境变量、生产部署相关的文件位置
4. 「登录页的文案」在哪个文件里

汇报之后，第 3 点列出的那些文件这次设为「只读、禁止编辑」。
唯一允许编辑的，是第 4 点找到的那一个文件。

关键是第一行就钉死一句「先别编辑」。少了这句，有的 AI 会在调查的同时顺手开始改。

可以直接运行的验证脚本

地图画好后，最好让改动前后能跑同一套检查。下面这个脚本会确认改动前后构建能否通过，以及差异是不是铺得太开。用 Node.js 运行。

// verify-edit.mjs
// 确认修改前后构建能否通过，以及改动是否超出预期范围
import { execSync } from "node:child_process";

// 提前定好「一条命令能还原的范围」内的改动文件数上限
const MAX_CHANGED_FILES = 3;

function run(cmd) {
  return execSync(cmd, { encoding: "utf8" }).trim();
}

try {
  // 统计被改动的文件数
  const changed = run("git diff --name-only")
    .split("\n")
    .filter(Boolean);

  console.log(`改动文件数: ${changed.length}`);
  changed.forEach((f) => console.log(`  - ${f}`));

  if (changed.length > MAX_CHANGED_FILES) {
    console.error(
      `差异铺得太开（${changed.length} > ${MAX_CHANGED_FILES}）。`,
    );
    console.error("先用 git checkout 还原，把改动拆小再做。");
    process.exit(1);
  }

  // 确认有没有动到保护区
  const protectedHits = changed.filter((f) =>
    /(^|\/)\.env|auth|billing|deploy/i.test(f),
  );
  if (protectedHits.length > 0) {
    console.error("保护区被改动了:");
    protectedHits.forEach((f) => console.error(`  - ${f}`));
    process.exit(1);
  }

  // 确认构建能否通过（按你的项目替换这条命令）
  console.log("正在确认构建...");
  run("npm run build");
  console.log("构建 OK，改动落在安全范围内。");
} catch (err) {
  console.error("验证失败:", err.message);
  process.exit(1);
}

用 node verify-edit.mjs 运行。一旦改动文件太多，或者动到了保护区，它会当场停下。开头那个「连认证文件都被整理了」的事故，只要过一遍这个脚本，本来就能在事前被拦住。

三个见效的场景

具体在什么样的仓库里能用，我列三个自己试过的情况。

1. 接手的内部工具 进一个没文档的代码库时。先让它把文件夹结构和启动命令列成清单，把认证和配置文件钉死成保护区。第一个改动选管理后台的标签文字这种，结果一眼就能从界面上看出来的。

2. 给公开仓库的第一次贡献 第一次给别人的开源项目发 Pull Request 时。先让它定位测试命令，在 npm test 保持全绿的前提下提交一个小改动。比起一大堆改进建议，一个能还原的单文件修改反而更容易被合并。

3. 重启搁置已久的项目 重新捡起搁了半年的代码时。让 Claude Code 调查「哪些还能跑」，把坏掉的入口画进地图。要改，也从最容易还原的那一处开始。

常见的坑和修法

坑一：想一次把全部改完 「顺便重构一下」一上头，差异就膨胀到 50 个文件，谁都审不了。修法是用上面的验证脚本给改动文件数设上限，超了就先还原、再拆开做。

坑二：构建成功就算完事 本地构建通过了，不代表界面就符合预期。如果是改文案，得真的把那个页面打开、用眼睛确认文字，才算一套完整流程。

坑三：保护区只靠嘴说 就算在提示词里说了「别碰认证」，长任务进行到一半也可能被它忘掉。修法是用验证脚本机械地把对保护区的改动挡掉。靠命令守住，而不是靠人的记性。

坑四：画好的地图没留下来 辛辛苦苦花一小时摸清楚，不留备忘录的话，下次又得把同样的调查再做一遍。把文件夹结构、验证命令、保护区写进一张备忘录，未来的自己会感谢你。

那张地图备忘录，写进项目的 CLAUDE.md 当规则会更管用。写法我整理在 CLAUDE.md 最佳实践 里。

常见问题

Q. 第一个小时真的什么都不改也行吗？ A. 改也可以，但只改「能还原的那一个小地方」。剩下的时间用来画地图，结果上事故更少、整体反而更快。

Q. 直接对 Claude Code 说「全都可以读」危险吗？ A. 只读不危险，危险的是「写」的权限。读取放宽，写入收窄，这就是基本的分法。

Q. 不知道验证命令的项目怎么办？ A. 先让 Claude Code 从 package.json 或 README 里列出候选。要是还不清楚，就先把「git status 里不出现差异」当成最低限度的验证。

Q. 用 PowerShell 也能做同样的事吗？ A. 能。数一数 git diff --name-only 的结果再和上限比较，这套逻辑用 PowerShell 照样能写。验证脚本按你用的环境改写就行。

Q. 这套流程新手也能跑起来吗？ A. 能，而且越是新手越见效。就算没完全看懂代码，只要先定好「哪些地方能碰」，大事故就能避开。想从基础打牢的人，可以先读 入门指南，之后会更顺。

我实际试下来的结果

这套流程，是开头那次事故之后我给自己做的。试下来最见效的，是在验证脚本里加上了「改动文件数上限」和「保护区自动检查」这两项。

实际在接手的仓库里跑了三次左右，其中一次因为改动文件数超过上限被拦了下来。打开一看，Claude Code 在改文案的同时把一个公共组件也改了，要是放过去，就会是一个影响范围根本读不清的差异。多亏它停了下来，我才把改动拆成两次分别提交。

不是「交给聪明的 AI 就没事」，而是「在摔倒也能爬起来的范围里交出去」。光是先画好地图，第一个小时的手感就完全不一样了。如果团队里有非工程师想一起用这套分法，写给非工程师的入门 也会派上用场。

Claude Code 的官方用法可以在 Anthropic 官方文档 里确认。想把手头的操作规则固定下来、做成团队能复现的形式，可以来 研修与咨询，我们一起把你具体的仓库画成地图。