企业官网建设流程全解析

Claudeception这个词我第一次看到的时候，第一反应是“套娃”——把Claude Code扔给Claude Code去优化，听起来确实像盗梦空间里的梦中梦。但这个概念真落到项目里，解决的是一个特别朴素的问题：Claude Code每次对话结束之后，经验就丢了，下一次遇到同样的问题，它还会再问一遍、再错一遍。所谓持续学习技能，就是给它装上一套“复盘—提炼—固化”的机制，让每次干活沉淀成可复用的技能文件，下次直接调用。

这篇文章我打算从机制讲到实操，再到CLI和VSCode里的实际用法，分四块：先拆解Claudeception背后的学习闭环，然后说环境怎么准备，接着手把手把“技能工坊”这个学习技能建出来跑一遍，最后是我踩过的坑和常见问题速查表。适合两类人：已经在用Claude Code但觉得它“每次像新朋友”的人，以及想把个人工作流沉淀成技能包、跨项目复用的人。

先说清楚：这不是某个官方按钮，而是基于Claude Code现有机制组合出来的一套工作方法。但只要照着做，技能确实是能长出来的。

1. 先说清楚Claudeception的持续学习闭环

1.1 为什么Claude Code需要“持续学习”这个技能

Claude Code本质上是一个跑在终端里的AI编程助手，能力和背后的模型推理强相关。它最大的短板也在这里：会话之间是彼此孤立的。你今天让它修好了一个诡异的构建报错，明天换个新会话，它大概率还是会先踩一遍同样的坑，再慢慢试出来。时间一长你会觉得，这家伙怎么不长记性。

很多人靠CLAUDE.md来补这个缺口，也就是项目根目录下的长期记忆文件，每次会话自动加载。这个方案有用，但它是静态的：规则需要人手动维护，而且写进去的通常只是“规范”，不是“操作路径”。真正让技能长出来的，是Claude Code的Agent Skills机制。技能文件是带结构化描述的Markdown文档，放在指定目录之后，Claude Code会根据当前任务的语义，自动把匹配的技能加载进上下文。

Claudeception做的事，就是把“写技能”这个动作本身也变成一个技能。让Claude Code定期复盘自己的会话记录，找出高频任务和成功路径，然后自己生成或更新技能文件。这就是持续学习的闭环：干活、记录、提炼、固化，再回到干活。类比一下，相当于你雇了一个永远不离职的助理，每天晚上帮你写工作复盘，再把复盘结论变成第二天的工作手册。

1.2 核心机制：技能目录、SKILL.md与自举循环

要理解Claudeception，得先把技能目录结构摸清楚。个人级技能放在~/.claude/skills/下（Windows是%USERPROFILE%\.claude\skills\），所有项目都能用。项目级技能放在当前仓库的.claude/skills/下，只对本项目生效。每个技能是一个独立目录，里面核心文件是SKILL.md。

SKILL.md的格式不复杂，大致长这样：

--- name: skill-workshop description: 复盘Claude Code会话日志，提炼高频任务并生成或更新技能文件。当用户说“复盘”“技能工坊”“生成技能”时使用。 --- # 技能目标 在这里面写具体的工作流程、操作步骤、示例和注意事项。

关键在于frontmatter里的name和description。Claude Code不是按目录名去找技能的，而是靠description做语义检索。任务描述和技能描述的匹配度越高，技能被加载的可能性就越大。所以description要写清楚“什么条件下触发”“解决什么问题”，而不是吹嘘这个技能多厉害。

自举循环是我一直在用的一个模型，四步走：

1. 执行：正常用Claude Code干活，比如修Bug、写功能、优化构建。
2. 记录：Claude Code每次会话都会在~/.claude/projects/下留下JSONL格式的会话日志。
3. 提炼：让技能工坊去读这些日志，提取“用户确认过的操作”“成功修复问题的路径”“高频出现的任务类型”。
4. 固化：把提炼结果写成新的SKILL.md，或者更新已有的技能文件，下一轮会话就能用上。

注意：技能文件不是越详细越好，而是越“可执行”越好。写过一堆空话的技能，比如“请谨慎思考、仔细检查”，这种内容既浪费上下文，也不会真正改变模型行为。

1.3 适用范围与实际预期

Claudeception这套玩法在几种场景下特别值钱。第一种是长期维护的代码仓库，项目规范多、历史包袱重，技能可以帮你沉淀“这个项目里什么东西不能动、什么地方最容易踩雷”。第二种是重复性操作密集的日常工作，比如频繁发布版本、处理固定格式的日志、做代码审查，技能能把多步操作压缩成一句指令。第三种是技术栈相对固定的开发环境，技能会慢慢积累成你的个人知识库，换个项目也能带走一部分。

