AI Native 创业（二）：公司已有数据，才是第一性资产

先别急着让 AI 写代码

这是 AI Native 创业系列里最容易被低估的一篇。它不对应单一创业阶段，而是抽出一条贯穿全系列的主线：AI 创业公司的核心资产，是能把已有公司数据转成可复用上下文。

AI-native startup 这个词很容易被误解成“用 AI 写代码的创业公司”。这当然是其中一部分，而且是最显眼的一部分：一个创始人现在可以靠 agentic coding 做出过去需要一支工程团队才能做出的原型。

但如果只看到这层，反而会错过更重要的变化。

AI 原生公司的第一性资产，不是代码，也不是 prompt，而是公司已有数据被整理成了可用上下文。客户怎么描述问题，竞品哪里被骂得最多，销售为什么丢单，用户在哪一步流失，支持工单反复出现什么边界情况，创始人脑子里那些行业判断和例外经验，能不能被系统读到、复用、更新。

这些东西过去散落在通话记录、Slack、CRM、客服系统、文档、表格和人的脑子里。AI 真正改变公司的地方，是它让这些碎片有机会变成一层持续运转的判断系统。

如果没有这层上下文，AI 只是一个很快的外包执行者。它可以写很多代码、生成很多文档、跑很多流程，但它不知道公司真正学到了什么。速度会变快，方向却未必更准。

原文里被低估的一条线

Anthropic 的 The Founder’s Playbook 表面上按创业阶段展开：Idea、MVP、Launch、Scale。它讲每个阶段的目标、退出标准、常见陷阱，以及 Claude、Claude Code、Claude Cowork 可以怎么帮忙。

但中间还有一条更值得单独拎出来的暗线：AI 如何处理公司已经拥有的数据。

在 Idea 阶段，它提到把客户通话记录整理成主题发现文档，把竞品评论和公开用户反馈综合起来，找出用户对现有方案的反复抱怨；也提到从行业报告、分析师文件和市场研究文档里抽取信息，建立 TAM/SAM/SOM 和趋势判断。

在 MVP 阶段，它强调不要等发布后才开始看数据，而要提前定义 retention、activation、Day 7、Day 30，以及什么样的早期热度只是 false positive。真实用户反馈、bug reports、留存数据和转介绍，才是判断 product-market fit 的证据。

到了 Launch 和 Scale，它讲的是另一类数据：CRM、支持工单、销售管线、产品指标、weekly metrics、customer success reporting、用户交互数据、工作流集成深度。这些不是用来写一份漂亮报告的，而是用来把公司从 founder 手动运转，变成系统自动运转。

这条线比“某个 AI 工具能做什么”更关键。因为工具会变，但公司能不能把数据变成上下文，是结构性能力。

数据不是上下文

很多公司说自己有数据，其实只是有库存。

一堆录音不是客户洞察。一堆 CRM 字段不是销售系统。一堆工单不是产品反馈。一堆 dashboard 也不等于公司真的理解自己。

数据变成上下文，至少要经过四层处理。

第一层是事实层：发生了什么。比如某个客户在第 3 次试用后流失，某个 sales call 里对方反复问安全合规，某个竞品在 G2 上被抱怨 onboarding 太重。

第二层是信号层：这些事实说明了什么。比如流失不是因为价格，而是 activation 没过；安全合规不是企业销售后期问题，而是进入采购流程前的门槛；竞品被骂的不是功能少，而是用户无法把它嵌入现有工作流。

第三层是判断层：我们应该如何改变决策。比如 MVP 先补 onboarding，不急着加新功能；Launch 前先补安全文档和审计日志；下一轮客户访谈要验证 buyer 和 user 是否是同一个人。

第四层是执行层：这些判断如何进入工作流。比如自动生成每周 PMF 证据板，自动从支持工单里提取前 5 个产品摩擦点，自动在销售 pipeline 里标记合规阻塞，自动把高频边界案例变成测试场景。

AI 真正有用的地方，不是把第一层事实总结得更漂亮，而是帮公司更快走完这四层。

Idea 阶段：整理外部数据和访谈数据

早期创业最容易犯的错，是把“我能做出来”误认为“这件事值得做”。AI 把构建成本降得太低，反而让这个错误更常见。

