Skill 版本记录
Skill 版本记录是围绕一次真实失败建立的轻量证据链：记录原问题、所属层级、修改哪一条规则、如何复测、结果是否缓解，以及下一版该改什么，让 Skill 迭代从“感觉变好了”变成可追踪的产品版本管理。
简介
Skill 版本记录不是为了把 Skill 管理变重，而是为了避免“改了很多、好像变好、下次又忘了为什么”的低效循环。很多人优化 Skill 的方式，是看到输出不满意就继续加形容词、加角色、加步骤、加模板，最后文件越来越长，却不知道哪一条规则真正有效。版本记录的目标，是把每次修改限定在一个可观察问题上，并留下能被复测的证据。
在《从自己能用到别人敢用：Skill 的验证、版本与交接》中，作者把 Skill 迭代和产品版本放在同一逻辑下：解决什么、为什么改、怎么验证，都要说清楚。如果同时改输入、流程、模板、角色、人设、文风和检查项，复测结果变好了也无法归因；如果没有复测，版本号只是编号；如果没有记录，复测只是感觉。
关键信息
- 适用对象：自用 Skill、团队共享 Skill、准备交接给他人的 Skill、需要长期维护的 Agent 工作流规则。
- 核心问题：让 Skill 迭代可归因、可复测、可交接，而不是靠主观感觉继续堆规则。
- 最低记录粒度：一次只记录一个最影响使用的问题，一次只改一条最相关规则。
- 相关概念：Skill、Skill 交接条件、事实标签、变更记录训练法、AI产品PRD。
核心特性
1. 版本记录从失败开始，而不是从“想优化”开始
成熟 Skill 的版本记录不应是“今天把文案优化得更专业”这种模糊描述，而应从真实任务中的失败出发。例如：异常场景缺失、系统边界写错、信息不足仍继续生成、输出结构不方便评审、敏感数据没有提醒脱敏。失败越具体，后续修改越可归因。
这与产品管理中的 Bad Case 池逻辑一致：错误样本只有进入归因、修复和回归验证，才会成为能力资产。对 Skill 来说，失败记录的价值不是追责，而是定位“该补输入、补过程、补输出，还是补验证兜底”。
2. 每次只改一条规则，降低归因噪音
Skill 很容易膨胀成“万能说明书”。但万能通常意味着不可验证。版本记录要求每次只改一条最相关规则，例如把“请根据资料生成完整 PRD”改为“在生成完整 PRD 前，先列出业务规则、系统边界和待确认问题；如果存在待确认问题，请先停止”。
这种小步迭代有两个好处：一是能判断这条规则是否真的解决问题；二是避免把 Skill 写成互相冲突的规则集合。规则越多，触发和执行越容易竞争；记录能提醒维护者哪些规则是为真实失败服务，哪些只是主观偏好。
3. 复测必须用相近但不同的真实任务
复测不是“把同一个任务再跑一次”。如果用“会员积分规则”暴露问题并改出 V2，下一次应该用“优惠券发放规则”来测，因为它们同属规则型需求但业务对象不同。这样才能看出 Skill 是否真的学会了结构，而不是记住上一个案例。
复测至少回答四件事：原来的问题有没有消失；如果没消失，是缓解还是无效；有没有出现新问题；下一版应该改哪一条。没有这四个回答，版本记录就无法指导下一次迭代。
4. 版本记录让 Skill 具备交接证据
一个 Skill 能在作者手上跑通，不代表别人敢用。交接时，接手者最需要看的不是“说明书写得多长”，而是它经历过哪些真实失败、哪些规则因此被加入、哪些相近任务已经复测通过、哪些边界仍然需要人工确认。版本记录把这些隐性信任证据显性化。
这也是它与普通 changelog 的区别：普通 changelog 记录“改了什么”，Skill 版本记录还要记录“为什么改、怎么验证、验证结果如何”。前者是改动清单，后者是能力证据。
不同素材中的观点
- 2026-07-08-woshipm-skill-validation-version-handoff：Skill 迭代应该像产品版本一样记录“解决什么、为什么改、怎么验证”。30 分钟极速迭代法要求选一个小任务、跑出 V1、找一个最影响使用的问题、判断它属于输入/过程/输出/验证哪一层、只改一条规则并记录；7 天练习则要求留下改造前、V1、失败记录、诊断、V2 和复测结果六份证据。
- 2026-07-19-woshipm-ai-output-failure-diagnosis：把版本记录压缩成一张更轻的修复工单（失败样本 / 症状 / 主因层级 / 判断证据 / 本次只改 / 复测任务 / 复测结果 / 新问题 / 下一步），并规定复测结果只分四类：消失、缓解、无效、转移。前置增加 输出失败诊断树：先命名六类症状、再定四层主因，避免“看起来很努力但一次改太多无法归因”。
- 2026-07-01-woshipm-ai-prd-full-workflow：变更记录训练法 说明，只喂最终稿 AI 学到的是结果，喂“初稿→终稿”的演变过程才学得到判断。Skill 版本记录同样是高价值训练语料，因为它包含“为什么这样改”。
- 2026-07-06-blocktempo-fable-5-self-improving-agent：会复利的 Skill 应吸收真实失败模式、反模式和 eval suite。版本记录是失败进入 Skill 正式规则前的证据层。
实用信息
最小版本记录模板
## Vx.y | YYYY-MM-DD | 任务：<真实任务名>
- 改造前问题：<这次最影响使用的一个问题>
- 问题层级：输入不足 / 过程缺确认 / 输出结构不对 / 验证兜底缺失
- 失败证据：<原输出或复盘摘要>
- 修改前规则：<原规则或缺失规则>
- 修改后规则：<只改一条最相关规则>
- 复测任务：<相近但不同的真实任务>
- 复测结果：问题消失 / 缓解 / 无效 / 引入新问题
- 下一版动作：<只写下一条最可能需要改的规则>使用原则
- 不要一次改十几条规则；先改一条最可能影响结果的规则。
- 不要用同一个任务复测；用相近但不同的任务验证迁移能力。
- 不要只写“优化了输出”；写清楚失败证据和复测结果。
- 不要让版本记录长期孤立；被多次验证有效的规则应并入 Skill 正文或 references。