输出失败诊断树
面对 AI「答得像对的」或整体效果不好时，先命名症状，再按输入 / 过程 / 输出 / 验证四层路由，只打一条规则补丁并用相近任务复测——把返工变成可归因的诊断证据。
简介
输出失败诊断树来自 Zoe「AI 协作」系列二第 8 篇，是对“这次效果不好”这句话的手术刀。很多人改 AI 工作流时第一反应是继续优化 prompt、加角色、加模板、调语气；但“效果不好”可能是完全不同的病：写空、编造、中途跑偏、形态不可交付、细查才出错、换任务失效。若层判错，修错层只会让错误更完整、更像正确答案。
诊断树不追求把问题变复杂，而是挡住三类常见误判：把输入问题当输出问题、把过程问题当模型问题、把验证问题当文风问题。它与 Skill 版本记录 同一逻辑——一次只改一条、必须复测、结果可归因——但更前置：在改规则之前，先给失败命名并判定主因层。
关键信息
- 类型：概念 / 方法论
- 领域：AI 协作 · Skill 维护 · 产品经理工作流
- 适用对象：PRD/需求初稿、方案文档、Agent 中间产物、任何“看起来完整但返工”的 AI 输出
- 前置依赖：已有一份真实失败输出（不要从空想优化开始）
- 相关概念：Skill、Skill 版本记录、Skill 交接条件、事实标签、提示词工程、HITL
核心特性
定义
输出失败诊断树 = 症状命名 + 四层主因路由 + 最小规则补丁 + 四态复测。它不是新的模型能力，而是人机协作中的质量工程习惯：先定位，再动刀。
六类症状（先命名，禁止写“效果不好”）
| 症状 | 典型表现 | 常误修方向 |
|---|---|---|
| 空泛 | 像行业百科，缺业务事实与边界 | 加“更专业、更全面”→ 更有条理地空 |
| 编造 | 未确认规则被写成事实 | 只改语气/格式，不拦无源判断 |
| 跑偏 | 前面理解错，后面一路跟着错 | 只改最终输出模板 |
| 不可交付 | 有用段落存在，但形态进不了文档/评审 | 继续堆内容长度 |
| 难复核 | 看起来完整，细查才发现例外与边界漏了 | 调“更像自己的文风”→ 错误更难发现 |
| 换任务失效 | 本任务好用，相近任务失效 | 针对单样本硬编码规则 |
四层主因（路由口诀）
- 输入层：事实不够——缺业务规则、系统能力、授权状态、范围边界
- 过程层：中途跑偏——缺检查点、缺“待确认先停”、中间判断错后仍写完
- 输出层：有用但不好交付——结构、章节、粒度、交付形态不对
- 验证层：看不出错——缺自查清单、事实标签、例外场景与边界检查
诊断树决策路径
- 最明显症状是哪一类？（六选一）
- 关键判断有没有事实来源？无 → 输入；有 → 继续
- 是否在某中间判断后开始跑偏？是 → 过程；否 → 继续
- 内容有用但形态不能交付？是 → 输出；否 → 继续
- 需人工细查才发现？是 → 验证；否 → 回到症状重判
最小修复与复测四态
- 只改一条规则：例如“触达渠道/发送能力/用户授权未提供时，不得写入短信/邮件/站内信方案，须列为待确认并说明影响章节”
- 复测用相近不同任务：验证迁移，而非背题
- 结果四态：消失 / 缓解 / 无效 / 转移（原问题好了但出现新副作用）
与相近概念的区别
| 概念 | 回答的问题 | 与诊断树关系 |
|---|---|---|
| 提示词工程 | 怎么写得更好 | 诊断树要求：未命名失败前不要继续堆 prompt |
| Skill 版本记录 | 改了什么、为何改、怎么验证 | 诊断树产出可直接填进版本工单 |
| Skill 交接条件 | 别人何时能用、何时必须停 | “未确认不得成文”是交接停止边界的具体补丁形态 |
| 事实标签 | 输出里哪些是事实/推断/待确认 | 编造与输入层问题的主治理手段 |
| 幻觉治理方案 | 模型胡说怎么办 | 诊断树先问：是输入缺事实还是验证缺清单，而不是默认换模型 |
不同素材中的观点
- 2026-07-19-woshipm-ai-output-failure-diagnosis：完整给出症状六类、四层口诀、五步诊断树、修复工单字段、30 分钟练习与匿名案例回流格式。核心主张：低质量输出不是一种病；最小修复 + 四态复测比“感觉好多了”更有用；群体结构化失败会沉淀成方法。系列下篇将从单点诊断扩展到多 Skill 流水线交接。
实用信息
修复工单（可直接复制）
失败样本：
这次症状：（空泛/编造/跑偏/不可交付/难复核/换任务失效）
主因层级：（输入/过程/输出/验证）
判断证据：
本次只改：（一条规则）
复测任务：（相近但不同）
复测结果：（消失/缓解/无效/转移）
新问题：
下一步：30 分钟练习节奏
- 5 分钟：选最近返工输出
- 5 分钟：命名六类症状之一
- 10 分钟：判唯一主因层并写证据
- 5 分钟：只写一条规则补丁进 Skill / 指令
- 5 分钟：选定复测任务与观察点
避坑
- 不要在未命名症状时重写整份 Skill
- 不要一次改多层规则，否则无法归因
- 不要用同一任务“再跑一次”当复测
- 不要把“转移”误判成成功——原问题消失但新副作用出现时，要记入下一版
- 不要把验证层问题当文风问题：语气越像自己，错误可能越难被发现
完成标志
不是 Skill 变完美，而是留下四条证据：症状是什么；病因在哪一层；本次只改了什么；复测要观察什么。