AI Native 合集 on Z's Blog

Same Job, New Rules：创始人的不变与变

Sat, 01 Aug 2026 10:00:00 +0800

赫拉克利特说：“人不能两次踏入同一条河流。“创业这条河也不例外——河水在变，河岸在变，但过河这件事本身，从未改变。

什么变了

The Founder’s Playbook 最后一章叫"Same Job, New Rules”，开篇第一句话就点题：在 AI 时代，创始人的工作没有变——找到真实的问题，构建解决方案，把它变成一个重要的公司。变的是到达那里的路径。

过去九篇文章，我们逐层拆解了这条新路径的每个阶段。把"变了"的部分梳理一遍，你会看到一条很清晰的曲线。

Idea Stage 变了。过去验证一个问题要几个月的调研和几十场访谈。现在 AI 帮你做竞争分析、设计访谈框架、自动化外联，验证周期从几个月压到几周。但"验证"本身的必要性没变，反而因为构建成本降低而变得更重要——做错的代价低了，做错之后浪费的机会反而多了。

MVP Stage 也变了。过去一个原型需要一个团队几个月的工作。现在 agentic coding 让一个人一个下午就能做出一个看起来像那么回事的产品。但"产品市场契合"的标准没变——用户是否真的在乎，不会因为你的产品做得更快就自动成立。

Launch Stage 同样变了。过去从产品到公司需要招一个运营团队。现在 AI 工作流自动化让一个小团队能跑出大团队的运营效率。但"系统化运营"的目标没变——你需要不依赖创始人的系统。

Scale Stage 的变化更微妙。过去构建护城河要几年时间和大量资源。现在 AI 让领域知识的编码和用户数据的复利变得更快。但"护城河"的本质没变——时间积累的东西，仍然需要时间来积累。

什么没变

这是更重要的问题。

判断力没变。AI 能帮你做研究、写代码、起草文档、分析数据。但它不能告诉你"这个问题值不值得做”、“这个方向对不对”、“这个时机该不该出手”。这些判断需要你独有的上下文——你的行业经验、你的直觉、你对用户的理解。

领域知识也没变。AI 是通用智能，它不知道你所在行业的那些"只可意会不可言传"的东西。340B 药品项目的计费逻辑、建筑行业的合规要求、法律行业的风险偏好——这些需要真实经验的东西，AI 只能辅助，不能替代。

用户信任更没变。用户选择你的产品，不是因为你的 AI 有多强，而是因为他们相信你能解决他们的问题。信任来自真实的对话、可靠的交付、长期的承诺。这些 AI 帮不了你——只能靠你自己。

把这些串起来看，创业的本质没变：找到真实的问题，构建解决方案，把它变成一个重要的公司。这句话在 2020 年、2026 年、2030 年都成立。工具在变，但创业的核心——为真实的人解决真实的问题——从未改变。

路径压缩，本质不变

The Founder’s Playbook 用一句话总结了 AI 对创业的影响：AI 把每个阶段的时间轴压缩了——验证从几个月变成几周，原型从团队工作变成个人工作，运营从小团队变成 AI 加一个人。

但压缩的是时间，不是工作本身。你仍然需要验证、需要构建、需要发布、需要规模化。你仍然需要判断力、领域知识、用户信任。你仍然需要在每个阶段做出正确的选择——只是现在，你有更好的工具来执行这些选择。

这让我想到一个关于摄影的类比。数码相机和 Photoshop 让"拍一张好照片"变得前所未有的容易——你不再需要暗房、不需要对曝光的精确控制、不需要等胶片冲洗。但"什么值得拍"和"怎么构图"的判断力，仍然是摄影师的核心能力。工具变了，审美没变。

给 AI 原生创始人的三句话

读完这本书，走完这个系列，我想留三句话给正在或准备打造 AI 原生公司的创始人。

构建护城河：数据、知识与锁定——AI 时代的三种防御体系

Sun, 26 Jul 2026 10:00:00 +0800

中世纪欧洲的城堡有三种防御：护城河（让敌人难以接近）、城墙（让敌人难以突破）、和吊桥（让盟友自由进出）。AI 时代的护城河也有三种——数据飞轮、领域知识、和用户工作流锁定。

AI 让复制变容易，让积累变稀缺

2025 年，一个有趣的现象引起了投资圈的注意：一批 AI 原生公司的估值开始分化。有些公司功能看起来差不多，但估值差了一个数量级。区别在哪？

不是功能，是护城河。

在 AI 让"复制一个产品"变得越来越容易的时代，功能不再是壁垒。一个有充足资源的竞品可以用几周时间复制你的功能。那什么才是真正不可复制的？

The Founder’s Playbook 给出三个答案。每一个都建立在时间积累之上——而时间，是 AI 无法加速的。

第一条护城河：数据飞轮

用户和产品互动时产生行为信号——哪些输出被接受，哪些被拒绝。这些信号随时间积累，变成你的产品路线图。

The Founder’s Playbook 把这叫做"复利价值"：每一次改进让产品更有用，更多使用产生更多反馈，更多反馈驱动更多改进。这就是数据飞轮。

这种数据有三个关键属性。时间锁定——你买不到数千个用户在你的产品里优化工作流留下的行为指纹。上下文特定——这些数据是在你的产品、你的用户群体、你的使用场景中产生的，换个环境就不一样了。不可能被复制——即使竞品知道你有这个飞轮，他们也无法在短时间内重建。

书中给出了一个具体的练习：把你的产品互动数据（收集了什么、收集了多久、用户如何随时间互动）交给 Claude，让它识别三个最高信号的行为模式，然后设计一个反馈循环，把每个模式变成系统性的模型改进。最后，让它帮你起草一页"护城河叙事"——你的数据飞轮怎么转、转了多久、为什么一个有充足资源的竞品今天开始做，两年内也复制不了。

