核心判断
一个常见的误解：Skill 是 Prompt Engineering 的下一阶段，是"更工程化的 Prompt"。这个理解是错的。Skill 和 Prompt Engineering 解决的是不同层次的问题，被创造的理由也完全不同。
Skill 出现的真实原因：Agent 时代需要可靠地执行长链条任务，但同一个任务在不同 Agent 间无法复用、执行结果难以观察、失败原因难以追踪——Skill 是为了解决这些可靠性问题而被创造的，不是为了把 Prompt 写得更好看。
Prompt Engineering vs Skill：本质区别
Prompt 工程
经验性的，每个人写的不同；关注单次调用的输出质量；没有标准化的评估标准；随模型升级逐渐消亡
Skill 系统
产品化的，有明确的定义、参数、评估标准；关注任务执行的可观察性和复用性；为 Harness 层提供标准单元；Domain-specific 部分不会消亡
Skill 的四个永久价值
即使基础模型变得无限强，Skill 系统的这四个属性仍然有价值：
可观察
每次执行都可被追踪，知道哪一步失败了
可复用
好的 Skill 可以在不同 Agent 间共享
可评估
有明确的成功标准，成本和成功率可量化
可优化
有数据就能改进，支持版本管理和迭代
哪些 Skill 会消亡，哪些会留下
Skill 内部同样有消亡度的分野。那些纯粹为了补救模型能力不足而存在的 Skill 会被吞掉：
- "让模型按格式输出的 Skill" — 强模型自然输出格式，这个 Skill 失去存在理由
- "让模型分步推理的 Skill" — 强模型默认推理，无需额外包装
但领域专属的 Skill 不会消亡：
- 医学诊断的决策树 Skill — 编码的是医学专业知识，不是补救缺陷
- 金融合规的规则引擎 Skill — 编码的是特定机构的合规要求
- 法律文书的模板系统 Skill — 编码的是法律领域的最佳实践
当前最大的问题：Discovery Layer 缺失
现在 Skill 系统最核心的工程问题不是 Skill 本身的质量，而是 Discovery——用户不知道该用哪个 Skill。
Claude Code 有数百个 Skill；各平台的 Skill 市场还在早期阶段；没有好的自动路由系统。如果用户需要手动选择 Skill，那 Skill 能提供的价值就大打折扣。理想的系统应该能自动识别"这个任务需要哪个 Skill"然后自动调用——这才是真正意义上的 Harness Engineering。
Skill 体系评估视角：评估一个 AI 产品的 Skill 体系，不能只看 Skill 的数量和质量，要看它的 Discovery Layer——用户怎么知道有这个能力？系统怎么自动路由到正确的 Skill？这才是决定 Skill 实际价值的关键。