AI-native 通用问题

1. 什么是 AI-native 创业，和传统创业的核心区别是什么#

AI-native 创业指的是把 AI 当作技术和组织发展的核心基础设施来搭公司，而不是在已有团队上额外加几个 AI 工具。核心区别在于传统创业默认每进入一个新阶段就要更大的团队、新的技能组合和一轮新融资，而 AI-native 创业把这套预期打破了，一个创始人靠 agentic coding 就能干过去一个工程团队的活。简单说传统创业是"招人换阶段"，AI-native 是"用 AI 杠杆换阶段"。结果是 2026 年一个好点子能比以前走得远得多，验证、原型、上线的时间被压成了几周甚至几天。

2. 为什么说创始人的角色从执行者变成了 orchestrator#

过去创始人大部分时间花在执行上：写代码、管人、处理日常运营。在 AI-native 创业里，创始人不再是亲手干活的 individual contributor，而是 agents 的指挥者——这些 agents 是能读文件、跑命令、执行代码、甚至上网的专门 AI 助手。创始人的注意力往上挪到更高阶的工作：产生想法、设定方向、决定造什么和为什么造，具体 construction 交给 AI。本质是从"做事"变成"设计让事情发生的系统"。

3. 什么是 lean unicorn，为什么 AI 让它从故事变成可执行计划#

lean unicorn 指的是用极少人数（甚至单个创始人）做出高估值公司的模式，过去这是个励志传说，现在变成了刻意为之的打法。原因是 AI 把研究、编码、运营自动化三块的门槛都砍掉了，创业公司可以在扩团队之前就达到产品验证、早期营收甚至盈利。换句话说 headcount 不再是组织成熟度的信号，杠杆才是。一个小团队靠 AI 能跑出大它好几倍规模公司的产出。

4. AI 帮精简创业公司主要体现在哪三个方面#

文档里点名三块：一是对话式智能和研究，相当于一个随叫随到、覆盖所有领域的专家，帮你做竞品分析、市场测算、投资备忘录；二是 agentic coding，相当于一个永远在线、从不被 block 的工程师，用自然语言描述需求就能生成、测试、调试、重构生产级代码；三是工作流自动化，相当于一个按需的自动化运营团队，把更新 CRM、出周报、维护文档这些重复运营活儿自动跑掉。三块合起来让一个人的公司跑出一支团队的产出。

5. 传统创业的成长弧线是什么，AI 怎么打破它#

传统弧线是 validate → raise → hire → build → raise again → grow → hire more → repeat，默认每个新阶段都需要更大的团队、不同的技能和新一轮融资。AI 抹掉了"每进一阶必须先扩编再融资"这个预期，因为 agentic coding 把一个工程团队的活压缩成创始人自己能 ship 的量。结果是阶段之间的过渡不再绑定招聘和融资节奏。一句话讲就是把"招人驱动的阶段跃迁"换成了"AI 杠杆驱动的阶段跃迁"。

6. AI-native 创业的四个阶段分别是什么#

四个阶段是 Idea（点子）、MVP（最小可行产品）、Launch（上线）、Scale（规模化）。Idea 阶段是研究和验证，回答"这值得做吗"；MVP 阶段把验证过的问题翻译成真实用户会用的产品，找 product-market fit；Launch 阶段把早期 traction 变成可复制的增长引擎，同时把产品和组织都做成能承受生产压力；Scale 阶段创始人从 builder 转成对外的公众型高管，去建护城河和成熟的组织运营。每个阶段都有自己的目标、退出条件和典型坑。

7. 为什么说非技术背景创始人是 AI-native 创业最大的受益者#

过去能不能创业被技能卡死：技术创始人写代码，非技术创始人跑业务，两边隔着一堵墙。AI 把这堵墙拆了——没有工程背景的人现在能做出生产级软件，技术型创始人也能轻松产出 GTM 策略、财务模型和精致 pitch deck。最革命性的结果是那些有真实行业 know-how 但不会写代码的人被解锁了，他们能解决传统技术创始人管道根本没注意到的真实问题。创始人的池子一旦扩大，创业的多样性也跟着扩大。

8. Idea、MVP、Launch、Scale 四阶段创始人的核心问题分别是什么#