所以 Idea 阶段最重要的数据整理，不是产品数据，而是问题证据。

你应该整理三类已有数据。

第一类是公开市场数据：行业报告、分析师文章、政策变化、招聘趋势、采购预算变化、社区讨论。它们回答的是：这个问题为什么现在更重要？市场是扩大、收缩，还是只是噪声变多？

第二类是竞品和替代方案数据：竞品评论、论坛抱怨、用户迁移故事、失败产品复盘、现有工具的 workaround。它们回答的是：用户今天已经怎么解决这个问题？他们对当前方案到底哪里不满意？

第三类是访谈数据：客户通话记录、访谈笔记、邮件回复、LinkedIn 私信、销售前期聊天。它们回答的是：真实用户用什么语言描述痛苦？他们过去一次遇到这个问题时做了什么？他们是否已经为这个问题付出时间、预算或组织成本？

这里最重要的 artifact 不是 pitch deck，而是 Problem Evidence Ledger：一张问题证据账本。

它至少包含五列：证据来源、用户原话、支持的假设、挑战的假设、下一步验证动作。

这样做的好处是，AI 不再只是帮你写“这个市场很大”的论证，而是持续逼你看见反证。如果每一条数据都只能支持你的想法，从来不挑战你的想法，通常不是想法太好，而是数据整理方式已经偏了。

MVP 阶段：整理使用数据和反馈数据

MVP 阶段看起来是在造产品，其实仍然是在收集证据。不同的是，Idea 阶段验证问题是否存在，MVP 阶段验证你的解决方案是否真的产生持续价值。

这里的数据整理要避免一个陷阱：只整理让自己高兴的数据。

注册数、访问量、转发、朋友夸奖、一次 Hacker News 或朋友圈带来的峰值，都可能让人误判。AI 让 landing page、demo、内容发布和冷启动更容易，所以早期热闹比过去更不可靠。

真正要整理的是四类信号。

第一，activation：用户是否完成了产品承诺中最核心的一步。

第二，retention：用户是否在第 7 天、第 30 天、下一次真实任务出现时回来。

第三，willingness to pay：他们是否愿意付费，或者至少愿意付出迁移、配置、邀请同事的成本。

第四，qualitative feedback：用户说“挺好”和用户把它嵌进工作流，是两回事。

MVP 阶段最重要的 artifact 是 PMF Evidence Board。它不应该只展示增长曲线，而应该同时展示支持证据和反对证据。

比如：

• 支持证据：某类用户 30 天后仍然每周使用 3 次。
• 反对证据：另一类用户注册后没有完成核心动作。
• 支持证据：用户主动问能否邀请团队。
• 反对证据：付费意愿集中在定制服务，而不是产品订阅。

AI 可以帮你每周整理用户反馈、工单、产品日志和访谈纪要，但创始人必须保留判断权。因为“用户想要一个新功能”这句话太粗糙了，它可能代表核心需求、边缘需求、定位问题、onboarding 问题，也可能只是一个礼貌建议。

Launch 阶段：整理运营数据，替代创始人的人工汇总

Launch 阶段的变化，是产品开始变成公司。

在 Idea 和 MVP 阶段，创始人亲自待在每个循环里是优势。你离用户近，理解细节，能快速判断。但是进入 Launch 后，同样的习惯会变成瓶颈：支持请求等你回答，bug triage 等你判断，销售问题等你解释，周报等你手动整理。

这时候，数据整理的目标不再只是“知道发生了什么”，而是让公司不靠创始人记得，也能持续运行。

你要整理的不是一张更漂亮的 dashboard，而是一套 Weekly Operating Brief。

它应该每周自动回答这些问题：

• 产品：本周用户在哪里卡住？哪些 bug 或体验问题影响了 activation 和 retention？
• 销售：pipeline 里最大的阻塞是什么？丢单理由是否集中在价格、合规、集成、信任或 ROI？
• 支持：哪些问题重复出现？哪些应该变成文档、产品改动或自动化流程？
• 工程：哪些技术债开始影响交付？测试覆盖、性能、安全有没有明显风险？
• 公司：哪些决策仍然必须经过创始人？哪些流程一旦创始人离线一周就会停摆？

