AI Native vs +AI：怎么判断该怎么做

先判断「该不该用 AI」见如何判断一个业务问题是否适合用 AI；真伪需求过滤见如何判断一个 AI 需求是真需求还是伪需求。

本文不重复四维评估与真伪清单，只回答：已经确认要用 AI 之后，做成 AI Native，还是做成 +AI。

一句话

•

AI Native 把 AI 当作价值引擎与架构前提——拿掉 AI，产品不再成立；

•

+AI（业界常称 AI-powered / AI-enhanced）是在既有产品上叠加智能能力——拿掉 AI，主流程仍可跑，只是少一层增益。

选错方向的浪费最大：把锦上添花做成从零重构，或把本该重构的体验压成侧边栏聊天框。

一、先对齐术语（不是营销标签）

公开讨论里，「AI native」常被当成 buzzword。可核验的区分更接近架构依赖，而不是功能清单里有没有大模型按钮。

#OphPqefegBhR text { white-space: pre; }#OphPqefegBhR .fb0 { stroke: var(--N900-FG, 0.15); }#OphPqefegBhR .fb0 {stroke: rgba(31,35,41, 0.15)}#OphPqefegBhR .fx0 { stroke-miterlimit: 10; }#OphPqefegBhR .fx0 {stroke-miterlimit: 10}#OphPqefegBhR .fa1 { fill: rgb(187, 191, 196); }#OphPqefegBhR .fa1 {fill: rgb(187, 191, 196)}#OphPqefegBhR .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#OphPqefegBhR .fx1 {font-style: normal}#OphPqefegBhR .fx2 { text-anchor: middle; }#OphPqefegBhR .fx2 {text-anchor: middle}#OphPqefegBhR .fx3 { dominant-baseline: central; }#OphPqefegBhR .fx3 {dominant-baseline: central}#OphPqefegBhR .fx4 { stroke: none; }#OphPqefegBhR .fx4 {stroke: none}#OphPqefegBhR .fc0 { fill: var(--text-caption); }#OphPqefegBhR .fc0 {fill: #646a73}#OphPqefegBhR .fa2 { fill: var(--text-link-disabled); }#OphPqefegBhR .fa2 {fill: rgb(187, 191, 196)}#OphPqefegBhR .fa3 { fill: rgb(225, 234, 255); }#OphPqefegBhR .fa3 {fill: rgb(225, 234, 255)}#OphPqefegBhR .fx5 { font: 700 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#OphPqefegBhR .fx5 {font-style: normal}#OphPqefegBhR .fx6 { text-anchor: start; }#OphPqefegBhR .fx6 {text-anchor: start}#OphPqefegBhR .fx7 { dominant-baseline: alphabetic; }#OphPqefegBhR .fx7 {dominant-baseline: alphabetic}#OphPqefegBhR .fc1 { fill: rgb(0, 0, 0); }#OphPqefegBhR .fc1 {fill: rgb(0, 0, 0)}#OphPqefegBhR .fx8 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#OphPqefegBhR .fx8 {font-style: normal}#OphPqefegBhR .fb1 { fill: var(--N900-FG, 0.15); }#OphPqefegBhR .fb1 {fill: rgba(31,35,41, 0.15)}#OphPqefegBhR .fb2 { fill: rgb(209, 217, 224); }#OphPqefegBhR .fb2 {fill: rgb(209, 217, 224)}#OphPqefegBhR .fa4 { fill: var(--bg-body); }#OphPqefegBhR .fa4 {fill: #fff}ABC123456维度AI NativeAI（AI-powered / AI-enhanced）价值假设「拿掉 AI」测试UX 重心数据与闭环投入形态没有生成 / 推理 / 编排，核心任务完不成产品塌成另一类东西，或几乎不可用工作流围绕意图、结果与人机协作重做交互、反馈、评测从第一天就是一等公民技术栈、评估、治理、成本一起从零搭核心任务本就可完成；AI 提效、提质、降本产品仍是原来的产品，体验变差一点在现有菜单 / 文档 / 工单上挂助手、摘要、推荐可先复用现有日志；闭环可后补，但上限更低复用现网架构，增量接入模型 / RAG / 工具

建议：对内评审时不要争论「我们算不算 AI Native 公司」

改问：这个需求的主路径，是否必须以模型能力为前提？

常见误读：

•

「用了 GPT 就是 Native」→ 侧边栏粘贴式助手多半是 +AI。

•

「老产品永远不能 Native」→ 可以做 Native 楔子（一条新旅程从零按 Native 做），不必一夜重写全站。

•

「Native = 多 Agent」→ Agent 是实现手段；先定价值依赖，再定是否 Agent（见何时不该上多 Agent）。

二、决策流：拿到需求后怎么走

前置闸门（本文不展开）：若「适合用 AI / 真需求」未过，停在规则、搜索、人工+模板，不要进入本决策流。

代码块

Plain Text

收到「要做 AI」的需求

│

▼

[0] 适合用 AI？真需求？ ──否──► 不做 AI / 换手段

│是（链 when-to-use-ai / real-vs-fake）