但也要泼点冷水：它不适合用来解决实时性极强的任务，比如秒级响应的问题排查；也不适合替代外部数据源查询，这类需求更适合用MCP挂外部工具。技能解决的是“怎么做事”的方法论，不是“能力从哪来”的源头。而且技能的迭代质量取决于复盘频率和数据质量，一周不复盘、不清理垃圾会话，技能库就会长歪。

2. 环境准备与基础配置

2.1 装好Claude Code CLI并验证

Claude Code的主形态是一个命令行工具，安装方式取决于你的包管理环境。最通用的方式是用npm全局安装：

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

装完先验证一下：

claude --version

能输出版本号就说明装好了。如果npm下载慢，可以先把registry切到国内镜像再装：

npm config set registry https://registry.npmmirror.com

装完注意Node版本，建议用Node 20 LTS以上，太老的版本容易遇到兼容问题。不想用npm的话，macOS可以用Homebrew，Windows可以用Scoop，本质都一样。卸载也顺手提一句，npm uninstall -g @anthropic-ai/claude-code就能清掉CLI本体，但用户目录下的技能和配置不会自动删，注意备份。

2.2 配置API密钥与项目记忆文件

安装完成之后，第一件事是配置API密钥。Claude Code读取的是ANTHROPIC_API_KEY这个环境变量。macOS和Linux在shell配置文件里加一行：

export ANTHROPIC_API_KEY="sk-ant-你的密钥"

Windows PowerShell里则是：

$env:ANTHROPIC_API_KEY="sk-ant-你的密钥"

配置完之后最好重新打开终端，让环境变量生效。密钥不要写进项目代码里，更不要提交到Git仓库，这个应该不用多说了。

接着是CLAUDE.md，这个文件放在项目根目录，每次Claude Code在这个目录下启动时都会自动加载。适合放什么？放那些“每轮对话都必须知道”的东西：项目技术栈、启动命令、测试命令、目录结构约定、禁止事项。写成这样：

# 项目约定 - 使用 pnpm 管理依赖，不使用 npm - 测试命令：pnpm test - 组件放在 src/components 下，hooks 放在 src/hooks 下 - 所有新的 API 调用必须加上错误处理

CLAUDE.md不是技能文件，它是静态上下文，承载的是“背景知识”；技能文件承载的是“操作流程”。这两个要分清楚，后面写技能的时候就不会混。

2.3 VSCode集成与终端工作流

Claude Code虽然核心是CLI，但实际干活时我几乎都在VSCode里操作。原因很简单：代码上下文就在编辑器里，切来切去太浪费时间。VSCode里有两个用法，一是装官方Claude Code扩展，界面化操作；二是在内置终端里直接跑claude命令，两个窗口并排，左边代码右边助手。

我更推荐内置终端方案，灵活，而且能直接复用你已经配好的shell环境、项目环境变量和Git信息。打开终端，进入项目根目录，输入claude，它就自动加载当前的CLAUDE.md和匹配的技能文件。

有几个斜杠命令需要先记住：

• /init：让Claude Code根据当前项目结构自动生成一份初始的CLAUDE.md。
• /compact：上下文太长时压缩历史，保留关键信息，腾出空间。
• /clear：清空当前会话上下文，开个干净的新对话。
• /model：切换当前会话使用的模型。
• /permissions：查看和修改权限配置。

熟练用这几个命令，CLI用起来会顺手很多。如果哪天觉得Claude Code行为诡异，先跑/status看一下当前会话状态，再决定是compact还是clear。

2.4 接入第三方模型接口，把成本降下来

很多人想用Claude Code但预算有限，或者希望在某些场景换更轻量的模型。Claude Code本身是支持通过兼容接口接第三方模型的，社区里最常见的就是接DeepSeek。原理很简单：Claude Code通过ANTHROPIC_BASE_URL来定位API端点，你把它指到兼容Claude接口的地址就行。

export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" export ANTHROPIC_AUTH_TOKEN="你的DeepSeek API Key"

然后启动时指定模型：

claude --model deepseek-chat

也可以用ANTHROPIC_MODEL环境变量固定默认模型。社区里常见的ccswitch这类切换工具，本质就是帮你快速改这几个环境变量，来回切换Claude官方模型和第三方模型。

但这里有个实际体会：技能机制在不同模型上的遵循度差别很大。Claude系列模型对技能文件的执行比较稳定，第三方模型有时候会漏掉步骤或者简化操作。所以我的建议是，核心的、需要严格按步骤来的技能场景，尽量用强模型跑；日常的、容错高的杂活可以切到轻量模型，省成本。技能本身要有“人工确认”的安全阀，别让模型全自动改文件。

3. 手把手让持续学习技能跑起来

3.1 设计第一个技能：技能工坊

