三个月前我第一次在终端里敲下claude这个命令时，根本没想到会被同一个工具折磨这么久，也从没想过它真能改变我的工作方式。如果你还不了解 Claude Code，一句话解释：它不是又一个能和你聊天的 AI 网页版，而是把 Claude 的能力直接塞进命令行的终端原生编程工具——你在项目目录里启动它，它就能读你的代码、改你的文件、执行你的命令，甚至帮你操作 git。这三个月我从"这玩意儿到底有什么用"，一路走到"离了它我不会写代码"，中间烧掉的 token 不少，踩过的坑也够写一篇长文了。

这篇东西不打算做成官方文档的复述，而是把我从菜鸟到相对明白的完整过程记录下来：前两周我犯过什么傻、CLAUDE.md 怎么成了我整个工作流的灵魂、权限和 hooks 应该如何配置、哪些任务适合交给它、哪些任务千万别碰，以及最后稳定下来的一套日常玩法。文章会比较长，适合所有正在用或者准备用 Claude Code 的人，尤其是那种安装完跑了个 demo 就吃灰、或者用了几次觉得"也就那样"的朋友。

1. 前两周的弯路：我一度把 Claude Code 当成会写代码的搜索引擎

1.1 第一次打开终端的真实冲击

第一次启动是跟着官方 README 来的，安装完之后在项目根目录敲claude，终端里弹出一个交互式界面。我当时最大的错觉是：这不就是带命令行的 ChatGPT 嘛。我完全照着网页版的使用习惯，先让它"解释一下这段代码干什么"，又让它"给我写个示例"，体验确实很好，回答速度快，代码质量高，还会主动贴出修改建议。

但真正开始干正事的时候，问题就来了。我让它给一个 Python 项目新增接口，它给出的代码本身没毛病，但漏掉了依赖声明和路由注册，我复制粘贴进项目之后直接跑不起来。当时我的第一反应是"这工具不太行啊"。现在回头想，根本不是它不行，是我不行——我还在用"问模型问题"的方式来驱动一个能直接操作代码库的 agent，而它要的驱动方式完全不是这样。它更像一个默认执行、默认动手的结对程序员，而不是一个默认解释的问答机器人。

这个认知差，导致我前两周一直在错误地使用它。最典型的循环是：提出需求、它生成代码、我手动复制、跑测试报错、再把报错贴回去、它改一版、我再复制……效率低到令人发指。有一次我让它给一个旧模块做小重构，它识别出了三处需要改的地方，写好了新的函数体，但我手动同步到本地文件时漏掉了一处，于是一切都乱了。后来我才意识到，Claude Code 的核心价值从来不是给你写一段代码，而是它能在你的真实环境里直接完成"读取、修改、运行、观察结果"这一个完整闭环。我把它当搜索引擎用，等于亲手砍掉了它最强的能力。

1.2 用聊天式提问跑真实任务，为什么总在关键时刻掉链子

前两周我还发现一个很反直觉的现象：聊得越久，它越容易"犯低级错误"。有一次我在终端里跟它讨论一个 Bug，来回七八轮，聊到后面它甚至忘了最初的问题背景，开始顺着我随口提的一个假设去解释。这种情况在网页版聊天里也有，但 Claude Code 的问题更严重，因为它有能力直接影响代码，一旦理解偏了，改出来的东西就是灾难。

后来我复盘当时的对话记录，发现自己一直在犯一个错误：我在"喂背景"而不是"给任务"。比如我会说"这个模块用了某种模式"，然后问"你觉得有没有问题"，但我没有明确告诉它"去检查这个模块并修复所有违规的地方，跑完测试再回报告"。前者是无边界的咨询，后者是有明确交付物的任务。Claude Code 在无边界的咨询场景下很容易发散，但在有明确目标的场景下，反而会表现出惊人的专注力。

这个发现彻底改变了我使用它的方式。我从"问它怎么写"转向"让它动手改"。第三周的时候，我抱着试试看的心态让它重构一个遗留的 user_utils 模块，我下的指令直接而具体：把超过 50 行的函数拆小，保持行为不变，跑完测试确认没有回归。它自己打开文件、生成 diff、修改代码、运行测试，第一次有一个用例挂了，它看了堆栈、自己把问题修正、然后补跑全部用例。我在旁边看着整个过程，最震撼的不是它写代码的质量，而是它读完测试输出之后知道要回头改代码，而不是把错误丢给我。从那一刻起我才真正明白，Claude Code 的正确打开方式是把任务说清楚，然后放手让它执行。