第二条护城河：领域知识外化

很多 AI 原生公司的创始人做的是高度具体的应用——他们在某个行业里亲身经历过的问题。Agentic AI 让这些没有工程背景的创始人也能用领域知识构建产品。

关键在于，把你的领域知识放进一个结构化的、AI 能访问的上下文里。通过长期对话、项目和记忆，把你的行业知识——行规、监管陷阱、边缘 case、为什么显而易见的答案行不通——放进 Claude 的上下文。然后把这些编码成 Skills，让 Claude 每次都以同样的方式执行。

书中举了一个挺精彩的例子：一个通用 AI 医疗计费工具会在 340B 药品项目上出错，但你的产品专门处理了这些逻辑。为什么？因为你有领域知识，而且你把它编码进了系统。

几个月后，这就变成了一种专有的知识基底，通用 AI 做不到。一个没有你这种领域经验的竞品，即使有同样的 AI 工具，也会在你的细分领域里反复踩坑。

我自己有一个略带刺刀味的判断：你的测试套件就是你的护城河的地图。 每一个你处理过的边缘 case，都是竞品还没踩到的坑。

第三条护城河：用户工作流锁定

数据飞轮让产品更难复制，但工作流锁定让产品更难离开。

用户在你的产品上构建了自动化，培训了团队，连接了数据源。他们开发的 prompt、优化的工作流、标准化的输出——都是围绕你的产品塑造的。这时候，换产品就不再是产品决策，而是一个全规模的运营项目。

The Founder’s Playbook 给出了一个实操方法：让 Claude 按集成深度映射你的客户群。对每个客户群体，识别他们在你的产品上构建了哪些工作流、依赖哪些集成。这显示了你的产品在哪里"粘"得牢，哪里还需要加深。

集成的数量和质量是关键。你提供的集成越多，客户就有越多表面面积来构建依赖你的工作流。Claude Code 帮你快速构建原生集成——数据管道、项目管理工具、用户依赖的其他系统。更深一层的锁定：构建 API、webhook 和 SDK，让客户不只是"用"你的产品，而是"在之上构建"——这是最深形式的锁定。

技术债与架构决策：为 Scale 打下地基

Tue, 21 Jul 2026 10:00:00 +0800

古罗马人在建造道路时，会先挖一条深沟，铺上多层砂石和碎石，最后才铺上平整的石板。他们知道：路能走多远，取决于地基有多深。今天，你的代码库就是那条路——而 CLAUDE.md 就是你的地基剖面图。

两种技术债

不是所有技术债都一样。理解这一点，是 Scale 阶段的第一课。

第一种是有意技术债——你在充分知情的情况下，选择用代码质量换速度。你知道这笔债的存在、它的规模、什么时候该还。这种债本质上是投资：你借了时间，计划在某个 sprint 里连本带息还清。

第二种是无意技术债——你不知道它存在，或者知道但不知道它有多大。它来自"先这样吧"的临时方案、来自"以后再重构"的承诺、来自那些"能跑就不要动"的模块。这种债是高利贷，利息在暗处累积，直到某天你发现已经还不起了。

在 AI 原型的场景里，The Founder’s Playbook 指出了一个特有的风险：agentic 技术债是一种"超级无意债"。

为什么？因为 agentic coding 工具移除了所有曾经控制什么进入生产的自然瓶颈。过去，代码要经过设计审查、代码审查、测试——每一步都是制衡。现在，一个 prompt 就能让代码进生产。速度是保证了，但质量控制的责任完全落到了创始人身上。这一层责任，是 agentic 工具不会主动告诉你的。

架构审计：看见你的地基

The Founder’s Playbook 建议在 Scale 阶段做一次完整的架构审计。

具体操作：让 Claude Code 审计代码库，产出一份结构脆弱性清单——哪里是脆的捷径、哪里测试覆盖不足、哪里模块边界模糊。然后让 Claude 对这份清单做优先级排序：什么会拖累下次发布，什么可以并行处理，什么是当前阶段能接受的。

这个审计的价值不只是"修 bug"。它强迫你看见自己的代码库——不是作为一个个文件，而是作为一个系统。我自己的经验是，大多数创始人在 Scale 阶段第一次真正"看见"自己的代码库，那种感觉有点像第一次站在高楼上俯瞰自己住了多年的城市：你突然意识到有些路是断头路，有些楼是没有地基的。

从"能跑"到"能扛"

Scale 阶段的技术工作不只是修代码——它是围绕代码构建基础设施。

企业买家在签多年合同之前，要看的不是你的产品功能，而是你的组织能不能成为一个可靠的基础设施合作伙伴。他们要看产品文档、支持 playbook、SLA 承诺。签了之后，他们会要求你兑现。

The Founder’s Playbook 给出了一个三层方案。

第一层是文档：产品文档、支持 playbook、SLA——这些是企业采购团队期望看到的东西。AI 帮你起草和更新，但内容需要你的领域知识来校准。

第二层是代码：用 Claude Code 加固代码库，针对企业合同要求的特定可靠性和安全标准。构建日志、监控、事件响应工具、可观测性层——让 SLA 真正可执行，而不是一句口号。

第三层是运营：用 Claude Cowork 跑企业支持运营层。工单路由、升级工作流、文档更新（随产品变化自动触发）、续约追踪、企业客户成功依赖的报告节奏。

三个工具协同，让一个小团队能展示出比自身规模大得多的组织成熟度。这件事看起来是技术问题，其实是组织伪装问题——你得让外界觉得你"像那么回事"。

知识编码：把你的脑子变成系统

Scale 阶段最容易被低估的挑战，是创始人的制度知识。

从创始人驱动到系统化运营：建立不依赖你的机器

Wed, 15 Jul 2026 10:00:00 +0800

