《Clouded Judgement 式 AI 软件投研：指标表 × 收入瀑布 × 终端价值重估》

本节学什么

本节只讲经营指标阅读。Jamin 的核心习惯是：收入增速从来不是单独结论，必须和毛利、运营利润率、FCF、NDR、销售效率、研发投入、G&A、CAC 回收期和非 GAAP 脚注放在一起读。软件公司最容易用漂亮增长遮蔽质量问题，也最容易用自定义指标制造不可比。

核心框架

第一看增长质量。NTM 收入增速是自然扩张、价格上涨、会计口径变化，还是疫情后递延需求？第二看毛利和 FCF。AI 功能可能拉高收入，也可能因为推理成本和云成本压毛利；裁员可能短期拉高 FCF，却牺牲研发和销售管线。第三看 NDR 和 ARR 脚注。NDR 的定义是否包含价格、seat、usage、流失客户？ARR 是否包含服务收入、一次性项目或非 recurring 合同？第四看 CAC payback。GM-adjusted CAC payback 改善，才说明获客效率变好；如果只是削销售团队，后续增长可能受损。

他怎么用

Jamin 的深研里有一句很典型：管理层叙事可以很美，最后要回到分桶倍数、净新增 ARR、GM-adjusted CAC payback、NDR 脚注。2024 年初，他曾倾向认为利率顺风和增长恢复会支持 SaaS，但公有 SaaS 中位增速没有明显再加速。这个例子说明，仅靠“利率下行 + AI 功能发布”不能推出软件整体复苏；必须看续约、净新增、销售效率和 FCF 是否真的改善。

常见误区

误区一：把 Rule of 40 当总分。Rule of 40 是增长和利润的合成，必须拆成来源。一个公司 20% 增长 + 20% FCF，和 5% 增长 + 35% 短期削成本，质量完全不同。误区二：把 NDR 横向比较。不同公司定义不同，脚注不读就不可比。误区三：把 AI ARR 当真实 ARR。许多 AI 收入口径可能是管理层口径、usage annualized、预期 run-rate 或包含多类产品。误区四：只看非 GAAP。股权激励、资本化软件、重组费用和推理成本都会影响真实经济性。

可迁移步骤

读任何 SaaS 财报，先做四张小表：增长桥、毛利/FCF 桥、留存/ARR 口径表、销售效率表。每张表写清数据来源和定义。然后问三件事：增长是客户更多、价格更高、用量更大，还是会计口径？利润是经营杠杆，还是成本延后？AI 功能带来的是新收入、保留旧收入，还是增加成本？

小结

Jamin 的指标阅读不是为了把研究变复杂，而是为了防止被单一增长故事带走。收入增速是入口，单位经济性和脚注才是判断质量的核心。脚注读得越细，越能看出管理层故事和真实经营之间的距离。

本节学什么

本节只讲 AI 收入瀑布。Jamin 的问题不是“AI 是不是重要”，而是“AI 收入先在哪一层、以什么口径、通过什么产品兑现”。这个框架专门用来抵抗从模型能力直接跳到应用胜利的错误。

核心框架

AI 收入瀑布有三层。第一层是 hyperscaler：Azure、AWS、GCP 把模型训练、推理、API、数据存储和企业云需求转成增量收入。这里看 AI 贡献点数、云增长率、capex、云毛利和供需缺口。第二层是数据/基础设施：Snowflake、Databricks、ClickHouse、dbt、数据治理、语义层、向量检索、observability 和开发工具，承接企业把数据变成 AI-ready 的工作。第三层才是应用软件：CRM、ServiceNow、Atlassian、Zendesk、Office、coding tool、agent 产品是否把 AI 功能变成留存、ARPU、usage 或 outcome 收入。

他怎么用

深研明确写到，他先看 AWS/Azure/GCP 是否把 AI 变成增量收入，再看数据平台、基础设施软件、应用软件是否获得同样经济收益。这就是为什么他的 AI 判断不只盯应用 demo。比如 Azure 增长和 AI 贡献点数能证明第一层兑现；Snowflake 或 Databricks 捕获更多 AI workload，证明数据控制平面有价值；但一个 SaaS 厂商如果只是发布 copilot，却没有披露用量、付费、留存或定价变化，就仍处在瀑布下游的不确定阶段。

