写了 Skill 还是不稳定？这套写法让 Agent 真正学会判断

很多人写 Codex / Claude Code 的 Skill，第一反应就是写流程。

第一步做什么。

第二步检查什么。

第三步输出什么文件。

看起来很完整，实际一跑就知道问题在哪：Agent 确实照着做了，但做出来的东西还是不稳。

选题 Skill 会选一堆通稿。

标题 Skill 会给你加“重磅”“炸裂”“必看”。

审稿 Skill 看起来过了一遍，真正的废话、空句、标题党，照样留在正文里。

这不是 Agent 不听话。

是 Skill 只告诉它“要做什么”，没告诉它“什么叫好”。

Skill 不是提示词，是一套可复用的经验包

我这两天重新看了一圈官方文档、社区项目和我们自己翻车的稿子，最大的感受是：好的 Skill 不是把步骤写满，而是把专家判断封进去。

提示词解决的是这一次怎么做。

Skill 解决的是以后遇到同类任务，Agent 能不能稳定按同一套标准做。

这两个东西完全不是一回事。

如果你只是写：

请帮我起 5 个标题，要求有点击率。

Agent 大概率会给你这种：

重磅！这个工具彻底改变 AI 工作流

看起来有情绪，实际啥也没说。

但如果 Skill 里写清楚：

标题必须让读者第一眼看出：
1. 这和谁有关
2. 解决什么痛点
3. 看完能拿走什么
4. 标题承诺必须能被正文兑现

再给它好坏案例，结果就会稳定很多。

同样是写 Skill，差别就在这里。

一个是在命令 Agent。

一个是在训练 Agent 的判断。

第一块：先写触发边界，别让 Skill 乱上场

很多 Skill 第一行就开始写流程，这是很危险的。

因为 Agent 最常犯的错，不是不会执行，而是不知道什么时候该用这套能力。

比如写一个“选题 Skill”，不能只写：

从热榜里选 3 个 AI 相关话题。

这样它会把所有 AI 新闻都当候选，最后选出来一堆大家都看过的通稿。

更好的写法是先把边界写清楚：

适用场景：
- 需要为公众号、头条、Twitter 找 AI 工具/教程/工作流选题
- 目标是让读者读完能立刻用上、收藏或转发

不适用场景：
- 只有行业新闻，没有用户收益
- 只有模型参数变化，没有实际使用路径
- 之前已经写过，除非出现新的角度或官方更新

这段看起来普通，但非常关键。

它会把 Agent 从“看到热点就写”，拉回到“这篇对读者有没有用”。

第二块：把好坏标准写具体

Skill 里最值钱的不是步骤，是标准。

你不能只写“标题要有吸引力”。

什么叫有吸引力？

是有数字？

是有情绪？

是有免费？

是击中某类用户的痛点？

这些不写清楚，Agent 只能按自己最熟的套路来。

我们这次标题就翻过一次车。

原来写成：

写了 Skill 还是不稳定？补齐这 10 个组件，Agent 才能真正干活

第一眼看是猛的，但它有个硬伤：正文根本没写 10 个组件。

这就是标题党。

不是“标题技巧”，是信任透支。

后来改成：

别再把 Skill 写成流程清单了，Agent 真正缺的是判断标准

这个标题没那么花，但正文能兑现。

文章讲的就是：Skill 不能只写流程，要写触发边界、判断标准、案例对照、工程闭环和验证场景。

标题承诺什么，正文就交付什么。

这条要写进 Skill 里。

否则 Agent 很容易为了点击率硬造数字、硬造清单、硬造结论。

第三块：一定要放好坏案例

只写规则，Agent 很难学会品味。

好坏案例才是最省 token 的训练方式。

比如你想让 Agent 学会判断标题，不要只写：

标题要具体，标题要有价值感，标题要避免 AI 味。

这三句话都对。

但没用。

你要直接给它看对照。

弱标题：
国产 Agent 工具链终于补上手脚

问题：
太抽象，看不出读者能拿走什么。

更好的标题：
Kimi 也能操作网页了，国产 Agent 开始干浏览器里的活

为什么更好：
对象明确，动作明确，读者知道这不是普通模型新闻，而是能进入真实工作流的能力变化。

这种案例放三五组，比写一堆“标题原则”更有用。

因为 Agent 不是缺流程。

它缺的是这种“哦，原来这叫好”的参照物。

写作 Skill、选题 Skill、审稿 Skill、产品判断 Skill 都一样。

只要是靠经验和品味的活，都必须有案例。

没有案例的 Skill，最后大概率会变成一份礼貌但无力的操作手册。

第四块：机械检查交给脚本，别塞进正文

还有一种 Skill 写法也很常见：把所有东西都写进 SKILL.md。

标题怎么写。

图片比例多少。

公众号摘要有没有。

头条位置选不选北京。

发布后链接回填到哪里。

这些当然重要，但它们不是同一类东西。

经验判断应该写进 Skill。

机械检查应该交给脚本。

比如：

封面图必须存在
头条封面比例必须是 16:9
公众号摘要不能为空
Twitter 线程配置必须有图片

这些不要靠 Agent 记。

直接写 validator。

没通过就挡住发布。

Skill 负责告诉 Agent 为什么这样做、什么时候这样做、什么结果算好。

脚本负责挡住低级错误。

这两个分开之后，Skill 会清爽很多，Agent 也不容易被一堆机械规则淹没。

第五块：给它真实翻车场景

最好的 Skill，不是从理论里写出来的，是从翻车里长出来的。

比如我之前写过一个选题 Skill，只写了“从热榜里挑 AI 相关内容”。

结果它真的很听话。

每天都能挑出 AI 相关内容。

但大部分都是普通新闻，读者看完没有任何行动价值。

后面我才把这条翻车场景写进去：

坏案例：
只因为某条 AI 新闻热，就把它当长文选题。

为什么坏：
它只有信息差，没有读者收益。读者看完不知道能省什么、学什么、避开什么坑。

正确处理：
这类题只适合发短动态。除非能拆出具体教程、工具入口、实操路径或成本变化，否则不要写成长文。

这比单独写一句“选题要有价值”有效得多。

因为它有具体场景。

Agent 下次遇到同类问题，就能知道这不是抽象原则，而是真翻过车的地方。

一份行业经验型 Skill，可以按这个骨架写

如果你现在要写一个真正能复用的 Skill，可以先别急着写流程。

先按这个骨架搭：

1. 这个 Skill 解决什么问题
2. 什么时候该用，什么时候不该用
3. 这件事的核心判断是什么
4. 什么算好，什么算差
5. 好案例和坏案例
6. 不同场景下怎么变形
7. 哪些错误一出现就打回
8. 哪些机械检查交给脚本
9. 用什么翻车场景验证它真的生效

这不是固定模板。

但它能避免一个最大的问题：把 Skill 写成流程清单。

流程清单只能让 Agent “做完”。

判断标准才能让 Agent “做好”。

以后我们写 Skill，真正要追求的不是“步骤越来越完整”，而是“Agent 越来越像懂这个领域的人”。

这才是 Skill 最值钱的地方。

关注我，继续聊 AI 工具和 Agent 工作流。大小项目开发和方案咨询，都可以私信。