老板在“AI万能”和“AI根本不行”之间反复横跳时，产品经理可以用4道门把一句“加个AI”变成可验证的产品需求。

周一开会，老板突然问：“竞品首页都有AI，我们怎么还没有？这个版本加一个。”

你试着问具体一点：“想让AI解决哪个问题？客服、搜索，还是内容生成？”

老板回答：“先做起来啊，AI现在不是什么都能干吗？”

于是，AI产品经理回到工位，开始熟悉的牛马流程：研究模型、拉研发评估、催业务整理数据，还要解释为什么不能只放一个发光的AI按钮。需求只有一句“加个AI”，潜台词却一个不少：更快、更聪明、更便宜，第一次演示还不能答错。

两周后，Demo跑起来了，模型偏偏在老板面前答错了一道简单问题。

老板皱了皱眉：“这就是AI？还不如人工。是不是你们模型没选对？”

从“AI什么都能做”到“AI根本不行”，有时只隔着一次Demo。产品经理不需要证明AI万能，也不用替AI辩护。第一项工作，是把老板的期待翻译成一个可以验证的问题。

在面对每次要“加个AI”之前，先问自己四个问题，分别检查用户代价、技术适配、落地条件和业务价值。

第一问：用户真的在为这个问题付出代价吗？

“用户希望更智能”不算需求。“用户每天要在三个系统之间来回切换，才能判断一笔退款能不能通过”才算。

这对应克莱顿·克里斯坦森等人提出并推广的“用户任务理论”（Jobs to Be Done，常简称JTBD）：不要先问用户喜欢什么功能，要找出他在特定场景下想完成什么任务。OpenAI Academy在2026年更新的方法也建议，从反复、耗时、易错的工作流出发，而不是先问“怎么用AI”。

例如，老板要做AI客服。跑完客服流程后，你发现最费时间的是复杂售后：客服要查订单、物流、会员等级和历史赔付，再判断能否退款。需求因此从“增加AI聊天框”变成“缩短信息收集和判断时间”。

要证明问题成立，至少要找到行为、频次和成本证据。找不到正在承受代价的人，项目先别往下走。

第二问：为什么一定要用AI？

有些问题用搜索、规则和流程改造就能解决，而且更稳定、更便宜。AI适合阅读非结构化内容和处理模糊判断，但并非每个任务都该用AI。

Goodhue和Thompson在1995年提出“任务—技术匹配模型”（Task-Technology Fit，常简称TTF）。他们分析600多人的数据后发现，技术只有被实际使用并与任务匹配，才可能改善绩效。

2026年正式发表于《Organization Science》的“锯齿状技术前沿”实验测试了758名知识工作者：在AI能力边界内的18项任务上，参与者平均多完成12.2%的任务，速度快25.1%；但在边界外的一项复杂任务上，使用AI的人得到正确答案的概率反而低19%。

老板看到任务A效果惊艳，容易认为AI万能；任务B翻车，又觉得AI无能。在反复横跳的老板的审判中，产品经理要判断的，是具体任务落在边界的哪一侧。

如果客服只是找不到退款按钮，那就改页面；如果需要阅读长段描述，再结合订单、历史沟通和政策做初步判断，AI才可能有增益。

这一问只需回答：不用AI还能怎么解决？AI具体好在哪里？

第三问：AI拿得到完成任务所需的东西吗？

大模型会说话，不等于它能完成工作。复杂售后至少需要订单、物流、退款政策和历史沟通；如果要执行退款，还要接入工具、权限和人工确认。

腾讯首席AI科学家姚顺雨提出，AI正在从“找方法”转向“找问题”，环境、评估以及模型与环境的交互，可能比单看模型能力更重要。

这也对应NIST AI风险管理框架中的“情境映射”（Map）环节：先说明场景、目标、相关人员和影响，再进入测试与风险决策。产品经理不能只画聊天页面，要画完整任务链：模型能看到什么、调用什么、谁来确认、信息不足时追问还是转人工。