这份 brief 的价值不在于汇报，而在于路由。它应该把信号推到正确的工作流：产品问题进 backlog，合规问题进 remediation queue，支持高频问题进文档和自动回复，销售阻塞进入 messaging 或 enablement。

当 AI 能持续读这些数据，公司才开始从“创始人靠脑子串起来”变成“系统靠上下文跑起来”。

Scale 阶段：整理专有数据，形成护城河

到了 Scale，问题不再是能不能做出产品，而是别人复制你之后，用户为什么还留下。

很多 AI 产品误以为护城河是模型能力。但模型会扩散，基础能力会商品化。真正难复制的是三种东西。

第一，行业知识。创始人和团队知道哪些边界情况，哪些监管细节，哪些“看起来合理但实际行不通”的方案。这些知识如果只在人的脑子里，就不是公司资产。它必须被整理成文档、测试场景、工作流规则、产品逻辑和模型上下文。

第二，用户行为数据。用户接受哪些输出，拒绝哪些输出，在哪一步修改，在哪个场景重复使用，哪些工作流慢慢变成默认路径。这些数据的价值不在于存下来，而在于进入反馈循环，让产品下一次更懂用户。

第三，工作流嵌入。客户把你的产品接进哪些系统，基于它建立了哪些自动化，哪些团队流程依赖它，切换成本在哪里。这个东西如果不整理，你只知道客户还在付费，却不知道他们为什么离不开你。

Scale 阶段最重要的 artifact 是 Moat and Workflow Map。

它应该回答：

• 我们有哪些行业边界案例，是通用竞品容易做错的？
• 哪些用户行为数据已经反过来改善了产品？
• 哪些集成让客户把我们放进日常流程，而不是偶尔使用？
• 如果一个资金更多的竞争对手今天复制功能，哪些东西它两年内仍然复制不了？

护城河不是一句“我们有数据”。护城河是数据、工作流、产品改进和客户依赖之间形成了闭环。

一套最小可用的数据到上下文系统

如果把这件事落到实践，我会从一个最小系统开始，而不是先上复杂数据平台。

第一步，做 Company Context Inventory。列出公司已有数据源：客户访谈、销售 CRM、支持工单、产品分析、会议纪要、竞品评论、行业报告、财务和运营报表、代码仓库、产品文档。

第二步，给每个数据源标记用途。它到底服务于哪类决策：找问题、判 PMF、排 roadmap、处理流失、做销售、补合规、改 onboarding、识别护城河。

第三步，为每类决策设计固定输出。不要让 AI 每次自由发挥，而是固定成 evidence ledger、weekly brief、PMF board、risk queue、workflow map 这样的 artifact。

第四步，建立更新节奏。访谈记录可能每 5 次整理一次，产品指标每周整理一次，销售和支持每周整理一次，护城河和工作流依赖每月整理一次。

第五步，把输出接回执行系统。只生成总结没有用。总结必须进入 Linear、Notion、CRM、支持系统、代码任务、销售材料或产品决策会。

这才是 AI-native 公司真正的起点：不是有一个会回答问题的 AI，而是公司每天发生的事会持续变成下一次判断和行动的上下文。

最后

The Founder’s Playbook 说 AI 压缩了创业生命周期。我更愿意把它说得具体一点：AI 压缩的是从数据到判断、从判断到行动、从行动到反馈的循环。

但前提是，你得先把公司已有数据变成它能读、能查、能更新、能执行的上下文。

没有这一步，AI 只是让你更快地生产东西。有了这一步，AI 才可能让公司更快地学习。

本文是 Anthropic The Founder’s Playbook: Building an AI-Native Startup 的中文拆解系列第二篇。

相关阅读

• AI Native 创业，到底重启了什么 —— 这个系列的开篇，先讲创业生命周期被压缩后，创始人的核心瓶颈如何变化。
• AI 时代，创始人从执行者变成编排者 —— 下一篇继续讲创始人角色如何从执行转向系统设计。
• 把公司建成一层智能，而不是一张组织架构图 —— 公司如何围绕一层 intelligence layer 重新组织。
• Agent 长任务的瓶颈，是上下文工程 —— 为什么模型能力之外，真正要工程化的是上下文本身。