Claude Code 是什么

它和「代码补全」差在哪

补全类工具处理的是光标附近：根据上下文猜你下一行想写什么。

Claude Code 处理的是一个任务：你描述要改什么，它在项目里自己找相关文件、 读、改、跑测试，出错再改。工作单位从「一行」变成「一次改动」。

这带来两个直接后果：

• 它能做的事更大（跨文件重构、补测试、修构建错误）；
• 它需要更多权限（读文件、写文件、执行命令），所以边界要你自己划。

一次典型的工作方式

1. 在项目目录里启动，它先看目录结构和关键文件。
2. 你说清目标（「给这个函数补单测，别改实现」）。
3. 它读相关代码、动手改、跑测试。
4. 你 review 差异，不对就继续说，对了就提交。

关键在第三步之后：它给的是 diff，不是结论。会用的人把时间花在 review 上， 不会用的人把时间花在返工上。

能做什么，不该让它做什么

适合	不适合
补测试、改命名、拆分文件	没写测试的核心逻辑大改
修 lint、修构建错误	生产数据库的迁移
读懂陌生项目、写说明	涉及密钥、支付、权限的代码
按清单批量改	需要产品判断的取舍

权限是设计的一部分

它可以执行 shell 命令，这意味着能干的事和能干坏的事是同一套能力。 稳妥的做法：

• 在独立的 git 分支上工作，改动随时可弃；
• 危险命令（删除、推送、部署）让它先问再做；
• 不把生产凭据放进它能读到的环境变量里。

常见误解

• 「它就是套了个壳的聊天」：差别在工具循环——它会自己读文件、跑命令、看结果再继续。
• 「用了就不用 review」：它写得快，但判断仍然要人来做，尤其是它没见过的业务规则。
• 「装上就能用」：要给它能跑起来的环境（依赖装好、测试能跑），否则它只能猜。

下一步

• 第一次上手：用 Claude Code 改第一处代码
• 它为什么能读文件：工具调用
• 怎么给它接外部工具：MCP