如何用 Claude Code 修改别人写的代码库

你刚接手一个代码库。没有文档，没有测试，原作者已经走了，线上还有个 bug。

这正是 Claude Code 最有价值的场景之一。这篇文章讲的是一套很实用的三段式流程：先审计，再谨慎改动，最后做验证闭环。

你需要准备什么

• 已安装并登录 Claude Code（claude --version）
• 仓库的 Git 权限
• 第一次大约 30 分钟，熟练之后会快很多

第一阶段：先把代码库审一遍

在你动任何一行代码之前，先建立一张“地图”。先让 Claude Code 帮你把仓库讲明白。

claude "Give me a plain-English tour of this repo. What is the entry point, what are the main layers, and where does data flow from the user to the database?"

Claude Code 会去读目录结构、关键文件和主要调用链，然后给你一个结构化总结。把它留存下来。

接下来，把明显的风险点先挖出来：

claude "List every place where user input touches the database without obvious sanitisation. Show file name and line number."

然后再对认证边界、第三方 API 调用、TODO、FIXME 这些位置做同样的排查。这样你手里就会有一份优先级清单。

小建议：把审计输出直接存成一个 Markdown 文件，比如 claude "audit this repo" > audit.md。后面回头看会非常有用。

第二阶段：用最安全的方式改

这一阶段的目标不是“快点改完”，而是“改得容易审、容易回滚”。Claude Code 的价值不在于帮你盲改，而在于它能在读上下文之后给出更像样的最小修复。

2.1 先开一个分支

git checkout -b fix/inherited-bug

在一个你还没真正摸清的仓库里，不要直接在 main 上动。

2.2 描述 bug，不要直接指挥实现

这是最重要的一条。不要这样说：

# ❌ 不建议
claude "change line 47 in auth.js to use bcrypt instead of md5"

更好的方式是这样：

# ✅ 更稳
claude "Users can log in with any password after a failed attempt. Find the root cause and propose a minimal fix."

你描述的是“症状”，不是“拍脑袋的修法”。这样 Claude Code 才会去读周边逻辑、发现你可能忽略的关联问题，并给出更贴近现有代码风格的修复方案。

2.3 应用前先把 diff 看一遍

Claude Code 会先提出变更方案。先读 diff，每一行都看。

如果方向是对的，但细节不对，就直接用自然语言压回去：

claude "That fix looks right but it changes the error message format. Keep the original error messages."

你确认没问题之后，再应用：

claude --apply

第三阶段：一定要做验证闭环

一个“修了当前 bug，但顺手又弄坏别的地方”的改动，不算修复。这里一定要把测试和复查补上。

3.1 先让 Claude Code 写测试

claude "Write a test for the auth bug we just fixed. It should fail on the original code and pass on the patched code."

如果仓库里原本没有测试框架，Claude Code 通常会建议你补一个最小可用配置。这个时候可以让它搭，不要怕。

3.2 跑完整测试

npm test  # 或者项目实际使用的测试命令

如果测试挂了，把错误信息原样贴回 Claude Code：

claude "The tests are failing with this error: [paste error]. What went wrong?"

这就是完整闭环：修复 -> 测试 -> 诊断 -> 再修。大部分 bug 都会在两三轮内收住。

3.3 提 PR 之前再做一次最终复查

claude "Review the diff in this branch and flag anything that looks unintentional or risky."

它很适合抓这种小尾巴：忘删的 console.log、误保留的密钥、修完后已经没人在用的函数。

常见坑

坑	为什么会发生	更好的做法
Claude 改错文件	你的描述太模糊	直接点名文件或模块
本地修好了，CI 挂了	环境假设不一致	让 Claude 一起检查环境依赖
审计漏掉隐藏入口	项目结构不标准	提前告诉 Claude 任何非标准约定

最后总结

这套模式其实很简单：先审计，再安全改动，最后验证。

Claude Code 在这里的价值，不是“魔法修 bug”，而是它能在更大的代码上下文里配合你做调查和收敛。你越先把代码库看明白，后面的修复就越稳。

先从审计开始。后面的大部分动作，都会顺着这个步骤自然展开。