三个小时前，我刚刚发布了 ECC 研究的第三篇文章《从 Session 到 Skill》。文章讲的是"连续学习"——Agent 如何从历史会话中自动提炼可复用的技能。
发布之后我盯着屏幕看了一会儿，然后问了自己一个问题：
我自己的技能库，跟 ECC 学到的"标准化"相比，差距有多大？
答案不太好说出口。我有 240 个技能，但它们的格式参差不齐——有的有 trigger 字段，有的没有；有的有 tags，有的是空的；有的还躺在旧格式里。它们都"能用"，但离"可管理"差得很远。
于是我花了两个小时，做了三件事：
这篇文章就是这两小时的复盘。
技能像代码一样，不用它的时候它不变，一用就开始"熵增"。
刚开始只有几个技能的时候，不需要标准格式——你记得每个技能是干什么的，什么时候该用，需要什么工具配合。但到了几十上百个的时候，问题就来了：
plan-completion-audit——这是干啥的？systematic-debugging——这个我常用，它需要配什么工具来着？这些问题不是说"能查"就能解决的。如果每次都要 load 一个技能看正文才知道它是不是我想要的，那技能库越大、效率越低。
---
name: strategic-compact
description: Suggests manual context compaction...
metadata:
origin: ECC
---它的正文结构是：When to Activate → Why Strategic Compaction? → How It Works。这是一个很好的参考模板。
| 字段 | 为什么加 |
|---|---|
| title（中文标题） | 翻列表时一眼看出是啥 |
| trigger（触发条件） | 明确"什么场景该用" |
| required_tools（依赖工具） | 不用进正文就知道需要什么工具 |
| tags（分类标签） | 按类别过滤、未来做自动推荐 |
| origin（来源） | 区分自建 skill 和外部导入 |
模板定稿：
---
name: skill-name
title: 中文标题
description: 一句话描述
trigger: 什么场景触发
required_tools: [工具1, 工具2]
tags: [分类1, 分类2]
origin: hermes
---在设计模板时有一个权衡：加太多字段维护成本高，没人愿意填。加太少信息不足。
我选了"够用就行"的原则：必须有 title / trigger / tags（影响日常使用），可以有 required_tools（加分项），暂不加 version / author / license。
我审计了所有 240 个技能，发现它们处于三个状态：
| 状态 | 占比 | 特征 |
|---|---|---|
| ✅ 完整格式 | ~5% | 有 name/description/tags，甚至有 metadata 嵌套 |
| ⚠️ 基本格式 | ~60% | 有 name/description，缺其他字段 |
| ❌ 简陋格式 | ~35% | 只有 name+description |
第一批选了 20 个最常用的升级。 选择标准是日常开发中反复加载的那些——部署、排查、审计、开发循环。
以 harness-deploy-workflow 为例，改动前：
name: harness-deploy-workflow
description: Harness 部署——一条make deploy搞定全部
trigger: 需要编译部署后端/前端到服务器时改动后：
name: harness-deploy-workflow
title: Harness 部署
description: Harness 部署——一条make deploy搞定全部
trigger: 需要编译部署后端/前端到服务器时
required_tools: [terminal, patch]
tags: [harness, deploy, devops]
origin: hermes只加了 4 行，但信息量翻了一倍。
升级过程中发现了一些没注意到的信息：
有的技能有 duplicate 字段。 一个技能的文件里出现了两行 tags:——新的和旧的都没删。说明有人升级过但没清理干净。
有的 category 字段跑到了 frontmatter 里但不是标准字段。 需要确认它是什么工具的产物。
约 30% 的技能已经有过部分升级痕迹。 说明"过去的我"已经意识到格式问题，但没有走到底。
这次升级让我意识到，技能标准化不止是"加几个字段"，而是三个层次的工作：
第一层：格式层（今天完成了）。所有技能有统一的 frontmatter 结构。这是基础，花 2 小时就能搞定。
第二层：分类层（部分完成）。通过 tags 实现按类别过滤。目标是：任何场景下 3 秒内能定位到需要的技能。
第三层：质量层（未开始）。技能的内容质量需要维护。理想状态下每个技能应该有：触发条件、所需工具、实际示例、已知陷阱。
这三层不必一次性完成。做完了第一层、打好了第二层的基础，第三层随用随补。
1. 检查你的技能库格式。 花 15 分钟看 5 个技能的 frontmatter。如果格式不一致，就是今天要修的问题。
2. 定义你自己的标准模板。 根据你的使用场景挑字段：常换平台加 origin；共享给团队加 author；用版本管理加 version。关键在于先定下来，再执行。
3. 从最重要的 5 个开始改。 不用一次改完。剩余技能随用随改——每次用到一个"格式老旧"的技能就顺手升级。持续改进比一次性完美更现实。
打开你的技能列表。找到最常用的那个看一下 frontmatter——如果只有 name 和 description，加一个 trigger 字段。5 秒能做完，但效果立竿见影。
💬 评论