经验变成 Skill 之前，为什么总会丢东西

我最近有一次很具体的失败：想把产品从探索进入真实业务后的交付经验，沉淀成以后可以复用的能力。最后生成的 Skill 格式、链接和哈希都没有问题，但读起来很笼统，也没有真正教 Agent 如何完成一次判断。

这让我意识到，把经验泛化，不等于把具体过程抽空。

泛化时最容易删除什么

很多人以为去掉项目名称、身份和私密细节之后，剩下的原则就是最干净的版本。但如果连同这些一起删掉了“当时看到了什么证据、谁拥有权限、哪个判断被什么事实推翻、最后交付了什么”，留下的就只是一串正确口号。

真正需要隐藏的是不必要的身份信息，不是机制。

一次真实交付至少包含：

• 起始问题和当时的错误理解；
• 通过哪些只读检查获得新事实；
• 新事实如何改变决策；
• 哪些权限或边界不能跨越；
• 最终产物如何验证，失败时怎么恢复。

这些部分才是别人能够迁移的教学材料。

薄入口不等于薄能力

Skill 的入口可以很短，但入口后面必须有足够的资源：调查步骤、证据解释、决策分支、示例和验收方式。只写“先核对来源”“确认权限”“验证结果”，并不能教会 Agent 到底查什么、何时阻断、要交付什么证据。

我现在会把入口和教学内容分开：入口负责判断当前任务是否匹配，正文负责提供能被执行和复盘的材料。简洁的导航不应该以牺牲可学习性为代价。

成熟度标签不能代替验证

“未验证”“个人试用”“低置信度”这些标记很重要，因为它们防止我把试验结果说成已证明的能力。但它们也不能替代行为验证。

用户批准安装，只说明可以试用，不说明内容已经足够好；格式检查通过，也不说明 Agent 在真实任务中会做出正确动作。最终仍然要用新的场景观察它是否能选择正确证据、解释结果并在权限不足时停下来。

我现在怎么检查一份 Skill

我会用一个很小的映射表复核它：经验事实是什么，提炼出的判断是什么，Agent 要做的动作是什么，完成后交付什么证据，在哪些情况下不能继续。若其中一格是空的，说明这份 Skill 还只是总结，不是教学。

对我来说，经验沉淀的目标不是让文档看起来更抽象，而是让下一次的行动少一点猜测。删掉身份，保留机制；缩短入口，补足教学；标记未验证，再用行为验收。