现在进入正题，建一个名为skill-workshop的技能，让Claude Code能够复盘自己的会话记录、提炼经验、生成新技能。这个是Claudeception的核心发动机。

先明确这个技能的目标：输入是Claude Code的会话日志，输出是新增或更新后的SKILL.md文件。它要做四件事：

1. 读取~/.claude/projects/下的近期会话日志，找到值得复盘的任务类型。
2. 从日志中提取用户确认过的操作序列和成功解决问题的路径。
3. 按照标准的SKILL.md格式，生成一个新技能文件或更新已有技能。
4. 对新技能做一次自检，确保描述和步骤可被后续会话检索、复用。

先在技能目录里建一个文件夹：

mkdir -p ~/.claude/skills/skill-workshop

目录名和技能名都要干脆、表意清晰，别用my-skill-001这种名字，检索的时候很难命中。

3.2 手写SKILL.md：把经验格式化成技能

在~/.claude/skills/skill-workshop/下创建SKILL.md，内容可以参考下面这个版本：

--- name: skill-workshop description: 复盘Claude Code会话日志，提炼高频任务和成功操作路径，生成或更新可用技能文件。当用户说“复盘”“技能工坊”“生成技能”“更新技能”“从会话中学习”时触发。 --- # Skill Workshop ## 目标 把最近的Claude Code会话经验固化为可复用的技能文件，形成持续学习闭环。 ## 工作步骤 1. 读取会话日志： - 进入 ~/.claude/projects/ 目录 - 按文件修改时间倒序排列，优先读取最近3个会话日志 - 日志是JSONL格式，逐行解析 2. 提取有效信息： - 标记用户最后确认采纳的操作步骤 - 记录成功修复Bug的完整命令序列 - 记录被用户纠正过的高频错误，写入注意事项 - 统计同一类任务出现的次数 3. 归纳技能点： - 当一个任务类型出现2次以上，并且有明确的成功路径，判定为可固化技能 - 提取共性步骤，删除项目特定路径，保留通用逻辑 4. 生成或更新技能文件： - 新技能：在 ~/.claude/skills/<skill-name>/SKILL.md 中创建 - 已有技能：合并新的有效步骤到旧文件，不删除原有内容 - description只描述触发场景和解决的问题，不写赞美性语言 - 正文使用可执行步骤、具体命令、真实示例 5. 自检： - 确认技能目录名称与name字段一致 - 确认description不超过100字且核心词前置 - 新技能先以 .new 后缀存放，人工确认后再覆盖正式文件 ## 注意事项 - 不生成与已有技能description高度重叠的新技能，应合并 - 不把项目私有信息写进个人级技能，注意脱敏 - 技能正文不要写“请谨慎思考”这类空话，要写具体操作

这个文件本身就是Claudeception的“种子”：它告诉Claude Code怎么去学习。写完保存之后，技能已经可以被检索了。你可以先跑一个简单测试，输入“生成一个git提交信息规范化技能”，看它是否会主动用skill-workshop里的方法去复盘并生成新技能。

3.3 让学习闭环跑起来：CLI实操记录

技能文件只是静态文本，关键在于闭环跑起来。拿我前阵子做的一个前端项目举例，项目里频繁出现一个重复劳动：每次改动组件后都要手动更新storybook测试用例，格式固定但容易忘。

我在终端里跑claude，会话中说了一句：“复盘一下最近的会话，把更新storybook用例的流程做成技能，下次直接调用。”这个指令就触发了skill-workshop。

Claude Code先读取了~/.claude/projects/下的会话日志，从中找到三次改组件后补storybook的操作记录，提取出共同的步骤序列：检查组件props变更、定位对应story文件、按新API更新控件、跑测试命令、确认快照。然后它把这些步骤写成了一个新的SKILL.md，放到~/.claude/skills/storybook-updater/下。整个过程不到两分钟。

为了确认技能真的被加载，我建议开启debug模式观察：

claude --debug

在debug输出里，你会看到Claude Code加载了哪些技能文件。如果日志里出现了Loaded skill: storybook-updater，说明技能被命中。没有出现的话，多半是description里的关键词和你的实际表述不匹配，去调整描述词就行。

提示：新会话里测试技能效果时，尽量用一句自然、真实的任务描述，不要用“请使用storybook-updater技能”这种命令式表述。技能加载是基于语义匹配的，你的任务越自然，越能验证描述写得好不好。

3.4 把反馈固化到CLAUDE.md：第二层记忆

