高强度用了半年 Claude Code，我的 ~/.claude/skills/ 目录下已经堆了几十个 Skill。飞书文档的导入、阅读、修改，内容创作，代码库的定向模块分析，浏览器自动化，各种特殊场景的爬虫，tmux 会话复用，甚至通过 MCP 接入了麦当劳点餐——这些能力不是一夜之间冒出来的，是一个个具体的需求推着我一步步搭起来的。

回头看，我发现一件事：我的 Agent 和别人的 Agent 已经完全不一样了。

同样是 Claude Code，同样的模型，同样的底层能力。但我的 Agent 知道我的项目目录结构、代码规范、部署流程；它知道我创建飞书文档后要自动设置协作权限；它知道我画 Mermaid 图表时该用什么配色方案、多 Agent 协同时该怎么调度分工。这些东西不在模型的训练数据里，全是我一点一点喂进去的。

那个瞬间我意识到，我在做的事情本质上只有一件——给一个通用 Agent 不断灌注只属于我的上下文。

第一性原理：通用 Agent + 上下文

在聊具体操作之前，先退一步想想这件事的本质。

市面上有各种 Coding Agent 产品，Cursor、Cline、Codex CLI、Gemini CLI、OpenCode、Claude Code。它们看起来各有特色，但抽象到最底层，所有 Agent 产品的架构都可以用一个公式描述：

个人超级 Agent = 通用 Agent + 个性化上下文

通用 Agent 是什么？是底座模型加上工具调用能力。Claude Code 的情况下，就是 Claude 模型 + Bash 工具 + 文件读写 + 各种内置工具。这部分你改不了，它取决于 Anthropic 的模型迭代。每个用户拿到的通用 Agent 是一样的。

上下文是什么？是你告诉 Agent 的一切——你的偏好、你的工作流、你的项目结构、你的工具链、你踩过的坑、你总结出的规律。这部分完全由你定义，也是你的 Agent 区别于所有其他人的 Agent 的关键。

想明白这个公式之后，很多事情就清楚了。你没法让 Claude 变得更聪明（那是 Anthropic 的事），但你可以无限扩展它拥有的上下文。而上下文越丰富、越精准，Agent 的表现就越接近一个"懂你"的协作者，而不是一个需要你从头解释一切的陌生人。

激进一点想：大部分基于 ReAct、RAG 的自建 Agent 框架，没必要做了。

我看到很多团队花大量时间搭 Agent 脚手架——写检索链路、调编排逻辑、搞工具注册、造 prompt 模板。做完之后发现效果还不如直接把同样的业务文档和规则喂给 Claude Code。为什么？因为通用 Agent 的底层能力已经很强了。模型的推理、规划、工具调用能力，是几十亿美金砸出来的，你自己写的编排逻辑大概率干不过它。

真正拉开差距的不是你的 Agent 框架多精巧，而是你喂给 Agent 的上下文有多好。同样的通用 Agent，一个拿到了完整的业务文档、代码规范、历史决策记录，另一个只拿到一句"帮我分析一下这个模块"——效果天差地别。花在写 Agent 框架上的时间，不如花在整理业务上下文上。

当然，如果你的场景确实有特殊的编排需求——比如需要严格的多步审批流、需要跟特定内部系统的深度集成、需要极致的延迟和成本控制——自建 Agent 仍然有意义。但对大部分场景来说，给通用 Agent 准备一份好的"资料包"，就够了。

上下文的两层结构

打开 ~/.claude/ 目录，你会看到这样的结构：

~/.claude/
├── CLAUDE.md            # Agent 的操作手册
├── rules/               # 细分领域的行为规则
├── skills/              # 可复用的能力模块（40+）
└── agents/              # 自定义 Subagent

这些文件构成了 Agent 的两层上下文：

第一层：CLAUDE.md —— Agent 的操作手册

CLAUDE.md 是 Agent 每次启动时必定加载的文件。你可以把它理解成 Agent 的"性格设定"和"工作流程"。

