企业官网建设流程全解析

我最初用 Claude Code 的时候，感觉就像招了个名校毕业但完全没带行李的实习生——脑子很好使，但手边什么工具都没有。你跟它说“写个脚本处理一下这些图片”，它能写，但它不知道你项目里图片规范、不知道你常用的组件库、更不懂你团队代码风格的约定。每次都要在 Prompt 里反复叮嘱，上下文窗口烧得飞快，心累。

后来我把 Skills 和图片识别这套东西配齐之后，体验完全变了。简单说，Skills 就是给 Claude Code 预先装满“工作手册”和“工具腰带”，图片识别则是给它装上“眼睛”，让它真正看得见你丢给它的截图、设计稿和报错画面。这篇文章我就把从零配置到实战的完整过程拆开揉碎讲一遍，全程带命令、带踩坑记录。

1. 为什么你需要给 Claude Code 装一套“技能库”

1.1 默认的 Claude Code 有什么能力边界

先说清楚一个容易被忽略的事实：Claude Code 本身不是一个“什么都预装好的 IDE 插件”，它本质上是一个运行在终端里的 AI 编程代理，能调用你的 Shell、读写文件、执行命令，但它的“领域知识”并没有针对你的项目做任何定制。

举个例子，你让它“用公司的前端规范写一个组件的 demo”，它虽然能写出 React 代码，但它大概率不知道你公司内部封装的 UI 库叫什么名字、样式方案是 Tailwind 还是 Less、提交信息要遵循什么格式。结果就是你得在一次会话里疯狂补充背景，或者频繁切换上下文，效率掉得很快。

这也是 Skills 机制存在的根本原因：它不是给模型“加功能”，而是给模型“加说明书和工具集”。一个 Skill 本质上是一个带结构的目录，里面有SKILL.md作为描述文档，还有可执行的脚本、参考模板、代码片段，甚至图片资源。Claude Code 在启动时会扫描这些目录，根据任务类型自动匹配合适的 Skill，然后按里面的步骤执行。

1.2 Skills 解决的是“上下文基建”问题

很多人喜欢把 Skills 理解为“插件”，但我觉得更准确的类比是“入职培训手册”。插件是代码层面的扩展，而 Skill 更像是一套“行为准则 + 速查表”，告诉 Claude 在你的项目里应该按什么套路做事。

比如一个前端开发 Skill，里面的SKILL.md会写明：

• 项目的目录结构长什么样，组件放在哪、工具函数放在哪
• 样式方案采用什么（Tailwind 配置项、设计 token 文件位置）
• 新组件必须导出的接口有哪些
• 提交代码前需要跑哪些 lint 和测试命令

把这份“手册”装进 Claude Code 之后，它每次处理前端任务时就会像老员工一样顺手。这个机制的妙处在于：它把上下文从“会话级”提升到了“资产级”，一份 Skill 可以跨项目复用，也能分发给团队其他成员。

1.3 这套配置适合谁参考

如果你只是偶尔用 Claude Code 写个一次性脚本，那 Skills 对你来说可能略显多余；但如果你天天要用它写业务代码、维护项目、处理重复性较高的开发任务，又或者你想让团队里不同水平的人都用出接近统一的质量，那这套配置就非常值得折腾。

图片识别则更适合另一类场景：比如拿到 UI 设计稿要还原页面、收到一张报错截图不知道是哪里的问题、文档里粘贴了某个架构图想让 AI 理解并生成代码。搭配 Skills 之后，整体工作流会顺滑很多：先让 Claude 看图理解目标，再调用前端 Skill 按项目规范产出代码，一气呵成。

2. 动手前需要准备的环境：Node.js、Git 和 Claude Code 本体

2.1 Node.js 安装时的版本坑

Claude Code 是 npm 包，所以 Node.js 是必须先装好的。很多人在这里踩的第一个坑是版本问题——Claude Code 对 Node.js 版本有硬性要求，太老的版本（比如 14.x、16.x）装不上或者装上了运行报错。我自己的经验是直接上 LTS 版本，用 nvm（Node Version Manager）管理最省心。

以 macOS 或 Linux 为例，安装 nvm 并切到 Node 20 LTS 的命令大致是这样：

# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重新加载 shell 配置 source ~/.bashrc # 或者 source ~/.zshrc # 安装 Node 20 LTS 并设为默认 nvm install 20 nvm alias default 20 nvm use 20

Windows 用户建议直接去官网下载 .msi 安装包，勾选“Add to PATH”，然后用node -v验证。注意不要用太旧的 18.x，我在 18.17 上碰到过 npm 安装依赖时偶发的证书问题，升级到 20 之后就再没遇到过。

2.2 Git 安装与基础配置

