观潮弄虾资本、时代与第一性原理

01 / 资本

钱先流向了哪里

过去的软件生意给人留下了一种直觉：产品做好以后，再多服务一个用户，成本似乎不会增加太多。轻资产、低边际成本、快速复制，这些词成了我们理解互联网公司的常用语言。

生成式 AI 让这套直觉需要重新检查。模型背后有芯片、机房、电力、网络，也有持续的训练与推理。一个产品越受欢迎，调用量可能越大；如果收入没有覆盖服务成本，增长也会放大压力。

使用量增长、收入增长和利润增长，是三个需要分别回答的问题。

因此，我把这条产业链分成三个位置来观察。它们互相依赖，却未必用同一种方式创造价值。

处在上游，不代表天然没有风险；离用户最近，也不代表一定最赚钱。基础设施需要长期投入，平台需要持续迭代，应用则要回答一个很直接的问题：如果底层模型明天更强了，这个产品还提供什么？

我的关注点因此从“接了什么模型”，转向“理解了什么工作”。行业知识、完整流程、分发渠道和成本控制，往往比一次漂亮的模型演示更难复制。应用的机会，需要在这些具体关系里寻找。

02 / 时代

技术之外，还有一个更大的背景

研究 AI 时，很容易只盯着技术公司的消息。但企业是否增加投入、消费者是否愿意付费，还受到收入预期、就业、资产负债状况和整体需求的影响。技术进步与经济修复之间，并不存在一个自动生效的等号。

我在原稿中把宏观增长、消费和就业放在一起，是想提醒自己：一个行业的高速发展，不能直接推导出所有人都同步受益。看总体趋势时，需要回到统计范围和具体语境。世界银行的经济增长数据与《中国经济简报》，是原研究使用的背景资料。

同样需要谨慎的是“规模”这个词。AI 核心产业、数字经济、企业使用 AI 带来的间接价值，统计边界完全不同。存量规模也不等于新增贡献。把这些数字并列，可能让故事更有冲击力，却不一定让判断更准确。

这也改变了我看产品机会的方式。一个宏大趋势只能说明某个方向值得观察；要不要做一个产品，还得回到具体的人：他正在经历什么，原来怎样解决，为什么愿意改变。

03 / 商业

有收入以后，怎样判断是不是一门好生意

在 AI 产品里，演示效果和持续付费之间有一段很长的距离。第一次使用可能来自好奇，第二次使用来自便利，长期付费则需要产品稳定地进入生活或工作。新鲜感能带来开始，未必能解释留下。

我会先区分几个容易混用的口径。一次调用的价格与成本，只说明局部的经济关系；它不能自动覆盖训练、研发、人员和基础设施。把某个时点的经常性收入年化，也不等于已经实现的全年收入。合作框架里的计划投入，更不能一概写成确定发生的现金支出。

这些区别听上去像财务细节，却直接影响我们如何评价商业模式。原稿参考了企业现金流资料；公开数据入口会持续更新，使用时仍应回到相应报告期的原始披露。

从付费开始，继续看留存

对订阅产品，我更想知道：用户完成了什么任务，在哪个时刻觉得值得续费，又在什么时候离开。转化率、退款、留存与服务成本，需要放在一起看。原研究引用的 RevenueCat 订阅应用报告提供了观察这些问题的材料，但不同品类、周期和样本的数字不能直接横向套用。

开源模型和平台能力的进步，也在不断改变产品的价值边界。如果一个功能很快成为基础能力，单独为它付费的理由就会变弱。这并不意味着应用没有机会，而是要求我们把注意力放到功能前后的完整体验：输入怎么来，结果怎样被检查，下一步工作如何继续。

一个市场的答案，不会自动适用于另一个市场

不同市场的支付习惯、分发渠道和服务成本不同。直接复制价格和增长方法，可能会忽略真正的约束。免费也需要回答谁承担成本、如何长期维持。对独立产品而言，理解具体用户，比先给一个市场贴上“适合付费”或“不适合付费”的标签更有帮助。

04 / 落地

企业买的，是一个能交付的结果

从个人尝鲜走到企业工作流，问题会发生变化。一个回答是否聪明只是起点；它能否接入现有系统、出错时能否发现、数据能否被正确处理、结果由谁负责，都会进入真实的采购和使用决策。

所以，计算收益不能只比较“人工花了多久”和“模型生成花了多久”。集成、数据整理、员工学习、人工复核和维护同样是成本。模型生成得快，不代表整个任务已经更快完成。

这也是我后来持续关注评测与 Agent Harness 的原因。把模型接进工具，只是建立了可能性；把上下文、执行过程、评测和失败恢复组织起来，才有机会让这种可能性成为可靠的日常体验。

与其承诺一次替换完整岗位，我更愿意从边界清楚、输出可判断的任务开始。先观察真实问题，再决定自动化到哪一步。能说明白什么还做不好，也是产品成熟的一部分。

05 / 个人

留给个人的空间在哪里

回到个人，我不认为答案是追上每一个新工具。工具变化太快，如果目标只是始终站在最新的名字旁边，很容易忙了很久，却没有留下自己的判断和作品。

更有价值的积累，是把模糊经验变成清楚的方法。使用 API 时，要表达输入与输出；使用编程工具时，要描述任务、环境和限制；构建 Agent 时，还要说明步骤、状态和异常。这些工具并不是一条必须依次升级的阶梯，但它们都在要求同一件事：把工作逻辑说清楚。

工具在变，把工作逻辑说清楚，始终是一件重要的事。

原稿里，我把人的位置归结为三个方向。第一是对具体业务的判断：哪些问题值得解决，哪些妥协可以接受。第二是对结果负责：把一个想法推进到可以使用、可以交付。第三是长期关系中的信任：别人为什么愿意把任务交给你，与你继续合作。

这些能力不会因为模型更强就自然消失，但也不会仅凭“人类独有”四个字自动成立。它们需要通过真实的选择、交付和反馈被证明。AI 可以参与其中，而我仍然要知道自己想完成什么，以及为什么这样做。

06 / 实践

看清一部分，再动手做一部分

“观潮弄虾”这个名字，对我而言是一种节奏。看远一点，避免被一时的热度牵着走；做近一点，避免只在宏观判断里打转。我们不需要先预测整个时代，才能完成一个有用的小产品。

我更愿意从一个反复出现的具体问题开始，做出可以使用的版本，把反馈记录下来。结果不好，就拆开看：是问题选错了，是模型能力不够，是上下文缺失，还是流程设计让人难以使用？每次弄清一个原因，都比换一组更宏大的词更有价值。

研究也因此不是产品之外的装饰。它帮助我决定什么值得尝试；产品实践则反过来检验研究里的假设。它们之间有来回，理解才能逐渐变得扎实。

我想保留的，最终是一个朴素的问题：我在用 AI 解决什么问题，结果怎样，下一步怎么改？