AI 时代的创业者:Token 无限,剑境有限

在前一篇《AI 时代，代码从未如此昂贵》里，我写出了一个反直觉的结论。AI 并未让代码变便宜，它只是把”维护坏代码的代价”推高到了前所未有的位置。把这个判断从工程层面搬到创业层面，会得到一个更犀利的版本—AI 并未让创业变得容易，它只是把稀缺从”执行”迁移到了”判断”。

当下关于 AI-native 公司的表述，给我留下很深刻印象的是 Y Combinator 的合伙人 Diana 的一场公开分享。她有过工程团队管理经验，在分享中提到自己观察了旗下多家 YC 公司的实践，并给出一个判断，AI 不应是公司的工具，而应是公司赖以运行的操作系统。与此并存的是另一类常被忽略的事实。Reddit 上一位前创业者花了 47,000 美元和 18 个月，得出”90% AI 创业注定失败”的结论。一边是广受欢迎的成功学，一边是反复重演的失败悲剧。其实，两者谈论的是不同的稀缺。

从第零天就搭起一家 AI-native 公司，真正昂贵的不是算力，也不是 token，而是三样东西：能把混沌业务概括可执行规范的人、能指向真实世界而非内部自洽的反馈信号、以及一位不把判断力外包出去的创始人。AI-native 公司不是效率的升级版本，而是围绕这三个新瓶颈重新组织起来的公司。

稀缺的迁移，而不是稀缺的消失

过去十五年，创业公司围绕三样东西的稀缺组织起来，昂贵的工程师、迟缓的招聘、高企的协调成本。从中层管理、敏捷冲刺、OKR 到周会，现代公司的几乎每一个制度设计，本质上都在解决信息沿着人形管道流动必然产生的损耗。

AI 却把这三样稀缺一起转移走了。一个人写一段规范，让 agent 实现；另一个人把客户通话喂给 notetaker，让 agent 提炼反馈；第三个人用 agent 比对昨天的 sprint 和上周的客户投诉。这不是效率提升，是稀缺点的整体迁移。原来维护在”人负责理解”层面的成本，全部上浮到了”谁来定义要做什么、谁来判断是否做对了”这一层次。

这场迁移是有价签的。以美国市场为例，传统软件公司的人均年营收大约在 20 万到 50 万美元之间，年营收 1000 万美元的公司通常需要 30 到 60 人；AI-native 公司在同样的营收段，每人负责 100 万到 300 万美元，3 到 10 人即可支撑。人数除以五，人均除法分母变成原来的五倍—减掉的那部分成本不是凭空消失，它被挤进了剩下那 3 到 10 个人的日常里，加进来的是判断、规范、提问和验证。今天的创业者中每三位就有一位是独立创业，七年前这一比例为六分之一。数据本身并不惊人，值得追问的是被这套数字倒推出来的那个人应当是谁。

HBS Online 在 2025 年的一篇 AI-first 文章中将这种变化拆为五步，涵盖加固数据基础、识别用例、排序优先级、审慎接入、评估与推广。这份框架自有其价值，但它回答的是大公司”怎么转型”，而非初创”什么会成为新的瓶颈”。一家从零开始搭建的 AI-native 公司不会背负转型包袱，却必须直面三个全新的问题。

第一重瓶颈：specs to company 会像 specs to code 一样塌方

设想一家典型 AI-native 公司的日常。创始人把业务目标写成规范，把 OKR 挂到 dashboard，把所有沟通索引进 agent，之后默认自己无需再审阅具体执行。几轮 sprint 之后，Linear 里的任务按时关单，客户反馈经 agent 汇总后看上去也在持续改善，周报标题光鲜。但若深入细节，产品正在向”客户在访谈中声称自己想要的东西”偏移，销售在同一批低质量线索上反复更换话术，工程团队将大量时间投入到无人真正使用的功能上。这便是 specs to company，与 specs to code 同属一种故障—规范没错，测试通过，产出已然偏离真正要做的事。

Diana 提到的 software factory 是这种叙事在工程层面的极端形态，人类只写规范和测试，agent 生成实现并迭代至测试通过，有些公司的代码仓库已无手写代码。工程层面的反例也早已出现，在前文中引用过Matt Pocock 的实测，specs to code 反复运行后代码质量会逐轮下降。同构的危险在组织层面更为隐蔽，因为公司不存在一个”compile 报错”的瞬间，熵增是慢速累积的，等到财务报表将其暴露，往往已晚了一两个季度。