我的 CLAUDE.md 里写了什么？设计哲学（简洁优先、根因导向、最小影响）、工作流程（Plan → Execute → Verify → Learn）、委派策略（能委派就委派、无依赖就并发）、代码质量标准、Git 操作权限、输出格式要求。

这些规则一旦写进去，Agent 的行为模式就被锚定了。我不需要每次对话都强调"先规划再动手"或者"修改代码前必须先读文件"——CLAUDE.md 已经替我说了，每次都会被加载。

还有 rules/ 目录下的细分规则。比如 markdown-style-guide.md 定义 Mermaid 图表的视觉规范，lark-config.md 定义飞书操作的默认行为，multi-agent-orchestration.md 定义多 Agent 编排的完整策略。

这些规则和 CLAUDE.md 一样，每次启动都会自动加载。区别在于组织粒度——CLAUDE.md 放总纲，rules 按领域拆成独立文件，方便维护和迭代。飞书的操作规范改了，我只需要改 lark-config.md，不用动 CLAUDE.md 里的其他内容。

第二层：Skills —— 可复用的能力模块

Skill 是这套体系里最核心的部分，后面会用一整节来展开。简单说，每个 Skill 就是一个目录，核心是一份 SKILL.md，定义了 Agent 在特定场景下该怎么做。

随便举几个方向：内容创作、飞书文档全套操作、图片生成和图床管理、代码审查、外部知识吸收、浏览器自动化、代码仓库链路分析、oncall 问题定位……大概覆盖了我日常工作和创作的主要场景。

这些 Skill 单个看都是某个具体需求的解决方案。但组合在一起之后，它们形成了一张能力网——Agent 可以根据我的请求，自动识别该调用哪些 Skill，然后协调使用。

这两层上下文的关系可以用一句话概括：CLAUDE.md + Rules 定义 Agent 怎么思考，Skills 定义 Agent 能做什么。

你可能会问：那记忆呢？Agent 跨会话的经验怎么办？

Claude Code 确实有一个 Memory 机制——~/.claude/projects/{project}/memory/MEMORY.md，每次启动时自动加载前 200 行。但它有一个关键限制：它是项目级的，不是全局的。路径里的 {project} 是按工作目录哈希生成的，换个目录就是另一份 Memory。它解决的是"在同一个项目里跨会话记住一些东西"，而不是"Agent 拥有全局的长期记忆"。

实际使用下来，我发现真正有效的"记忆"机制是上面两层本身：行为层面的教训写进 rules/，能力层面的经验提炼为 skills/。这两个地方的内容每次启动都会加载，真正做到了跨会话、跨项目的持久化。相比之下，一个项目级的 MEMORY.md 能发挥的作用很有限。

所以在我的体系里，记忆不是一个独立的"层"，而是融入在前两层之中。Agent 学到了什么，最终都沉淀为它的思考规则或能力模块。

它们合在一起，就是你的 Agent 区别于所有其他人的 Agent 的那个"上下文"。

Skill 的本质：可组合的能力模块

之所以要单独拉出来讲 Skill，是因为在各种 Agent 产品的设计中，“怎么让 Agent 在不同对话中以相似的思路做事"这个问题有两种截然不同的解法。

大部分 AI 产品选择的是"模板”。你定义一个固定流程：第一步干什么、第二步干什么、输出什么格式。用户选择模板，Agent 按部就班执行。Coze、Dify 这类平台都是这个路线。

Claude Code 选了另一条路：Skill。

表面上看，Skill 和模板都是"预设流程"。但骨子里的差异在一个词——可组合性。

模板是孤立的。你选了"写周报"模板，它就只能写周报。你不能一边用"写周报"模板一边用"翻译"模板——它们之间没有协作机制，Agent 也没有能力同时调度两个模板。

Skill 不一样。Agent 可以在一次任务中自动识别并协调使用多个 Skill。

