哈喽大家好，我是欧呦，这篇文章将为大家分享如何从 0 到 1 成为一名 AI 产品经理——包括我自己的两段转型经历、在 AI 初创公司做产品经理和传统公司的真实工作差异、需要补齐哪些研发与 AI 认知，以及在没有 AI 履历的前提下，如何做出第一个个人作品并在社交媒体上找到 AI 赛道的工作。

我目前的主业是在一家 AI 初创公司负责产品设计和产品开发，同时也在制作 AI 相关的内容，参与培训和直播分享。

回头看，我进入 AI 产品经理这个岗位，经历了两次变化：先从前端开发转到传统产品经理，再通过持续使用 AI 工具、自己动手开发 AI 应用和公开输出内容，在过去一年里先后进入了 3 家真正开发 AI 应用和 Agent 的公司。

我是如何一步步转到 AI 产品经理的

1. 从前端开发转到传统产品经理

刚毕业时，我的主业是前端开发，找的也是前端开发相关的工作。大学期间，我和同学一起组建过外包工作室，开发过不少小程序和网页，毕业时已经完成了十几个项目。刚开始接触前端时，我觉得这份工作很新奇，也确实喜欢过一段时间。

真正开始工作以后，我逐渐发现，前端工程师很多时候需要根据原型图把应用实现出来，能够深入研究的部分主要是工程化、代码优化和组件调整。业务上的决定权比较少，大量任务属于基础的增删查改，创造性和挑战性都有限。即使换到规模更大的公司，工作的性质也未必会发生变化。

我更希望往业务侧靠近，参与产品本身的设计和判断，于是开始阅读产品经理相关的书籍和课程。后来，公司准备开发一个新版本和新产品，需要先整理文档和设计，研发才能开始实现。领导询问有没有人愿意尝试转为产品经理时，我主动报名了。

这次转岗并不是临时起意。此前我和公司的产品经理协作比较多，也会主动参加 PRD（产品需求文档）评审。如果我认为某个交互流程设计得不够好，就会直接提出反馈。大学期间积累的项目经验，让我接触过很多组件；开发应用时，我也习惯参考其他产品，所以对常见的交互形态比较熟悉。

前端经验还帮助我更快掌握产品经理常用的工具，比如 Figma 和原型设计工具。前端开发中经常接触组件化和复用，使用 Figma 时，我很快搭建出了组件库，后续页面可以通过组合组件完成。

当时我所在的公司叫 API7.ai，很多人看到名字里带 .ai，会以为我一毕业就在 AI 行业。其实那是一家做云原生 API 网关的基础软件公司，业务和 AI 没有任何关系。产品经理需要理解技术和业务之间的关系，我本身有技术背景，转到产品岗位后更容易理解这部分工作。转岗之后，因为公司规模比较小，我仍然承担了一部分前端开发工作，从单纯的前端开发变成了同时参与产品设计和开发的人。

2. 从零 AI 履历到一年入职三家 AI 应用公司

产品经理是一个非常依赖前置业务经验的岗位。比如你本来是一个做 C 端产品的产品经理，突然跳槽去做 B 端的基础软件产品，如果你在这方面一点积累都没有，企业为什么要选择你呢？虽然学习能力是可以迁移的，但很多公司不希望你进来之后再去学习，而是希望你一进来就可以直接干活，甚至最好能带着其他人一起干活。

我在基础软件公司的这段背景，对于我去找 AI 相关的工作没有任何加成。

但在 ChatGPT 和各类 AI 编程工具出现后，我开始从日常使用 AI 工具转向亲自开发 AI 应用，先后做出了「学习卡盒」「Text Well」和 AI 狼人杀（wolfcha） 等产品，并把开发过程和产品思考发在社交媒体上。

正是依靠这些自己做出来的产品和持续的内容输出，在过去一年时间里，我先后入职了 3 家不同类型的 AI 应用公司，包括做通用型 AI Agent 的超级麦吉、做 AIGC 画布产品的 OpenCreator，以及做海外营销 Agent 的 MuseOn。

AI 初创公司里的产品经理，和传统公司有什么不同？

我对 AI 产品经理的理解有两个角度：

第一个角度是**「用 AI 来做事的产品经理」**：现在各种 AI 工具很流行，每个产品经理多少都会用到一些，比如用 AI 写文档、做原型、做设计图，或者直接上手改应用、改前端。

