最近面试AI PM岗位，遇到一个让我困惑的现象。
同样是讲RAG的设计细节，有的面试官听得很专注，有的却明显兴趣缺缺。起初我以为是表达问题，后来才意识到：不是我讲得好不好，是我们根本在说不同的事。
这让我开始认真想一个问题：为什么同样是"要做AI"的公司，对AI PM的期待差异会这么大？
用技术复杂度判断企业成熟度，是一个常见的认知陷阱
很多人（包括我自己）会下意识地用技术栈来给企业分级——直接调API是初级，用Coze/Dify是中级，内部自研RAG是高级。
这个判断框架看起来合理，但其实有问题。
技术复杂度描述的是企业"用了什么"，但没有回答更关键的问题：企业现在真正面对的不确定性是什么？
一家用Dify搭了工作流的公司，可能还完全不知道自己的AI产品要交付什么业务结果；一家有算法团队的公司，可能已经在用数据驱动的方式持续迭代产品。技术复杂度和企业真实面对的问题，并不直接对应。
更有效的判断维度是：这家企业有没有明确的、可度量的AI产品化目标。
用这个维度来看，企业的AI应用现状自然分成三层，每一层面对的根本问题完全不同。
第一层：探索期——真正的问题是"值不值得做"
这类企业通常有明确的AI战略意图，但还没有落地成具体的产品目标。老板层面已经达成共识"要拥抱AI"，但往下问"做什么、先做哪个、投入多少合理"，往往没有清晰的答案。
企业的真实焦虑不是技术，是决策。
他们面对的核心不确定性是：哪个业务场景引入AI的ROI最高？现有的数据和流程条件支不支持？如果做错了方向，代价是什么？
AI在这个阶段扮演的角色，不是解决方案，而是一个需要被评估的选项。
做场景筛选时，我的判断框架大概是三个维度：
- 重复性：这个任务够不够标准化，能不能用规则描述。如果每次都需要人的主观判断，就不适合优先交给AI。
- 出错成本：AI判断错了，有没有人工兜底的机制，错误能不能被快速发现和纠正。
- 反馈可验证性：怎么知道AI做得好不好，有没有明确的验收指标。
基于这三个维度，通常的结论是：执行层、重复性高、规则可标准化的任务，优先让AI接；涉及最终决策、影响较大、出错难以挽回的判断，必须留给人。
这个阶段最常见的认知误区是：把"引入AI"本身当成目标，而不是手段。于是开始大量采购AI工具、搭建基础设施，却没有一个清晰的业务问题等待被解决。结果是投入了资源，但没有任何可度量的产出，热情在半年内消退。
第二层：交付期——真正的问题是"出在哪一层"
这类企业已经有了明确的AI产品目标，也在跑了，但效果不稳定，始终达不到预期。团队知道自己想要什么，但不知道问题出在哪里。
企业的真实焦虑不是方向，是诊断。
效果上不去的原因可能有很多：数据质量不够、工程实现有缺陷、产品设计本身就错了、或者工具选型和业务需求不匹配。这几种原因表现出来的症状可能很像，但解法完全不同。诊断能力本身，才是这个阶段最稀缺的东西。
一个典型的场景：用低代码平台搭了一个客服工作流，上线后效果不稳定，团队开始反复调Prompt，但始终没有明显改善。真正的问题可能出在工具选型阶段——当初没有认真评估平台能力边界和业务需求的匹配度，导致后续所有优化都在错误的层面上使劲。
这个阶段最常见的认知误区是：把工具能力边界的问题，误诊成了使用姿势的问题。于是不断在Prompt上做文章，却始终没有触及真正的瓶颈。
第三层：迭代期——真正的问题是"飞轮转起来了吗"
这类企业已经有稳定交付，AI产品在跑，业务结果可度量。但产品往往在某个效果水位停滞——不是因为遇到了技术天花板，而是因为没有建立从用户反馈到持续优化的闭环。
企业的真实焦虑不是能不能做，是能不能持续变好。
AI产品和传统软件产品最不一样的地方在于：它不是一次设计完就固定的，而是动态收敛的。用户每一次对AI输出的修改和反馈，都是潜在的优化信号。如果这些信号没有被系统性地收集、分析和反哺到迭代中，产品就会停在一个局部最优点上，再怎么调也很难突破。
数据飞轮的基本逻辑是：持续收集Bad Case，定期分析根因，反哺迭代，让AI的能力边界随着使用不断被校准。这个机制建立起来之前，讨论微调或更复杂的技术优化，往往是在错误的层面上使劲——基础没打稳，优化的方向本身就可能跑偏。
这个阶段最常见的认知误区是：跳过飞轮直接谈技术升级。数据积累不足、反馈机制不完善，就开始讨论微调——结果优化的基础本身有问题，方向跑偏了却很难察觉。
三层对照
不确定性在决策层。用AI场景筛选框架（重复性 × 出错成本 × 验证可行性）帮助企业锁定正确的起点，避免把"引入AI"本身当成目标。
不确定性在诊断层。效果不稳定的根因可能是数据、工程、设计或选型任一环节，解法完全不同。最忌把工具边界问题误诊成使用姿势问题。
不确定性在优化层。有稳定交付但效果停滞，通常缺的是Bad Case收集 → 根因分析 → 反哺迭代的闭环，而不是更复杂的技术升级。