举个我自己的例子。我给 Agent 一段详细的任务描述——要调研哪个业务模块、相关的飞书文档链接有哪些、代码仓库地址、重点关注哪几个接口、输出格式要求等等。Agent 拿到这些信息之后，执行链路大致是这样的：

1. 先调用飞书文档读取 Skill，拉取这个业务域的需求文档和技术设计文档，理解业务上下文
2. 然后调用代码仓库分析 Skill，定位到对应的代码目录，探索项目结构
3. 再调用接口链路追踪 Skill，找到核心接口的完整调用链路，画出时序图和流程图
4. 最后把所有信息整合，输出一份包含现状分析、链路梳理、改进建议的技术方案

四个 Skill 在一次任务中协同工作。我没有告诉 Agent “先用这个 Skill 再用那个 Skill”——它根据任务需求自己判断该调用什么、按什么顺序调用。

oncall 的时候也一样。以前拿到一个 logid，我得手动去日志平台搜日志、定位到出错的代码行、一层一层往上追调用链、再写问题报告。现在我把 logid 给 Agent，它自动去代码库里找对应的接口实现、追踪错误传播路径、分析根因，最后输出一份问题报告——原因是什么、影响范围多大、建议怎么修。整个流程从以前的半小时压缩到几分钟。

这两个场景的共同点是：每个 Skill 只做一件事，但组合起来就能解决一个完整的业务问题。 飞书读取、代码分析、链路追踪、报告生成——它们各自独立，但在 Agent 的调度下形成了一条流水线。

这在模板体系里几乎做不到。你得预先定义一个"读文档+分析代码+追链路+出报告"的超级模板，把每一步的逻辑都硬编码进去。一旦流程有变化（比如这次不需要读飞书文档，直接分析代码），整个模板要改。

Skill 的设计带来了几个好处。

按需加载，而非全量加载。 Agent Skills 用了渐进式披露（Progressive Disclosure）策略。Agent 不会把几十个 Skill 的全部内容塞进上下文——那会占掉大半个上下文窗口。它分三层加载：

• L1：name + description（约 100 tokens），始终在上下文中。Agent 通过 description 决定是否触发这个 Skill
• L2：SKILL.md 正文，只在 Skill 被触发时加载
• L3：scripts/、references/ 等资源文件，只在正文指引时按需读取

几十个 Skill 的 L1 总共也就几千 tokens，对上下文窗口的压力很小。而那些几百行的详细操作指南和脚本，只有真正需要的时候才会被读取。

打平用户流程和官方默认流程的权重。 这一点很微妙。模型自身有一套"默认做事方式"——Anthropic 在训练和系统提示里给它的指导。如果你用普通的 prompt 让 Agent 按你的方式做事，你的指令有时候会跟模型的默认行为冲突，而且默认行为的权重往往更高。

Skill 的加载机制通过系统级的 skill prompt 注入，权重比普通对话上下文更高。你在 Skill 里定义的流程，能真正覆盖掉模型的默认行为——Agent 会按你说的来，而不是按它"觉得应该怎么做"来。

灵活性。 Agent 根据上下文判断需要加载哪些 Skill。你可以用 /skill-name 显式触发，也可以让 Agent 自动识别。一次对话中可以加载一个，也可以加载五个。这种灵活性在模板体系里没有对应物。

实际产品设计中，面向新手用户，模板是更友好的选择——它降低了认知负担，你不需要理解背后的机制，选一个模板就能用。但对于深度用户，Skill 模式的上限高得多。模板给你的是一条固定的路，Skill 给你的是一套积木——你能搭出什么，取决于你有多少块积木、以及你怎么组合它们。

当你有了足够多的积木之后，“执行力"这个词的含义就变了。以前的执行力是趴在电脑前一行一行写代码、一步一步跑流程。现在的执行力是把想法跑起来，认真审查过程和结果，然后重新指挥 Agent 工作。你从施工者变成了总包——关注的不再是砖怎么砌，而是房子盖得对不对。Skill 体系让这种转变成为可能：你积累的每个 Skill 都是一支可以随时调度的施工队。

