三个月前我第一次在终端里敲下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 - ORMSQLAlchemy 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 目录写操作逐个确认完全不给它执行任意命令的机会。我的建议是一开始别学我老老实实一个个允许跑半个月之后你自然知道哪些命令可以放心放开哪些必须每次确认。我现在的设置是读文件和运行测试全放开写操作保留确认删除操作永远拦截。简单列一下我建议的权限梯度给大家参考权限级别适用阶段操作范围风险控制全放权个人玩具项目、一次性脚本所有读写和命令依赖 git 回滚默认授权日常工作流读文件、跑测试自动允许写文件逐次确认盯着 diff越界立刻中断收紧扣链生产仓库、多人协作只允许访问指定目录危险命令全部拦截hooks 做关键闸门权限本身没有正确答案关键是你得清楚这一刻我让它做什么和它会顺手做什么之间的差距。把权限收到最密不等于最安全因为那会把你累死每个操作都弹窗。我的经验是找到一个它能干活、你睡得着觉的平衡点这个点因人而异但一定要在开始阶段用心去调。3.2 MCP 扩展的实际取舍哪些装了真有用哪些是折腾MCPModel 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 把这轮做了什么、改了哪些文件、还有什么没做、下一步建议写进去。下次会话直接让它先读这个文件再开始干活。这个习惯帮我省掉了至少一半的重复解释成本也是我强烈推荐给所有长期使用者的一个工作法。工具会越来越强但把规矩定好、把手感练出来永远是自己的本事。 
长河君 · 2026/10/18 22:21:27 · 阅读 1.2k Claude Code 三个月实战：命令行 AI 编程的高效工作流指南
三个月前我第一次在终端里敲下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 - ORMSQLAlchemy 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 目录写操作逐个确认完全不给它执行任意命令的机会。我的建议是一开始别学我老老实实一个个允许跑半个月之后你自然知道哪些命令可以放心放开哪些必须每次确认。我现在的设置是读文件和运行测试全放开写操作保留确认删除操作永远拦截。简单列一下我建议的权限梯度给大家参考权限级别适用阶段操作范围风险控制全放权个人玩具项目、一次性脚本所有读写和命令依赖 git 回滚默认授权日常工作流读文件、跑测试自动允许写文件逐次确认盯着 diff越界立刻中断收紧扣链生产仓库、多人协作只允许访问指定目录危险命令全部拦截hooks 做关键闸门权限本身没有正确答案关键是你得清楚这一刻我让它做什么和它会顺手做什么之间的差距。把权限收到最密不等于最安全因为那会把你累死每个操作都弹窗。我的经验是找到一个它能干活、你睡得着觉的平衡点这个点因人而异但一定要在开始阶段用心去调。3.2 MCP 扩展的实际取舍哪些装了真有用哪些是折腾MCPModel 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 把这轮做了什么、改了哪些文件、还有什么没做、下一步建议写进去。下次会话直接让它先读这个文件再开始干活。这个习惯帮我省掉了至少一半的重复解释成本也是我强烈推荐给所有长期使用者的一个工作法。工具会越来越强但把规矩定好、把手感练出来永远是自己的本事。