夜雨聆风两周前我写了《一个神级卡位的AI云产品》，借助此文和多个从业者和客户进行了沟通。经过深度思考，我对这款云产品有了更深刻更清晰的认知。
这款产品的卡位很神，很像十几年前云计算爆发期的对象存储产品，这款产品也能成为AI爆发期的明星产品。
因为这个产品是IT+toB，而且是API服务，我认为这就是一款PaaS云计算产品。该产品既能帮助一个创新团队成长为AI算力云厂商，也适合云厂商开拓一条AI创新产品线。
1. 产品定义和客户价值
我不擅长也不想发明产品新名词，但我能给产品做好定义——
“先做好上下文优化，再调度token资源”
这是一个面向企业用户和开发者的toB产品，客户可见的产品形式是SDK和API。
AI上下文优化和调度token资源，是在帮客户的应用实现某些AI功能，并不是我们自己直接做AI应用给客户使用。那些AIAgent、APP的AI模块、添加了AI功能的网站和企业服务，都是该产品的目标客户。
这款产品就非常类似于对象存储，没有开发者经验的读者，确实搞不懂对象存储是做什么用的。但不懂不代表产品没价值，对象存储就证实了其商业价值。
现在大模型已经足够聪明，制约开发者使用AI的重要因素是，如何向大模型发起提问。这款产品就是要集成在客户代码中，优化每一次客户端向大模型发起提问的过程。
一个前辈写了篇《从超参到Harness，大模型应用演进的温故知新》，文中的话就很透彻：“当我们把这些超级大脑丢到工作场景中，最大的瓶颈不是AI够不够聪明，而是天才AI也缺乏处境信息”。
大模型已经很聪明了，而且后续各厂商能力会追平。我知道某些大模型确实领先，但是一两年后，领先者未必能从95分提升到100分，而追赶者更容易从80分提升到95分。而且，很多客户需求找个80分的大模型就够用了。大模型原厂不会成为垄断供应商，这很重要。
这个产品并不直接抢大模型的生意，它的工作范围在模型之外，是在帮提问者优化上下文。这个产品和CodeX等编程Agent也没有竞争关系，虽然Codex可以内置上下文优化服务，但客户可以指定编程Agent必须集成本产品的SDK。
2. 产品的工作范围和演进方向
类似该创意，市面上有很多半成品和试验品，但还没有形成成熟产品。因此我们先分析产品的工作范围和演进方向，下一步再探讨目标客户和成功路径。
最近两年是产品初创期，这款产品要先帮助客户在客户推出AI应用时，快速实现功能和降本增效的目的，最终培养用户的使用习惯。
70%的工作是优化从客户端向大模型的提问内容，比如，优化“你好”等废话，搜索实时比赛信息，对提问内容进行脱敏。
20%的工作审核大模型向客户端的回答，包括遵守所在地法规、防范幻觉和过滤高风险回答等内容。
10%的工作是调度管理后台使用的Token资源池，比如，跨时区错峰复用资源池，调度请求到合规资源池。
在两三年后，市面上有了成熟的竞品，该产品的主要工作会从优化提问内容，逐渐转移到审核回答和调度资源池。
ToB产品的功能很难保密，而且大模型的使用方法也会逐渐趋同，所以优化提问的细节功能很容易同质化。
现在对大模型回答的宽容和放纵，这是管理滞后和新品红利。随着新品红利散去，监管越来越严格，后续会出现大量审核大模型回答的的精细化需求。
各种大模型的能力逐步追平的时候，对模型算力池做精细调度就更有可行性了。此时产品的主要演进方向，就是如何像CDN调度带宽和缓存一样，更精细的调度模型推演请求。
在本阶段，一些大型企业客户（包括中型互联网客户和传统大企业），有较大概率能接受不再使用原厂大模型，而是使用本产品搭售的、可以灵活调度的模型算力资源。
后续继续发展，该产品大概率会拓展出自建算力资源池的能力。毕竟客户奔着该产品来的，我们又能调度需求和资源，将优质负载留在自建节点，将突发负载甩给原厂和同行，这才能做出营收和盈利来。
此外，我对某些读者再唠叨一次，使用AI编程工具完成自动编程，不是本产品的目标场景和演进方向。
操作AI编程是为了提高编程的产出效率，这就要求AI编程工程师具备IT知识和沟通能力。他们可能会从我们这里购买便宜的token，但不会寄希望于本产品来提高他的编程效率。现在很多AI编程者从网上自动搜索技术方案，然后自动应用到编程代码中，这是教学红利，生产环境不该这么干。
无论是AI还是人手工编出来的业务应用（比如社交APP、仿真人客服、企业智能报表），当它需要访问AI大模型时，很大概率会频繁的进行上网搜索、查询新闻、审核输出内容等上下文优化工作。这时才是本产品的用武之地。
3. 目标客户和营收潜力
当我们将产品的工作范围定义为“优化上下文+调度token资源”以后，产品的目标叫客户和成功路径就比较清晰了。
第一类目标客户是海量的AI开发者，他们参与创造需求和验证产品能力，为产品线贡献小额高毛利的营收。
AI普及带来的职场变化，会诞生数千万个AI相关的开发者；相比开网约车和送外卖，这些人更有可能去做AI应用创新。
我们以智能优化上下文的功能点来吸引客户，并强势引导客户接受我们对toke资源的调度工作。
对于不愿意使用调度能力的客户，他们也可指定使用自己的大模型账号，我们只处理上下文，对我们也没损失。
第二类目标客户是传统企业内的IT工程师，他们就是例行采用了一款低门槛的新技术，这类客户能为我们的产品线创造更大的营收。
精明的程序员都是面向工资编程，更愿意在互联网大厂学习通用IT技能。传统企业里面向业务的IT部门，因为吸引不到人才，能力一直很差。
AI编程、AI整理数据、AI生成内容都在极大地增强传统企业的IT工作能力，过去一些因为缺乏IT人才无法推动的业务，可能现在都能变活了。
本产品的切入点是优化上下文，能极大降低这类客户的IT实操学习成本。这类客户也不介意我们倒卖token资源，甚至因为不信任外国模型，会主动要求把数据交给我们的资源池（乃至私有资源池）。
第三类目标客户是头部互联网企业，这类客户对本产品的使用会比较专业，可以创造大额营收但没多少利润。
客户需要转售海量token和提供一部分上下文补充内容，不需要上下文优化和审核上下文。此处的“一部分上下文补充内容”，最典型的需求就是搜索API。且转售token和提供内容两类业务相互独立，并没有黏连性。
现阶段，这些巨头不敢将上下文信息透露给转售方，主要是怕信息泄密。其实他们也不信任模型方，但没得选只能硬着头皮去做。而未来可真不好说：举个例子，理论上这些巨头都能直接采购运营商带宽自建CDN，但实操他们都大量购买商业CDN，AI算力将来可能也一样。
4. 成功路径长是优势
ToB IT产品要想创造海量营收，必须要大量售卖资源。本产品“先做好上下文优化，再调度token资源”，也是一个很长的成功路径。
第一步，聚拢客户需求，拼车倒卖大模型原厂的token。这类企业类似于CDN的代理商，现在能挣点快钱，但因为和原厂大模型有利益冲突，估计一两年后该行业就会消失。我并不是在意能否跟风挣快钱，我将其视为一个很好的入门步骤，能摸到AI上下文，能摸到token资源，第二步工作就更容易开展了。
第二步，在上下文优化层面收取产品费用，比如收取搜索API费用、收取数据接口费用。这些功能我们可以全部自己做，也可以代理转售第三方的功能。这一步能够更好更细的摸清楚AI上下文，并且通过亲自优化上下文，证明产研团队的工作能力。这个阶段产品大概率能够赚回IT资源支出，但靠自己的利润未必养得起庞大的产研团队，也是非常类似对象存储。
第三步，替中小客户调度token资源。比如“你好”等废话用自家便宜模型回答，复杂问题调用错峰的领先大模型，低延迟请求调用就近大模型，设计数据合规的问题必须保证请求不出境。这就像对象存储厂商将小客户的需求放到自己主导的融合CDN上，此时的产品只要能大量卖出去，就能养活团队乃至上缴利润。
第四步，随着大模型能力的趋于相同、随着客户规模的增大，以及互联网巨头逐渐敢于将上下文转售给第三方。该产品的工作重点就是调度token资源了，这时我们需要调度客户请求到廉价资源池，或者自建个电费硬件都便宜的资源池，甚至在客户现场私有化部署资源池。这就像对象存储厂商在高利润区域就自建CDN资源，将垃圾流量甩给其他CDN。
做到第三步的时候，因为我们已经完全掌握了上下文，大模型原厂会把我们当做客户而非代理分销商。做到第四步的时候，算力资源池厂商已经是在为我们打工了。乐观去看，本产品能带来的营收和掌控力，强大到难以想象。
我在上一篇文章还在反思，该产品最大的缺点就是成功路径太长了。我是看不到其他更短的成功路径，所以才更欣赏这条路的。但通过和朋友沟通，通过了解大厂竞品，以及体验了Codex、Cursor内置的类似服务，我反倒认为，成功路径长一点是好事儿。
小团队充分集权，三五个核心产研能力够强又齐心协力，所有资源都由小团队自做出来，更容易一步步的实践漫长的成功路径。
相比之下，在大厂里做类似的创新，漫长的成功路径代表着大量的参与方。任何一个参与方的能力缺陷，都会极大降低产品创新的成功率。而你想甩开同事单干，那就是抢权限抢地盘了。
大家都在大厂上过班，或者见过大厂上班的人。大厂更擅长做短路径的尝试，就是因为协作效率无法支撑长路径产品创新。
5. 现有的参考玩家
写完上面四段内容，本文就可以结束了。但我是实干派，不能只列畅想，不列点实际内容。所以本段落分享一些公开的资料。
我看到的第一个重要的公开资料，是博查AI搜索的官方API文档，https://bocha-ai.feishu.cn/wiki/HmtOw1z6vik14Fkdu5uc9VaInBb 。
火山也有类似博查的联网搜索产品，但我更开心的是，找到了火山的联网问答产品，https://www.volcengine.com/docs/85508/1510774 。
通过博查的官方文档可以看到，他在搜索时，不仅做深做细到了内容的整编排序，也在做百科、天气、手机对比、路线规划等等超出搜索的内容。我和其他类似的搜索API从业者沟通，他们宣称自己在做了一些上下文合规的审核。
火山的联网问答产品的功能，更接近（但还没到达）产品的最终形态。该产品的集成了集团生态的很多资源，该产品还能管理开场白、引导追问、拍照答疑、图文视频混排等功能，进一步降低开发者的工作难度。
我和一些类似产品的从业者沟通，他们自己规划的成功路径，和本文的预测差不多，我的规划内容甚至更详细一些。
6. 产品所需人员和资源
成功路线长的业务，必须有三五个核心人员盯住所有环节，保证每个环节都不出大错。
新产品从零摸索做好上下文优化功能，需要拥有强悍的产品经理。
产品经理需要有ToB产品的工作经历，这个产品不是给个人客户使用的。产品经理需要有PaaS API类产品的工作经验，更容易发掘产品的功能细节。
产品经理需要了解模型的大体能力和成本；不用猛追top1的能力和成本，而是了解top5或Deepseek的能力和成本。
比一般的开发者客户，产品经理更了解使用大模型的各种技巧方法和大致原理；这样才能设计出为客户优化上下文的产品功能。
在接入客户后，产品经理需要频繁总结已有客户的上下文特征信息；观察和验证客户的提问过程中，需要加入哪些新信息新服务。
在具体功能设计、业务对接上，产品经理表现出一定的思考能力，但专业性要求并不太高，也不用特别深入场景kown-how中。随口举例，我们要是要加个“保险知识”“宠物血统”“板球比赛”的功能，稍微思考深一点点就够了。
本产品不是开发大模型，只是开发API应用，不需要特别顶尖的技术人员。中等偏上敬业精神的程序员，可以相对轻松的转岗做这些技术实现工作。
产品初期在“做功能”，所需IT资源并不算多，就是一个测试环境和几台线上服务器。到中后期“做资源”的阶段，产品需要的资源会水涨船高；但是资源开销越大，销售额和运营数据就会更高，这是好事啊。
产品在初期阶段，可能能靠倒卖Token赚一些块钱，但这些营收不长久。要做好产品功能，需要长期的产研投入和产品打磨，初创团队最好找一些融资，已上市的公司可以定向增发或找集团申请预算。这么有潜力的产品，值得重注长期投入。
我上篇文章想的还比较窄，过于看重搜索API的作用。但通过撰写本文理顺思路，我也意识到了，这个产品的最终目标是“上下文优化+调度token资源”。在这个前提下，是自己做搜索API，还是集成第三方搜索API，都是可行的。如果我们做好了其他数据源的接入工作，或者做了很多可以看到上下文的token转售案例，完全可以节省人力集成第三方的搜索API。
7. 结束语
我的每次思考，都是先让自己激动感动，然后再去说服别人。
这个从搜索API延伸出的“优化上下文+调度token资源”的产品，同样让我很激动。我希望各位读者帮帮我，接触到从事或计划从事这类产品的创新团队。如果你们自己是AI程序员（目标客户），也可以跟我分享你们的产品需求。
如果找不到这种渠道，我也无所谓，我不缺创意和热情，还会观摩其他产品和路径。
只要是AI+toB+IT方向的创新和创业，我都想琢磨琢磨。大家想联系我，可以看留言里公开的微信联系方式。