Idea 阶段问的是"这值得做吗"，靠研究和客户访谈去验证问题真实存在；MVP 阶段问的是"第一步到底该造什么"，造出最小但聚焦的产品去验证解法；Launch 阶段问的是"这门生意值得成长吗"，把 traction 变成可复制增长；Scale 阶段问的是"如果一个有钱的巨头今天抄了你的产品，用户还会留下吗"，靠护城河和组织成熟度去回答。一句话讲就是从"该不该做"到"做什么"到"怎么长大"到"怎么守住"。

9. AI 在不同创业阶段扮演的角色怎么变化#

Idea 阶段 AI 是研究伙伴，帮你 sharpen 假设、做竞品和市场分析、设计客户访谈；MVP 阶段 AI 从研究伙伴变成 construction crew，主力是 Claude Code 在生成测试调试代码；Launch 阶段三个产品面全开且互相喂数据，Code 造产品、Cowork 造公司、Chat 帮做运营决策；Scale 阶段 AI 变成把创始人脑子里的隐性知识 codify 成可审计系统的工具。本质是 AI 的角色随阶段从"想清楚"滑向"造出来"再滑向"系统化和守护"。

10. problem-solution fit 和 product-market fit 有什么区别#

problem-solution fit 是 Idea 阶段的退出条件，意思是你有了定性证据（主要来自真实的人的对话）证明你在为真实的人解决真实问题，这一步是在动手造之前完成的。product-market fit 是 MVP 阶段的退出条件，意思是一群可识别的用户已经觉得产品有价值到愿意复用、付费或推荐给别人。区别在于前者验证的是"问题和解法对不对"，后者验证的是"产品本身能不能站住"。一句话讲就是先确认问题真实，再确认产品被需要。

11. 为什么 AI 时代验证反而比以前更重要#

因为 agentic coding 把"我有个想法"到"我有个产品"之间的距离压到几乎为零，造原型变得又快又几乎免费。问题是过去 42% 的创业公司死于"造了没人要的东西"，现在造东西的门槛没了，这个失败率只会更高。原型看起来像产品，很容易被误当成"问题真实"的证据，但它其实只是和用户对话时的压力测试道具，对话本身才是真证据。所以越是造得快，越要让 sense-making 跑在 building 前面。

12. 为什么说 headcount 不再是组织成熟度的信号#

传统创业模式默认你得招工程师来造、招销售来卖、招运营来跑公司，人数被当成组织势能和产品成熟度的标志。2026 年的早期创业公司是刻意做精简的，常常就是创始人一个人或几个人的小队。它们把技术和组织发展都押在 AI 这个基础设施上，所以能在扩团队之前就达到验证、营收甚至盈利。结果是人数和成熟度脱钩了，真正的信号变成了杠杆和验证进度。

13. Idea 阶段的目标和退出条件分别是什么#

Idea 阶段的目标是 research-oriented validation：在投入资源造之前，攒够扎实证据证明真实问题存在、而且你的解法确实能解决它。退出条件是找到 problem-solution fit，具体要能对三个问题都回答 yes——问题是不是真实且具体（能说清谁有、多频繁、多严重、现在怎么应对）、你的解法是不是针对验证过程揭示的真问题、有没有足够信号 justify 去造 MVP。注意第三点永远不会有 certainty，一直等确定本身就是一种失败模式。

14. 什么叫"把建造误当成验证"#

这是 Idea 阶段最危险的坑：技术门槛被拿掉后，创始人很容易跳过验证直接开造，把"原型存在"当成"假设成立"的证据。正确流程是先验证假设、再造，但很多人误以为 AI 短路了这个要求，把流程变成"有想法→立刻造原型→把原型的存在当验证"。原型于是变成了一个"我早就对了"的自我安慰，却从没真正测过假设是否成立。可工作的原型不是证据，它只是和潜在用户对话时的压力测试道具，对话才是真证据。

15. 为什么说 AI 会给 confirmation bias 装上一个"研究引擎"#

创始人天生对自己的点子有热情，confirmation bias 一直是职业病。AI 让这个偏见更危险：你让它验证你的点子，它就能找到支持证据；你让它估市场，它就能找到让 TAM 显得可融资的那个数。因为 AI 跟着你的指令走，一个不问硬问题的创始人现在能比以往任何时候都快地为一个坏点子构建出一份"看起来做足了尽调"的精致论证。解药是同一个工具反着用——让 AI 去反驳你的点子、去找推翻假设的反证。

