判断一个 AI 功能值不值得做：从炫技到用户价值

我砍掉了三个「很酷」的 AI 功能

上个季度，我在产品路线图里放了三个 AI 功能：智能摘要、自动标签、对话式搜索。Demo 演示的时候，团队都很兴奋。上线四周后看数据，智能摘要的周活不到 3%，自动标签的采纳率只有 11%，只有对话式搜索勉强留在核心流程里——但用户量也不到预期的三分之一。

问题不在模型。模型能力够用，输出质量也过了内部评审。问题在于，我在立项的时候没有认真回答一个前置问题：这个功能到底在帮用户完成一个他们本来就有的任务，还是我在替用户发明一个新任务？

这篇文章把我后来踩坑和补课积累的东西整理出来。核心就一件事——在写第一行 Prompt 之前，怎么判断一个 AI 功能值不值得做。

为什么 AI 功能特别容易做过头

传统功能做多了，最多是界面变复杂、代码变臃肿。AI 功能不一样，它附带持续的运营成本。每一次调用都有 Token 消耗、延迟、失败率和用户解释成本。Mixpanel 在 2026 年的 AI 产品指标报告里提到，北美 AI 产品的 DAU/MAU 中位数只有 21%，是全球最低的地区——用户量最大，但黏性最差（来源）。

这说明一件事：做出一个能跑的 AI 功能不难，让用户留下来很难。原因可以归到三类：

• 任务不真实：用户本来不需要这个能力，是 AI 让它看起来可以存在。
• 信任没建立：输出质量不够稳定，用户试了两次就不敢再用了。
• 成本没算清：每次调用的 Token 和延迟在 Demo 阶段看不出来，到了生产环境变成持续性负担。

Google Research 在 2026 年初发的一篇企业 AI 产品开发框架论文里总结得更直接：AI 项目失败，通常不是因为技术不行，而是因为战略没对齐（来源）。

四问判断法：立项前的最低限度检查

我后来把踩坑经验收拢成四个问题。这四个问题不需要精确答案，但如果你连方向都答不上来，功能就不该进核心流程。

问题一：用户原本就高频做这件事吗

这是最根本的一个。好的 AI 功能应该加速一个已经存在的工作流，而不是创造一个新工作流。

判断方法很简单：在没有这个 AI 功能之前，用户是怎么做的？如果答案是「他们不做这件事」或者「他们用自己的方式做得挺好的」，那 AI 介入后带来的增量就很有限。

问题二：AI 介入后，能明显减少时间、步骤或认知负担吗

有些任务看起来适合 AI，但人工做也不慢。比如给一篇 500 字的文章加标题，人工 10 秒能搞定，AI 哪怕做得稍好一点，用户感知到的价值差异也很小。

真正值得 AI 介入的场景，是那些人工做起来费时、费脑子或者容易出错的：长文档摘要、多源信息聚合、格式转换、模式识别。

问题三：用户能不能快速判断输出好坏

AI 输出本质上是概率性的。如果用户花 30 秒才能判断一条输出有没有用，那这个功能的使用摩擦就很高。反过来，如果用户一眼就能看出对错——比如翻译、分类、提取——那即使偶尔出错，用户也愿意用，因为纠正成本低。

危险场景是那些输出看起来对但实际错了的情况：事实错误、数值偏差、法律条款误引。用户没法快速验证，一旦出错就是信任崩塌。

问题四：团队是否有足够的数据或上下文，让模型比通用聊天更有优势

如果你的 AI 功能只是包了一层 ChatGPT API，没有注入任何业务数据或用户上下文，那用户自己用 ChatGPT 也能达到同样效果。你的壁垒在哪里？

壁垒可以来自私有数据、用户行为历史、领域特定 Prompt 工程，或者跟产品工作流的深度集成。如果这些都还没有，至少要有明确的获取路径。

经验法则：四个问题里如果有两个答不上来，功能更适合放进实验入口，而不是核心流程。