1.3 放手执行的前提是"看得见"，先学会盯它的每一步

不过"放手执行"并不是毫无保留地闭眼信任。我后来被坑过几次，于是养成了一套盯动作的习惯：在它开始动手之前，先让它把计划列出来；执行过程中紧盯终端输出，看到它要动我不希望它动的文件就立刻打断；每完成一个阶段，让它用git diff小结一下。你可以把它想象成第一次把车交给新手司机——你看着它开，握着副驾驶的手刹，但不要替它踩油门。

这里也分享一个指令上的技巧：我会在任务的最后固定加一句"每步操作前先说明目的，涉及文件修改先展示 diff"。这个约束会让它的行为透明很多，也方便你在它跑偏的时候及时喊停。前两周我就是因为太过"放养"，导致它改了不该改的文件我都没发现。所以从第一周开始积累"盯动作"的习惯，后面会省掉大量返工和修复的成本。

2. CLAUDE.md 才是灵魂：让工具越用越懂你的工程

2.1 项目说明文件如何改变上下文质量

真正让我从"会用"变成"玩明白"的，是 CLAUDE.md 这个被很多人忽略的配置文件。简单说，它就是放在项目根目录下、或者用户目录下的一个 Markdown 说明文件。Claude Code 每次在项目里启动时，会自动读取这个文件的内容作为上下文，相当于一见面就告诉它"我们这个项目的规矩是什么"。

没有这个文件的时候，你会发现同一个项目今天问它的和明天问它的，完全是两套理解。它的记忆只存在于当前会话，会话一清理就什么都不剩，每次新开会话它都像一个刚入职的实习生，什么都要重新教。而且更麻烦的是，没有项目文档约束时，它会凭借训练数据里的"通用最佳实践"来写代码，但这些通用实践不一定适配你的项目和团队约定。

我最初也没当回事，直到有一次在 CLAUDE.md 里写了三行说明：这个项目的前端是 React 18、不要动 migrations 目录下的历史文件、API 变更时需要同时更新 types。效果立竿见影，它给出的建议立刻变得"懂事"了，不会再提"把整个 migrations 目录重新生成一遍"这种让人血压升高的方案。我一直跟朋友说，写 CLAUDE.md 的投入产出比，比调任何 prompt 都高。你在这份文件上花的每一分钟，都会在后续每一次会话里得到回报，而且是复利回报。

2.2 一套适合多数工程的分层 CLAUDE.md 模板

我不建议一上来就写一个特别长的"大全"，那样反而会稀释重点。根据我的经验，一份实用的 CLAUDE.md 应该分四块：项目概览、技术栈与目录约定、常见任务流程、禁止事项。我的模板大概是下面这样：

# 项目说明 ## 项目概览 一句话说明这个项目是做什么的，服务谁，部署在什么环境。 ## 技术栈与目录约定 - 后端：Python 3.12 + FastAPI - 前端：TypeScript + React 18 - ORM：SQLAlchemy 2.0，禁止写裸 SQL - 业务代码放在 app/services，不要放 app/routers ## 常见任务流程 - 新增 API：先写 schema -> 再写 router -> 最后补测试 - 修 Bug：先写复现用例，再改代码，最后跑全量测试 - 数据库变更：新建迁移文件，禁止修改历史迁移 ## 禁止事项 - 不要动 migrations 目录下的历史文件 - 不要在 utils 里引入 domain 层逻辑 - 未经确认不要把第三方库升级到 major 版本

写完之后，你可以直接问它"我们项目的代码规范是什么"，确认它能准确复述出来。这个文件不是一次写完就不动了，我基本上每两周会更新一次，把新踩的坑和新的约定补进去。文件越贴近团队真实规则，它后续每一步产出就越正确。而且当你换机器或者拉新的分支时，这份文件会跟着项目走，等于团队的隐性知识被沉淀成了显性资产。

2.3 别把记忆寄托在对话里：文档即上下文

我踩过的一个比较深的坑是：同一个会话里聊得很好的约定，换一个新会话就全忘了。Claude Code 的上下文窗口虽然大，但每次新会话都是全新状态。早期我习惯在对话里补充很多背景信息，比如"记住，这个模块我们不用异常控制流程"，但它只对当前会话有效，过了两天再开新会话，又原形毕露。

