在职场中，AI工具的应用已从简单的效率提升演变为解决深层工作流问题的关键。本文通过一个真实案例，揭示了如何将AI从‘高级搜索框’升级为系统性解决问题伙伴的思考框架。当面试官询问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 在中间帮你减少了哪些试错。
• 再讲这件事最后有没有被沉淀成流程。

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

而是：我遇到一个真实问题时，能拆、能试、能复盘，也能把一次经验变成下一次的效率。

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