Triple Fit 框架：比四问更系统的评估

Product Voyagers 在 2025 年提出了一个叫 Triple Fit 的 AI 产品战略框架，从三个维度评估一个 AI 功能是否值得做（来源）：

这个框架给我的最大启发是「激励匹配」这一层。很多时候我们只考虑功能好不好用，忘了考虑用户愿不愿意用。一个帮审计师查欺诈的 AI 工具，如果让审计师觉得「它在证明我工作不到位」，就不会被采纳。反过来，把它定位成「帮你把检查做得更准的助手」，采纳率就上去了。

Triple Fit 框架建议用打分矩阵来评估：每个维度 1-5 分，至少要每个维度拿到 3 分以上，且有一个维度达到 5 分，才值得投入。

决策流程图

把四问判断法和 Triple Fit 框架结合起来，我整理了一个实际可用的决策流程：

三个真实案例

案例一：智能摘要——看起来对，实际上用户不需要

我做智能摘要的时候，假设是「用户没时间读长文，需要 AI 帮他们总结」。但实际上，我们产品的用户主要是内容创作者，他们读长文是工作内容的一部分，根本不存在「没时间读」的问题。我替用户发明了一个他们不需要的任务。

上线后四周，周活不到 3%。偶尔用一下的用户，大多是在测试功能，而不是真的需要摘要。

教训：四问里的第一个问题就没过。用户不高频做这件事。

案例二：自动标签——方向对，但信任没建立

自动标签是给用户上传的图片自动打分类标签。任务真实，用户确实每次都要手动选分类。AI 介入后也确实能省时间。

但问题出在第三个问题：用户没法快速验证标签是否准确。我们的分类体系有 200 多个标签，用户对其中一半都不熟悉。AI 打了一个标签，用户不知道对不对，只能自己重新选。结果就是，自动标签变成了一个「还要额外检查一遍」的负担。

采纳率 11%，修改率超过 60%。

教训：任务匹配，但输出验证成本太高。正确做法是先把标签体系收窄到 20 个高频标签，降低用户的验证负担。

案例三：对话式搜索——唯一活下来的功能

对话式搜索解决的是一个真实痛点：我们的内容库有上万条素材，传统的关键词搜索经常找不到用户想要的东西。用户需要一种更自然的方式来表达搜索意图。

这个功能能活下来，有几个原因：

• 任务真实：搜索是高频操作
• AI 介入后体验明显提升：自然语言比关键词灵活得多
• 输出可以快速验证：搜索结果好不好，用户看一眼就知道
• 我们有内容库的私有数据作为壁垒

即使这样，最初的版本也有问题——用户不知道对话式搜索和传统搜索有什么区别，很多人试了一次就回去了。后来我们在搜索框旁边加了一个「找不到？试试 AI 搜索」的引导，使用率才上来。

工程落地：MVP 前的验证闭环

判断完「值不值得做」之后，工程侧还需要一个小型验证闭环。AI 功能和传统功能不一样，传统功能上线后行为是确定的，AI 功能上线后行为是概率性的——你需要持续监控。

必须跟踪的指标

Mixpanel 的建议是按三个层次组织指标：用户采纳与参与度、模型运行质量、商业影响。不同类型的团队优先级不同——AI 原生团队从模型质量指标入手，传统产品团队从采纳指标入手（来源）。

Prompt 版本管理

很多人把 Prompt 当配置文件随手改，出了问题回头一看，不知道哪次改动导致了指标波动。我的做法是给 Prompt 加版本号，跟代码一样进 Git：

# ❌ 错误做法：Prompt 散落在代码里，随手改
SYSTEM_PROMPT = "你是一个助手，帮用户总结文章内容。"
 
# 后来觉得不够好，随手改了一句
SYSTEM_PROMPT = "你是一个专业助手，帮用户总结文章内容，要求简洁准确。"
 
