AI需求四道门
AI产品需求可行性检查框架——把”加个AI”这句模糊需求变成四道可验证的关卡，每道门都要拿出证据，不通过就从对应出口离开。
简介
AI需求四道门是一套由AI产品经理蔡延庆（在下毛毛雨）提出的需求可行性检查方法论。它解决了AI PM最常见的困境：老板一句”加个AI”，潜台词却一个不少（更快、更聪明、更便宜，第一次演示还不能答错），PM需要把这种模糊期待翻译成可验证的产品需求。
四道门分别检查四个维度：用户代价（问题是否真实存在）、技术适配（AI是否最优方案）、落地条件（数据和工具是否就绪）、价值验证（是否知道怎样算做得好）。每道门不通过都有明确的退出路线，避免”先做再说”的资源浪费。
关键信息
- 类型：方法论（概念类实体）
- 领域：AI 产品管理 · 需求分析 · 可行性评估
- 提出者：蔡延庆（在下毛毛雨）
- 提出时间：2026-07-15
- 核心逻辑：四道关卡 + 四条退出路线
- 适用场景：老板/业务方提出”加个AI”时，AI产品需求立项前
核心特性
1. 四道门详解
第一道门：用户代价门
- 核心问题：用户真的在为这个问题付出代价吗？
- 理论基础：JTBD 用户任务理论
- 检查方法：找到行为、频次和成本证据——用户每天要做什么重复/耗时/易错的事
- 退出出口：问题不成立→回到用户调研
- 案例：AI客服需求从”增加AI聊天框”变成”缩短信息收集和判断时间”
第二道门：技术适配门
- 核心问题：为什么一定要用AI？不用AI还能怎么解决？
- 理论基础：TTF 任务技术匹配模型 + 锯齿状技术前沿
- 检查方法：AI比普通方案（搜索/规则/流程改造）好在哪？任务落在AI能力边界的哪一侧？
- 退出出口：普通功能能解决→不用AI
- 案例：客服找不到退款按钮→改页面；需阅读长段描述+结合多方信息做判断→AI有增益
第三道门：落地条件门
- 核心问题：AI拿得到完成任务所需的东西吗？
- 理论基础：NIST AI风险管理框架 情境映射 + 姚顺雨”从找方法转向找问题”
- 检查方法：画出完整任务链——模型能看到什么、调用什么、谁来确认、信息不足时追问还是转人工
- 退出出口：条件不足→先补数据和工具
- 案例：复杂退款需要订单+物流+退款政策+历史沟通，缺一样都只能停留在Demo
第四道门：价值验证门
- 核心问题：我们怎么知道AI做得好不好？
- 理论基础：OpenAI “Start with evals” + Eval 框架
- 检查维度：结果质量、任务效率、业务结果、风险边界、单次成本
- 退出出口：价值无法衡量→离线测试或暂停
- 案例：NBER 5179名客服研究显示AI提高14%效率，新手提高34%，但高经验员工几乎无影响
2. 四条退出路线（比四个问题更重要）
这套方法论的核心价值不是4个问题本身，而是4条明确的退出路线：
- 回到调研：问题不成立，没有正在承受代价的真实用户
- 不用AI：普通功能（搜索、规则、流程改造）就能解决，而且更稳定更便宜
- 先补基础：数据和工具条件不足，先补齐再谈AI
- 暂停或离线测试：价值无法衡量，先定义清楚怎么算”做得好”
四条退出路线让PM避免陷入”先做起来再说”的陷阱——在条件不成熟时强行上AI，只会加速验证”AI根本不行”。
3. 四道门通过后的流程
四道门全部通过后才进入：
- 模型选型（而不是一开始就纠结选哪个模型）
- POC（跑通最小任务链，用真实上下文和评测集验收）
- “业务影响 × 实现投入”排序，高影响低投入优先
- 决定扩大、缩小还是停止
不同素材中的观点
- 2026-07-15-ai-sigangqi-jiashenme-ai：本文原创提出四道门方法论。核心洞察是：AI产品经理的价值不是记住最多的模型参数，而是选对问题。功能做得越快，选错问题的代价越容易放大。“把需求入口守住，才是AI产品经理真正替团队省钱的地方。“
实用信息
AI需求可行性检查清单
□ 第一道门·用户代价
□ 找到了正在承受代价的真实用户吗？
□ 有行为、频次、成本三类证据吗？
□ 如果答案否定 → 回到用户调研，不要往下走
□ 第二道门·技术适配
□ 不用AI能解决吗？方案是什么？
□ 如果用AI，具体好在哪里？
□ 这个任务落在锯齿状前沿的哪一侧？
□ 如果常规方案更稳更便宜 → 不用AI
□ 第三道门·落地条件
□ 画出了完整任务链吗？（能看到什么/调用什么/谁来确认/追问还是转人工）
□ 关键数据都能拿到吗？
□ 工具和权限都接得上吗？
□ 如果数据/工具缺失 → 先补基础
□ 第四道门·价值验证
□ 验收标准写清楚了吗？
□ 五个维度都定义了指标吗？（结果质量/任务效率/业务结果/风险边界/单次成本）
□ 如果无法衡量 → 离线测试或暂停