我把日常工作流搬进了 Claude Code

事情是这样的。

前阵子有个周三晚上，我对着 ChatGPT 网页版，开了第七个标签页。左边粘一段代码，右边贴一个报错，中间还得切回编辑器复制文件路径。切来切去切到我自己都懵了，我寻思了一下我没寻思明白，我在干嘛呢？？？

那一刻我真的觉得，这种用法不对劲。

我不是大厂资深工程师，写代码算不上多溜，但日常要折腾的东西不少。课程系统的脚本、部署的小修小补、偶尔改个前端样式。这些活儿碎片、零散，还经常得跨好几个文件。网页版那个聊天框模式，你一句我一句，聊着聊着上下文就乱了，它也不知道我项目长啥样。

直到我把 Claude Code 装上，在终端里敲下第一行命令，我才有一种，哦，对，就该是这样的感觉。

从网页版跳到命令行

说真的，一开始我是抗拒命令行的。

网页版多舒服啊，点点鼠标就能用。命令行听着就劝退，黑乎乎一个窗口，还得记命令。我不是那种 terminal 一开就兴奋的人，相反，我之前觉得能不碰就不碰。

但网页版有个致命问题，它不知道你的项目。

你问它「帮我看看这个报错」，它让你把报错贴过来。你问它「这个文件里那个函数怎么改」，它让你把函数贴过来。每问一句，就得手动搬运一次。就像你请了个顾问，能力很强，但他每次来你公司都得你重新给他介绍一遍「这是哪个部门、用的什么技术栈、代码放哪」。

Claude Code 不一样，它直接长在你的项目目录里。

我敲一句话，它自己去看文件、自己去找报错在哪、自己改完还问我要不要提交。第一次跑通的时候我愣了一下，这种感觉太爽了，像是从「我跟 AI 翻译我的项目」变成了「AI 直接住进了我的项目」。

这个区别，用过就回不去了。

三个我天天在用的场景

迁过来之后，慢慢就形成了几个固定用法。

第一个，读陌生代码库。

我接手过一个不是自己写的项目，几千行代码，光配置文件就好几个。以前这种情况，我得一个个文件打开，从头读，读着读着就困了。现在我就跟 Claude Code 说，帮我过一遍这个项目，讲讲主要模块干啥的，入口在哪，数据怎么流的。

它真的会去翻，翻完给我一份不算完美但够用的地图。哪几块是核心逻辑，哪几块是历史遗留，它甚至能指出「这块写法有点绕，可能是后来补的」。当然它也会猜错，你得自己判断，但比起你一个人在代码海里捞针，效率高太多了。

第二个，批量重构。

这个是我觉得最值的地方。有次我要把项目里所有图片路径重写一遍，因为目录结构调整过，几十篇文章的图片全 404 了。手动改？几十个文件一个个开，想想就想死。

我跟它说了下规则，旧路径长啥样、新路径长啥样、哪些文件要改。它列了个清单，一个一个改，改完还自己跑了一遍校验。我盯着看它干活，那种感觉，怎么说呢，像看着一个不用催的实习生。

不过我得提醒一句，批量改动一定让它先跑一遍给你看，别一上来就让它直接写。我后面踩过这个坑。

第三个，写一次性脚本。

这种活儿特别多。今天想把一堆 markdown 里的标题提取出来做个目录，明天想批量重命名一堆文件，后天想算一下某几个文件的字数。以前我得现学命令行或者写 Python，搜半天语法。现在就一句话的事，它写完我跑一下，跑完脚本就扔了。

一次性脚本这个东西，精髓就在于你不需要维护它，用完即弃。让 AI 写这种脚本，简直是绝配，因为你根本不在乎代码写得优不优雅，能跑就行。

折腾配置的那些坑

用顺了之后我就开始作，想让它更懂我。然后就掉坑里了。

先是 CLAUDE.md。这个文件相当于给 Claude Code 留一张纸条，告诉它这个项目的规矩。我一开始写得特别长，恨不得把所有规范都塞进去，什么命名规则、提交格式、代码风格。结果发现，写太多它反而抓不住重点，该犯的错还是犯。

