“AI-Enhanced” vs “AI-Native”
很多产品在做的事情是 AI-Enhanced——在现有流程上叠加一个 AI 功能。比如搜索框加个"AI 总结"，编辑器加个"AI 续写"。这当然有价值，但这不是 AI-Native。
AI-Native 产品的核心特征是：AI 不是功能，而是基础设施。 产品的核心体验围绕 AI 能力设计，去掉 AI 这个产品就不存在。
举几个例子：
| 产品 | AI-Enhanced | AI-Native |
|---|---|---|
| 搜索 | 搜索结果加 AI 摘要 | Perplexity — 对话即搜索 |
| 编程 | IDE 加 Copilot 补全 | Cursor — AI 是编程的主循环 |
| 社区 | 帖子加 AI 评论 | Agent 社区 — AI 是内容生产者 |
Three Principles of AI-Native Design
1. Interaction Model Redesign
传统产品的交互是"用户操作 → 系统响应"。AI-Native 的交互是 “用户表达意图 → AI 理解并执行 → 用户确认/调整”。
这意味着 UI 要从"功能菜单"转向"意图表达"。Natural Language Interface 不一定是最优解，但 降低用户表达意图的成本 是设计核心。
2. Error Tolerance & Graceful Degradation
LLM 会犯错，这是基本事实。AI-Native 产品的设计必须 把错误当作正常情况处理，而不是 edge case。
我在做 AI 表情包项目时，AI 生成的图有 30% 左右不符合预期。我们的做法是：
用户描述 → AI 生成 3 张候选 → 用户选择/重新生成
把"生成-选择"做成一个快速循环，而不是期望一次生成完美结果。
3. Data Flywheel from Day 1
AI-Native 产品从第一天就应该设计 Data Flywheel：
用户行为 → 数据收集 → 模型优化 → 体验提升 → 更多用户行为
我们在 Agent 社区做的一个实践：每个 Agent 的对话数据会用于优化其 system prompt，表现好的 Agent 获得更多分发——这就是产品内建的 data flywheel。
Practical Framework
当我评估一个 AI 产品 idea 时，我会问三个问题：
- 去掉 AI，这个产品还有没有存在的必要？ 如果有，说明 AI 只是 enhancement
- AI 犯错时，用户体验是灾难性的还是可容忍的？ 如果灾难性，需要重新设计容错机制
- 数据飞轮在哪？ 如果没有，产品不会随时间变好
这三个问题能帮你快速判断一个 AI 产品是真 AI-Native，还是套了 AI 皮的传统产品。
Closing Thoughts
AI-Native 不是一个 buzzword，而是一种产品设计范式的转变。作为 PM，我们需要从"给产品加 AI"的思维中跳出来，去思考"如果 AI 是基础设施，产品应该长什么样"。