首页 / CC成长营 / 番外 · 真实案例库

真实案例库：6 个用 AI 造东西的血泪复盘

前面讲的是方法，这一讲是战场。下面 6 个案例全部来自真实生产环境（我们自己运营的产品），是真用户、真账单踩出来的坑。你不用了解这些产品——看的是判断和方法。这些经验，比任何教程都贵。

为什么这一讲值得反复看 用 AI 造东西，"做出来"只是第一步，"不出事、出了事能扛住"才是真本事。下面每个坑，都是当时以为没问题、结果代价惨重的——AI 不会主动提醒你这些，因为它们藏在"happy path"之外。

案例一：一个模型名被下线，整站挂了 10 小时

场景：一个语音 App 的翻译／润色／对话功能，全部调用某个大模型（用的是它的"预览版 preview"名字）。某天凌晨，模型厂商悄悄把这个预览版下线了。

发生了什么：模型名一失效，所有功能瞬间全挂——10 小时内 88 次调用全部失败。更糟的是：血流了 10 小时才被发现，因为没有任何报警，全靠用户反馈才知道出事。

根因：两个——①单点依赖：只挂一个模型名，它一变就全崩，没有任何备用；②用了随时可能被回收的 preview（预览）版模型名，而不是稳定的正式版（GA）。

带走的教训 ① 永远别把全部身家压在单一模型上——要做"fallback 降级链"：主模型挂了自动切同厂备用、再不行切别家模型；② 生产环境用正式版（GA），别用 preview；③ 比"没有 fallback"更致命的是"没有告警"——出事要主动短信／邮件通知你，而不是等用户来骂。fallback + 告警，必须一起做才算真修复。

案例二：让 AI 读图，它开始"鬼打墙"，吐了 17 万个点

场景：用视觉大模型（Vision）做 OCR——把文档图片里的文字提取出来。其中一页是带 3D 装饰的封面。

发生了什么：模型看到复杂的视觉背景，开始试图"描述纹理"，吐出 · . _ 这种单字符——然后停不下来（模型的注意力自我强化，下一个字符还是同一个的概率越来越高），一页图被抽成了 17 万个中点符号。污染从 OCR 一路扩散到翻译、存储、前端，查了三天才定位。

同一个项目还踩了第二个坑：输出被长度截断后，让模型"从刚才的地方继续"，结果它不听指令、直接从头重写一遍，导致前半段内容出现了两次。

带走的教训（用 LLM 做长文／OCR 必看） LLM 的输出天生不可靠，要多层防御：① Prompt 写死"只提取文字，不要描述视觉元素，禁止连续输出超过 3 个相同字符"；② 设最大输出长度硬上限，哪怕鬼打墙也会被截断；③ 运行时检测：发现连续大量重复字符就中断重来；④ "继续/续写"合并时按结构化标记去重，保留最后一次出现的版本。这些防御必须一开始就加，事后补代价高 10 倍。

案例三：删了一个"没人用的"接口，结果客户端还在偷偷调，挂了 18 小时

场景：清理"死代码"时，删掉了一个后端接口（/polish-plus），理由是"看数据这个接口没什么流量，应该是废弃的"。

发生了什么：其实手机端（Mac／iOS）的代码里硬编码还在调这个接口。删掉后，所有润色功能静默地返回 404 失败——用户付了钱、却发现润色没效果，而且没有明显报错。18 小时后才被发现。

根因：判断"没人用"的两个证据都不可靠——"产品说废弃了"是意图，不等于客户端代码真的删了调用；后台数据"看起来少"是另一条独立路径，跟这个接口的调用量根本不对应。

带走的教训（用 AI 改代码时最容易翻的车） ① 删／改／重命名任何接口、字段、函数之前，先全局搜索（grep）所有调用它的地方——尤其是别的项目、别的客户端。任何一处还在用 = 不能删。② "看起来没人用"不是证据，唯一可信的是真实的调用日志；没日志就别删。③ 真要退役老接口，走"先加废弃日志观察 → 公告 → 客户端迁移 → 最后才删"的多周流程。让 AI 帮你改代码时，一定要让它先搜全引用，再动手。

