2026-05-11 22:22
扫码打开虎嗅APP
本文来自微信公众号： 云算计 ，作者：曹亚孟
我发了《分析产品经理》的文章后，既有新朋友做友善沟通，也有一些破防的产品文档助理说我吹牛。我在看机会的过程中，也经常被质疑“你没做过AI产品，凭什么说自己能胜任工作”。
本文就是要通过分析一款AI产品，以实现下列四个目的：
第一，本文的内容才叫产品设计，产品设计不是天天画原型和写PPT。
第二，凡是IT+toB的产品，都可以算做广义上的云计算产品，这些产品我都很、非常、特别的熟。
第三，我以前总拿“2个月精通边缘计算”来炫耀自己的学习能力；本文涉及的产品技术和行业知识，我只学习了10个小时。
第四，我不缺产品创意，客户和员工可见的产品创意也不可能保密，这些事本来就是应该分享的。
我接触了多个AI创业团队、从业者和投资人，对于AI生态有了一定的认知。AI生态常见的是这四类人：
第一类，基础模型团队，高风险、高门槛、高回报。
第二类，云厂商和非云的AI Infra团队，就是建设、倒卖和维护卡池。
第三类，各种面向客户业务的tob团队，就是在“用AI做系统集成”。
第四类，各种AI toC的开发者和创业团队，后续这个领域的人会像排山倒海一样多。
在上述四个角色中，第三、第四类角色，都面临着用不好大模型的问题。我不擅长创造和追捧新名词，我只能说“第三和第四类人需要一个中间层，帮他们约束修饰提交给AI的上下文“。
一个前辈刚写了一篇《从超参到Harness，大模型应用演进的温故知新》，文中的话就很透彻：“当我们把这些超级大脑丢到工作场景中，最大的瓶颈不是AI够不够聪明，而是天才AI也缺乏处境信息”。
带着这个疑问，我们再看看这张Agent示意图。我发现，优选tools，次选memory，甚至也包括一些planning，都存在“帮忙约束上下文”的产品创新空间。
这个Agent示意图中的其他角色，大多是缺乏想象力的本地软件，某些服务因为离业务太近而缺乏扩展潜力。这些组件中，最有想象空间、难度适中、投入合理的产品，就是AI搜索。
AI搜索是一个通用服务，可以输出大量提交给AI模型的上下文信息。
你问AI某个问题时，可能需要AI客户端去网上搜索新闻、比赛、游戏攻略、技术文档、学术文档、股票外汇等等信息，然后把这些信息一并喂给大模型。
当你问AI助手，“今天该穿什么外套”时，这个AI助手可能就要搜索本地的气温和天气预报。当你告诉AI助手，“我不开心”时，AI助手可能立马想到给你定个旅游计划，或者买个甜品。而这些工作的闭环，都需要AI搜索帮忙，输入很多新的上下文信息。
过去Bing是开放搜索API的，但AI应用火起来以后，微软突然意识到了什么，就关闭此服务了。然后，国内外瞬间就出现了几个补位产品。
我对AI搜索的评价是“神级卡位”。因为十几年前，在云计算行业初创期，有另一个神级卡位的产品——对象存储。
本节内容就是在做AI搜索和对象存储的类比，AI从业者可能听不太懂，但云计算老炮们都能看到步步心惊。一些老朋友了解我的对象存储工作履历，他们会发现，两者真是一模一样。
两者的技术难度都是不高不低，既没有低到人人都会，也没有高到需要天才攻坚，所需资源也不算太多太重。
两者在各自场景里，都是客户必选产品，客户基数大，对开发者友好。一个人做AI APP，大概率要用到AI搜索，一个人做移动端APP，大概率要用到对象存储。
两者在各自场景里，都只是调味品，不是核心产品。无论是对象存储还是AI搜索，直接营收都很小，在客户的采购决策过程中，权重也不太重。
因为不是核心产品，产品发展早期（前三年）可以避开顶尖大厂的竞争。直到2017年，我还能靠自家存储的技术优势，抢一线大厂的存储订单，因为大厂核心研发都在做云主机和CDN。换到AI场景下，模型大厂的核心团队应该继续优化模型，而非自己去做AI搜索。
这几年一定会出现海量的AI创业者，就像2015年4G普及时，当时出现了海量的移动端创业者。小微创业者是感性开发者，只要你足够尊重客户、足够简单易用，他们是可以出于情感、基于流量去选择你的AI搜索产品，而非选择大厂竞品。
海量的小微客户，聚沙成塔，能够把产品的营收做到几千万，能够验证产品的基本功能。那些年消费额只有几千块钱的客户，更是能为厂商贡献暴利。客户业务继续增长，供应商适度降价依旧有可能留下客户。（开发者生态展开聊很复杂也很伤人，本节不展开了）。
对象存储除了基础的读写管理功能，还能做图片缩放、水印、转码、鉴黄等工作，这就是在证明服务型产品的可扩展性。AI搜索除了基础的搜索网页，也有一大堆的功能扩展，详情见第5节。
对象存储自身的营收很少，但是对象存储可以连带销售远超存储收入的CDN带宽。AI搜索自身的营收也不高，但是，客户用我的AI搜索，是不是能顺路用我的token乃至算力资源哪？
大客户哪怕仅仅出于容灾，也会将数据在几个厂商那里存多份。一个热门AI应用，哪怕出于容灾目的，也应该对接多家AI搜索。
我没做过搜索，但我懂IT和web的常识。本节内容是做产品经理层面的硬核炫技，在有限的投入下，产品经理应该怎么做取舍，短期内给技术和资源减负，但长线要求都要逐步实现。
首先，搜索要接触一大堆第三方客户的资料，这是我们从未遇到过的场景。后续所有工作步骤，我们都必须扪心自问，有没有法律风险？
我把网页搜索的实现手段分为四类。第一类，“直接扒”，按照爬虫协议存下所有的公开网页；第二类，“假扒”，就是调用其他搜索引擎的搜索结果；第三类“强扒”，一定要拿到自己想看的公开内容；第四层是“正规扒”，就是跟数据所有方谈合作，我给他钱或者他给我钱，获得“对方想提供的信息”。
网页搜索，需要首先实现“直接扒”这个手段，验证自家技术团队能胜任搜索的工作。但是，在产品起步阶段尚无营收之时，缓存全球网页的成本太高了，根本不现实。所以，网页搜索可能要先借助大量的边缘IP，用“假扒”的方式服务初始客户。
依赖别的搜索引擎的假扒，只是初始阶段的权宜之计。产品设计者需要紧盯客户需求和访问日志，把热门重要的新鲜信息，存储到自己的网页信息库中。当我们存储了几十亿个库存网页，上亿个新鲜网页时，就几乎不用依赖其他搜索引擎了。
一些网站要求登录、点广告等方式，才让普通客户看到网页内容，这就需要搜索团队增强“强扒”的能力了。这种猫鼠游戏会持续很多年，源站变了，搜索端也要跟着变。
正规扒数据是一堆很复杂的运营行为。比如你接入某个旅游平台，对方认为你是带来了流量，会给你佣金；而你接入实时显示股价的接口，可能要给接口方付费。我并不反感对我们收费的接口，因为我们被收费客户也得掏钱；而很多人看到拿流量佣金就开始兴奋了，但我没多兴奋，因为toC流量的业务超出我的认知范围了。
搜索产品还要把扒下来的数据做一些预处理。比如我们搜到了100个网页，不能直接把这100个网页都发给AI，而是要做排序和预处理。
我们自然人能想到阅读中文内容，但AI可以读取英文等其他语言。这就让AI搜索的搜索范围、处理的难度都有一定的增加。换语言的最大难题不是技术，因为AI眼里所有语言都是向量，但我们自然人读不懂外语很难做产品的验证。
好的产品经理不仅要面对现实，思考落地方案，更要忠于理想。我们要在符合逻辑的基础上，努力去画一个自己相信、自己肯吃、自己去实现的大饼。
这个AI云产品，起点是网页搜索，但终点绝对不止网页搜索。
AI搜索是个在线服务，在线服务本就容易扩展新功能。API接口+一堆json消息，能将更多上下文一股脑塞给Agent，而模型不会区分这些上下文是谁提交的。我多次强调这个产品卡位卡的好，就是因为该产品可以大量扩展内容，最终实现“帮用户和大模型优化上下文”的工作。
搜索是个提供在线信息的流量入口，所以AI搜索可以提供付费文献、实时信息、外卖、出行、购物等等信息。前文就提到过这些事，但我此处再次强调，大家别梦想着能倒卖流量，因为这些信息供应商都很强势，toB供应商倒卖toC流量也没有成功案例。我们来主导对接这些数据源头厂商，做好对接认证代付费等工作，就能简化开发者的工作量。
除了在线信息之外，AI应用理论上还要给模型提供其他上下文信息。因为AI搜索是个在线服务，它提供一些其他软件的功能不算太突兀。
比如，AI搜索提供个计算器功能、汇率转换、天气查询到功能，这还算正常吧？
比如，AI搜索帮客户管理一些会话层级的记忆，这也算正常吧？
还比如，AI搜索推荐一堆Planning和SKILL，这也算正常吧？
反过来想，上述软件自带在线搜索功能，这就很诡异吧？
除了输入信息之外，AI搜索（以及后续衍生出的新产品）还可以管控大模型的输出信息。
比如，AI应用里开启了儿童模式，但大模型里输出了黄暴内容，客户可以把信息抄送一份给AI搜索，AI搜索发现违规内容，要求大模型撤回重新生成啊。
如果Ai应用传递了用户的所在地和语言等信息，AI搜索可以结合当地法规对大模型输出进行风控检查。如果当地禁止数据出境，AI搜索可以调用符合要求的本地大模型。
如果我们把AI搜索（以及后续衍生出的新产品）做的足够好，开发者和中小企业，有更大可能调用我们推荐的、我们代理的、我们包装后的大模型。
现在token转售的生意看似挣钱很爽，但这和大模型原厂存在利益冲突，未来一定会被整治。如果大模型的输入输出都被我们处理过，那就不是在倒卖token，而是在运行自家业务了。
随着硬件成本下降和大模型技术扩散，随着我们搜集了大量上下文信息，随着我们保持一批老客户，几年以后，我们自己也能运营自己的模型和算力池。
产品经理有个很重要的工作是规划产品线的支出和工期等内容。但本文只是个花费不超过10个小时的畅想，所以我只列出支出方向，但不列出具体数值了。
首先看人力成本，大约8个P6+2个P8。我特地咨询过做搜索的前辈，用10个普通工程师，再加一个兼职外脑，半年内足以完成第一版搜索产品。后续日常迭代和维护，这几个人也够用了。
然后看存储资源支出，大约10PB存储。假设存一个网页的文字信息体积为1M，10PB存储足以存储100亿个网页了。
这个群集的算力和网络支出，和用户访问体量强相关。如果没有什么用户访问量，可以按照一个常规的Hadoop群集去申请算力资源。
搜索初期可能要频繁调用其他搜索引擎，所以需要经常临时替换IP。我是守法公民，不太了解这类资源的行情，但应该也不贵。
我知道本文会遇到很多无聊的质疑，我只把潜在的质疑列出来，我心里有详细答案，但我就不说。看好事、欣赏我的朋友，都会自己脑补出答案，而想挑刺的人，我写再详细也还是挑错。
这事大厂也能自己做……对啊，大厂什么都能自己做，然后哪？
这事没技术含量……我说这事技术难度适中，那是因为我懂技术，你懂吗？
这事没你说那么简单……本文是个产品分析设计的demo，不是产品日常运营和技术实践的demo。
你没做过，只是在胡编……子非鱼、鱼非我，我第一次做就比你做到更好的事情有很多。
太晚了，早就有人做了……事情的成功、行业的机会，不仅要看灵机一动，更要看日常执行效率。
你的那些愿景畅想都不符合实际……你说具体点？没具体论点就是抬杠。
这事的成功路径太长了……这个疑问不算刁难，但是没办法，短平快的事情或者门槛高（现在炼大模型），或者不长久（倒卖token）。我们能做甚至该抢着做的，就是这些需要长期努力的事。