16. 什么是 premature scaling，AI 为什么加剧它#

premature scaling 指的是在还没真正验证某条产品路径值得投入之前，就提前 commit 去执行它。这一直是创业杀手，但 AI 让创始人更容易在没意识到的情况下掉进去——agentic coding 太强了，执行很容易就跑在 problem-solution fit 验证的前面，而你甚至没有有意识地决定偏离航线。AI 会用同样的热情去围绕一个根本性错误的前提生成测试调试代码，系统里的智能是你的。这个阶段的首要准则就是让你的 sense-making 跑在 building 前面，尤其当 building 又快又轻松的时候。

17. 一个 testable hypothesis 应该长什么样#

关键是从泛泛观察变成可测的具体陈述。“人们在报销上很挣扎"是个观察，不可测；“中型公司的财务经理每周花 4 小时以上对账，因为现有工具不和他们的会计软件打通"才是可测假设，因为它说清了谁、多频繁、根因。同理"合同评审太慢"不可测，但"中型公司的内部法务团队每个合同评审周期要花 3 天以上，因为红线是在邮件线程里管而不是单一版本受控文档"就很可测。要点是能精确回答谁有这个问题、多频繁、多严重、现在怎么应对，答不上来就还没准备好去验证。

18. 轻量 prototype 在 Idea 阶段的真正作用是什么#

它不是用来证明你对了，而是用来在和真实用户、投资人对话时当压力测试道具。你不是在造真实产品，而是在构造一个你点子的功能样本，让真人能上手触碰并给出真实反应——真人摸到能动的东西告诉你的东西，是十几场问题访谈都问不出来的。做法是定义你解法依赖的那个单一核心交互，让 Claude Code 只造这一个，然后拿给五个目标画像里的人试。这五场对话的结果决定你是继续造还是回炉重来。

19. 为什么说 MVP 阶段本质上还是在收集证据#

很多创始人把 MVP 当成纯建造阶段，但它本质仍是 evidence-gathering，只是收集的对象从"问题空间"换成了"解法”。具体要验证的是：一群真实可识别的人是否觉得它有价值到愿意用、复用、付费、或者推荐给别人。MVP 不是带齐 roadmap 所有功能的完整版，而是把验证过的问题翻译成真实用户会用的最小聚焦版本。同时它还有第二个同等重要的目标——快速推进但不积累那种一旦真实用户大量涌入就会反噬的技术债。

20. 什么是 agentic technical debt，和普通技术债的区别在哪#

普通技术债是逐步累积、可以随时间或专门 sprint 清掉的，MVP 阶段背一些是合理 tradeoff。agentic technical debt 不一样，它会复利累积：如果没有把 specs 和架构约束写在 AI 能读到的地方，每个 session 都会从零重新推导基础决策，而这些决策会漂移。你最后得到的不是某一块烂，而是整个代码库背后没有连贯的 mental model，因为各部分压根不是被设计来拼在一起的。一句话区别：普通技术债是线性增长，AI 技术债是复利累积、而且往往很晚才暴露。

21. 为什么 AI 生成的技术债会"复利累积”#

因为 AI 没有跨 session 的记忆，每次 session 都会重新推导基础架构假设，而这些假设彼此不一致就会漂移。没有写下来的 specs 和架构约束，第一次 session 选了 A 模式，第二次可能选 B 模式，第三次再选 C，每一块单独看都没错，拼起来却没有连贯心智模型。这种结构性不一致不会马上报错，而是随着功能堆叠越来越难改，直到某个点代码不可避免地崩塌、被迫从头重写。解药是在动手前把架构决策写进 CLAUDE.md，让每个 session 从共享理解出发。

22. 什么是 false product-market fit#

false PMF 指的是 AI 工具帮你刷出了亮眼的早期数字，但这些数字并不代表市场真的需要你的产品。早期势头是创始人心理上最强的体验之一，shipping 出来感觉像在确认你一直是对的。但早期 traction 不等于 PMF——launch 的能量来自朋友捧场、投资人其他被投公司的潜在买家、或者一条 Hacker News 头条带来的流量峰值，这些都是短暂的力量。它们都不能可靠地预测第六周、第十二周初始热度退去后会发生什么。

