这是「AI 协作」系列二第 7 篇。前几篇依次解决了输出标准、输入可信度和过程控制，这一篇补上最后一层：怎样留下失败记录、版本证据和交接规则，让一个 Skill 从“我自己能用”走向“别人也敢用”。

我最早以为，一个 Skill 能不能交给别人，主要看它写得够不够完整。

于是我会把角色、背景、步骤、输出格式、自查要求一条条补进去。越写越长，越看越像一份认真准备过的说明书。

但真正准备交接时，我发现问题不在“说明书还不够长”。

问题在于：很多关键判断从来没有被写进去。

一、先别急着分享：自己能用，不等于别人能用

前面几篇，我们一直在把一个 PRD Skill 往前推。

最开始，它只是能生成一份看起来像 PRD 的文档。

后来，我给它补了输出标准，让它知道什么叫“像我写的”。

再后来，我给它补了开工闸门，让它在信息不足时先暴露未知。

到了第六篇，我又把一次完整生成拆成几个确认节点，让错误能回到最近一步，而不是整份推倒重来。

到这一步，它已经比最早稳定很多了。

但稳定，不等于可交接。

1. 输入要求：哪些必须给，哪些不能给

不要只写“请提供业务背景”。

这句话太松了，松到使用者不知道该给什么，也不知道什么不能给。

更好的写法是：

输入要求不是为了显得专业，而是为了让 Skill 知道：没有这些材料时，它不能假装自己知道。

2. 事实标签：哪些是已确认，哪些只是推断

AI 最容易让人放松警惕的一点，是它会把推断写得像事实。

所以我会要求它在输出中加事实标签：

比如“系统支持短信通知”这句话，如果输入里没有明确写过，就不能直接出现在方案里。它最多只能写成：

这一步很小，但它能挡住很多“看起来很顺”的错误。

3. 自查清单：不要只靠使用者认真读

很多人会在 prompt 最后写一句：

“请你完成后认真检查。”

这句话基本没用。

因为“认真检查”不是一个可执行动作。

更好的方式，是把检查项写死：

检查项不需要一开始就很多，但必须具体。

具体到它能在输出里找到证据。

4. 失败兜底：什么时候必须停止

这是交接里最重要的一条。

一个可以交给别人的 Skill，不能只知道“怎么继续写”，还要知道“什么时候不能继续写”。

注意，这不是让 AI 变保守。

恰恰相反，这是让它更像一个靠谱同事：知道哪些事可以推进，哪些事必须停下来等确认。

二、输出不好是症状，不是病因

很多人迭代 Skill 的方式，是看到输出不满意，就继续加形容词：

它不知道这次需求服务什么人、解决什么问题、有哪些系统边界、哪些规则已经确认，所以只能写出一份漂亮但空泛的通用文档。

这时改文风没有用，应该补输入。

再比如，AI 写出来的流程前后矛盾。

你以为是模型不够聪明，其实可能是过程层没有确认节点。它在第一步误解了规则，后面当然越写越偏。

这时你不应该继续让它“重写一版”，而应该在关键节点加一句：

在生成完整 PRD 前，先列出你理解的业务规则、流程节点和系统职责，等待我确认后再继续。

先诊断，再修改。

否则你只是把 Skill 越改越长，但不一定知道哪一条真的有效。

三、别凭感觉改 Skill：每次修改都要留下证据

我以前改 Skill，经常有一种错觉：

这次改完感觉好多了。

但问题是，下次又出错时，我常常想不起来自己到底改过什么。

更麻烦的是，如果一次改了十几条规则，我也不知道到底是哪一条起了作用。

所以第七篇最想留下的动作，是给 Skill 建一份轻量的版本记录。

如果你同时改输入、流程、模板、角色、人设、文风和检查项，复测结果变好了，你也不知道为什么变好。

Skill 迭代和产品版本一样：解决什么、为什么改、怎么验证，都要说清楚。

这也是我不建议一上来就追求“万能 Skill”的原因。

万能通常意味着不可验证。

先让一个小任务稳定，再逐步扩展。 改得少，才看得清；有记录，才谈得上迭代。

四、复测不是再跑一次：要用相近但不同的真实任务

很多人以为，改完 Skill 后重新生成一次，就是复测。

不完全是。

比如你用“会员积分规则”改出了 V2，下一次可以用“优惠券发放规则”来试。

它们都属于规则型需求，但业务对象不同。

这样你才能看见：

• 它是不是只记住了上一个案例；
• 它能不能迁移同类结构；
• 它会不会在新场景继续乱补能力；
• 它的检查项是否仍然有效。

复测时也不要只问“这版是不是更好”。

要看证据。

至少看四件事：

1. 原来的问题有没有消失；
2. 如果没消失，是缓解了还是完全无效；
3. 有没有出现新问题；
4. 下一版应该改哪一条。

