“Nobody Asked for AI”这句话与其说是在否定人工智能不如说是在给很多技术团队提了一个尖锐的问题你做的这个 AI 功能用户真的在等吗在实际项目里我们经常看到的情况是大模型能力刚接入产品经理就急着设计一堆“AI 能力”工程师花几周部署模型、写提示词、调参数结果上线后点击寥寥。问题往往不在模型效果而在一开始就没有回答一个最基本的问题这个功能到底解决谁的什么需求。这篇文章从工程实践角度把“Nobody Asked for AI”当作一个需求质量信号来展开。我们会讨论为什么 AI 功能特别容易出现“先造出来再说”的思维怎么用一套可复用的方法判断需求真伪怎么写最小可行 AI 功能以及如何评估、排错和止损。整个讨论面向做应用层 AI 开发、AI Agent、AI 产品设计和模型部署的工程师也适合负责技术选型的产品经理参考。1. 先把“Nobody Asked for AI”当成需求信号而不是媒体报道标题1.1 一句话定义功能空转的本质是需求缺失“Nobody Asked for AI”不是一个严格术语而是开发者群体对“为了 AI 而 AI”的调侃。它描述的是这样一个状态团队围绕大模型做了大量工作但功能没有进入用户的真实工作流使用率、留存率和业务转化率都低于预期。很多人以为这是模型能力不够导致的实际上多数失败案例是需求定义阶段出了问题。技术团队把“能做什么”当成了“用户要什么”把“大模型可以完成这个任务”当成了“这个任务值得被完成”。这在技术社区非常常见因为 AI 能力边界每天都在变化容易让人产生“我可以用模型做什么”的兴奋感。要避免这个问题第一个动作不是马上写代码而是把“Nobody Asked for AI”翻译成一句可检验的问题如果去掉这个 AI 功能用户现有的流程会损失什么如果他们没有任何感知那这个功能就属于空转。1.2 开发者的任务是把“AI”翻译成可验证的问题技术方案评审时我经常听到这样的描述“我们可以用 AI 自动给工单打标签。”这个描述里“AI”只是一个工具不是需求。需求应该被写成这样客服团队现在每天手工给大约 500 张工单分类每张耗时 2 分钟分错后流转到错误组平均多等 30 分钟。把需求写成这样后AI 的价值就非常明确减少耗时、减少错误流转、提升响应效率。即使不用 AI团队也可以通过优化下拉菜单、预设分类规则、强制必填字段来改善。这样一来AI 方案就要和规则方案对比成本、效果和可维护性。在实际开发中不要让“AI”这个词出现在需求目标里。需求目标应该是用户可感知的结果比如“工单平均处理时间下降 20%”“分类准确率达到两条人工抽检链路的水平”。如果目标无法被量化后续评估模型效果就会退化成“看起来还行”。1.3 一个反例没有需求驱动的自动标签分类器我见过一个典型的失败项目团队为了展示 AI 能力给内容管理系统做了一个“文章自动标签”功能。模型已经接好标签也打得看起来挺准演示时全场满意。但上线后真正使用的只有测试账号业务方给出的原因是他们有一套非常固定的标签体系文章发布时编辑本来就会填标签自动标签的结果不仅对不上业务口径还需要人工逐条修改。这个案例里模型效果不是致命问题需求就错了。用户没有“标签耗时过高”或“标签质量差”的痛点自动标签反而增加了二次确认成本。如果开发前只问一句“这个功能上线后业务人员的工作量真的会下降吗”可能就发现答案是否定的。这类反例很有参考价值。它说明AI 功能的验收标准不是“模型输出正确率”而是“是否减少了某个现存问题的发生频率或成本”。正确率只是必要条件不是充分条件。1.4 真需求经常具备的四个特征判断一个 AI 需求是否为真需求可以参考下面四条标准。四条不一定同时满足但至少要有两条能给出明确证据。第一用户在现有流程里有明确耗时或等待痛点。比如“人工客服每天重复回答 30 次退货政策”而不是“我们觉得客服需要智能助手”。第二错误带来的成本可以量化。例如分类错误导致工单流转错部门平均增加 30 分钟处理时间如果这类错误很少发生优化的优先级也不高。第三数据可以反馈到后续环节。AI 功能必须有输入、输出和结果回收的完整链路否则无法知道模型是否真的在帮助用户。第四功能上线后用户可以感知到差异。用户不需要知道背后是矩阵乘法还是大模型他们只需要感受到更快、更准或更省力。凡是无法被用户感知的 AI 能力最终都会被关闭。2. 用需求漏斗替代“先堆模型”的思路2.1 先列出问题清单再匹配 AI 能力很多团队把顺序搞反了先选定一个模型再去找一个场景。正确的顺序应该是先列问题再对每个问题判断是否需要 AI以及需要哪种 AI。以客服工单分类为例先列出现有问题工单需要人工选择一级分类和二级分类每天约 800 张。分类规则复杂新员工培训成本高。部分分类之间界限模糊人工判断也存在不一致。高峰期客服没有足够时间逐张处理。这些问题里第一项和第四项可以通过自动分类解决第二项可以通过知识库和帮助文档解决第三项需要人工抽检机制配合。把问题拆开后真正适合模型介入的可能只有“自动分类”和“相似问题推荐”。这种拆解的价值在于它不会把 AI 当成万能药。模型适合处理高重复度、语义模糊、量大且耗时的问题而不适合处理规则完全清晰、错误影响非常大的场景。比如支付金额核算就不能依赖大模型输出应该用确定性的业务规则。2.2 没有 AI 的基线必须算清楚在决定用 AI 之前先估算现状的基线成本。这个成本通常包括时间成本、人力成本和错误成本。以工单自动分类为例基线可以这样计算每张工单手工分类耗时 2 分钟。客服时薪折算每分钟约 1 元那么每张成本约 2 元。每天 800 张一个月 22 个工作日月成本约 35200 元。手工分类准确率假设为 92%每月约 64 张工单会分错分错工单平均延迟 30 分钟延迟造成的客户等待成本另计。如果 AI 自动分类可以做到 95% 准确率并且每张人工确认耗时 10 秒那么节省的明显是手工耗时和错误流转成本。但与此同时需要叠加模型调用成本、GPU 或 API 费用、提示词维护成本和人工抽检成本。只有把基线算清楚才能判断“AI 是否值得”。很多时候结论是规则加自动化就能解决 80% 问题模型只负责剩余 20% 的兜底。这就是混合方案的由来。2.3 定义成功指标不要用准确率冒充业务价值模型评测里的准确率、F1、BLEU 等指标只是中间指标。产品侧真正要关心的是业务指标比如处理时长、用户满意度、客服转人工率、工单积压量。准确率和业务价值之间不是必然关系。一个文本摘要模型 ROUGE 分数高未必代表用户阅读时间缩短一个对话模型回答流畅未必代表用户问题被解决。要建立中间指标到业务指标的映射关系。以客服助手为例可以设定这样一套指标模型回答被用户点击“有帮助”的比例。用户发起新一轮追问的比例。会话最终转人工的比例。平均对话轮数。单次会话成本。当“转人工率”下降时说明 AI 确实解决了一部分问题。如果转人工率没有变化即使模型生成内容再流畅也不能算成功。这就是为什么需求阶段就要把业务指标定义清楚。上线后每两周回顾一次这些指标比盯着一张 PRD 里的功能描述有效得多。2.4 一个可复用的需求评估模板我现在习惯在动手前填一张简单的评估表。表里不写技术方案只写业务判断。项目内容目标用户客服、运营、创作者等当前痛点每天重复劳动、等待时间长、错误率高当前基线耗时、成本、错误率期望改进降低到多少如何测量非 AI 方案规则、流程优化、人工培训AI 方案需要哪些数据和能力用户感知点用户能感知到什么变化失败指标上线后哪些数据说明功能该下架这张表的目的不是增加文档负担而是逼着团队把模糊想法变成可验证假设。假设写不出来的功能通常需求就是不成立的。3. 最小可行 AI 功能应该怎么写3.1 不要一上来就上大模型先从规则和提示词工程开始很多应用场景并不需要大模型。最小可行 AI 功能的起点应该是一个“规则 轻量模型 人工兜底”的组合。以工单自动分类为例可以分三步走第一步写一套硬规则。如果工单正文包含“退款”“发票”“物流”直接映射到对应分类。这个方案零成本立刻能解决一部分问题。第二步对规则无法覆盖的工单使用文本分类模型或大模型提示词分类。尽可能构造少量样本先用示例驱动提示词验证能不能稳定复现分类逻辑。第三步所有自动分类结果都进入一个“人工确认队列”。用户不会被 AI 直接决定而是看到 AI 预填的分类可以选择接受或修改。这个设计既留下人工兜底也为后续模型迭代收集标注数据。这种渐进式设计最大的好处是降低启动成本。如果规则已经解决了大部分问题模型只需要处理少量长尾样本对模型能力要求也随之下降。3.2 一个 MVP 示例客服工单自动分类接口下面是一个最小 API 示例。它展示的是“规则优先 模型补位 人工反馈”的完整链路真实项目可以根据内部模型网关调整模型调用方式。import re from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() RULE_KEYWORDS { 退款: after_sale, 发票: invoice, 物流: logistics, 账号: account, } class Ticket(BaseModel): ticket_id: str content: str class TicketResult(BaseModel): ticket_id: str predicted_category: str confidence: float source: str def classify_by_rule(content: str) - tuple[str, float]: for keyword, category in RULE_KEYWORDS.items(): if keyword in content: return category, 0.99 return , 0.0 def classify_by_llm(content: str) - tuple[str, float]: # 这里替换成公司内部统一的模型服务地址。 # 请求体和解析方式以模型网关文档为准。 # 示例只说明调用结构不绑定特定供应商。 prompt f你是工单分类引擎。 工单分类只能从 [after_sale, invoice, logistics, account] 中选择一个。 只输出 JSON{{}category: 分类名, confidence: 0.0-1.0{}} 工单内容 {content} # response chat_client.chat.completions.create(...) # data parse_json(response) # return data[category], data[confidence] # 下面是示意返回值。 return after_sale, 0.87 app.post(/classify, response_modelTicketResult) def classify_ticket(ticket: Ticket): content ticket.content.strip() if not content: raise HTTPException(status_code400, detailticket content is empty) rule_category, rule_confidence classify_by_rule(content) if rule_category: return TicketResult( ticket_idticket.ticket_id, predicted_categoryrule_category, confidencerule_confidence, sourcerule, ) llm_category, llm_confidence classify_by_llm(content) return TicketResult( ticket_idticket.ticket_id, predicted_categoryllm_category, confidencellm_confidence, sourcellm, )这段代码里有两个关键点一是规则结果直接返回不再打扰模型二是模型结果带有 confidence方便下游做阈值控制。如果 confidence 低于 0.6就不应该自动流转而是进入人工队列。生产环境里这里还需要加上鉴权、限流、审计日志和模型服务超时处理。尤其要注意大模型接口单次可能消耗 500 到 2000 个 token如果每张工单都调用成本会快速上涨。规则先行就是为了省下这部分成本。3.3 设计反馈回路用户“不用”也是数据AI 功能上线后只有日志没有反馈是远远不够的。业务侧需要主动记录三类数据用户接受的结果、用户修改的结果、用户完全忽略的结果。在工单分类场景里UI 可以设计成“AI 预选分类客服下拉确认”。当客服把 AI 预选结果改掉时这个修改就是一个真实标注样本。把修改前后的内容、最终分类、是否来自规则或模型记录下来就形成了持续迭代的评测集。没有反馈回路的 AI 功能本质上是一个黑盒。你不知道模型什么时候开始退化也不知道新部署的版本和旧版本相比到底有没有变好。所以 MVP 阶段就要把“结果回写”这个接口一起定义好。3.4 学习环境与生产环境差异要提前分清学习环境里通常用一两个样例就能验证模型输出生产环境则需要考虑稳定性、成本和错误兜底。两者差异很大直接对照一下。维度学习环境生产环境数据规模几十条示例每天数千条真实数据模型调用直接调 API内部网关、超时、重试、熔断输出质量人工目测评测集 周期性回归成本控制不需要按 token 或调用次数核算安全合规忽略敏感信息脱敏、审计人工兜底没有低置信度转人工监控告警不需要错误率、延迟、成本监控学习环境跑通过只是说明代码逻辑没问题。离生产上线还差日志、监控、异常处理和灰度方案。所以项目起步时可以简单考虑要提前想清楚最好在第一个版本里预留日志和反馈接口。4. 评估 AI 功能的真实收益不能只看演示4.1 从 10 条样例到 200 条闭环样本演示阶段大家很容易被 10 条精心挑选的样例征服。这些样例通常手写或者选得非常典型不能代表真实数据分布。进入评估阶段至少需要建立一个小规模的评测集规模不小于 200 条并且要覆盖正常样本、边界样本、错误样本和长尾样本。构造评测集时要注意几点不要只选模型表现好的案例。要包含业务方真实输入而不是同学手写的理想输入。每条样本要有“预期结果”这个预期结果最好由业务专家或规则确定。评测时要记录模型输出、置信度、来源规则还是模型方便后续切片分析。一个 200 条样本的评测集可能只需要两天就能准备完但它对模型选型、提示词调优和上线判断非常有价值。没有评测集就直接上线等于在没有仪表盘的情况下把一个模型部署到生产环境。4.2 四类指标质量、成本、延迟、不可用率AI 功能评估不能只盯着模型效果。至少要同时看四类指标。指标类型具体示例说明质量分类准确率、摘要相关度、推荐点击率模型输出是否符合预期成本单次调用 token 数、API 费用、GPU 利用率是否可持续运营延迟P50/P95 响应时间用户是否愿意等待不可用率超时率、5xx 错误率、解析失败率系统是否可靠这四类指标之间是互相牵制的。比如为了提升质量把模型换成更大的版本可能导致延迟从 300ms 涨到 1500ms成本翻倍。此时就要确认质量提升是否真的能转化为业务收益否则就要调整方案。在实际项目里最常见的问题是只有“质量”维度被讨论成本和延迟在联调阶段才暴露。等到上线时才发现单次调用成本过高功能一旦放开成本会吃掉整个项目预算。4.3 用 A/B 测试验证“AI 是否被需要”如果业务指标已经在图里但不确定功能是否真的有价值可以做一个最小 A/B 测试。把用户流量按 50%/50% 分成两组一组使用原有流程一组使用 AI 功能比较核心业务指标。以客服工单分类为例对照组保留人工分类实验组使用 AI 预分类 人工确认。对比两个组的人工处理时长、分错率、满意度。实验至少运行一周样本量要达到能看出差异的水平。A/B 测试最怕两件事一是实验组功能体验不稳定用户还没理解产品流程就退出导致结果严重偏向对照组二是同时改了两三个变量最后无法定位是哪个变量带来的效果。所以测试只改一个变量其他条件保持一致。如果 A/B 测试结果显示两组没有显著差异说明 AI 功能至少在“减少处理时长”这个目标上未达成。这时候不应该继续追加训练数据应该重新回到需求定义阶段。4.4 发现“没人用”之后如何止损没人用不等于功能一定要立刻删除。先看是不是入口、权限、通知和用户理解的问题再做结论。排查顺序可以是功能入口是否真的暴露给了目标用户用户是否知道这个功能可以解决问题功能是否默认开启还是需要用户手动进入使用链路里是否有额外操作成本导致用户放弃结果是否准确到足够替代原有流程如果这些问题都查过入口明显、操作简单、结果和人工持平但用户仍然不用那就可以考虑下架。止损不一定代表项目失败它可能是帮助你避免继续投入无效资源的最好决策。把“随时可以砍掉”当成设计原则功能架构上就不要和业务强绑定太深。AI 模块尽量独立下架时不会影响基础流程。这听起来保守但在“Nobody Asked for AI”很常见的今天反而是一种专业态度。5. 常见坑为什么 AI 功能做着做着就失真了5.1 把模型吞吐当成产品指标有些团队把“每天处理 10 万次调用”当成功绩这是典型的技术指标替代业务指标。调用量高只说明流量高不代表用户获得了价值。一个设计糟糕的聊天机器人可能每分钟产生大量无意义对话但这些对话没有解决任何问题。正确的做法是同时看调用量、有效解决率、用户留存率和人工转接率。如果调用量高但转人工率也很高很可能说明 AI 无法独立解决问题用户只是进来试一下然后马上找人工。5.2 忽略幻觉和引用来源大模型幻觉是应用层必须面对的问题。只要模型输出内容涉及事实、条款、操作步骤就可能编造信息。比如客服助手把退换货政策里的 7 天说成 30 天用户按错误指引操作最终一定会引发客诉。缓解幻觉的思路不是让模型“不要胡说”而是在架构上把事实来源接进来。例如给模型提供知识库检索结果要求回答必须引用来源或者在高风险场景里不允许模型直接给结论只允许给出检索到的原文片段。生产环境还要对可观测性提出更高要求记录模型使用的上下文来源、生成引用的片段和用户最终的反馈。如果某条回答被用户多次投诉才能追踪到是检索问题还是模型生成问题。5.3 Credits 和成本模型没设计好功能活不过一周“Credits” 在 AI 产品里通常指额度或积分它既可以是内部成本核算单位也可以是面向用户的计费单位。做 AI 功能时一定要在早期搞清楚 credits 的消耗链路。从成本角度看一次大模型调用消耗的 token 数量直接决定了单次成本。比如一个客服回答平均需要 800 个输入 token 和 200 个输出 token按模型单价计算在业务量预期下每日成本是否在预算内同一功能在规则版和 LLM 版之间成本差距可能是几十倍。从用户角度看如果产品以 credits 方式计费还要设计额度的充值、扣减、过期和提醒机制。很多 AI 产品上线后开发者只关注生成效果忘了设计额度耗尽后的降级逻辑。用户额度为 0 时是直接失败还是自动切换规则版这会影响用户体验。这里有一个关键判断如果功能的核心体验不能覆盖 credits 成本说明单位经济模型不成立。这时候需要降低模型调用频率、使用更小的模型、增加缓存或者重新评估功能是否值得保留。5.4 “Prompt 调一下就能好”的误区提示词工程确实是提升模型输出的低成本手段但它有上限。当模型连续出现知识性错误、格式不稳定、覆盖不了长尾样本时问题可能出在数据、模型选择或评测集构建上。在实际开发里经常看到团队花两周调提示词结果每次业务方给一条新样例模型输出又会出问题。这是因为 prompt 本质上是对任务的描述但模型不能通过几行文本把所有业务规则内化。尤其对于领域知识密集的业务单纯调 prompt 不如引入知识库或微调方案。建议把提示词维护当成代码维护每个 prompt 都要留版本、写说明、接评测集。修改 prompt 前跑一遍回归不能肉眼判断“看起来可以”就合并。5.5 常见问题排查路径如果 AI 功能表现不如预期可以按下面的链路排查。现象可能原因检查方式处理建议输出分类不准评测集覆盖不足抽样 50 条人工核对补充长尾样本同样内容答案不稳定提示词没有设置输出格式连续调用 10 次查看差异锁定 JSON 格式并增加约束响应慢模型输入 token 过多查看日志中的请求 token 数压缩知识库检索内容成本超标每次请求携带的上下文过大统计平均 token 数增加缓存、减少历史轮次用户不用入口不明确或需求不成立看用户行为和客服反馈调整入口或考虑下架排查时先处理最可能影响用户体验的问题再处理成本和效率。不要一上来就换成更大的模型那样只会让问题更难定位。6. 从需求到上线的 AI 工程实践检查清单6.1 上线前必须完成的五个检查每次做一个 AI 功能我都会把下面几点列为硬性要求。第一需求描述里不出现“AI”只出现可测量的用户问题。如果说不清楚问题开工是浪费资源。第二有至少 200 条覆盖边界情况的评测集。没有评测集模型效果就靠运气。第三接口有日志和反馈记录。至少记录输入文本、模型输出、置信度、耗时、成本、用户是否采纳。第四有降级方案。模型调用超时或失败时系统能回退到规则或人工流程。第五有止损条件。定义好“哪些指标连续两周没有改善就暂停功能”。这五条不是流程冗余而是防止 AI 功能变成“Nobody Asked for AI”的必要约束。6.2 模型、提示词、评测集、日志四层维护AI 应用上线后维护工作至少要分成四层。模型层要关注版本变化。模型供应商发布新版本后必须先跑评测集结果再决定是否升级不能自动跟随。提示词层要拆成结构化模板并把动态部分和静态部分分开。静态部分是规则说明动态部分是用户输入和检索内容。模板变更要像代码变更一样走评审和回归。评测集层要持续积累。线上用户修改过的结果、客服反馈、新出现的业务规则都应该定期合并进评测集。日志层要能回答三个问题这个请求为什么不这样返回这次调用花了多少钱这个错误是模型问题还是程序问题没有日志层的 AI 功能排错时只能靠猜。6.3 什么时候该砍掉 AI 功能砍功能不是失败而是产品管理正常的一部分。以下情况出现两条以上就应该认真考虑下线。连续两周使用率低于预期且已经尝试过入口和引导调整。模型输出质量持续无法稳定且成本远高于人工处理。用户反馈显示AI 结果不仅没有减少工作量反而增加了校验成本。维护这个功能需要投入的资源明显高于它带来的收益。决策时不要只看短期也要考虑有没有办法通过更小改动扭转。但如果已经验证了核心假设不成立就应该尽快止损。继续投入资源只是在拖延一个已经失败的功能。6.4 AI Agent 开发中的额外注意点如果开发的是 AI Agent而不只是单轮调用需要额外考虑工具调用、状态管理和多步骤错误恢复。Agent 的每一步都可能导致错误累积所以不能只看最终结果还要看过程可追踪性。Agent 类项目最常见的“Nobody Asked for AI”表现是用户本来五分钟能完成的事Agent 自动执行时花了十分钟并且中间出现了不可控的写入操作。让 Agent 自动执行必须满足一个前提自动执行后的失败率低于人工执行的失败率并且出现失败时可以安全回滚。在工程实现上要给 Agent 增加每步审批、工具调用白名单、最大步数限制和超时熔断。不要设计成“Agent 全自动搞定一切”至少在初期保留“建议方案用户点击确认”的交互模式。等数据证明 Agent 稳定以后再逐步扩大自主范围。7. 最该记住的技术判断与下一步练习AI 功能能不能活下来不取决于模型参数和锦上添花的动画而取决于有没有答对“用户原来的流程缺什么”这个题目。很多失败的 AI 项目不是代码写错了而是从需求推断这一步开始就偏了。工程师可以把“Nobody Asked for AI”当成一种自检提醒每做一次需求评审就问这功能有没有真实的使用场景有没有可量化的收益有没有随时可退出的方案。对于还没有做过完整 AI 应用的同学建议从一个小场景开始练选一个你每天都重复做的任务比如整理会议纪要、给文件取标题、判断工单优先级先用规则做一版再用提示词工程做一版最后加反馈日志和评测集。把一个场景做透比同时做十个功能更接近真实的 AI 工程。下一步可以顺这几个方向继续深入一是学习 AI Agent 开发中工具调用与状态管理的设计二是研究模型部署后的监控、降级和成本控制三是把评测集和 A/B 测试真正引入团队逐步形成一套自己的 AI 功能评估流程。把这些事做好你就不再是“给 AI 找一个功能”的人而是“给功能找一个合适 AI 方案”的人。