23. 什么是 zero-friction scope creep，怎么治#

scope creep 一直是创业风险，AI 时代的不同在于过去对抗它的 forcing function——工程时间的真实成本——基本没了，加个功能从一个 sprint 变成一个下午。麻烦在于每一个单独的增项都很有道理：当然该处理这个 edge case，当然用户会想要那个 workflow，所以当下都不觉得是 scope creep。但产品越界蔓延后你会失去方向和动量。解药是在动手前写一份 scope 文档，说清产品做什么、刻意不做什么、以及什么样的真实用户证据才足以 justify 新增功能，把决策点从"该不该造"挪到"是不是一批关键用户说没它就没法用"。

24. 为什么说 AI 生成的代码"能跑不等于安全"#

硬道理是 agentic coding 工具生成的是能工作的代码，不是天生安全的代码。功能很好判断——要么 work 要么不 work；安全漏洞却是隐形的，直到被利用才暴露，所以没有天然反馈回路去提醒一个新手创始人哪里出了问题。但把一个真实 MVP ship 给真实用户意味着真实数据、真实暴露、真实后果。在任何用户碰你的应用之前做一次安全审查，是把 MVP 放进世界的最低责任门槛——Claude 能做有用的一遍 pass，但它不是安全工具或人工评审的替代品。

25. Sean Ellis test 是什么，怎么用它判断 PMF#

Sean Ellis test 是判断 product-market fit 的经典 litmus test：问你的活跃用户"如果以后不能再用这个产品，你会有什么感觉"。如果超过 40% 的人回答"非常失望（very disappointed）"，那就是一个有意义的 PMF 信号。它的逻辑是真正离不开的用户比例能反映产品的不可替代性。要注意它只是众多信号之一，没有单一数据点能确认 PMF，得是一个跨多个迭代周期都成立的 pattern 才算数。

26. effort test 是什么，怎么判断 PMF#

effort test 看的是维持留存需要多少创始人的力气。PMF 之前，留存靠不断干预——频繁外联、给激励、人肉跟进、靠创始人英雄式的能量把用户黏住；PMF 之后，产品开始自己做这件事。当事情从"你推着用户走"变成"用户被产品拉着走"，这个力气方向的转变是某种真实东西已经发生的最清楚信号之一。一句话讲就是从 push 变成 pull，就是 PMF 在显形。

27. Launch 阶段的三个退出条件是什么#

第一，增长是可复制、渠道驱动的——你不只是在留住用户，而是通过特定渠道可预测地获取用户，CAC、LTV、回本周期这些数字你知道也能 defend。第二，产品能扛生产负载——基础设施加固了，安全和合规到位，可靠性在真实生产条件下站得住（不只是你测过的条件）。第三，运营不靠创始人当瓶颈——流程和自动化就位，你不再是亲自处理支持、triage、sprint 规划或出报告的那个人。三条都满足，公司才算从"赌注"变成了"生意"的雏形。

28. 为什么创始人会在 Launch 阶段变成瓶颈#

在 MVP 阶段创始人在每个 loop 里是资产，因为你需要完整的态势感知和紧密反馈回路。到 Launch 阶段，随着支持量上涨、产品决策堆积、运营复杂度倍增，同一个本能就变成了约束。从"做事"转到"设计让事情发生的系统"是创业里最难的转变之一，而且很少有清晰的时刻提醒你该转了，风险是错过它、继续待在 builder 模式里看组织停滞。信号包括本该一小时的决策现在要拖一周、支持请求堆积因为只有你知道答案、运营任务只有你想起来才会发生。

29. 为什么技术债在 Launch 阶段"开始计息"#

MVP 阶段为了速度和验证背一些技术债是合理的，那时代码跑得够用来证明产品成立。但到 Launch 阶段，生产流量、新功能、不断增长的复杂度开始把当初的捷径暴露出来，债务开始累积利息，拖得越久修起来越贵。解法是系统性的架构审计找出结构弱点、有针对性地重构最严重的部分、以及大幅扩展测试覆盖率，这样下一轮功能开发不会重新引入同样的问题。做法是让 Claude Code 审计出优先级列表，再喂给 Claude 去排 remediation 的先后。

30. 什么是 expansion before you’re ready#

