给已有仓库接入 Claude Code 的第一天：不弄坏代码，挑出第一个安全任务的步骤

入职第三天，我被丢了一坨大概 150 个文件的支付相关代码。文档几乎为零。不管问谁，得到的回答都是「它现在能跑，最好别去碰」。我图省事，直接跟 Claude Code 说了一句：「把这个仓库摸清楚，看到不顺眼的地方顺手改一下。」

十分钟后，Claude 信心满满地回我「已经整理了 20 个文件」。我打开 diff，整个人凉了半截。它把数据库迁移用的 SQL 文件重新格式化了，把 .env.example 的顺序重排了，还擅自把支付重试的等待时间「优化」掉了一半。代码确实能跑。但要是这些上了生产环境，客服电话会被「重复扣款」的投诉打爆。

问题不在 Claude 不够聪明。只是我在第一天交给它的范围太宽了。要把别人的庞大代码安全地交出去，与其去找一个更聪明的 AI，不如先花 30 分钟把「按什么顺序读、哪里不许碰、第一个小活儿是什么、怎么算干完」定下来。光这一步，第一天的事故基本就消失了。今天我就把这 30 分钟的内容，整理成能直接复制粘贴的样子。

本文要点

• 已有代码的第一天，「全看一遍顺手改」是最危险的。因为范围还含糊就开跑了。
• 头 30 分钟要做的不是设计文档，而是一张帮你安全挑出第一个任务的便签。
• 便签上只写四件事：阅读顺序、不许碰的地方、第一个小活儿、判断「干完了」的验证命令。
• 第一个活儿只限定在「容易回退的地方」。文案、按钮文字、测试名称这类正合适。
• 交给 AI 的只到「调查、打草稿」为止。生产数据库、计费、删除、发布按钮，由人来按。

为什么第一天的第一条指令最容易栽

Claude Code 很快。正因为快，第一次交给它的信息一旦太宽，它会连无所谓的 diff 都全力以赴地做出来。

换成人类新人，会先问一句「这里我能动吗？」。AI 不问。它出于好心把范围扩大。你说「整理一下」，它真的会连犄角旮旯都整理。把迁移文件重排版、把计费重试「优化」掉，它自己都觉得是在帮忙。

所以第一天该做的，既不是把代码全读进去，也不是定一份漂亮的改进计划，而是划边界。哪些可以擅自动手，哪些必须先问人。先把这条线划好，对 Claude 的请求就从「自由发挥」变成了「在这个范围内、留下证据」。划这条线只要 30 分钟，并不需要把代码全部理解透。

30 分钟做出来的第一天便签

写在纸上或记事本里都行。只填下面这四项。它们的顺序也有讲究。

1. 把阅读顺序划窄。 别一上来就读全部文件，先只读 README 和 package.json。这样就知道用的是什么语言、怎么启动、用了哪些工具。接着挑 2~3 个主要页面或路由。这就够了。
2. 写下不许碰的地方。 计费、登录认证、环境变量、数据库迁移。这些地方明确写上「可以读，但不准改」。不写的话，Claude 会把它们当成普通的编辑对象。
3. 挑一个第一个小活儿。 只限定在容易回退的地方。文章末尾的文案、按钮标签、看不懂的测试名称。这些就算搞砸了也能立刻还原。
4. 定下判断「干完了」的验证方式。 构建能不能过、diff 是否在预期范围内、页面有没有崩。不靠感觉，靠命令的结果来判断。

把这四项填完，第一天的不安基本就消了。因为你掌握的不再是「Claude 会闯什么祸」，而是「我把范围交到了哪一步」。

交给 AI 的范围，和由人来定的范围

把这条线用文字写下来，每次就不用纠结了。我自己用的划分是这样的。

要做的事	交给 Claude	由人来定
读代码、归纳结构	○ 让它打草稿	最终理解自己确认
提议「不许碰的地方」	○ 让它列候选	计费、认证必须人来拍板
修改文案或标签	○ 可以交给它	看 diff 后再批准
写入生产数据库	×	由人手动执行
删除、发布、计费相关	×	由人来按按钮

关键是：一开始就把危险操作全部放进「先问人」这一侧。只有确认安全的操作，事后才升级为自动。反过来不行。先大范围放权、出了事再收紧，顺序是反的。

想把这套思路了解得更细的话，搭配 Claude Code 入门第一步指南 和 Claude Code 最初 30 分钟检查清单 一起读，第一天的动作就能串起来。

可以直接复制的请求模板

诀窍是：第一步别让它编辑。先让它「只读、只汇总成表格」。

我是第一次接触这个仓库，请先不要做任何编辑。
按下面的顺序阅读，并把结果用表格返回给我。

1. 读 README 和 package.json，列出用的语言、启动命令、主要依赖
2. 列出碰了会出事的地方（计费、认证、环境变量、数据库迁移），并附上文件路径
3. 提出 3 个容易回退的「第一个小活儿」候选，每个都说明理由
4. 对每个候选，写出确认完成用的命令（构建、查看 diff 等）

再强调一次：这个阶段一个字都不要编辑。

表格回来后，自己亲眼核对一遍「不许碰的地方」有没有漏。漏了就补上，然后才终于只交出一个任务。

刚才的候选里，只推进 ○○（修改文章末尾的文案）这一项。
计费、认证、环境变量、迁移文件一律不准碰。
编辑后执行 `npm run build`，再用 `git diff --stat` 给我看 diff。
如果弄坏了，先用一行说明原因和修法，然后停下来。

如果一开始就把「不许碰的地方」写进 CLAUDE.md，每次就不用再贴这段注意事项了。具体写法整理在 CLAUDE.md 最佳实践 里。

让机器替你做检查的一小段代码

