这是「AI 协作」系列二第 8 篇。上一篇让你为 Skill 留下失败、修改和复测记录；这一篇继续往前走，把“AI 效果不好”拆成一棵“症状 -> 病因 -> 修复”的诊断树。

读完这篇，你不需要立刻重写整份 Skill。先拿最近一次失败输出做一件事：给失败命名，判断主因，只改一条规则，再用相近任务复测。

同样是“不好用”，症状不是一种

很多人改 AI 工作流时，第一句复盘都是：

“这次效果不好。”

这句话很真实，但对修复几乎没有帮助。

因为“效果不好”可能指的是完全不同的事情：

• 它写得很空，像行业百科；
• 它把没有确认的规则写成了事实；
• 它前面理解错，后面一路跟着错；
• 它有几段内容可用，但不能直接放进文档；
• 它看起来完整，细查才发现例外和边界都漏了；
• 它在这个任务上好用，换个相近任务就失效。

这些症状不能用同一种方式修。

如果问题是输入层缺事实，你继续加“更专业、更全面”，它只会更有条理地空泛。

如果问题是过程层没有检查点，你继续改输出格式，它还是会在中途判断错以后写完整篇。

如果问题是验证层缺清单，你把语气调得再像自己，也只是让错误更难被发现。

所以第八篇的第一步，不是继续优化 prompt，而是先问：

这次失败，到底是哪一种失败？

低质量输出不是一种病。先命名症状，才知道下一刀该落在哪里。

先别改 prompt，先问四层

前几篇我们已经拆过四层：

记不住时，可以先用四句话：

• 事实不够，先查输入。
• 中途跑偏，先查过程。
• 有用但不好交付，先查输出。
• 看不出错，补上验证。

这一篇要做的，就是把这四句话变成一张诊断表。

一棵输出失败诊断树

当你拿到一份失败输出，不要急着改。先顺着下面这组问题往下查：

1. 这次最明显的症状是什么？

– 空泛 / 编造 / 跑偏 / 不可交付 / 难复核 / 换任务失效

2. 输出里的关键判断有没有事实来源？

– 没有：先查输入层

– 有：继续看过程

3. 它是在某个中间判断后开始跑偏的吗？

– 是：先查过程层

– 否：继续看输出

4. 内容本身有用，但形态不能交付吗？

– 是：先查输出层

– 否：继续看验证

5. 问题需要人工细查才发现吗？

– 是：补验证层

– 否：回到症状，重新判断主因

诊断树不是为了把问题变复杂，而是为了避免一个常见误判：

把输入问题当成输出问题，把过程问题当成模型问题，把验证问题当成文风问题。

六类常见症状怎么修

下面这张图是第一版修复地图：每类症状先只改一条规则，再看一个复测信号。表格保留为文字版细项。

注意，这里说的是“最小修复”。

不要一次把输入、流程、格式、语气、检查清单全改掉。那样看起来很努力，但下一次变好时，你不知道到底是哪条规则起了作用；下一次变差时，你也不知道是哪条规则带来了副作用。

别一次改太多：只做一条规则补丁

第七篇讲过版本记录，这一篇把它变成更轻的一张修复工单：

失败样本：

这次症状：

主因层级：

判断证据：

本次只改：

复测任务：

复测结果：

新问题：

下一步：

举个脱敏合并示例。

如果 AI 在“积分过期提醒”里自动写了短信提醒方案，但输入里根本没有确认短信能力和用户授权，这次不要顺手改完整 PRD。

只补一条规则：

当触达渠道、发送能力或用户授权状态未提供时，不得写入具体短信、邮件、站内信方案。

请先列为待确认项，并说明会影响哪些章节。

然后用一个相近任务复测，看它是否还会把未确认渠道写成正式方案。

复测结果只分四类：

• 消失：原问题没有再出现；
• 缓解：问题减少，但仍有残留；
• 无效：问题照旧；
• 转移：原问题好了，但出现了新副作用。

这比一句“感觉好多了”更有用。

30 分钟修复一份失败输出

今晚可以不用大改 Skill，只做一次最小练习：

1. 5 分钟选样本：找一份最近让你返工的 AI 输出。
2. 5 分钟命名症状：不要写“效果不好”，从六类里选最像的一类。
3. 10 分钟判断主因：输入 / 过程 / 输出 / 验证，先选一个主因。
4. 5 分钟写规则补丁：只改一条。
5. 5 分钟设计复测：找一个相近但不完全相同的任务。

完成标志不是“这份 Skill 变完美了”，而是你留下了一条可以继续积累的证据：

• 症状是什么；
• 我判断病因在哪一层；
• 我这次只改了什么；
• 复测时要观察什么。

把翻车案例带回来

如果你愿意把案例匿名留下来，可以按这个格式：

岗位 / 任务 / 输出症状 / 你已经尝试过的修复 / 仍然卡住的地方

比如：

产品经理 / 需求初稿 / 异常场景总是漏 / 已经补了模板结构 / 还是不知道怎么让它主动追问例外

不需要提交敏感业务数据，也不需要贴完整原文。

这一篇先给诊断表。后面如果积累到足够多的授权样本，我会把不同岗位的失败记录放在一起做案例会诊。

一个人的失败，是一次返工。

一群人的失败被结构化记录下来，就会变成一套方法。

下期预告

系列二 · AI 协作 · 第 9 篇：把 5 个 Skill 串成一条需求流水线。

这一篇解决的是单个输出失败时怎么诊断。

下一篇，我们不再只看一个 Skill，而是看多个 Skill 之间怎么交接：上一环交什么，下一环才能接；哪里必须停下来让人确认；哪些输出不能自动流入下一步。

单点问题诊断清楚以后，才谈得上把它们串成稳定工作流。