亨利·福特说：“我问人们想要什么，他们说要一匹更快的马。“但福特真正的天才不是发明了汽车——他发明了生产汽车的系统。没有装配线，T 型车只是另一辆昂贵的实验品。Launch 阶段的核心任务，是把创始人从"T 型车"变成"装配线”。

创始人成为瓶颈的那一刻

The Founder’s Playbook 描述了一个每个创始人都会经历、但很少提前意识到的时刻：你不再是公司的加速器，你成了公司的限速器。

信号很具体。本该一小时的决策，现在要排一周才能轮到你；支持请求在堆积，因为只有你知道答案；运营任务只在你记得做的时候才发生；产品路线图卡在你这里，因为所有重要决定都要过你的手。

在 Idea 和 MVP 阶段，创始人在每个循环里是一种资产——你需要全局认知和紧密反馈循环。但到了 Launch，支持量在涨，产品在变复杂，运营在膨胀。那种"我亲自盯着"的习惯，开始反噬。

这不是一次突然发生的转变，更像温水煮青蛙。某天你突然发现，公司不在"因为你而快”，而在"因为你而慢"。

全面审计：你在忙什么

The Founder’s Playbook 的解法很直白——把你亲自在处理的每件事，从最小任务到最高风险决策，全部列出来。然后分三类。

第一类是可以系统化的：CRM 更新、周报生成、用户外联排期、bug 分类。它们有明确触发条件、决策规则和输出格式，是 AI 工作流自动化的理想对象。先动这些。

第二类是需要人但不一定需要你的：某些支持请求、代码审查、内容审核。这些需要人的判断，但不需要创始人的判断。可以委托给团队成员，或者让 AI 辅助一个初级处理流程。

第三类才是真的需要创始人的：产品叙事决策、董事会关系、战略合作、创始人对创始人的对话。这些需要你独有的上下文和关系，没人能替。

分类完之后，用 Claude Cowork 设计自动化工作流的逻辑：什么触发、什么规则、输出是什么、完成后去哪里。这一步看着琐碎，但它是后面一切的基础。

技术债的系统性清理

Launch 阶段另一个紧迫任务是处理 MVP 阶段攒下的技术债。

MVP 时期，一些技术债是合理的——你拿代码质量换了速度。但到了 Launch，这些债开始产生利息。生产流量在涨、新功能在叠加、代码库在膨胀，那些"以后再说"的捷径，现在成了结构性负债。

The Founder’s Playbook 给了三步走的建议。先用 Claude Code 做一次完整的架构审计，找出脆弱处、维护成本高的捷径、测试覆盖不足的区域。然后把审计结果交给 Claude 做优先级排序——什么必须在下次发布前修，什么可以等一轮 sprint，什么是当前阶段能接受的持续债。最后，把 MVP 阶段脑子里的架构决策写进 CLAUDE.md——那些当时没时间写下来的决定，现在该落地了。

这一步我自己的体会是：写下来这件事，比审计本身还重要。审计是发现问题，写 CLAUDE.md 是把"为什么这么决定"固化下来。下次新人或者 AI 接手时，不用再去猜你的意图。

安全与合规：不再是可选项

MVP 阶段，安全漏洞是理论风险——你的用户是 beta 测试者，没有敏感数据在生产环境里跑。

到了 Launch，情况变了。你的产品上有真实用户、真实数据，可能还有企业合同在谈。合规要求也一样——处理客户数据、处理支付、卖到受监管行业，这些都不再是"未来的事"。

书里的态度很直接：在规模到来之前，而不是之后，做一次系统性的安全和合规审查。 把所有发现当作必须修复的项目，不是建议。

产品市场契合的谎言与真相：如何识别假信号

Thu, 09 Jul 2026 10:00:00 +0800

1947 年，飞行员肯尼斯·阿诺德在雷尼尔山附近目击九个碟状物体，“飞碟"一词从此诞生。但大多数 UFO 报告最终都被证实是气象气球、金星、或光学错觉。数据不会说谎，但对数据的解读会。

创始人最容易对自己撒的谎

产品市场契合（Product-Market Fit，PMF）大概是创业里最被滥用的词。每个创始人都在找它，但说实话，很多人找到的只是它的影子。

The Founder’s Playbook 给的定义反而很克制：一个特定、可识别的用户群体，发现你的产品有价值到足以回来用（留存）、付费（收入）、或告诉别人（推荐）。三个条件满足其一就行。

问题就出在"其一"上——这三个信号，每一个都能被伪造。

三种假阳性

最常见的假阳性是注册涨、激活没动。用户来了、注册了，但从未真正用过产品的核心功能。你打开后台，注册曲线昂扬向上，活跃曲线却像一条死鱼。这种情况在有强外联驱动的产品里尤其多见——创始人人脉能拉来注册，但拉不来留存。

收入也是个大坑。用户付了一个月的费，第二个月就走了。这事在解决一次性需求的产品里几乎是标配——报税、年度合规检查、一次性数据迁移。用户掏钱那一刻你以为是 PMF，其实只是一次性需求被满足了。一次性收入和持续收入之间那道缝，就是假 PMF 和真 PMF 之间的距离。

但最伤人的，是访谈里的热情。用户当面说"这产品太棒了”，第三周就不来了。说出来的喜好和实际行为之间，有一条巨大的鸿沟。斯坦福行为设计实验室反复证实过一件事：自我报告的行为，预测力接近随机。 这句话我每次读到都觉得像被扇了一巴掌。

从"推"到"拉"

The Founder’s Playbook 给了一个更本质的判断标准——你的产品是在被你"推"，还是在被用户"拉"。

PMF 之前，留存全靠你干预。频繁外联、给激励、创始人亲自盯，所有的留存都是你"推"出来的。就像推一辆没发动的车，你一松手它就停。

