企业官网建设流程全解析

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 才是精髓：把“带实习生”的经验固化成 SOP

4.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 安装启动阶段的高频报错

这个环节的问题通常集中在环境层面，我把常见的几种列成一张速查表：

这里最值得提醒的是：不要在一个项目还没理清楚的时候就着急装各种东西。我见过有新手在系统根目录直接敲claude，然后让它“给全系统做个优化”，事后发现它开始扫描各种系统文件——并不是它有多危险，而是你给了一个没边界的指令，它在系统目录里干活的风险自然就高了。老话重提：你让它做什么，它才会做什么，边界感要靠你自己去划。

6.2 实操中最容易翻车的三个场景

第一个翻车点：让它在错误的目录里干活。有一次我在项目 A 的目录里启动了 Claude Code，让它去修改一个“登录页的 bug”，结果它在项目 B 的代码里找了半天没找到，还自作主张地在项目 A 里新建了一个看起来很像登录页的文件。后来我才发现，是我自己同时在多个项目之间切换，上下文都乱了。解决方案很简单：一次只在一个项目里工作，跨项目任务分开启动，每条指令都带上明确的项目路径。

第二个翻车点：文件被大范围重写，而且改动不符合预期。Claude Code 修改文件时通常会先展示 diff 再确认。但有一次它执行一个重构任务时，由于改动涉及的模块太多，生成的 diff 非常长，我没仔细看就顺手同意了“apply all”。结果发现它把一些无关的文件也格式化了，导致某个配置文件的行尾符被改掉，在 Windows 环境下引发一串问题。从那以后，我养成了一个习惯：大改动必须分批接受，每次只看一部分改动，重点检查它是否“顺手”改了不该动的东西。实习生干活毛手毛脚，你签批的时候就得瞪大眼睛。

第三个翻车点：上下文被塞爆，它开始“胡言乱语”。这个问题的根源是模型上下文窗口有限。当项目很大、本次对话涉及的上下文又很多时，它可能记不清最开始的要求，或者在读文件时跳过了一些内容，导致后面的判断失准。症状就是——你让它改一个函数，它改完说“改好了”，你一看，关