📔 笔记整理 · 🌿 生长中 · 图例见 本站的诚实规则
一句话经验：越靠近协议、解析、状态机、流式传输、格式转换的代码，越不能让低级模型“凑一个能跑的”。这类代码一旦错，症状会出现在很远的上层，排查成本可能远高于一开始就用高级模型认真写。
亲历的一个 bug
我的一个 AI 聊天界面项目出现渲染问题。起初以为是渲染方案不成熟，切换到更成熟的 Markdown/LaTeX 渲染管线，问题依然存在；AI 一度判断为“大模型输出有问题”。换了模型之后才发现，真正的根因既不是渲染库也不是模型质量，而是底层 SSE 流式拆包逻辑错了。
具体来说：拆包函数用花括号计数来处理“代理把多个 SSE JSON 合并到一行”的情况，但没有判断当前字符是否位于 JSON 字符串内部。于是正文里的 LaTeX 花括号也被当成结构花括号参与计数，深度下溢，payload 在错误位置被切分，JSON.parse 抛错，代码又用 continue 把整条 delta 静默丢弃。公式里的闭合花括号就这样一个个丢掉，最后渲染出错位的公式。
这个 bug 难查在它有五层误导：底层错误发生在拆包；异常被静默吞掉；中层表现为内容残缺；上层表现为公式渲染错误；最外层看起来像“模型输出 LaTeX 不稳定”。底层协议解析不可靠，上面所有的模型、渲染、补全、清洗逻辑全被污染。
核心判断
这不是某个模型优劣的问题，是一个通用的工程判断：低级模型可以写低风险、可直接验证、局部失败不会污染全链路的代码；但协议解析、流式增量处理、各类转义、状态机、并发一致性、数据迁移、鉴权支付、错误处理与重试，这些必须交给强模型设计、实现和审查。
这些代码的风险不在于“写不出来”，而在于“看起来能跑，但在边界条件下悄悄损坏数据”。
按风险分配模型：文案、样式、批量整理给便宜模型；普通业务代码给中高模型；协议、解析、状态机、数据一致性、疑难 bug 根因定位给强模型全程参与。关键不是“只用贵模型”，而是把正确等级的模型放在正确风险等级的任务上。
企业用 AI 同理：不是越省越好。低风险任务追求低成本和速度，核心链路交给低能力模型生成，后续排错、返工、客户损失的成本可能更高。AI 时代的管理者要学会判断任务风险，而不是只会问“哪个模型便宜”。