常见误区

误区一：把 AI 使用量等同收入。使用量增加可能发生在免费层、试用层或高成本补贴层。误区二：把云厂收入等同应用收入。云厂先赚钱，不代表应用层已经拥有毛利和定价权。误区三：忽略毛利。AI 收入如果由高推理成本换来，短期可能压 FCF。误区四：把数据平台当可选项。企业 AI 生产化需要权限、审计、语义和治理，数据层经常是应用落地的前置条件。

可迁移步骤

研究任何 AI 公司，先标明它在瀑布哪一层。若是云厂，看增长、capex、毛利和 AI 贡献。若是数据平台，看 AI workload、消费式收入、治理功能和客户扩展。若是应用软件，看付费席位、usage/outcome 收入、续约、ARPU 和推理成本。然后写出上一层和下一层的依赖：应用依赖数据，数据依赖云，云依赖 GPU/电力/资本开支。

小结

AI 不是一场所有公司同时兑现的雨，而是一条有先后顺序的收入瀑布。Jamin 的框架让研究者先追钱流，再谈故事。

本节学什么

本节只讲定价迁移。Jamin 对 AI 软件最有穿透力的转译之一，是把“AI 用更少人做更多事”翻译成传统 SaaS per-seat 定价的结构性矛盾。许多讨论停在“AI 提升生产力”，但他会继续问：如果生产力提升意味着客户需要更少 seat，靠 seat 收费的软件公司如何保住收入？

核心框架

传统 SaaS 的收入基础是席位数、续约率、上售和价格提升。AI 改变了这个基础：一个 agent 可以替代多个操作员，一个开发者配合 coding assistant 可以完成更多工作，一个客服系统可以减少人工 seat。若厂商仍只按人头收费，客户从 AI 中获得的价值未必流向厂商。因此定价需要从 per-seat 迁移到 per-seat + usage，再逐步探索 outcome。usage 捕获调用、自动化、工作流执行和数据处理；outcome 捕获解决了多少工单、生成了多少合格线索、节省了多少时间或带来多少业务结果。

他怎么用

深研列出微软、Salesforce、ServiceNow、Zendesk 等观察对象。Jamin 不是只看它们有没有 AI 功能，而是看收入 mix 是否迁移。Microsoft 365 Copilot 如果只卖 seat，就要证明企业愿意给每个员工付费；GitHub Copilot 或 agent 工具如果使用量越大成本越高，就要有 usage/value pricing 覆盖推理成本；Salesforce/ServiceNow 若想守住工作流前门，也要证明 agent 带来的结果可以变成付费，而不是免费功能防守。

常见误区

误区一：把 AI 功能发布当定价成功。功能可以提升留存，也可能只是竞争必需品。误区二：以为 usage 一定更好。usage 定价会带来客户预算不确定、成本波动和采购阻力。误区三：忽略毛利。推理成本、模型调用和云成本可能吃掉新增收入。误区四：认为 seat 会立刻消失。Jamin 并不说 seat 明天死亡，而是说 seat 需要和 usage/outcome 混合，否则长期结构有压力。

可迁移步骤

评估一家 SaaS 时，画一张定价表：当前收入来自 seat、usage、平台费、服务还是结果分成？AI 功能提升的是 seat 数、ARPU、留存、用量还是结果？客户如果减少人手，公司能否通过 usage 捕获价值？推理成本由谁承担？合同是否允许价格随用量变化？这些问题比“AI 功能很强”更接近利润表。

小结

seat→usage 不是一句商业模式口号，而是 AI 生产力承诺带来的收入结构重写。Jamin 的贡献，是把这件事提前放进可跟踪指标。

本节学什么

本节只讲 agent 前门和控制平面。Jamin 对存量 SaaS 的判断不是简单“软件死了”或“软件没死”，而是拆成两个层次：系统记录是否仍有价值，用户前门是否会被 agent 夺走。这个拆法能避免极端化。

核心框架