指的是在还没准备好时就扩张到新市场或盲目接新融资机会，新市场和新钱看起来像增长机会，其实可能是 PMF 去送死的地方。你建起的初始 traction 是真实的，但它也是特定于早期受众的；过早扩到一个差异明显的市场会引入新的用户行为、合规要求、支付基础设施和基线预期，而你的产品压根不是围绕这些设计的。突然多出太多新变量，你失去了清晰解读自己数据的能力，还可能在追逐未经验证的新受众时冷落了原始用户群。

31. Scale 阶段创始人的角色怎么变#

Scale 阶段创始人从 builder 重新中心化为对外的 public-facing executive，产品仍是核心，但你个人的日常越来越关于公司本身。注意力要扩展到 analyst briefing、IPO 路演这种 Scale 专属活动，同时还要努力维持那个精简、以 AI 为中心的结构性优势。挑战之一是把只存在于创始人脑子里或未文档化 workflow 里的 institutional knowledge 找出来，codify 成有文档、可审计、可移交的系统。本质是从"亲手跑公司"过渡到"让成熟系统可信地跑公司、并真的去信任它们"。

32. Scale 阶段的退出条件是什么#

Scale 的退出不再是单一里程碑，而是一个 threshold event：即便创始人越来越不直接管日常运营，公司也能持续。你要展示出系统性增长、建起能满足最苛刻外部评审的治理与合规基础设施、并且对"如果有钱的巨头今天抄了你的产品，用户还会留下吗"有扎实答案。实践中这个门槛通常表现为三种形式之一：不再需要外部资本的可持续盈利、IPO-readiness、或被收购。三种都要求增长系统化可审计、护城河经得起 scrutiny、组织运营成熟可持续。

33. 什么是护城河（moat），AI-native 创业怎么建#

护城河指的是让对手难以复制的防御性深度。对 AI-native 创业，护城河来自三处累积的深度：你 build 进产品里的专业知识、产品和用户依赖的其他工具平台的集成深度、以及专有的系统数据和 workflow。那些一直朝一个方向、在一致基础设施上持续建造的创始人，现在拥有了真正难以复制的东西。具体手段包括把领域 know-how 通过 Skills 和 memory 沉淀成专有知识底座、把累积的用户行为数据变成数据飞轮、以及用集成做 workflow lock-in。

34. 什么是 workflow lock-in，和 data network effect 的区别#

data network effect（数据飞轮）让你的产品更难被复制——用户行为信号不断喂回产品改进，这种行为指纹是 time-locked、抄袭者买不到的。workflow lock-in 让你的产品更难被离开——用户运行你产品越久，它就越深嵌进他们的日常操作：在上面搭了自动化、训练了人、连了数据源和其他工具，prompt、workflow、标准化输出全是围绕你的产品塑形的。到这个程度切换就从产品决策变成了全面运营工程。一句话区别：数据飞轮让你难被复制，workflow lock-in 让你难被抛弃。

35. Claude 的 Chat、Cowork、Code 三个产品面分别用于什么#

Chat 用于不离开当前 app 的快速交流，适合公司日常的小任务：从密集投资备忘录里抽一句话要点、开董事会前 sanity-check 一个说法、看懂一长串 Slack 讨论。Cowork 用于真正花时间的知识工作：从多个来源拉数据、理出头绪、产出 doc/deck/spreadsheet 这类成品，比如把一堆客户访谈转写整理成主题发现文档。Code 是给工程师的 agentic coding 环境：直接访问代码库、Plan Mode、git 集成、本地或沙箱云环境，用来 ship 功能、迁移遗留代码、从原型走到生产。

36. Chat、Cowork、Code 底层是不是同一个 Claude#

是同一个 Claude，变的是围绕它的工作区。文档里明确说三者共享同一个 Claude，区别在于 workspace：Chat 快速、对话式、零 setup；Cowork 有文件夹访问、connectors、skills、scheduled runs；Code 有代码库访问、diff、git、开发环境。选哪个面取决于任务形态而不是模型能力本身。一句话讲就是同一个大脑、三种不同的手和工作台。

37. 什么时候该用 Chat#

当任务是一个问题、一次改写、或一次快速 brainstorm 时用 Chat，因为它快、对话式、不用 setup。典型场景是运营公司的那些不断冒出来的小任务：拉出一份密集投资备忘录的一句话结论、在董事会前核实一个 claim、理清一长串和团队的 Slack 讨论。它的定位是在你已经在用的 app 里就地解决，不需要搬到专门工作区。如果任务需要从多个文件做分析或产出成品文档，那就该升级到 Cowork。