技能文件负责“怎么做”，CLAUDE.md负责“项目里有什么约定”。在Claudeception的体系里，这两层要配合起来用。技能提炼的是通用经验，比如“组件变更后必须同步更新storybook”；但每个项目跑测试的命令不一样，有vitest、jest、playwright等等。这时候项目级的CLAUDE.md就发挥作用了：它告诉Claude Code“本项目的测试命令是pnpm test:storybook”，技能里的步骤只需要写“运行测试命令验证”，实际命令由CLAUDE.md补全。

所以我在每次复盘之后，还会让Claude Code顺手检查一下CLAUDE.md有没有过时信息。比如项目从npm切到了pnpm，CLAUDE.md里还写着npm run test，那后面所有依赖这个信息的操作都会出错。把“检查CLAUDE.md与当前项目状态一致性”也写进skill-workshop的步骤里，这样每次复盘都会顺带修一遍静态文档。

这两层记忆的分工可以这么理解：CLAUDE.md是项目的“宪法”，变更频率低，稳定性高；技能是“操作手册”，迭代速度快，可跨项目复制。持续学习的关键不只是不停地写新技能，还要定期清理、合并、修正旧技能和旧文档，不然知识库会越来越臃肿。

4. 进阶技巧与常见问题排查实录

4.1 进阶：多技能联动与优先级管理

技能数量超过十几个之后，会出现一个很实际的问题：技能之间互相打架。比如我同时有“代码审查技能”和“安全扫描技能”，它们都可能在用户说“检查一下代码”时被加载，导致上下文被占满，输出内容混杂。

解决思路是给技能建立目录分层，按职责归类：

~/.claude/skills/ ├── core/ # 核心通用技能：git操作、代码审查、重构 ├── review/ # 专项检查：安全、性能、兼容性 ├── daily/ # 日常杂务：日志分析、storybook更新 └── workshop/ # 技能工坊本身

虽然Claude Code会扫描整个skills目录，但目录分组能让你自己维护起来清晰很多。更重要的是，技能description要设计好“互斥”的关键词：审查技能描述里写“代码逻辑、可维护性、命名规范”，安全技能描述里写“漏洞、敏感信息、依赖风险”。这样同一个任务描述只会精准命中其中一个。

再进一步，可以把技能和MCP配合使用。技能负责编排流程，比如“检测到异常日志就去复盘”，MCP负责实际读取外部数据源，比如数据库、监控系统、Git远程仓库。技能管方法，MCP管能力，两者不冲突。

技能文件本身也应该纳入版本管理。我的做法是：

cd ~/.claude/skills git init git add -A git commit -m "feat: 添加storybook-updater技能"

每次技能变更都能回溯，出问题直接回滚，比手动复制备份靠谱得多。

4.2 常见问题速查表

实操Claudeception过程中，有几个问题反复出现，整理成一张表方便排查：

排查技能问题时，我建议第一条路永远是开debug模式，看日志里技能是否被加载。有时候你以为技能没生效，其实是描述没匹配上；有时候技能生效了但行为不对，那是技能正文写得不够具体。这类问题靠猜效率很低，看日志最直接。

4.3 我在实操中踩过的坑与心得

第一个坑是技能description写得太“大”。最早我写了一个“全能助手”技能，描述涵盖了代码、运维、写作，结果任何对话都会把这一大坨内容加载进去，浪费了大量上下文，还干扰了模型对当前任务的判断。后来我把description拆细，只保留触发词，比如“成对出现”“只有数据库迁移时使用”，加载效果立刻精准了。

第二个坑是技能正文写成了“方法论散文”。第一版技能文件里写了很多“应该充分理解需求、应该保持代码整洁”这类话。模型看了等于没看，该犯的错还是犯。改成可执行列表之后，比如“先运行git status检查工作区，再运行pnpm test确认基线”，技能才真正有了约束力。

第三个坑是让Claude Code直接覆盖技能文件，导致一次复盘把好端端的技能改坏了。后来我定了规矩：所有自动生成的技能文件一律先存成SKILL.md.new，人工确认后再改名覆盖。这个流程虽然多了一步，但大大降低了失控风险。

个人经验是，Claudeception的价值不在于一次生成一个完美技能，而在于日拱一卒的积累。我每周让Claude Code做一次全局复盘，把本周的高频操作、踩坑记录、修正方案全部过一遍。三个月下来，技能库从最初的3个长到了20多个，而且大部分都是真实项目里验证过、持续修正过的，不是凭空写出来的理想流程。现在开新项目，很多事情真的不需要从头教起，旧项目的成功路径直接就能复用过来，这大概就是“持续学习”最实在的回报。

最后分享一个小习惯：每次新技能通过验证之后，我会顺手在技能文件的末尾补一段“实际使用案例”，写上触发场景、预期输出、真实输出差异。这些案例是后续调试技能的重要依据，也方便其他人接手维护。技能库会越用越顺手，前提是你把它当成一个需要持续打理的东西，而不是写完就扔。