企业软件有两类资产。一类是前门：用户每天打开的 UI、工作流、仪表盘、输入页面和协作入口。另一类是底座：系统记录、数据定义、权限、审计、合规、工作流状态和可写事实源。Jamin 认为 vibe code 不能一夜复制复杂 SaaS，因为 SSO、RBAC、审计、合规、权限和运维很难复制；但 agent 可以改变用户入口。若用户让 agent 直接读写底层系统，原应用还在，却从前门变成中间件，扩张收入和用户心智都会受损。

他怎么用

他看 Salesforce、ServiceNow、Atlassian 能否把 agent 前门留在自己体系内，也看 Snowflake、Databricks、dbt、ClickHouse 等数据/语义/治理平台是否成为 agent 时代控制平面。深研中的关键判断是：AI 应用赢家会更像“数据库/控制平面公司”，不是传统应用 UI 公司。核心资产是数据定义、语义层、权限、策略和可写入事实源。没有这些资产、只拥有旧式 UI 的公司，才更接近“slowly melting ice cubes”。

观察信号

这一节最重要的信号不是发布了多少 agent，而是前门到底归谁。用户是在 Salesforce 内部调用 agent，还是在 Microsoft Teams、ChatGPT、浏览器或自建工作台里调用底层 CRM？工单是在 ServiceNow 体系内自动闭环，还是被外部 agent 直接写回？数据查询是在 Snowflake/Databricks 的治理边界内发生，还是绕到非受控副本？这些行为信号比发布会标题更能说明价值迁移。

常见误区

误区一：把前门风险理解成软件立刻归零。企业系统记录和合规流程很黏，合同不会瞬间消失。误区二：把系统记录黏性当永久护城河。系统还在，不代表用户入口、增量预算和定价权还在。误区三：把所有数据库公司都当赢家。控制平面要有治理、语义、权限、工作负载和生态，不是存数据就够。误区四：忽略业务 SaaS 的反击。Salesforce、ServiceNow、Microsoft 也会把 agent 嵌进自己的分发和权限体系。

可迁移步骤

分析一家软件公司，问五个问题：它是否掌握事实源？是否掌握权限和审计？agent 能否绕过它的 UI？如果绕过，收入是受损、持平还是转为 usage？它是否能成为 agent 的执行控制层，而不是被执行层调用？再写验证指标：AI agent 使用入口、API 写入量、workflow 自动化收入、客户续约和 ARPU。

小结

Jamin 的前门框架把“软件死没死”拆成可研究问题。系统记录可能长存，但前门、定价和增量价值会重新分配。

本节学什么

本节只讲 TAM。Jamin 的代表性表达是“TAM is a lagging indicator”。这不是说市场空间不重要，而是说平台迁移期，传统 TAM 表经常用旧世界的人群、价格和预算去测量新世界，因此滞后甚至误导。

核心框架

传统 SaaS TAM 常用“目标用户数 × seat 单价”。这在稳定市场有效，但 AI 改变两个变量。第一，新用户边界扩大。Cursor、Claude Code、AI agent 这类工具可能不只服务传统开发者，还服务销售、财务、运营、产品、客服和非技术员工，因为自然语言降低了软件能力门槛。第二，预算来源变化。价值可能不再是 20 美元/月工具费，而是生产力预算、外包预算、人力预算、云预算或业务结果预算。TAM 因此不是静态表，而是能力释放、预算迁移和新行为的函数。

他怎么用

深研把 Cursor/Claude Code 作为样本：新用户可能不是开发者，而是被 AI 赋能的非程序员；价值也不是传统开发工具订阅，而是生产力预算。Jamin 会看 AI 工具是否跨角色扩散，非技术用户是否贡献收入，ARPU 能否突破传统工具价格。如果使用仍集中在原专业人群，ARPU 不能突破旧工具费，TAM 扩张就要降级。

案例拆法

