前一阵子给自己定了个小目标：把 Claude Code 从零完整学一遍，边学边记，最后整理成这份 S01 学习记录。Claude Code 说白了就是一个跑在终端里的 AI 编程助手，它能在命令行里读你的项目代码、改文件、跑命令，甚至代替你完成一整条开发流水线。今天这篇就讲讲我从零开始学它的全过程，包括安装、配置、实战和踩坑。全文没有云里雾里的理论，全是终端里敲出来的真实记录，适合想入坑的开发者、技术负责人，以及所有好奇“命令行里的人工智能到底能干多少活”的人。1. 为什么突然决定把 Claude Code 学会1.1 厌倦了在 IDE 和浏览器之间反复横跳过去写代码，我的日常是：在编辑器里改代码，切到浏览器找文档，再切回来粘贴、调试、跑测试。遇到跨文件重命名或者全局替换，还要小心翼翼地确认作用范围。这种工作方式不能说不能用，但确实非常消耗注意力，尤其当你在做一个有一百多个文件的旧项目时，光花在“找到要改的位置”上的时间，就比真正动手改的时间还多。Claude Code 这个工具吸引我的核心点，就是它把“找代码、改代码、验证代码”这三个动作统一到了同一个对话入口里。我不需要先手动定位到某个模块，再思考怎么改，而是直接把需求用自然语言扔给它。它会自己翻项目结构、读文件、定位相关代码，然后给出修改方案。这种交互方式，本质上把“编程”从“敲击键盘的体力活”变成了“描述意图并验收结果的脑力活”。1.2 它和传统 AI 自动补全完全不是一回事很多人一听到 AI 编程，第一反应是编辑器里的代码补全插件，也就是写到一个函数名时自动补全下一行。但 Claude Code 的工作方式完全不同：它更像一个“能自己动手干活的外包工程师”，而不是一个“只会接话的输入法”。举个例子，同样是“给登录接口加一个验证码”这个需求。传统补全工具能帮你写一段生成验证码图的代码片段，但不会主动去改路由、加依赖、更新测试用例。而 Claude Code 的理解是原子的：它会先看接口文件，弄清现有鉴权逻辑，再决定验证码存哪里、过期时间设多少，甚至会把文档和测试一起更新。这种“从目标出发反推步骤”的能力，才是它真正值钱的地方。在 S01 这期学习里，我的目标也很简单：不追求会用那些高阶技巧，先把“安装、初始化、权限控制、跑通一个完整小任务”整明白，能稳定地用它处理日常项目里的琐碎工作。2. 动手前先把底层的运行逻辑摸清楚2.1 所谓“对话即操作”到底是怎么实现的我第一次用 Claude Code 之前，一直有一个疑问：它本质上是一个跑在终端里的进程，凭什么能修改我磁盘上的文件、执行我 shell 里的命令？后来捋清楚了：Claude Code 的核心是一个“工具调用循环”。你输入一段自然语言，它内部会把这段话拆解成意图，然后循环执行一系列工具操作。这些操作包括读文件、写文件、列目录、执行终端命令，每执行一步，它都会观察结果，再决定下一步行动。这就像一个新手程序员在跟你协作：你说“把这个接口的返回结果里加上创建时间”，它先grep找到接口位置，再读文件确认数据结构，然后改代码，最后跑一遍测试给你看。你不需要在终端里敲那些底层命令，它代替你做了，但每一步又都在你的监控之下。理解这一点很重要，因为这意味着：它的能力上限不只取决于模型本身，还取决于你给它的环境是否清晰。如果一个项目目录下塞满了构建产物、临时文件、node_modules，它很容易被无关信息干扰，从而在错误的方向上反复试探。我第一次实战时就是吃了这个亏，后面会详细讲。2.2 权限边界和安全模型的取舍既然它能执行终端命令，那安全问题怎么解决？这是每个初次接触的人都会问的，也是我一开始最警惕的。实际上 Claude Code 默认采用“请求许可”机制：它想执行一条 shell 命令前，会把命令原样展示给你，等你按确认键才会执行。读文件和普通编辑操作通常在授权范围内，而像删除大量文件、推送远端、修改权限这类高风险操作，会有更显眼的警告和二次确认。这个设计其实很像“给外包工程师一个只读账号，他要改东西之前先提交申请”。好处是安全可控，坏处是非常啰嗦——一个稍微复杂的任务可能要弹十几次确认。后面我会介绍怎么通过配置文件把低风险操作做成自动放行，但这里想先说一句：不要为了省事把所有权限全部放开，尤其是项目刚开始还不熟悉的时候。权限弹窗本质上是你和 AI 之间的“核对点”，省掉它们，就相当于把方向盘全部交给了一个还在实习期的司机。我还建议你养成一个习惯：每次让 AI 执行重要操作前，先让它用git status和git diff把当前改动展示出来。这样就算它改错了，你也知道回滚点在哪里。3. 安装与初始配置全记录3.1 环境准备：没有想象中复杂，但值得列个清单Claude Code 的运行环境依赖并不多，但基础版本最好提前确认。我自己的环境是 macOS + Node.js 长期支持版 + Git，其他终端环境基本也能跑，Linux 和 Windows 用户用 WSL 也是官方推荐的路径。这里给一个检查清单：Node.js 版本是否满足官方要求，最好在终端执行node -v看一下，版本太老会遇到奇怪的兼容问题Git 是否已安装并完成全局配置，很多项目操作会依赖 Git 状态判断是否安装了常用的构建工具链，比如你的项目是 Python 就要有 Python 环境，是前端项目就要有包管理器终端是否为 UTF-8 编码，避免中文路径或中文内容乱码我一开始没仔细检查 Node.js 版本，结果启动之后报了一个模块加载错误。当时第一反应是工具坏了，折腾了半天才发现是本地环境太旧。所以建议所有刚开始接触的人，先花三分钟把这些基础项确认好，不要直接跳到安装那一步。3.2 安装、登录和第一次启动安装过程非常简单，本质上就是把官方发布的 CLI 模块通过包管理器全局装到系统里。官方提供了全局安装命令，我这边因为环境不同，就不贴具体包名了，你在官方文档里直接复制对应命令执行就行。装完以后在终端输入claude --version，能看到版本号就说明安装成功。接下来是认证环节。启动后会自动打开浏览器让你完成账号授权，授权成功后会生成一个本地凭据，之后就不需要反复登录了。如果你是团队协作环境，也可以使用 API 密钥的方式配置，但为了安全，我建议个人学习阶段用默认的账号授权就好，少走弯路。首次启动时，Claude Code 会在你当前目录下创建一个会话。它默认是“跟随当前项目上下文”，也就是说你在哪个目录里启动，它就会以哪个目录作为工作根目录。所以请务必在想要让 AI 操作的代码项目根目录下启动它，而不是在/root或者用户主目录里启动，那样它会扫到一堆无关文件，既费 token，也容易产生错误判断。初始化完成之后，我做的第一件事是查看内置帮助菜单。Claude Code 内置了很多斜杠命令，比如帮助、清空会话、状态查看、成本统计等，每个版本会有细微差异。不要小看这一步，很多功能藏在这些看似不起眼的命令里。4. 第一次实战：在模拟项目 X 里跑通完整流程4.1 项目背景与任务拆解为了不拿真实项目冒险，我建了一个模拟项目 X，是一个用 Python 写的命令行小工具，功能是管理本地任务清单。项目结构很典型：有存储数据的模块、命令行入口、还有一小组单元测试。我给它提的需求是：新增一个“提醒日期”字段，并在查看任务列表时按提醒日期排序。这个需求看起来简单，但实际涉及数据存储格式变更、命令行参数的解析、排序逻辑的调整和测试用例更新，对一个不熟悉项目细节的人来说，至少需要十几分钟。我想验证的核心问题，就是 Claude Code 能不能在无人引导的情况下，靠自己的代码阅读能力把整个链路理清楚。在开始敲第一句话之前，我按照前面学到的经验，先手动看了一遍项目里的 README 和主入口文件，然后在会话里给它圈定了范围：“这是一个本地任务清单工具，我要增加提醒日期字段，涉及存储和命令行展示。请先阅读相关代码，再给我一个修改计划。”这里没有直接命令它“开始改”，而是先要求它输出计划，这一步帮了大忙。4.2 实操过程实录：从计划到改代码再到踩坑Claude Code 的第一轮回复给了三段式计划：修改存储结构、调整命令行解析、更新测试。它列出了要改的三个具体文件，并且每条都带了解释。我确认之后，它开始自动读取这些文件，逐段修改。整个过程里，我只需要看着终端里的进度，偶尔确认执行权限。第一次修改完成后，我让它运行项目的测试套件。结果失败了，原因是某个测试数据还停留在旧结构。这个错误很典型，恰恰是因为它修改了存储层但没同步修正测试夹具。我当时的处理不是直接指出具体位置，而是对 Claude Code 说：“测试失败了，请查看失败信息并修复所有相关代码。”它立刻定位到了测试文件，把旧结构的数据更新成了新格式，再次运行后全部通过。就在我以为已经完成的时候，它主动提示我：命令行入口里有一处打印逻辑还没适配新字段，虽然不影响测试，但会导致实际使用时的输出格式不完整。这个小细节让我比较意外，说明它确实领会到了整个功能链路的完整性，而不仅仅是满足测试绿变。随后它把那一处也修掉了，我确认 diff 之后才算收尾。这次实战给我最直接的感受是：把任务拆成“先计划、再实施、后验证”三个阶段，AI 的完成质量比直接让它一口气改完要高一截。因为它在计划阶段就会把相关文件扫一遍，后面改动时所有的判断都基于更完整的上下文，而不是边猜边改。4.3 权限确认环节的亲身教训过程中有一次它提出想删除一个临时数据文件，理由是旧格式的缓存不再需要。我从权限弹窗里看到这条rm命令，第一反应是拒绝。原因不是它判断得不对，而是我一直认为“删除数据”这类操作应该有更强的确认门槛。拒绝之后，我选择让它在项目里新开一个迁移目录，保留旧文件，只调整读取逻辑。这样虽然多了一步，但万一新代码有问题，旧数据依然能兜底。这件事情给我留下的印象很深：Claude Code 的执行能力越强，你对“哪些操作可以放权”的思考就得越认真，尤其是涉及删除、覆盖和推送这类不可逆动作时，宁可保守一点。5. 常用命令与工作流技巧5.1 这几个高频操作，建议第一天就记住Claude Code 的功能很多，但平时用得最勤的其实就那么几个。我把高频操作整理成了下面这张表，不同版本可能会有细微差别，但大方向是一致的：操作作用我的使用场景直接输入自然语言让 AI 理解并执行任务几乎所有操作的第一步斜杠清屏命令开启一个干净的会话窗口，清掉旧上下文任务切换时必用，避免前一个任务的上下文干扰斜杠压缩命令自动总结整段对话并压缩上下文对话太长、AI 开始“失忆”时使用斜杠成本命令查看本次会话的 token 消耗写完一个任务后随手看一眼，心里有数斜杠初始化命令在项目根目录生成或更新项目说明文件新项目第一次接入时执行文件引用前缀在输入中加入指定文件路径，强制 AI 优先参考想让 AI 关注某个关键文件时使用叹号前缀直接执行 shell 命令而不经过 AI 理解快速跑测试、查看状态时使用这里特别想强调文件引用前缀。如果你发现 AI 在理解需求时总是跑偏，最有效的办法就是在问题里直接塞上相关文件的路径，它读文件的顺序会因此发生明显变化。这就好比给外包工程师画了一个圈：“你不用满屋子找，就在这张桌子上干活。”5.2 把工作流编排出来的四个习惯第一，先立项目说明文件再开工。Claude Code 会读取项目根目录里的 CLAUDE.md 作为长期记忆，很多同学不知道这个文件的存在，结果每次对话都要重新交代项目背景。我在模拟项目 X 里特意写清楚项目结构、测试命令和代码风格约定之后，AI 后续的行为明显“稳重”了很多。第二，任务切换前务必清空会话。有一次我让它改完 A 功能后，直接接着问 B 功能的实现，结果它把 A 功能的旧思路带到了 B 的实现里，改出来的代码风格非常拧巴。从那以后，每切换一个任务，我都会先清空会话再重新描述目标。第三，用“先计划后执行”作为默认姿势。对话里的第一句话是“请先阅读代码并给出修改计划”，等计划确认后再补一句“按照计划执行”。这套组合几乎百试百灵，特别适合重构和涉及多个文件的改动。第四，定期看成本。不要觉得看 token 消耗是抠门，它其实是让你对“AI 干活有多贵”建立体感。我看到一个文件反复被读取、上下文越来越长时，就知道该压缩会话了，这种意识能在团队协作时帮你省下真实预算。6. 踩坑实录与排查速查表6.1 我遇到的几个典型问题学习期间踩过的坑不少，挑几个最有代表性的记录下来，后续遇到类似问题能少走弯路。第一个问题是启动时模块加载报错。起因是我的 Node.js 版本太旧。这类错误有时会伪装成“找不到模块”或者“语法错误”，如果你本身环境比较陈旧，第一反应应该去查运行时版本是否满足官方要求，而不是去搜代码问题。第二个问题是 AI 在改完代码后，把我的文件格式化风格搞乱了。原因是项目说明文件里没有写明“使用代码格式化工具”，它按自己的偏好下了手。后来我在说明文件里加了一条规则：所有提交前必须运行格式化命令。问题立刻消失。第三个问题是上下文太长之后，AI 的回答开始“重新发明轮子”。比如明明已经在上文里确认过某个接口的签名，过了一段时间它又自作主张重新定义了一遍。解决方案是压缩会话，而不是继续追加新指令。第四个问题是权限弹窗一多反而容易麻木。有个下午我连续点了十几次确认，后来弹窗里出现一条git push指令，我差点随手点掉。幸亏那只是一个练习仓库，否则后果堪忧。这件事让我决定：在正式项目里只对可信目录开启自动批准，并且逐步缩小授权范围。6.2 问题速查表与避坑心得下面这张表格是我整理出来的“问题现象 + 解决方案”速查表：现象可能原因排查思路启动报模块错误环境版本过旧先查运行时版本，再搜报错关键词AI 频繁改错文件没有先读项目说明/上下文太杂清空会话，明确指定关键文件路径改完代码格式乱缺少代码风格约束在项目说明文件里写入格式化规则测试通过但功能不对AI 只满足于测试覆盖要求它补充测试并手动演示运行结果弹窗太多导致误点权限粒度设置不合理配置自动批准白名单，单独保留高风险操作确认对话长到“失忆”上下文窗口被占满使用压缩命令，或拆分成多个小任务改动不可控缺少回滚方案每次改动前先git diff，并建立隔离分支我个人最想强调的避坑心得很简单：永远让 AI 先给你看 diff 再收尾。我见过的绝大多数“AI 把代码搞坏了”的案例，都不是模型能力不够，而是操作者跳过了代码审查这一步。把它当成和“自己写完代码后再读一遍”同等重要的事，你的体验会很不一样。6.3 关于信任边界的一点个人体会使用 Claude Code 一段时间后，我对“ AI 编程助手”的定位有了更清醒的认识。它不是替你思考，而是替你节省“从意图到代码”的执行成本。思路和架构仍然要由你负责，尤其是在项目边界、数据安全和不可逆操作上，人类必须掌握最终决定权。我现在每天最常用的场景，是让它帮我处理那些“不那么需要创造性但又很花时间”的活儿：批量加日志、整理工具函数注释、替换过时的调用方式、补测试用例。这些事过去会占据我大量的编码时间，现在只需要检查它给出的改动是否合理即可。最后再分享一个小技巧：每个任务开始之前，我会刻意用一句话告诉它“这部分代码如果改坏了，影响范围是什么”。这句看似多余的话，往往能明显提高它对高质量改动的重视程度。S01 的学习记录就到这里，下次我打算继续整理细粒度权限配置和团队协作方面的用法。
前一阵子给自己定了个小目标：把 Claude Code 从零完整学一遍，边学边记，最后整理成这份 S01 学习记录。Claude Code 说白了就是一个跑在终端里的 AI 编程助手，它能在命令行里读你的项目代码、改文件、跑命令，甚至代替你完成一整条开发流水线。今天这篇就讲讲我从零开始学它的全过程，包括安装、配置、实战和踩坑。全文没有云里雾里的理论，全是终端里敲出来的真实记录，适合想入坑的开发者、技术负责人，以及所有好奇“命令行里的人工智能到底能干多少活”的人。1. 为什么突然决定把 Claude Code 学会1.1 厌倦了在 IDE 和浏览器之间反复横跳过去写代码，我的日常是：在编辑器里改代码，切到浏览器找文档，再切回来粘贴、调试、跑测试。遇到跨文件重命名或者全局替换，还要小心翼翼地确认作用范围。这种工作方式不能说不能用，但确实非常消耗注意力，尤其当你在做一个有一百多个文件的旧项目时，光花在“找到要改的位置”上的时间，就比真正动手改的时间还多。Claude Code 这个工具吸引我的核心点，就是它把“找代码、改代码、验证代码”这三个动作统一到了同一个对话入口里。我不需要先手动定位到某个模块，再思考怎么改，而是直接把需求用自然语言扔给它。它会自己翻项目结构、读文件、定位相关代码，然后给出修改方案。这种交互方式，本质上把“编程”从“敲击键盘的体力活”变成了“描述意图并验收结果的脑力活”。1.2 它和传统 AI 自动补全完全不是一回事很多人一听到 AI 编程，第一反应是编辑器里的代码补全插件，也就是写到一个函数名时自动补全下一行。但 Claude Code 的工作方式完全不同：它更像一个“能自己动手干活的外包工程师”，而不是一个“只会接话的输入法”。举个例子，同样是“给登录接口加一个验证码”这个需求。传统补全工具能帮你写一段生成验证码图的代码片段，但不会主动去改路由、加依赖、更新测试用例。而 Claude Code 的理解是原子的：它会先看接口文件，弄清现有鉴权逻辑，再决定验证码存哪里、过期时间设多少，甚至会把文档和测试一起更新。这种“从目标出发反推步骤”的能力，才是它真正值钱的地方。在 S01 这期学习里，我的目标也很简单：不追求会用那些高阶技巧，先把“安装、初始化、权限控制、跑通一个完整小任务”整明白，能稳定地用它处理日常项目里的琐碎工作。2. 动手前先把底层的运行逻辑摸清楚2.1 所谓“对话即操作”到底是怎么实现的我第一次用 Claude Code 之前，一直有一个疑问：它本质上是一个跑在终端里的进程，凭什么能修改我磁盘上的文件、执行我 shell 里的命令？后来捋清楚了：Claude Code 的核心是一个“工具调用循环”。你输入一段自然语言，它内部会把这段话拆解成意图，然后循环执行一系列工具操作。这些操作包括读文件、写文件、列目录、执行终端命令，每执行一步，它都会观察结果，再决定下一步行动。这就像一个新手程序员在跟你协作：你说“把这个接口的返回结果里加上创建时间”，它先grep找到接口位置，再读文件确认数据结构，然后改代码，最后跑一遍测试给你看。你不需要在终端里敲那些底层命令，它代替你做了，但每一步又都在你的监控之下。理解这一点很重要，因为这意味着：它的能力上限不只取决于模型本身，还取决于你给它的环境是否清晰。如果一个项目目录下塞满了构建产物、临时文件、node_modules，它很容易被无关信息干扰，从而在错误的方向上反复试探。我第一次实战时就是吃了这个亏，后面会详细讲。2.2 权限边界和安全模型的取舍既然它能执行终端命令，那安全问题怎么解决？这是每个初次接触的人都会问的，也是我一开始最警惕的。实际上 Claude Code 默认采用“请求许可”机制：它想执行一条 shell 命令前，会把命令原样展示给你，等你按确认键才会执行。读文件和普通编辑操作通常在授权范围内，而像删除大量文件、推送远端、修改权限这类高风险操作，会有更显眼的警告和二次确认。这个设计其实很像“给外包工程师一个只读账号，他要改东西之前先提交申请”。好处是安全可控，坏处是非常啰嗦——一个稍微复杂的任务可能要弹十几次确认。后面我会介绍怎么通过配置文件把低风险操作做成自动放行，但这里想先说一句：不要为了省事把所有权限全部放开，尤其是项目刚开始还不熟悉的时候。权限弹窗本质上是你和 AI 之间的“核对点”，省掉它们，就相当于把方向盘全部交给了一个还在实习期的司机。我还建议你养成一个习惯：每次让 AI 执行重要操作前，先让它用git status和git diff把当前改动展示出来。这样就算它改错了，你也知道回滚点在哪里。3. 安装与初始配置全记录3.1 环境准备：没有想象中复杂，但值得列个清单Claude Code 的运行环境依赖并不多，但基础版本最好提前确认。我自己的环境是 macOS + Node.js 长期支持版 + Git，其他终端环境基本也能跑，Linux 和 Windows 用户用 WSL 也是官方推荐的路径。这里给一个检查清单：Node.js 版本是否满足官方要求，最好在终端执行node -v看一下，版本太老会遇到奇怪的兼容问题Git 是否已安装并完成全局配置，很多项目操作会依赖 Git 状态判断是否安装了常用的构建工具链，比如你的项目是 Python 就要有 Python 环境，是前端项目就要有包管理器终端是否为 UTF-8 编码，避免中文路径或中文内容乱码我一开始没仔细检查 Node.js 版本，结果启动之后报了一个模块加载错误。当时第一反应是工具坏了，折腾了半天才发现是本地环境太旧。所以建议所有刚开始接触的人，先花三分钟把这些基础项确认好，不要直接跳到安装那一步。3.2 安装、登录和第一次启动安装过程非常简单，本质上就是把官方发布的 CLI 模块通过包管理器全局装到系统里。官方提供了全局安装命令，我这边因为环境不同，就不贴具体包名了，你在官方文档里直接复制对应命令执行就行。装完以后在终端输入claude --version，能看到版本号就说明安装成功。接下来是认证环节。启动后会自动打开浏览器让你完成账号授权，授权成功后会生成一个本地凭据，之后就不需要反复登录了。如果你是团队协作环境，也可以使用 API 密钥的方式配置，但为了安全，我建议个人学习阶段用默认的账号授权就好，少走弯路。首次启动时，Claude Code 会在你当前目录下创建一个会话。它默认是“跟随当前项目上下文”，也就是说你在哪个目录里启动，它就会以哪个目录作为工作根目录。所以请务必在想要让 AI 操作的代码项目根目录下启动它，而不是在/root或者用户主目录里启动，那样它会扫到一堆无关文件，既费 token，也容易产生错误判断。初始化完成之后，我做的第一件事是查看内置帮助菜单。Claude Code 内置了很多斜杠命令，比如帮助、清空会话、状态查看、成本统计等，每个版本会有细微差异。不要小看这一步，很多功能藏在这些看似不起眼的命令里。4. 第一次实战：在模拟项目 X 里跑通完整流程4.1 项目背景与任务拆解为了不拿真实项目冒险，我建了一个模拟项目 X，是一个用 Python 写的命令行小工具，功能是管理本地任务清单。项目结构很典型：有存储数据的模块、命令行入口、还有一小组单元测试。我给它提的需求是：新增一个“提醒日期”字段，并在查看任务列表时按提醒日期排序。这个需求看起来简单，但实际涉及数据存储格式变更、命令行参数的解析、排序逻辑的调整和测试用例更新，对一个不熟悉项目细节的人来说，至少需要十几分钟。我想验证的核心问题，就是 Claude Code 能不能在无人引导的情况下，靠自己的代码阅读能力把整个链路理清楚。在开始敲第一句话之前，我按照前面学到的经验，先手动看了一遍项目里的 README 和主入口文件，然后在会话里给它圈定了范围：“这是一个本地任务清单工具，我要增加提醒日期字段，涉及存储和命令行展示。请先阅读相关代码，再给我一个修改计划。”这里没有直接命令它“开始改”，而是先要求它输出计划，这一步帮了大忙。4.2 实操过程实录：从计划到改代码再到踩坑Claude Code 的第一轮回复给了三段式计划：修改存储结构、调整命令行解析、更新测试。它列出了要改的三个具体文件，并且每条都带了解释。我确认之后，它开始自动读取这些文件，逐段修改。整个过程里，我只需要看着终端里的进度，偶尔确认执行权限。第一次修改完成后，我让它运行项目的测试套件。结果失败了，原因是某个测试数据还停留在旧结构。这个错误很典型，恰恰是因为它修改了存储层但没同步修正测试夹具。我当时的处理不是直接指出具体位置，而是对 Claude Code 说：“测试失败了，请查看失败信息并修复所有相关代码。”它立刻定位到了测试文件，把旧结构的数据更新成了新格式，再次运行后全部通过。就在我以为已经完成的时候，它主动提示我：命令行入口里有一处打印逻辑还没适配新字段，虽然不影响测试，但会导致实际使用时的输出格式不完整。这个小细节让我比较意外，说明它确实领会到了整个功能链路的完整性，而不仅仅是满足测试绿变。随后它把那一处也修掉了，我确认 diff 之后才算收尾。这次实战给我最直接的感受是：把任务拆成“先计划、再实施、后验证”三个阶段，AI 的完成质量比直接让它一口气改完要高一截。因为它在计划阶段就会把相关文件扫一遍，后面改动时所有的判断都基于更完整的上下文，而不是边猜边改。4.3 权限确认环节的亲身教训过程中有一次它提出想删除一个临时数据文件，理由是旧格式的缓存不再需要。我从权限弹窗里看到这条rm命令，第一反应是拒绝。原因不是它判断得不对，而是我一直认为“删除数据”这类操作应该有更强的确认门槛。拒绝之后，我选择让它在项目里新开一个迁移目录，保留旧文件，只调整读取逻辑。这样虽然多了一步，但万一新代码有问题，旧数据依然能兜底。这件事情给我留下的印象很深：Claude Code 的执行能力越强，你对“哪些操作可以放权”的思考就得越认真，尤其是涉及删除、覆盖和推送这类不可逆动作时，宁可保守一点。5. 常用命令与工作流技巧5.1 这几个高频操作，建议第一天就记住Claude Code 的功能很多，但平时用得最勤的其实就那么几个。我把高频操作整理成了下面这张表，不同版本可能会有细微差别，但大方向是一致的：操作作用我的使用场景直接输入自然语言让 AI 理解并执行任务几乎所有操作的第一步斜杠清屏命令开启一个干净的会话窗口，清掉旧上下文任务切换时必用，避免前一个任务的上下文干扰斜杠压缩命令自动总结整段对话并压缩上下文对话太长、AI 开始“失忆”时使用斜杠成本命令查看本次会话的 token 消耗写完一个任务后随手看一眼，心里有数斜杠初始化命令在项目根目录生成或更新项目说明文件新项目第一次接入时执行文件引用前缀在输入中加入指定文件路径，强制 AI 优先参考想让 AI 关注某个关键文件时使用叹号前缀直接执行 shell 命令而不经过 AI 理解快速跑测试、查看状态时使用这里特别想强调文件引用前缀。如果你发现 AI 在理解需求时总是跑偏，最有效的办法就是在问题里直接塞上相关文件的路径，它读文件的顺序会因此发生明显变化。这就好比给外包工程师画了一个圈：“你不用满屋子找，就在这张桌子上干活。”5.2 把工作流编排出来的四个习惯第一，先立项目说明文件再开工。Claude Code 会读取项目根目录里的 CLAUDE.md 作为长期记忆，很多同学不知道这个文件的存在，结果每次对话都要重新交代项目背景。我在模拟项目 X 里特意写清楚项目结构、测试命令和代码风格约定之后，AI 后续的行为明显“稳重”了很多。第二，任务切换前务必清空会话。有一次我让它改完 A 功能后，直接接着问 B 功能的实现，结果它把 A 功能的旧思路带到了 B 的实现里，改出来的代码风格非常拧巴。从那以后，每切换一个任务，我都会先清空会话再重新描述目标。第三，用“先计划后执行”作为默认姿势。对话里的第一句话是“请先阅读代码并给出修改计划”，等计划确认后再补一句“按照计划执行”。这套组合几乎百试百灵，特别适合重构和涉及多个文件的改动。第四，定期看成本。不要觉得看 token 消耗是抠门，它其实是让你对“AI 干活有多贵”建立体感。我看到一个文件反复被读取、上下文越来越长时，就知道该压缩会话了，这种意识能在团队协作时帮你省下真实预算。6. 踩坑实录与排查速查表6.1 我遇到的几个典型问题学习期间踩过的坑不少，挑几个最有代表性的记录下来，后续遇到类似问题能少走弯路。第一个问题是启动时模块加载报错。起因是我的 Node.js 版本太旧。这类错误有时会伪装成“找不到模块”或者“语法错误”，如果你本身环境比较陈旧，第一反应应该去查运行时版本是否满足官方要求，而不是去搜代码问题。第二个问题是 AI 在改完代码后，把我的文件格式化风格搞乱了。原因是项目说明文件里没有写明“使用代码格式化工具”，它按自己的偏好下了手。后来我在说明文件里加了一条规则：所有提交前必须运行格式化命令。问题立刻消失。第三个问题是上下文太长之后，AI 的回答开始“重新发明轮子”。比如明明已经在上文里确认过某个接口的签名，过了一段时间它又自作主张重新定义了一遍。解决方案是压缩会话，而不是继续追加新指令。第四个问题是权限弹窗一多反而容易麻木。有个下午我连续点了十几次确认，后来弹窗里出现一条git push指令，我差点随手点掉。幸亏那只是一个练习仓库，否则后果堪忧。这件事让我决定：在正式项目里只对可信目录开启自动批准，并且逐步缩小授权范围。6.2 问题速查表与避坑心得下面这张表格是我整理出来的“问题现象 + 解决方案”速查表：现象可能原因排查思路启动报模块错误环境版本过旧先查运行时版本，再搜报错关键词AI 频繁改错文件没有先读项目说明/上下文太杂清空会话，明确指定关键文件路径改完代码格式乱缺少代码风格约束在项目说明文件里写入格式化规则测试通过但功能不对AI 只满足于测试覆盖要求它补充测试并手动演示运行结果弹窗太多导致误点权限粒度设置不合理配置自动批准白名单，单独保留高风险操作确认对话长到“失忆”上下文窗口被占满使用压缩命令，或拆分成多个小任务改动不可控缺少回滚方案每次改动前先git diff，并建立隔离分支我个人最想强调的避坑心得很简单：永远让 AI 先给你看 diff 再收尾。我见过的绝大多数“AI 把代码搞坏了”的案例，都不是模型能力不够，而是操作者跳过了代码审查这一步。把它当成和“自己写完代码后再读一遍”同等重要的事，你的体验会很不一样。6.3 关于信任边界的一点个人体会使用 Claude Code 一段时间后，我对“ AI 编程助手”的定位有了更清醒的认识。它不是替你思考，而是替你节省“从意图到代码”的执行成本。思路和架构仍然要由你负责，尤其是在项目边界、数据安全和不可逆操作上，人类必须掌握最终决定权。我现在每天最常用的场景，是让它帮我处理那些“不那么需要创造性但又很花时间”的活儿：批量加日志、整理工具函数注释、替换过时的调用方式、补测试用例。这些事过去会占据我大量的编码时间，现在只需要检查它给出的改动是否合理即可。最后再分享一个小技巧：每个任务开始之前，我会刻意用一句话告诉它“这部分代码如果改坏了，影响范围是什么”。这句看似多余的话，往往能明显提高它对高质量改动的重视程度。S01 的学习记录就到这里，下次我打算继续整理细粒度权限配置和团队协作方面的用法。