如果没有复测，版本号只是编号。

如果没有记录，复测只是感觉。

五、不用等 7 天：先做一次 30 分钟极速迭代

很多人一听“版本记录”“复测”“交接”，会觉得这件事很重。

其实不用。

先做一次 30 分钟极速迭代就够了。

第一步：5 分钟，选一个小任务

不要选“搭一整套产品工作流”。

选一个小、痛、高频的任务，比如：

• 写一份需求初稿；
• 梳理一次评审问题；
• 整理一份复盘提纲；
• 把会议纪要转成待办；
• 给一个活动方案补异常场景。

标准只有一个：这个任务你最近真的会用。

第二步：10 分钟，跑出 V1

不要追求完美。

把你现在的 Skill 跑一遍，生成第一版真实产物。

这一步的目标不是成功，而是暴露问题。

第三步：5 分钟，只找一个最影响使用的问题

不要把所有不满意都列出来。

只选一个最影响你继续使用的问题。

比如：

• 异常场景缺失；
• 系统边界写错；
• 信息不足还继续生成；
• 输出结构不方便评审；
• 敏感数据没有提醒脱敏。

第四步：5 分钟，判断它属于哪一层

把问题放进四层：

• 是输入不够？
• 是过程缺确认？
• 是输出结构不对？
• 是验证没有兜底？

这一步很关键。

因为你一旦判断错，后面就会改错地方。

第五步：5 分钟，只改一条规则

不要重写整个 Skill。

只改一条最相关的规则，并记录下来。

比如：

修改前：

请根据资料生成完整 PRD。

修改后：

在生成完整 PRD 前，先列出你识别到的业务规则、系统边界和待确认问题。

如果存在待确认问题，请先停止，不要继续成文。

六、如果你愿意认真做：7 天只改造一项工作

30 分钟适合开工。

但如果你真的想把一个 Skill 打磨到能复用，我更建议做一个 7 天小练习。

重点仍然是：只改造一项工作。

不要同时改 PRD、周报、复盘、评审材料、会议纪要。

只选一个。

第 7 天不看你打卡多努力，只看有没有留下这 6 份证据：

改造前：旧方法或旧产物是什么样

V1：第一版 Skill 写了什么

失败记录：真实任务暴露了什么问题

诊断：问题属于哪一层，依据是什么

V2：只修改了哪一条规则

复测结果：相近任务中，问题消失、缓解还是仍然存在

能回答这 6 项，才算走完一次迭代循环。

如果只能回答“我觉得好像更好了”，那还不算。

这不是苛刻。

这是为了让你的经验真的能积累下来。

七、交接前，最后检查 4 个问题

当你准备把一个 Skill 发给同事、朋友或社群成员时，先别急。

让它回答这 4 个问题：

停下来后，要把问题交还给谁？

这四个问题能回答，才算具备最小交接条件。

注意，我说的是“具备交接条件”，不是“已经证明别人一定用得好”。

如果要证明别人也能正确使用，还需要独立试用、失败记录和复测结果。

这里我不夸大。

我现在更愿意承认：很多 Skill 不是不能分享，而是不该在没有边界说明、没有失败兜底、没有版本记录时就被当成“成熟工具”分享。

八、总结：一个人的经验，要靠证据变成可复用能力

回看这几篇，我们其实一直在做同一件事：

把一个人脑子里的经验，慢慢写成 AI 能执行、别人能理解、后续能迭代的规则。

第四篇，我们解决输出标准：

不要只说“像我写”，要拆成具体结构和验收标准。

第五篇，我们解决输入可信度：

信息不足时，Skill 要先暴露未知，而不是继续装懂。

第六篇，我们解决过程控制：

不要一口气写到底，要有确认节点和可回退流程。

这一篇，我们补上验证与交接：

失败要被记录，修改要能追踪，换一个人用时要知道边界。

这说明这篇目前对你还只是“看懂了”，还没有变成自己的工具。

回到第一个动作，选一个小任务，跑一次，记录一个问题，只改一条规则。

AI 协作真正拉开差距的地方，不是你有多少 prompt，而是你能不能把每一次失败都变成下一版规则。

灵魂拷问

评论区可以按这个格式留一句：

岗位 / 任务 / 最痛的一步

比如：

产品经理 / 需求初稿 / 每次异常场景都要等到评审后再补

下一篇，我会把这些常见失败整理成一棵“症状 → 病因 → 修复”的诊断树。

一个人的坑叫返工。

一群人的坑整理出来，才叫方法。

下期预告

系列二 · AI 协作 · 第 8 篇：AI 总是答得像对的，问题到底出在哪？

下一篇会把实践中最常见的失败整理成“症状 → 病因 → 修复”诊断树。

这篇先让你为自己的 Skill 留下版本记录；下一篇，我们再把不同人的失败记录放在一起诊断。