以 AI coding 工具为例，旧 TAM 是开发者人数乘以 IDE 或开发工具价格；新 TAM 可能包括产品经理写原型、运营人员生成脚本、财务人员自动化报表、销售人员配置工作流。可是这些新用户是否真的会付费，取决于组织权限、安全、代码质量、IT 审批和 ROI。Jamin 关心的不是“非程序员很多”这句口号，而是新用户是否形成 recurring revenue，以及预算是否从人力或外包迁移过来。

常见误区

误区一：所有 AI 工具都说 TAM 扩大。没有新用户行为和预算迁移，TAM 只是营销语言。误区二：把免费用户当市场空间。免费试用、开发者热度和社交传播不等于 recurring revenue。误区三：忽略替代预算。客户预算从哪里来必须写清，是旧软件、外包、人力、云、广告还是新增预算。误区四：只看上行，不写反证。平台迁移期 TAM 可以扩大，也可以因为客户不愿为 usage 付费而受限。

可迁移步骤

研究 AI 产品时，先写三张 TAM 表：旧 TAM、扩张 TAM、反证 TAM。旧 TAM 用传统用户和价格；扩张 TAM 写新用户、能力释放和预算迁移；反证 TAM 写使用集中、ARPU 天花板、成本压力和采购阻力。然后用实际数据验证：付费用户构成、净留存、用量、毛利、预算来源和客户案例。

小结

TAM 在平台迁移期最容易撒谎。Jamin 的方法不是拒绝大市场，而是要求每个大市场都能被新用户、新预算和收入质量证明。

本节学什么

本节只讲 Jamin 的元能力：在同一张表上同时看叙事与反叙事。AI 软件是最容易被故事污染的领域，市场往往在“应用爆发”和“软件死亡”之间摇摆。Jamin 的方法不是选一个口号，而是把正反都拆成指标。

核心框架

他的过滤器有三层。第一层，收入瀑布：AI 收入出现在云厂、数据 infra 还是应用？第二层，前门与系统记录：旧软件失去的是 UI 入口，还是底层事实源？第三层，定价迁移：seat 到 usage/outcome 时，谁能保住价值？每一层都同时有叙事和反叙事。推理成本通缩利好应用，但也降低自建门槛；系统记录没死，但被推下技术栈后扩张收入更难；TAM 会扩大，但 TAM 语言本身最容易撒谎；AI 云收入增长强，但 capex 和毛利可能承压。

他怎么用

2025 年他写“软件没死”，强调工作流黏性、维护负担和软件长半衰期；到 2026 年初，软件中位 NTM 倍数跌到十年低位，他用“Software is Dead…Again…For Real this time?”把问题升级到 AI 是否破坏软件终端价值。这不是简单反复，而是旧框架解释不了价格和新证据时升级框架。Jamin 的可贵处在于，他既保留软件系统复杂性的现实，也承认 agent 可能重估终端价值。

训练方法

这套过滤器可以刻意训练。每读一篇 AI 应用文章，先不判断对错，而是把它放进三栏：收入在哪一层、前门是否迁移、定价是否捕获价值。再给每栏写一条反证。例如“推理成本下降”对应反证是“客户自建更便宜”；“数据平台受益”对应反证是“应用绕过平台直接接模型”；“Copilot seat 增长”对应反证是“活跃使用和 ROI 不足”。只有正反都写出来，观点才有承压能力。

常见误区

误区一：把修正理解成摇摆。研究者不修正，才是更大问题。误区二：只写正方证据。AI 研究如果没有反证条件，最终会变成营销。误区三：把价格当全部证据。价格下跌需要解释，但不能只用价格倒推逻辑。误区四：把叙事与反叙事写成空泛辩证法。每个正反都要有指标：云增速、AI ARR、NDR、usage、毛利、capex、前门留存。

可迁移步骤

对每个 AI 判断写一张双栏卡。左栏写上行：成本下降、用量提升、TAM 扩大、定价迁移、控制平面价值。右栏写反证：自建门槛下降、客户不愿付费、推理成本压毛利、agent 绕过前门、估值已反映。每季度用数据更新，不让观点停在发布那天。

小结

Jamin 的“同表过滤器”是抵御故事污染的关键。先拆指标，再谈未来；同时持有叙事和反叙事，才可能在 AI 软件这种高噪声领域保持判断质量。