把「准备妥当了才交出去」全靠人脑记，忙起来的那天一定会漏。所以让机器来判断这张便签是不是最起码备齐了。下面这段代码用 Node.js 可以直接跑。

// 机器检查：第一天的便签是否已经处于「能交给 Claude」的状态
const repoMap = {
  goal: "挑出一个容易回退的第一任务",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "修改文章末尾的文案（不碰支付代码）",
  proofCommands: ["npm run build", "git diff --stat"],
};

function isReady(map) {
  const reasons = [];
  if (map.readFirst.length < 2) reasons.push("阅读顺序太窄或未设置");
  if (map.protectedAreas.length === 0) reasons.push("不许碰的地方为空");
  if (!map.proofCommands.some((c) => c.includes("build"))) {
    reasons.push("缺少构建确认命令");
  }
  if (!map.firstTask) reasons.push("还没选第一个任务");
  return { ready: reasons.length === 0, reasons };
}

const result = isReady(repoMap);
console.log(result.ready ? "可以交出去" : "先别交: " + result.reasons.join(", "));

运行后是这样：

node check-repo-map.mjs
# => 可以交出去

试着把 protectedAreas 改成空数组再跑，会输出「先别交: 不许碰的地方为空」。就这么点东西，却能在交出去之前，挡住「忘了写不许碰的地方就全自动跑起来」这个最常见的事故。这张便签直接贴进 CLAUDE.md 或 issue，明天的自己和同事就能复用同一份判断。

实际起作用的三个场景

1. 运营博客时，守住能赚钱文章的链接 只想改热门文章末尾的引导文案时，跟 Claude 说「改善一下文案」，它会顺手连商品链接的 URL 都动。于是我把范围关上：「文案可以改，但链接 URL 一个字都不准动。改完把构建结果和 diff 给我看。」这样既能打磨文字，又不会弄坏直接关系到收入的链接。

2. SaaS 里，绝不靠近计费处理 设置页面的说明文字看不懂时，要改的对象就只有显示文本。计费、套餐变更的逻辑不让它碰。只要在便签的「不许碰的地方」里加上 billing/，就能防止 Claude 出于好心去动重试逻辑。

3. 内部工具里，只改输出的列名 有人反映 CSV 导出的列名看不懂。要改的只是列名字符串，跟统计逻辑是两码事。跟它说「只改列名的显示字符串，计算公式不准碰，用样本数据把输出给我看」，确认起来一瞬间就完了。

三个场景的共同点不是 Claude 能力不足，而就一句话：边界一薄就出事。边界写得越清楚，AI 反而动得越安全、越快。

容易踩的坑和修法

坑 1：一上来就让它读全部文件。 时间和 token 都耗在无关紧要的格式整理上，真正该改的反而做得很单薄。修法是把阅读对象收窄到 README、package.json 外加 2~3 个主要路由。整体把握等第一个任务做完了再一点点扩大。

坑 2：不写不许碰的地方。 Claude 会把计费、认证、部署配置当成普通编辑对象。修法是带上文件路径写一份保护清单，并让它常驻在 CLAUDE.md 里。口头叮嘱会被忘，写下来的东西会留着。

坑 3：不定验证命令就信「我做好了」。 那样每次都得人去猜完成报告靠不靠谱。修法是在请求文里一开始就写上「构建并把 diff 给我看」。HTTP 200 或者一句像模像样的回复，都不是成功的证据。只相信真正跑出来的结果。

常见问题

Q. 先把已有代码的全貌理解透再交给它，不是更安全吗？ 理想是这样，但第一天理解不完全貌。等它理解完，什么都推进不了，所以先把「不许碰的地方」关上，从一个容易回退的任务开始。理解这事，边干边扩展反而更快。

Q. 第一个任务该小到什么程度？ 以「一个文件、一句文案、一条命令就能搞定」的颗粒度为准。请求一大，Claude 就会好心地把范围扩开。确认完构建和截图再进下一步，既不拖慢速度，又能减少回退的时间。

Q. 不许碰的地方写在哪里最好？ 写在 CLAUDE.md 里最能坚持下去。每次往提示词里贴的做法，忙起来那天就会忘贴。作为项目规则放在一个地方，新任务也会自动生效。

Q. 我说了「别碰」，Claude 还是碰了。 多半是保护对象只写到了文件名，没把整个目录指定进去。不要只写 billing.js，要像 billing/ 这样按范围写。要是还越界，就在请求文开头加一道「编辑前先声明要动的文件再继续」，它就比较容易停下来。

Q. 这张便签每次都要重做吗？ 每个仓库做一次，之后就能反复用。贴进 CLAUDE.md 和 issue，明天的自己和同事都能接着用同一份判断。发现新的保护对象时，补上去就行。

实际试过的结果

开头那场支付代码事故之后，我在另一个已有仓库上试了同一套步骤。先一个编辑都不让它做，用上面的请求文只让它出表格，它果然把 billing/ 和 migrations/ 当成保护对象候选都列了出来。不过环境变量文件漏掉了，于是我自己把 .env 补了进去。这里以「由人来看」为前提推进，我再次觉得很重要。

第一个任务只收窄到修改文章末尾的一处文案，一路确认 npm run build 和 git diff --stat 才算完。diff 只有 7 行，支付代码一个字都没碰。检查用的代码我也实际跑了，确认把 protectedAreas 改空后会停在「先别交」。与其去找更聪明的 AI，不如先定好一个「摔了也能立刻爬起来」的小范围。这一点，在把别人的代码交出去的第一天最管用。

如果你已经到了想给公司已有代码定一套接入 Claude Code 的团队规范的阶段，可以来 培训与咨询，对着真实仓库一起把边界怎么划理清楚。官方的前置条件也建议过一遍 Anthropic Claude Code getting started，心里更有底。