AI 进化的三阶段与拟物化陷阱

标题: 系统的融化 - 拟物化陷阱、AI Native 与液态商业来源: https://chennative.ai/zh/skeuomorphism-trap-ai-native-liquid-business 作者: 陈天桥 (Chen Tianqiao) - chennative.ai 收集日期: 2026-03-12

核心隐喻：更快的马车 vs 内燃机

如果在 19 世纪末问一个马车夫，他最需要什么，他几乎一定会说：我要一匹更快的马。他不会说：我需要一个内燃机。

—— 亨利·福特

拟物化陷阱：

不是用新技术创造真正的新东西
而是去模仿旧世界已经存在的形状
给马车装上内燃机 = 更快的马车，不是汽车

AI 时代的拟物化：

❌ 旧流程 + AI 插件 = 新流程（加法逻辑）
✅ 从第一性原理重新设计（乘法逻辑）

AI 进化的三个阶段

第一阶段：AI Enable（加法逻辑）

底层逻辑：

旧流程 + AI 插件 = "新流程"

权力结构：

人 = CPU（中央处理器）
AI = 外接 GPU（更强的加速器）
人的角色：逻辑判断、串流程、经验传承

问题：

协调成本成倍上升
摩擦成本增加
没有乘法效应

三重门槛（尚未完全走完）：

门槛	从	到	实质
1. 从概率拟合到逻辑推理	System 1	System 2	从”看起来很懂” → “真的会想”
2. 从文本对话到工具行动	对话框	接手键盘鼠标	从”顾问” → “自动执行体”
3. 从无状态到长期记忆	人的记忆	系统的记忆	从”记忆载体” → “记忆结构设计者”

判断标准：如果把 AI 拿掉，业务是**“变慢了”还是”不存在了”**？

变慢了 → Enable
不存在了 → Native

第二阶段：AI Native（乘法逻辑与液态商业）

AI Native（AI 原生）定义：

从一开始就把 AI 当成核心能力来设计的产品、团队或公司，而不是在传统系统上”后加一个 AI 功能”。

核心特征：

产品或公司逻辑本身由 AI 驱动
自动理解需求、生成内容、执行任务、持续优化
AI 是 CPU，人类做策略和例外管理

临界点：

"人是 CPU" → "AI 是 CPU，人只在上层做策略与例外管理"

从第一性原理出发：

流程为 AI 而设计
组织为 AI 而设计
产品为 AI 而设计

液态商业的特征：

数据、人才、资源像水一样流动
随需聚合，随需分流
厚重的组织骨架被数据流和 Agent 流程取代

三个审视问题：

1. 存亡问题

如果把 AI 拿掉，你的业务是”变慢了”，还是”不存在了”？

残酷的标准：

变慢了 = Enable（只是加速）
不存在了 = Native（本质改变）

2. 流转问题

在你的业务链条里，谁是那个”传球”的人？

真正的 Native：

不仅让 AI 干活
更让 AI 之间直接”握手”
AI-to-Agent 的协作

3. 记忆问题

你的系统是在”消耗”数据，还是在”吞噬”经验？

护城河的终极拷问：

❌ 消耗数据 = 用 AI 搬砖，没有壁垒
✅ 吞噬经验 = 把人类的”痛苦”转化为机器的”直觉”

第三阶段：AI Awaken（终局边界与文明级问题）

从 Native 到 Awaken：

Native: 人类定义工作，AI 执行
Awaken: AI 开始定义工作

三个质变：

维度	Native 阶段	Awaken 阶段
发现	在已知地图里把路走对	闯入无人区，发现人类未见过的规律
问题	给出标准答案	质疑问题本身，提出新假设
目标	逼近目标函数	重写奖励函数

终极拷问：

当”正确”可以被计算，“决策”可以被外包，这个世界上究竟还剩下什么东西，是必须由我——一个会犯错、会衰老、会痛苦的碳基生命——亲自来完成的？

残酷的答案：为了赢，为了突破文明的存量瓶颈，我们终将亲手按下那个觉醒的按钮。

补充洞察：AI SaaS 的真正危机

来源: 产品研究者的观察与补充

传统 AI SaaS 的商业模式

AI SaaS = 卖 SaaS + 批发 token

盈利模式：

订阅费：$100/月
成本：LLM API 调用
Margin: ~90%

问题：

不是 AI-native
只是”传统 SaaS + LLM 包装”
定制化程度低

真正的危机：本地化 Agent

场景：如果 OpenAI/Claude 推出本地化 Agent（如 Claude Code）：

用户可以：

花费 1 小时搭建
一次性消耗 $10-500 的 token
获得前端 + 后端 + local storage
完全定制化

成本对比：

方案	初始成本	持续成本	定制化
传统 AI SaaS	$0	$100/月	低（通用模板）
本地 Agent	1小时 + $10-500	仅 LLM token（省90%）	高（完全定制）

本地方案的缺点：

❌ 不专业
❌ 不安全
❌ 不稳定
❌ 没有边界
❌ 不能维护
❌ 容易 crash
❌ 敏感数据可能被攻击者 dump

但是：

✅ 大部分用户不需要那么高的专业/安全标准
✅ 很多人只是”尝尝咸淡，用完就扔”
✅ 改变了 SaaS 和软件的逻辑

AI SaaS 的生存之道

必须做到：

极致专业 - 本地 Agent 做不到的深度
极致漂亮 - 用户体验的差异化
极致高效 - 时间/成本的显著优势

残酷的现实：

以绝大多数当今 AI SaaS 员工们自己用 Claude Code 瞎几把糊出来的产品来看，还真没有多大的优势。

与 @pontusab 观点的对照

Pontus Abrahamsson：从 UI/UX 角度

核心观点：