第二个角度是**「负责 AI 产品的产品经理」**：这类人需要理解模型的能力边界，把 AI 的能力变成用户价值，对 AI 的理解要比普通产品经理更深。

当我真正进入这几家 AI 初创公司工作后，我发现里面的日常工作方式，和在传统公司做产品经理的差别是非常大的。

传统产品经理与 AI 初创公司产品经理的日常工作流对比

1. 传统公司的产品流程：写 PRD、画静态原型与多轮交接

在传统的公司里，产品经理的职责非常标准：你需要先接住领导给的需求、产品总监或其他同事给的需求，或者是用户的需求。拿到这些需求后，你要去拆解分析它们到底是不是真需求，把一些笼统的想法转化成具体的产品功能需求。

下一步就是写 PRD。在 PRD 里面，一般来说你要写清楚这件事情的需求背景、我们怎么样解决这个问题、用户旅程是什么样的、功能设计是什么样的、需要修改哪些模块与逻辑、怎么样排期、如何验收，并且要把静态原型图做出来附上去。

写完文档和原型图之后，你要拿着这套产品设计方案去找 UI 设计师和研发确认可行性，确认没问题后再由设计师去做 UI 稿。最后再去跟研发开会宣讲，让功能实际排期落地，等研发做完之后你自己再去验收，最终上线。在传统流程里，光是一个 PRD 的对齐和两轮评审，最快也要一个星期，稍大的功能往往要两三个星期。

2. AI 初创公司的产品流程：基于存量代码直接跑通预览环境与合并上线

而在一些 AI 初创公司里面，我承担的其实不是一个传统产品经理的职责。

我同样负责把需求转化成产品功能，中间的产品设计是我来做的；但产品设计完成之后，我会直接用 Vibe Coding（通过自然语言让 AI 编写代码）把可交互的页面写出来。如果这是我自己独立负责的功能，我甚至不需要先去找其他人过原型图，而是可以直接把它开发出来，放到产品的线上预览环境（比如 Vercel 的预览环境，或者代码分支上的预览环境）里，直接在真实产品上面给大家看现在的效果怎么样。

很多人可能会觉得直接写代码比画原型图难，其实恰恰相反：**相较于传统产品经理从零去画一套原型图，在项目里直接用 Vibe Coding 实现出来的难度反而更低。**因为项目里本来就有现成的存量代码、组件和样式，基于存量代码让 AI 把新页面写出来，比自己去画静态原型图更简单，还原度也高得多。

此时，大家直接对着线上预览环境看效果。如果评审通过，大家觉得线上的功能已经没问题了，直接合并 PR（Pull Request，代码合并请求）就正式上线了。

在这个过程中，由于现在 AI 写代码的能力已经很强了，大多数简单的前端界面和后端逻辑，我们都可以直接让 AI 来实现。只有遇到非常重的后端任务——比如涉及复杂的数据表操作，或者涉及架构上的改动、可能导致性能问题的部分——我们才会在 UI 预览评审通过之后，拉一位后端研发同学来协助，把后端的复杂接口补全，对接完成之后自己验收上线。

3. 从「T 型人才」走向「方块型人才」

过去行业里常说的是「T 型人才」：在一个方向深入，其他方向只到了解的层面。

但在 AI 时代，AI 拉高了能力的地板，帮助我们补齐了短板。现在做产品的关键往往不是会不会做，而是谁先把可体验的版本做出来。所以我把现在更需要的能力组合称为**「方块型人才」**：在多个领域都达到一定水平，产品的每个流程都能做到八十分。

以我自己为例，我可以负责产品设计，也可以通过 Vibe Coding 做出一个真正能够运行的产品原型甚至直接开发应用，同时还可以制作内容去推广产品。在不少 AI Native（AI 原生）公司里，岗位的边界都在融合，设计师在向产品经理和工程师延伸，产品经理也可以往设计、工程和宣发多走一步。

成为 AI 产品经理需要补齐哪些能力？应该怎么学？

1. 为什么 AI 产品经理不能对技术一窍不通？

看到需要直接在存量代码上做功能、提 PR，不少非技术背景的同学可能会问：如果我不懂代码，还能不能做 AI 产品经理？

