拿埋点数据做 A/B 归因，得出「新功能上线后准确率掉了一大截」——被当场指出口径有问题。那个字段从头到尾只记录了其中一方的输出。

分类链路先是把菜单塞进 prompt 让模型背，然后改成给模型三个检索 tool 让它查。查准了，但要来回好几轮。最后量了一下体积：整棵子树直接给它就行。

客户发来的截图常常是唯一的故障证据。接入多模态时差点白写一整条取图链路；上线后又发现，PDF 和录屏在模型眼里全是「一张图片」——不是模型认不出，是取数层先把信息毁了。

扩展里做语音转写，云端要每人一个 API key，浏览器内 WASM 又太慢。最后落到 Native Messaging + 本机宿主——路上撞到的每一道墙，都是消息通道的尺寸与形状。

过滤器写错不报错，而是「看起来查到了全量」。在这样的接口上做相似检索，第一件事是验证你的过滤条件真的生效了。

三级分类树里 38% 的叶子重名，加分改变不了「同名无法区分」。于是先分流再打分——然后树被改了层级，锚点淹没了小系统，分词器切不开连写的中文。

把已有能力函数包成可编排的 tool 只是第一步。真正的设计在于副作用分级，以及「流程可以自主提交」和「LLM 可以自主调用提交」之间那条容易被抹平的界线。

同一件事，写死一条链和交给模型自己编排，差别不在能力上，在于出问题时你能不能定位到是哪一步。

「OpenAI 兼容」只保证形状兼容。真正会咬你的是那些它没说、而你也不会去试的地方——包括一个模型被下架后静默路由到别的模型。

从网页内注入面板改成浏览器级侧栏，换来的是不抢页面空间和不被宿主重建冲掉。代价是三个必须先知道的约束。