AI时代的产品经理：从焦虑到突围

最近和几个产品经理同行聊天，大家都在说同一个问题：AI工具一天比一天强，但我们的工作方式好像还停留在十年前。有人还在吭哧吭哧画几百页的原型，然后贴满密密麻麻的批注，开发看到头皮发麻，测试翻到手抽筋。有人已经开始用AI写PRD，但生成的内容要么太空泛，要么根本不符合实际业务。这种焦虑感很真实，因为我们能感受到变化正在发生，但又不知道该怎么适应。

我也在不断地摸索和试错，踩过一些坑，也尝到了一些甜头。这段时间的实践让我意识到，AI时代产品经理的工作方式需要重新思考，但这不是简单地"用AI替代人工"，而是要理解AI的能力边界，然后重新设计我们的工作流程。今天想把这些思考和实践整理出来，希望能给不同阶段的产品经理一些启发。

第一阶段：用AI理清业务逻辑，而不是让AI生成需求

接手新项目时，我们往往面对十几份行业文档、三五张Excel表格、一堆微信聊天记录，有时候还有老板随口说的几句话。过去我们要花大量时间梳理背景、理清业务流程，光整理资料就要好几天。现在我的做法是把这些原始资料全部扔给AI，先让它帮我整理出行业背景和业务流程。

但这里有个关键点：不要指望AI一次性生成完美的文档。我通常会用ClaudeCode或OpenCode这类智能体平台的"plan模式"和AI逐步探讨。先让AI给出业务流程的大概步骤，然后针对每个步骤追问："这个环节有没有考虑异常情况？如果用户没有权限怎么办？如果数据校验不通过怎么处理？有没有更好的办法？"每确认一个点，就让AI把对应的内容补充到文档里。这样一轮轮下来，就像和一位熟悉业务的同事在讨论，最后会得到一份比较完整的业务文档。

这个过程的核心是：AI帮我们加速思考，而不是替我们思考。我们的角色从"资料整理员"升级成了"业务逻辑的审查官"。这个转变很重要，因为它让我们能把精力集中在真正需要人类判断的地方——理解业务的本质、发现隐藏的需求、预见可能的风险。

这个阶段的产出物我叫"草稿版的业务需求文档"，它主要描述的是"业务上要做什么"，而不是"系统要怎么做"。我建议用Markdown格式写，因为Markdown是结构化的，不像Word文档那样干扰信息多，AI能更好地读取和理解。等人工仔细校审修改后，这份文档就成了后面所有工作的基础。

我一直认为，AI时代文档变得更重要了。但这里说的文档，不是流水账式的PRD，而是一份结构化的、能被AI理解的需求说明。从第一步开始，我们就在为后续的AI协作打基础。

第二阶段：沉淀规范，让AI成为你的"专属助理"

每家公司的前端开发都有自己的习惯：按钮的命名规范、输入框的长度限制、日期选择器的格式、分页组件的尺寸、弹窗的标题字号。这些细节如果每次都要重复跟AI说，不仅累，而且容易出错。更重要的是，不同项目之间可能会因为沟通不一致而出现风格差异，影响用户体验。

我的做法是和前端同学一起把公司内部项目的前端代码或设计规范文档交给AI去分析，让它总结出常用的字段类型、长度、默认值、公共方法、交互约束、组件尺寸等，整理成一份规范文档。然后把这套规范做成一个"skill"（技能），让ClaudeCode这种智能体平台可以随时调用。

你可以把skill理解成AI的一个"插件"或"记忆包"。在ClaudeCode里，你可以加载自定义的skill，这样AI在生成代码或界面时，就会自动遵循你公司的规范，不用你每句话都叮嘱一遍。这就像给AI配了一本"公司内部设计手册"，它干活的时候会随时翻看。

而且这个skill是可以不断优化的。随着项目迭代，前端规范也会变化——比如组件库升级了、设计语言更新了，我们只需要把最新的规范交给AI重新学习，更新skill文件就行。下一个项目直接复用，效率越来越高。

同时，我们还需要建立行业知识库。产品经理不仅要懂自己公司的业务，还得懂行业。比如做医疗的，得知道DICOM标准、HL7协议；做电商的，得了解交易流程、库存管理规范；做金融的，得熟悉支付清算规则、监管要求。这些知识如果每次都要靠自己去查，效率很低。