我的看法是：新时代的产品经理确实需要具备一些基础研发的知识。AI 公司在招 AI 产品经理的时候，也不会去招一个对技术一窍不通的人——因为如果你对技术一窍不通，你是没有办法负责一个技术产品、也没法做方案决策的。

举一个很具体的例子：假设我们需要在产品里做一个「AI 生成 PPT」的功能，作为 AI 产品经理，我主要做的是基于 AI 能够做到的能力去设计产品功能。那此时我们就要思考 AI 怎么样去做 PPT。AI 做 PPT 的实现方式有很多种，比如可以用 HTML 去渲染生成，也可以直接用 .pptx 文件格式去生成。如果你作为一个负责 AI 产品的产品经理，连基础的 HTML 是什么都不了解，那是没有办法做这个产品决策的。

2. 一个优秀的 AI 产品经理必须了解的两类知识

具体来说，我认为需要重点补齐两块认知：

第一块是基础研发概念。包括常见的技术栈选型、不同技术栈各有什么优势、有哪些常用的组件库，以及基础的网络知识、开发知识和系统知识——比如什么是 SSR（服务端渲染）、HTTP 和 HTTPS 是什么、TS（TypeScript）和 JS（JavaScript）的区别是什么，以及组件化、函数化这些基础概念。

第二块是AI 工程概念与模型体感。AI 产品经理需要了解什么是上下文工程（Context Engineering）、Agent 的工具设计（Tool Design），并对市面上大多数主流的 AI Agent 有一定基础的了解（关于主流 Agent 工具的对比与配置，可以参考前面的 《AI Agent 推荐与环境配置》）。同时还要知道 TPS（每秒生成 Token 速度）是什么、怎么样去调用外部大模型的 API、它们是怎么样传参的、流式传输是什么、JSON 结构化响应是什么。

除此以外，还要清楚不同模型在实际场景里有什么样的表现：哪个模型审美比较好、哪个模型写代码比较强、哪个模型说话更有人味、哪个模型性价比比较高。这些都是一个优秀的 AI 产品经理必须了解的。

3. 新时代的学习方式：基于实战去构建一个 AI 应用

听到这么多概念，大家不用被吓到，因为现在学这些知识，跟传统时代的学习方式已经完全不一样了。

以前我学前端的时候，需要去看很多课程，然后自己一行一行去手敲代码。但现在我们不需要手敲代码了，我更建议大家基于实战去学习——也就是直接动手去构建一个属于自己的 AI 应用，我自己其实就是这样走过来的。

早期 ChatGPT 推出以后，我也和很多人一样，只是用 AI 工具来提升日常效率，比如用它写文章、做翻译，或者付费使用文心一言来协助处理中文 PRD 文档和头脑风暴；写代码时也用过通义灵码、MarsCode，后来切换到 Cursor、Claude Code 和 Codex。

但对我成长帮助最大的事情，还是亲自开发第一个 AI 应用。单纯使用 AI 工具，和把 AI 能力放进一个应用里，是两种完全不同的经验。

我最早开发的 AI 应用叫「学习卡盒」，是一个类似 Anki 学习卡的背单词小程序。它有正反两面的卡片，用户可以创建卡盒。我在里面加入了 AI 功能：输入一篇文章后自动提取单词，也可以给出一个主题，让它生成四级相关的单词并自动生成词卡；卡盒建立以后，还可以基于卡片生成选择题和填空题。

在做「学习卡盒」之前，我顶多算是有一些前端的背景，但对于 AI 底层到底是怎么工作的，我其实一窍不通——我甚至连「大模型本身不会自动记住上一轮对话，所谓的记忆机制是通过每一次请求把全量的历史上下文重新传给它来实现的」这件事都不知道，当时在实际调用接口看到之后我才觉得很震惊。

正是这个小程序让我建立了实现 AI 应用的基础认知。在开发过程中，我不得不去处理几个具体问题：如何调用 AI 大模型接口、如何约束模型返回规范的 JSON、如何把响应渲染到 UI 上，以及怎样控制输出长度让结果更快展示出来。

也是在做这个产品的过程中，DeepSeek V3 发布了。当时它在海外已经有热度，在国内还没有那么火。我把 DeepSeek V3 接入学习卡盒后，需要权衡不同模型的速度、效果和价格，实际对比下来觉得它的效果很好、价格也比较低。因为我已经拿它和其他模型在真实产品里做过对比，这种判断和单纯听说某个模型很强完全不一样，我能够具体感受到模型之间的差距。

