1. 先把心态摆对Claude Code 不是“另一个软件”是一个“会用电脑的编程实习生”如果你是从 VS Code 插件市场或者某篇推文里看到 Claude Code 这个名字大概率第一反应是又一个 AI 编程工具装就完事了。但实际用下来我最大的感受是——这玩意儿和你以前用的任何“自动补全插件”“AI 聊天助手”都不一样。它不是一个等你敲完代码再帮你提示的辅助工具而是一个能自己打开文件、搜索代码、运行命令、修改多处文件、跑测试、然后告诉你“我改完了你自己看下”的独立执行者。最贴切的比喻就是标题里那句话把 Claude Code 当成你刚招进来的一个“会用电脑的编程实习生”。实习生是什么状态你给他一个需求他不会的第一时间会问你但更多时候他会自己尝试、自己查资料、自己动手改。他会在你的项目目录里翻文件会试着运行命令会给你一个初步结果。这个过程中你需要做的不是手把手教他每一行代码怎么写而是把需求讲清楚、定好边界、最后验收结果。Claude Code 就是这个实习生。它的能力边界、它的使用方式、它的坑全部围绕这一个比喻展开。这篇文章我按“从零到能干活”的顺序来写覆盖三个重点第一怎么用“带实习生”的心态理解 Claude Code 的工作方式第二从安装到正式跑起来小白会遇到哪些问题第三也是我觉得最值得研究的——Skill 机制它本质上就是在给这个“实习生”写标准作业流程SOP把你的团队经验、踩坑教训、项目规范全部固化成文件让实习生一键调用。这也是标题里“Skill 作为 SOP 的一键化”的意思。适合看这篇的人想入门的编程新手、想提高日常开发效率的工程师、以及团队里想规范化 AI 编程流程的负责人。如果你已经重度使用 Claude Code可以直接跳到第三节看 Skill 的部分前面两节就当回顾。2. 把 Claude Code 当“实习生”来理解很多困惑会瞬间消失2.1 实习生的三项核心能力读代码、改代码、跑命令Claude Code 在命令行里工作但它和那些只能在聊天框里输出代码片段的 AI 有本质区别。它被赋予了三个关键能力对应现实中实习生会做的事第一读代码。你给它一个需求比如“帮我看下登录模块的 token 刷新逻辑为什么偶尔失效”它会自己去项目里搜索相关文件阅读代码追踪数据流而不是凭空给你一段不相干的代码。这一点特别重要因为很多 AI 工具只能根据你已经贴出来的代码片段做分析而 Claude Code 是在整个项目上下文里工作。第二改代码。它可以直接读取、编辑、创建项目里的文件。你说“把这个接口的返回格式改成统一包装结构”它真的会去找到那个文件修改然后告诉你改了哪些地方。在修改前它会先展示 diff等你的确认——像不像实习生改完作业等你批注第三跑命令。它能在你的终端环境里执行命令比如运行测试、安装依赖、执行构建脚本。改完代码它会自己跑一遍测试来验证如果测试挂了它会继续分析原因再修一轮。这三个能力叠加才是 Claude Code 真正能“干活”的原因。但这也正是新手最容易出问题的地方——很多人没意识到它真的会执行命令、修改文件于是给了非常模糊的指令结果它在错误的文件里瞎改一气。想用好它得先理解这个“实习生”的权利边界。2.2 为什么说“带实习生”而不是“让 AI 自动干活”有个很关键的心态转变不要指望 Claude Code 是一个“全自动编程机器人”打开它、扔给它一个项目它就能把整个软件写完。现在的 AI 编程工具包括 Claude Code 在内本质上还是一个需要人盯着的实习生而不是无人驾驶汽车。我带它的方式是把它当成团队里最勤快但经验最少的那个人。我会像布置任务一样给它拆解需求——背景是什么、目标是什么、边界在哪、验收标准是什么。它执行的过程中我不会全程盯着但会要求它每一步都告诉我它在干什么遇到不确定的地方先问我而不是自作主张。它有权限运行命令但这个权限范围我可以控制。它可以修改文件但每个修改我都要求它展示 diff。这样理解之后你再看那些“Claude Code 把项目改崩了”“Claude Code 瞎删文件”的吐槽就会明白——本质上都是“带实习生”的人没做好自己的本职工作。需求讲不清楚、边界没划定、验收没把关出问题不能全怪实习生。当然 Claude Code 也有它自己的局限比如上下文窗口有限、对超大项目的理解不全面这些后面的常见问题章节会细讲。2.3 它到底是怎么“思考”的——上下文、工具调用和权限模型要当好这个实习生的“领导”你还得稍微理解一下它的“大脑”是怎么运作的。Claude Code 背后是一个大语言模型它不是像人一样“理解”代码而是根据你项目里的文本内容做模式匹配和推理。它能看到什么取决于上下文窗口——可以简单理解成它一次能“看到”多少内容。它干活的时候是这样的读入你的需求然后在项目里搜索相关内容塞进自己的上下文接着决定下一步要调用哪个工具比如读取文件、编辑文件、执行命令然后再观察工具返回的结果决定下一步做什么。这是一个循环思考 → 行动 → 观察 → 再思考。这种循环让它能完成多步骤的复杂任务但也意味着如果项目太大它可能会漏掉一些关键文件或者被一些过时的信息误导。另一个核心概念是权限。Claude Code 执行命令、修改文件都需要经过你的授权。默认情况下它是比较谨慎的每一个操作都会来问你这就像实习生每做一步都要拿给你看。如果你觉得太烦可以通过配置放宽权限让某些安全操作自动执行但我强烈建议新手先保持默认等熟悉了它的行为模式再调整。权限模型是你控制这个“实习生”最重要的抓手——心里要有这根弦所有权限都是你给的你随时可以收回来。3. 实操第一步把“实习生”招进来——安装 Claude Code 并完成首次启动3.1 安装前的环境准备Node.js 是唯一硬性要求在装 Claude Code 之前先确认你的电脑上有没有 Node.js。这是它唯一硬性的环境依赖没有 Node.js 就装不了。如果你不确定自己装没装可以在终端里敲node -v如果返回了一串版本号比如v20.11.0说明已经有了。如果提示command not found需要去 Node.js 官网下载 LTS 版本安装。这里有个小提示不要为了追求最新版本去下载 Current 版本LTS 版本更稳定AI 工具的兼容性测试也主要针对 LTS 做的。装完 Node.js 之后打开终端执行下面的命令npm install -g anthropic-ai/claude-code-g表示全局安装装完之后你就拥有一个claude命令了。安装过程如果比较慢多半是网络问题可以换成国内 npm 镜像源再重试。这一步我自己在 Windows 和 macOS 上都试过没有遇到什么特别的坑。Windows 用户这里多提醒一句建议用 PowerShell 或者 Windows Terminal 来跑老版本的 CMD 有时会出一些奇怪的编码问题。另外如果安装的时候报权限错误不要一上来就想着用管理员权限强装一般是 Node.js 安装路径的权限问题用 nvm 重装一遍 Node 反而更省事。3.2 首次启动与登录比想象中顺畅安装完成后在终端输入claude第一次启动会引导你登录 Anthropic 账号。这个过程需要在终端里打开一个链接用浏览器完成授权后再回到终端。登录方式通常支持两种使用 Claude 订阅账号直接登录或者通过 API 的方式接入。作为入门用户直接用订阅账号是最省心的因为 API 是按 token 计费的对小白来说很容易在不知不觉中把额度跑光。登录成功之后你会进入一个交互式的命令行界面开头会显示版本号和一个提示大意是“在项目目录中使用效果更佳”。这时候你会发现自己到了一个看起来很像聊天窗口的界面。但注意这和聊天窗口有本质区别——你现在的当前位置决定了它能看到哪些文件。我的建议是不要直接在用户目录下启动 Claude Code而是先cd到你的项目目录再敲claude。这样它就自动把当前项目当成工作目录后续它搜索文件、运行命令都在这个目录范围内进行。好比你把实习生领到了工位而不是让他在公司大厅里瞎晃。3.3 第一个需求从“帮我解释这个项目”开始刚启动之后先别急着让它写功能。第一件事——让这个“实习生”先熟悉项目。你可以这样下第一条指令先不要修改任何文件。请浏览一下这个项目的整体结构告诉我这是一个什么项目用了哪些技术栈核心模块有哪些各自的职责是什么。这个指令有几个好处一是验证它是否真的能“理解”项目结构二是让你自己对项目做一次“AI 视角”的梳理有时候能发现被你忽略的东西三是建立安全边界——明确要求它暂不修改文件给自己一个观察它行为模式的机会。正常情况下它会开始搜索目录结构、读取关键配置文件比如 package.json、README、浏览源码文件然后给你输出一份项目概览。你可以在这份概览里检查它有没有漏掉关键模块。如果有你可以追问“你是不是没看到 xxx 目录”它会去补充。这个过程可能比你想象的更能体现出一个“实习生”的真实工作方式——它不会主动跟你说“我哪里没看全”除非你问。3.4 保存会话和恢复上下文把“实习生的记忆”接上Claude Code 是支持会话历史的你退出之后再次启动可以接着上次的对话继续。具体操作是在项目目录里再次运行claude然后用--continue之类的参数恢复最近的会话或者用--resume来选择指定会话。平时用的时候如果一次任务干到一半被叫去开会回来之后重新接上上下文这点很实用不用把之前的所有信息再喂一遍。对于经常性重复的工作更高效的做法是下面第三节要讲的 Skill——把常用任务的执行流程固化成文件让每次启动都能一键复用而不是依赖会话历史慢慢往回翻。4. Skill 才是精髓把“带实习生”的经验固化成 SOP4.1 从“每次重复交代”到“一键调用”的转变用 Claude Code 一段时间后你会发现一个很明显的痛点同一类任务每次都要从零开始交代背景、步骤、注意事项。比如我经常让它做代码审查每次都要在指令里写一大段“先看结构再看逻辑最后检查边界条件注意安全漏洞报告要按 xx 格式输出”。一次两次还好时间长了真的烦。更麻烦的是不同人让它做审查审查的标准和深度完全不一样。Skill 就是解决这个问题的机制。简单说你可以把一套完整的任务执行流程、判断标准、输出格式写成一个文件然后给这个文件起个名字。之后你要执行这类任务时只需要告诉 Claude Code “使用 xxx 技能来完成任务”它就会自动按照你写的流程去执行。这不就是 SOP 吗标准作业流程把老师傅脑子里的经验显性化变成任何一个新人都能照着执行的文档。Skill 的本质就是把 SOP 变成 AI 能自动调用的格式实现真正意义上的一键化。以前你要培养一个新人得花几周甚至几个月让他慢慢积累经验现在你写一个 Skill 文件它三秒钟就学会了你总结的所有要点。4.2 Skill 的目录结构和核心配置一个 SKILL.md 加若干脚本Claude Code 的 Skill 机制核心是一个基于文件目录的结构。规范的 Skill 目录通常长这样~/.claude/skills/ └── code-review/ ├── SKILL.md └── scripts/ ├── check_security.py └── complexity_report.py这里最核心的文件是SKILL.md它就是这个 Skill 的“说明书”。Claude Code 在调用 Skill 时会先去读这个文件按照里面的指引去执行任务。SKILL.md的编写方式我建议遵循一个基本结构开头是元信息name 和 description声明这个技能叫什么、什么时候该用它中间是任务目标和工作流程告诉模型遇到这类任务应该按什么步骤来后面是注意事项和质量标准列出常见错误、边界条件、输出格式。下面是一个简化的示例--- name: code-review description: 对项目代码进行系统审查包括结构、逻辑、安全和性能。 --- # 代码审查技能 ## 工作流程 1. 先浏览项目整体结构确定本次审查范围。 2. 按依赖关系阅读相关文件标注关键逻辑。 3. 检查安全漏洞硬编码密钥、未授权接口、注入风险。 4. 输出审查报告按严重程度分级。除了SKILL.md之外这个目录里还可以放一些辅助脚本。如果这个技能需要特定的数据处理、规则检查或者更复杂的自动化操作你可以在scripts目录里放 Python 或 Shell 脚本然后在SKILL.md里告诉模型“执行到第 x 步时运行 scripts 目录下的 xxx 脚本来检查”。4.3 怎么区分“用 Skill”和“写 Skill”日常使用中其实存在两个层面。大部分用户首先是 Skill 的“使用者”。你从社区或者团队内部拿到一个现成的 Skill只要把它放进约定好的目录通常是~/.claude/skills/或者项目级的.claude/skills/括号里的内容就生效了。下次对话时你只需要说“用 xx 技能帮我处理 xx”它会自动从对应目录中找到那个 Skill 并按照里面的 SOP 执行。另一种情况你是 Skill 的“作者”。当团队里某个工作流程已经跑通比如你们接了新的 API、采用了新的代码规范、总结了常见的 bug 模式你把这些沉淀成一个 Skill 文件放进共享目录团队其他成员就能直接受益。这也是一种知识管理把散落在个人文档里的经验变成团队公共资产。这也就解释了为什么在社区里你会看到各种五花八门的 Skill——数学建模 skill、仓颉 skill、测试用例 skill、代码审查 skill、挖掘漏洞 skill本质上都是不同领域的老师傅把他们各自领域的 SOP 固化成了 AI 可执行的格式。Skill 本身不限制领域你甚至可以给自己的日常工作流写一个 Skill。4.4 Skill 和 Agent 的区别别再傻傻分不清热词里有一个很常见的搜索词是“skill 和 agent 的区别”。这两个概念经常被放在一起讨论确实容易混淆。我用自己的理解来拆一下Skill 是一个“剧本”是一套固化的流程文档。它本身不主动做事它只是告诉模型“遇到这类任务你应该按这些步骤来”。它是被动等着被调用的。Agent 是一个“角色”是一个能自主决策和行动的执行体。它会根据目标任务自行决定调用哪些工具、执行哪些操作、何时需要向你询问确认。Agent 是更主动的存在。准确地说Skill 更像是 Agent 的“工具箱”或者“手册”。Agent 在执行任务时可以选择调用某个 Skill 来指导特定环节的操作。反过来一个 Skill 也可以被不同的 Agent 共享复用。关系可以理解为Agent 是“实习生”本人Skill 是“实习生”手边的那本操作手册。实习生可以自己思考怎么干活但遇到手册里写过的情况翻手册照着做是最稳的。5. 手把手写一个自己的 Skill以“测试用例生成”为例5.1 先想清楚这个 Skill 要解决什么问题、给谁用很多人一上来就想写一个“万能 Skill”结果什么都没写好。我建议从自己最常做的、但又特别有规律的事情入手。以我自己为例我经常需要给后端接口生成测试用例但每次都要在指令里写清楚“要从哪些角度测、覆盖哪些边界、用什么格式输出”。后来我写了一个“测试用例生成” Skill一次性把这些问题全解决了。动笔之前你先问自己三个问题这个 Skill 面向的任务是什么比如“给接口生成测试用例”执行时它需要知道哪些信息比如接口路径、入参、出参结构、依赖环境输出结果应该是什么形式比如一张包含用例编号、场景、步骤、预期结果的表格想清楚这三个问题你的 SKILL.md 基本就成型了。5.2 编写 SKILL.md用“教新人”的口吻写SKILL.md 的语言不要太抽象要具体。但注意它不是在给你看是写给 AI 看的执行手册。AI 最擅长从具体的步骤描述中提取可执行的指令所以你要像教一个完全不懂你们项目背景的新人那样把每个步骤都写清楚。下面是我当时写的简化版你可以直接参考--- name: api-test-case-generator description: 为给定的后端 API 接口生成完整的测试用例包含正常场景、边界场景和异常场景。 --- # API 测试用例生成技能 ## 输入信息 使用本技能前先确认以下信息 - 接口路径和请求方法 - 请求参数的结构和类型 - 响应数据的结构 ## 工作流程 1. 根据输入信息梳理接口的入参、出参和可能的状态码。 2. 生成正常场景用例主流程能跑通的情况。 3. 生成边界场景用例参数为 null、空字符串、超长字符串、极限数值等。 4. 生成异常场景用例错误参数类型、未授权访问、服务异常等。 5. 输出为 Markdown 表格包含用例编号、场景描述、前置条件、测试步骤、预期结果。 ## 注意事项 - 不要假设接口的鉴权方式统一用 Authorization: Bearer token 占位。 - 状态码覆盖 200、400、401、500 等常见值。 - 涉及幂等性的接口要加一条重复请求的用例。写完之后把文件保存为~/.claude/skills/api-test-case-generator/SKILL.md。就是这么简单不需要编译不需要注册只要你把文件放在对了位置这个 Skill 就生效了。5.3 在 Claude Code 里测试和调试你的 Skill用的时候很简单在 Claude Code 会话里输入类似这样的指令使用 api-test-case-generator 技能为/api/v1/user/login这个接口生成测试用例。接口入参是 username 和 password都是 string响应是 { token, expire_in }。它会根据 SKILL.md 里的流程来执行输出一份有模有样的测试用例表格。第一次跑完大概率会有不满意的地方比如有的用例场景覆盖不够细有的预期结果写得不够具体。这时候你不用去改对话直接去改 SKILL.md 文件就行——把每次实际使用中发现的问题回填到 SKILL.md 里这个技能就会越用越准跟你带新人时不断校准操作手册一个道理。这里分享一个小技巧写完 SKILL.md 后先不要用复杂的输入去测试用一个最简单的例子跑通流程确认它能正确读取并执行你的指令再逐步增加复杂度。相信我这一步能帮你省去很多排查问题的时间。5.4 几个常见的 Skill 编写误区在社区里见过不少写得不太好的 Skill这里总结几个典型问题。第一个是过于抽象。写 SKILL.md 的人以为 AI 什么都知道于是只写了“进行全面的代码审查”没有写具体审查什么。AI 不是你们项目组的老人你不说它真不知道。写 Skill 一定要把标准写清楚最好拿一个具体例子在 SKILL.md 里对照说明。第二个是流程太复杂。一个 Skill 里塞了十几步、几十条注意事项模型执行到后面很容易漏掉前面的步骤。我建议一个 Skill 聚焦解决一个核心任务流程控制在五到七步以内。太复杂的任务拆成两三个 Skill 来写分别调用。第三个是不做版本管理。Skill 文件改了一版又一版没有记录也没有备份。我自己吃过大亏——有一次把写好的 Skill 目录误删了里面有几个迭代了很多轮的 SKILL.md重新写真的特别痛苦。后面我养成了每个 Skill 配一个CHANGELOG.md记录关键修改的习惯重要的 Skill 还会同步到 Git 仓库里代码能进版本管理Skill 凭什么不能6. 常见问题与实战避坑这里都是真金白银换来的教训6.1 安装启动阶段的高频报错这个环节的问题通常集中在环境层面我把常见的几种列成一张速查表现象常见原因解决方案command not foundnpm 全局安装路径不在 PATH 中重新安装 Node.js或用 nvm 管理版本安装时提示EACCES权限错误npm 全局目录权限不足不要用 sudo 硬装用 nvm 重装 Node.js启动后一直转圈不响应网络问题或首次启动需要加载资源检查网络连通性耐心等待 30 秒以上登录后授权页面打不开终端无法自动唤起浏览器手动复制终端里输出的链接到浏览器打开提示 can‘t connect 或超时网络受限先检查是否能正常访问官方服务再排查代理冲突这里最值得提醒的是不要在一个项目还没理清楚的时候就着急装各种东西。我见过有新手在系统根目录直接敲claude然后让它“给全系统做个优化”事后发现它开始扫描各种系统文件——并不是它有多危险而是你给了一个没边界的指令它在系统目录里干活的风险自然就高了。老话重提你让它做什么它才会做什么边界感要靠你自己去划。6.2 实操中最容易翻车的三个场景第一个翻车点让它在错误的目录里干活。有一次我在项目 A 的目录里启动了 Claude Code让它去修改一个“登录页的 bug”结果它在项目 B 的代码里找了半天没找到还自作主张地在项目 A 里新建了一个看起来很像登录页的文件。后来我才发现是我自己同时在多个项目之间切换上下文都乱了。解决方案很简单一次只在一个项目里工作跨项目任务分开启动每条指令都带上明确的项目路径。第二个翻车点文件被大范围重写而且改动不符合预期。Claude Code 修改文件时通常会先展示 diff 再确认。但有一次它执行一个重构任务时由于改动涉及的模块太多生成的 diff 非常长我没仔细看就顺手同意了“apply all”。结果发现它把一些无关的文件也格式化了导致某个配置文件的行尾符被改掉在 Windows 环境下引发一串问题。从那以后我养成了一个习惯大改动必须分批接受每次只看一部分改动重点检查它是否“顺手”改了不该动的东西。实习生干活毛手毛脚你签批的时候就得瞪大眼睛。第三个翻车点上下文被塞爆它开始“胡言乱语”。这个问题的根源是模型上下文窗口有限。当项目很大、本次对话涉及的上下文又很多时它可能记不清最开始的要求或者在读文件时跳过了一些内容导致后面的判断失准。症状就是——你让它改一个函数它改完说“改好了”你一看关