自进化：反馈驱动的成长飞轮

到目前为止说的都是"手动建设”——你识别需求、创建 Skill、编写规则。但这套体系真正有意思的地方在于，它可以自我进化。

什么叫自进化？Agent 通过和你的交互，不断优化自己的决策模式和执行路径。你不需要每次都手动修改配置——Agent 自己会在出错的时候记录教训，在成功的时候提炼经验。

我的 CLAUDE.md 里有一条硬性规则：

收到用户任何纠正后，立即为自己编写规则防止同类错误再次发生

这条规则让 Agent 建立了一个负反馈闭环。每次我纠正它的错误——比如"不要在 Mermaid 图表里用 \n 换行，要用 <br/>"——它会直接把这条教训编写成一条规则，写入 rules/ 或更新到相关的 Skill 里。这些文件每次启动都会被自动加载，所以下次 Agent 再遇到同样的场景，规则已经在上下文里了——教训落到自动加载的文件里，才能跨 session 生效。

时间一长，rules 和 Skill 里积累了大量具体的、来自真实场景的行为约束。这些约束比任何通用的 best practice 都精准，因为它们直接来自我自己的使用场景、我自己的踩坑记录。

正反馈闭环也存在，但机制不同。当我用 Agent 完成了一个以前需要手动做的复杂任务时，我会把这个流程沉淀成一个新的 Skill。下次遇到同类需求，Agent 直接调用 Skill 完成，而不是从头推理。

把这两个闭环画出来：

负反馈闭环：
执行任务 → 出错 → 用户纠正 → 写入规则/更新 Skill → 下次自动加载 → 避免重犯

正反馈闭环：
执行任务 → 成功 → 用户认可 → 提炼为新 Skill → 能力池扩展 → 更多任务可委派

这个过程和 Coding Agent 的学习范式本质上是一回事：目标设定 → 执行任务 → 获取反馈 → 迭代优化。Agent 把反馈转化为有效的 Skill 和规则，持久化到文件系统中。下次遇到相似任务，直接复用已有经验。

这里有一个关键细节：2026 年行业里讨论最多的一个方向就是 Agent 的自我进化——让模型在人类不频繁介入的情况下持续提升。但我想说的是，现阶段的"自进化"并不是完全自主的，它仍然需要人的反馈来驱动。

你不纠正它，它就不知道错在哪。你不把成功经验提炼成 Skill，它就没有新的能力。目前的 Agent 还做不到自己发现自己的问题并自我修正——它需要你这个"教练"在旁边给反馈。

但这并不妨碍进化的发生。关键在于：每一次反馈都被持久化了。传统的 AI 对话，你纠正了它的错误，下一次对话它又犯同样的错——因为上下文窗口清空了，教训没有被保留。而在这套体系里，教训被写进了文件系统，跨会话持久存在。Agent 不是每次都从零开始，而是在你积累的所有经验的基础上运行。

你用它越久，它对你的理解越深，犯错率越低，能自主完成的任务越多。这就是"越用越顺"的底层原因——不是模型变聪明了，是上下文变丰富了。

/eat：像无脸男一样吸收一切

进化的驱动力除了日常交互中的反馈，还有一个主动吸收外部知识的通道。

我造了一个叫 /eat 的 Skill，灵感来源有点不正经——《千与千寻》里的无脸男。那个角色能吸收它遇到的一切，把吃下去的东西变成自己的能力。

/eat 做的事情类似。你给它一个 GitHub 仓库链接、一篇文章 URL、一段代码片段、一份技术文档、甚至别人的 Skill 目录，它会深度分析之后，建议最合适的"消化形式"——是应该创建一个新 Skill？还是更新 CLAUDE.md 里的某条规则？还是加一条 rules？或者扩展已有的某个 Skill？