学习卡盒上线后的前两天，依靠小程序内置搜索的流量，第一天有几百个用户，第二天有上千个用户；但第三天因为备案问题搜索权限被关闭，等备案完成就只剩下十几个用户了。虽然第一个产品最后没有明显增长，但它让我真正理解了 AI 模型的能力边界，也让我搞懂了如何实现一个 AI 应用。

如何做出第一个属于自己的 AI 产品？

1. 选什么样的练手项目：从解决个人需求的「实用小工具」切入

很多同学想动手做第一个 AI 产品时，不知道该选什么方向。我觉得选择什么样的练手项目，主要取决于你自己的个人需求。

我更推荐大家做一些实用的小工具。因为小工具本身有明确的使用需求；而且大家如果没有专业 UI 设计的背景，其实很难一上来做出 UI 非常惊艳的作品。所以从你自己的真实痛点出发，做一个实用的、带一点自己小巧思的工具，再在 UI/UX 上稍微打磨一下发出来，你就拥有了一个属于自己的 AI 作品，可以作为简历和社交媒体上的背书。

2. 在实用小工具里加入自己的产品巧思与体验打磨

对我影响更大的第二个 AI 产品是「Text Well」，它就是一个从我个人需求出发的文本润色小工具。

这个想法来自我担任产品经理时写 PRD 的经历。那时很多 PRD 是手动输入的，难免会出现错别字，整篇文档里出现明显错误会让文档显得不够专业。AI 工具出现后，检查错别字大致有两种常规做法：一是把整篇文章交给 AI 指出错别字，人再手动逐个修改，这样很麻烦；二是让 AI 直接改完返回整篇文章，但 AI 很容易顺手改动原本没有问题的句子，后续重新通读核对的成本很高。

所以我把 Text Well 设计成了中间的处理方式：只定位并标注正文里的每个小问题，让用户在旁边逐项选择「应用」或「忽略」，把修改权保留在用户手里。

因为 Text Well 的基础场景比较简单，我把更多时间放在了产品整体的表达、去掉界面的 AI 味以及交互体验上，并加入了一个很有意思的功能——「AI 评审团」：

  • 我设想用户写完一份 PRD 后，可以模拟同事、老板或者目标用户来评审；
  • 应用会动态生成三个不同身份的模拟评审者（比如工业设计师、数字游民、软件工程师），让他们围绕内容打分、评论和纠错；
  • 正文里会显示不同颜色的标注，如果两位评审者标注了同一句话，颜色还会产生渐变。

在设计这个功能时，模型响应速度也是产品设计的一部分。用户不可能愿意在评审过程中干等三四分钟直到所有评论生成完毕，所以我专门测试了多个模型，挑选能够更快生成评论的方案。

后来我和小伙伴参加黑客松，又用两天时间开发并上线了 AI 狼人杀（wolfcha）。能够在两天内完成并把 UI 打磨得没有很重的 AI 味，靠的就是之前积累的 AI 编程工具经验，以及把 Text Well 里的拟人化设计迁移过来。在狼人杀里，不同角色先后发言，同样需要处理好模型速度、等待时间和提前预加载下一个角色发言的体验问题。

3. 做个人产品的「隐形收益」

如果只看直接的商业收入，无论是早期的 Text Well（在上线订阅功能前一直免费），还是 Token 开销高、用户付费意愿弱的 AI 狼人杀，它们在当时都算不上赚钱。

但做产品和持续输出，会带来很多订阅收入之外的隐形收益。

我围绕 Text Well 的功能录制了产品 Demo 发到社交媒体上，虽然当时只有几百个粉丝、一条内容拿了 100 多个赞，却让一些独立开发者和大公司的负责人注意到了我。后来我跳槽去第一家做 AI 的公司，正是因为那家公司的负责人看到了 Text Well，觉得产品设计有巧思、又结合了 AI 功能，他们在做类似功能时参考过我的产品，于是主动联系我询问是否愿意加入。

对我来说，一个新的工作机会，比应用每个月赚几百元或几千元更有价值。一个自己开发出来的产品本身就是最好的简历，它不仅能证明你的动手能力，还能直观体现你的产品判断与审美上限。