规范从来不是用来”替代对产出的判断”的。《人月神话》作者 Frederick Brooks 所言的 design concept 正是这个意思：它是两个人合作时共享于脑中、不可见的”这件事物应是什么样”，既非文档，也非示意图，而是意图本身。我经常使用的Superpowers 把这条纪律内置为 brainstorming skill，要求 agent 在动手之前反过来盘问使用者，直至对齐。对抗式追问比再写一份 PRD 更能挤压出 specs to company 中那些被省略的前提。

由此得出的推论朴素。AI-native 公司的招聘标准不再是”谁会写代码”，而是”谁能将脑中混沌的业务直觉概括成几千字可被机器执行、且与所有人对齐的规范”。这类人在过去的分工中被称为产品经理或架构师，但大多数产品经理并不具备书写规范的能力，多数架构师也缺乏面向业务的翻译能力。这一人才缺口，几乎没有公司在系统性地培养。

第二重瓶颈：闭环需要一个外部锚点

闭环系统听上去无懈可击，捕获信号、反馈、自我改进。但闭环有一个致命前提，输入的信号必须指向客观真实。如果信号本身来自公司内部自己生成的内容，比如 agent 写的 sprint 总结、AI notetaker 整理的会议纪要、从内部 dashboard 自动汇总的客户反馈，那么所谓的自我改进，实际上是围绕公司内部的自我叙事进行优化。

这正是 Stanford 教授、精益创业（Lean Startup）方法论奠基人 Steve Blank 坚持十余年的一条旧道理。创业的核心不是撰写商业计划，而是走出办公室与真实客户对话，验证最底层的假设。AI 可以协助拟定问题清单、总结反馈、进行初步的市场调研，但它无法替创始人承受客户对其想法的正面否定。

Blank 对 AI 给出的警告在此值得重读，”AI 的回答里 10% 到 50% 是胡说，问题是你不知道哪一部分”。一家公司越是被改造为闭环系统，就越应在闭环中保留一个不可被 AI 代劳的节点。这个节点通常是少数几件事之一，例如真实客户的付费决定、真实员工的离职对话、真实用户停止使用的动作。三者均无法被内部系统伪造，是少数不会被信号噪音污染的锚点。

一个反例足以说明问题。当创业者将产品迭代的全部反馈来源交由 agent 汇总，他会发现产品正在向”客户在访谈中声称自己想要的东西”而非”客户在真实场景中实际会用的东西”优化。两个方向看似相近，长期走向却截然不同。前者将公司导向精巧但无人使用的 MVP 矩阵，后者才能形成真实的用户粘性。

这里有一个反直觉的结论。AI-native 公司越是把组织改造得可查询、artifact 丰富、对 agent 可读，就越应刻意保留几条低效的、需要创始人亲身在场的反馈通道。这不是怀旧，而是为闭环锚定一个它自身无法生成的真实信号源。

第三重瓶颈：创始人作为战略级架构师

Twitter 联合创始人、金融科技公司 Block（原 Square）CEO Jack Dorsey 在内部推动的组织重构，被 Diana 概括为一句话。若公司本身可查询、artifact 丰富、对 AI 可读，中间便几乎不再需要”人形管道”。与之对应，Diana 提出公司中将只保留三种角色，即个体贡献者（IC）、对结果负责的人（DRI），以及创始人本人。

这套三角色模型有其逻辑上的优雅，也有显而易见的盲点。中层管理长期被低估，他们并非仅是信息路由，还承担着另一些难以自动化的职能，比如吸收下属的情绪震荡，将模糊的上级指令翻译成可执行事项，在冲突中为各方保留体面，在坏消息面前保护下属，在跨职能博弈中充当缓冲器。一个 agent 可以合成 sprint 报告，却无法对一位被否掉方案的工程师说：”这次不是你的问题，我去跟产品团队沟通。”

当中层被移除，这些职能并不会消失，只会上浮。要么落回 IC 身上，迫使他们同时承担执行与组织协调；要么落到创始人的头上，使其成为整个公司唯一的情绪熔炉与判断中枢。token 可以任意扩展，判断力却不能；创始人的认知带宽是一种真实、有限、会被耗竭的资源。

