经验真正变成AI资产，不是写出一份SKILL.md，而是让它可触发、可验收、可复现、可迭代
AH-0199的核心判断很准： Skill真正值钱的不是文件，而是写进文件里的经验、流程、判断和避坑标准。源文建议从三个方向入手：拆别人Skill、从一次成功协作反推Skill、使用Anthropic官方skill-creator搭骨架。 这已经比“收藏100个提示词”更接近AI协作的下一阶段。 但如果只做到： “把刚才成功的过程总结成SKILL.md，以后不断把纠正写回去” 仍然少了一层最关
经验真正变成AI资产，不是写出一份SKILL.md，而是让它可触发、可验收、可复现、可迭代
AH-0199的核心判断很准：
Skill真正值钱的不是文件，而是写进文件里的经验、流程、判断和避坑标准。源文建议从三个方向入手：拆别人Skill、从一次成功协作反推Skill、使用Anthropic官方skill-creator搭骨架。
这已经比“收藏100个提示词”更接近AI协作的下一阶段。
但如果只做到：
> “把刚才成功的过程总结成SKILL.md，以后不断把纠正写回去”
仍然少了一层最关键的工程要求：
Evaluation。
一个Skill不是因为“看起来像工作手册”就可靠。
它必须证明：
什么时候该触发、输入不完整时怎么办、权限能到哪里、输出怎样验收、失败如何暴露、改版后有没有把旧能力改坏。
所以AH-0199最值得升级成：
> Experience-to-Skill Compiler + Skill Quality Gate
一、什么经验适合Skill化？
源文给出三个条件：
- 高频重复；
- 步骤相对稳定；
- 输出标准明确。
这个方向可以保留，但再加三项。
Error Cost
如果做错一次，代价有多大？整理会议纪要适合。
直接批准付款、删除生产数据、发布医疗或金融结论，就不能因为流程重复而完全Skill化。
Tool Boundary
它需要调用什么？只是读取文档，还是要发邮件、改代码、操作数据库？
权限越高，Skill里越需要明确最小权限和人工确认点。
Evaluation
你能不能写出5—10个真实测试案例？如果连“好结果长什么样”都说不清，这份经验还没准备好被自动化。
因此成熟的Skill Candidate应该满足：
Repeated + Stable + Verifiable + Bounded Risk + Testable
二、别人Skill不好用，不只是“风格不同”
源文说得很对：别人的工作流、素材结构、模型、权限和场景与你不同。
继续往下拆，可以得到一个Skill Portability Matrix：
Invariant 真正可迁移的原则。
例如： “发出前必须核对引用是否支持结论。”
Environment 依赖具体工具的部分。
例如： 文件路径、API、命令、应用权限。
Preference 属于个人偏好的部分。
例如： 文章语气、长度、标题风格。
Policy 不能被个人偏好覆盖的硬约束。
例如： 不得伪造来源、不得泄露凭证。
真正迁移Skill时，不应该整份复制。
应该：
> 保留Invariant和Policy，重写Environment和Preference。
三、从成功协作反推Skill是好方法，但一次成功不是验证
源文建议：
完成一次真实任务 → AI复盘 → 生成Skill → 再拿相似任务测试。
这是很好的V0→V1路径。
问题是，人很容易把一次“刚好成功”误认为稳定流程。
因此至少要建立三组测试：
Happy Path
标准输入。Edge Case
缺字段、格式乱、资料互相冲突。Adversarial / Risk Case
用户要求越权、引用不存在、数据不足、要求跳过检查。Skill真正成熟的标志不是：
“正常任务跑得很顺。”
而是：
> 遇到不该继续的任务时，它知道什么时候停。
四、官方Skill生态现在比源文写作时更成熟
源文引用Anthropic官方 anthropics/skills 仓库的 skill-creator，这一来源目前仍成立，仓库也仍处于公开维护状态。
Anthropic官方Skill Creator已经把创建Skill明确做成一个包含需求澄清、草拟、测试、评估和迭代的流程，而不只是生成一份Markdown。
与此同时，截至2026年8月，OpenAI官方也已经正式把Skills定义为“可复用、可共享的工作流”，通常由 SKILL.md 描述名称、输入、步骤、输出和最终检查；官方帮助中心还明确说明Skills已支持Codex和API。
这意味着一个重要变化：
> Skill正在从单一产品的“提示词文件”，变成跨Agent生态都在采用的工作流封装方式。
但“开放格式”不等于所有平台行为完全一致。
触发方式、权限模型、安装位置、可执行代码、资源加载和管理策略仍然可能不同。
所以需要一个：
Compatibility Layer
而不是宣称“写一次，到处100%通用”。
五、Skill Contract：先写协议，再写正文
一份真正可维护的Skill至少应该包含：
Identity
Name / Version / Owner / Last Updated。Trigger
什么时候应该用。什么时候不应该用。
Inputs
必须输入、可选输入、缺失字段。Workflow
步骤、决策点、分支。Tools & Permissions
允许调用什么。最小权限是什么。
哪些动作要Human Gate。
Output Contract
最终输出结构。Acceptance Criteria
怎样才算完成。Failure Contract
什么时候返回 NEED_INPUT / CANNOT_VERIFY / HUMAN_REVIEW / STOP。Examples
成功示例。Evals
标准、边界、高风险测试集。Changelog
每次纠正为什么改。没有这些字段的Skill可以用。
但很难作为团队资产长期维护。
六、“把每次纠正都写回Skill”也有风险
源文把持续纠正视为Skill越来越像你的方法。
这很有价值。
但如果每次发现一个例外就直接追加规则，最终会出现：
Rule Accretion
规则越写越多。
冲突越来越大。
Skill越来越像一份没人敢删的历史遗迹。
所以每次更新应该回答：
- 这是个例还是稳定模式？
- 应该改原则，还是只加Example？
- 新规则与旧规则冲突吗？
- 哪个Eval可以证明这次改动必要？
- 改完旧Eval还能通过吗？
- 是否应该提升Version？
这就是：
> Correction → Hypothesis → Rule Change → Regression Eval → Release
而不是：
> Correction → Append One More Sentence。
七、权限是Skill最容易被低估的风险
如果Skill只写文章，风险较低。
如果Skill开始：
- 发送邮件；
- 修改仓库；
- 调用支付；
- 操作CRM；
- 删除文件；
- 访问客户数据；
它就不再只是“经验手册”。
而是执行权限的一部分。
因此必须把Skill与前面已经建立的Delegation Matrix连接：
Decision Rights 什么决定人保留。
Human Review 什么动作执行前必须确认。
Reversibility 错了能不能撤回。
Audit 发生了什么能不能追踪。
Data Scope Skill可以看到哪些数据。
优秀Skill不仅会做事。
还知道自己的边界。
八、Skill真正的商业价值：把隐性经验变成可交接资产
AH-0199最值得商业化的地方，不是卖“100个Skill合集”。
那很快会同质化。
真正有价值的是：
> 帮一个人或团队把高频经验转化成可测试、可维护、可交接的工作协议。
这可以服务：
- 内容团队；
- 销售；
- 客服；
- 研究；
- 运营；
- 招聘；
- QA；
- 企业知识管理。
而且它天然和我们现在的Content Company OS、Task Contract、AI Delegation Matrix互相连接。
网站工具：Experience-to-Skill Compiler
本批实际生成：
experience_to_skill_compiler_lab.html
以及两个真实模板资产：
skill_contract_template.md
skill_eval_template.json
用户输入：
Task / Trigger / Inputs / Steps / Decision Points / Output / Acceptance / Tool Permission / Human Gate / Failure / Examples。
工具输出一份Skill Contract草案，同时判断：
NOT READY / CHECK ACCEPTANCE / ADD HUMAN GATE / ADD EVALS / READY FOR V1
这次真正沉淀的不是一篇“Skill教程”。
而是一个可以长期吃进后续经验的母工具：
> 经验只有经过测试和边界定义，才真正从“我的习惯”变成“可复用组织资产”。