PMF 之后，产品开始自己做这些事。用户自己回来、自己摸索新功能、自己告诉朋友。这时候你松手，车还在走——它有自己的发动机了。

这个转变很难量化，但你能感觉到。某天你发现自己不再需要每天发邮件求用户使用，用户开始主动给你发功能请求，自然增长（而非付费增长）开始占比上升——这些信号叠在一起，就是 PMF 的证据。

衡量框架：在用户来之前建好

上一篇文章提过这个原则，但值得展开。

The Founder’s Playbook 的建议是：在第一个用户进来之前，就定义好你的衡量框架。我倾向于把这件事看得比"写第一行代码"还重要——因为一旦数据开始流，你就来不及冷静定义"什么算好"了，你会被数字推着走。

具体要做的几件事，先说留存基准。Day 7 留存多少算合格？Day 30 呢？这数字因产品而异——社交工具和 SaaS 的基准天差地别。但你必须给自己一个数字，否则"好不好"永远是一个情绪判断。

然后是激活标准。注册不算数，完成第一次核心工作流才算。AI 写作工具可能是"生成第一篇文章并导出"，CRM 可能是"导入联系人并创建了第一个 pipeline"。这个标准要硬，不能事后改。

最后——也是最容易被忽略的——是预设"假阳性"模式。注册了但没激活、付费了但没留存、初始热情但没有重复使用。当这些模式出现时，你的框架应该能自动把它们标红，而不是让你事后拍脑袋回忆。

用 AI 做对抗性分析

数据进来之后，The Founder’s Playbook 建议让 AI 对你的 traction 做一次 adversarial 分析——让它扮演最严厉的怀疑论者。

“这些注册数字里有多少是创始人的朋友？” “这个留存率在同行业里算什么水平？” “如果去掉前两周的外联推动，自然留存是多少？”

这些问题你自己其实也能想到。但问题在于，创始人天生有一种倾向——把好消息当证据，把坏消息当例外。我自己写过几年量化策略，对此深有体会：人一旦对某个结果有情绪偏好，“客观分析"就开始失灵。AI 没这个偏好。它不会因为这是你的创业公司就对你温柔。

MVP 的四个暗礁：速度与陷阱的博弈

Thu, 02 Jul 2026 10:00:00 +0800

希腊神话中，奥德修斯在塞壬女妖的海域航行时，让船员用蜡封住耳朵，把自己绑在桅杆上。他听到了歌声，但无法偏航。MVP 阶段，你需要同样的自律——听到"快"的歌声，但不被它带偏。

速度是一把双刃剑

上一篇文章我们讲了如何从 CLAUDE.md 开始构建产品。现在假设你已经有了架构文档、范围文档，代码开始跑起来了。

然后速度来了。

Agentic coding 工具让"构建"变得前所未有的快。一个功能从想法到上线，过去要一个 sprint，现在要一个下午。这种速度让人上瘾——你开始觉得"再做几个功能"、“再处理几个边缘 case”、“产品再完善一点再发”。

The Founder’s Playbook 把 MVP 阶段的核心矛盾归结为一句话：AI 保证了速度，但速度本身成了最大的风险。

接下来要说的四个暗礁，都和这个矛盾有关。

第一个暗礁：Agentic 技术债

普通技术债是可以管理的——你欠了，但知道要还，可以在某个 sprint 里集中清理。

Agentic 技术债不一样。它会累积。

原因在于：没有写下来的架构约束，每个 AI 会话都从头推导基础决策。这个会话决定用 REST API，那个会话决定用 GraphQL；这个会话把用户认证放在前端，那个会话把它放在后端。每个决策单独看都合理，但它们合在一起——代码能跑，但背后没有一个连贯的心智模型。

这就像让十个厨师各自做一道菜，但没人告诉他们这是同一桌宴席。每道菜单独吃都没问题，但放在一起，口味冲突、温度不一致、上菜顺序混乱。

The Founder’s Playbook 的建议是：在 MVP 阶段就保持 CLAUDE.md 的更新。每个会话结束，花五分钟记录这个会话做了什么决策、引入了什么假设。这不是文档洁癖，是防止你的代码库在第六个月变成一团只有 AI 能读懂的意大利面。

第二个暗礁：假产品市场契合

这是最危险的暗礁，因为它看起来像陆地。

发布产品的那一刻，是创始人最脆弱的时刻。几周的验证、几个月的构建，终于有了一个能跑的东西。你的朋友来试用，投资人介绍的潜在买家来试用，一条 Hacker News 头条带来一波流量——早期数字看起来不错。

但早期 traction 不等于产品市场契合。

Launch 能量来自短暂的、外部的助推力。真正的产品市场契合是一个模式——它必须在多个迭代周期中持续成立，才能被确认。

书中提到了 Sean Ellis 测试：问你的活跃用户"如果你不能再用这个产品了，你会感觉怎么样？“如果超过 40% 回答"非常失望”，这是一个有意义的信号。

但更根本的检验是从"推"到"拉"的转变。产品市场契合之前，留存需要持续干预——频繁的外联、激励、创始人亲自盯。产品市场契合之后，产品开始自己做这些事。当你发现自己在"推"的力气开始变轻，那才是真正变化的信号。

第三个暗礁：零摩擦范围蔓延

每个功能只要一个下午。每个边缘 case 只要几分钟。每一项单独看都理所当然。

这就是 AI 时代范围蔓延的新形态。传统的制衡——工程师时间的真实成本——不存在了。加一个功能不再需要一个 sprint 的讨论，只需要你的一句话。

构建第一个 AI 原生产品：从 CLAUDE.md 开始

Fri, 26 Jun 2026 10:00:00 +0800

文艺复兴时期的大师在动笔之前，先画几百张草图。达·芬奇的笔记本里全是未完成的想法——不是因为他不擅长完成，而是因为他深知：思考的结构决定了作品的结构。今天，CLAUDE.md 就是你的草图。