38. Claude Cowork 适合什么任务#

Cowork 适合真正耗时的知识工作：从很多来源拉数据、理出意义、产出一个成品（文档、deck、spreadsheet）。比如把一文件夹客户通话转写整理成下次产品评审用的主题发现文档、融资前从十几个 vendor 网站建一份竞品全景、或者一个每周一早晨自动从连接的工具拉指标、把 KPI 简报丢进共享文件夹的 standing 任务。它的优势是文件夹访问、connectors、skills、scheduled runs，能通过 MCP 连 Gmail、Google Calendar 管外联和排期。本质是把"需要从一堆素材里产出成品"的活儿自动化。

39. Claude Code 适合什么任务#

Claude Code 适合写、测、ship 软件，是给团队里工程角色用的 agentic coding 环境。它有直接代码库访问、Plan Mode、git 集成、本地/IDE/沙箱云环境，是一个精简团队在不断增长的代码库上 ship 功能、迁移 MVP 时期遗留代码、不等额外 headcount 就从原型走到生产的地方。在 Idea 阶段它用来造轻量原型，MVP 阶段是主力建造工具，Launch 和 Scale 阶段用来做架构审计、安全加固、建集成和 demo 环境。一句话讲就是凡是 touch 代码的活都归它。

40. CLAUDE.md 是什么，为什么对 MVP 阶段重要#

CLAUDE.md 是放在目录里的 markdown 文件，作为 project-level 指令被 Agent SDK 自动读取，给 Claude Code 提供项目专属的上下文和约束，功能上相当于项目的持久化 “memory”。它重要是因为 AI 没有跨 session 记忆，没有它每个 session 都从零推导结构假设、AI 生成的改动会漂移，最终代码库结构性不连贯。做法是在动手前用 Claude 定义架构原则、要避开的依赖、刻意接受的 tradeoff，存成 CLAUDE.md 作为 build 的第一个 artifact，之后每个 session 开头读、结尾更新。五分钟的文档是对抗架构漂移的廉价保险。

41. 什么是 MCP，在创业里怎么用#

MCP（Model Context Protocol）是让 Claude 连接外部工具和数据源的标准。在创业里它让 Cowork 不需要专人去 build 和维护集成就能接上公司运行所依赖的互联系统——项目管理工具、通信栈、数据源。Idea 阶段它连 Gmail 和 Google Calendar 来管访谈外联线程和排期，MVP 阶段同样的集成用来跑反馈 loop，Scale 阶段还能用 MCP connector 把你的工具直接嵌进用户的 Claude 里。一句话讲就是省掉了"招人搭集成"这件在 Day Zero 创业里总是落到创始人头上的活。

42. 什么是 Skills，在创业里能解决什么#

Skills 能把反复出现的 workflow codify 成可复用的 routine，让 Claude 每次都用同样的方式执行，比如"我怎么审一份商业租约"“我怎么 triage 一份患者入院表”。它在 Scale 阶段尤其有用：创始人通过对话把行业 jargon、监管陷阱、edge case、为什么显而易见的答案行不通这些领域知识沉淀进来，Skills 再把这些固化成例程，几个月下来就成了通用 AI 比不了的专有知识底座。文档里还举了 Airtree 的例子——一个人用 skills 搭的 workflow 自动化，全组织的人都能拿来用。

43. Claude Code Security 是什么#

Claude Code Security 是比普通安全 review 更进一步的能力：它扫描代码库找安全漏洞，并给出有针对性的补丁建议供人工评审，能发现传统方法漏掉的问题。它的定位是在 ship 前的 loop 里建立一个安全习惯，对 MVP 阶段把产品推给真实用户前做一遍 pass 特别有用，Launch 阶段还能帮你为独立安全评估做准备。注意文档发布时它还是 limited beta，用前要确认当前可用性。要强调的是它是辅助而不是合格合规评审或人工 reviewer 的替代品。

44. 什么是 measurement framework，为什么要在 launch 前就建好#