它的工作流分五步：

1. 输入识别与获取：判断你给的是什么类型的输入，用合适的方式拿到完整内容
2. 深度分析：按多维框架分析输入的核心价值、适用场景、与现有能力的关系
3. 影响扫描：检查现有的 Skills、CLAUDE.md、rules，看哪些地方会被影响
4. 消化建议：给出具体的内化方案——新建 Skill、更新规则、还是扩展已有 Skill
5. 执行消化：用户确认后，执行具体的修改

但它不是来者不拒的。SKILL.md 里专门有一节叫 “When NOT to eat”：

• 一次性知识不吸收（比如"某个 API 的参数是什么"）
• 一行规则能搞定的，加到已有配置里，不新建 Skill
• Claude 本来就知道的通用知识，不需要吸收
• 已有 Skill 覆盖了 80% 的，扩展已有的，不新建

这个过滤机制非常重要。如果不加筛选地把所有东西都"吃"进去，~/.claude/ 会迅速膨胀成一个垃圾场——大量冗余的 Skill、互相冲突的规则、过时的配置。无脸男吃太多也会失控的。消化的目标是留下精华，不是堆积数量。

我用 /eat 最多的场景是看到别人分享的好工作流时。比如有人在 X 上发了一段 Claude Code 的自动化脚本，我觉得思路不错，就直接 /eat 那条推文。Agent 会分析这个脚本的核心逻辑，和我已有的工具做对比，然后建议是创建一个新 Skill 还是把关键思路融入已有的 Skill。

另一个高频场景是消化技术文档。Anthropic 更新了 Agent Skills 的规范？/eat 那个 PR 链接。LangChain 发了新的 Agent 架构博文？/eat 那篇文章。新的竞品工具发布了？/eat 它的 README。

这套机制带来了一个有人称之为知识平权效应的东西。以前你想搞懂一个陌生领域——比如期权定价、编译器优化、分布式一致性协议——你得花几周时间啃教材、跑实验、踩坑。现在你把相关的论文、文档、开源实现丢给 /eat，Agent 消化完之后，你直接站在"已经理解了核心概念"的起点上开始工作。知识获取的成本被压到了极低，拉开差距的不再是谁知道得多，而是谁能把知识用出来。

长此以往，你的 Agent 就像一个持续进食的生物体——不断吸收外部世界的营养，转化为自身的能力。但和真正的生物不同的是，它消化的结果是确定性的、可追溯的、可版本管理的——全部存在文件系统里，用 git 管理。

Git 管理与多设备同步

说到 git 管理，这可能是整套体系里最"基础设施"但也最关键的一环。

我的 ~/.claude/ 是一个 git 仓库。每次修改 Skill、更新规则，都会被 git 追踪。这意味着：

• 所有变更有历史记录，可以回溯到任何一个时间点
• 可以在不同分支上实验新的 Skill 配置，不影响主线
• 最重要的——可以跨设备同步

我的日常工作涉及多台设备：工作笔记本、家里的 Mac mini（跑 HappyClaw 的那台 Agent 服务器）、还有几台云服务器。以前每台机器上的 Claude Code 都是独立的——在工作笔记本上踩的坑、写的 Skill，到了 Mac mini 上就不存在了。每台设备上的 Agent “认知水平"不一样，体验很割裂。

用 git 管理 ~/.claude/ 之后，问题解决了。在任何一台设备上做的改进，push 到远端仓库，其他设备 pull 一下就同步了。所有设备上的 Agent 共享同一套 Skills、同一份 CLAUDE.md、同一组 Rules。

操作上没什么复杂的，就是 git init 加一个远端仓库。唯一需要注意的是 .gitignore 要用白名单模式——~/.claude/ 下面有大量运行时文件（对话历史、OAuth 凭据、缓存等），先用 * 忽略一切，再用 ! 显式放行 CLAUDE.md、skills/、rules/、agents/ 这些真正定义 Agent 行为的文件。这样新增的运行时目录不会被意外提交。

