AI 问答库
一句话回答
多数 AI 项目不是败在模型不够强，而是败在动手之前：需求没被定义成可验收的问题、数据根本没准备好、以及拿 AI 去绕开本该修的流程。典型表现是 demo 惊艳、上线后没人用。有效的预防办法是先建评测集、先挑一个边界清晰的小场景、并明确谁为业务结果负责，而不是先选模型。
下表把常见失败原因按「什么阶段会暴露」排开。规律很清楚：暴露得越晚，修复成本越高。需求含糊在启动时几乎没有代价，等到验收阶段才发现双方对「做成什么样」的理解不同，往往只能推倒重来。所以这张表最有价值的用法不是事后复盘，而是在立项评审时逐行对照 —— 每一行都能在动手前用一两个问题问出来。
| 失败原因 | 典型表现 | 什么阶段暴露 | 怎么提前避免 |
|---|---|---|---|
| 需求没定义成可验收的问题 | 双方都说「做完了」，但对「做成什么样」的理解不同 | 验收阶段，最晚也最贵 | 立项时就写下：用哪批真实问题验收、达到什么标准、谁判定 |
| 数据没准备好就开工 | 进度停在「还在调优」，反复调提示词却不见改善 | 开发中期，通常被误判为模型能力不足 | 先盘点首个场景涉及的语料：能否提取文本、有没有版本与时效、权限清不清楚 |
| 用 AI 绕开本该修的流程 | 上线后业务方还是走原来的老路，新系统成了摆设 | 上线后 1–2 个月，使用率自然衰减 | 先画现状流程图，确认卡点是「信息处理慢」而不是「审批链太长」 |
| KPI 定错，考核过程而非结果 | 调用量、接入部门数都很漂亮，业务指标纹丝不动 | 第一个考核周期结束时 | 把指标绑到原有业务口径上（返工率、处理时长、一次通过率） |
| 试点范围过大 | 需求方太多、口径互相冲突，改一处影响一片 | 开发中后期，表现为无法收敛 | 第一期只取一个边界清晰、有真实使用者、失败不影响主业的场景 |
| 交付后没人能维护 | 改一个提示词、加一类文档都要找原厂按人天计费 | 交付后 3–6 个月，随第一次业务变化暴露 | 签约前就要求后台配置界面、文档与一次真实交接培训 |
复盘失败项目时，最常听到的解释是「模型能力还不够」。但真去拆的话，大部分卡点落在检索没召回到正确段落、原始文档本身互相矛盾、或者业务方根本没同意改流程 —— 这些换成 Llama 4、Qwen 3.x、DeepSeek V4 还是 GPT-5 都一样。技术选型之所以被当成主因，是因为它是唯一一个可以由技术团队单方面决定、也最容易改的变量；而真正的主因（需求、数据、流程、责任）都需要业务方一起动，难度高得多。一个实用的自查方法：把失败原因写下来后问自己「如果明天换一个能力强一倍的模型，这个问题会消失吗」，如果答案是否，那它就不是模型问题。
第一步，选场景：边界清晰、有真实且愿意配合的使用者、失败了不影响主业。第二步，建评测集：请业务同事写下他们真实问过的问题和标准答案，这既是验收依据，也是后面每次改动的对照物。第三步，盘数据：确认这批问题涉及的文档能否提取成文本、有没有版本与生效日期、权限边界清不清楚 —— 这一步经常直接改变技术方案。第四步，定指标：用原有业务口径，不要发明新指标。第五步，才是选技术路线和模型。把顺序颠倒过来（先选模型再找场景）是最常见的开局错误，也是最难在中途纠正的。
适用边界
同义问法