2026-09-15 10:00:00
本文整理自我在深圳 AI 出海 Meetup 的一次现场分享，由录音内容精简而成。分享的主题虽然是 AI 出海，但我更想讨论一件基础的事：无论战场怎么变，商业于增长的底层逻辑并没有变。也顺带整理了过去十年我在产品和运营工作上的一些或许无用的方法论。
我是周良 Len。过去这些年，我做过基金，也做了大约十年产品经理；做过运营合伙人，也自己创业做过电商和互联网医疗平台。后来我从杭州来到深圳，加入一家从事 GPU 租赁和 Token 业务的公司。
我的经历看起来很杂，但这些工作背后一直是同一件事：理解一门生意，找到价值交换成立的方式，然后把已经跑通的闭环复制放大。
回头看我做过的医疗、电商、建筑 SaaS、公链和模型 API，它们表面上完全不同，最后遇到的却总是相似的问题。与其追逐某个短期渠道或工具，我更关心这些业务共同依赖的商业逻辑。
出海会改变语言、渠道、支付方式和文化环境，AI 也会改变产品形态和交付效率，但商业的底层逻辑没有因此消失或改变。客户为什么选择你，愿意拿什么与你交换，以及这次交换能不能持续发生，这些问题始终存在。
因此，这次分享不会把重点放在某个出海渠道或某种 AI 工具上。我更关心的是：换了一个战场之后，我们还能不能把生意做成。
语言不同，获客渠道不同，用户使用的支付工具不同，甚至对信任的理解也不同。这些变化都需要认真处理，但它们更多属于表层条件。再往下一层看，用户是否需要你的产品、谁来作出购买决定、谁愿意付钱、你能否履约，这些事情并不会因为加上「AI」或「出海」两个标签就自动成立。
我一直不太愿意把自己叫作「增长运营」。我更愿意说自己是一个生意人。增长并不是单纯把流量做大，而是把一套已经成立的价值交换不断复制和扩大。
如果第一次交换都没有发生，增长只会把问题放大。先证明有人需要、有人愿意付出成本、我们也能持续交付，然后再讨论规模。
我过去做增长时，从来没有觉得自己是在执行一套固定的增长方法论。我更像是在不停地做生意：先找到一笔能够发生的交易，再看这笔交易为什么成立，最后想办法把它重复一百次、一千次。所谓增长，只是这个复制过程的结果。
我通常把一门生意拆成六个连续问题：看懂生意、定义价值、找到矛盾、完成交换、跑通闭环、复制放大。
先看清这门生意里的参与者和利益关系，再定义用户到底得到了什么、公司又得到了什么。接着找到阻碍交换发生的核心矛盾，用产品、服务或组织能力完成第一次交换。闭环能够持续运转之后，才轮到增长。
这六步有严格的先后关系。如果生意没有看懂，就很难定义真正的价值；如果没有找到矛盾，团队很可能用一堆功能去解决假问题；如果没有完成过一次交换，所谓闭环就只是纸面上的流程图。增长不是从最后一步突然开始，而是前面五步都成立之后自然出现的结果。
商业可以被理解为不同个体或群体之间的价值交换：用户获得需要的价值，公司获得收入。如果这件事还能为社会提供更多价值，当然更好。
产品只是承载交换的工具。APP、网页、Agent 都不重要，重要的是没有这些工具时，这笔交换是否仍然成立。产品的作用，是让已经成立的交换更高效、更稳定。
我原来是产品经理。我对产品经理的理解，是在用户价值和商业价值之间寻找平衡。用户得到他需要的东西，公司获得能够持续经营的收入，产品负责承载和优化这个过程。因此，我不会先问「我们要做一个什么 APP」，而会先问「这笔交换有没有可能发生」。如果不开发产品也能完成第一单，往往应该先把第一单做出来，这才是我们常说的 MVP 的本质。
一项业务里的「用户」往往不是同一个人。使用者、决策者、付费者和推动者可能分别由不同角色承担。有时还存在明确的阻碍者。
很多产品的需求并没有错，最后却死在利益关系上。真正获益的人不承担成本，承担成本的人又得不到收益，价值交换自然无法继续。分析用户时，必须先把这些角色拆开。
我自己过去做产品也经历过失败。回头复盘时，需求判断可能没问题，技术也做出来了，最后却因为没有处理好获益者与付出者的关系而失败。一个人说「需要」，不代表另一个负责付款的人会买；决策者同意购买，也不代表真正使用的人愿意改变习惯。把所有人统称为「用户」，会掩盖最重要的矛盾。
我把指标分成三类。虚荣指标看起来漂亮，却不能改变业务，比如下载量很大，但激活和留存接近于零。可行动指标能够告诉团队下一步该做什么，常见的包括激活、留存、转化和用户的商业行为。
北极星指标通常只有一两个，它们代表产品或商业模型中最关键的结果。指标不是为了证明团队厉害，而是为了帮助我们判断问题、安排优先级并采取行动。
比如一款 APP 有一千万甚至一个亿的下载量，但激活和留存都是零，这个下载量对业务没有意义。相反，一项规模不大的指标，如果它发生变化后能明确告诉团队该改什么，就是有价值的指标。北极星指标也不是越多越好。它应该能长期指引团队，一旦这个数据持续改善，商业结果通常不会太差。
AARRR 把用户旅程拆成获客、激活、留存、收入和推荐。不同业务可以调整这些环节的顺序，但它的价值一直没变：帮助团队看清用户从哪里来，在哪一刻第一次感受到价值，为什么愿意留下，何时愿意付钱，以及会不会把别人带进来。
它不是五个需要汇报的字母，而是一张排查商业问题的地图。
获客回答用户从哪里来；激活回答用户第一次真正感受到价值的时刻是什么；留存回答这种价值能不能持续发生；收入回答用户是否愿意用钱完成交换；推荐则回答体验是否足以让用户把朋友和同事带进来。不同业务里，这几个环节可以重排，但每一环都必须对应真实行为，而不是一个孤立的数据字段。
我优化漏斗时，通常会优先寻找上游的关键断点。比如付费率已经达到 5%，团队投入大量精力，可能也只能将它提高到 6% 或 7%；但如果首次价值环节能多留住十到十五个百分点，这部分增量会沿着漏斗传导，最终会显著放大转化的 GMV。
这不是一条绝对规则，而是一种 ROI 思维：团队的时间和资源有限，应该优先解决影响范围大、改善空间也大的问题。漏斗分析的本质，不只是观察转化率，更是确定投入精力的顺序。
第一个案例来自互联网医疗平台微脉。当时许多平台展示的是全国医生，但患者最终需要在线下完成诊疗。人在深圳打开产品，看到的医生可能来自北京、南京或天津，却很难找到一个可以在线下继续服务的本地医生。
我们判断，互联网医疗的核心不只是线上问诊，而是通过本地医生建立信任，再把服务闭环落到线下。
当时我把市面上的主要互联网医疗产品都看了一遍。无论好大夫、丁香医生还是平安好医生，都能提供大量医生在线咨询，但医生与患者所在城市经常没有关系。医疗与普通内容产品不一样。用户线上咨询以后，检查、手术、治疗和长期复诊仍然依赖本地机构，医生离患者越远，后续服务越难形成闭环。
因此，我们没有继续在「医生数量更多」这件事上竞争，而是把问题重新定义为：怎样让患者在真实就医场景里认识并信任一位医生？
我们决定只做本地医生，并把主要战场放在四五线城市。同样一笔预算，如果投入一线城市，只能覆盖一个高成本市场；放到更小的城市，可以同时覆盖多个区域。
当竞争对手集中在一线城市时，我们利用本地化和成本差异建立优势。冷启动不是寻找「蓝海」这个抽象概念，而是选择资源约束下更有机会赢的战场。
当时我的直观计算是，打一座深圳或杭州的成本，可以覆盖几个金华、宁波或台州。四五线城市的医疗资源同样存在数字化需求，但竞争强度和进入成本都低得多。我们用本地医生建立服务网络，再借助城市数量获得用户增量。这更像「农村包围城市」，先在别人不愿意重投入的地方形成规模。
我们把患者在医院的旅程拆开：挂号、科室候诊、缴费、看病结束。每个场景里，用户的意图都不同。
挂号后可以推荐对应医生的咨询服务；候诊时，用户有停留时间，可以通过医院 Wi-Fi 连接到公众号；缴费后可以进入后续 Push 触达体系；看病结束时，患者对医生已经建立了初步信任，适合连接后续咨询复诊服务。
有效用户不是一个新增数字，而是在具体场景里有明确意图、能够继续完成价值交换的人。
最大的入口是挂号。我们与医院一起把挂号、缴费和查报告做成了线上流程，合作医院的患者只要使用手机，就可能进入我们的服务体系。候诊也是一个重要场景。患者在科室门口等面诊、等报告时有明确的停留时间，当年微信刚好支持连接医院 Wi-Fi 后关注公众号，我们就把不同科室的用户导入相应的服务入口。
缴费环节还出现过一个特殊机会：用户微信支付达到规定金额后，可以自动关注指定公众号。单个公众号达到粉丝上限后功能就会失效，所以高峰期我们每周都要注册几个新公众号承接用户。这些做法带有很强的时代特征，但它们背后的判断仍然成立：用户在每个节点的意图不同，不能用同一种内容和转化动作处理。
转化最高的时刻出现在看病结束后。我们曾经给医生桌上放二维码，内部名称叫「患者报到」。我接手后重新设计，把它改成患者能理解的「加医生微信」，并把二维码印在纸上塞进病历，告诉患者有问题可以扫码免费问三个问题。实际结果是，扫码后的患者大多会与医生交流；只要对话达到一定深度，许多人就会在一段时间后购买医生的服务。
我们没有把公众号当成简单的流量池。用户通过哪个二维码、从哪个科室和医生进入，都会被识别。就诊当天、第三天、第七天、一个月后，用户会收到与疾病、科室和医生相关的不同内容。
公众号真正承载的是用户识别、持续触达和服务转化。它是一套生命周期基础设施，而不是一个用来累计粉丝数量的账号。
我们会根据二维码来源判断用户来自哪家医院、哪个科室，甚至哪位医生，再决定推送什么。骨科患者不应该收到与他无关的泛医疗内容，看病当天和看病一个月后也不应该收到同样的信息。每一条路径都对应不同的触达节奏和转化任务。
当时我的团队规模并不大，大致是两名业务人员配合三名研发。公众号矩阵累计获得了约 3500 万粉丝，并成为平台订单转化的重要来源之一。这里最重要的不是粉丝总数，而是我们知道这些人为什么来、此刻需要什么，以及下一次价值交换可能在哪里发生。
单个医院的流程优化得差不多以后，增长遇到了新的瓶颈：继续靠自己的团队逐家实施，速度太慢；依赖患者推荐也很难成立，因为疾病不是适合主动传播的消费场景，医疗天然不适合粗暴裂变。要让业务滚得更快，必须换一种复制方式。
很多医院缺少开发和运营能力，原有系统也常由外包公司维护。我们把挂号、缴费、查报告和生命周期管理做成免费工具，嵌入医院公众号，条件是医院里的医生接入我们的医生端。医院获得一套可用的系统，我们则通过医生端和生命周期体系承接后续服务。第一周同时上线了二十多家医院，效率远高于自己的团队逐家推进。增长的关键不再是继续堆人，而是把自己的能力变成合作方愿意采用的东西。
免费工具解决了单家医院的部署效率，却没有完全解决跨城市扩张的问题。产品和运营能力可以标准化输出，医院关系、地方资源和落地经验却很难由总部远程复制。当业务从一家医院走向几十座城市，增长的瓶颈便从「工具怎样复制」转向「组织怎样复制」。
一家杭州公司很难真正理解全国几十个城市的医疗关系。我们把总部的产品、数据和标准化能力开放出去，在核心城市寻找有长期行业经验的本地负责人，通过子公司分享一部分利润。
总部提供完整能力，本地 CEO 解决医疗关系和落地问题。两者相乘，形成城市扩张速度。跨城市复制不是把总部动作重复七十遍，而是重新设计组织模型。
我们最终相当于把一家公司拆成了几十家城市公司。当地负责人不需要从头组建产品、研发和运营团队，总部把钱、人员、产品和业务方法准备好；他需要做的，是利用多年积累的本地医疗经验，把医院和关键资源连接起来。
在三四线城市，这种模式的成本更低。当地 CEO 分享子公司的一部分利润，也有足够动力推动落地。增长在这里已经不再是一个投放或产品问题，而是「总部能力 × 本地关系」的组织问题。
离开微脉之后，我尝试做社交电商。当时行业都在争夺宝妈人群，我想找一个传播结构更强、又没有被充分服务的人群，最后选择了大学生。
大学生的关系网络天然向外扩散，但真正稀缺的不是流量，而是信任。我进入学校，寻找卖电话卡的人、社团负责人、楼长和宿舍管理人员。这些人才是校园网络里的信任节点。
我选择学生，还有一个原因。当一个人成为宝妈，她身边会出现很多处在相似阶段的人；而一个大学生的同学网络，可能从本校延伸到其他城市甚至海外。它不是围绕单一社区形成的小圈子，而是更分散、更具传播性的关系网络。当时我判断，这种结构的复制效率可能比宝妈市场更高。
但不能因为「大学生多」就把他们看成流量。我去学校待了几天，加了卖电话卡的人、吉他社和滑板社负责人、Cosplay 社团负责人、每层宿舍楼长、宿管阿姨和教官。我要找的是学生已经信任的人，而不是从外部硬插入一个陌生平台。
当时我没有完整团队，也没有多少钱。我先找到一批供应链，用 Excel 标清供货价和利润，再把表交给校园里的信任节点。没有开发复杂系统，第一个月就做出了约 500 万利润，证明学生愿意买、校园节点能够卖、供应链也可以完成履约，这条交易链路是成立的。
这才是我理解的 MVP：它不是一套功能较少的平台，而是用最低成本验证生意中最关键的假设。交易跑通以后，扩张和产品开发要解决的就不再是「这门生意能不能成立」，而是如何把已经验证的动作复制成一百份、一千份。产品和平台不是起点，而是规模化工具。
后来我们发现，要进一步释放学生的消费能力，业务会逐渐触及信贷。但监管政策不允许继续向学生开放相关金融服务，信贷平台最终关闭。这也是商业闭环的一部分：用户需求、产品和交易链路成立还不够，业务还必须在政策和社会边界内成立。
第三个案例是一家建筑 SaaS 公司。产品拥有同行 80% 到 90% 的功能，公司连续投入数年，却没有真正的客户和收入。
我去工地跑了两三周后发现，问题不在功能，而在采用成本。记录数据会给一线人员增加额外工作，有些透明数据还会触碰既有利益。老板获益，一线承担成本，价值和成本完全错位。
这家公司每年大约亏损 2000 万，已经做了三四年。老板早年就在工地搬砖，对行业有很深的经验，也一直靠自己的资金支持产品。站在办公室里看，这套 SaaS 缺的似乎只是销售；到了工地以后，才发现即使购买了竞品的客户，也很难真正让一线人员持续使用。
我在那里听不懂工人的方言，也看到大量记录仍然依赖不同颜色的纸质本子。让他们在原有工作之外再打开 APP、拍照、录入数据，并不是一个「培训一下就能解决」的小问题。
使用门槛不只是界面复杂。员工使用考勤工具，往往不是因为喜欢，而是管理制度要求。在建筑现场，人员结构复杂、操作习惯不同，一线员工还可能因为数据透明而失去灰色收益。
如果只把问题归因于培训不足或功能不够，产品会不断增加功能，却始终无法落地。真正的问题是：谁承担采用成本，谁又能从中获益。
更麻烦的是，建筑行业存在真实的利益冲突。数据没有进入系统时，一些材料损耗和现场行为很难被追踪；一旦完整记录，某些人原有的灰色空间就会消失。对于老板，透明化是价值；对于一线部分人员，透明化可能是损失。
所以客户口中的「不会用」，可能包含三种完全不同的问题：操作确实复杂、改变习惯需要额外成本、或者用户根本不愿意让系统发挥作用。产品团队如果不区分这些情况，就会不停简化界面，却解决不了采用。
解决采用问题，靠的不是继续增加功能，而是重新设计每个角色的利益。老板付了钱，却一直看不到系统带来的管理价值。于是我先用两周做了二十多张数据看板。刚上线时图表几乎都是空的，但每个空白都会说明缺少什么数据、应该由谁补充。老板想看清材料损耗和现场问题，自然会推动对应负责人完成录入。
一线人员承担的是额外的操作成本，「数字化能提高公司效率」对他们并没有直接吸引力。软件一年卖八万元，我们就考虑从收入中拿出一部分，每月奖励完成数据录入的人，用直接收益补偿他们改变习惯的成本。
第一个月，奖励全部被领完，老板的报表中开始出现数据，许多异常也被系统标红。老板据此采取管理动作，管理要求又进一步推动一线持续录入。系统真正转起来，不是因为所有人突然认可数字化，而是因为决策者获得了管理价值，使用者的采用成本也得到了补偿。
复杂 B2B 产品的销售，不是把功能表和许可证交给客户，而是让一套采用机制在客户组织里真正运转。决策者需要看到管理价值，一线人员需要获得足够的使用动力，中间人则要帮助降低跨层级协作的阻力。只有这些角色都进入闭环，产品价值才能通过真实数据被证明。
因此，软件「有人用」是规模化销售的前提，而不是交付后的附加结果。如果产品在单个客户内部都无法运转，卖得越多，实施和服务问题只会越大；采用机制跑通以后，销售才有了可以复制的基础。
我曾经负责一项广告投放业务，后来承包了国内头部平台上相当大一部分广告流量。Banner 点击率达到 40%，说明入口和素材很有吸引力；但用户进入详情页后，大约六七成会直接离开。流量按照 CPM 购买，每一次退出都意味着成本已经发生，却没有形成交易。
入口数据很好、最终结果却很差，说明用户愿意了解，但不接受当前页面提供的商品或表达方式（毕竟是被骗进来的呀）。我们尝试过许多优化，效果始终有限。到后来这个问题后来也让我意识到，用户第一次拒绝的可能只是当前选择，并不一定代表他完全没有需求。
如果只看最终订单，团队很容易得出「流量不精准」的结论，继续换素材、换人群或增加预算。但 40% 的点击率已经证明用户愿意进入，真正的断点发生在他看到第一组商品之后。因此，我们停止继续放大入口，把注意力转向落地详情页。
漏斗的价值就在这里：它不仅告诉我们结果不好，还能帮助定位结果从哪个环节开始变差。此时需要判断的不是怎样获得更多点击，而是用户拒绝的究竟是这类需求、这个商品，还是当前这组选择。
（这个例子我就展示不在博客放产品截图了）
我们最终做了一个实验：在页面上增加了一个假的的关闭按钮，做成带链接的图片。用户点击「叉」时不会直接退出，而会进入另一组商品；再次关闭，还会看到新的选择。这个设计延长了停留时间，基本消化了原来六七成的流失，订单交易量也提升了约 xx%（对外数据就先保密了）。
我把它称为一个「骚操作」，因为它确实有效，却不值得包装成先进方法论。它给了用户更多「选择」，也让用户更难离开，因而可能伤害体验。后来我在其他产品中也见过连续多次挽留用户的类似设计。这个案例留下的真正提醒是：指标可以被优化，但数据变好不等于用户价值同步提高。团队仍要追问，我们是在帮助用户找到需要的东西，还是仅仅增加了退出成本。
在一个北美公链项目里，我几乎只有一个可用的人和两万美元预算，却要完成冷启动、持续获客和留存。当时公链竞争已经非常激烈，其他项目一天的 KOL 和广告投入就可能达到几万美元。沿用相同打法，我们没有任何胜算。
我想到 360 免费杀毒的故事：当整个行业默认软件应该收费时，它直接消灭了这项成本。在公链世界里，类似的默认门槛是 Gas。用户进入一条新链以前，必须先购买对应的原生资产；不同链使用不同货币，购买、兑换和转账都会产生摩擦。有限预算下的突破口，不是购买更多流量，而是直接消灭这个所有用户都会遇到的进入成本。
我们把主要预算直接用于补贴 Gas。用户完成一些简单操作以证明自己不是机器人后，就能获得足够进行十几到二十次链上交互的金额。补贴需要控制在一个微妙区间：太少无法消除门槛，太多又会吸引专业套利。
项目另外只花了两三千美元做传播。由于市场对未来空投存在预期，免费 Gas 很快引发了主动讨论和扩散。后来这条链在一些主流钱包中的活跃数据相当靠前，某头部钱包团队甚至参与了节点建设。冷启动由此完成，但免费 Gas 只解决了用户如何迈出第一步，还没有回答他们为什么长期留下。
免费 Gas 带来了大量追逐空投预期的用户，其中也混有大量女巫机器人。这在预期之内，冷启动完成后，继续增长的关键不是发更多补贴，而是从这些地址的行为中筛选值得服务的真实需求。（其实不是我们完成了冷启动再去看怎么做业务，这里只是为了便于理解）
链上数据让我们能够观察地址持有什么资产、参与过哪些协议。分析后，我们发现一批用户持有较多比特币相关资产。他们既希望获得收益，也希望保持资产流动性。当时行业流行将比特币存入协议获得凭证，再把凭证用于二次质押。我们由此设计了新的价值交换：用户存入凭证，再借出美元，让被锁定的资产重新流动起来。
这类业务风险很高，因此增长不能脱离风控。我们需要验证凭证背后的真实资产，设置预警和处置机制，同时连接愿意提供美元流动性的人。参与者从最初的十个人逐渐增加到一百、一千人…补贴只带来了第一批地址，提升资产效率的真实需求才让业务形成后续闭环。
最后一个案例来自我目前负责的 API Token 业务。市场上存在大量模型中转站，将不同来源的 Token 额度整合后卖给企业或个人，其中一些依赖批量注册云账号等逆向代理方式。我们希望做的是合规版本：与国内外模型供应商正式签约，不承接灰产和黑产资源。
公司的另一项基础能力是 GPU 资源，部分开源模型可以自行部署。相比单纯转售，我们因此有机会更好地控制某些模型的供给、价格和稳定性。这项业务仍在发展中，我将的重点不在包装一个尚未完成的成功案例，而在于判断它究竟是什么生意，以及哪些供给约束决定它能否持续。
接手业务后，我首先要决定该看充值额、客户数，还是其他指标。最终，我把重点放在真实消耗上。客户充值却没有调用，长期需求仍然存疑；只有持续消耗 Token，才能说明 API 正在他的业务里创造价值。除了每周和每月的消耗增长率，我也会观察客户自己的业务是否同步增长。
分析业务健康度时，还要把少数超大客户暂时剔除。大客户当然贡献 GMV 和利润，但异常大的数字会掩盖其余客户的真实状态，让团队把集中度误判为普遍增长。经营结果时要看头部贡献，判断模式能否复制时则要单独观察更广泛的客户群。
看完客户需求后，我发现 API Token 更像供应链生意，而不是单纯的流量生意。客户会比较价格和质量，也会关心额度能否持续、模型是否稳定。某个上游出现问题时，我们有没有其他资源、其他机房或自建模型可以迅速切换？这些看似分散的问题，最后都指向供应链能力。
尤其对国内客户来说，成本很重要，但低价无法单独建立长期合作。营销可以带来一次访问，真正的交付则是在客户需要时稳定提供模型，并在供给波动时及时调度替代资源。流量决定客户会不会来，供应链决定客户敢不敢把核心业务放进来。
增长的第一步，是找到真正高消耗的场景，例如 Agent、开发者工具和批处理业务，再识别这些场景里的目标客户。接入阶段需要降低接口兼容和迁移成本，试用阶段要帮助客户尽快完成第一次稳定调用。正式使用后，内部调度团队还要持续发现资源异常并切换供给，尽量不把上游波动传递给客户。
在此基础上，更重要的工作是客户成功。SaaS、CDN 和短信公司通常都有客户成功经理；这项业务还在早期，我也会直接与客户沟通，帮助他们分析产品怎样获得更多真实用户、业务怎样继续增长。客户扩大 Token 消耗，不应该依赖我们反复催促，而应该来自他自己的产品创造了更多价值。客户的业务增长，我们的消耗和收入自然随之增长，这比一次性充值更可持续。
这项业务还没有一个完整结局。我仍在寻找 API Token 行业真正的「降维打击点」。暂时没有答案，就继续做、继续观察，而不是为了让本次分享的故事完整，而硬造一个结论。
我以前常说：设计向产品靠，产品向运营靠，运营向 CEO 靠。这不是让岗位边界消失，而是让每个人多理解一步下游结果。设计要知道方案是否帮助用户得到价值交换，产品要判断功能能否带来业务结果，运营需要继续靠近收入、成本和供给，CEO 则要让这些角色围绕同一套商业闭环协作。
增长因此不是某个部门的专属职责。一个价值不成立、供给不稳定或组织利益冲突的业务，无法由增长团队独自修复。只有每个角色都理解自己的工作如何影响价值交换，整家公司才可能对最终结果负责。
医院里的挂号入口、校园里的信任节点、工地上的利益关系、广告页里的退出按钮、公链上的 Gas 和模型 API 的供应链，看起来毫无关系，却都在回答同一组问题：用户会在什么场景中行动，谁能推动交易，什么阻碍价值交换，以及已经成立的结果怎样被继续复制。
方法论可以整理思路，却不能代替进入真实业务。很多关键答案不在会议室里，而在医院走廊、大学宿舍、建筑工地、客户的调用数据和一线人员的利益关系中。先看清这些事实，再决定产品和增长应该做什么。
无论做产品、运营、增长还是 AI 出海，最终都要持续完成一场双方认可的价值交换。先把生意做成，再用产品、组织、渠道和资本把它复制出去。增长不是某个部门的任务，而是整家公司理解生意的方式。
好了，谢谢各位，我今天废话连篇的分享大概到这里结束，如果你有任何问题，欢迎添加我的微信：Aipsme 与我进行讨论或业务合作~
2026-06-07 10:00:00
从 2022 年底 ChatGPT 开放给公众那天起，我就一头扎了进去。三年多过去，主流模型轮番上阵，从最早那个「会写诗的玩具」，到如今能陪我把一个 Idea 跑成产品、再跑出第一笔商业化收入。如今 AI 已经成了我使用最高频、投入最多、ROI 最高的工具。
也因为这层关系，身边越来越多的朋友总会问我同一个问题：AI 到底该怎么用？
市面上 AI 教程已经过剩，多数在贩卖一种幻觉：仿佛复制一个神奇的提示词，就能点石成金。但现实是，多数人试过两次觉得不靠谱，从此再也没碰过。
这篇文章不教提示词。我把这三年踩过的坑、和验证过的几条习惯整理出来，希望能给同样在摸索的朋友一点参考。
重要的从来不是技巧，是手感。
我对 AI 预期是这样的：一个看遍了所有书、考遍了所有试，但从没在你公司工作过一天的天才。
它知识满分，反应也快。但对你的业务一无所知：没开过你的会，没见过你的客户，不知道你的资源边界，更不知道你老板上周拍了什么板。
更要命的是，它不知道的时候，不会说「我不知道」，而是会一本正经地编一个看起来很对的答案给你看。
所以两件事很关键：
这三年我越来越确信一句话：AI 时代真正值钱的，不是技术深度，而是业务判断力 × 工具使用能力。AI 帮你干活，但你得知道该干什么活。
AI 犯错的方式很有欺骗性：它说得越自信，你越容易信，但它的自信和准确率之间，并没有必然关系。
几条底线得守住：
也有些事，最好别交给 AI：
信任，但验证。 这是我和 AI 协作的基本态度，三年没变过。
过去，要一个人高效完成跨职能的事，并不容易。产品经理想自己写代码，得脱产学几个月；设计师想独立做产品做运营，得补很多功底；内容创作者想做数据分析，得啃一遍统计基础。
每多跨一个领域，就要补一大堆基础，所以最经济的做法是分工。公司也因此越做越大、团队越做越臃肿。
AI 在改变这个等式。
未来的竞争力，已经不在于你是什么「岗位」，而在于你懂多少业务 × 会用多少工具 × 能用的多好。
下面这几件事，不是设想而是身边正在发生的：
AI 不会取代团队，但它确实大幅压低了「独立完成一件复杂事情」的门槛，它在延长每个人的能力半径。你不需要成为每个领域的专家，只需要把任务描述清楚、交给 AI、再把关质量。
很多人用 AI，其实是在「许愿」：
「帮我写一篇好文章」
「给我出个方案」
「解释写个视频脚本」
这就像你对一个刚入职的实习生说「把这事儿办好」，他不知道你要什么标准、给谁看、什么风格、哪些不能碰。
AI 不是阿拉丁神灯。它是一个极其勤快、但不了解你脑子里潜台词的同事。你给的指令越像一份「作业要求」，它交回来的东西，就越像样。
用了这么多年，我自己稳定下来的还是最朴素的一套：
[角色] 你是 ___（[背景] 现在的情况是 ___[任务] 请帮我 ___[要求] 输出需要 ___（长度 / 语气 / 禁区 / 格式）举个例子。不要说「帮我写个会议通知」，而是：
就这四句话的差别，输出质量能从 40 分直接跳到 75 分。
（朴素，但有效。AI 不需要花活，需要的是清楚。）
这一条特别送给有专业能力的朋友。
AI 出了一个 60 分的稿子，你手痒改两下变成 80 分，改着改着变成全部重写，最后说「还是我自己来吧」，从此再也不用 AI。
我见过太多人这么弃坑。
正确的做法是：当输出不满意时，不要去改它的结果，去改你的指令。
你的目标不是让 AI 一次输出 100 分，而是让这套工作流能稳定输出 75-80 分；剩下的 20 分，由你来做最终判断和润色。
迭代流程，而不是迭代结果。
我对刚开始上手 AI 的朋友的第一条建议是：前期同一个问题，至少抛给三个 AI。
每个模型都有自己的「性格」：
你不需要选出「最强模型」，你要的是长出手感：知道什么任务适合交给谁、谁出「第一稿」、谁做「审稿人」。这事和管理一个小团队没什么两样，得了解每个人的长板和短板。
（顺带一提：这条和上一条不冲突。前期多模型横评是为了「选人」，进入稳定工作流后该锁定主力就锁定主力；横评不是用来代替「改流程」的。）
过程可能要一两周。但一旦手感出来，效率提升是质变的。
AI 最大的优势不是「一步到位给你正确答案」，而是它能在你设计的流程里，稳定地完成很多小步骤。
你越是要它一口气搞定一个复杂任务，它就越容易「看似完整、实则偷工减料」。
比如要 AI 帮你写一份产品需求文档，不要说「帮我写个 PRD」。而是拆：
每一步都是一个明确的小任务，AI 在小任务上的完成度，远高于「一步登天」。
这套思路的本质，不是教 AI 一句万能咒语，而是教你自己一套工作流。
只让 AI 给你一个答案，你拿到的通常是最中庸、最保险、最「AI 味」的那一个，就是那种四平八稳、没有人味、什么都对又什么都不痛不痒的腔调。
我自己的习惯是：
用数量对抗平庸。 当你把平均分和产量都提上来，分布里自然会冒出几个让你眼前一亮的好东西。
这套思路，其实和互联网做增长是同一套底层：A/B Test 的本质，就是用数量和概率去取代「拍脑袋」。
很多人用 AI 时有个反直觉的误区：用 100 字的提示词，要求它写出 3000 字的文章。这就像让一个手头什么资料都没有的人凭空写论文，出来的东西注定是泛泛而谈的水货。
正确的做法反过来：
给它海量材料，让它帮你压缩、提炼、组织。
把会议录音转录稿、行业报告、竞品分析、客户反馈都喂进去，让它从中提取关键信息、整理结构、输出摘要。压缩比扩张容易：把 10 万字压到 1 万字，AI 做得很好；把 100 字扩到 1 万字，十有八九是灌水。
但喂材料也有讲究：AI 会走最省力的路径。给它一个 PDF，它可能只扫了个目录就开始编；给它一个网页链接，它可能根本没真正读完。
所以你要替它做一点「体力活」：
你愿意做一点点准备，AI 的智力输出就会锋利很多。就像你给实习生准备好整理过的资料包，他干活效率自然高。
不要上来就想着「让 AI 帮我重构整个业务」。从身边的「小问题」入手，是更靠谱的开场。
通用场景：
针对不同朋友的「第一个任务」：
每一个小任务都能帮你省 15-30 分钟。一天做三四个，加起来就是一两个小时。用得越多，手感越好，你也会越清楚什么时候该用、什么时候不该用。
这三年看过无数 AI 产品的起起落落，有一个规律非常明确：
真正从 AI 中获益的人，都是在它「还不够好」的时候就开始用的人。
不要等完美的模型出来，不要等最佳实践固化。AI 每隔几个月就有一次大升级，但你和它协作的「手感」，是要靠时间慢慢积累的：
这些经验没有捷径，只能靠用。
模型会迭代，工具会更新；但你对 AI 的理解和驾驭能力，是真正属于你的资产。就像二十年前学电脑、十年前学智能手机一样，早用早受益，越用越顺手。
AI 不是魔法，也不是骗局。它是一个正在快速变强的工具。
和所有工具一样，它放大的是使用者本身的能力。你有好的判断力、好的品味、好的业务理解，AI 就能帮你把这些十倍放大；反过来，你什么都没有，只是对着它许愿，它也只能还你一堆看似正确的废话。
材料 × 品味 × 工具使用能力
——这才是 AI 时代一个人的真正产出公式。
希望这篇对你有用。有问题，随时找我聊。
2024-08-23 14:44:00
最近 SEO 又火起来了特别是在出海圈，很多朋友私底下在频繁咨询我。故放出 17 年在微脉内部做的一次 SEO 分享 PPT 和相关文档。内容比较古早，但基本涵盖 SEO 的核心，在如今用于实战依旧有效，希望能帮助到有需要的朋友。
(地榆是我的花名，别笑…)
SEO 基础规范文档：https://shimo.im/doc/aLMG4FtoLZ8JRoKC
SEO 相关的尬聊：https://shimo.im/doc/7GVFl8rwU2snuY6X·
2024-05-15 05:00:00
Bento.me 是一个零代码创建个人主页的平台，以优雅美观的界面和使用简单而闻名。
但它唯一的缺点是：不支持自定义域名
但别担心，本文将用最简单、零成本的方式，帮助你为 Bento.me 绑定自定义域名。
在终端中输入以下命令，创建一个基础的 Cloudflare Worker：
npm create cloudflare@latest
然后按照终端内说明进行操作：
In which directory do you want to create your application? 你现在哪个目录创建应用
What type of application do you want to create? 你想创建什么类型的应用？
Do you want to use TypeScript? 你想使用 TypeScript 吗？
Do you want to use git for version control? 你想使用 Git 进行版本控制吗？
Do you want to deploy your application? 你想部署应用么？
完成后对应目录会出现一个文件夹，使用 Visual Studio Code 等代码编辑工具打开这个文件夹。
wrangler.toml 文件，在末尾添加下列内容：[vars]BENTO_USERNAME = "len" # 替换为你的 Bento 页面 ID，我的是 bento.me/lenBASE_URL = "https://bento.imzl.com" # 替换为你的自定义域名.dev.vars 文件，黏贴下列内容：BENTO_USERNAME="len" # 替换为你的 Bento 页面 IDBASE_URL="http://127.0.0.1:8787"/src/index.js 文件，替换为下列内容：/* * 为 Bento.me 设置自定义域名 * 作者：len * 详情：https://imzl.com/bento-add-domain * 源代码来源：https://jayfranco.hashnode.dev/ */// 事件监听addEventListener('fetch', event => { // 发生 fetch 事件时，用 handleRequest 函数结果做出响应 event.respondWith(handleRequest(event.request));});// 根据内容类型解析响应async function parseResponseByContentType(response, contentType) { // 如果没有内容类型，响应以文本形式返回 if (!contentType) return await response.text(); // 根据内容类型不同，采取不同的操作 switch (true) { case contentType.includes('application/json'): // 如果是 JSON，以 JSON 字符串形式返回 return JSON.stringify(await response.json()); case contentType.includes('text/html'): // 如果是 HTML，则使用 HTMLRewriter 对 response 进行转换 const transformedResponse = new HTMLRewriter() .on('body', { element(element) { // 自定义 CSS 和 JS 可添加到 HTML 页面中 element.append( ` <style> // 在这里输入你需要的自定义 CSS </style> `, { html: true }, ); element.append( ` <script> // 在这里输入你需要的自定义 JS </script> `, { html: true }, ); }, }) .transform(response); // 转换后的 response 以文本形式返回 return await transformedResponse.text(); case contentType.includes('font'): // 如果内容类型是字体，响应将以 ArrayBuffer 形式返回 return await response.arrayBuffer(); case contentType.includes('image'): // 如果内容类型是图片，响应将以 ArrayBuffer 形式返回 return await response.arrayBuffer() default: // 如果内容类型是其他类型，响应将以文本形式返回 return await response.text(); }}// 处理所有请求的函数async function handleRequest(request) { // 从请求 URL 中提取路径 const path = new URL(request.url).pathname; // 默认情况下，URL 设置为 "https://bento.me" + 路径 let url = 'https://bento.me' + path; // 如果路径包含'v1'，URL 将更改为 'https://api.bento.me' + 路径 if (path.includes('v1')) { url = 'https://api.bento.me' + path; } // 如果 URL 为 "https://bento.me/"，URL 将更改为 https://bento.me/' 后加上 BENTO User ID if (url === 'https://bento.me/') { url = 'https://bento.me/' + BENTO_USERNAME; } // 为 fetch 请求定义基本的 headers let headers = { 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'GET,HEAD,POST,OPTIONS', }; // 使用定义的 headers 获取 URL const response = await fetch(url, { headers }); // 从响应 headers 中提取内容类型 const contentType = response.headers.get('content-type'); // 根据内容类型解析响应 let results = await parseResponseByContentType(response, contentType); // 如果结果不是 ArrayBuffer // 将所有对 bento API 的调用替换为我们的 BASE_URL // 这是解决 CORS 错误的临时方案 if (!(results instanceof ArrayBuffer)) { results = results.replaceAll('https://api.bento.me', BASE_URL); } // 将内容类型添加到 headers headers['content-type'] = contentType; // 返回带有结果和 headers 的新响应 return new Response(results, { headers });}npm run devnpm run deploy2024-02-07 07:00:00
以下是一部分推荐阅读的 Crypto 相关文章列表，从 Dan Romero Blog 复制过来的，以英文为主我已经把标题翻译为中文，建议按时间顺序阅读：
2023-12-27 01:13:00
git clone https://github.com/atomicals/atomicals-js.gitcd atomicals-JavaScriptnpm install -g typescriptnpm run buildnpm install -g yarnyarn installyarn cli wallet-init //这是创建钱包命令最后一步是创建钱包，命令运行后，会在文件夹内生成一个 wallet.json 文件，保存着助记词和私钥，请务必保存好该文件。
创建钱包后，会自动生成两个地址，Primary Address 及 Funding Address：
Primary：用于接收Atomicals生态资产
Funding：用于铸造（挖矿）过程的中转钱包，通常是往 Funding 地址中存入相应数量的 BTC，用于铸造相应资产。
yarn cli mint-dft dmint --satsbyte 30
yarn cli mint-dft quark --satsbyte=100
dmint 和 quark 是 token 名称，请修改成相对应 FT 资产名称。
satsbyte 是矿工费设置，设置 100 即为 100聪/KB 的费用 Mint 对应资产。
yarn cli mint-nft "\punk0000.png" --satsbyte 30 --satsoutput 1000 --bitworkc 233
npm run cli balances