Claude Code 在项目里会和 Git 深度联动，比如生成提交信息、查看 diff、回滚变更等，所以 Git 也必须就位。各平台安装方式不用多说，重点说一下配置：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这两个配置缺失的话，Claude Code 帮你生成提交的时候会直接报错。另外建议顺手配一下默认分支名和拉取策略，减少后续交互时的摩擦：

git config --global init.defaultBranch main git config --global pull.rebase false

2.3 安装 Claude Code 本体与登录验证

环境就绪后，安装 Claude Code 本体其实就一条命令：

npm install -g @anthropic-ai/claude-code

安装完成后输入claude进入交互界面，按提示完成登录授权。如果你之前没有 Anthropic 账号，需要先去官网注册。这里有个比较容易踩的坑：如果终端里有代理环境变量，登录时偶尔会卡住，我遇到过几次，当时排查了很久，最后把终端代理关掉重试就秒过了。

登录成功后在项目目录里跑claude，你会看到它扫描当前目录并生成.claude相关的配置文件夹。到这一步，Claude Code 的“本体”才算真正就位，接下来就可以开始装“技能库”了。

3. 给 Claude Code 安装“技能库”：从零到实战

3.1 Skills 目录结构与 SKILL.md 的编写规则

在装社区技能包之前，我强烈建议你先花十分钟搞懂 Skills 的目录结构，否则后面遇到问题很难排查。一个标准的 Skill 目录大致长这样：

my-skill/ ├── SKILL.md ├── scripts/ │ └── run.sh ├── templates/ │ └── component.tsx └── assets/ └── example.png

SKILL.md是这个技能的核心，通常用 Markdown 写成，里面会写清楚“这个技能解决什么问题”“在什么情况下使用”“执行步骤是什么”“有哪些参数可选”。Claude Code 读取它的逻辑和 GPTs 的 Instructions 有点类似，但加了更结构化的格式约定。

一个比较精简的SKILL.md可以是这样的：

--- name: frontend-component-builder description: 根据设计稿生成符合项目规范的前端组件 --- # 前端组件生成 当用户需要创建新组件时，遵循以下步骤： 1. 检查 src/components 下已有组件的命名与导出方式 2. 使用 templates/component.tsx 作为初始模板 3. 样式统一采用 Tailwind 工具类 4. 生成后运行 npm run lint 校验

注意开头的 YAML front matter 里需要有name和description，Claude 会根据description里的描述判断要不要激活这个技能。

3.2 安装社区热门技能包：superpower skills

社区里目前比较出圈的是 superpower skills 这个仓库，它把大量开发场景的 Skill 集中管理起来，包括前端开发、后端调优、代码审查、测试生成等，基本属于“装一个顶十个”的类型。

安装方式很简单，把仓库克隆到 Claude Code 的技能目录即可。以 macOS/Linux 为例：

# 进入 Claude Code 的配置目录 cd ~/.claude # 克隆社区技能包 git clone https://github.com/awesome-superpower/superpower-skills.git skills

Windows 用户注意路径，一般位于C:\Users\你的用户名\.claude\skills。克隆完成后，重启claude会话，让它重新扫描技能目录。

装好后怎么验证是否生效？有个很朴素的办法：在 Claude Code 里直接问它“你现在掌握哪些技能”，它会列出扫描到的 Skill 列表和各自的用途。如果它一个都没列出来，大概率是SKILL.md的 front matter 格式不对，或者目录路径没有识别到。

3.3 如何写一个自己的极简“需求解析 Skill”

社区技能包虽好，但真正好用的是“长在你项目上”的自定义技能。我拿自己写的“需求解析 Skill”举例。这个 Skill 的作用是：当用户丢过来一段模糊需求时，Claude 先按固定格式问澄清问题，再输出结构化的需求拆解文档。

它的SKILL.md核心内容其实就几行：

--- name: clarify-requirements description: 将模糊需求拆解为可执行的任务清单 --- 当用户描述需求但信息不充分时，先输出以下澄清问题： - 这个功能的核心用户是谁？ - 优先级和时间要求是什么？ - 依赖哪些现有模块？ - 验收标准是什么？ 用户回答后，按 背景 / 目标 / 任务拆解 / 验收标准 四段输出。

写完后放在~/.claude/skills/clarify-requirements/目录下。效果很明显：以前让 Claude 写功能，它总是迫不及待地咔咔写代码，结果方向经常跑偏；现在它先像个产品经理一样问清楚需求，再动手，返工率低了很多。

3.4 开发类 Skills 的进阶：把脚本打包进技能

Skills 不只是“说明书”，它还能携带可执行脚本。这个能力非常关键，等于你既能告诉 Claude“应该怎么做”，还能直接给它“能做到的工具”。