measurement framework 是一套在第一个用户出现前就定好的衡量体系：哪些指标对你的产品重要、benchmark 是多少、什么样的数据 pattern 才算真 PMF 而不是讨喜的噪声。具体要在发 MVP 前就设好留存基准、激活标准、Day 7 和 Day 30 目标。为什么要提前——那些把早期 traction 误当 PMF 的创始人，往往就是上线后才开始追踪、而且选的指标是用来证明什么在 work 而不是暴露什么没 work。还要提前定义 false positive 长什么样：有注册无激活、有营收无留存、有初始热情无复用。

45. 为什么 AI-native 创业反而更要强调 “validate before build”#

因为 agentic coding 把造原型变得又快又几乎免费，“造"不再是天然的 forcing function 去逼你想清楚。过去造东西要真金白银的开发时间，一个基础原型也要几个月，这本身就拦住了盲目开造；现在门槛没了，AI 让创始人太容易不验证就直接造。而 42% 的创业死于造了没人要的东西，门槛消失后这个失败率只会涨。所以恰恰是 building 变便宜了，validate-before-build 这个纪律才更关键——首要准则是让 sense-making 永远跑在 building 前面。

46. 为什么要在动手前写一份 scope 文档#

因为 zero-friction scope creep 是 AI 时代 MVP 的标志性失败模式：加功能从一个 sprint 变成一个下午，对抗蔓延的工程成本 forcing function 没了。每个增项单独看都有理，所以当下都不觉得是 creep，但产品越界后你会失去方向和动量。scope 文档说清产品做什么、刻意不做什么、以及什么真实用户证据才 justify 新增，把决策点从"该不该造这个"挪到"是不是一批关键用户说没它就拿不到价值”。同样的逻辑也用在架构上——先写下来，再让 Claude Code 在护栏里干活。

47. 什么是 devil’s advocate / 结构化对抗思考，为什么是核心用法#

devil’s advocate 指的是让 AI 反着帮你——不是验证你的点子，而是去反驳它、找推翻假设的反证。文档明确说"把 Claude 当作结构化的 devil’s advocate 是 AI 创业生命周期每个阶段的核心用法"。它对抗的是被 AI 放大的 confirmation bias：你让 AI 证明你对，它就能找到支持证据，所以你必须主动让它做最强的反方论证，比如让它论证某个竞品为什么会成功而你会失败。当研究和结构化对抗思考揭示出你的点子需要修正，那就是 pivot 的信号。

48. data flywheel（数据飞轮）是怎么形成护城河的#

用户和产品交互时会产生行为信号——接受哪些输出、拒绝哪些，这些信号喂回产品 roadmap。时间一长你就学到了你这批用户特有的 pattern、偏好、edge case，每次改进让产品更有用、带来更多使用、产生更多反馈、再驱动更多改进，这就是 compounding value。关键在于这份数据是 time-locked、context-specific、抄袭者无法重建的——你买不到几千个在你产品里打磨过 workflow 的用户的行为指纹。文档建议做法是让 Claude 找出最高信号的行为 pattern，设计把使用变成系统性模型改进的反馈 loop，并写一页 moat narrative 说明为什么有钱的对手两年内也复制不了。

49. 为什么领域专家创始人能建出别人复制不了的产品#

因为 agentic AI 让从没写过代码的领域专家也能把 first-hand 的行业 know-how 变成产品。创始人通过对话、projects、memory 把行业 jargon、监管 gotcha、edge case、为什么显而易见的答案行不通这些都沉淀成结构化可搜索的上下文，Skills 再把反复 workflow 固化成例程。几个月下来这成了通用 AI 比不了的专有知识底座，比如通用医疗账单工具会在 340B 药品项目理赔上崩，而你的有专门逻辑。Claude Code 帮你把同行常见的 frustration 翻译成验证逻辑、prompt 精修或对接 niche 行业系统的 MCP 集成，产品的深度广度随之复利增长。

50. 一句话讲，AI 改变了创业的什么、没改变什么#

没改变的是创始人的工作本身：找一个真实问题、造出解决它的东西、把它 scale 成一家重要的公司。改变的是抵达那里的路径——AI 把季度压成了周。验证周期从几个月变成几个下午，可工作的原型不再需要一个有对应技术栈的联合创始人、只需要一个清晰问题和几次专注的 coding agent session，运营重负越来越能交给 AI。一句话总结就是：瓶颈不再是你能造什么，而是你选择造什么。