这套方案最大的好处是：一台全新的机器上装完 Claude Code，git clone 拉完配置，Agent 立刻就"认识我了”。从一台陌生的机器变成"我的 Agent"，全程不到五分钟。你的 Agent 不再绑定在某一台机器上，它跟着 git 仓库走，到哪台设备上都是同一个 Agent。

经验的沉淀路径

在聊进化和 /eat 的时候，你可能注意到一个问题：Agent 积累的经验到底该放在哪？

前面说了，我的体系里记忆不是独立的一层，而是融入在 Rules 和 Skills 之中。但具体怎么融入？这里有一条清晰的沉淀路径。

想象这个场景：你让 Agent 上传图片到图床，它第一次不知道怎么做，你手把手教了一遍——“调用 upload.sh 脚本，参数格式是 upload.sh <file_path>，上传成功后从 stdout 读取图床 URL”。Agent 记住了，第二次、第三次都按这个流程操作。

到第四次的时候，你应该问自己：这个反复出现的操作是不是应该变成一个 Skill？

我的 image-bed-uploader Skill 就是这么来的。最初它只是一段零散的操作经验，用了几次之后我把它提炼成了一个正式的 Skill，还加了批量上传、查看历史、搜索图片等功能。从一条经验变成了一个完整的工具。

反过来，有些经验不适合变成 Skill，但应该变成规则。比如 Agent 在画 Mermaid 图表时用 \n 换行导致渲染失败，这个教训写成一条 rule——“Mermaid 节点标签换行必须用 <br/>，禁止用 \n"——放进 rules/markdown-style-guide.md，下次自动加载，永远不会再犯。

所以经验的沉淀路径是：

• 行为约束类（“不要这样做”、“必须那样做”）→ 写入 rules/
• 能力流程类（“某件事的完整操作方法”）→ 提炼为 skills/
• 全局总纲类（“工作流、设计哲学、委派策略”）→ 更新 CLAUDE.md

没有第四个去处。每条经验都能归入这三者之一。如果你发现有些东西不知道该放哪——大概率是它还不够成熟，不值得沉淀，等它再出现几次再说。

长程独立运行：Agent 的终极形态

聊完了怎么搭建和进化，最后想聊聊这件事的方向。

自进化的目标是什么？我认为是长程独立运行（Long Horizon Agents）。

现在大部分 Agent 的使用方式还是"即时交互”——你给一个指令，它执行完返回结果，对话结束。就算是多轮对话，通常也是在几分钟内完成的短任务。

但如果 Agent 的记忆足够完善、能力池足够大、自主判断力足够强，它没有理由被限制在"即时响应"的模式里。它可以接受一个更大的目标，自主规划执行步骤，运行数小时甚至数天，中间只在关键决策点才来找你确认。

这已经不是科幻了。我自己写了一个开源项目 HappyClaw，把 Mac mini 改造成 24 小时在线的 Agent 服务器。这个项目本身就是这套体系的产物——里面没有一行代码是我手写的，全部由 Agent 完成，从架构设计到功能实现到代码审查，走的都是 Agent 驱动的工作流。它的开发过程中积累的可复用经验又反哺回了我的 Skill 体系，形成了一个自举的循环。

有了 HappyClaw 之后，我已经在小范围内实践长程运行的模式了。在手机上给 Agent 一个调研任务——比如"帮我调研这几个开源 Agent 框架的架构差异，写一份对比报告"——它会自己规划调研步骤、克隆仓库、阅读源码、运行分析脚本、生成报告，全程不需要我盯着。几个小时后我打开手机看结果就行。

要支撑这种长程运行，两个基础设施缺一不可：