举个例子，我给一个项目写过“批量压缩图片”的技能，目录里放了一个scripts/compress.py脚本，SKILL.md里写“当需要压缩图片时，运行 scripts/compress.py 并传入目标目录参数”。这样 Claude 遇到相关任务时不用现场写 Python 代码，直接调用现成脚本，稳定性和速度都好很多。

自定义脚本注意一点：在SKILL.md里明确写清楚脚本的输入输出格式和依赖环境。否则 Claude 调用时可能不知道需要先装 Pillow，或者不知道脚本需要传什么路径。

4. 给 Claude Code 装上“眼睛”：图片识别的三种可行路线

4.1 路线一：原生读取图片路径（最简单）

先说一个很多人不知道的隐藏能力：Claude Code 本身是支持“看图”的。不是说你贴一张二进制的图片给它，而是把图片路径作为上下文传给 Claude，模型可以读取本地图片文件，并理解里面的内容。

我在实际使用中一般是这么操作的：先在终端里用/add命令把图片路径加入上下文，或者在对话里直接告诉它“看一下screenshots/bug.png这张截图”。它读取之后，真的能理解截图里的界面布局、报错信息，甚至能描述出 UI 的大致结构。

这个能力对于“根据截图写前端”特别有用。有一次 QA 发来一张页面错位的截图，我没有远程 VNC 去看，直接把截图拖进终端，让 Claude 描述差异点，然后让它定位到对应组件的样式问题，整个过程不到五分钟。

4.2 路线二：Python OCR 方案（适合识别文字密集的截图）

原生图片理解能力虽然强，但如果截图里全是文字，比如文档截图、错误日志抓图、验证码之类的，用 OCR 会更精准。目前在 Claude Code 里做 OCR 最方便的组合是pytesseract+Pillow。

环境准备命令：

# macOS brew install tesseract # Ubuntu/Debian sudo apt install tesseract-ocr # Python 库 pip install pytesseract pillow

然后写一个极简的 OCR 脚本，让 Claude Code 通过 Skill 调用：

import sys from PIL import Image import pytesseract if len(sys.argv) < 2: print("用法: python ocr.py <图片路径>") sys.exit(1) image_path = sys.argv[1] text = pytesseract.image_to_string(Image.open(image_path), lang="chi_sim+eng") print(text)

把脚本丢进一个叫ocr-image的 Skill 目录，SKILL.md里写清楚“当用户需要提取截图中的文字时调用此脚本”。实测下来，对于清晰截图里的中文、英文混排文字，识别准确率相当可观，至少能作为第一道“文字提取器”，然后再交给 Claude 做语义分析。

4.3 路线三：视觉解析服务（适合复杂图片和批量处理）

如果图片不只是一段文字，而是包含复杂图表、架构图或者 UI 设计稿，简单 OCR 就不够用了。这种情况下更靠谱的做法是把图片交给视觉能力更强的模型来解读，或者自己搭一个简单的视觉解析服务。

在我自己的项目里，我选择的是把图片转成 base64，再通过 API 调一个支持视觉输入的模型，把返回的文字描述喂给 Claude Code。Python 调用示例大致是：

import base64 import requests def image_to_base64(image_path): with open(image_path, "rb") as f: return base64.b64encode(f.read()).decode("utf-8") # 将 base64 作为请求体的一部分，配合提示词让模型返回结构化描述

这套方案更适合有较多图片处理需求、或者想把图片理解能力沉淀成服务的场景。好处是稳定、可控、可以批量，坏处是需要维护一个 API 服务和对应的 Key，对普通个人项目来说稍微重了一点。

4.4 我推荐的组合方案

我实测下来最顺手的组合是：截图/网图用“原型读取图片路径”，文字密集的抓图用“Python OCR”，架构图/设计稿用“API 视觉解析”。三者并不冲突，可以分别做成一到两个 Skill，Claude Code 会根据任务类型自动选择。如果你嫌麻烦，至少先把“原生路径读取”和“OCR 脚本”配好，这两者能覆盖 80% 的日常需求。

5. 实战组合拳：让 Claude 根据截图和 Skills 完成一个前端页面

5.1 需求描述与图片输入

光讲配置不讲实战等于白讲。我来复盘一个我实际做过的小任务：把一张手画的页面线框图转成一个可运行的 React 页面。

我在 Claude Code 里输入的内容是这样的：

这是一张手画线框图，路径是 ~/Desktop/wireframe.jpg， 请先理解它的布局，然后用项目现有的前端规范实现这个页面。

它先读取了图片，识别出这是一个带顶部导航、左侧侧边栏、中间内容卡片区的典型后台布局。紧接着它自动扫描项目里已有的组件目录，匹配了frontend-component-builder这个 Skill，开始按里面的规则生成代码。

5.2 Claude 调用 Skill 的完整过程与监控