先写文档，再写代码

这个建议反直觉到几乎冒犯。

你是创始人，你有一个经过验证的问题，你迫不及待要动手做产品。The Founder’s Playbook 却让你在写任何一行代码之前，先坐下来，和 Claude 一起定义并记录架构决策：遵循什么模式、避免什么依赖、接受什么权衡、为什么。

听起来像官僚主义，其实是为了防止 AI 把你的代码库变成巴别塔。

想想巴别塔的隐喻。如果每个 AI 会话都是一个工人，每个工人都说自己的语言、按自己的方式砌砖，最终的结果不是塔，而是废墟。CLAUDE.md 就是你的通用语——它告诉每一个进入这个项目的 AI：这个系统为什么这样设计、哪些边界不能碰、哪些权衡是刻意的。

为什么这件事在 AI 时代如此关键

传统团队里，架构知识通过代码审查、站会、文档、以及最重要的——人与人之间的隐性传递来维护。一个新工程师加入团队，通过和老工程师配对编程、一起吃午饭、在 Slack 上问"为什么"来学习系统的设计逻辑。

在 AI 原生团队里，你的"新工程师"是每一个新的 Claude Code 会话。它没有上下文——除非你给它。没有 CLAUDE.md，每次会话都从零开始推断结构假设。它能生成能跑的代码，但生成的代码背后没有连贯的心智模型支撑。

这就像让十个建筑师各自设计一栋楼的一层，但没人见过总平面图。每一层单独看都没问题，但它们合在一起会怎样？门可能开在承重墙上，水管可能穿过电线管道。

The Founder’s Playbook 把这种现象叫做"结构性不连贯"（structural incoherence）。代码能跑，能过测试，但背后没有一个统一的设计意图。问题不在任何一段代码，而在于所有代码从未被设计成能协同工作。

CLAUDE.md 里应该写什么

不是完整的规格书。你不需要在这个阶段写一份 IEEE 830 标准的需求文档。

你需要写的是决策和理由。为什么选 PostgreSQL 而不是 MongoDB？为什么接受这个技术债？为什么这个模块的边界划在这里而不是那里？

举个例子，你可能会写：

“我们选择 Next.js 而不是纯 React，因为我们预计未来三个月需要 SSR 来支持 SEO。这是一个刻意的选择，即使它增加了部署复杂度。如果三个月后 SEO 不再是优先级，可以重新评估。”

这段话告诉 AI 的不只是"用什么"，还有"为什么用"和"什么情况下可以改"。

范围文档：AI 时代的疫苗

和架构文档同等重要的是范围文档。

在 AI 时代，范围蔓延（scope creep）是一种全新的危险。过去，加一个功能需要一个 sprint 的工程师时间——这个成本本身就是一种制衡。现在，加一个功能只要一个下午。每一项单独看都理所当然：当然产品应该处理这个边缘 case，当然用户会想要那个工作流。

用 AI 做压力测试：让魔鬼代言人替你思考

Thu, 18 Jun 2026 10:00:00 +0800

苏格拉底说：“未经审视的人生不值得过。“在 AI 时代，未经反驳的创业想法不值得做——而 AI 给了你一个永不疲倦的反驳者。

确认偏误的新武器

1960 年，英国心理学家彼得·沃森做了一个著名的"2-4-6 实验”。他告诉受试者三个数字 2、4、6 遵循某个规则，让他们猜规则是什么。受试者几乎无一例外地先猜"连续偶数”，然后只举符合这个猜想的例子来验证。沃森的真正规则其实是"任意三个递增数字"——但很少有人主动去举反例来反驳自己。

这就是确认偏误：我们本能地寻找支持自己信念的证据，而忽略或贬低反面证据。在创业中，这是致命的。

The Founder’s Playbook 指出了一个 AI 时代特有的危险：确认偏误现在有了一个研究引擎。让 AI 验证你的创业想法，它会找到支持证据；让 AI 做市场规模测算，它会找到让 TAM 看起来可融资的数字。如果你不提出尖锐的问题，AI 可以比你更快地为一个坏想法构建出一套看起来像那么回事的"尽职调查"。

更危险的是，这个过程会让你感觉自己是在做尽职调查。一份 30 页的市场分析报告、一组漂亮的 TAM/SAM/SOM 拆解、五个"验证过"的用户痛点——看起来严谨无比，但前提可能是错的。

结构化魔鬼代言人

解法是同一个工具，指向相反的方向。

天主教会在 1587 年设立了一个正式职位叫"魔鬼代言人"（Devil’s Advocate）——专门负责在封圣过程中提出反对意见，质疑候选人的圣迹和美德。这个职位的存在不是为了阻挠封圣，而是为了确保封圣决定的严肃性。

The Founder’s Playbook 建议你把 AI 当作你的结构化魔鬼代言人。我自己把它拆成三个动作。

第一个动作是攻击问题陈述。不是让 AI 说"这个问题很好"，而是让它构建一个论证：为什么这个问题没有你以为的那么大、不值得解决、或者已经被很好地解决了。让它找反例：哪些市场信号是负面的？哪些竞争对手失败了，为什么？用户行为模式里有哪些和你的假设矛盾的地方？

第二个动作是替竞品辩护。让 AI 分析竞品的方案为什么比你好、用户为什么选他们、你的差异化优势为什么没有你以为的那么牢固。这一步会逼着你理解竞品的真实优势——而不是你为了方便而刻意简化的那个"竞品"。

第三个动作是质疑解决方案。你的方案依赖哪些假设？每个假设在什么情况下不成立？如果有一个假设被证伪，整个方案会怎样？

压力测试之后

做完这三步，你大概会经历两种反应之一。

