一个传统互联网产品经理进入 AI 一线后的真实观察

我在传统互联网行业做了将近 10 年产品经理，后来进入一家 AI 硬件创业公司。真正参与 AI 产品之后，我对职业转型、产品实践和工作方式都有了新的认识。

过去的产品经验依然有价值，但模型、Agent、语音交互和 AI 辅助编程（AI Coding）带来了新的问题。只有进入实际工作场景，才能慢慢理解这些技术会怎样影响产品，以及自己需要补上哪些能力。

我为什么进入 AI 行业？

我不是 AI 科班出身，过去主要做传统互联网产品、平台业务和用户增长。比如，我曾参与一个马拉松赛事服务平台，涉及赛事组织者、跑者，以及平台自身的业务运营。

这些年，我积累得比较多的是用户需求分析、业务流程设计、产品规划、数据分析，以及跨团队推动项目落地的能力。

后来关注 AI，不完全是因为它热门。我发现，很多事情原来的实现方式正在改变。

以前做一个产品，从想法到落地，通常需要产品、设计、研发、测试等多个角色协作。产品经理定义问题和需求，研发负责实现。现在，借助大模型和 AI Coding，一些原本需要专业开发资源才能验证的想法，产品经理自己也可以先尝试做出来。

这让我意识到，软件的生产方式可能正在发生变化。

后来，我选择进入一家 AI 硬件创业公司，开始参与 AI 产品工作。这对我来说是一次很大的转变。

从 App 设计，走向软硬件协同

过去做互联网产品，我们更多关注用户需求、业务流程、功能设计和产品数据。进入 AI 硬件领域之后，除了 App 设计和用户操作，还要考虑硬件交互、语音唤醒、网络连接、设备状态，以及 AI 如何理解自然语言、调用工具完成任务。

以前，我可能不需要深入理解语音识别（ASR）、大语言模型（LLM）、语音合成（TTS）这些模块。现在，我必须知道它们各自解决什么问题，又会怎样影响产品体验。

开始设计模型的不确定性

进入这个行业之后，我最大的认知变化，是开始重视 AI 产品中的不确定性。

传统软件的很多功能逻辑是预先定义好的：用户输入什么，系统执行什么，最后返回什么，基本可控。AI 产品中，模型可能理解错用户意图、生成不准确的内容，也可能在调用工具时出问题。

所以，产品设计还要回答：模型出错怎么办？信息不完整怎么办？任务执行失败怎么办？怎样判断 AI 最终交付的结果是否可靠？

过去积累的产品能力并没有失效，只是需要在新的技术环境下重新组合。 对我来说，这次转型是在过去对用户、业务和产品的理解之上，结合 AI 技术，形成新的能力。

没有 AI 背景，怎么判断自己适合哪个方向？

很多人一提到转型 AI，第一反应就是：是不是要学 Python？是不是要学机器学习？是不是必须是计算机专业？

我觉得，先要弄清楚自己想做哪类工作。AI 行业有算法工程师，也有很多其他角色。一个 AI 产品从技术研发到商业落地，需要不同类型的人参与。

粗略划分，我会把它分成三个层次：

基础技术层：模型研发、算法工程、推理优化、数据工程等，主要解决模型本身的能力问题。
产品和解决方案层：AI 产品经理、Agent 产品经理、解决方案架构师等，主要把模型能力转化为用户需要的产品和服务。
应用和交付层：AI 应用开发、Agent 工程、工作流自动化等，主要把模型、工具和业务流程组合起来，构建可以使用的应用。

从已有能力寻找方向

选择方向时，我建议先盘点过去积累的能力。

产品经理可以往 AI 产品经理、Agent 产品经理方向发展；后端研发可以探索 AI 应用和 Agent 工程；设计师可以结合 AI 工具做产品设计和创意应用；运营人员可以尝试 AI 内容生产和自动化工作流。

有多年行业经验的人，也值得关注。比如，一个熟悉医疗行业的人，未必需要从头学算法。他对医疗流程、专业场景和真实需求的理解，本身就是优势。如果再结合 AI 技术，就可能找到新的机会。

我比较认同的转型思路，是在原有能力的基础上，看看 AI 能帮自己多做些什么。

以产品经理为例，过去主要考虑用户需求、业务流程、功能设计和产品体验。做 AI 产品，还要考虑模型能否理解用户意图、上下文是否完整、输出是否可靠、工具能否正确执行，以及出错后如何处理。

比如，用户说“帮我安排明天下午的会议”，产品就需要判断：用户想创建会议还是查询会议？有没有指定时间和参会人？日历是否有冲突？信息不完整时要不要追问？最后有没有成功创建？

这要求 AI 产品经理把模型能力、工具和用户任务组织起来，同时设计和管理模型带来的不确定性。

技术需要学到什么程度？

没有技术背景，需要学到什么程度？我会分成三个层次。

第一，技术认知必须具备。 要了解大模型的基本工作方式、Token、上下文窗口、Prompt、幻觉、模型能力边界和模型接口（API）。不一定需要掌握背后的数学原理，但要知道它们会怎样影响产品。