▼

[1] 拿掉 AI，核心用户任务还成立吗？

│

├─否（价值塌掉）──────────────────────────► 倾向 AI Native

│ │

│ ▼

│ [2a] 团队能否在可接受周期内

节点说明（给 PRD / 评审用）

[1] 拿掉 AI 测试——只问主路径，不看营销页。

#MneIOSOpHAct text{white-space:pre}.fb0{stroke:var(--N900-FG, 0.15)}.fx0{stroke-miterlimit:10}.fa1{fill:#bbbfc4}.fx1{font:normal 400 12px MonospacedNumber,LarkHackSafariFont,LarkEmojiFont,LarkChineseQuote,-apple-system,BlinkMacSystemFont,Helvetica Neue,Tahoma,PingFang SC,Microsoft Yahei,Arial,Hiragino Sans GB,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji}.fx2{text-anchor:middle}.fx3{dominant-baseline:central}.fx4{stroke:none}.fc0{fill:var(--text-caption)}.fa2{fill:var(--text-link-disabled)}.fx5{font:400 normal 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"}.fx6{text-anchor:start}.fx7{dominant-baseline:alphabetic}.fc1{fill:rgb(31, 35, 40)}.fb1{fill:var(--N900-FG, 0.15)}.fb2{fill:rgb(209, 217, 224)}.fa3{fill:var(--bg-body)}AB1234信号更像 Native用户付费点是「生成 / 推理 / 代办完」本身无模型则无法交付承诺结果UX 必须按不确定输出重做（确认、撤销、进度）信号更像 +AI用户付费点是文档、交易、协作、内容分发等既有能力无模型仍可点选、填写、搜索完成任务在现有页面加入口即可，失败可静默降级

[2a] Native 的能力门槛——不是「会不会调 API」，而是生产化闭环是否齐：效果定义与评测、数据回流、成本上限、失败兜底。写进 PRD 的方式见 AI 产品 PRD 怎么写；交互侧见兜底、反馈与预期管理。

[2b] +AI 的增益门槛——相对非 AI 基线要能量化：任务完成率、单位任务成本、人工介入率、留存。增益说不清，多半是「为 AI 而 AI」回流到真伪需求题。

两条错误路径（优先避免）

把 +AI 做成 Native：全量重做信息架构与技术栈，最后只换了摘要按钮——投入巨大、体验无感。

把 Native 做成 +AI：真正依赖生成与编排的新产品，却塞进旧菜单侧栏，上下文割裂、价值被埋没（用户每轮都要重新「解释工作」）。

三、选型对照：投入、风险、演进

#iIvTqVwdTFwq text{white-space:pre}.fb0{stroke:var(--N900-FG, 0.15)}.fx0{stroke-miterlimit:10}.fa1{fill:#bbbfc4}.fx1{font:normal 400 12px MonospacedNumber,LarkHackSafariFont,LarkEmojiFont,LarkChineseQuote,-apple-system,BlinkMacSystemFont,Helvetica Neue,Tahoma,PingFang SC,Microsoft Yahei,Arial,Hiragino Sans GB,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji}.fx2{text-anchor:middle}.fx3{dominant-baseline:central}.fx4{stroke:none}.fc0{fill:var(--text-caption)}.fa2{fill:var(--text-link-disabled)}.fx5{font:400 normal 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"}.fx6{text-anchor:start}.fx7{dominant-baseline:alphabetic}.fc1{fill:rgb(31, 35, 40)}.fb1{fill:var(--N900-FG, 0.15)}.fb2{fill:rgb(209, 217, 224)}.fa3{fill:var(--bg-body)}ABC12345问题第一期范围成功标准主要风险常见演进选 AI Native 时一条可闭环的核心旅程，而不是「全站智能化」无 AI 则任务失败率不可接受；完成率 / 采纳率相对「不可能用手搓」的基线成本与质量波动、治理与预期管理跟不上Native 楔子做厚 → 吞并相邻流程选 +AI 时单个高频入口 + 可降级路径相对现网基线的增量（如起草时间、点击率、人效）入口隐蔽、上下文不足、变成摆设功能+AI 验证价值 → 再决定是否重构为 Native 旅程

组织现实：多数存量产品应默认从 +AI 起步；仅当新产品或战略楔子的价值机制本身依赖模型时，才按 Native 立项。Product School 亦强调用 1–2 条 wedge 推进，而不是公司级口号式「全面 Native」

四、落到 PRD 的三句话

无论走哪条支路，立项文档至少写清：

依赖声明：主路径是否假设模型可用；不可用时的降级是什么。

路线标签：本需求按 Native / +AI / 「Native 楔子」哪一种验收，避免口头都叫「AI 重构」。

Kill 标准：Native 写清评测与成本红线；+AI 写清相对基线无增益则下线或收口。

小结

先过「该不该 AI」，再用「拿掉 AI 是否塌掉」分 Native 与 +AI；Native 看闭环能力是否跟得上，+AI 看增益是否打得过基线。标签服务于资源分配，不服务于发稿口径。