会用 Hermes 还不够：未来真正拉开差距的，是会写 Skill，一文学会

这两年，很多人的焦虑都变具体了。

以前谈技术进步，大家还觉得有点远。
现在不一样了。

AI 写代码、做图、 做 PPT、 剪视频、 查资料、 写方案、甚至直接进项目目录改文件。
工具一轮接一轮更新，Agent 一天比一天能干。

一边是效率提升，一边是失业、裁员、岗位重组的消息不断出现。

于是很多人开始问一个问题：

以后个人竞争力到底在哪？

编程？提示词？学某一个软件？追着每一个新工具跑？

我觉得都不够。

因为 Agent 发展到现在，技术、信息、编程、软件操作，这些门槛正在快速变低。

以前你不会开发，一个想法大概率停在脑子里。
现在你会描述需求，Hermes、Claude Code、Cursor、Codex 这类工具就能帮你先跑出一版。

以前你不会设计，就很难做出像样页面。
现在 AI 能给你生成布局、颜色、组件、图标、动效。

以前你不会写脚本，只能手动重复操作。
现在你说清楚步骤，Agent 可以直接帮你写自动化流程。

个人认为，工具越强，新的分水岭就越明显：

你能不能把自己的经验、判断、流程，整理成 AI 能稳定执行的 Skill。

未来不一定人人都要写代码，但每个人都可能需要学会写 Skill。

这句话听起来有点夸张，但你仔细想想，变化已经开始了。

回看来时路，为什么说写 Skill 可能会变成新基本功？

以前，很多人要学打字。

后来，大家要学用电脑、用 Office、用搜索引擎、用表格、用网盘、用协作文档。

这些能力一开始也像“专业技能”，时间一长，就变成基础能力。

Agent 时代，写 Skill 也可能走同样的路，因为每个人都有自己的工作方法：

一个做产品的人，知道 idea 不能只看兴奋感，要看用户是谁、痛点强不强、替代方案是什么、前 10 个客户从哪里来。 一个做项目的人，知道开工前要定边界，交付前要验收，出问题要复盘。 一个做销售的人，知道客户跟进要看行业、预算、角色、时间点和异议。 一个学习的人，知道错题不能只抄答案，要记录错误原因、相似题、下次提醒。

这些经验以前散在脑子里，现在可以沉淀成 Skill。

你写出来，Hermes 就能按这套流程帮你做事。
你越会整理流程，Agent 越像长期助手。
你只会临时提要求，Agent 就更像临时外包。

这就是差距。

未来的个人竞争力，很可能不是“我会用多少工具”，而是：

我能不能把自己的方法封装起来，让 AI 稳定复用。

先介绍一下 Anthropic 和 Claude Code

这次我们参考的是 Anthropic 发布的一份 Skill 构建指南。

Anthropic 是一家 AI 公司，它自我介绍是一家公共利益公司，目标是让 AI 带来好处，同时降低风险；旗下最出名的产品就是 Claude 系列。Anthropic 这几年在大模型、AI 安全、Agent、编程助手这些方向都很活跃。

其中一个很重要的产品就是大家最为熟知 Claude Code，Anthropic 对它的介绍里有一句很关键：对没有工程背景的创造者来说，Claude Code 打开了一条以前不存在的软件开发入口。

这句话很值得想一想。

软件开发不再只属于传统程序员。
产品经理、设计师、运营、创作者、创业者，只要能描述清楚目标，也可以让 Agent 帮自己搭工具、做原型、改项目。

AI 编程的重点，已经从“自动补全一行代码”，走到了“把一个目标交给 Agent，让它完成一段工作”。

当工具具备这种能力后，人要学的东西也变了。

只会说“帮我写一下”不够。
你得知道怎么让 Agent 按你的方法做事。

这就是 Skill 出场的地方。

回到正题，我推荐大家看这份 33 页的指南

Anthropic 这份文档叫《Claude skills构建的全面指南》，虽然教Claude skills指南，但是现今 skill 已全面通用，可以理解为通用构建指南，一共 33 页。

