产品策划面试：回答AI应用问题，别只报工具名，要讲解决问题思路

在工作这一领域当中,人工智能工具在其中得以应用呈现情况,已经是从原本较为简单的效率提升方面,演进变化成为能解决深层次工作流问题的关键所在。这篇文章借助一个真实发生的案例状况,把如何将人工智能从‘高级搜索框’进行升级成为系统性解决问题伙伴的思考框架给揭示了出来。当有面试官就人工智能应用进行询问的时候,真正在内心里期待着听到的内容是你怎样去界定问题,怎样去拆解约束条件,以及怎样去沉淀流程,而并不是仅仅只是工具名称的罗列而已。

上个月面试时，面试官问了我一个现在很常见的问题：

“你平时在工作里怎么用 AI？能不能举一个具体例子？”

这个问题其实是非常容易搞砸的。

因为好多人的最先反应，皆是将自身用过的工具以及场景报一回，写PRD，总结会议纪要，生成一个不知能否使用的Demo，生成PPT大纲，查资料等。

诚然，这些均算作运用 AI，然而，实事求是来讲，当面试官听闻诸多此类情况之后，着实难以分辨你究竟是的确具备解决问题的能力，还是仅仅将 AI 视作一个高级搜索框而已。

所以我当时没有讲这些。

我讲了一件有点狼狈的小事。

在某一回，我平常惯用的某劳工具突然间无法使用了，，账号被封禁了，，而那时我手上恰好存在一个需求需要去确认。就在那天的晚上，，还得和同事一同核对用户流程，，我整个人的节奏一下子就被打乱了。

当初，我着手开展的事项同样极为平常：首先寻觅一个临时性的应对办法予以支撑，防止当日的工作出现状况。

但忙完以后，我越想越不对。

要是一个用具已然变为我的工作基础配备了，那它陡然没法使用了，这事可就不简简单单只是“今日运气差”而已啦。实际上它揭示出了一个状况：在我的工作流程当中，存在着一个关键的步骤并非稳固的。

随后，我针对此问题再次进行了拆分。从表面情形来看，它呈现为“工具无法使用该如何处理”。

可事情要说解决的层面，关键在于，“如何能够让自身拥有一套更具稳定性，且具备可控性，同时可进行复用的AI工作环境”。

这个具有框架类特性的思维走向，实际上具备着相当程度的重要性，而这同样是后续阶段面试官最为关心留意的所在之处。

1、不要急着问 AI 答案，先把问题讲清楚

刚开始我也犯了一个很典型的错误。

我直接问 AI：“遇到这种情况怎么解决？”

那结果是，它给我的答复特别宽泛，说可更换工具，要检查网络状况，去查看服务所处状态，还得准备备用方案。每一条单独看，好像都没错，然而，每一条又都欠缺更为具体的内容。

之后，我察觉到，问题并非出在AI那里，而是在于我提出的问题太过类似于“求答案”这种形式了。

于是我换了一种方式，把它当成一个临时的产品搭子。

我先把背景交代清楚：

每天我都会借助AI去做需求梳理，去做竞品整理，去做访谈摘要，去做文档初稿；我并非技术背景，不期望方案需长期维护；成本不得太高；首次最好在两个小时内能够跑通；后续要是再碰到问题，我得清楚如何排查，而非每次都再度求助他人。

这些话说完以后，AI给出的东西明显不一样了。

它着手帮我把问题划分成几个阶段，首先是确认目标，接着是列出约束，随后是整理可选方案，最终是设计验证方式以及排错清单。

在这个过程当中，AI所具备的最为有用之处并非是“替我去做出决定”，而是能够将那一堆杂乱无章的信息转变成颇具条理的状态。

我遇到陌生概念，就让它用白话解释这个概念在流程里负责什么。

某一步我卡住了，于是把当前状态以及报错信息抛给它，让它先去判断可能存在的原因，接着按照优先级给我排查的路径。

我在使其运行成功之后，又促使它将整个流程整理成一个 SOP，其中包括之前的条件是什么，重要的步骤是什么，哪些地方容易出现失误，怎样去检验结果，再次使用时需要留意什么。

