一家被很多人以为“早就消失”的互联网老牌公司最近重新出现在科技新闻里。雅虎计划借 AI 工具重振业务CEO 兰佐内Jim Lanzone给出的理由不是“我们掌握了多强的模型”而是“复古就是最大优势”。这句话乍听像是给业务老化找台阶但放到今天的 AI 落地语境里它其实说出了一个关键事实当大模型能力趋于标准化真正稀缺的是稳定场景、历史数据和用户信任而这三样东西恰好在老产品身上最集中。这篇文章不打算预测雅虎能否翻盘而是想从中拆出一个可复用的思考框架为什么“复古”在 AI 时代可能不是劣势传统产品接入 AI 时哪些资产值得优先变成模型能力如果我们的团队也要给一个老产品加入 AI 问答或 Agent 能力应该先做什么、怎么评估、怎么安全上线为了不空谈我会在第 5 章用一个 FastAPI LLM 的最小项目演示“给老门户加入 AI 助手”的工程套路并给出完整的验证和排错方法。1. 雅虎的 AI 转型为什么值得技术人关注过去几年几乎每一家互联网公司都宣布过“All in AI”。雅虎的表态之所以值得单独讨论是因为它代表的不是创业公司从零找场景而是一个有二十几年历史、上亿存量用户的旧产品体系要在不破坏既有体验的前提下完成 AI 升级。这类问题在传统行业同样普遍银行、运营商、教育、医疗、传统电商大量团队手里的系统都是“老产品”都面临同一个问题——大模型到底应该先加在哪个入口上从很多 AI 改造项目来看最常见的失败不是技术选型出错而是没有想清楚“旧产品里什么资产值得被 AI 放大”。雅虎 CEO 提到的“复古优势”恰好回答了这个问题。对技术团队来说这则新闻最有价值的部分是把讨论从“模型能力”拉回到“业务场景”上。这篇文章适合三类读者。第一类是 AI 应用开发工程师想了解老牌产品做 AI 改造的通用路径第二类是传统 IT 团队的技术负责人正在评估是推倒重来还是增量改造第三类是 AI 产品经理需要一套可复用的场景优先级判断方法。如果你只是关心雅虎的商业结局那本文不是那个方向。2. “复古就是最大优势”到底在说什么2.1 先看看雅虎手里的存量资产雅虎创立于 1994 年最早以网址导航和搜索起家后来演变成集邮箱、新闻、财经、体育等于一体的门户。它经历了搜索大战的失利、多轮易主也正因如此很多人的第一反应是一个“过气”品牌拿什么跟新一代 AI 公司竞争但如果拆开“复古”这个词会发现它的底层资产并不弱。资产类型典型表现对 AI 改造的潜在价值用户规模与信任邮箱、财经、体育等频道仍有大量用户新功能无需从零做冷启动老用户更可能尝试明确的使用场景查邮件、看行情、看比分、读新闻用户意图清晰适合 AI 问答和 Agent 化历史知识与内容库多年新闻、行情、赛事、帮助文档可作为 RAG 知识库减少模型幻觉老牌门户的心智很多用户仍把门户当作互联网“入口”AI 助手可以承接“入口”角色形成新的交互路径当然这些资产只有在合规使用的前提下才有价值。尤其是用户行为数据必须在隐私授权、数据安全、最小化采集的框架内使用。任何打着 AI 旗号的“数据再利用”一旦越过合规边界风险都远大于收益。2.2 “复古”不是保守而是差异化定位如果只看表面很容易把“复古”理解成“什么都不改”。实际上兰佐内的意思更接近雅虎不需要模仿年轻社交产品而是把已经被验证的经典场景用 AI 重新做一遍。这个策略背后的逻辑是AI 能力本身很难成为长期差异化因为大模型 API 谁都能买开源模型谁都能部署真正难复制的是“什么场景 什么数据 用户为什么信任你”。这也是雅虎案例对传统技术团队最重要的一个启示很多遗留系统的价值不在于代码多新而在于它沉淀了公司十几年的业务规则、历史数据和用户习惯。直接推倒或换肤等于把这些资产清零。更稳的打法是在老入口旁边加一个新的 AI 能力让用户原来的路径不变但每一步都更省事。2.3 “复古”策略也有明显风险需要客观说的是“复古优势”并不保证成功。如果 AI 改造只是做个聊天机器人挂在首页不解决用户真正的问题老用户会更快离开。大模型输出还有幻觉、延迟、成本问题老产品如果组织流程跟不上AI 从实验到上线可能需要太久。所以接下来两件事很关键改造路线怎么设计工程过程怎么控制。3. 从报道中拆解雅虎 AI 改造的三类技术动作截至目前能看到的公开信息更多是方向和口号具体产品形态还没有完全定型。下面三类技术动作是基于雅虎的存量业务和 AI 能力结合行业常见实践做的合理推断不代表官方路线图。但对很多门户、内容平台和传统软件公司来说这三类动作几乎可以平移复用。3.1 搜索与内容分发的语义化改造门户产品的流量入口是搜索、信息流和首页。传统做法依赖关键词匹配和编辑推荐用户表达自然语句时召回效果很差。引入大模型后首先是 Embedding 层的改造把文章、视频、帮助文档全部向量化用户查询也向量化然后做语义召回其次是大模型摘要比如阅读一个企业财报或一支球队的赛后报道时在链接下生成一段摘要。这一块的工程重点不在模型调参而在数据管道内容更新后多久能进向量库搜索延迟是否能控制在用户可接受范围。如果在老系统上做还要考虑原有的倒排索引和语义召回如何共存通常的做法是“关键词召回 向量召回”双通道融合而不是直接替换。3.2 邮箱与生产力助手的 Agent 化雅虎邮箱是历史最悠久的业务之一。邮箱场景非常适合 AI因为它有明确的用户行为读信、回信、归类、找附件、设置日程。规则系统可以完成“按发件人分类”但无法理解“这封邮件里提到的会议邀请是否和日程冲突”。引入 LLM 后可以摘要长邮件、生成简短回复、从邮件中抽取待办并调用日历工具。这个方向会逐步从“提示词问答”升级为真正的 Agent模型负责理解和规划工具调用负责执行。工程难点是模型错误调用工具的兜底和权限控制。例如 AI 可以草拟回复但不能在没有用户确认的情况下直接发送Agent 访问日历前需要明确的最小权限授权。这些约束比模型本身更需要提前设计。3.3 广告与用户洞察的智能化雅虎很重要的收入来源是广告。传统广告系统依赖画像标签和规则匹配AI 能做的事包括自动从广告主素材生成多组文案用大模型理解网页正文做更好的上下文匹配用预测模型优化出价和排序。这块的约束是隐私与合规要做的是在数据安全的前提下做特征自动化而不是越权使用敏感信息。小结一下这三类动作的共同点不是“把模型塞到现有业务里”就完事而是都要配套做数据管道、评估体系、权限边界和成本控制。这也是下面要展开的通用决策框架。4. 传统产品接入 AI 的通用决策框架4.1 场景盘点和优先级打分在给老产品接 AI 之前先做盘点。步骤包括列出用户高频路径标记每个路径上的痛点评估数据可得性、错误容忍度和上线复杂度最后给出试点结论。场景示例用户价值数据可得性错误容忍度上线复杂度结论邮件自动分类高高中中优先试点新闻内容语义摘要高高中高低优先试点股价预测问答高中低高暂缓或辅助定位自动代发邮件高中低高暂缓需要人工确认错误容忍度是一个经常被低估的指标。面向外部用户的金融建议、医疗建议、代发消息容错率极低不适合第一个上而帮助文档检索、邮件摘要这类场景模型即使偶有不完美用户容忍度也更高适合当作第一个落地场景。4.2 技术选型不是所有场景都需要大模型选型时有一个经验原则能用规则解决的问题不要用模型能用轻量模型解决的问题不要直接上大模型确实需要语义理解和生成的地方才用大模型。常见路线可以按复杂度分成四档。第一档是规则和传统机器学习适合意图明确、标签可控的文本分类第二档是基于 Embedding 的语义检索适合 FAQ 匹配、内容召回第三档是 RAG适合“知识库 生成回答”的场景第四档是 Agent适合需要调用工具、多步完成任务的场景。大模型不是万能药也不是越大的模型越好关键看单位成本能带来多少业务收益。4.3 架构取舍增量改造而不是推倒重来老产品的改造要尽量避免把核心链路一次性替换掉。更稳的做法是加一个 AI 能力层在原有业务前面做一个代理或网关AI 结果和旧逻辑并行通过开关和灰度比例控制流量。这样即使模型效果不达预期也能快速回滚到旧逻辑用户损失很小。同时AI 能力层要负责三件事请求日志、模型调用成本统计、结果兜底。很多项目在实验阶段效果不错上线后却因为没人看到线上质量而悄悄回退根本原因就是缺少这一层可观测性。5. 最小实践给一个传统门户产品加入 AI 问答助手从这一章开始进入代码实操。我们要做一个最小但完整的“老门户 AI 助手”原来的形态是网站的静态 FAQ 页面现在把它升级成POST /ask接口支持检索知识库并回答问题同时提供MOCK_MODE让没有大模型 API 的读者也能跑通接口。5.1 需求与目录结构需求设定如下一个传统门户网站原本用静态 FAQ 页面回答用户问题内容包含邮箱密码找回、财经行情查询、体育比分。现在我们希望用户能够用自然语言提问系统能结合 FAQ 知识库准确回答并且保留原有的 FAQ 页面作为兜底。目录结构legacy-portal-ai/ ├── app.py ├── evaluate.py ├── requirements.txt ├── .env.example └── README.md本文只需要关注app.py、evaluate.py、requirements.txt和.env.example。5.2 环境准备建议使用 Python 3.9 或更高版本。先创建虚拟环境并安装依赖mkdir legacy-portal-ai cd legacy-portal-ai python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate依赖文件内容如下