最近把 Hermes 和 OpenClaw 这两个开源 Agent 摆在一起用，有个差别越用越扎眼——不在谁接的模型更强，而在它俩”怎么建一个 Skill”。
很多人夸 Hermes，夸到”它能自进化”就停了。但还有个更小的细节，不知道你注意到没有——Hermes 在创建 Skill 的时候，会尽可能用 Python 脚本，而不是写一段话告诉模型”你该怎么做”。
反观 OpenClaw，它的 Skill 本质上就是一份 SKILL.md：说白了，一段写得更讲究的 Prompt。
同样叫”建 Skill”，一个尽量落成能跑的脚本，一个停在一段提示词。这个差别看着小，却正好戳中我折腾 Skill 大半年最值钱的一条经验，就一句话：
一个能长期稳住的 Skill，从来不只是一段 Prompt，而是 Prompt + 脚本。
Prompt 负责”想”——判断、理解、组织语言，这些交给模型；脚本负责”做死”——那些步骤确定、可枚举、错了有代价的活，固化成脚本，别留给模型现场发挥。
大多数人的 Skill 老翻车，根子不在 Prompt 写得好不好，而在整个 Skill 只有 Prompt 这一半，把本该写死的步骤也丢给模型去猜。有猜测就有变量，有变量就会翻车。
系列定位：这是《一人公司的 AI-Coding Harness》系列开篇。承接上一篇 DSPy 复盘，从”调好一段 Prompt”升维到”让一个 Skill 长期稳得住”。
先把”脚本”说清：它不只是代码
我说的”脚本”，不一定是 shell、py、mjs 这种能跑的代码。它的本质是把确定的部分固化下来，让模型照着走，而不是每次现场猜。
按这个本质，它其实是一道光谱：
- 可执行脚本（shell / py / mjs）：由机器执行，管”算”和”做”——Excel 求和、文件读写、编译测试这类步骤。
- 结构化模板 / SOP（一份写死的 md）：由模型照着填，管”结构”和”套路”——写作、运营这类文字 Skill，把文章骨架、固定话术、流程套路写成模板，模型只往里填需要判断和创意的部分。
区别只在”谁来执行”：代码由机器跑，md 由模型照着走。但作用是同一个——消掉一个变量。所以一个写作 Skill 的”脚本那一半”，往往就是一份钉死了结构和流程的 md。
我撞过的两堵墙
同一个道理，我是被两个 Skill、从两个方向各教了一遍才记住的。
墙一：换个模型，Skill 就废了
我给一个前端项目写过代码审查 Skill，在 Claude 上调得百发百中。后来想省点 API 的钱，换上一个开源小模型，Prompt 一个字没动——第一份报告就稀碎：该揪的五个 P0 漏了仨，表格塌成一行纯文本，末尾还很贴心地加了句”建议开发同学注意休息、多喝热水”。
那两百行我引以为豪的 Prompt，根本不是代码，是一堆只对 Claude 有效的咒语。换个模型，咒语就失灵。
后来我用 DSPy 把它重构成”只声明契约和打分函数、措辞交给编译器生成”的程序，换模型从”几乎重写一遍”变成”改一行、重编译一次”。完整复盘在这：《我把一个 Skill 从手写 Prompt 重构成了可编译模块——一次 DSPy 实战复盘》。开头提到 Hermes 的”自进化”，底层用的正是这套 DSPy + GEPA：拿真实执行轨迹自动迭代 Prompt，不靠人工重写。它不过是把我手动那一步，做成了自动的。
这堵墙教我的是 Prompt 侧的稳：连 Prompt 本身，都该被当成”能重新生成的程序”，而不是手抄的、绑死在一个模型上的权重。
墙二：建了 Skill，还是天天翻车
另一个例子更日常，也更扎心。
我媳妇每天要用 AI 把一张 Excel 整理成日报。Skill 早建好了，可还是三天两头出岔子：有时把”本周实际”那一列看成了”计划”，数字整个错位；有时表格里夹了个空行，它就把求和算崩了；生成的日报偶尔还凭空多出一条根本没发生的进度。
她的困惑特别有代表性：明明建了 Skill，为什么还翻车？
根因和墙一是同一个：这个 Skill 只告诉了 AI”该做什么”，但每一步具体怎么做，仍然让模型现场推测。 读哪一列、怎么求和、遇到空行怎么处理——这些根本不该靠”想”，该写成确定的脚本。模型只做它真正擅长的那一步：把算好的数字，写成一段通顺的日报。
这个案例我在系列② 《那份周报是 AI 编的，第一个信的人是我》 里完整讲过。这里只取最锐的一刀：它缺的，就是脚本那一半。
这堵墙教我的是脚本侧的稳：凡是能写死的流程，就别留给模型临场发挥。
那一步，到底该交给谁？
两堵墙合起来，我现在判断”某一步交给 Prompt，还是写成脚本”，只看一张表：
| 这一步的特征 | 交给谁 | 为什么 |
|---|---|---|
| 需要判断、理解、创意、组织语言 | Prompt（让模型想） | 这是模型的主场，写死反而僵 |
| 步骤确定、可枚举、可重复 | 脚本（写死） | 确定的事没必要每次重新猜 |
| 错了代价大 / 不可逆（删文件、改库、发布） | 脚本 + 红线 | 高危动作不能赌模型这次清醒 |
| 格式、规范、校验 | 脚本兜底 | 让结果可预期，而不是”忽好忽坏” |
但别急着”能写死的全写死”——脚本那一半，不是免费的稳。 你把”不确定”消掉的同时，也给自己揽下了”维护成本”：Excel 多一列、接口改个字段，写死的脚本会当场崩，而模型反倒能连蒙带猜地扛过去。
所以这张表真正的用法，是算一笔账：这一步的不确定性，值不值得你用一段脚本去钉死、并长期养着它？越高频、越高危、越不常变的步骤，越值得写死；越是边角、易变、错了无所谓的，越该放心交给模型去想。
一句话记牢：让 Skill 变稳的每一步，本质都是把一个变量，从”靠模型猜”挪到”被脚本定死”——但你得清楚，这一挪是要付维护费的。
Skill 一多，你要的就是 Harness
一个 Skill 是 Prompt + 脚本。可当你有十个 Skill、还要它们彼此协作，光靠”这儿写段脚本、那儿调个 Prompt”就乱套了。你需要一套外壳，系统地安放这两半——这套外壳，就是 Harness。
我把它拆成四层，正好是后续四篇的骨架：
- 输入层：喂什么上下文、规则、工具（MCP）——让 AI 不靠猜就知道这次要干嘛。比如把”我们项目的提交规范”直接写进上下文，而不是每次祈祷它还记得。
- 执行层：让 AI 真正能动手——编译、测试、读写文件、查库。光会”说”代码没用，得能跑一遍
npm test、亲眼看它绿不绿。 - 约束层：权限、沙箱、红线——能动手，但出不了事。比如删文件、改库前，强制先过一道”工作区干净、且在分支上”的脚本检查，不满足就拦下。
- 验收层：自动测试、Lint、Eval、人工 review——不达标不算完。Lint 不过、Eval 掉分，这一轮直接打回，而不是”看着还行”就放行。
你会发现，这四层本质上是在更大的尺度上，反复回答同一个问题：这一层里，哪些交给 Prompt 想，哪些写成脚本钉死。
为什么这恰恰是一人公司的主场
一个人训不了大模型，这条路从一开始就堵死了。但”哪一步交给 Prompt、哪一步写成脚本、怎么把它们组织起来”——这是纯工程判断，不需要 GPU 集群，只需要你对自己业务的那点理解。它恰恰是一个人能打磨到极致的地方。
你可能会反问：Hermes 不是已经把”Prompt + 脚本 + 自进化”整套打包成产品了吗？那我费劲搭 Harness，还算什么护城河？
问得好。工具给你的，是脚手架；但”在我这摊业务里，到底哪一步该交给模型想、哪一步值得写死、写死之后我愿不愿意养它”——这种领域判断，Hermes 给不了你。脚手架谁都能下载，往里填的东西才是你的。
模型是所有人共享的，工具也是；真正只属于你的，是你对自己这摊事”哪里该稳、怎么稳”的那本账。
这个系列接下来写什么
这篇是开篇，先给你那把判断的尺子。后面四篇，沿着四层逐层展开：
- 输入层——把”这次要干嘛”讲到模型不用猜（已发：《那份周报是 AI 编的，第一个信的人是我》）。
- 执行 + 约束层——给 AI 沙箱和权限，让它能动手却出不了事。
- 验收层——给整条流水线写”单元测试”，Eval-driven 实践。
- 完整模板——把四层拼成一张可复用 SOP，附可下载版本。
下次你的 Skill 又翻车，先别急着改 Prompt。回头看一眼：是哪一步，本该写成脚本，却还在让模型猜？ 找到它、把它钉死（顺手也认下这份维护费），你的 Skill 就又稳了一格。