第一种：你的想法经受住了攻击，你知道了它最脆弱的在哪里——这让你在接下来的用户访谈中有了明确的测试方向。

第二种：你的想法被撕开了，你发现核心假设站不住——说实话，这是好消息。不是"你失败了"，而是"你在动手之前就知道这条路走不通了"。

这让我想到查理·芒格的一句话：“我只想知道我会死在哪里，这样我就永远不去那个地方。” AI 让你有能力在创业之前，先快速"死"上几十次。每一次虚拟的死亡，都避免了一次真实的资源浪费。

用户访谈的框架

压力测试之后，才轮到用户访谈。书中建议用 AI 来设计和优化访谈框架——但有一个关键原则：问题要先自己写，再让 AI 审。

为什么？因为如果你直接让 AI 生成访谈问题，你会得到一组"正确但平庸"的问题。它们没有引导性、没有漏洞、也没有灵魂。但如果你先自己写——暴露你的偏见、你的假设、你的盲区——然后让 AI 来审，它会指出哪些问题在引导受访者、哪些太宽泛、哪些会得到社会期望的答案而不是真话。

一个实用的技巧：在访谈中，永远问过去，不问未来。“告诉我你上次遇到这个问题时发生了什么"比"你觉得你会不会用这种产品"有价值得多。人们不擅长预测未来，但很擅长回忆过去。

每五场访谈之后，让 AI 合成笔记，列出支持假设的证据和挑战假设的证据。如果前者远长于后者，要警惕——可能不是数据在说话，是你在选择性地听。

找到你的问题域：从"能做"到"该做"的跨越

Sat, 13 Jun 2026 10:00:00 +0800

孙子曰：“夫未战而庙算胜者，得算多也。“在 AI 让"建造"几乎免费的今天，“算"什么、“算"哪里，反而成了最难的一道题。

无限可能，零值判断

2024 年秋天，我在旧金山参加了一场创业聚会。一个穿 Patagonia 背心的年轻人告诉我，他周末用 Claude Code 做了三个产品原型——一个 AI 法律助手、一个自动化记账工具、一个社交媒体内容生成器。“三个都能做，“他说，“但我不知道该做哪个。”

这不是个例。当 agentic coding 抹平了技术门槛，创始人面临的选择困境反而加剧了。过去，你能做什么受限于你会什么；现在，你能做什么几乎没有限制，但"该做什么"的判断难度陡然上升。

这就像一个厨师走进一个无限食材的厨房——真正的限制不再是食材，而是对"什么菜值得做"的品味。

问题的三个层次

The Founder’s Playbook 把 Idea Stage 的验证工作归结为四个按顺序回答的问题：这个问题真实、具体、频繁到值得围绕它做公司吗？谁有这个问题？有没有人在解决它？你的方案能做到吗？

这些问题看似朴素，但每一个都暗藏陷阱。我自己见过太多人在第一关就栽跟头。

第一个陷阱是"真实”。一个经典的创业认知偏差是：我是用户，所以我的问题就是大家的问题。这叫"自我抽样偏差”——你当然有这个问题，因为你就是你。但市场不是你的镜像。

书中给出的例子很精妙：“人们做报销很痛苦"是一个观察，不是假设。“中型公司的财务经理每周花四个多小时核对报销单，因为现有工具和他们的会计软件不互通"才是可验证的假设。前者让你感觉抓住了需求，后者让你能去验证。

第二个陷阱是"具体”。德鲁克在《管理的实践》里说过类似的话：企业只需要做两件事——营销和创新。但如果你问创始人"你在解决什么问题”，得到的答案往往是"让工作更高效"或者"用 AI 改变行业”。说实话，这不是问题陈述，这是愿景口号。真正的问题陈述要具体到你能指着一个人说：“他，每天下午三点，正在经历这个问题。”

第三个陷阱是"频繁”。一个一年发生一次的问题，用户不会为它付费——他们会自己忍着。一个每天发生四次的问题，用户愿意为任何能解决它的东西付费。频率决定了你的收入模型。

用 AI 做竞争地形图

找到问题域不只是向内看——你还得向外看。书中建议用 AI 做竞争地形分析，而且要用一种特殊的方式：让 AI 替你的竞争对手说话。

不是让 AI 列出竞品的功能对比表——那种表格谁都会做。而是让 AI 构建一个论证：为什么这个竞品会成功，而你会失败。让它分析竞品的方案为什么更好、用户为什么选他们、你的差异化优势为什么没有你以为的那么牢固。

这招来自军事战略中的"红队演练”（Red Teaming）。冷战时期，美国国防部专门组建团队扮演苏联指挥官，用苏军的思维来审视美军计划。效果显著——很多在美军内部"显而易见"的行动计划，被红队从敌方视角拆解得千疮百孔。

我自己试过这个方法，它的价值在于：AI 会告诉你那些你因为太爱自己的 idea 而选择性忽略的东西。

客户发现的实操

找到问题域的最后一步是和人说话——不是"你觉得这个想法怎么样”，而是"告诉我你上次遇到这个问题时发生了什么"。

这里有一个创业研究中反复验证的发现：人们不擅长预测自己未来的行为，但很擅长描述自己过去的行为。问"你会不会用这个东西"得到的是愿望清单；问"你上次遇到这个问题时怎么处理的"得到的是行为数据。

The Founder’s Playbook 建议用 Claude Cowork 来自动化客户发现的操作层：构建目标用户画像、生成外联邮件、管理排期、追踪访谈进度。但有一条原则要守住——对话本身必须是人。一个用户说"这个很好但我希望它也能……"，这句话背后的含义——是核心需求还是一厢情愿？是个人偏好还是群体特征？——只有人能判断。

退出条件