关键数据拿不到、工具接不上，或者权限风险无法控制，再强的模型也只能停留在Demo里。

第四问：我们怎么知道AI做得好不好？

AI输出有概率性，只看“能不能生成”不够。OpenAI在《AI in the Enterprise》中把“先做评测”（Start with evals）列为第一条经验：先定义用例基准和专家反馈，再开始开发。这里的Evals不是另一套学术理论，而是AI评测实践。翻成产品语言，就是先写验收题，再做AI功能。

复杂售后助手至少要看：

• 结果质量：引用的订单和政策是否正确，建议是否符合规则？
• 任务效率：客服完成一次处理需要多久，减少了多少查找和复制？
• 业务结果：一次解决率、转人工率、投诉率是否改善？
• 风险边界：错误建议会造成什么损失，哪些情况必须由人复核？
• 单次成本：完成一个有效任务的模型、系统和人工复核成本是多少？

NBER论文《Generative AI at Work》分析了5179名客服人员。接入AI助手后，每小时解决问题数平均提高14%；新手和低技能员工提高34%，但对高经验员工影响很小。AI价值要落实到具体任务和人群，这14%也不能直接复制到自己的立项书里。

如果项目只能汇报调用次数、对话轮数和生成字数，却说不清改善了哪个业务结果，那是使用量，不是价值。

把4个问题变成“AI需求四道门”

开需求会时，可以把前面4问变成“AI需求四道门”。每道门都要拿出证据，不通过就从对应出口离开。

这套方法最重要的不是4个问题，而是4条退出路线：问题不成立就回到调研；普通功能能解决就不用AI；条件不足就先补数据和工具；价值无法衡量就做离线测试或暂停。

四道门全部通过，才进入模型选型和POC。POC要跑通最小任务链，用真实上下文和评测集验收，再决定扩大、缩小还是停止。之后再用“业务影响 × 实现投入”排序，高影响、低投入的需求优先验证。

AI产品经理的价值，不是记住最多的模型参数

模型当然要懂，但项目开始时，更重要的是选对问题。功能做得越快，选错问题的代价越容易放大。

有人正在为问题付出代价吗？AI比普通方案合适吗？数据和工具准备好了吗？我们知道怎样算做好吗？

四个问题都能答清楚，再去选模型。把需求入口守住，才是AI产品经理真正替团队省钱的地方。

参考资料

1. OpenAI， Identifying and scaling AI use cases。用于AI机会识别及影响与投入排序。
2. 腾讯， 产业一线的AI经验：从“找方法”转向“找问题”，2026年6月5日。用于“扎根场景”与“找问题”观点。
3. Clayton M. Christensen等， Know Your Customers’ “Jobs to Be Done”，《Harvard Business Review》，2016年。用于第一道门的用户任务方法论。
4. Dale L. Goodhue与Ronald L. Thompson， Task-Technology Fit and Individual Performance，《MIS Quarterly》，1995年，DOI： 10.2307/249689。用于第二道门的任务技术匹配理论。
5. Fabrizio Dell’Acqua等， Navigating the Jagged Technological Frontier，《Organization Science》，2026年。用于AI能力边界和758人实验数据。
6. NIST， AI Risk Management Framework Playbook： Manage。用于第三、第四道门的场景映射、测试评估和风险决策。
7. Erik Brynjolfsson、Danielle Li与Lindsey R. Raymond， Generative AI at Work，NBER Working Paper 31161，2023年，DOI： 10.3386/w31161。用于客服生产率和人群差异数据。
8. OpenAI Academy， Use Case Discovery Workshop Playbook，2025年发布，2026年6月更新。用于从真实工作流而非宽泛AI能力出发的用例发现方法。
9. OpenAI， AI in the Enterprise。用于“Start with evals”及用例基准、专家反馈方法。