7.4
深览指数
成长人人都是产品经理·Zoe产品手记··AI 生成
AI 总是答得像对的，问题到底出在哪？
这是一篇面向重度 AI 协作用户的实操方法论，核心贡献在于将模糊的「AI 输出不好用」拆解为六类具体症状（空泛、编造、跑偏、不可交付、难复核、换任务失效），并对应到输入、过程、输出、验证四个排查层级。文章提供了一套「先命名症状→判断主因→只改一条规则→用相近任务复测」的最小修复流程，避免用户陷入同时修改多项规则却无法归因的困境。适合已经搭建过 AI 工作流、正面临输出质量瓶颈的产品经理、内容创作者等认真使用 AI 工具的人群。原文 ↗
核心观点
- ▍AI 输出效果不好不是一种病，而是至少六类不同症状（空泛、编造、跑偏、不可交付、难复核、换任务失效）的集合，必须按症状归因到输入/过程/输出/验证四个层级，才能有效修复。
- ▍一次只改一条规则并做复测，比同时修改多项规则更有效，因为前者能让你知道哪条变更真正起了作用。
- 01文章提供了一个「输出失败诊断树」：先判断最明显症状→检查关键判断是否有事实来源→是否在中间判断后跑偏→内容形态是否可交付→是否需要人工细查才发现问题，逐层定位主因。
- 02修复地图给出了六类症状的最小修复方案示例，例如对于「空泛」问题，检查输入缺少哪些具体信息并补充；对于「跑偏」问题，在过程层增加一个中间检查点。
- 03建议用户使用结构化的「修复工单」记录：失败样本、症状、主因层级、判断证据、本次只改、复测任务与结果、新问题与下一步。
- 04复测结果只分四类：消失、缓解、无效、转移，比模糊的「感觉好多了」更有诊断价值。
- 05举了一个脱敏案例：AI 在「积分过期提醒」任务中自动写入短信方案，但输入缺少短信能力和授权信息，修复规则是要求未提供时「不得写入具体方案，列为待确认项」。
反方 / 局限
- — 文章设定的「修复一次只改一条规则」在真实复杂工作流中可能面临效率问题：面对频繁变动的业务规则，用户可能无法承受逐条修复的迭代速度。
7 分钟 · 4 卡片 · 8 资料
读原文 →