第二，建议具备技术应用能力。 自己调用模型、调试 Prompt、使用工作流工具，甚至搭建一个简单的 AI 应用或 Agent。动手做过，才更容易理解技术能做到什么、做不到什么。

第三，技术开发能力要看岗位。 想做算法工程师，就需要系统学习编程、数学和机器学习。想做 AI 产品经理，不一定要独立开发复杂系统，但至少要看懂基本技术方案，理解 API、数据流和工程约束。

转型前，先回答三个问题

技术深度可以因岗位而异，但不能完全没有技术理解。如果现在想转型 AI，我建议先问自己三个问题：

我过去擅长解决什么问题？
AI 能不能帮助我更高效、低成本，或者用新的方式解决这些问题？
为了完成这件事，我还需要补齐什么能力？

不要因为自己不是计算机专业，就觉得 AI 和自己没有关系；也不要因为工具降低了门槛，就低估专业能力的价值。一个既懂某个领域，又能用 AI 把问题解决得更好的人，更有竞争力。

AI 产品经理到底在做什么？结合现有产品拆解真实工作

很多人可能觉得，接一个大模型 API，设计聊天界面，再写一些 Prompt，就完成了一款 AI 产品。这些工作完成了技术集成，但产品有没有价值，还要看它能否可靠地解决用户的问题。

传统互联网产品更多是按照确定的规则和流程设计功能。用户点击按钮，系统按预先定义的逻辑执行，返回一个相对确定的结果。

AI 产品面对的需求，往往是用自然、模糊、不完整的语言表达出来的。模型需要理解意图、结合上下文判断，必要时调用外部工具完成任务。

我正在做的产品是一款随身 AI 助手设备，用户可以通过语音向它发出指令。

比如，用户唤醒设备后说：“帮我安排明天下午的会议。”从这句话到任务完成，需要经过几个环节：

KWS（语音唤醒）：识别用户是否说出了唤醒词。
ASR（语音识别）：把用户说的话转换成文本。
LLM（大语言模型）：理解用户意图，识别任务类型，提取关键信息。
Agent：涉及实际操作时，判断调用什么工具、传递什么参数，以及是否需要追问用户。
TTS（语音合成）：把执行结果转换成语音，反馈给用户。

每个技术模块，都对应着具体的产品问题：唤醒是否灵敏，会不会误唤醒？嘈杂环境下，语音识别是否准确？模型有没有理解用户真正的意图？Agent 有没有选对工具、传对参数？语音反馈是否自然、及时？

产品经理不一定要亲自实现每个模块，但必须知道它们的作用、能力边界，以及出问题时会怎样影响用户体验。

把不确定的需求变成可验证的任务

还是“帮我安排明天下午的会议”这个例子。它有很多不确定的地方：用户想创建会议还是查询会议？具体几点？持续多久？有没有参会人？日历有没有冲突？

信息不完整时，AI 应该追问，还是根据上下文推断？工具执行失败后，又该怎么反馈？这些都需要产品经理设计处理机制。

信息完整、意图明确时，可以执行。
缺少必要信息时，需要追问。
存在歧义或冲突时，需要用户确认。
工具调用失败时，必须明确告知用户，不能假装已经完成。

模型理解了需求，不代表任务已经执行；模型说完成了，也不代表任务真的完成了。

比如，模型正确识别了创建会议的意图，也生成了正确参数，但日历接口可能超时，或者因为权限问题调用失败。只关注回答是否流畅，就会忽略执行环节的问题。

因此，AI 产品经理需要把完整任务拆成可验证的步骤，并明确每一步成功和失败的标准。

评估用户有没有完成目标

除了传统产品的使用率、转化率和留存率，AI 产品还需要关注意图识别准确率、参数抽取准确率、任务规划正确率、工具调用成功率，以及最终的端到端任务成功率。

响应延迟、用户纠错率和任务放弃率也需要关注。

这里有两点要分清。

第一，单个模块表现好，不代表整体体验就好。比如，ASR 识别得很准确，但大模型理解错了意图，任务仍然会失败。

第二，模型回答正确，不代表用户任务成功。我们需要确认用户是否完成了目标，不能只看模型有没有生成一个合理的答案。

从 Demo 到真正的产品，还有哪些问题？

现在，接入模型、写好 Prompt、设计界面，可能很快就能做出一个效果惊艳的演示版本（Demo）。但能演示，还不足以说明产品成立。

像我正在做的这类软硬件结合产品，除了模型，还涉及设备连接、网络、功耗、语音交互、App 和后台服务。在办公室网络良好的环境里运行正常，不代表用户在户外、通勤或嘈杂环境下也能获得同样的体验。

还要回答：用户是否真的需要这个功能？会不会持续使用？它有没有改变用户原来的行为？用户愿不愿意付费？这些问题不能靠技术 Demo 回答。

我现在越来越警惕一种情况：技术上可以实现，用户却未必需要；功能上可以跑通，却还没有证明产品价值。

AI 产品经理最终还是要回到用户任务和业务价值上，关注用户到底完成了什么。

AI Coding：普通人真的可以借助 AI 改变工作方式吗？