所以我现在的原则是"一切重要约定必须落盘"，要么写进 CLAUDE.md，要么写在项目文档里。凡是值得让工具记住的事情，都值得让它能从文件里读到。与其靠提示词和会话维持记忆，不如把上下文做成项目自身的文档资产。这个方法实际用下来，你会明显感觉到它的"稳定性"高了很多——它不会因为换了会话就突然失忆，也不会因为聊天过程中的一个岔路口就跑偏。

我还养成了一个习惯：在每个较大任务开始前，先让 Claude Code 读一遍项目里相关的设计文档和 README，再让它总结这个任务需要遵循哪些约束。这个小动作相当于给它的上下文"锚定"在正确位置，比直接丢任务要可靠得多。如果你手头有项目文档但没喂给它，那等于一个非常有经验的工程师被蒙着眼做事，发挥不出来是必然的。

3. 权限、MCP、Hooks：放开手脚之前先想清楚这三件事

3.1 权限模型：我为什么先全放权，又一步步收紧

Claude Code 的核心能力是操作真实环境，所以权限配置注定是一个绕不开的话题。用它的第一周我图省事，在启动时加了跳过权限确认的参数，也确实爽了几天——所有操作一路绿灯，改文件、跑命令都不需要我点头。但后来发现不行。最惊险的一次是它在帮我改完代码之后，顺手对一组文件做了格式化，我都没看清改了哪些文件，就把一个配置文件的缩进全改了。虽然git diff能查，但还是让我出了一身冷汗。

这个工具的好处是它的权限模型其实很细。默认情况下，涉及文件写入、执行命令、网络请求等操作时会弹确认，你可以选择允许一次、允许整个会话，或者拒绝。我见过有开发者用非交互模式配合一份允许清单跑自动化任务，比如只允许它读 src 和 tests 目录，写操作逐个确认，完全不给它执行任意命令的机会。我的建议是一开始别学我，老老实实一个个允许，跑半个月之后你自然知道哪些命令可以放心放开，哪些必须每次确认。我现在的设置是：读文件和运行测试全放开，写操作保留确认，删除操作永远拦截。

简单列一下我建议的权限梯度，给大家参考：

权限本身没有正确答案，关键是你得清楚"这一刻我让它做什么"和"它会顺手做什么"之间的差距。把权限收到最密不等于最安全，因为那会把你累死，每个操作都弹窗。我的经验是找到一个"它能干活、你睡得着觉"的平衡点，这个点因人而异，但一定要在开始阶段用心去调。

3.2 MCP 扩展的实际取舍：哪些装了真有用，哪些是折腾

MCP（Model Context Protocol）可以理解成给 Claude Code 配了一套"外接插件接口"，让它能连接各种各样的外部系统。这两个月我陆续试过不少 MCP 服务器，包括数据库访问、浏览器操作、文件系统增强、时间管理这些。说点大实话：有些确实香，有些纯属折腾。

对我个人最有用的有三个：一个是数据库只读查询的 MCP，让它能直接看库里的真实数据而不是靠代码猜，排查数据类 Bug 的效率翻倍；一个是浏览器调试的 MCP，适合前端场景自动打开页面做基础验证；还有一个是任务看板类的 MCP，能把多步骤任务落成一个可勾选的清单，方便我随时中断和恢复。至于那些需要在本地起一大堆服务的 MCP，我基本都卸载了——因为它们引入的不稳定性和配置成本，远大于它们带来的那点效率提升。

判断一个 MCP 值不值得装，我只有一个标准：它能不能减少你人工介入的次数，而不是增加你的部署负担。装完如果三天用不上一次，那它就是噪音。另外提醒一句，MCP 服务器本质上也是在你的机器上执行一些操作，装第三方服务器之前建议先读一下它的源码或者至少确认它的来源可信，别什么都往里接。

3.3 Hooks 把关键动作变成确定性逻辑

Hooks 是我后面才玩明白的功能。它可以让你在特定事件发生时触发自定义脚本，相当于给 Claude Code 装上了一些"红绿灯"和"围栏"。比如我可以配置它在执行某些工具之前先跑一个密钥扫描脚本，防止它不小心把 token 提交到代码里；也可以在它每次编辑文件之后自动跑一次 linter，尽早发现问题。