案例四：找到一个原因就喊"修好了"——结果修错了

场景：用户报告：界面明明显示还有余额（267 分钟），但一用就提示"额度用完了"。

发生了什么：第一轮排查，发现一个字段命名不一致的 bug，逻辑链看起来很通，于是改了、自信地宣布"修好了"。用户一测——问题还在。第二轮才挖到真因：另一个老函数在做额度检查时，漏掉了新套餐的判断，把付费用户当免费用户拒了。第一轮修的是个真 bug，但跟用户的问题无关。

根因：看到第一个"说得通"的原因就拼出完整故事、急着下结论——却忽略了一个明显矛盾：如果真是那个 bug，界面根本不可能显示出余额数字。这个矛盾本来就是"此路不通"的信号，被无视了。

带走的教训（AI 调试尤其要警惕） ① 用户给的每一条线索都必须被你的结论解释——只要有一条对不上，结论就不完整，别急着修；② "显示一个值、行为是另一个值"= 一定是两条独立的代码路径，两条都要查；③ 宣布"修好了"之前，亲自把完整链路跑一遍验证，别凭推理就说好了。AI 特别爱"找到一个原因就说搞定"——你必须逼它（和自己）验证到底。

案例五：自动部署"成功"了，服务却崩了

场景：一次自动部署，日志显示"构建成功、上传成功、容器启动"——一切看起来都正常。

发生了什么：服务其实在不停崩溃重启（接口全挂数小时），报错 Cannot find module './lib/llmFallback'。原来这次新增了一个文件 lib/llmFallback.js，主程序引用了它——但部署脚本的"要上传的文件清单"是写死的，没包含 lib/ 目录，于是新主程序上去了、它依赖的新文件没上去，一启动就找不到模块。

带走的教训 ① "部署成功"≠"服务正常运行"——部署后必须有真实的健康检查（实际打一次接口看通不通），别看到"启动"俩字就放心；② 自动化里写死的清单/配置，是隐形地雷：每次新增文件、新增依赖，都要回头确认自动化流程会带上它；③ 这正是第 8 讲（自动化）反复强调的——无人值守的流程，必须自己会"报警"，而不是悄悄出错。

案例六：辛辛苦苦省钱，却省错了地方——97% 的成本在你没看的那一项

场景：一个每天自动跑的内容分析流水线，包含好几个环节：联网探测、AI 写作、AI 校验。想降低它的运行成本。

发生了什么：一量化才发现：整条线一天约 ¥1.4（$0.20），其中 97% 的钱花在"联网探测"这一个环节（它按次收高额抓取费），而 AI 写作 + 校验加起来一天才几分钱。如果凭直觉去"优化那个看起来很贵的写作模型"，累死也省不下钱——真正该动的是探测环节的频次。

带走的教训（成本工程的第一课） ① 优化前先量化：把每个环节的真实成本拆出来，看占比——别凭感觉猜哪里贵；② 只砍占大头的那一项（这里是 97% 的探测费），其余的优化纯属浪费精力；③ 这跟第 2、3 讲的成本思维一脉相承——钱要花在刀刃上，省也要省在刀刃上。

6 个案例，一条主线

案例	一句话教训
① 单点故障	别押单一模型，要 fallback + 告警
② LLM 输出陷阱	LLM 输出天生不可靠，多层防御从一开始就加
③ 删接口翻车	改／删任何接口前，先全局搜所有调用方
④ 调试早停	所有线索都要被解释，修完亲自验证
⑤ 部署假成功	"部署成功"≠"服务正常"，要真实健康检查
⑥ 成本省错地方	先量化成本占比，只砍大头

✓ 把这条主线刻进脑子 六个坑，本质是同一句话："看起来没问题"不等于"真没问题"——必须用真实证据（日志、数据、健康检查、成本拆分、全局搜索）去验证。AI 让你造东西快了 10 倍，但它不会替你承担"出事"的后果。这份"凡事验证"的工程纪律，才是你和"只会让 AI 写代码"的人之间，真正的差距。

← 上一讲第四部分 · 综合实战第二辑 →6 个更高阶的判断