后来我悟了，这玩意儿要写得短，写最关键的几条。比如「这个项目用 TypeScript」「提交信息用中文」「别动 src/legacy 目录」。几句话，比一页纸管用。就像你给新同事留交接文档，写三页没人看，写三条贴显示器上，人人都记住了。

然后是自定义 slash 命令。这个功能我刚发现的时候特别兴奋，觉得自己能造工具了。我写了个命令，一键帮我生成文章 frontmatter。折腾了半天，路径写错、参数没对上，搞了两个小时才跑通。跑通那一刻确实爽，但回头想想，两个小时造一个省两分钟的轮子，值不值？

我觉得对于高频操作，值。对于一年用三次的，别折腾，直接打字更快。这个判断很重要，很多人一上来什么都想自动化，最后配置的时间比干活还长，本末倒置了。

最折腾的是接 MCP。MCP 简单说就是让 Claude Code 能连外部服务，比如读你的文档库、查数据库。听着美好，接起来一头包。版本对不上、权限没配、连上了结果超时。我当时对着一个报错卡了一整个晚上，最后发现是网络代理的锅。

说真的，MCP 这种东西，新手别碰。等你把基础用法全跑顺了，真的遇到「我需要让它读我某个系统里的数据」这种刚需了，再去搞。不然纯粹是给自己找罪受。

有些活儿别甩给它

聊了这么多好处，我得说点泼冷水的。

不是所有事都该交给它。我踩过最大的坑，是让它做它不擅长的事，然后还怪它不行。

比如，那种需要你对业务理解特别深的判断。这个功能到底该不该加、这个交互逻辑符不符合用户习惯、这段代码要不要现在就重构。这些事情，AI 给你的答案永远是基于「一般情况」，但你的项目不是一般情况，是你一个个具体决策堆出来的。你把这种决策甩给它，它给你一个看似合理的方案，你照着做，做着做着发现不对味。

还比如，那种改一行就可能炸全局的核心逻辑。我让它改过一个跟钱相关的计算模块，改完它信誓旦旦说没问题，我多留了个心眼手动验了一遍，还真算错了。。。不是大错，但那种地方，小错也是大事故。

我的原则是，越靠近业务核心、越不可逆的操作，越要自己来。Claude Code 适合干那些重复的、机械的、错了也无所谓的活儿。把脏活累活甩给它，把需要判断的活儿留给自己。这不是偷懒，这是分工。

而且你得有能力看懂它写的代码。如果你完全不懂，它写啥你用啥，那就不是在用工具，是在赌博。它给你的代码，你至少得能读懂、能验对错。这个底线不能让。

给新手的三条实在话

最后给想上手的朋友几条建议，都是我自己蹚出来的，不一定全对，但至少是真金白银换的教训。

第一，先别碰配置，直接用。装上就开聊，先让它帮你读代码、写脚本、改 bug。等你用了两周，真的觉得「要是我能让它默认这样做就好了」，这时候再去写 CLAUDE.md，去搞 slash 命令。需求驱动配置，不是反过来。我自己一开始就是倒过来的，先配置一堆，结果一半没用上。

第二，永远 review 它的输出。它不是不会错，是错了还很自信。尤其是批量操作，一定让它先 dry run，给你看清单，你确认了再真改。我现在的习惯是，但凡涉及多文件改动，先看 diff 再决定。多花三十秒，省下三个小时的回滚。

第三，把边界划清楚。哪些目录它可以动，哪些不能碰，哪些决策它给建议你来拍。这个边界不是一开始就能定好的，是你用着用着，踩了几次坑之后慢慢磨出来的。我的 CLAUDE.md 改了不下十遍，每一遍都是被一个坑教育的结果。

说到底，Claude Code 不是万能的，但它是真的好用了。

它没有把我变成大神，我还是那个写代码一般般、靠折腾过日子的人。但它把我从那些无聊的重复劳动里捞出来了，让我能把精力花在真正需要我想事情的地方。对我来说，这就够了。

工具这东西，终归是放大器。你脑子里有东西，它帮你放大，你脑子里没有，它放大的是空气。所以与其花时间研究一百个 Prompt 技巧，不如先想清楚，你自己到底要干什么。

想清楚了，再打开终端。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。

/ 作者，词元Max