本文整理自我在深圳 AI 出海 Meetup 的一次现场分享，由录音内容精简而成。分享的主题虽然是 AI 出海，但我更想讨论一件基础的事：无论战场怎么变，商业于增长的底层逻辑并没有变。也顺带整理了过去十年我在产品和运营工作上的一些或许无用的方法论。
01. 关于我
我是周良 Len。过去这些年，我做过基金，也做了大约十年产品经理；做过运营合伙人，也自己创业做过电商和互联网医疗平台。后来我从杭州来到深圳，加入一家从事 GPU 租赁和 Token 业务的公司。
我的经历看起来很杂，但这些工作背后一直是同一件事：理解一门生意，找到价值交换成立的方式，然后把已经跑通的闭环复制放大。
回头看我做过的医疗、电商、建筑 SaaS、公链和模型 API，它们表面上完全不同，最后遇到的却总是相似的问题。与其追逐某个短期渠道或工具，我更关心这些业务共同依赖的商业逻辑。
02. 出海只是换了战场，增长没有换底层逻辑
出海会改变语言、渠道、支付方式和文化环境，AI 也会改变产品形态和交付效率，但商业的底层逻辑没有因此消失或改变。客户为什么选择你，愿意拿什么与你交换，以及这次交换能不能持续发生，这些问题始终存在。
因此，这次分享不会把重点放在某个出海渠道或某种 AI 工具上。我更关心的是：换了一个战场之后，我们还能不能把生意做成。
语言不同，获客渠道不同，用户使用的支付工具不同，甚至对信任的理解也不同。这些变化都需要认真处理，但它们更多属于表层条件。再往下一层看，用户是否需要你的产品、谁来作出购买决定、谁愿意付钱、你能否履约，这些事情并不会因为加上「AI」或「出海」两个标签就自动成立。
03. 先做成一门生意，再谈增长
我一直不太愿意把自己叫作「增长运营」。我更愿意说自己是一个生意人。增长并不是单纯把流量做大，而是把一套已经成立的价值交换不断复制和扩大。
如果第一次交换都没有发生，增长只会把问题放大。先证明有人需要、有人愿意付出成本、我们也能持续交付，然后再讨论规模。
我过去做增长时，从来没有觉得自己是在执行一套固定的增长方法论。我更像是在不停地做生意：先找到一笔能够发生的交易，再看这笔交易为什么成立，最后想办法把它重复一百次、一千次。所谓增长，只是这个复制过程的结果。
04. 一套增长方法，解决六个连续问题
我通常把一门生意拆成六个连续问题：看懂生意、定义价值、找到矛盾、完成交换、跑通闭环、复制放大。
先看清这门生意里的参与者和利益关系，再定义用户到底得到了什么、公司又得到了什么。接着找到阻碍交换发生的核心矛盾，用产品、服务或组织能力完成第一次交换。闭环能够持续运转之后，才轮到增长。
这六步有严格的先后关系。如果生意没有看懂，就很难定义真正的价值；如果没有找到矛盾，团队很可能用一堆功能去解决假问题；如果没有完成过一次交换，所谓闭环就只是纸面上的流程图。增长不是从最后一步突然开始，而是前面五步都成立之后自然出现的结果。
05. 增长之前，先确认这是不是一门生意
商业可以被理解为不同个体或群体之间的价值交换：用户获得需要的价值，公司获得收入。如果这件事还能为社会提供更多价值，当然更好。
产品只是承载交换的工具。APP、网页、Agent 都不重要，重要的是没有这些工具时，这笔交换是否仍然成立。产品的作用，是让已经成立的交换更高效、更稳定。
我原来是产品经理。我对产品经理的理解，是在用户价值和商业价值之间寻找平衡。用户得到他需要的东西，公司获得能够持续经营的收入，产品负责承载和优化这个过程。因此，我不会先问「我们要做一个什么 APP」，而会先问「这笔交换有没有可能发生」。如果不开发产品也能完成第一单，往往应该先把第一单做出来，这才是我们常说的 MVP 的本质。
06. 不要把「用户」当成一个人
一项业务里的「用户」往往不是同一个人。使用者、决策者、付费者和推动者可能分别由不同角色承担。有时还存在明确的阻碍者。
很多产品的需求并没有错，最后却死在利益关系上。真正获益的人不承担成本，承担成本的人又得不到收益，价值交换自然无法继续。分析用户时，必须先把这些角色拆开。
我自己过去做产品也经历过失败。回头复盘时，需求判断可能没问题，技术也做出来了，最后却因为没有处理好获益者与付出者的关系而失败。一个人说「需要」，不代表另一个负责付款的人会买；决策者同意购买，也不代表真正使用的人愿意改变习惯。把所有人统称为「用户」，会掩盖最重要的矛盾。
07. 指标的价值，是帮助行动
我把指标分成三类。虚荣指标看起来漂亮，却不能改变业务，比如下载量很大，但激活和留存接近于零。可行动指标能够告诉团队下一步该做什么，常见的包括激活、留存、转化和用户的商业行为。
北极星指标通常只有一两个，它们代表产品或商业模型中最关键的结果。指标不是为了证明团队厉害，而是为了帮助我们判断问题、安排优先级并采取行动。
比如一款 APP 有一千万甚至一个亿的下载量，但激活和留存都是零，这个下载量对业务没有意义。相反，一项规模不大的指标，如果它发生变化后能明确告诉团队该改什么，就是有价值的指标。北极星指标也不是越多越好。它应该能长期指引团队，一旦这个数据持续改善，商业结果通常不会太差。
08. AARRR 是一张问题地图
AARRR 把用户旅程拆成获客、激活、留存、收入和推荐。不同业务可以调整这些环节的顺序，但它的价值一直没变：帮助团队看清用户从哪里来，在哪一刻第一次感受到价值，为什么愿意留下，何时愿意付钱，以及会不会把别人带进来。
它不是五个需要汇报的字母，而是一张排查商业问题的地图。
获客回答用户从哪里来；激活回答用户第一次真正感受到价值的时刻是什么；留存回答这种价值能不能持续发生；收入回答用户是否愿意用钱完成交换；推荐则回答体验是否足以让用户把朋友和同事带进来。不同业务里，这几个环节可以重排，但每一环都必须对应真实行为，而不是一个孤立的数据字段。
09. 漏斗优化先看最上游
我优化漏斗时，通常会优先寻找上游的关键断点。比如付费率已经达到 5%，团队投入大量精力，可能也只能将它提高到 6% 或 7%；但如果首次价值环节能多留住十到十五个百分点，这部分增量会沿着漏斗传导，最终会显著放大转化的 GMV。
这不是一条绝对规则，而是一种 ROI 思维：团队的时间和资源有限，应该优先解决影响范围大、改善空间也大的问题。漏斗分析的本质，不只是观察转化率，更是确定投入精力的顺序。
10. 案例一：用户在哪里不重要，他此刻愿意做什么更重要
第一个案例来自互联网医疗平台微脉。当时许多平台展示的是全国医生，但患者最终需要在线下完成诊疗。人在深圳打开产品，看到的医生可能来自北京、南京或天津，却很难找到一个可以在线下继续服务的本地医生。
我们判断，互联网医疗的核心不只是线上问诊，而是通过本地医生建立信任，再把服务闭环落到线下。
当时我把市面上的主要互联网医疗产品都看了一遍。无论好大夫、丁香医生还是平安好医生，都能提供大量医生在线咨询，但医生与患者所在城市经常没有关系。医疗与普通内容产品不一样。用户线上咨询以后，检查、手术、治疗和长期复诊仍然依赖本地机构，医生离患者越远，后续服务越难形成闭环。
因此，我们没有继续在「医生数量更多」这件事上竞争，而是把问题重新定义为：怎样让患者在真实就医场景里认识并信任一位医生？
11. 冷启动先选择能赢的战场
我们决定只做本地医生，并把主要战场放在四五线城市。同样一笔预算，如果投入一线城市，只能覆盖一个高成本市场；放到更小的城市，可以同时覆盖多个区域。
当竞争对手集中在一线城市时，我们利用本地化和成本差异建立优势。冷启动不是寻找「蓝海」这个抽象概念，而是选择资源约束下更有机会赢的战场。
当时我的直观计算是，打一座深圳或杭州的成本，可以覆盖几个金华、宁波或台州。四五线城市的医疗资源同样存在数字化需求，但竞争强度和进入成本都低得多。我们用本地医生建立服务网络，再借助城市数量获得用户增量。这更像「农村包围城市」，先在别人不愿意重投入的地方形成规模。
12. 医院里的每个瞬间，都有不同的转化任务
我们把患者在医院的旅程拆开：挂号、科室候诊、缴费、看病结束。每个场景里，用户的意图都不同。
挂号后可以推荐对应医生的咨询服务；候诊时，用户有停留时间，可以通过医院 Wi-Fi 连接到公众号；缴费后可以进入后续 Push 触达体系；看病结束时，患者对医生已经建立了初步信任，适合连接后续咨询复诊服务。
有效用户不是一个新增数字，而是在具体场景里有明确意图、能够继续完成价值交换的人。
最大的入口是挂号。我们与医院一起把挂号、缴费和查报告做成了线上流程，合作医院的患者只要使用手机，就可能进入我们的服务体系。候诊也是一个重要场景。患者在科室门口等面诊、等报告时有明确的停留时间，当年微信刚好支持连接医院 Wi-Fi 后关注公众号，我们就把不同科室的用户导入相应的服务入口。
缴费环节还出现过一个特殊机会：用户微信支付达到规定金额后，可以自动关注指定公众号。单个公众号达到粉丝上限后功能就会失效，所以高峰期我们每周都要注册几个新公众号承接用户。这些做法带有很强的时代特征，但它们背后的判断仍然成立：用户在每个节点的意图不同，不能用同一种内容和转化动作处理。
转化最高的时刻出现在看病结束后。我们曾经给医生桌上放二维码，内部名称叫「患者报到」。我接手后重新设计，把它改成患者能理解的「加医生微信」，并把二维码印在纸上塞进病历，告诉患者有问题可以扫码免费问三个问题。实际结果是，扫码后的患者大多会与医生交流；只要对话达到一定深度，许多人就会在一段时间后购买医生的服务。
13. 公众号不是粉丝池，而是生命周期基础设施
我们没有把公众号当成简单的流量池。用户通过哪个二维码、从哪个科室和医生进入，都会被识别。就诊当天、第三天、第七天、一个月后，用户会收到与疾病、科室和医生相关的不同内容。
公众号真正承载的是用户识别、持续触达和服务转化。它是一套生命周期基础设施，而不是一个用来累计粉丝数量的账号。
我们会根据二维码来源判断用户来自哪家医院、哪个科室，甚至哪位医生，再决定推送什么。骨科患者不应该收到与他无关的泛医疗内容，看病当天和看病一个月后也不应该收到同样的信息。每一条路径都对应不同的触达节奏和转化任务。
当时我的团队规模并不大，大致是两名业务人员配合三名研发。公众号矩阵累计获得了约 3500 万粉丝，并成为平台订单转化的重要来源之一。这里最重要的不是粉丝总数，而是我们知道这些人为什么来、此刻需要什么，以及下一次价值交换可能在哪里发生。
14. 单点工具一旦开放，就可能变成增长飞轮
单个医院的流程优化得差不多以后，增长遇到了新的瓶颈：继续靠自己的团队逐家实施，速度太慢；依赖患者推荐也很难成立，因为疾病不是适合主动传播的消费场景，医疗天然不适合粗暴裂变。要让业务滚得更快，必须换一种复制方式。
很多医院缺少开发和运营能力，原有系统也常由外包公司维护。我们把挂号、缴费、查报告和生命周期管理做成免费工具，嵌入医院公众号，条件是医院里的医生接入我们的医生端。医院获得一套可用的系统，我们则通过医生端和生命周期体系承接后续服务。第一周同时上线了二十多家医院，效率远高于自己的团队逐家推进。增长的关键不再是继续堆人，而是把自己的能力变成合作方愿意采用的东西。
15. 跨城市复制的关键是组织模型
免费工具解决了单家医院的部署效率，却没有完全解决跨城市扩张的问题。产品和运营能力可以标准化输出，医院关系、地方资源和落地经验却很难由总部远程复制。当业务从一家医院走向几十座城市，增长的瓶颈便从「工具怎样复制」转向「组织怎样复制」。
一家杭州公司很难真正理解全国几十个城市的医疗关系。我们把总部的产品、数据和标准化能力开放出去，在核心城市寻找有长期行业经验的本地负责人，通过子公司分享一部分利润。
总部提供完整能力，本地 CEO 解决医疗关系和落地问题。两者相乘，形成城市扩张速度。跨城市复制不是把总部动作重复七十遍，而是重新设计组织模型。
我们最终相当于把一家公司拆成了几十家城市公司。当地负责人不需要从头组建产品、研发和运营团队，总部把钱、人员、产品和业务方法准备好；他需要做的，是利用多年积累的本地医疗经验，把医院和关键资源连接起来。
在三四线城市，这种模式的成本更低。当地 CEO 分享子公司的一部分利润，也有足够动力推动落地。增长在这里已经不再是一个投放或产品问题，而是「总部能力 × 本地关系」的组织问题。
16. 案例一补充：冷启动最稀缺的往往是信任
离开微脉之后，我尝试做社交电商。当时行业都在争夺宝妈人群，我想找一个传播结构更强、又没有被充分服务的人群，最后选择了大学生。
大学生的关系网络天然向外扩散，但真正稀缺的不是流量，而是信任。我进入学校，寻找卖电话卡的人、社团负责人、楼长和宿舍管理人员。这些人才是校园网络里的信任节点。
我选择学生，还有一个原因。当一个人成为宝妈，她身边会出现很多处在相似阶段的人；而一个大学生的同学网络，可能从本校延伸到其他城市甚至海外。它不是围绕单一社区形成的小圈子，而是更分散、更具传播性的关系网络。当时我判断，这种结构的复制效率可能比宝妈市场更高。
但不能因为「大学生多」就把他们看成流量。我去学校待了几天，加了卖电话卡的人、吉他社和滑板社负责人、Cosplay 社团负责人、每层宿舍楼长、宿管阿姨和教官。我要找的是学生已经信任的人，而不是从外部硬插入一个陌生平台。
17. MVP 的极致，是先不用开发
当时我没有完整团队，也没有多少钱。我先找到一批供应链，用 Excel 标清供货价和利润，再把表交给校园里的信任节点。没有开发复杂系统，第一个月就做出了约 500 万利润，证明学生愿意买、校园节点能够卖、供应链也可以完成履约，这条交易链路是成立的。
这才是我理解的 MVP：它不是一套功能较少的平台，而是用最低成本验证生意中最关键的假设。交易跑通以后，扩张和产品开发要解决的就不再是「这门生意能不能成立」，而是如何把已经验证的动作复制成一百份、一千份。产品和平台不是起点，而是规模化工具。
后来我们发现，要进一步释放学生的消费能力，业务会逐渐触及信贷。但监管政策不允许继续向学生开放相关金融服务，信贷平台最终关闭。这也是商业闭环的一部分：用户需求、产品和交易链路成立还不够，业务还必须在政策和社会边界内成立。
18. 案例二：产品落不了地，往往不是用户不会用
第三个案例是一家建筑 SaaS 公司。产品拥有同行 80% 到 90% 的功能，公司连续投入数年，却没有真正的客户和收入。
我去工地跑了两三周后发现，问题不在功能，而在采用成本。记录数据会给一线人员增加额外工作，有些透明数据还会触碰既有利益。老板获益，一线承担成本，价值和成本完全错位。
这家公司每年大约亏损 2000 万，已经做了三四年。老板早年就在工地搬砖，对行业有很深的经验，也一直靠自己的资金支持产品。站在办公室里看，这套 SaaS 缺的似乎只是销售；到了工地以后，才发现即使购买了竞品的客户，也很难真正让一线人员持续使用。
我在那里听不懂工人的方言，也看到大量记录仍然依赖不同颜色的纸质本子。让他们在原有工作之外再打开 APP、拍照、录入数据，并不是一个「培训一下就能解决」的小问题。
19. 「不会用」的背后，是「不想用」
使用门槛不只是界面复杂。员工使用考勤工具，往往不是因为喜欢，而是管理制度要求。在建筑现场，人员结构复杂、操作习惯不同，一线员工还可能因为数据透明而失去灰色收益。
如果只把问题归因于培训不足或功能不够，产品会不断增加功能，却始终无法落地。真正的问题是：谁承担采用成本，谁又能从中获益。
更麻烦的是，建筑行业存在真实的利益冲突。数据没有进入系统时，一些材料损耗和现场行为很难被追踪；一旦完整记录，某些人原有的灰色空间就会消失。对于老板，透明化是价值；对于一线部分人员，透明化可能是损失。
所以客户口中的「不会用」，可能包含三种完全不同的问题：操作确实复杂、改变习惯需要额外成本、或者用户根本不愿意让系统发挥作用。产品团队如果不区分这些情况，就会不停简化界面，却解决不了采用。
20. 重新设计利益，让关键角色推动采用
解决采用问题，靠的不是继续增加功能，而是重新设计每个角色的利益。老板付了钱，却一直看不到系统带来的管理价值。于是我先用两周做了二十多张数据看板。刚上线时图表几乎都是空的，但每个空白都会说明缺少什么数据、应该由谁补充。老板想看清材料损耗和现场问题，自然会推动对应负责人完成录入。
一线人员承担的是额外的操作成本，「数字化能提高公司效率」对他们并没有直接吸引力。软件一年卖八万元，我们就考虑从收入中拿出一部分，每月奖励完成数据录入的人，用直接收益补偿他们改变习惯的成本。
第一个月，奖励全部被领完，老板的报表中开始出现数据，许多异常也被系统标红。老板据此采取管理动作，管理要求又进一步推动一线持续录入。系统真正转起来，不是因为所有人突然认可数字化，而是因为决策者获得了管理价值，使用者的采用成本也得到了补偿。
21. 能卖出去，靠的是一套角色化销售公式
复杂 B2B 产品的销售，不是把功能表和许可证交给客户，而是让一套采用机制在客户组织里真正运转。决策者需要看到管理价值，一线人员需要获得足够的使用动力，中间人则要帮助降低跨层级协作的阻力。只有这些角色都进入闭环，产品价值才能通过真实数据被证明。
因此，软件「有人用」是规模化销售的前提，而不是交付后的附加结果。如果产品在单个客户内部都无法运转，卖得越多，实施和服务问题只会越大；采用机制跑通以后，销售才有了可以复制的基础。
22. 案例三：用户第一次拒绝的，可能只是表达方式
我曾经负责一项广告投放业务，后来承包了国内头部平台上相当大一部分广告流量。Banner 点击率达到 40%，说明入口和素材很有吸引力；但用户进入详情页后，大约六七成会直接离开。流量按照 CPM 购买，每一次退出都意味着成本已经发生，却没有形成交易。
入口数据很好、最终结果却很差，说明用户愿意了解，但不接受当前页面提供的商品或表达方式（毕竟是被骗进来的呀）。我们尝试过许多优化，效果始终有限。到后来这个问题后来也让我意识到，用户第一次拒绝的可能只是当前选择，并不一定代表他完全没有需求。
23. 入口很强，问题可能发生在详情页
如果只看最终订单，团队很容易得出「流量不精准」的结论，继续换素材、换人群或增加预算。但 40% 的点击率已经证明用户愿意进入，真正的断点发生在他看到第一组商品之后。因此，我们停止继续放大入口，把注意力转向落地详情页。
漏斗的价值就在这里：它不仅告诉我们结果不好，还能帮助定位结果从哪个环节开始变差。此时需要判断的不是怎样获得更多点击，而是用户拒绝的究竟是这类需求、这个商品，还是当前这组选择。
24. 再给用户一次选择，曾经让订单增长
（这个例子我就展示不在博客放产品截图了）
我们最终做了一个实验：在页面上增加了一个假的的关闭按钮，做成带链接的图片。用户点击「叉」时不会直接退出，而会进入另一组商品；再次关闭，还会看到新的选择。这个设计延长了停留时间，基本消化了原来六七成的流失，订单交易量也提升了约 xx%（对外数据就先保密了）。
我把它称为一个「骚操作」，因为它确实有效，却不值得包装成先进方法论。它给了用户更多「选择」，也让用户更难离开，因而可能伤害体验。后来我在其他产品中也见过连续多次挽留用户的类似设计。这个案例留下的真正提醒是：指标可以被优化，但数据变好不等于用户价值同步提高。团队仍要追问，我们是在帮助用户找到需要的东西，还是仅仅增加了退出成本。
25. 案例四：找到行业默认成本，直接消灭它
在一个北美公链项目里，我几乎只有一个可用的人和两万美元预算，却要完成冷启动、持续获客和留存。当时公链竞争已经非常激烈，其他项目一天的 KOL 和广告投入就可能达到几万美元。沿用相同打法，我们没有任何胜算。
我想到 360 免费杀毒的故事：当整个行业默认软件应该收费时，它直接消灭了这项成本。在公链世界里，类似的默认门槛是 Gas。用户进入一条新链以前，必须先购买对应的原生资产；不同链使用不同货币，购买、兑换和转账都会产生摩擦。有限预算下的突破口，不是购买更多流量，而是直接消灭这个所有用户都会遇到的进入成本。
26. 免费 Gas 只是敲门砖
我们把主要预算直接用于补贴 Gas。用户完成一些简单操作以证明自己不是机器人后，就能获得足够进行十几到二十次链上交互的金额。补贴需要控制在一个微妙区间：太少无法消除门槛，太多又会吸引专业套利。
项目另外只花了两三千美元做传播。由于市场对未来空投存在预期，免费 Gas 很快引发了主动讨论和扩散。后来这条链在一些主流钱包中的活跃数据相当靠前，某头部钱包团队甚至参与了节点建设。冷启动由此完成，但免费 Gas 只解决了用户如何迈出第一步，还没有回答他们为什么长期留下。
27. 补贴可以点火，但不能替代真实需求
免费 Gas 带来了大量追逐空投预期的用户，其中也混有大量女巫机器人。这在预期之内，冷启动完成后，继续增长的关键不是发更多补贴，而是从这些地址的行为中筛选值得服务的真实需求。（其实不是我们完成了冷启动再去看怎么做业务，这里只是为了便于理解）
链上数据让我们能够观察地址持有什么资产、参与过哪些协议。分析后，我们发现一批用户持有较多比特币相关资产。他们既希望获得收益，也希望保持资产流动性。当时行业流行将比特币存入协议获得凭证，再把凭证用于二次质押。我们由此设计了新的价值交换：用户存入凭证，再借出美元，让被锁定的资产重新流动起来。
这类业务风险很高，因此增长不能脱离风控。我们需要验证凭证背后的真实资产，设置预警和处置机制，同时连接愿意提供美元流动性的人。参与者从最初的十个人逐渐增加到一百、一千人…补贴只带来了第一批地址，提升资产效率的真实需求才让业务形成后续闭环。
28. 案例五：从 API Token 业务重新理解增长
最后一个案例来自我目前负责的 API Token 业务。市场上存在大量模型中转站，将不同来源的 Token 额度整合后卖给企业或个人，其中一些依赖批量注册云账号等逆向代理方式。我们希望做的是合规版本：与国内外模型供应商正式签约，不承接灰产和黑产资源。
公司的另一项基础能力是 GPU 资源，部分开源模型可以自行部署。相比单纯转售，我们因此有机会更好地控制某些模型的供给、价格和稳定性。这项业务仍在发展中，我将的重点不在包装一个尚未完成的成功案例，而在于判断它究竟是什么生意，以及哪些供给约束决定它能否持续。
29. 大客户增长不等于业务健康
接手业务后，我首先要决定该看充值额、客户数，还是其他指标。最终，我把重点放在真实消耗上。客户充值却没有调用，长期需求仍然存疑；只有持续消耗 Token，才能说明 API 正在他的业务里创造价值。除了每周和每月的消耗增长率，我也会观察客户自己的业务是否同步增长。
分析业务健康度时，还要把少数超大客户暂时剔除。大客户当然贡献 GMV 和利润，但异常大的数字会掩盖其余客户的真实状态，让团队把集中度误判为普遍增长。经营结果时要看头部贡献，判断模式能否复制时则要单独观察更广泛的客户群。
30. API Token 不是流量生意，而是供应链生意
看完客户需求后，我发现 API Token 更像供应链生意，而不是单纯的流量生意。客户会比较价格和质量，也会关心额度能否持续、模型是否稳定。某个上游出现问题时，我们有没有其他资源、其他机房或自建模型可以迅速切换？这些看似分散的问题，最后都指向供应链能力。
尤其对国内客户来说，成本很重要，但低价无法单独建立长期合作。营销可以带来一次访问，真正的交付则是在客户需要时稳定提供模型，并在供给波动时及时调度替代资源。流量决定客户会不会来，供应链决定客户敢不敢把核心业务放进来。
31. 让客户的增长，成为自己的增长
增长的第一步，是找到真正高消耗的场景，例如 Agent、开发者工具和批处理业务，再识别这些场景里的目标客户。接入阶段需要降低接口兼容和迁移成本，试用阶段要帮助客户尽快完成第一次稳定调用。正式使用后，内部调度团队还要持续发现资源异常并切换供给，尽量不把上游波动传递给客户。
在此基础上，更重要的工作是客户成功。SaaS、CDN 和短信公司通常都有客户成功经理；这项业务还在早期，我也会直接与客户沟通，帮助他们分析产品怎样获得更多真实用户、业务怎样继续增长。客户扩大 Token 消耗，不应该依赖我们反复催促，而应该来自他自己的产品创造了更多价值。客户的业务增长，我们的消耗和收入自然随之增长，这比一次性充值更可持续。
这项业务还没有一个完整结局。我仍在寻找 API Token 行业真正的「降维打击点」。暂时没有答案，就继续做、继续观察，而不是为了让本次分享的故事完整，而硬造一个结论。
32. 增长不是一个部门的任务
我以前常说：设计向产品靠，产品向运营靠，运营向 CEO 靠。这不是让岗位边界消失，而是让每个人多理解一步下游结果。设计要知道方案是否帮助用户得到价值交换，产品要判断功能能否带来业务结果，运营需要继续靠近收入、成本和供给，CEO 则要让这些角色围绕同一套商业闭环协作。
增长因此不是某个部门的专属职责。一个价值不成立、供给不稳定或组织利益冲突的业务，无法由增长团队独自修复。只有每个角色都理解自己的工作如何影响价值交换，整家公司才可能对最终结果负责。
33. 最后，记住六句话
- 增长之前，先看懂生意。 它必须能够完成的真实交易，否则增加流量只是在浪费资源和时间。
- 产品首先要承载可持续的价值交换。 APP、网页、客户端和 Agent 都只是形式。用户价值与商业价值无法同时成立，形式再新也没有推向市场的基础。
- 先找到业务的核心矛盾。 医疗案例的关键是本地信任，建筑 SaaS 是获益者与成本承担者错位，公链冷启动则是准入门槛和利益驱动的价值交换。解决决定交易能否发生的问题，比增加锦上添花的功能更重要。
- 用 ROI 思维处理冷启动 MVP。 先完成第一笔交易，再决定是否开发 APP、网页和管理工具。不要在收入尚未验证时，先投入大量成本建设一套可能无人使用的系统。
- 补贴只能点火。 用户因为补贴进来以后，必须获得真实价值。只有留存和转化继续发生，补贴才是商业闭环的加速剂，不然只是一场昂贵的数据表演。
- 对商业闭环负责，而不只对指标负责。 指标是帮助判断和行动的工具，终点是生意能否持续运转、能否守住法律与商业伦理，并以合理方式不断扩大。
34. 增长是整家公司理解生意的方式
医院里的挂号入口、校园里的信任节点、工地上的利益关系、广告页里的退出按钮、公链上的 Gas 和模型 API 的供应链，看起来毫无关系，却都在回答同一组问题：用户会在什么场景中行动，谁能推动交易，什么阻碍价值交换，以及已经成立的结果怎样被继续复制。
方法论可以整理思路，却不能代替进入真实业务。很多关键答案不在会议室里，而在医院走廊、大学宿舍、建筑工地、客户的调用数据和一线人员的利益关系中。先看清这些事实，再决定产品和增长应该做什么。
无论做产品、运营、增长还是 AI 出海，最终都要持续完成一场双方认可的价值交换。先把生意做成，再用产品、组织、渠道和资本把它复制出去。增长不是某个部门的任务，而是整家公司理解生意的方式。
好了，谢谢各位，我今天废话连篇的分享大概到这里结束，如果你有任何问题，欢迎添加我的微信：Aipsme 与我进行讨论或业务合作~
评论