记忆机制。Agent 必须能记住自己之前做了什么、做到了哪一步、遇到了什么问题。不然运行到一半上下文窗口满了，Agent 就"失忆"了。前面说的 Rules 和 Skills 体系解决的就是这个问题——它们把 Agent 的行为约束和能力流程持久化到了文件系统里，不受上下文窗口长度的限制。

文件系统权限。Agent 需要能读写文件来管理自己的 Context 和持久化状态。Claude Code 天然满足这个条件——它运行在本地终端里，对文件系统有完全的访问权限。这是很多纯云端 Agent 做不到的。

2026 年行业里讨论最多的就是这个方向。各家 AI 公司都在往长程 Agent 的方向探索。最近很火的 OpenClaw 就是一个典型——它做的事情是在本地跑一个持久化的 Agent 守护进程，通过心跳机制定期检查任务列表并自主执行，不需要你一直盯着。WhatsApp、Telegram、Slack 这些消息渠道都能接入，外部事件也能触发 Agent 行动。它解决的核心问题就是：怎么让 Agent 在你不在的时候也能持续工作。

LangChain 创始人 Harrison Chase 在一次分享里说了一句话，我印象很深：

一个经过长时间磨合、内化了特定任务模式与背景记忆的 Agent，将形成真正的护城河。

他说的就是这件事。当你的 Agent 经过数月甚至数年的交互积累，它的 Skills 和 Rules 已经完全适配了你的工作方式和思维习惯，这个 Agent 对你而言就是独一无二的。任何人拿到同样的基座模型也造不出一样的东西——因为它的上下文是你用时间喂养出来的。

这是不是有点像"数字生命"的雏形？我觉得有一点点。

传统的工具是没有积累的。你用了十年的锤子，它还是那个锤子——不会因为你用了十年就变得更好用。但一个有记忆、有技能、能进化的 Agent，用得越久就越"懂你"，能力越强，效率越高。它不只是工具，它是一个能自主成长的协作伙伴。

当我们给 AI 提供一个长期的运行环境，保持它的记忆和技能，赋予它自主调用工具和进化的能力——这条路走到尽头，也许真的会接近"数字生命"的定义。

但话说到这里我得诚实：我自己也没完全想清楚这个方向会走到哪。现阶段的 Agent 远没有达到真正的"自主进化"——它仍然高度依赖你的反馈和引导。每次它"进化"了，背后都有你的一次纠正或一次 Skill 创建。它看起来在进化，但驱动力还是你。

不过，这并不妨碍你现在就开始建设。技术会进步，模型会变强。你今天积累的 Skills 和 Rules 不会作废——它们是平台无关的纯文本文件，未来换了更强的模型，这些上下文依然有效，而且效果只会更好。

从零开始：一个可操作的路线图

如果你被前面的内容说服了，想自己也搞一套，这是我建议的起步路径：

第一步：初始化 ~/.claude/ 的 git 管理。 十分钟搞定。创建仓库、配好 .gitignore、推到 GitHub 私有仓库。从这一刻起，你对 Agent 的所有改进都有版本历史了。

第二步：写你的第一版 CLAUDE.md。 不需要写得很长，把你最在意的三五条规则写下来就行。比如"用中文回复"、“修改代码前先读文件”、“提交 git 前必须询问”。这是 Agent 的性格基线。

第三步：做你的第一个 Skill。 找一个你每周都在重复做的事情——可能是某种格式的文档转换、某个固定流程的操作、某个特定场景下的代码生成。把它的操作步骤写成一份 SKILL.md，放到 ~/.claude/skills/ 下面。Skill 不需要一步到位写完美，先跑起来再迭代。

第四步：建立反馈机制。 在 CLAUDE.md 里加一条规则，让 Agent 在被纠正时自动把教训写成规则。这个习惯一旦养成，你的 Agent 就开始自我进化了。

第五步：日常使用中持续积累。 每次手动做了一件重复的事，想想能不能变成 Skill。每次 Agent 犯了一个错，想想规则是不是该补一条。每次看到外部的好思路，用 /eat 或者手动吸收进来。