# 指标波动了，不知道是哪次改动引起的

# ✅ 正确做法：Prompt 有版本号，可追溯
# prompts/summarize/v1.0.yaml
version: "1.0"
model: "gpt-4o-mini"
system: |
  你是一个内容摘要助手。
  根据用户提供的文章，生成 3-5 句话的摘要。
  要求：
  - 保留核心观点和关键数据
  - 不添加主观评价
  - 使用与原文相同的语言
temperature: 0.3
max_tokens: 500

# prompts/summarize/v1.1.yaml
version: "1.1"
model: "gpt-4o-mini"
system: |
  你是一个内容摘要助手。
  根据用户提供的文章，生成 3-5 句话的摘要。
  要求：
  - 保留核心观点和关键数据
  - 不添加主观评价
  - 使用与原文相同的语言
  - 如果文章包含数据或统计，优先保留
temperature: 0.3
max_tokens: 500
# 变更说明：v1.1 新增数据保留优先级，因为 v1.0 反馈
# 摘要经常遗漏关键数字。

失败样本标签

AI 功能一定会产生失败样本。关键是把这些失败分类，才能判断是「用户不需要」还是「实现质量不够」。

// ❌ 错误做法：只记录成功/失败
{
  "task_id": "abc123",
  "success": false
}
// 知道失败了，但不知道为什么，无法改进

// ✅ 正确做法：给失败打标签
{
  "task_id": "abc123",
  "success": false,
  "failure_type": "context_insufficient",
  "failure_detail": "用户输入的文档只有标题没有正文，模型无法生成摘要",
  "model_version": "1.0",
  "token_cost": 0,
  "latency_ms": 120,
  "user_action": "abandoned"
}
// 失败类型枚举：
// context_insufficient - 输入信息不够
// format_error - 输出格式不符合预期
// factual_error - 事实错误
// intent_unclear - 用户意图不明确
// safety_refusal - 模型拒绝回答
// timeout - 超时

AI 功能的适用边界

经过这几轮试错，我总结了一个简单的分类表，帮助快速判断一类 AI 功能适不适合早期做：

适合先做的功能：文本摘要、改写、翻译、结构化提取、候选方案生成、智能搜索。

需要谨慎的功能：自动发送邮件、自动审批、合同条款生成、医疗建议、财务预测。对于这些场景，更稳妥的做法是 AI 生成建议，用户确认执行。

成本不能事后才算

很多团队在 Demo 阶段不算成本，因为单次调用看起来便宜。但当你有 1000 个日活用户，每人每天触发 10 次 AI 调用，每次调用平均 2000 Token，情况就完全不同了。

Deepset 的 AI 采纳框架里提到，AI ROI 必须同时计算收益和成本两端（来源）：

一个实用的成本估算公式：

# 月度 AI 功能成本估算
monthly_cost = (
    dau                        # 日活用户数
    * avg_calls_per_user       # 每用户日均调用次数
    * 30                       # 月天数
    * avg_tokens_per_call      # 每次调用平均 Token 数
    * price_per_token          # 每 Token 单价
    * (1 + retry_rate)         # 重试带来的额外成本
    * (1 + ops_overhead_rate)  # 运维开销比例，通常 0.2-0.4
)
 
# 示例：1000 DAU，每用户 10 次/天，每次 2000 Token
# gpt-4o-mini 价格约 $0.15/1M input tokens + $0.60/1M output tokens
# 假设输入 1500 tokens，输出 500 tokens
avg_cost_per_call = (1500 * 0.15 + 500 * 0.60) / 1_000_000  # ≈ $0.000525
monthly_cost = 1000 * 10 * 30 * 0.000525 * 1.2 * 1.3  # ≈ $245.7
# 看起来不多，但如果模型换成 gpt-4o，价格翻 10 倍就是 $2457