最近，我很明显地感受到，AI Coding 正在改变产品经理的工作方式。

以前有了想法，通常要先写需求文档，找设计师出设计稿，再与研发沟通、等待开发，最后才能看到可以运行的版本。这个过程有它的必要性，但如果只是想验证一个想法，成本往往比较高。

现在，产品经理可以借助 AI，自己搭建基础页面、实现简单交互，甚至做出一个可以运行的 Demo。

从设计规范到真机迭代

在这款产品的 App 实践中，我使用 Codex 和 Flutter 推进客户端工作。当时团队没有完整的视觉和 UI 设计资源，App 又需要持续迭代。我就尝试先用 AI 整理 UI 参考、建立设计规范，再把页面和功能拆成小任务，让 Codex 分阶段实现。

大致工作流程是这样的：

收集 UI 参考：先明确页面结构、视觉风格和交互方式，再交给 AI 实现。
建立设计系统：定义颜色、字体、间距、组件和页面规范，减少不同页面之间的视觉差异。
拆分开发任务：把页面、组件和交互拆成足够小的任务，逐步实现。
真机验证：在真实设备上运行，检查布局、交互、性能和实际使用效果。
截图迭代：通过真机截图发现问题，再给 AI 明确的修改指令，持续优化。

这段实践让我感受到，AI Coding 确实降低了产品经理验证想法的门槛。后来，我也因为这方面的实践，获得了公司内部的 Spot Award。

AI 能写代码，质量仍需把关

但我不认为，产品经理因此就能完全取代程序员。

AI 生成的代码不一定正确，也不一定理解整个项目的架构。它可能实现了表面功能，却留下性能、维护性或兼容性问题。尤其是账号、支付、设备连接和隐私数据等关键模块，仍然需要专业研发审查和把关。

AI Coding 降低了代码生产和试错的成本，让更多非研发角色能够参与原型验证和问题探索。软件工程对质量的要求依然存在。

其他岗位也可以尝试：运营人员做内容批处理工具，分析人员搭建数据处理小工具，设计师快速验证交互原型，管理者把日常重复流程做成自动化工具。

我建议先找工作中一个真实、具体、反复出现的问题，尝试用 AI 把它做成可以运行的小工具，不必一开始就做完整产品。

真正完成一次从想法到可运行结果的过程，才会对 AI Coding 有更实际的理解。它不一定让每个人都成为程序员，但让更多人有机会把想法变成可以运行、可以验证的东西。

如果今天重新规划职业，我会怎么做？

首先，我不会因为焦虑就盲目转型。

AI 发展很快，每隔一段时间就有新模型、新工具和新岗位。很容易看到别人学什么就跟着学，看到某个岗位热门，就觉得自己也应该转过去。但职业选择不能只看热点。

AI 正在进入医疗、金融、教育、制造、供应链和企业管理等行业。机会可能在模型公司，也可能在传统行业的业务升级和流程重构中。与其追逐每个新工具，我更愿意先找到自己擅长、也愿意长期投入的领域。

如果给想转型 AI 的人一个具体建议，我会设计一个 30 天的低成本验证计划。

第 1 周：了解岗位和市场

找 20 个自己感兴趣的 AI 岗位，认真看职责和要求。把高频技能和能力要求整理出来，对照自己已经具备什么、还缺什么，不要只看岗位名称。

第 2 周：补齐基础认知

学习大模型、API、Prompt、上下文、幻觉等基础概念。如果目标方向涉及 RAG、Agent 或 Tool Calling，也要了解它们的基本工作方式。至少自己调用一次模型，不要只停留在看文章和视频。

第 3 周：做一个真实项目

从熟悉的工作或生活场景中找一个具体问题，尝试用 AI 做出可以运行的解决方案，尽量不要止步于一个简单的聊天机器人。

第 4 周：验证和复盘

找真实用户体验，记录出错或效果不好的情况（Bad Case），看看方案是否真的解决了问题。整理项目过程、方案、效果和不足，形成一个可以展示的作品，再尝试投递岗位，获取市场反馈。

这 30 天不能保证转型成功，但可以帮助自己验证：是否对这个方向有兴趣，是否有能力继续学习和实践，以及市场是否需要自己的能力。

选择公司，也要验证产品价值

选择公司时，也要多看一层。进入 AI 公司，不等于遇到了好机会。尤其是创业公司，除了产品方向和技术能力，还要看组织机制、团队协作方式，以及有没有真实用户和商业验证。

如果一个产品长期只有内部测试，没有真实用户持续使用，也没有付费验证，那么它的产品价值和商业模式仍然需要证明。判断机会时，要看公司是否真的在解决问题。

如果今天重新规划职业，我会重点培养三种能力：

专业能力：真正理解某个行业、领域或业务问题。
AI 协作能力：借助 AI 提高效率、扩展能力，完成过去难以完成的任务。
独立判断能力：判断什么问题值得解决、什么结果值得相信，以及什么时候不应该依赖 AI。

这三种能力结合起来，才可能形成长期竞争力。对我来说，转型 AI 的意义，是借助新技术，放大自己原有的专业能力，并创造新的价值。