当判断中枢收敛到一个人，这个人的职责便不再是经营，而是架构。创始人每日需要重新回答的四个问题，本质上都是架构问题。对客户承诺什么、商业模式如何成立，这是公司的接口；做什么与明确不做什么，这是公司的边界；产品与用户在我们的抽象中是什么模样，这是公司的领域模型；如何及时发现自己走偏，这是公司的测试策略。无一可以被 agent 代替。极限编程（XP）与测试驱动开发（TDD）的提出者 Kent Beck 那句”每天都要投资于系统设计”，至此才真正落到了公司层面。

Diana 自己对此其实有所意识。她在分享中强调，”你不能外包你对这些工具的信念，你必须亲自花时间与 agent 相处，直到它们打破你关于能建什么的固有预设”。这句话通常被读作一种号召—创始人应懂 AI。更准确的读法是，在一家没有中间层的 AI-native 公司里，创始人的品味、对 agent 的使用深度、对优秀产品的感知阈值，直接决定整个组织的上限。这是单点故障，而且是不可替代的单点故障。

把组织做深，而不是做薄

AI-native 公司存在两种可能的组织形态。第一种是”薄组织”，各项职能被切得极细，每个人、每个 agent 都对外暴露大量接口，彼此互相对接；任何改动都需穿越七八个交接点，每个节点单看尚属合理，整体已无人能看清。第二种是”深组织”，若干条边界清晰、职责厚重的流并排运行，每条流对外只承诺一件事，即”负责什么结果、交付什么产物”，内部则吸收全部复杂度。金庸笔下独孤求败在剑冢刻下”重剑无锋，大巧不工”八字，讲的正是同一种取舍—真正厉害的不是精巧花哨的浅接口，而是重到让你不必再在接口层反复搏斗的深结构。薄组织像浮在水面的一片叶子，深组织像钉入地下的一根桩。

AI 将两种形态间的差距进一步放大。在薄组织中，agent 的改动散布各处，每个节点都需由人逐一验证，创始人被迫审查每一条路径。这不是”用 AI 加速”，而是替自己多开一份 PR review 的兼职。在深组织中，创始人只需在每条流的接口层把关，流内部则可部分授权给 agent。将 agent 作为灰盒使用的前提，是组织本身先做成灰盒。这正是 Stanford 计算机科学家 John Ousterhout 在《软件设计的哲学》中反复强调的取舍，把复杂度藏进去，只暴露一个简单接口。代码适用，组织更甚。

差距亦可被量化。一项流传较广的估算显示，一位将 AI 工具栈搭建得当的 solo 创始人，产出是完全手工方式的 4 至 5 倍。这一乘数的前提是每一层工具之间能相互喂入数据，客户邮件中的 bug 报告经 Claude 摘要后直接进入 Cursor，推送后 Row 自动记账。同一来源中还有一句常被跳过的警告，”AI 运行成本会偷偷涨起来，如果产品没被搭对的话”。放大倍率与失控成本，是同一枚硬币的两面。组织亦是同构。做成深组织，放大生效；做成薄组织，成本失控。中间没有缓冲带。

Diana 建议尽可能减少 DM 与 email，将所有沟通嵌入 agent 可访问的渠道，令每一项重要动作都留下 artifact。这一建议在逻辑上是完美的，实践中却有副作用。当所有对话都会被索引、被回看、被喂入 agent，人的坦率程度会下降。思考所需要的那种未完成、不严谨、试探性的对话，会被挤到若干极小的、未被记录的缝隙中。半成形的判断往往在私下的 DM、午餐闲聊、某人深夜发给自己的 draft 中逐渐成熟。一旦这些缝隙被彻底抹平，组织表面上变得 AI 可读，实际的判断质量却在悄然退化。

一家可查询的公司，不等于一家会思考的公司。artifact 密集度高，不等同于对问题的理解深。借用 Goodhart 的说法：一旦一项指标成为目标，它便不再是好指标。一旦”产出 artifact”成为隐含的绩效要求，员工会学会生产漂亮却空洞的 artifact，agent 会学会从中提炼出同样漂亮却空洞的结论。整条闭环可以很快速、很自洽，也可以彻底失准。

从第零天开始的五条纪律