SaaS 不是死了，是你的 UI 死了
从 app-first → assistant-first
护城河从 UI → Backend/Domain Model

关注点：

产品设计
架构转型
First-class Client vs Plugin

陈天桥：从进化阶段角度

核心观点：

拟物化陷阱（更快的马车）
三阶段进化（Enable → Native → Awaken）
液态商业

关注点：

组织变革
商业模式
文明级问题

两者结合

维度	@pontusab	陈天桥	产品研究者补充
产品	Assistant-first	AI Native	极致专业/漂亮/高效
架构	4 层模型	液态组织	本地 vs 云端
商业模式	Plugin vs First-class Client	Enable vs Native	SaaS 订阅 vs Token 成本
护城河	Domain Model	吞噬经验	专业化 vs 定制化

产品判断框架（更新版）

维度 1: 是否是 Native？

三个问题：

存亡测试
- ❌ 把 AI 拿掉，业务变慢了 = Enable
- ✅ 把 AI 拿掉，业务不存在了 = Native
流转测试
- ❌ 还需要人类”传球” = Enable
- ✅ AI 之间直接”握手” = Native
记忆测试
- ❌ 消耗数据，用 AI 搬砖 = Enable
- ✅ 吞噬经验，建立壁垒 = Native

维度 2: 护城河在哪里？

旧护城河（正在失效）：

更好的 UI
更流畅的 onboarding
更少的工作流步骤

新护城河：

Domain Model（@pontusab）
吞噬经验的能力（陈天桥）
极致的专业化（产品研究者）

维度 3: 能否抵御本地 Agent？

三个极致：

极致专业 - 本地做不到的深度
极致漂亮 - 用户体验的差异化
极致高效 - 时间/成本的显著优势

反面教材：

拖拽式 AI workflow
通用 chatbot
基础 AI 辅助
任何”用 Claude Code 1小时能搭出来的东西”

市场预测

短期（1-2 年）

会发生的：

大量”更快的马车”类 AI SaaS 死亡
本地化工具（如 Claude Code）普及
用户意识到”我可以自己搭建”

不会发生的：

所有 SaaS 都变成 Native
本地 Agent 完全替代专业 SaaS

中期（3-5 年）

分化加剧：

专业 SaaS（Native）- 生存并壮大
- 极致专业、漂亮、高效
- 本地 Agent 做不到
通用 SaaS（Enable）- 死亡或被 commoditize
- 本地 Agent 可以替代
- 变成 Plugin
本地工具 - 成为新的基础设施
- Claude Code、Replit 等
- 个人定制化解决方案

长期（5-10 年）

终局：

大部分”工作”由 AI 完成
人类退到策略和例外管理
触碰 Awaken 的边界问题

对创业者的建议

如果你要做 AI SaaS

必答题：

你的产品是 Enable 还是 Native？
把 AI 拿掉，你的业务还存在吗？
你的护城河是 UI 还是 Domain Model？
用户能用 Claude Code 在 1 小时内搭出替代品吗？
你做到了”三个极致”吗？

如果是”Yes”（Native），继续。如果是”No”，重新思考。

避免拟物化陷阱

不要做：

❌ 旧流程 + AI 插件
❌ 传统 SaaS + LLM 包装
❌ “更快的马车”

要做：

✅ 从第一性原理出发
✅ 为 AI 而设计的流程/组织/产品
✅ 真正的 AI Native

建立真正的护城河

从 UI 护城河转移到：

Domain Model（@pontusab）
吞噬经验（陈天桥）
专业化深度（产品研究者）

对投资者的建议

评估框架更新

三个新问题：

Enable vs Native
- 把 AI 拿掉，业务还存在吗？
Plugin vs First-class Client
- 会成为别人的 Plugin 吗？
抵御本地 Agent
- 能否抵御 Claude Code 类工具的替代？

避免投资：

❌ “更快的马车”类项目
❌ 通用 workflow 工具
❌ 没有专业深度的 chatbot
❌ 任何”用户能自己搭出来的东西”

寻找：

✅ 真正的 AI Native
✅ 有 Domain Model 护城河
✅ 能吞噬经验建立壁垒
✅ 极致专业/漂亮/高效

待验证假设

高置信度 ✅

“更快的马车”类 AI SaaS 会大量死亡
本地化工具会普及
Enable → Native 是必然趋势

中等置信度 ⚠️

三个极致的必要性
- 是否所有 SaaS 都需要做到极致？
- 有些品类可能”足够好”就够了
Native 的边界
- 什么样的产品才算 Native？
- 有没有明确的判断标准？

低置信度 ❓

Awaken 阶段的时间和形态
- 什么时候会触碰 Awaken？
- 社会会如何应对？
本地 vs 云端的平衡
- 隐私需求 vs 便利需求
- 监管会推动哪一方？

行动清单

对于产品研究者

分析框架更新：

用”三个问题”评估 AI SaaS
识别 Enable vs Native
追踪”拟物化陷阱”的案例
研究本地 Agent 对 SaaS 的替代

案例收集：

Native 案例：真正 AI Native 的产品
Enable 反面教材：只是加速旧流程
本地替代案例：Claude Code 搭建的解决方案

对于创业者

立即执行：

评估自己的产品：Enable vs Native
测试：用户能用本地工具替代吗？
审计：护城河在哪里？
规划：如何做到”三个极致”？

战略规划：

避免”更快的马车”陷阱
从第一性原理重新设计
建立真正的护城河

对于投资者

评估框架：

用”三问题”筛选项目
识别”拟物化陷阱”
避免”马车”类投资

重点关注：

真正的 AI Native
有吞噬经验能力的系统
极致专业化的 SaaS

Product Hunter

探索

2026-03-12 - AI进化的三阶段与拟物化陷阱 - 陈天桥