AI 总是答得像对的，问题到底出在哪？
Zoe「AI 协作」系列二第 8 篇：把“效果不好”拆成症状 → 病因 → 最小规则补丁 → 复测的诊断树，避免把输入问题当输出问题、过程问题当模型问题。
基本信息
- 标题：AI 总是答得像对的，问题到底出在哪？
- 作者：Zoe产品手记
- 来源：人人都是产品经理
- 日期：2026-07-16
- 原始链接：https://www.woshipm.com/ai/6430451.html
- 原始素材：
raw/articles/2026-07-19-094048-tg-71747c.md - 处理说明：Telegram bot 先写入 URL 桩（msg 2079）；本次用 baoyu-url-to-markdown（headless + defuddle）抓取正文并回填桩文件；extract 备份
raw/extracts/20260719-102409/woshipm.com/ai.md。
核心观点
- “效果不好”不是一种病，先命名症状才知道下一刀落哪。空泛、编造、跑偏、不可交付、难复核、换任务失效是六类不同症状；同一句“这次不好用”可能对应完全不同的修复路径。
- 先别改 prompt，先问四层：事实不够先查输入；中途跑偏先查过程；有用但不好交付先查输出；看不出错补上验证。把四句话落成诊断表，避免层间误判。
- 诊断树按症状 → 事实来源 → 中间判断 → 交付形态 → 是否需细查 往下走；常见误判是：输入问题当输出问题、过程问题当模型问题、验证问题当文风问题。
- 最小修复：只做一条规则补丁。一次改输入/流程/格式/语气/清单，变好时无法归因、变差时无法定位副作用。复测结果只分四类：消失 / 缓解 / 无效 / 转移。
- 30 分钟即可修一份失败输出：5 分钟选样本 → 5 分钟命名症状 → 10 分钟判主因层 → 5 分钟写一条规则 → 5 分钟设计相近任务复测。完成标志是留下可积累证据，不是把整份 Skill 改完美。
- 失败要结构化回流：岗位 / 任务 / 输出症状 / 已尝试修复 / 仍卡住的地方；个体返工 + 群体结构化记录 → 方法。下期预告：把 5 个 Skill 串成需求流水线（交接与人确认点）。
实操内容保留
诊断树（拿到失败输出后按序问）
- 最明显症状是什么？— 空泛 / 编造 / 跑偏 / 不可交付 / 难复核 / 换任务失效
- 关键判断有没有事实来源？— 没有 → 先查输入层；有 → 看过程
- 是否在某个中间判断后开始跑偏？— 是 → 先查过程层；否 → 看输出
- 内容本身有用，但形态不能交付？— 是 → 先查输出层；否 → 看验证
- 问题需要人工细查才发现？— 是 → 补验证层；否 → 回到症状重判主因
四层速记
- 事实不够，先查输入。
- 中途跑偏，先查过程。
- 有用但不好交付，先查输出。
- 看不出错，补上验证。
修复工单模板
失败样本：
这次症状：
主因层级：
判断证据：
本次只改：
复测任务：
复测结果：
新问题：
下一步：最小规则补丁示例（积分过期提醒 / 未确认短信能力）
当触达渠道、发送能力或用户授权状态未提供时，不得写入具体短信、邮件、站内信方案。
请先列为待确认项，并说明会影响哪些章节。
然后用相近任务复测：是否仍把未确认渠道写成正式方案。
30 分钟最小练习
- 5 分钟选样本：最近让你返工的 AI 输出
- 5 分钟命名症状：从六类里选最像的一类，禁止写“效果不好”
- 10 分钟判断主因：输入 / 过程 / 输出 / 验证，先选一个
- 5 分钟写规则补丁：只改一条
- 5 分钟设计复测：相近但不完全相同的任务
匿名案例回流格式
岗位 / 任务 / 输出症状 / 你已经尝试过的修复 / 仍然卡住的地方
例：产品经理 / 需求初稿 / 异常场景总是漏 / 已经补了模板结构 / 还是不知道怎么让它主动追问例外
关键概念
- Skill — 本文把 Skill 维护从“继续优化文风”拉回“按层诊断 + 单规则补丁”
- Skill 版本记录 — 修复工单是第 7 篇版本证据的更轻落地形态
- Skill 交接条件 — 停止条件、待确认项与本篇“未确认不得写成方案”直接衔接
- 输出失败诊断树 — 本文主贡献：症状命名 + 四层路由 + 最小修复
- 事实标签 — 与“无事实来源先查输入 / 待确认项”同构
- 提示词工程 — 明确反对在未命名失败前继续堆 prompt
与其他素材的关联
- 与 2026-07-08-woshipm-skill-validation-version-handoff 为同一系列前后篇：第 7 篇要求失败/修改/复测记录；本篇把“效果不好”拆成可操作的诊断树与 30 分钟工单。
- 与 2026-07-18-bnext-ai-agent-reverse-workflow 互补：Wesley 强调过程断点与 ROI 闸门；本文强调单点输出失败时如何定位层与最小改规则。
- 与 2026-07-16-woshipm-ai-hallucination-3-solutions 交叉：幻觉/编造可映射到输入事实不足或验证层缺失，而非一律“模型不行”。
- 与 2026-07-17-woshipm-course-consulting-assistant-3-iterations 同构：演示通过 ≠ 可用；本篇要求复测四态（消失/缓解/无效/转移）而不是“感觉好多了”。
原文精彩摘录
如果问题是输入层缺事实，你继续加“更专业、更全面”，它只会更有条理地空泛。如果问题是过程层没有检查点，你继续改输出格式，它还是会在中途判断错以后写完整篇。如果问题是验证层缺清单，你把语气调得再像自己，也只是让错误更难被发现。
诊断树不是为了把问题变复杂，而是为了避免一个常见误判：把输入问题当成输出问题，把过程问题当成模型问题，把验证问题当成文风问题。
不要一次把输入、流程、格式、语气、检查清单全改掉。那样看起来很努力，但下一次变好时，你不知道到底是哪条规则起了作用；下一次变差时，你也不知道是哪条规则带来了副作用。
一个人的失败，是一次返工。一群人的失败被结构化记录下来，就会变成一套方法。