将规范评审视作一级工作，而非”写完便交给 agent”。规范评审所占的时间不应少于代码评审，凡未经严肃质询的规范，将在下游被 agent 放大为代价高昂的错误。此条是对 specs to company 叙事的直接对冲。
保留一条不可被 AI 代劳的反馈回路。创始人每周至少与三位真实客户直接对话，不经 agent 摘要，不看汇总报告；每月至少查阅一次原始的取消使用日志；每季度至少通读一遍用户在第三方平台上的负面评价原文。这些动作反直觉地低效，却是整条闭环抵御自欺的唯一防线。此条与 Blank “get the heck outside”一句本质相通。
将 artifact 与意义分离。会议记录、sprint 纪要、客户反馈合集之类的 artifact 交由 agent；而关于”我们究竟在做什么、为谁而做、为何值得做”的对话，应以定期、小范围、不被索引的方式进行。这看似返祖，实则是守住判断力的唯一物理载体。
公开承认创始人的判断力即是公司的单点故障。AI-native 公司较任何一种组织形态都更依赖顶端一个人的品味与判断。与其假装这是一种扁平化的奇迹，不如坦然承认并围绕这一点进行设计。创始人使用 agent 的深度决定公司上限；创始人读什么、与谁交谈、亲自接触何种一手信息，决定整条闭环所接入的真实信号质量。
看清”一人十亿美元公司”的算术。OpenAI CEO Sam Altman 关于”一人十亿”的预言被反复传诵，但最常见的论证路径如下。AI-native 软件公司毛利高、人头少，市场给出的估值倍数可达年营收的 20 倍，故一家公司只需做到 5000 万美元 ARR，便可获得 10 亿美元估值。

换言之，”一人十亿”在数学上的完整形态是，一人把业务从零带到百万 ARR 是现实的，百万至数千万 ARR 的路径中必然从 1 人扩展为若干人的团队。但口号中被压缩掉的，是那段最关键的组织演化，及其成立的前提：创始人必须在 1 人阶段就将规范、反馈、深模块三件事做对，否则此后每招一人都是对初始错位的放大。一人阶段成立的另一前提，是背后存在 Stripe、AWS、OpenAI、Shopify、Meta、Google 等将重资产沉入底层的大平台。一人公司并非独立的奇迹，而是高度依赖的寄生。真正值得追问的问题不是”我能否做到一人”，而是”当底层平台变更、涨价或撤出时，我的业务能否在一个月内重新站立”。

创业者的四阶剑道

回到那位花去 47,000 美元、耗时 18 个月最终失败的创业者。他在 Reddit 仅留下一行标题与一个”90% AI 创业注定失败”的结论。这类故事在 2026 年的 AI 创业圈中每日都在重演。失败往往并非 AI 工具不够好，而是创业者用 AI 加速了一个方向错误的选择，将 agent 当成替代判断的捷径，而非放大判断的工具。

金庸在《神雕侠侣》里为独孤求败写过一段剑冢自述。弱冠之年，持凌厉刚猛的利剑与河朔群雄争锋；三十岁前，用紫薇软剑，因误伤义士不祥，乃弃之深谷；四十岁前，恃重剑无锋、大巧不工横行天下；四十岁后，不滞于物，草木竹石皆可为剑，渐进于无剑胜有剑之境。这四阶段，恰好映照一位 AI-native 创业者须经的四重关口。

利剑阶段的创始人事事亲自执剑，代码自己写，会议自己开，客户自己见。这套功夫在前 AI 时代是立身之本，到了 AI 时代却很快变成拖累。单人带宽的绝对上限，就是公司的上限。

软剑阶段是另一种极端。创始人把所有事交给 agent，把业务目标写成规范后便撒手，指望 specs to company 替自己运转公司。紫薇软剑”误伤义士不祥”的教训在这里几乎一字不改地复现，规范没错、测试通过，产出却早已偏离目标，等到财务报表暴露时已晚了一两个季度。软剑必须被”弃之深谷”。

重剑阶段才是真正能支撑规模化的形态。深模块化的组织、被严肃评审过的规范、锚定真实世界的反馈回路，全部压进一个简单接口之下。重剑无锋，大巧不工，不靠每一处的花哨去解决问题，而是靠厚重本身碾过去。

无剑阶段是这条路径的真正终点。当判断力本身足够锋利，草木竹石皆可为剑。agent 是工具，规范是工具，dashboard 是工具，API 也可以是工具。用什么工具不再重要，什么工具都能为我所用。代码不会因 AI 而变便宜，公司亦不会因 agent 而变容易。稀缺只是换了个位置，从擅长执行，变为擅长提问、擅长验证、擅长忍住不自欺。

能走到无剑阶段的创业者，才有资格谈什么AI-native。其余大多数，不过是以更快的速度，尝试撞向同一堵墙的痛感。

2026 年 4 月 28 日

扩展阅读：

AI 时代，代码从未如此昂贵