它没有把 Skill 讲成玄学，也没有包装成复杂工程。开头直接给了定义：

Skill 是一组指令，打包成一个简单文件夹，用来教 Claude 处理特定任务或工作流。它让你不用每次对话都重新解释偏好、流程和领域经验，可以“教一次，以后反复用”。

这句话放到 Hermes 用户身上也一样成立。

你每次让 Hermes 写文章，都要提醒它：

先查项目。
别乱编安装命令。
不确定就说不确定。

你每次让 Hermes 做产品判断，都要提醒它：

别急着写代码。
先问用户是谁。
先看痛点是不是真的。
先判断谁会付费。

这些重复提醒，就是 Skill 最适合接管的部分。

Skill 的价值，不在于让 AI 记住一句口号。
它让 AI 记住一套做事方式。

Skill 到底是什么？别把它想成提示词

很多人一听 Skill，会以为它就是一个高级提示词。

这个理解太浅了。一个 Skill 是一个文件夹，里面至少有 SKILL.md，还可以有 放可执行脚本、资料、模板、字体、图标等素材，很像一个小工具包。

提示词更像你临时对 AI 说的一句话。
Skill 更像你给 Agent 写的一份工作说明书。

用一个更容易理解的说法：

SOP 是给人看的，脚本是给机器跑的，Skill 是给 Agent 执行的。

我们以前把工作经验写成文档，给同事看。
后来把重复操作写成脚本，让电脑跑。
现在 Agent 能理解任务、调用工具、读文件、写代码，我们需要把工作方法写成 Skill，让 Agent 执行。

这就是新的变化。

从指南里学到的第一点：先找重复流程

很多人想写 Skill，第一反应是：
“我要不要写一个全能开发 Skill？”
“我要不要写一个万能办公 Skill？”

先停一下。

Skill 最怕大而空。

Anthropic 指南建议，写 Skill 前先找到 2 到 3 个具体用例。比如用户会说什么、触发场景是什么、需要哪几步、最后结果是什么。它还给了一个项目 Sprint 规划的例子：触发语、步骤、结果都要写清楚。

一个好 Skill，往往从一句话开始：

这件事我经常重复做，而且每次都要提醒 Hermes 这些 Agent 一堆细节。

只要符合这句话，就值得写 Skill。

第二点：这两件事决定 Skill 会不会被用对

很多 Skill 不好用，问题出在第一段。

Anthropic 指南里说，description 是 Claude 判断要不要加载 Skill 的关键。它必须同时包含两件事：这个 Skill 做什么，以及什么时候使用；还要写具体任务和用户可能说出的触发语。

这就提醒我们：description 不能写得像广告语。

比如这个写法很弱：

description: 帮助用户高质量完成项目。

Hermes 看完还是不知道什么时候该用。

更好的写法是：

description: 用创业者视角压力测试产品想法。Use when user says “帮我验证这个 idea”“这个产品值不值得做”“先别写代码，先判断需求真假”“帮我找 2 周 MVP”。

这样就清楚了。

它知道这个 Skill 处理的是产品 idea。
它知道用户想要验证，不是立刻开发。
它知道看到“idea”“MVP”“值不值得做”这些词时，可以考虑加载。

写 Skill 的时候，一定要把用户真实会说的话写进去。

因为 Agent 不是读你心里想什么，它读的是任务文本。

第三点：主文件要轻，资料要分层

很多人写 Skill 时，喜欢把所有内容都塞进 SKILL.md。

背景解释、案例、长命令、资料、表格、FAQ，全放进去。

看起来很完整，实际会变重。

Anthropic 指南把这个设计叫分层加载。第一层让模型知道什么时候用；第二层是 SKILL.md 正文，只在相关时加载；第三层是链接文件，需要时再打开。这样能减少 token 消耗，同时保留专业内容。

所以写 Skill 时，别把它写成一本书。

主 SKILL.md 放这几块就够：