# 对比：不同模型选择对成本的影响
scenarios = {
    "gpt-4o-mini": {
        "input_price": 0.15,   # $/1M tokens
        "output_price": 0.60,
        "monthly_cost": 245.7,  # 上述计算结果
        "quality": "中等",
    },
    "gpt-4o": {
        "input_price": 2.50,
        "output_price": 10.00,
        "monthly_cost": 4095.0,  # 约 16.7 倍
        "quality": "高",
    },
    "claude-3-5-haiku": {
        "input_price": 0.80,
        "output_price": 4.00,
        "monthly_cost": 1428.0,  # 约 5.8 倍
        "quality": "中高",
    },
}
# 模型选择不是一个技术问题，是一个产品决策：
# 质量提升 30%，成本可能增加 10 倍。值不值？要看用户愿意为这个质量差付费吗？

立项检查清单

经过这些踩坑和复盘，我整理了一份检查清单。在把任何 AI 功能放进 MVP 之前，我会逐项过一遍：

用户价值

• 用户在没有这个功能时，是用什么方式完成这个任务的？
• 这个任务在用户的工作流中出现的频率是？（每天/每周/每月/很少）
• AI 介入后，用户感知到的最大改善是什么？能用一句话说清楚吗？
• 用户能在 5 秒内判断 AI 输出的质量吗？

技术可行性

• 当前模型的能力是否足以达到用户可接受的质量？
• 团队是否拥有让模型比通用 ChatGPT 更好的私有数据或上下文？
• 平均延迟能否控制在 3 秒以内？
• 失败率能否控制在 5% 以下？

商业可持续性

• 月度 Token 成本在当前用户规模下是否可承受？
• 如果用户量增长 10 倍，成本结构是否还能成立？
• 这个功能对留存、转化或收入有直接可衡量的影响吗？
• 如果换一个更便宜的模型，质量下降是否会影响核心体验？

工程准备

• Prompt 是否已经版本管理并纳入代码仓库？
• 是否有完整的指标跟踪方案（采纳率、输出质量、延迟、成本）？
• 失败样本是否有分类标签机制？
• 是否有降级方案——AI 不可用时，用户体验不会完全断裂？

写在最后

AI 功能的判断，本质上跟任何功能判断没有区别——都要回到用户价值和商业可持续性。只不过 AI 功能多了一层持续运营成本和概率性输出的复杂度，让判断门槛更高了一些。

我学到的最重要的一件事是：不要在 Demo 阶段做决策。Demo 是给人看的，不是给用户用的。真正的判断依据是上线后的数据——采纳率、输出采纳率、重试率、修改率、留存影响。这些数据才是功能该留还是该走的裁判。

OpenAI 的产品负责人说过一句话我很认同：「AI 不只是改变了我们构建产品的方式，它改变了 Product-Market Fit 本身的含义。」（来源）传统 PMF 看的是用户要不要这个产品，AI 时代的 PMF 还要看用户信不信任这个产品的输出、愿不愿意为概率性的结果付费、能不能接受偶尔的错误。

下次再有人说「我们可以用 AI 做 XXX」的时候，先别急着写 Prompt。把四个问题拿出来，把 Triple Fit 框架过一遍，把检查清单走一趟。能活着走完这些检查的功能，大概率值得做。

参考资料

1. Product Voyagers. The Triple Fit Framework for AI Product Strategy. 2025.
2. Mixpanel. 30+ AI Product Metrics to Track Today. 2026.
3. Nupur Jain, Google Research. A Strategic Framework for AI Product Development and Evaluation in Enterprise Software. 2026.
4. Deepset. A Guide to Generative AI Adoption Framework: Measurable Outcomes & ROI. 2025.
5. Product Management AI. OpenAI's Product Lead Reveals the New Playbook for Product. 2025.
6. McKinsey & Company. AI in the Workplace: Superagency. 2025.
7. Presta. AI Product Strategy 2026: The Founder's Guide to AI-Native Growth. 2026.