为什么 AI 项目失败，往往不是模型问题
0次浏览0条评论0个赞
评审会开到第 40 分钟，桌上三张验收表：业务写 P99 ≤ 800ms，技术写吞吐 ≥ 200 QPS，财务写单位成本减半。三张都没写错，合起来却无法验收同一个系统。
AI 项目失败，多数时候是没人先把「什么叫成功」写成同一句话，不是模型不够好。
先把失败链条拆成四步，再说判据。
结论：缺判据的代价不是选得不好，是选不出来
系列占位：正文待补——判断、框架与落点先固定。先回答一个问题：为什么指标全面达标的方案，会在评审会上被三方同时否掉？
缺判据的代价是选不出来，不是「选得不够好」 —— 会议开完仍然没有可执行的下一步。
反过来，一旦判据被写成同一句话，方案比较就重新变成技术问题：候选会自己往两三条路线收敛，而每个人知道自己那一条是否满足。 —— 这一屏在首页第二屏与第四屏各出现过一次 [1]，同一个问题在竞赛、售前、交付里的三次现身见 [2]。
骨架
-
多方冲突：业务要时延、技术要吞吐、财务要成本 —— 每条诉求都成立，指向的却是不同的技术选择。
-
判据缺失：没有人把「怎么算成」写成一句话，于是每一方都拿自己那把尺子验收。
-
方案无法收敛：没有共同判据，方案比较退化成立场比较 —— 谁声音大谁赢，或者干脆悬置。
-
统一判据之后如何收敛：把各方的底线收进同一张验收表，路线自然收敛到少数几个候选。完整过程见 [3]。
-
一个对照：同一个项目里，先定义判据与后定义判据的两次评审，分别停在什么状态（前者收敛，后者散会）。
小结与接下来
判据是让方案能收敛的那个动作，不是文档工作：没有它，会议开完仍然没有可执行的下一步；有了它，候选自己会往两三条路线收。
这一篇写完之后的下一站，是把它变成可复用的东西 —— 与首页第五屏同题。
参考文献
[1] 本站 · 首页第二屏「AI 项目里，模型能力往往不是瓶颈」（洞察来源） — /#home-layer-2
[2] 本站 · 首页第四屏「反复验证」：同一个问题在竞赛、售前、交付里的三次现身 — /#home-layer-4
[3] 本站 · 从三方冲突到四方对齐：一个运营商项目的判据定义过程 — /blog/from-three-parties-to-four-alignment/
相关文章
这篇的正文还没写完。
先把同一条线上已经写完的读完 —— 它们回答的是同一个问题。
评论
填个昵称就能发，不需要注册或登录