这一步很有意思，你可以看到 Claude 的思考链路：它先描述了图片里的布局结构，然后说“检测到当前项目使用 src/components 组织组件，我将遵循 frontend-component-builder 技能中的模板生成代码”，接着就真的调用了相关模板和组件命名规范。

我在这个过程中盯了两个点：

• 第一，它有没有真的走 Skill 的步骤，还是自己自由发挥。如果它自由发挥，我会用/skills 强制加载 frontend-component-builder手动指定
• 第二，它生成代码后有没有主动跑 lint。Skill 里写了“生成后运行 npm run lint 校验”，但偶尔会有遗漏，需要提醒

5.3 生成结果验收与迭代

页面生成后，我直接让它npm run dev起本地服务，再截图给 Claude 看渲染结果，让它自己对比线框图找差异。这一段“生成→渲染→截图→回传→修改”的闭环，是我觉得 Claude Code 配完图片识别后最值钱的地方。以前要自己截图自己看自己改，现在成了 AI 的自我迭代循环，我只负责做最终验收。

当然也不是一次就完美。第一次生成的页面在间距和字体大小上跟线框图有出入，我直接把渲染截图喂回去，说了一句“左侧边栏宽度偏窄，卡片间距可以再大一点”，它就自己调整了对应样式。

6. 常见问题与排查技巧实录

6.1 Skills 扫描不到

这是我遇到最多的问题。装好技能包后，Claude 半天不识别，对话里问它有哪些技能，它一直回答“我没有额外技能”。

排查步骤按这个顺序来：

• 确认目录位置对不对，Claude Code 默认扫描~/.claude/skills/下的子目录
• 确认每个 Skill 目录下都有SKILL.md，且文件名大小写正确
• 确认SKILL.md开头的 YAML front matter 有name和description，格式用---包裹
• 如果改完还不行，直接重启 Claude Code 会话，有时候是会话缓存导致扫描结果没刷新

6.2 图片路径无法读取

有时把图片路径丢给 Claude，它说“找不到文件”或“无法读取”。常见原因是路径里的特殊字符，比如空格或中文。解决方案很简单：给路径加上引号，或者用相对路径，甚至可以把图片复制到项目目录下再操作。

还有一种情况是图片格式不兼容。Clipping 的截图、webp 格式、某些高分辨率 PNG，在读取时偶尔会出问题。我的处理办法是先用sips（macOS 自带）或 Python 把图片统一转成 JPEG 或标准 PNG 再丢给 Claude。命令行一行就搞定：

sips -s format jpeg input.png --out output.jpg

6.3 OCR 中文识别乱码

遇到中文识别乱码，九成是语言包没装好。tesseract默认只支持英文，要识别简体中文需要额外的chi_sim语言包。macOS 上用 brew 安装后还要确认一下语言包位置，有时需要单独软链。

更隐蔽的问题是，代码截图里混排了中英文和特殊符号，OCR 会把|、>之类的符号识别成I或1。这种场景下只靠 OCR 是不够的，建议先把截图放大再识别，或者配合 Claude 的图片理解能力做二次校正，别把 OCR 结果当最终答案。

6.4 上下文过长被截断

装了 Skills 以后，Claude Code 的上下文占用会明显上升，尤其当你同时装了几十个技能包。遇到“上下文超长”或“回答到一半断掉”的情况，我会做三件事：

• 用/compact压缩当前对话，保留关键信息
• 把已经完成的文件从上下文里移除（用/drop命令）
• 把用不到的大技能包先移出目录，需要时再启用

6.5 一个必须补上的教训

最后说一个让我记忆深刻的坑：有一次花了一个多小时配置各种 Skills，结果发现有个技能的脚本路径写的是~/scripts/run.sh，而实际目录已经改名了，导致 Claude 每次执行都报错“脚本不存在”。

后来我养成一个习惯：写包含脚本的 Skill 时，脚本和 SKILL.md 必须放在同一个技能目录下，并且用相对路径引用。这样无论技能包拷贝到哪台机器、哪个目录，都不会因为绝对路径失效而挂掉。既方便自己迁移，也能直接分享给团队其他人复用。

写在最后的个人体会

配置 Skills 和图片识别这套东西，本质上是在做“提示词资产化”。以前我们写提示词是临场发挥，每次都要重新组织语言；现在把常用的套路、规范、脚本固化成一个一个 Skill，让 AI 每次出手都保持稳定水准，这份积累是会随着时间增值的。

我现在的习惯是：每次遇到重复三次以上的任务，就会停下来想想能不能固化成技能。三个月下来，攒了一套完全属于自己工作流的 Skills，新项目接入 Claude Code 后基本半小时内就能达到“老员工”生产力。这套玩法最迷人的地方在于——它没有上限，你的技能库越厚，AI 在你手里就越强。