头一回，我耗费了差不多两个小时。实际上，花费时间长的并非操作自身，而是我不清楚各个环节彼此间的关联，并且也不晓得出现问题时应当先查找何处。

重新回顾流程之后，我又一次对流程进行了整理。当第二次去执行时，相同之事在大约三十分钟左右便可完成。

这比单纯说“我用 AI 提高了效率”更有说服力。

因为效率不是喊出来的，是前后对比出来的。

2、面试官想听的，其实是你怎么定义问题

讲到这里时，面试官没有追问我“你具体用了哪个工具”。

他问的是：“你当时为什么会想到把它整理成流程？”

我觉得这个问题问得很准。

很多时候，我们以为自己在解决问题，其实只是在处理症状。

用户说按钮不好用，我们立刻想改按钮；

业务说转化率低，我们立刻想加弹窗；

工具突然用不了，我们立刻去找替代品。

这些动作都可能有用，但它们不一定碰到了真正的问题。

产品经理的价值，很多时候就在于多问一句：

“这件事背后，真正不稳定的是什么？”

且回到我的那个例子当中，工具失效仅仅是表层次的现象而已。而真正存在的问题在于，我将一个处于高频运作状态的工作环节构建在了难以把控的环境之上，并且既不存在备用的流程之设定，也没有可供排查错误的清单，还没有能够重复使用的文档。

所以我后来在面试里总结成了一句话：

并非是借助 AI 将一个工具方面的问题给解决掉了，而是凭借 AI 为自身把一段工作流的稳定性给添补完整了。

这句话比“我会用 AI 写文档”更能说明问题。

3、我后来把这个案例整理成了一个小框架

这件事之后，我发现它其实可以迁移到很多工作场景里。

不论你属于产品领域，还是运营范畴，亦或是用户研究方向，又或者是内容岗位，只要你打算将“我如何运用AI去解决实际存在的问题”阐述清楚，全然能够依据这个顺序去进行复盘：

先讲场景。

别一开始就提及工具，先把你当时所从事的事情完整表述清晰，再阐明任务迫切的缘由，接着说明问题对结果产生影响的原因。

再讲问题。

务必不要仅仅讲述表面呈现之物。尝试朝着下方挖掘一个层次：它究竟是效率方面的问题，稳定性方面的问题，协作方面的问题，还是信息不对称方面的问题呢？

然后讲约束。

于实际工作当中，极少存在堪称完美的方案，预算、时间、人力、权限以及技术能力，这些方面均会对所能采取的做法产生影响，将相关约束清晰地予以说明，反倒会促使案例更具可信度。

接着讲 AI 参与了哪一段。

这一步相当关键，AI并非必然要涉足全部流程，它有可能仅仅是帮你诠释概念，解析路径情况，整理相关资料，生发出检查清单，又或者在排查错误时为你提供一个优先级顺序。

最后讲结果。

最佳的结果，并非仅仅表述为“成功了”。而是能够阐述前后所耗费时间的变化情况，以及复用的次数，合作所产生成本的变化状况，又或者是否沉淀生成了文档以及流程。

要是再朝着前面更多地走上那么一步，还能够去讲迁移，这件事情在后来有没有致使你对待其他问题的方式产生改变呢？

这才是一个完整的 AI 使用案例。

4、真正拉开差距的，不是提示词，而是问题感

现在大家都在学 AI。

有一些人收藏着工具清单，有一些人钻研着提示词，有一些人每日尝试新模型。它们固然都具备价值，然而要是放置于产品经理的语境之中，我认为更为关键的仍旧是问题感。

这些能力，AI 替代不了你。

你可以借助AI，更快速地获取信息，更迅速地整理结构，还要更快捷地形成初稿。不过呢，关于“为什么要做”，关于“做到什么程度算有效”，以及关于“哪些风险不能忽略”这几个问题，最终还是得依靠人来进行判断的。

所以，要是面试官再次询问你“怎样运用AI”，我给出的提议是，不要赶忙说出工具的名称。

讲一个真实场景。

这样讲出来的 AI 能力，就不只是“我会用工具”。

并且是：当我撞见一个实实在在的问题之际，能够进行拆解，能够去尝试，能够予以复盘，还能够将一回经验转化为下一回的效率。

这才是面试官真正想听的东西。