我的做法是把行业通用知识、行业书籍、国家标准、行业标准、相关文献等资料收集起来，做向量化处理，搭建一个知识库（RAG，即检索增强生成）。简单说，就是把一堆文档转成AI能快速检索的形式。当AI回答业务问题时，会先去这个知识库里找依据，而不是凭空瞎编。对于做RAG有难度的同学，可以把所有参考资料放在同一个目录下，让AI去读就好了。现在的大模型上下文已经很大了，消化基本书还是没问题的。

这样做还有一个好处：可以提炼出项目里要用到的专业术语，统一叫法。比如一个字段到底是叫"订单编号"还是"交易流水号"？有了知识库，AI会帮我们保持一致，整个团队沟通起来也顺畅很多。这其实就是把行业知识和项目背景统一起来，让AI在同一个知识基础上工作，避免出现"各说各话"的情况。

除了这些，我还给自己写了一份"产品经理的skill"，里面规定了工作规则：写需求文档时，如果引用外部资料，必须给出出处；用Git做版本管理，每次迭代自动commit、push；我的常用规范放在哪个文件夹，AI需要先去学习；随手记的碎片需求，AI要自动整理到文档相应位置；维护一个TODO状态表，每完成一个模块就更新。有了这份skill，AI就像我的专属助理，知道我的习惯，能帮我处理琐事，我只需要专注思考和决策。

第三阶段：原型和文档的角色重塑

这是我最想强调的一点。在AI时代，原型和需求文档的关系需要重新定义。

过去，原型是"所有信息的总容器"。我们在原型上贴满批注，用颜色标记状态，用箭头表示流程，甚至把一些业务规则也写在原型的角落里。结果就是原型越来越复杂，越来越难维护。开发看着密密麻麻的批注头皮发麻，测试翻到手抽筋。

现在，我把职责分开了。原型只负责展示界面布局和关键交互，具体的规则、约束、异常处理，都写在需求文档里。这样做的好处是清晰、易维护、易复用。

当我们用AI生成多个不同风格的界面demo时，这个分工变得特别明显。我会基于之前整理的业务文档、行业知识库、前端规范skill，让AI生成多个不同风格的界面。比如同样是"用户登录页"，AI可以出三个版本：简洁风、卡片风、引导式。我们团队一起看看，哪个更符合产品气质，就选哪个。如果不满意，随时让AI重新生成——在AI时代，原型生成变得非常廉价，不满意就重新生成，甚至可以同时出好几个让团队选，再也不用担心画一版原型要花好几天了。

选好后，可以继续和AI沟通调整：“按钮再大一点”“颜色改成品牌蓝”“这里加一个提示文案”。直到界面基本满意。这个过程其实是在快速迭代，而且因为有AI，试错成本极低。

如果你用Figma，可以试试Claude Code to Figma——把AI写出来的代码界面，一键转成Figma里可编辑的设计稿。然后UI设计师可以在Figma里继续微调，调整完后，再通过Figma MCP把修改回传给ClaudeCode，AI会根据最新的设计稿同步调整代码。这样一来，产品、设计、开发之间的协作就顺畅多了，不用反复截图、标注。

虽然AI生成界面越来越强，但有些特别复杂的交互、或者需要严格对齐业务逻辑的地方，我还是会打开Axure或MasterGo，手动画一下。比如一个复杂的审批流程界面，涉及多个角色、多种状态、各种条件分支，用AI生成可能还需要反复调整，不如我手动画个草图，把关键逻辑标清楚。画完后加上必要的批注，说明特殊交互逻辑，然后让AI参考这些手动稿去完善其他页面。

但这时候我画的原型，已经不是过去那种"包罗万象"的原型了。它只负责表达界面布局和关键交互，而具体的规则、约束、异常处理，都会写在需求文档里。这个转变很重要，因为它让原型回归本质——快速展示想法，而不是承载所有信息。

第四阶段：需求文档的新生命

界面差不多定下来了，接下来要写详细的需求说明。这时候我们已经有了一份业务文档和一份demo，可以合并成正式的需求规格说明书。我会把Markdown格式的文档发给AI，让它基于demo补充每个页面的说明。