我自己的配置里，最有价值的一条 hooks 是在 bash 命令执行前检查是否包含危险命令，比如"下载外部脚本并直接执行"这类操作，一旦命中就直接拦截。这样它想跑什么非常规命令都逃不过我的眼睛。配置方式不复杂，大概是在项目的.claude/settings.json里声明一个 hook，核心逻辑类似：

{ "hooks": [ { "matcher": "PreToolUse", "hooks": [ { "type": "command", "command": "python scripts/guard.py --tool bash --input {input}" } ] } ] }

脚本里的判断逻辑完全由你自己定义，比如检测命令里是否包含curl | sh、是否有删除某个目录的危险模式等等。说句实话，如果你用了 Claude Code 但没配 hooks，那你的使用姿势基本还停留在"裸奔"状态。用好了 hooks，你才能做到"给它空间，但关键闸门自己控制"。

4. 三个月实测：哪些活它干得漂亮，哪些活千万别交给它

4.1 高光时刻：批量重构、跨文件追踪、测试补齐

用到现在，我认为它真正高效的是三类任务。第一类是批量重构。比如把一段重复出现 20 次的逻辑抽成公共函数，把整个模块从旧接口迁移到新接口，这种跨文件、模式化的活它干得非常快，人肉来改可能要一整天，它十分钟就能把 diff 摊在你面前。而且因为它在动手前会自己先读一遍所有相关文件，所以遗漏率比人肉搜索要低很多。

第二类是跨文件追踪。你跟它说"找到从订单创建到支付回调的完整链路"，它能一路读过去，把涉及的函数、表、消息队列全部串起来，给你画出一份完整的链路说明。我以前自己去理这种调用链，少说半天，它还经常会漏掉一些间接调用。第三类是测试补齐。让它给一个现有模块补测试，它生成的用例覆盖路径相当广，边界值、异常场景都会主动补上，比自己手写省太多事。这三类任务的共同特点是：边界明确，改什么、涉及哪些文件、期望什么结果全都说得清楚。在一个封闭问题上，它的执行力和耐力是完胜人类的。

4.2 一般般：从零搭项目、理解陌生代码库、改遗留代码

也有些场景它表现一般，不是不能用，而是你得把期望调低。比如从零搭建一个新项目，它能帮你把目录、框架、配置文件一次性铺出来，但选型、取舍这些还得你亲自来，它给的默认方案往往保守中庸，缺少个性。再比如理解一个完全陌生的代码库，它能给出整体架构梳理，但涉及"这个业务为什么这么设计"，它只能靠猜，经常把设计意图和技术债混为一谈。

改遗留代码也是一样。有一次我让它动一个多年前的老模块，它按照现代最佳实践重构了，测试全绿，但资深的同事看了一眼直接说不行——因为那块代码当年就是为了绕过某个老框架的 Bug 才写成那样的。这种只存在于老同事脑子里的隐性知识，它永远学不会。所以在这些场景里，我现在的做法是让 Claude Code 做辅助而不是主力：让它出方案、出草稿、做数据分析，但最终拍板和关键的老代码修改，一定要人肉兜底。怎么兜底？让它先出方案，你审查方案，再让它执行你批准的那一版，而不是让它自己自由发挥。

4.3 大坑：最后 10% 的收尾和语义含糊的改动需求

用这三个月，我最深的体会就是它的"倒数第二个版本陷阱"。什么意思呢？就是它做一件事能做到 90%，剩下的 10%——边界情况、异常处理、兼容性细节——往往是它最纠结的部分。它自己知道没完成，但又不知道还缺什么，于是会反复尝试，消耗大量 token，最后还可能会把一个原本稳定的版本改坏。遇到这种情况我现在会果断喊停，让它先提交当前版本，剩下的 10% 我自己上手补。

还有一个大坑是需求本身语义含糊的时候，别指望它帮你"脑补全"。比如你说"把用户列表页优化一下"，它真的不知道你想优化什么。优化性能、优化布局、优化交互是三个完全不同的方向，它只能随机挑一个。我现在学到的习惯是：需求描述里必须带验收标准。你给它"当用户数超过 1000 时，列表首屏渲染时间要降到 500ms 以内"这种话，它的执行力会完全不一样。简单来说，你对它越像对一位"认真但缺乏行业常识的新同事"，你的使用体验就会越好。