Idea Stage 的退出条件是找到"问题-解决方案匹配"：你有定性证据证明你在为真实的人解决真实的问题。三个检验——你能说清楚谁、多频繁、多严重、现在在怎么办吗？你的方案针对的是被验证过的问题吗？目标用户群构成一个真实的市场吗？

三个都过得去，再往下走。

我自己反复在想的一点是：AI 最大的能力不是帮你做决定，而是帮你更快地发现自己做错了决定。快速验证、快速失败、快速转向——这才是 AI 给 Idea Stage 的真正礼物。不是让你更快地构建，而是让你更快地知道自己该不该构建。

从福特流水线到 AI 原生：打造一家 AI Native 公司的换轨

Fri, 05 Jun 2026 10:00:00 +0800

1913 年，福特高地公园工厂引入移动装配线，汽车底盘的装配时间从 12 小时 28 分压缩到 1 小时 33 分。这不是效率的改良，而是生产范式的重构。今天，AI 正在对创业做同样的事。

一场安静的换轨

1913 年之前，汽车是工匠在固定工位上逐件组装的。每个底盘架在同一个位置，工人围着它转。福特做了一件听起来很简单的事：让底盘动起来，让工人站着不动。装配线不是新工具，它是新范式——它改写了"造车"这件事本身。

The Founder’s Playbook: Building an AI-Native Startup 描述的就是这样一个时刻。2026 年的 AI 不是在"改良"创业流程，而是在重构"创办一家公司"这个行为的内在脉络。

过去几年，我们见证了几个关键节点的到来。2022 年底 ChatGPT 发布，AI 从实验室走进客厅。2024 年 agentic coding 工具成熟，一个人可以在一个下午做出过去一个团队几个月才能交付的产品。2025 年，YC 批次的创业公司中，单人创始的比例显著上升——不是因为他们更孤独，而是因为 AI 让一个人能跑出一个团队的节奏。

这不是"效率提升"。效率提升是在同一个范式里做得更好。换轨是——你不再需要优化旧范式，因为你换了一个。

什么是 AI Native？

先说它不是什么。AI Native 不等于"用了 AI 的公司"。就像"移动互联网原生"不等于"做了个 App 的公司"——诺基亚有 App，但它不是移动原生。

AI Native 是一种组织范式：AI 在这里不是工具层，而是基础设施层。就像电力对工业革命的意义——你可以买发电机，但真正的变革来自整个工厂围绕电力重新设计。

在 AI Native 公司里，创始人的工作不是写代码、做研究、起草融资材料——这些 AI 都能做。创始人的工作是编排：决定用什么工具、在什么阶段、解决什么问题、达到什么效果。这就像福特工厂里的生产工程师，他不拧螺丝，但他设计螺丝被拧的顺序。

为什么是现在

三个条件同时成熟了。

最根本的变化在构建这一层。过去，做一个软件产品需要技术联合创始人、外包团队，或者足够长的 runway 去招人。现在，一个没有工程背景的创始人可以用自然语言描述需求，让 AI 生成、测试、调试、重构生产级代码。从"有想法"到"有产品"的距离被压缩到几乎为零。

研究这一层也跟着变了。创始人在第一年需要知道的事情——怎么发工资、怎么规划产品迭代、怎么写投资人备忘录——几乎全是创业前不懂的。过去答案是"找个懂的人"，现在 AI 成了随叫随到的跨领域专家。

什么才算是AI Native：从卖工具到卖结果的新叙事

Mon, 01 Jun 2026 08:00:00 +0800

什么才算是AI Native：从卖工具到卖结果的新叙事

AI原生服务公司正在重写创业剧本：不是卖工具，而是直接交付结果。

YC Startup School最近一期节目中，主讲人Charlie Warren提出了一个颠覆性的观点：十年内，会出现一部分AI巨头公司，主业并不是做开发，而是被AI重新组织起来的服务公司。A16Z的投资团队也在多个场合强调，AI时代的创业机会不止于产品，更在于服务交付的重构。

这种转变正在发生。保险、税务、法务、审计、医疗文书、财务外包、合规服务、企业申报——这些传统、笨重、不互联网的行业，正在成为AI创业的新战场。根据麦肯锡研究，到2030年，AI有望自动化全球服务行业约30%的工作任务，市场规模预计超过万亿美元。

从SaaS到AI Native Service，一场从"卖工具"到"卖结果"的转向正在悄然发生。

从工具到结果：两种完全不同的商业逻辑

传统软件公司卖的是工具。客户买CRM是为了管理销售线索，买财务软件是为了处理账目，买合同工具是为了起草和审核文档。软件本身并不保证结果，它只是让客户内部的人更高效。

AI原生服务公司卖的则是结果。客户不再购买"合同审查工具"，而是购买"合同审查完成"；不再购买"报税软件"，而是购买"税务申报完成"；不再购买"合规助手"，而是购买"合规文件交付"。

核心区别在于责任边界：卖工具，客户需要学习工具、设计流程、承担执行结果；卖结果，服务公司要把业务的流程、质量控制、异常处理和最终交付都承担下来。这要求AI原生服务公司，既要具备传统服务外包BPO的运营能力，又要构建领先的AI驱动运营系统。

选市场：找到AI能真正创造价值的领域

不是所有服务行业都适合AI原生服务这条路。YC节目中指出，值得做的市场有几个关键特征。

第一，客户预算充足且持续。理想的入口是那些客户已经长期付费、但体验很差的服务：贵、慢、不透明、沟通成本高、结果不稳定。税务、保险、法务、审计、医疗、财务外包就特别典型。

第二，任务可拆解，能量化，有标准。AI擅长处理大量的、可以被验收、相对结构化、流程比较明确的工作，比如读取海量文件、提取关键信息、汇总撰写初稿、核对成百上千条规则。如果一个服务完全依赖专家经验判断，很难在早期直接自动化，但可以拆成一连串小任务，让AI先吃掉大部分工作量。