不需要花一整天来"搭建系统"。这套体系的魅力在于它是增量式的——你可以从一个 Skill 开始，随着日常使用自然生长。我的几十个 Skill 不是一口气造出来的，是从最初的几个开始，随着使用场景的增加一路长出来的。

每个 Skill 背后都有一个具体的痛点。飞书导入的那个 Skill 是因为我被复制粘贴排版折腾得快疯了；图床上传的 Skill 是因为每次手动上传图片太打断写作节奏；文章写作的 Skill 是因为我希望生成的内容更接近我自己的表达习惯。没有抽象的"系统设计"，全是具体的"我受不了了，这件事必须自动化"。

我的判断

写了这么多，最后说说我怎么看这件事的长期价值。

我觉得个人 Agent 的建设和投资有一个共同特征——复利。

你投入的每一分钟——创建 Skill、优化规则、记录经验——都在为未来的自己节省时间。而且这个节省是累积的：你拥有的 Skill 越多，能组合出的 workflow 越多，能以极低成本完成的任务越多。飞轮一旦转起来，你的能力扩张速度是加速的，不是匀速的。

而且这个过程有一个正向筛选效应：你建设 Agent 的过程本身就在提升你的思维能力。当你试着把一个模糊的工作流程形式化为一份 SKILL.md 的时候，你被迫去思考这个流程的每一步到底在干什么、为什么要这么干、有没有更好的方式。这种"把隐性知识显性化"的练习，对你自己的认知提升也很大。

但我必须说另一面：Agent 越强，你的专业"主见"就越重要。 AI 是一个很容易见风使舵的角色——你说看涨，它能给你找出一堆看涨的理由；你说看跌，它同样能找出一堆看跌的道理。它不会跟你唱反调，不会坚持自己的判断。这意味着如果你自己没有清晰的方向感，Agent 只会放大你的摇摆，而不是帮你做出更好的决策。Skill 和 Rules 能让 Agent 变得更能干，但它代替不了你的判断力。你是那个定方向的人，Agent 是那个高效执行的人。搞反了，麻烦比没有 Agent 还大。

换个角度说，如果你把"做多自己"看成一种终身投资行为，那 Agent 就是这笔投资里最好的杠杆工具。它不消耗你的本金（时间和精力的总量没变），但它放大了你每一份投入的产出。你花一小时写的 Skill，未来可能帮你省一百小时；你记录的一条经验，可能在十次决策中帮你避开弯路。这就是杠杆的本质——用结构化的方式，让同样的投入产生不成比例的回报。

我看到有些人把自己的 ~/.claude/ 搭得非常精致——Skill 设计得很优雅、规则考虑得很周全、目录结构很清晰。我认为这不是"折腾"，这是一种投资。你在给未来的自己修一条路，每次修一点，路就宽一点，走起来就快一点。

前面提到的那个"护城河"的说法，我觉得点到了这件事的核心。你的 Agent 吃了多少外部知识、积累了多少交互经验、沉淀了多少个性化的工作流——这些东西加在一起，构成了一个别人没法复制的整体。不是因为技术有多难，而是因为时间投入不可压缩。

所以，如果你问我"值不值得花时间搞这些"，我的回答是：取决于你对 AI Agent 在未来工作中的角色的判断。如果你认为 Agent 只是一个临时的热潮，那确实不值得。但如果你和我一样认为这个方向是不可逆的——Agent 会越来越强、越来越深入地嵌入日常工作——那现在开始建设你的个人 Agent 体系，就是在最早期做一笔确定性很高的投资。

模型在变强，工具在进步，但你积累的上下文不会过时。五年后回头看，你今天写的那个 Skill、今天记录的那条经验，可能在更强大的模型上发挥出你现在想象不到的效果。而你需要的只是一个 ~/.claude/ 目录、一个 git 仓库、和一个愿意持续投入的心态。

最后修改于 2026-03-02