AI原生创业公司
最近我花了一整个周末，认真啃完了一本来自于Anthtropic整理了一份打造 AI 原生创业公司的实用手册《The Founder‘s Playbook：Building an AI-Native Startup》的手册。读完之后我在书房里坐了很久。不是因为它有多晦涩——恰恰相反，它写得太直白了。让我不安的是：它描述的那个世界，正在以远超我预期的速度变成现实。
在进入正题之前，我想先系统地介绍一下这本手册到底讲了什么。它是我整个思考的起点，也值得每一位关心AI创业的人认真了解。
《The Founder's Playbook》核心内容介绍
这本手册由一系列与AI原生创业密切相关的深度内容组成，系统性回答了“在AI能够自主编写代码、生成内容、分析数据、甚至做出运营决策的时代，创业公司的构建方式会发生什么根本性变化”。
手册的核心主张可以归纳为一句话：AI正在将创业从“资源密集型”转变为“洞察力密集型”。 它不再是一种辅助工具，而是成为创业公司的核心基础设施——就像当年的互联网、云计算一样，但这次变革的程度更深、速度更快。
手册围绕创业的四个关键阶段——Idea、MVP、Launch、Scale——逐一展开，为每个阶段绘制了全新的路线图。但更让我印象深刻的是，它不仅给出了阶段性的方法论，还提供了一套完整的“操作系统”和“衡量框架”，让创始人能够真正驾驭AI的杠杆，而不是被AI的速度反噬。
具体而言，手册涵盖了以下核心模块：
第一，AI驱动的想法验证与市场洞察系统。 在Idea阶段，手册详细展示了如何用AI进行想法压力测试、竞品格局分析、客户调研模拟。它不是让AI告诉你“这个想法好不好”，而是让AI扮演你最严厉的反对者，帮你发现那些你从未考虑过的致命假设。
第二，AI生成MVP的工程纪律与安全实践。 这是手册中极具实操价值的部分。当Agentic Coding让非技术创始人也能在几天内交付产品时，一个被严重低估的风险随之而来：技术债务的快速积累和安全漏洞的引入。手册给出了明确的架构 原则、范围控制方法和安全审查流程，帮助创始人在速度和质量之间找到平衡——不是为了让你成为工程师，而是让你知道“哪些问题必须找工程师把关”。
第三，区分真正PMF与虚假繁荣的衡量框架。 这是手册里让我反复琢磨的部分。AI原生产品常常在上线初期获得爆发式关注，但“很多人试用”和“真正的产品市场契合”是两回事。手册给出了一套系统的衡量框架，帮助创始人判断：那些涌进来的用户，是会留下来的人，还是只是来看热闹的人？
第四，以智能工作流取代创始人精力投入的上线操作系统。 Launch阶段是创始人最容易被耗干的阶段。手册提出了一套“上线操作系统”——用AI构建自动化工作流 ，承担用户反馈分类、常见问题回复、社交媒体监控等任务，让创始人从琐碎的执行中抽身，专注于只有人能做的判断和连接。
第五，Claude产品矩阵的阶段化使用策略。 手册花了不少篇幅介绍Chat、Claude Cowork和Claude Code这三款产品在不同创业阶段的差异化用法——什么时候用对话式AI做探索性思考，什么时候用协作式AI做深度构建，什么时候用自主式AI做规模化执行。这个产品矩阵概念让我重新思考了“用AI”这件事本身：用对工具，和用好工具，是两种完全不同的能力层级。
第六，来自前线的创始人故事。 手册穿插了Ambral、Anything、Carta Healthcare、HumanLayer、Vulcan Technologies等AI原生公司的真实创始经历。这些故事不是用来励志的，而是用来“对照”的——你可以看到这些创始人在Idea、MVP、Launch、Scale各个阶段遇到了什么具体问题，做了什么关键决策，犯了什么错误。某种程度上，这些故事本身就是最好的创业教练。
读完这本手册，我意识到它真正在讨论的，其实不是一个技术问题，而是一个身份认知的问题：当AI能帮你写代码、做市场调研、写投资材料、自动化运营流程的时候，你作为创始人，到底是谁？你在做什么？
创始人的身份正在被重写
手册里有一段话我反复读了三遍：“历史上，创始人的大部分时间花在执行模式上——写代码、管人、处理日常运营工作。在AI原生初创公司中，创始人的角色变得更不像个体贡献者，而更像智能体 的指挥者——这些专门的AI助手可以读取文件、运行命令、执行代码，甚至浏览网页。”
指挥者，orchestrator。
这个词选得非常精准。过去的创始人，不管你是技术出身还是商业出身，本质上都在充当公司里最全能的那个“超级员工”。产品出问题了你顶上，客户投诉了你出面，投资人材料你亲自写，代码架构你亲自定。但AI原生时代的创始人，核心能力变成了调度：你知道调用哪个模型完成哪项任务，你知道如何把一个大目标拆解成AI可执行的工作流，你知道在什么时候需要人的判断介入、什么时候可以完全放手。
手册还指出了一个更具革命性的结果：AI作为核心基础设施，最大的意义是解放了那些有行业专长但不懂技术的创始人。当创业的准入门槛不再取决于你会不会写代码，而是取决于你对某个领域有多深刻的理解，整个创始人群体就被极大地拓宽了。
这让我想起一句话：未来最好的创始人，不是最会干活的人，而是最会提问的人。 因为当你把执行层面交给AI之后，你唯一不可替代的价值，就是你提出的那个问题——那个只有你看到了、而别人还没有意识到的问题。
OPC不是退而求其次，而是新范式
在这个语境下，我们必须认真讨论一个概念：OPC（One Person Company）——“一人公司”。它不仅仅是法律意义上由单一自然人控股的企业，更象征着一种属于AI时代的创业新模式——个人与AI深度协同，以一个“超级个体”的姿态，撬动曾经需要团队才能完成的梦想。
坦白说，我第一次听到“一人公司”的时候，心里有些不以为然。一个人能做什么？充其量是个小生意吧。但当我看到那些案例——3人公司、9周赚了700万，40多人做到18亿美金估值——我才意识到自己有多傲慢。
OPC的核心逻辑不是“退而求其次”，而是用AI的杠杆效应重构生产关系。传统创业依赖“人力杠杆”实现规模扩张，你雇佣的人越多，你的产出越大。而AI驱动的OPC构建的是“1+N”智能体矩阵，其中“1”是核心创始人的战略决策能力，“N”是算法驱动的数字员工集群，承担内容生产、数据分析、客户响应等标准化任务。
这意味着什么？意味着你的规模不再受限于你管理的人数。你能调用多少模型，整合多少流程，就等于拥有多少生产力。
当然，OPC也不是万能的。有创业者总结了三种可落地的OPC路径：项目制专业服务变现迅速、适合起步；产业化定制服务面向企业提供高附加值IP；以及资源整合平台构建创作者网络。但核心门槛也非常明确——商业模式适配能力和AI应用能力，缺一不可。
给OPC创业者的建议： 从一开始就建立“AI密度”的意识。不要让OPC变成“一个人硬扛所有事”，而是“一个人指挥一支AI军团”。你每接手一项任务，第一反应都应该是：这个任务能不能被AI完成或者部分完成？如果不能，为什么？这个思维习惯会决定你最终是陷入疲于奔命的个人英雄主义，还是真正驾驭AI杠杆的超级个体。
AI原生不是“AI优先”，而是“没有AI就不存在”
很多人混淆了两个概念：“AI优先”和“AI原生”。区别在哪里？
“AI优先”是在原有商业模式上嫁接AI来提高效率，而“AI原生”是从第一天起，公司的价值主张、运营模式、商业逻辑就完全建立在AI的基础之上。狠一点说，若没有AI，这家公司根本不会存在。
这个区别至关重要。很多传统公司开始“拥抱AI”，但本质上是在旧系统上打补丁。而AI原生公司的组织架构、成本结构、增长模型，从基因层面就是不同的。
手册里那些创始人故事——Ambral、Carta Healthcare、HumanLayer——都在反复验证同一个道理：AI原生公司不是在旧房子上加装新设备，而是直接在AI的地基上盖房子。 这个选择会让你的前六个月看起来更激进、更冒险，但一旦地基稳固，你的规模化速度会让传统公司望尘莫及。
一些个人感悟：为什么我感到不安
回到开篇提到的那种不安。
我仔细想了想，这种不安来源于一个认知：当创业门槛降到历史最低，竞争就会升到历史最高。当每个人都能用AI做出一个MVP，你的差异化在哪里？当每个公司都在用AI做客户服务，你的护城河是什么？
手册给的答案是：创始人的判断力。 当执行被AI商品化之后，唯一稀缺的资产就是你对某个问题的独特理解和你的决策质量。
这也意味着，创业这件事正在从“资源密集型”转向“洞察力密集型”。过去你可以靠资本、靠团队规模建立壁垒。未来，你的壁垒只有一个：你看到了什么别人没看到的东西，以及你能多快把它做出来。
这让我既兴奋又谦卑。
同时，手册里关于“技术债务”和“虚假PMF”的警告也让我重新思考：AI给创业者的礼物，并不全是加速。它也可能让你更快地走向一条错误的道路，更早地累积起一堆难以清理的技术和历史包袱。AI缩短了试错周期，但并没有消除试错的必要性——它只是要求你必须更快地从错误中学习。
写在第一篇的最后
这本手册的六个核心模块——想法验证、MVP工程纪律、PMF衡量框架、上线操作系统、产品矩阵策略、创始人实战故事——共同构成了一套完整的AI原生创业体系。在接下来的系列文章中，我将逐一深入拆解每个阶段的具体打法。
但无论我们讨论多么实操的战术，我希望你始终记住第一篇里的这个核心命题：
在AI原生时代，创始人的身份正在从“最会干活的那个人”变成“最会判断的那个人”。
这个转变是痛苦的，因为它要求你放弃那些让你感到安全的技能标签，转而依赖一种更抽象、更难以量化的能力：判断力。但它也是解放的，因为它让创业这件事第一次真正地向所有拥有深刻洞察力的人敞开了大门，无论他们是否懂得技术实现。
最后，用一句值得每个AI创业者贴在墙上的话收尾：门槛越低，越考验判断力。
获取更多 AI 咨询、一人公司、创业读书笔记、Openclaw、Claude Code 实战干货，欢迎关注我评论区留言获取《The Founder‘s Playbook：Building an AI-Native Startup》全书
过去十年的创业圈里，有一句话被奉为圭臬：“想法不值钱，执行才值钱。”
这句话曾经是对的。在那个年代，把一个想法变成可验证的产品，需要一支团队、一笔钱和一段不短的时间。投资人的邮箱里每天躺着上百个商业计划书，谁有能力把它们做出来，谁才有资格上牌桌。想法本身，确实不值钱。
但我越来越强烈地感觉到，这个等式正在被AI改写。
当一个人加上AI就能在三周内做出一个可用的MVP时，“执行”正在被商品化。过去稀缺的能力——写代码、做设计、搭系统——正在变成人人都能调用的基础服务。而真正稀缺的东西浮出了水面：你最初要解决什么问题？你为什么是解决这个问题的最佳人选？
好想法，正在重新变得值钱。
但这不意味着任何想法都值钱。恰恰相反，正是因为“做出来”的门槛降到了历史最低，你的想法必须经得起更残酷的审视。门槛越低，对判断力的考验就越残酷。这一篇，我想跟你聊聊，在AI原生时代，如何用一个系统化的方法，验证你的想法是否值得投入你为数不多的时间和资源。
第一步：在你爱上自己的想法之前，先让AI扮演你最凶猛的反对者
我发现一个规律：绝大多数创始人——包括我自己——对一个新想法的第一反应都是爱上它。这是人性。我们的大脑会下意识地寻找支持自己想法的证据，忽略那些不利的信号。这种“确认偏误”在过去可能只造成几周时间的浪费，但在AI时代，它可能让你在三天内就做出一个注定失败的产品，然后花三个月才肯承认它没戏。
所以，我给自己立了一个规矩，也想分享给你：在你向任何人类展示你的想法之前，先让AI扮演你最凶猛的反对者。
具体怎么做？把你的想法用最诚实的方式描述给AI——不是写一个漂亮的融资话术，而是原原本本地描述你要解决什么问题、你的目标用户是谁、你计划怎么赚钱。然后，给AI下达几个明确的指令：
“找出这个想法最脆弱的五个假设。”
“用红队思维攻击这个商业模型——如果它注定会失败，最可能的三个死因是什么？”
“假设你是这个领域的资深从业者，你对这个想法最大的质疑是什么？”
我第一次对自己一个酝酿了很久的创业想法做这个实验时，心情非常复杂。AI在十分钟内指出了七个我没有认真考虑过的致命问题。其中有一个问题直击要害：我假设用户愿意为某个功能付费，但我没有任何证据支持这个假设——我只是觉得“理所当然”。那种感觉像被泼了一盆冰水，很不舒服，但我知道它帮我避免了一次代价高昂的试错。
特别想对OPC创业者说： 这一步对你尤其关键。在一个传统团队里，你的联合创始人、投资人、早期顾问会天然地扮演“质疑者”的角色。但当你是一个人的时候，没有人会主动挑战你。AI是你唯一可以随时随地调用、不会顾及你面子、完全诚实的反对者。不用它，你就失去了OPC模式下最稀缺的东西——外部压力测试。
第二步：让AI帮你画出你不知道存在的竞争地图
传统的竞品分析有一个致命的局限：你只能分析你已经知道的竞争对手。但真正危险的往往不是那些你紧盯着的直接竞品，而是那些从你完全没想到的角度切入的“跨界杀手”。
我在研究自己的目标市场时，用了一个让我后背发凉的方法。我没有只问AI“我的直接竞争对手是谁”，而是设计了三个更深层的问题：
“用户目前用什么方式解决这个问题？” ——这个问题帮你找到“替代方案竞品”。它可能不是一个产品，而是一种行为习惯，比如用Excel 手动处理、在微信群里口头沟通。替代方案竞品往往比你想象的要根深蒂固得多，因为改变用户的行为习惯比击败一个竞品产品难十倍。
“谁最有可能在六个月内进入这个市场？” ——这个问题帮你识别“潜在进入者”。它可能是相邻领域的巨头正在寻找新增长点，也可能是某个技术突破让以前不可能的事变成了可能。提前看到他们，你至少可以在定位上做出差异化的选择。
“有哪些看起来完全不相关的领域的公司，正在以不同的路径逼近同一个用户场景？” ——这个问题帮你发现“跨界威胁”。我做这个分析时，发现了三个我从未想过的对手，它们从不同的起点出发，正在向完全相同的用户需求汇聚。如果没有这一步分析，我可能要到产品上线几个月后才会意识到他们的存在，而那时候他们已经跑得很远了。
做完这三个维度的分析之后，我的感受是：AI不是在帮你做竞品分析，AI是在帮你打破信息茧房。 它不能替代你对行业的理解，但它能极大地拓展你看到的信息范围，帮你避免“只见树木不见森林”的盲区。
第三步：用AI模拟用户访谈，在见真用户之前先“预演”你的假设
这是我觉得最巧妙的一步，也是最容易被误用的一步。
具体做法是这样的：定义一个非常详细的用户画像——不只是“30岁白领女性”这种粗糙的标签，而是要具体到这个人的工作场景、日常痛点、决策逻辑、预算权限、甚至她昨天下午三点在做什么。然后，让AI扮演这个用户，你来“访谈”它。
我第一次尝试这个方法的时候，以为会得到一堆泛泛而谈的废话。结果出乎意料。当我定义了一个足够具体的用户画像后，AI模拟的回答让我发现了自己问题设计中的好几个盲区——我问了一些在真实用户看来会觉得“这根本不是我关心的问题”的东西。
但我要特别强调：模拟用户访谈是真实用户研究的预演，不是替代品。 它最大的价值是帮你发现你的问题设计是否合理、你的假设是否经得起推敲、你对用户的理解是否过于表面化。它让你在浪费真实用户的时间之前，先做一轮自我校正。
模拟结束后，我建议你追加一个灵魂拷问式的提示：“基于你刚才扮演的这个用户，请你诚实地评估——这个产品是否真正解决了一个让你痛苦到愿意付费的问题？如果答案是否定的，请说明原因。”
这个问题的回答，往往比你之前的整个访谈过程更有启发性。因为它强迫AI跳出“配合你演戏”的模式，给出一个更接近真实判断的评估。
第四步：构建AI原生的价值主张——你真正的差异化不应该是“有AI”
这是最容易被忽视，也最致命的一步。
我观察到很多AI创业者——包括我在内——会不自觉地陷入一个陷阱：把“用了AI”当作自己的核心卖点。“我们有AI驱动的客服系统”、“我们是一个AI原生的CRM”……这些表述在2024年可能还有用，但在今天，它们已经变得毫无区分度。
我的理解是：AI原生公司的价值主张，不是因为它“用了AI”所以更好，而是因为它“建立在AI之上”所以能提供传统方式根本无法提供的价值。
举个例子。一家传统翻译服务的价值主张是“更便宜、更快地翻译文档”。但一家真正的AI原生翻译产品的价值主张可能是：“让你的跨国团队像在同一个房间里一样自然交流——不只是翻译文字，而是同步理解语境、语调和专业术语，并在对话过程中持续学习团队的表达习惯。”后者不是“更好的翻译”，而是一种传统翻译服务根本不存在的产品形态。
我问自己的一个核心问题是：如果我把“AI”这个词从我的产品描述中完全拿掉，我的产品还能提供什么独特价值？如果答案是“就没剩什么了”，那说明我还没有找到真正的差异化。
给OPC创业者的特别叮嘱： 在Idea阶段，你的资源极度有限。一个OPC创业者最大的风险不是“选错了方向”，而是“在一个模棱两可的方向上消耗了太多时间却得不到明确的信号”。所以我对自己的要求是：在这个阶段花至少两周时间，用AI工具做尽可能全面的验证。多问自己一个问题——“如果这个方向是错的，我能不能在一个月内发现并转向？”如果答案是不能，说明你的验证周期太长了，需要把假设拆得更小。
这个阶段我常用的一些工具和方法
工具层面，我不打算给你一个长长的清单。工具在快速进化，今天推荐的可能明天就过时了。我更想分享的是使用工具的方法论：
对话式AI（如Claude、ChatGPT） 是Idea阶段最重要的伙伴。用它做红队攻击、模拟访谈、价值主张打磨。关键不是用什么模型，而是你问出什么问题。
深度搜索工具（如Perplexity） 用于市场调研和竞争情报。它能帮你找到那些传统搜索难以发现的跨领域信息和新兴趋势。
快速展示工具（如Gamma） 用于把你的想法快速变成可以分享给他人的可视化 材料。当你想找一个朋友做“人类干扰”验证时，一个结构清晰的展示比口述效果好得多。
JTBD（Jobs To Be Done）框架 是我验证想法时最喜欢用的思考工具。它让我从“用户画像”的表层描述，深入到“用户雇佣这个产品要完成什么任务”的本质问题。AI可以帮你用JTBD框架分析你的目标用户——试试这个提示词：“基于JTBD框架，分析[目标用户]在[某个场景]下真正需要完成的任务是什么？他们目前用什么方式完成？存在哪些未被满足的需求？”
写在Idea阶段的最后
读这一部分的时候，有一句话在我脑子里久久散不去：“最好的AI原生想法，往往来自那些在一个垂直领域深耕多年、深刻理解那个领域痛点的人，而不是来自AI技术专家。”
这句话给了我很大的触动，也给了我希望。它意味着，AI原生创业时代最大的红利，不是给技术专家的，而是给那些在某个领域积累了深厚行业认知的人的。你的行业经验、你对某个具体问题的独特理解、你在那个领域里建立的信任和关系——这些东西是AI无法替代的，也是最稀缺的资产。
但这份红利只会留给那些愿意花时间做验证的人。AI可以让你的构建速度快十倍，但它也让你走向错误方向的速度快了十倍。在Idea阶段，慢就是快。 用两周时间做充分的验证，比用两天做一个产品然后花两个月困惑为什么没人用，要高效得多。
下一篇文章，我会进入MVP阶段——当你的想法经过了足够的验证，得到了第一个“值得继续”的信号，你该如何在极低预算、极小团队的条件下，把它变成一个可以接受用户检验的产品。
去年秋天，一个做外贸的朋友跟我说，他想做一个自动处理跨境报关单的工具，但一直没动手。不是没需求——他手里攥着十几个等着付费的客户。而是他没技术，找不到合适的技术合伙人，外包报价又贵得离谱。
上个月他给我发了个链接。他用AI工具，花了两个周末，独自把这个工具做出来了。已经有两个客户开始付费使用。
这件事给我带来的冲击，比任何行业报告都来得直接。一个从未写过代码的人，用两个周末做出了一个能收钱的产品。这意味着什么？意味着“做产品”这件事的门槛，正在以肉眼可见的速度消失。
这让我迫不及待地开始深入研究这个课题。我想搞清楚，在这个门槛消失之后，我们真正该把注意力放在哪里。
一个人能走多远：从“想都不敢想”到“做给你看”
我读到的几个真实案例，让我反复确认了细节。
一个完全没有编程背景的创始人，借助Agentic Coding工具，在两周内交付了一个功能完整的SaaS产品的第一个付费版本。另一个创始人，用AI在三天内完成了从原型到上线的全部过程，并在上线第一周获得了首批付费用户。还有一个：一个创始人只用了一个周末，就做出了一个后来获得数十万用户的产品雏形。
说实话，看到这些的时候，我心里经历了一个三段式变化。第一反应是震惊——这种效率放在三年前，我会觉得是天方夜谭。第二反应是兴奋——这意味着有无数被技术门槛挡在门外的优秀想法，终于有了被实现的机会。第三反应是冷静下来问自己一个更关键的问题：当每个人都能用AI做出产品时，产品本身就不再是壁垒。你真正需要回答的是：你做的这个东西，到底解决了什么真实问题？
我现在深刻体会到，AI已经将“从想法到MVP”的时间，从几个月压缩到了几周甚至几天，而且这个压缩不以牺牲基本质量为代价。注意“基本质量”这个词——我并不认为AI生成的代码在架构优雅性上能与资深工程师手写的代码媲美，但它的质量已经足够好到可以验证一个商业假设。而这恰恰是MVP的全部意义。MVP从来不是为了写出完美的代码，而是为了用最少的投入，得到关于用户需求的最诚实的回答。
Agentic Coding：从“你自己写”到“你描述它做”
让我真正理解这个变化的关键，是一个概念：Agentic Coding。
传统的AI编程 工具像一个副驾驶——它帮你写代码片段、做代码补全，但方向盘始终在你手里。你需要知道你要去哪里，你需要理解路线图，你需要在它犯错的时候纠正它。
但Agentic Coding完全是另一回事。它更像你直接雇了一个能独立工作的工程师。你告诉它你想要什么，它自己规划实现路径、编写代码、运行测试、检查错误、修复bug，然后向你汇报结果。你可以对它说：“这个页面需要一个数据看板，数据从这三个接口取，显示最近30天的趋势，支持按地区筛选”，然后它会自己完成这一切——包括处理数据为空时的兜底逻辑、筛选条件变化时的状态管理、以及不同屏幕尺寸下的响应式布局。
这个区别的意义怎么强调都不过分。我特别认同一个总结：过去你需要理解代码才能构建软件，现在你需要理解你想要什么。
对于一个有行业专长但不懂编程的创始人来说，这打开了一扇以前被锁死的门。那个在你脑海里盘旋了三年的产品想法，现在终于可以被做出来了——而且是你自己把它做出来，不需要等技术联合创始人加入，不需要融到第一笔钱去雇佣开发团队。门槛从“掌握一门编程语言 ”变成了“清晰地描述一个问题”。
让速度飞一会儿——关于速度、债务与安全的新思考
这是整个学习过程中让我最兴奋、同时也让我最警醒的部分。
兴奋在哪里？兴奋在于，AI第一次让非技术创始人可以独立走完“从想法到产品”的完整闭环。这是一次生产力的彻底解放。过去你有个想法，你得先说服一个工程师加入你，或者去融一笔钱雇人。这个过程本身就可能花掉你半年时间。而现在，你今天有个想法，今天晚上就能看到它的雏形。这种即时反馈带来的可能性，让我觉得我们正站在一个巨大的拐点上。
但警醒同样重要。我注意到了一个非常容易被忽视的陷阱：当你用AI在几天内做出了一个能跑的产品，你很容易产生一种错觉，觉得这就是你的产品基础了。你开始在这个基础上加功能、修复bug、对接客户。三个月后，你发现产品已经变成了一团无法维护的乱麻——你想加一个小功能需要改五个地方，你不知道为什么那个按钮有时候会消失，你更不知道你的用户数据是否安全。
我把这种现象叫做“AI速度债”——因为你构建得太快而积累的隐性债务。它比传统技术债务更隐蔽，因为你缺乏一个技术团队来帮你发现和预警。当你一个人用AI构建MVP时，没有人在旁边提醒你：“这里需要加一个异常处理”、“这个接口调用会暴露用户信息”。
我要特别强调一点：这绝不意味着你应该放慢速度。恰恰相反，正因为你可以在几周内做出MVP，你更应该尽情拥抱这个速度。 只是你需要带着一套清醒的纪律去拥抱它。我为自己总结了三根“护栏”，它们恰恰是为了让你在保持高速的同时不至于翻车：
第一根护栏：范围纪律——明确你的MVP到底在验证什么。 AI让加功能变得太容易了，容易到你会不自觉地想：“既然AI十几分钟就能多做一个小功能，为什么不做呢？”我的回答是：更快的构建速度，不该成为更差的产品判断力的借口。在开始构建之前，你应该先问自己：“我要验证的核心假设是什么？哪些功能对这个验证是绝对必要的？”然后冷酷地把所有不必要的东西砍掉。AI可以帮你更快地做事，但不能帮你决定该做什么事——那个判断必须由你来做。
第二根护栏：架构纪律——为“可抛弃性”而构建。 传统软件工程强调可维护性和可扩展性，但MVP阶段的代码有极高的概率在验证后被完全重写。所以，MVP阶段追求架构完美是错误的目标。正确的目标是：在保持代码基本可读和安全的前提下，让代码足够好到能完成验证，并且足够清晰到能让你在验证完成后，快速决定是“基于它重构”还是“彻底重写”。我的做法是，要求AI在生成代码时明确说明代码结构和关键决策——这些说明本身，就是我未来做重构决策时的核心文档。
第三根护栏：安全纪律——知道哪些事情必须找人类工程师把关。 AI生成代码中最容易出问题的领域是：身份验证、用户数据处理、支付流程、API密钥管理 。如果你是一个非技术创始人，在这些安全关键点上，不要完全信任AI生成的代码。找一个你信任的工程师朋友做一个小时的Code Review，或者使用专门的安全扫描工具。我很认同一个观点：在安全问题上，花200美元请一个工程师做一小时审查，比上线后处理数据泄露便宜一万倍。
这三根护栏的意义不是让你的代码完美，而是让你在享受AI速度红利的同时，不被隐藏的风险绊倒。让你可以放心地拥抱快，而不是因为担心翻车而减速。
非技术创始人最容易踩的三个坑
作为一个长期和创业者打交道的人，我看到太多非技术背景的创始人在这个阶段栽跟头。我总结了自己观察到的三个最常见的坑：
第一个坑：试图先学会编程再动手。 我的态度非常明确：在Agentic Coding时代，非技术创始人最不该做的事就是花三个月去学一门编程语言。你的时间应该花在理解“能构建什么”上，而不是“如何构建”上。你需要培养的核心能力不是写代码，而是精确地描述你想要什么——功能描述、边界条件、异常处理逻辑、用户交互细节。这些描述就是你给AI的“需求文档”，它们的精确度直接决定了AI生成代码的质量。你不需要成为一个工程师，但你需要学会像一个优秀的产品经理那样思考和表达。
第二个坑：盲目信任AI的输出。 AI生成的代码可能包含你完全不懂的逻辑、你没有意识到的数据调用、或者在边界情况下会崩溃的处理方式。你不需要读懂每一行代码，但你需要养成一个习惯：让AI向你解释它在做什么。“请用非技术语言向我解释这段代码的核心逻辑”、“这个函数在什么情况下可能会失败”、“如果用户输入为空会发生什么”——这些提示词是你作为非技术创始人的安全网。把AI的代码当作一个需要接受质询的黑箱：你不一定要理解它的内部结构，但你要反复追问它的边界和假设。
第三个坑：在MVP上停留太久。 这是最微妙的一个陷阱。因为AI让你能自己构建产品，你可能会在“打磨产品”中获得一种持续的正反馈——每次你加一个新功能，都能马上看到效果。这种爽感会让你不自觉地停留在舒适区里，不断打磨一个还没有被市场验证过的产品。有一句话我想裱起来挂在墙上：AI可以帮你构建一个产品，但AI不能告诉你这个产品是否值得构建。 在MVP阶段，你最大的风险不是产品做得不够好，而是你花了太多时间做一个根本没人需要的东西。
对OPC创业者说的几句心里话
这一部分，我想直接对选择“一人公司”这条路的朋友说几句。
当一个人用AI构建MVP时，整个构建过程发生在一个高度封闭的回路里：你提出想法，AI实现它，你看到结果，你提出修改，AI再实现。这个回路可以跑得飞快，但它有一个结构性的缺陷：没有任何人在这个回路里挑战你的假设。
在传统团队中，工程师会质疑产品经理的需求是否合理，设计师会挑战交互逻辑，合伙人之间会因为产品方向激烈争论。这些摩擦看起来低效，但它们是你创业判断力的“压力测试”——它们帮你提前发现了那些你一个人想不到的问题。当你一个人与AI协作时，AI不会主动质疑你。它会忠实地执行你的每一个指令，即使那个指令本身存在问题。
所以我有三个具体建议：
第一，在构建过程中主动引入“人类干扰”。 不需要雇人，不需要找顾问。每周找一个人——朋友、前同事、目标用户都行——把你做出来的东西给他看，问他三个朴素的问题：你觉得这解决了什么问题？你会愿意为它付费吗？你觉得哪里不对劲？这些朴素的问题，往往能戳破你在封闭构建过程中形成的认知泡沫。
第二，重新定义什么是“完成”。 很多OPC创业者下意识地把“做出了一个能跑的产品”当作里程碑。但我现在会对自己说：里程碑不应该是产品的完成，而应该是验证的完成。你的MVP是否成功的唯一标准是：它有没有帮你获得关于用户需求的一个明确的信号？如果答案是“没有”，那不管这个产品做得多漂亮，这个阶段的真正任务就还没完成。
第三，工具成本上保持梯度升级的节奏。 OPC的资源极其有限。我的建议是：MVP阶段，先用免费或低成本的工具跑通完整流程，然后根据验证到的信号逐步升级。你不需要一开始就购买最贵的Agentic Coding服务。先用对话式AI做需求梳理和功能拆解，用免费的部署 平台上架你的MVP，等获得了第一个真实的用户信号之后，再考虑为更高级的工具付费。这个节奏能帮你在资源紧张的情况下，把好钢用在刀刃上。
这一阶段的工具与心法
我花了不少时间去了解Agentic Coding的生态：Cursor、Windsurf、Replit、Bolt、Lovable这些工具各有侧重，有的擅长前端交互，有的擅长全栈构建，有的在自主纠错方面表现更稳定。部署和后端方面，Vercel和Supabase是被频繁提及的组合。Claude Code在深度构建场景下也展现出了独特的能力。
但我最深的体会是：具体的工具推荐今天有用，三个月后可能就已经不是最优选了。真正需要内化的，是“用AI构建”的思维方式。
我把它总结成三条：
第一，从“我要写代码”变成“我要描述产品”。 你的角色从构建者变成了描述者。你描述得有多清晰、多具体、多考虑到边界情况，AI就做得多好。描述能力，正在成为新的硬技能。
第二，从“一次构建完成”变成“持续对话构建”。 用AI构建产品不是下达一个指令然后等待成品。它是一个持续的对话过程——你说，它做，你试，你给反馈，它改。这个对话的深度和质量，决定了产品的深度和质量。
第三，从“信任但验证”变成“委托但审计”。 你把执行委托给AI，但你保留审计的责任。你不需要检查每一行代码，但你一定要检查那些关键的节点——安全相关的逻辑、用户数据处理的路径、核心功能在异常输入下的表现。审计不是因为你信任不够，而是因为这是你作为创始人的责任。
从执行到验证的跨越
在MVP这部分内容的末尾，有一句话我反复琢磨了很久：你构建MVP的速度，不该超过你从中学习的速度。
这句话点破了AI原生MVP阶段最核心的矛盾。构建速度被AI极大地提升了，但学习速度——你从用户那里获取反馈、更新认知、调整方向的速度——并没有被同步加速。你可以在三天内做出一个产品，然后花三个月困惑为什么没人用。问题不在于产品做得不够快，而在于你跳过了那个最关键的步骤：在构建之前、构建之中、构建之后，持续地问自己：我到底在验证什么？
MVP不是一个产品，它是一个实验装置。你不是在做一个产品，你是在用最少的时间和资源，去测试你对用户需求最核心的那个假设——它是否成立。AI让这个实验装置的搭建变得前所未有地便宜和快速，但它并没有改变实验的本质：你需要一个清晰的假设，一个可操作的实验设计，以及对实验结果诚实到近乎冷酷的解读。
而这一切，AI帮不了你。它只能帮你执行，不能帮你判断。
下一篇文章，我会聊聊Launch阶段——当你的实验得到了第一个值得继续的信号，该怎么用AI原生的方式把它推向市场？以及在发布期，怎样保护创始人最稀缺的资源：你的注意力和判断力。
如果说MVP阶段让团队心跳加速，那Launch阶段的内容，是让团队彻底坐不住的那一环节。
过去我们理解的“产品发布”，有一个相对固定的剧本：打磨产品，找一批内测用户，收集反馈，慢慢积累口碑，同时搭建销售团队，开始做内容营销，争取媒体报道，等待增长曲线缓慢爬升。这个过程，按月计算都算快的，按年计算也不算慢。
但我在Launch章节里看到的案例，把这个时间线撕得粉碎。
看过一篇报道：有一个AI原生SaaS产品，从正式上线到100万美元ARR，只用了4个月。另一个案例更让我反复确认数字：45天，创收3600万美元。还有一个，8个月ARR突破一亿。反复确认这些数字不是印刷错误之后，脑子里只剩下一个问题：他们到底做对了什么？
答案不是“他们有个好产品”——好产品是前提，但不足以解释这种爆发力。答案是：他们玩的根本就不是传统SaaS的GTM游戏。他们发明了一套全新的剧本。
不是加速，是重构
传统SaaS的GTM依赖几个核心支柱：内容营销积累SEO权重，销售团队逐家拜访或做演示，渠道合作慢慢铺开，品牌广告持续投入。这些渠道的共同特点是：需要持续的人力投入，见效缓慢，但长期可积累。它们像种树——你今天浇水，三年后乘凉。
而AI原生公司的GTM，更像是在放一把火。火的蔓延速度不取决于你浇了多少水，而取决于你点燃的那一瞬间，风往哪边吹，燃料是否干燥。
我的理解是：AI原生公司的GTM策略，不是传统GTM的加速版，而是一种全新的物种。 它们有三个我反复琢磨的特征：
第一，产品即营销。 当你的产品因为AI而拥有一个“神奇时刻”——用户第一次体验时那种“天啊这竟然能行”的震撼瞬间——这个产品本身就自带传播属性。用户会截图发社交媒体，会拉同事来试，会在社区里自发安利。你的营销预算最应该投向的地方不是广告位，而是让更多用户抵达那个“神奇时刻”。
第二，Launch是一个事件，不是一个阶段。 传统SaaS的Launch是漫长增长曲线的起点。而AI原生公司的Launch，本身就是一个引爆点。Product Hunt的霸榜、某个演示视频在社交网络的病毒传播、某个行业KOL的自发推荐——这些事件集中爆发，在极短时间内把产品推到临界质量，然后飞轮自己转起来。
第三，增长本身也用AI来做。 这是我以前想都没想过的事。AI不只帮你做产品，还帮你做增长：AI生成个性化外发邮件，AI分析用户行为数据找出转化瓶颈，AI自动优化落地页文案和布局，AI辅助设计A/B测试并解读结果。增长团队可以小到只有一个人加一群AI Agent 。
Launch的三个阶段：我的拆解和真实感受
我把Launch拆成了三个阶段，每个阶段有不同的核心任务，也有不同的心理陷阱。
Pre-Launch（发布前2-4周）：积累势能，而不是制造噪音
这个阶段最容易被误解。很多创始人以为Pre-Launch就是“提前宣布”，发几篇预热文章，在社群里广而告之。但我学到的教训是：Pre-Launch的核心不是广而告之，而是找到第一批“正确的人”。
什么是我说的“正确的人”？不是那些随手点个赞的路人，而是那些真正有痛点、愿意深度使用、愿意给你反馈、愿意向别人推荐的人。一个拥有50个狂热早期用户的AI原生公司，比一个拥有5000个沉默等待用户的公司更有爆发力。
我的具体做法是这样的：
先用AI生成一整套Launch物料——不是为了让AI替你写，而是用AI做第一稿，然后你自己注入真实的情感和判断。PR 稿的初稿、社交媒体帖子的多个版本、Product Hunt的文案、甚至Demo视频的脚本，都可以让AI先出一版，你再修改到“像你说的话”为止。
然后，建一个等待列表，但别只是让人留个邮箱就完了。我用AI自动化了一个流程：新加入列表的人会收到一封个性化的欢迎邮件，问他们“你最期待这个产品解决什么问题”，然后把他们的回复分类整理好。这个动作有两个效果：第一，它帮我提前理解了早期用户的需求；第二，它让等待列表上的人感觉到自己在参与一件事，而不是被动等待。
最后，在目标用户聚集的社区里开始真诚地参与对话。注意我的用词是“参与对话”，不是“硬推广”。你带着你的行业认知去回答问题、提供价值，你的签名档里带一个等待列表的链接 ，这比在十个群里扔推广海报有效十倍。
给OPC创业者的提醒： Pre-Launch是你最容易被耗干的阶段。一个人要处理物料、社区、用户沟通，很容易陷入“什么都做了但什么都没做好”的困境。我的建议是：用AI把你从重复性任务中解放出来。自动回复、物料初稿、信息分类——这些全交给AI。你自己只做那些只有你能做的事：与关键用户做一对一的深度交流，在社区里留下有人味儿的发言，打磨那些需要用你的真实经历和判断力来表达的核心信息。
Launch Day（发布日）：你唯一的工作是“人在场”
发布日那天，你会有一大堆事情想做：盯着Product Hunt排名，在各个社群里发链接，回复每一条评论，监测数据，调整投放策略……
但我想给你一个听起来有点反直觉的建议：在发布日，你唯一的工作是回应。 回应每一条评论，回复每一封邮件，接住每一条反馈。其他的执行工作——数据监测、定时发布、自动回复——全部交给AI和自动化流程。
为什么？因为Launch Day最稀缺的资产不是曝光 量。以AI原生公司通常能在Launch Day获得的关注度，曝光量是足够的。最稀缺的是创始人与早期用户之间建立的真实连接。 那些在发布日愿意花时间给你写反馈的人，是你未来最忠实的用户基础。他们中可能藏着你的第一个付费企业客户、你的第一个行业KOL推荐者、甚至你未来的联合创始人。而你用自动化回复去应付他们，是你能犯的最昂贵的错误。
我记得有一个案例让我印象很深：一个创始人在Product Hunt发布日，亲自回复了超过300条评论，每一条都不是模板化的“谢谢支持”，而是针对评论内容的具体回应。当天他收获了远超同类产品的转化率，更重要的是，那一批早期用户后来成了他产品最狂热的口碑传播者。有人在社交媒体上写：“我从来没见过一个创始人这么认真地在乎用户的反馈。”这种口碑，花多少钱都买不来。
Post-Launch（发布后4周）：从“事件驱动”转向“系统驱动”
这是最容易被忽视，也最危险的阶段。
很多AI原生公司在Launch Day取得了巨大成功，然后迅速衰落。原因是什么？他们把Launch当成了终点。发布日的高潮过去之后，团队疲惫了，关注度下降了，增长曲线开始变得平缓——这时候很容易陷入迷茫：“我们是不是已经过了巅峰？”
我自己的体会是：Launch不是终点，甚至不是增长的高潮，它是你增长系统启动的按钮。
发布后的四周，核心任务只有一个：把“事件驱动的脉冲式增长”，转化为“系统驱动的持续性增长”。具体来说：
用AI分析发布期的用户行为数据，找出高转化用户的特征。哪类用户留下来了？他们做了什么动作？他们从哪个渠道来的？这些信息是你构建可持续获客渠道的核心输入。
建立内容复利系统。发布期的热度是短暂的，但你可以把发布期产出的用户故事、使用案例、媒体报道，转化为持续产生长尾流量的内容资产。用AI帮你把一篇用户访谈变成十篇社交媒体帖子、一篇博客、一个视频脚本。
开始构建社区。不是建个微信群就完了，而是用AI辅助运营：自动欢迎新成员、分类整理常见问题、识别活跃用户并赋予他们社区角色。社区不是用来“管理”的，是用来“赋能”的——赋能你的早期用户，让他们成为你产品的延伸。
特别想对OPC创业者说的： Post-Launch阶段，你会面临一个巨大的诱惑：因为Launch Day的成功，你觉得自己应该趁热打铁，马上开始开发新功能、拓展新渠道、追求更大增长。但我想提醒你的是，Launch阶段最重要的动作不是“加速”，而是“巩固”。把你已经获得的用户服务好，把他们的反馈转化成产品迭代，把那些验证有效的增长动作固化下来。一个OPC最稀缺的不是增长速度，而是可持续性。你跑得再快，如果根基不稳，一个跟头就能把你打回原形。
一些在Launch阶段反复出现的心理状态
写到这里，我想诚实地说说我在Launch阶段经历过的几种心理状态，以及我如何与它们共处。
第一种心理：比较焦虑。 你会不停地看别人的Launch数据——“别人三天就一万用户，我怎么才五百？”这种比较会在深夜把你吞噬。我后来学会了一件事：把对比的对象从“别人”换成“昨天的自己”。别人的数据你看不到全貌——你不知道他们投入了多少资源、他们的启动用户基础如何、他们是否在数据口径上做了美化。唯一诚实的标尺是：我今天比昨天更理解我的用户了吗？
第二种心理：过山车情绪。 Launch期间的情绪波动非常剧烈。一条好评让你觉得世界是你的，一条差评让你觉得一切都完了。我后来给自己定了一个规矩：不要在同一天做任何重大决策。今天收到的所有信息——无论好坏——先记下来，睡一觉，第二天再看。你会发现，那些让你狂喜的东西可能没那么重要，那些让你崩溃的东西可能也没那么严重。
第三种心理：创始人身份焦虑。 Launch之后，你可能会面临一个存在主义式的问题：“我的角色是什么？”当用户服务有AI，内容生成有AI，数据分析有AI，你作为创始人到底在做什么？我的答案是：你在做判断。在所有信息被AI处理好之后，选择往哪个方向走、优先做什么、放弃什么——这些只有你能做。你的角色不是更少了，而是更难了。因为它要求你在信息充足的情况下，依然有勇气做出不可逆的选择。
Launch阶段的工具与心法
工具层面，我不想给你一个长长的清单，因为工具在快速进化。我更想分享的是使用工具的逻辑：
发布平台（如Product Hunt）是你的引爆点，但它不是魔法。发布日的成功取决于你前两周积累的势能，而不是发布日当天做了什么操作。
用户反馈收集工具（如Typeform）帮你有结构地收集用户声音。但工具只是容器，真正重要的是你设计了什么问题。多问开放式问题：“你最失望的一点是什么？”比“你给产品打几分？”有价值一百倍。
自动化工作流工具（如Zapier、Make）是你作为OPC或小团队的AI分身。把一切重复性的操作——欢迎邮件、反馈分类、数据汇总——串联成自动化流程，让你把精力留给只有你能做的事。
AI邮件工具和社交媒体管理工具帮你规模化地做个性化沟通。但记住：个性化的本质不是“在邮件里插入收件人的名字”，而是“你的内容与收件人的真实需求相关”。AI能帮你处理前者，但后者需要你对用户有真正深刻的理解。
我最大的心法其实只有一句话：工具放大你的执行力，但不能替代你的判断力。 在Launch阶段，你最应该用工具做的事是“省下时间”，然后用省下的时间去做工具做不了的事——与用户深度交流，感受市场的真实温度，做出那些没有标准答案的选择。
写在Launch阶段的最后
我最大的感受是：Launch是一门关于“时机”和“人味儿”的艺术。
AI可以帮你准备好一切——物料、流程、数据、自动化。但当发布的那一刻到来时，最打动用户的，依然是那些机器无法伪装的东西：一个创始人对自己产品的真诚信念，一个团队对用户反馈的认真态度，一个品牌在这个嘈杂时代里依然愿意好好说话的耐心。
AI让你的Launch可以更快、更广、更精准。但决定你的Launch是否能从“烟花”变成“篝火”的——烟花炸一下就没了，篝火却能一直烧下去——是你作为创始人，在AI替你处理完所有执行之后，把剩下的时间花在了哪里。
下一篇文章，我会进入最后一个阶段——Scale阶段。当你的产品开始规模化增长，你需要多少人才够？传统的“规模=人数”等式是否还成立？以及，一个AI原生公司如何在小团队的状态下，撑起一个巨大的梦想。
过去十年，我们对“规模化”的理解几乎是一个公式：增长意味着招更多人。你的ARR从100万到1000万，团队从10人涨到100人。这是一种被资本和董事会默认的增长逻辑——融了钱就要花在招人上，人多了就能做更多事，更多事就能带来更多增长。很少有人质疑这个等式，因为它看起来像物理定律一样不可动摇。
但学完这一章，我开始认真地怀疑：在AI 能够承担越来越多执行工作的时代，“规模=人数”这个等式是否还成立？
那些让我重新思考“规模”的案例
我反复研究了几个数据点，每一个都让我对“规模化”的旧定义产生更深的怀疑。
有一家AI原生公司，在只有12名员工的情况下达到了3000万美元的ARR。按照传统SaaS的基准，这个营收级别通常需要80到120人的团队。另一家公司，40多人做到了18亿美金估值。还有一个更极端的例子：一家AI客服公司，创始人和AI Agent 一起支撑起了前100个付费客户，在达到500万美元ARR之前，没有雇佣任何一个客服人员。
这些数字背后有一个共同的逻辑，我花了很长时间才真正理解：AI不是在增强人，而是在取代某些人力的需求。 传统的规模化需要线性增加人头，因为每个客户经理只能服务一定数量的客户，每个工程师只能写一定量的代码。但当AI能够自主承担客户服务的大部分工作、能够独立完成大量编码任务时，“每单位营收所需的人力”这个指标被彻底改写了。
我意识到，这些公司不是在“用更少的人做更多的事”——他们在重新定义“做事”本身。不是把原来的工作分给更少的人，而是重新设计了工作的完成方式，让其中相当一部分压根不需要人来做了。
什么时候招人，什么时候用AI？
这是整个Scale章节里对我最有实操价值的部分。它迫使我建立了一套自己的判断框架。
我倾向于用AI的场景： 任务高度重复、规则明确、不需要创造性判断、规模越大越适合自动化。一线客服、基础数据分析 、标准化报告的生成、代码测试、文档撰写——这些我越来越放心交给AI。
我倾向于招人的场景： 任务需要复杂判断、需要跨领域整合信息、需要建立深度信任关系、需要做出不可逆的战略决策。产品战略、关键客户关系、公司文化塑造、危机处理——这些我坚信必须由人来做。
但这套框架有一个我差点踩进去的陷阱。有一段时间，我看到AI能自动化很多东西，就本能地想：“既然能自动化，那就赶紧自动化吧。”但我后来发现，在你尚未理解一个任务之前就试图用AI自动化它，是极其危险的。 我自己首先应该亲自做某件事，理解它的本质、难点和微妙之处，然后再决定是自动化还是招人。跳过“亲自理解”这一步，直接跳到“AI自动化”，往往会构建出一个看起来很高效但实际上一塌糊涂的系统——因为你根本不知道它应该在什么地方出错，应该在什么地方停下来等人来判断。
组织设计：从“管人”到“设计系统”
如果我接受“少人高产出”是AI原生公司的目标，那么组织设计就需要遵循完全不同的原则。我梳理出了三条自己认为最重要的：
第一，围绕工作流组织团队，而不是围绕职能。 传统公司有市场部、销售部、产品部、工程部，每个部门是一堵墙。AI原生公司更倾向于围绕“用户获取”、“用户留存”、“产品迭代”等工作流来组织小型的、跨职能的团队。每个团队都像一个微型公司，拥有完成该工作流所需的所有资源和权限。我越来越觉得，职能墙是规模化的大敌——它制造了信息孤岛，让“做决策的人”和“有信息的人”变成了两拨人。
第二，信息透明是“少人高效”的前提。 当团队很小的时候，信息不对称的代价极高。我发现，AI原生公司应该建立极致的透明文化——每个人都能看到公司的核心指标、财务状况、客户反馈。这不仅减少了对中层管理者的需求，也让每个人都能基于完整信息做出更好的决策。在一个信息透明的组织里，“汇报”这件事变得多余，因为该知道的人已经知道了。
第三，雇佣“T型人才”，但我更看重“T”的横杠。 在小团队中，每个人都需要在多个领域有一定能力，同时在某个领域有深度专长。我特别看重那些“深度理解业务”而不仅仅是“深度掌握技能”的人——因为技能越来越容易被AI替代，而对业务的理解和判断力是AI无法替代的。一个人能不能同时思考产品逻辑和用户心理？能不能在讨论技术方案的时候，始终不忘记商业目标？这种横向的穿透力，在AI原生公司里比纵向的专业深度更稀缺。
Scale阶段我感到的心理挑战
我想花一些篇幅，诚实地聊聊我在Scale阶段面临的心理状态。这些事很少有人公开讨论，但我认为它们极其重要。
当公司进入规模化阶段，我面临的心理挑战和传统创始人很不一样。传统创始人的焦虑通常是“团队不够大”、“钱不够用”、“增长不够快”。但我的焦虑更隐蔽，也更让人不安：“我正在变得多余吗？” 当用户服务有AI，内容生成有AI，数据分析有AI，运营流程有AI，我到底在做什么？这个公司还需要我吗？
这个问题困扰了我相当长一段时间。后来我慢慢找到了一个答案，它帮助我重新定位了自己的角色：在AI原生公司的Scale阶段，创始人的核心价值从“做事”彻底转向“做判断”。 我不再因为我能写代码、能谈客户、能管团队而有价值——这些事AI和团队都能做，而且可能做得比我好。我的价值在于我能看到全局、能在不确定中做出高质量决策、能塑造文化、能吸引和留住那些同样优秀的T型人才。
我想到一个比喻：传统创始人像船长，亲自掌舵，手不能离开方向盘。AI原生创始人更像舰队指挥官——设定方向，赋予他人权力，在关键时刻出手。你不是在控制每一艘船，你是在确保整个舰队知道要去哪里，并且彼此之间保持正确的距离和速度。
这个转变是痛苦的，因为它要求我放下那些让我感到安全的技能标签。但它也是解放的，因为它让我第一次可以把注意力从“怎么把事做好”转向“应该做什么事”。
对OPC创业者的心里话
如果你是选择以OPC模式进入Scale阶段，我有几句特别想跟你说的话。
选择能“以AI为核心护城河”的商业模式。 如果你的规模化依赖大量的人与人之间的信任关系——比如高端咨询，OPC模式会碰到天花板。但如果你的规模化依赖的是数据和算法的积累——比如AI驱动的SaaS工具，OPC可以走得很远。我从一开始就在问自己这个问题：我的护城河是不是随着数据积累而加深？如果是，那我一个人加AI就是一支军队。如果不是，那我在规模化阶段迟早要面临一个艰难的选择。
在合适的时机引入“最小必要团队”。 OPC不意味着永远一个人。我越来越清楚，当某些工作需要人类判断力、而这些工作又占用了你太多时间时，就应该招人。但我招人的标准极其严苛——只招那些能显著放大我能力的人，而不是来分担我任务的人。放大器和分担者的区别在于：放大器的加入，让你能做的事发生质变，而不是量的增加。
保持组织的“AI密度”。 这是我给自己定的一个概念：AI密度等于AI处理的工作量除以总工作量。我刻意在规模化过程中维持高AI密度，而不是随着规模增长逐渐滑向传统组织模式。每当我考虑招一个人，我都会先问自己：这个任务是不是只能由人来做？有没有可能用AI完成它，或者用AI完成其中的大部分？这不是为了省钱，而是为了保持组织的轻盈和灵活性。一个AI密度高的组织，可以快速调整方向而不被“人员冗余”拖累；一个AI密度低的组织，每调整一次方向都像给一艘巨轮调头。
工具、方法与思维
Scale阶段涉及的工具不再像MVP和Launch阶段那样具体——到了这个阶段，你用什么样的AI工具取决于你的业务形态和技术栈，没有一套通用的推荐清单。
但我想分享一个比工具更重要的思维转变：从“我做事”到“我确保事情被完成”。
在Scale阶段，我不再是那个亲自下场解决问题的人。我的工作是建立系统——包括AI系统和人类系统——让事情在没有我直接参与的情况下也能被高质量地完成。这需要我同时思考两件事：哪些环节可以用AI自动化，哪些环节需要人类的判断力介入，以及两者之间如何衔接。
具体到工具选择上，我现在更看重“可组合性”——不同的AI工具能不能串联成一个工作流，而不是各自为战。Zapier和Make这类自动化平台在这个阶段变得极其重要，它们是我把各种AI能力编织成一个系统的线。
写在Scale阶段的最后：一个完整的循环
到这里，我从Idea 、MVP、Launch到Scale，走完了一个完整的创业旅程。
回顾这整个过程，如果只能留下一个核心思想，我会选择这个：AI原生创业的本质，不是用AI提高效率，而是用AI重新定义“什么是可能的”。 从一个人用一个周末构建一个产品，到一个小团队在一个季度内达到传统公司需要数年才能企及的规模——这些不是因为AI让事情变快了，而是因为AI让一种全新的做事方式成为可能。
我越来越相信，未来的创业故事，不会讲述一个创始人如何组建了多么庞大的团队，而会讲述一个创始人如何在极少资源的条件下，用判断力和AI杠杆，撬动了多么巨大的影响力。
这可能是我们这个时代对创业者发出的最激动人心的邀请。
浙公网安备 33010602011771号