比如一个"提交"按钮，我会让AI详细描述：什么时候能点（比如所有字段填完且格式正确）、谁可以点（比如只有管理员）、点击后状态怎么变（按钮置灰、显示loading）、提交成功或失败怎么处理（失败后是保留数据还是关闭弹窗、跨系统同步失败后是回滚还是挂异常单）。这些细节如果不写清楚，开发容易猜错，测试也不好验证。

一份好的需求文档，最重要的不是文采，也不是篇幅，而是结构。它把一个需求最关键的信息收拢起来：为什么做、解决什么问题、涉及哪些角色、影响哪些系统、核心流程是什么、字段怎么定义、状态怎么流转、规则怎么约束、异常怎么处理、验收标准是什么。而且用Markdown写，AI能更好地理解和复用。如果类似业务做多了，这些结构可以沉淀成skill，下一个项目直接套用。

这就是AI时代文档重新变重要的原因：它不再是过去的流水账式PRD，而是一份结构化的需求规格说明，既能让人看懂，也能让AI读懂。开发把这份文档喂给AI辅助编码，AI就能基于清晰的规则生成更准确的代码，减少沟通成本和返工。当然，AI生成的说明不一定完全准确，需要人工仔细审定。但有了AI初稿，效率确实高很多。而且在这个过程中，我不断把"提交按钮的规则"这类细节补充进文档，其实也是在丰富这份需求规格说明，让它成为真正可执行的契约。

深层思考：为什么这样做有效

回顾整个流程，我发现有几个深层的原因让这套方法有效。

首先，我们改变了和AI的协作方式。过去我们习惯"一句话告诉AI要做什么，然后期待AI给出完美答案"。现在我们更多是"和AI一起思考，通过多轮对话逐步逼近最优方案"。这种转变很微妙，但效果很不一样。它让AI从一个"自动化工具"变成了一个"思维伙伴"。

其次，我们把隐性知识显性化了。规范、知识库、skill，这些东西本来就存在于我们的脑子里或者散落在各个文件里。现在我们把它们整理出来，让AI能理解和使用。这个过程本身就是一种知识管理的升级。而且一旦这些知识被显性化，新人上手会快很多，团队的知识积累也会更有价值。

再次，我们让每个产出物各司其职。业务文档负责说"是什么"，原型负责展示"长什么样"，需求文档负责说"怎么做"。这种清晰的分工让信息流动更顺畅，也让AI更容易理解和处理。

最后，我们降低了试错成本。因为原型生成变得廉价，我们可以大胆地尝试不同的方案，快速迭代。这让产品设计变得更灵活，也更容易发现更好的解决方案。

实践中的一些建议

如果你想尝试这套方法，我有几个建议。

第一，不要急着用AI生成最终产物。先用AI来加速你的思考过程，比如帮你整理资料、提出问题、补充细节。这样AI就成了你的思维工具，而不是替代品。

第二，投入时间沉淀规范和知识库。这看起来是额外的工作，但实际上是在为未来的项目做准备。一旦这些东西建立好了，后续项目会快很多。

第三，保持对AI输出的警惕。AI很容易生成看起来很合理但其实有问题的内容。所以一定要有人工审查环节，特别是对于关键的业务逻辑。

第四，不要过度依赖AI。有些工作，比如复杂交互的手动原型、关键业务逻辑的思考，还是需要人工来做。AI是工具，不是替代品。

第五，持续优化你的工作流程。这套方法不是一成不变的，要根据你的团队特点、项目特点不断调整。

展望与思考

AI时代变化很快，我们产品经理的工作方式也在一点点进化。上面这些方法不一定适合所有团队，但我相信方向是对的：用结构化思维组织信息，用AI提升效率，把我们从重复劳动中解放出来，去做更有创造性的工作。

未来，我觉得产品经理的核心竞争力会越来越集中在几个方面：深度理解业务和用户、发现真实的问题、设计创新的解决方案、有效地协调团队。这些都是AI暂时还做不好的事情。而那些重复性的工作——资料整理、文档生成、原型制作——会越来越被AI承担。

所以，与其焦虑AI会不会取代我们，不如主动拥抱AI，把它变成我们的工具。学会和AI协作，学会设计AI能理解的工作流程，这才是AI时代产品经理的生存之道。