什么时候用； 核心步骤； 常见坑； 验收标准。

长资料放到：references，

可执行脚本放到：scripts，

模板素材放到：assets，

你可以把 Skill 想成一个工具抽屉。

最常用的工具放最上层。
不常用的说明书放旁边。
需要时再让 Hermes 打开。

这样才轻，才稳。

第四点：少写口号，多写步骤

Skill 不是给 Agent 打鸡血。

很多 Skill 写得很像：

“请认真分析。” “请高质量输出。” “请全面严谨。”

这些话听着没错，执行时没抓手。

Anthropic 指南里给了一个很典型的对比：好的说明会写清楚运行什么命令、输入是什么、失败时常见原因是什么；差的说明只写“继续前验证数据”。

你需要让 agent 知道每一步该做什么。

写 Skill 的核心诀窍就是：

把脑子里的经验，拆成 Agent 能执行的动作。

别写“做好一点”。
写“先做 A，再做 B，失败看 C，最后交付 D”。

第五点：写完 Skill 要测试

很多人写完 Skill 就丢进去，然后期待 Hermes 自动变强。

这不现实，Skill 也要测试。

Anthropic 指南里提到，要证明 Skill 相比基础表现有提升，可以做个基础测试。比如不用 Skill 时要来回 15 轮、有 3 次失败调用、消耗 12000 tokens；用了 Skill 后，只需要 2 个澄清问题、0 次失败调用。指南还提到，后续要根据欠触发、过度触发、执行问题不断调整。

你写完一个 Skill，至少测三件事：

第一，它该触发时能不能触发。

第二，它不该触发时会不会乱来。

第三，用了它以后结果有没有更稳。

同一个任务，分别用 Skill 和不用 Skill 跑一遍。
看有没有少废话、少漏项、少返工、结构更稳定。

如果没有明显差异，这个 Skill 还没写好。

一个真正有用的 Skill，应该让 Hermes 的表现发生可见变化。

Skill 不是程序员专属

这篇文章最想说的，其实不是某个具体命令。

我更想强调一个趋势：

写 Skill 不只是程序员的事。

比如：运营可以写活动复盘 Skill。

先看目标；
再看数据；
再看渠道；
再看失败原因；
最后输出下次改进清单。

这些都不是写代码。

这些是把工作方法交给 Agent。

一旦你能做到这一步，Hermes 就不只是一个“你问它答”的工具。

它开始按你的流程工作。

用一句话讲清 Skill、记忆、提示词的区别

很多人容易把 Skill、记忆、提示词混在一起。

可以这样理解：

提示词：这次你想让我怎么做。
记忆：你希望我长期记住什么。
Skill：遇到某类任务时，我应该按什么流程做。

比如：

“帮我写一个程序”是提示词。
“我不喜欢对话框”是记忆。
“每次写程序前都先查 README、Release、安装门槛、适合人群、常见坑”就是 Skill。

这个区别搞清楚，Hermes 才会越用越顺。

最后说一句

Agent 时代，个人竞争力正在重新排序。

会不会用某个软件，当然还有价值。
会不会写代码，也依然重要。
但越来越多工具会帮你处理技术细节。

真正难复制的，是你的判断、流程、经验和审美。

你怎么定义问题。
你怎么判断方向。
你怎么拆任务。
你怎么验收结果。
你怎么避免踩坑。
你怎么把一次成功经验沉淀下来。

这些东西，过去藏在脑子里。
现在可以写成 Skill。

所以我越来越觉得：

未来不一定人人都要写代码，但每个人都应该学会写 Skill。

会用 Hermes，是第一步。
会给 Hermes 写 Skill，才是把它变成长期助手的关键。

如果你只会临时提要求，Hermes 每次都要重新理解你。
如果你能把流程写成 Skill，Hermes 就会越来越像一个懂你工作方法的协作者。

技术、工具、模型都会继续迭代。

但有一件事不会过时：

谁能把自己的经验沉淀下来，谁就更容易在下一轮变化里站稳。