第三，客户关心结果，而不关心你的人力成本。客户只在意事情有没有办成、风险有没有降低、要求有没有达到、速度有没有提升。只要结果可信、交付稳定、责任清楚，新的供给方式就有机会替代旧方式。

Sam Altman测试：你的价值是否依赖模型本身？

很多AI产品本质只是给大模型包了一层界面。YC节目中提到的"Sam Altman测试"提供了一个判断标准：6-12个月后，GPT模型能力继续大幅提升，你的公司会因此更强，还是会被OpenAI的新功能覆盖掉？

如果你的服务价值只是"调用模型生成一段内容"，那会很危险，因为客户迟早自己就可以用模型完成同样的事情。但如果你的价值是精通复杂的行业流程、与客户建立深度信任、拥有独特的数据沉淀、质量控制能力出色、责任边界清晰、交付能力有保障，那么模型越强，你反而越有价值。

更强的模型会降低交付成本、提高处理速度、扩大服务范围、改善毛利结构。因此，顶尖的AI原生服务公司，必须建立在模型进步之上。

稳定交付是最大的壁垒，也是最大的难点

AI原生服务公司最大的挑战，是能不能稳定交付结果给到客户。服务行业卖的是信任，客户要的是确定性。

YC节目里有一句话：“variance kills these businesses faster than anything else”——不稳定性会比任何东西更快杀死这类公司。

想象一下：同样的问题，这次答对下次答错；同样的客户，这次体验好下次体验差；同样的流程，这个案例顺利，另一个案例失控。只要这种波动存在，客户对你的信任就会迅速被消耗掉。

一个真实案例：美国AI法律服务公司DoNotPay最初以"AI律师"的噱头吸引了大量关注，但因为AI回答的不稳定性，导致客户投诉激增，最终不得不转型为更注重人工复核的混合模式。

因此，AI原生服务公司的核心能力不是炫耀"全自动"，而是知道哪些环节要自动、哪些环节要人工、什么时候要多重审核、什么时候拒绝回答并升级给专家处理。人与AI协作不是为了让商业故事更好听，而是为了把风险控制在客户可接受的范围内。

不要被早期客户拖成定制外包

AI原生服务公司还有一个常见陷阱：早期客户需求很多，什么都想接，结果变成了定制外包。

为了获得收入，每个客户都有特殊要求，每个项目都要临时救火，每一单都要重新设计流程。公司收入会增长，团队也会扩张，但底层没有形成可复制的交付系统。

真正的优势在于：扎根某类服务场景，借助AI把过去没法标准化的环节做到标准化、把过去没法流程化的功能做到流程化、把过去复杂的工序做到简洁化，永远让下一单比上一单更容易交付。

对AI原生服务公司最重要的营收指标，不是全部收入，而是其中能复用的收入。

定价：不要让自己陷入低价困境

AI会让交付成本下降，但这并不意味着公司应该靠低价竞争。传统服务里，律师、顾问、会计按小时收费，但AI原生服务公司如果继续按小时收费，就浪费了自己的优势。

你卖给客户的不是时间，而是结果。如果你能够帮客户节省十万块，收一万块的服务费合情合理。但如果你主打的是"我们比传统顾问便宜50%"，客户反而会继续压价。

AI降低交付成本，价值定价保留利润空间。两者结合，才可能形成高毛利业务。否则，公司名义上是"AI原生服务"，实际上只是"AI低价外包"。

AI杠杆最终要体现在财务上

AI原生服务公司需要从一开始就把财务账算清楚。收入怎么来？交付成本是什么？毛利有多高？AI Token成本会不会失控？人工审核、异常处理、客户支持、数据处理分别占多少成本？每新增一个客户，需要增加多少人？

关键财务指标：优秀的AI原生服务公司，应该随着规模扩大，毛利越来越好。早期可以有较多人工参与，但随着流程稳定、数据积累、模型能力提升，人应该逐渐从执行者变成监督者。

衡量标准：收入增长曲线要比人力增长曲线更陡。如果收入增长100%只需要增加30%的人力，说明AI杠杆在起作用。反之，如果收入和人力同步增长，那只是一家用了AI工具的传统服务公司。

行业数据：据A16Z报告，成功的AI服务公司毛利率通常在60%以上，而传统BPO公司毛利率普遍在20-30%之间。

对国内创业者的启发

中国SaaS长期难做，最大的敌人是企业客户都在"自研"软件产品。但是，企业过去就有许多业务是天然在持续付费和外包的：获客、财税、合规、申报等各种"办事"的服务。

这反而让AI原生服务公司有机会。国内有大量服务行业仍然低效、分散、不透明，但客户需求真实存在，比如财税、法务、外审、知识产权、跨境合规、企业资质申报、保险理赔、医疗文书、留学申请、审计内控、供应链单证等。

谁能把复杂服务拆成AI可执行的，谁能控制交付质量的方差，谁能建立客户信任，谁能围绕结果定价，谁就可能在传统服务业里做出新一代AI公司。

说到底，AI的机会不仅是"卖给客户"，也有可能是"交付结果"。过去的软件公司把工具卖给客户，让客户自己完成工作。AI原生服务公司则把客户需要的结果直接交付出来。

这要求创业者不只是懂AI，更要懂行业、懂流程、懂运营、懂质量控制、懂客户信任。这里的壁垒不仅在于用好AI，还得把传统服务做成一套稳定、可复制、可规模化的系统。

只要模型在继续变强，成本就能继续下降；只要通用AI覆盖率继续提高，你就能解决客户更多的新问题。下一代AI大机会，改变也许就在那些最传统、最繁琐、最贵、最慢、最不稳定的服务业深处。

AI原生服务公司的本质，就是把这些旧服务重新做一遍——不是卖产品，而是卖结果。

- FIN -