5. 性能与成本：怎么让上下文更短、让模型更聚焦

5.1 上下文管理是第一生产力

上下文是 Claude Code 最重要的资源，也是最容易被新手浪费的资源。我刚用的时候喜欢让它"读一下整个项目"，它确实读了，但代价是上下文窗口被大量占满，之后正经的修改任务分到的注意力就少了，答案质量明显下降。后来我学乖了，把它当人一样对待：只告诉它需要看的目录和文件，而不是整个仓库。

有一个很实用的技巧：在任务描述里限定范围，比如"只读 app/services/order.py 和 tests/test_order.py，分析订单状态流转的 Bug"。这样它的上下文就只聚焦在这两个文件上，检索噪音小，产出质量高。我还习惯在项目里维护一个"边界说明"，直接在 CLAUDE.md 里写清楚哪些目录是它默认可以看的，哪些目录不要碰，这相当于从源头控制上下文污染。上下文管理做得好不好，直接决定了同样的任务是一次到位还是要来回拉扯三次——后者不仅费钱，更费你的耐心。

5.2 任务拆解：一次只做一件事

如果你把一个复杂的宏任务直接丢给它，比如"帮我加一个支付功能"，它可能会列出很多步骤然后开始尝试。但说实话，这种大任务的执行成功率并不高，因为它需要边探索边决策，而每一步探索都会消耗 token、引入不确定性。我的习惯是把大任务拆成一个一个子任务，每次对话只做一件事，做完验证完，再给它下一件事。

比如"加支付功能"这个需求，我会拆成：先画数据模型，再写支付接口，再接入回调，再补测试。每个子任务单独开会话，每个会话结束前让它把变更和下一步计划写在项目文档里。这样做的劣势是对话次数变多了，优势是每一步都稳定可控，不用整个任务推翻重来。用三个月之后，我可以负责任地说：拆得越细，它在单步上的表现越惊艳，整体成功率也越高。

5.3 早晚会碰到的卡壳场景与应对

再稳定的工具也有一堆怪癖，我列几个真实的卡壳场景和我的应对。第一个是它改一个文件改着改着把上下文搞得很长，这时候不要硬撑着继续，直接用上下文压缩功能，把历史记录压缩后再继续，往往能救回来。第二个是它在一个错误方向上反复试探，比如认为某个 Bug 是缓存问题，但实际上根本不是。这时候你得果断打断它，告诉它"停，先别查缓存，往数据库连接方向查"，不要让它一条道走到黑——它有时候真的会在一棵树上吊死。

第三个是它会跑一些你根本没有要求的命令，比如突然装个包或者格式化某段代码。如果你的权限控制比较松，建议随时盯着它，发现越界立刻中断，然后用版本控制把不该动的文件还原。第四个卡壳场景是它容易在"自己不确定"的时候向你要确认，但如果你的上下文已经很乱了，它的确认也经常是错的。遇到这种情况，最快的解决方案是开一个新会话，把必要背景和任务重写一遍。

还有一个成本上的建议：不要让它做完一步就等一步，更不要频繁开新会话重复描述同一个需求。你在新会话里重新描述的那一大段，每次都是要花钱的。把需求的描述沉淀到项目文档里，既省钱，又能保证每次开工它都快速进入状态。我见过有人把同一个需求聊了十几次，每次都是全新的上下文，那个 token 消耗看着都心疼。

结尾

这三个月的实践，最让我笃定的一个道理是：Claude Code 本质上不是一个生成代码的工具，而是一个"可以放手让它干活的同事"。你和它的关系质量，取决于你怎么告诉它规矩、怎么给它划边界、怎么把大任务拆成小任务。配置上最值钱的是 CLAUDE.md，安全上最关键的是 hooks，效率上最核心的是上下文管理，这三样玩明白，基本就超过 90% 的人。

最后再分享一个小技巧：我会在项目里单独维护一份agent-handoff.md文档，每次一个较大的任务做完，我会让 Claude Code 把"这轮做了什么、改了哪些文件、还有什么没做、下一步建议"写进去。下次会话直接让它先读这个文件再开始干活。这个习惯帮我省掉了至少一半的重复解释成本，也是我强烈推荐给所有长期使用者的一个工作法。工具会越来越强，但把规矩定好、把手感练出来，永远是自己的本事。