先说结论：这两天我对 DeepSeek 有点失望。
不是写得不好，不是推理退步。是一项我已经当成“自来水”的功能，突然拧开龙头没水了。
一个跑通过的功能，悄悄坏了
事情出在我做的一个 AI 研究日报上。
这个项目需要每天自动检索行业动态、整理资料、生成报告。我一直在琢磨怎么把本地那套研究流程搬到线上。火山方舟能联网，但实测下来，研究型任务给的那点搜索结果根本不够用——我要的不是十条链接，是能接着往下挖的资料。
然后自然想到 DeepSeek。
我手上还有一个正在做的研究工具，后面本来就打算让 DeepSeek 当研发主力。搜索、分析、写作都走同一套模型体系，架构简单，成本也低。算盘打得挺好。
结果日报项目里，DeepSeek 搜索直接跑不通。
一开始我以为是自己实现的问题。直到我翻出更早的一个项目做对照。
那个项目以前是真跑通过 DeepSeek 联网搜索的。历史文档、运行记录都还在。按常理新项目不行，老项目总得行吧，好歹有个参照。
老项目也不行了。
更离谱的是，模型开始直接往外吐它内部用的工具协议格式——相当于你点了个外卖，骑手没送餐，递给你一张后厨的进货单。
最后是拿 30 次 API 直连探针砸出来的结论：当前环境下，DeepSeek Responses API 的原生 web_search，根本没在执行。
Demo 只证明它成立过一次
真正让人难受的，不是“功能坏了”。
是它曾经真的能用。
一个进过真实项目、跑通过、留下过成功记录的能力，后来变成了不可依赖的状态。这种事在 AI 产品开发里特别典型，也特别危险。
我们总把 Demo 跑通当成“这个能力成立了”。
Demo 只证明它在某个时刻、某个模型版本、某个 API 状态下成立过一次。不代表稳定。更不代表供应商会一直维持同样的接口和行为。
搜索不能绑死在一家身上
这次之后我想明白一件事：AI 产品最核心的部分可能不是模型，是模型之外那些你觉得能省掉的基础设施。
对研究型产品来说，搜索尤其如此。
搜索不是锦上添花。它决定模型能看到什么。模型看不到正确的资料，后面的推理、事实核查、行业分析、写作，全是空中楼阁。
所以以后我不会再把搜索绑死在某一家大模型的内置工具上。
合理的结构是三层：搜索一层，模型一层，研究编排一层。DeepSeek 继续干推理和写作的活，哪天它原生搜索恢复了，也可以回来当一个搜索提供方。但它不能再是唯一的搜索提供方。
看起来多了一层开发成本。实际上是在买长期不被一家厂商卡死的保险。
AI 开发越来越像供应链管理
还有一个更深的教训。
研发里最危险的东西不是 Bug，是错误的前提。
老项目当初跑通过搜索，所以依赖它不算一个明显错误的决定。但这个决定底下压着一个没人说出口的假设：今天能用，明天大概率也能用。
AI 时代这个假设越来越像个笑话。
模型会换，接口会换，工具能力会换。连同一个模型名背后实际跑的是哪个版本，你都不一定知道。
于是 AI 开发越来越像供应链管理。
你不只是挑模型。你还要管搜索、OCR、ASR、向量、浏览器、工具调用分别来自谁，互相之间能不能替换，某一家突然调个参数、改个接口，你的产品会不会跟着一起瘫。
从“调用模型”到“做产品”
这件事对个人开发者尤其残忍。
大厂可以拉个团队专门维护兼容层。个人开发者每多接一家供应商，就多一份半夜起来救火的概率。但完全不做解耦呢？等于把整个产品押在上游厂商的一次产品调整上。
所以折腾到最后我反而接受了一件事：研究工具要真做成，必须拥有自己的检索层。
不是自己造搜索引擎。是自己掌握搜索能力的抽象和切换权。这跟“自己训练模型”完全是两码事。核心就一条：不能让任何一个供应商的临时能力，定义你产品的边界。
这次经历当然让人失落。
本来以为 AI 会让个人开发越来越轻，结果做到稍微复杂一点的产品才发现，很多被模型暂时盖住的基础设施问题，最后还是得回来补课。
但换个角度，这也是从“调用模型”走向“做产品”的分界线。
调用模型的人关心的是：这个模型今天能不能帮我把活干了。
做产品的人必须问：如果它明天不能了，我的产品还能不能活着。
这两个问题，从来就不是一回事。