核心观点
作者按产品经理真实工作流拆解 AI 实践，跑通了从需求定义到上线的完整闭环：项目初始化 → 市场分析 → 需求调研 → 需求分析 → 原型 → PRD → 需求评审 → 研发 → 测试上线 → 运营反馈。
开始之前：先给 Agent 一个产品项目
产品判断大多依赖历史，每次重新解释，AI 就只是临时工具。所以先建一个可长期工作的项目空间：把产品介绍、历史 PRD、系统截图、设计规范整理进去，让 AI 梳理「产品是什么、已知什么、未知什么」；再定一套协作规则——什么能当事实、文件放哪里、改需求后同步哪些内容。这套流程已沉淀成一份初始化 Prompt。
1. 市场分析：别信一个答案
AI 几分钟就能给出一套「很完整」的答案，但不能直接当事实——不同模型训练数据、搜索能力不同，同一问题换几个 AI 问，数字经常对不上。做法：多个 AI 扩大信息面，多来源交叉验证，回到财报、行业报告等原始出处，最后判断「这个数字能不能找到可信出处」。
2. 需求调研：AI 找不到公司里的真相
客户最关心什么、领导为什么做这个方向、研发觉得哪个方案成本最高——这些只存在于访谈、会议和工位聊天里。「你知道，不等于 AI 知道」，要把隐性认知持续整理进项目，变成 Agent 的上下文。
3. 需求分析：AI 做加法，产品经理做减法
AI 擅长把问题想全，问题也在这：改个端口号，它能补出校验、批量失败、异常状态，每一项都合理，合起来却把简单功能越做越复杂。产品经理要删：哪些是核心、哪些放后续版本、哪些复杂度不值；且每个留下的关键决策自己都要懂，否则研发一问「为什么这么设计」你还得回去问 AI，就成了传话筒。
4. 原型设计：先把设计约束交代清楚
AI 很快能生成 HTML 原型，效果好不好看设计约束有没有交代清楚：把已有页面、组件库、UI 规范放进项目，否则页面单看好看，放回产品却不像同一个系统。
5. PRD：下一位读者可能是 AI
一是符合公司规范：把 PRD 模板和好的历史 PRD 放进项目；二是 PRD 开始有两类读者——以前只给人看，现在研发测试也用 AI，下一棒会交给另一个 Agent，所以要保留一份信息完整的 Markdown 交接。
6-9. 评审、研发、测试、运营：让项目事实一直新鲜
评审后方案常变，每次重要决策都要把背景（时间、哪次会议、为何调整）写回项目，否则 AI 只能记住结果、找不到理由。研发阶段方案从 A 改到 B 也要同步——「项目现实过期了，能力再强也没用」。测试阶段 AI 可借 Computer Use 逐项验收，但最终判断仍归产品经理。上线后的反馈重新成为下轮输入，流程才闭环。
10. 三个心法
- 充分：给足上下文。结果不对先别怪模型，它可能缺你已经知道的背景；
- 约束：主动做减法。AI 容易把事情做得「完整」，取舍要人拍板；
- 慢下来：AI 越快，人越要先想清楚，别把思考成本也降到零。
写在最后
写 PRD、画原型、做竞品分析这些基本功正在变便宜，产品经理真正值钱的是「在真实世界里获取信息、理解约束、做判断」：能给 AI 足够真实的上下文，做出正确的取舍，并对结果负责。
个人点评
这篇文章最难得的是没有停在「用 AI 写文档」的工具层，而是把 AI 当作需要长期维护的协作者——项目空间、事实规则、决策日志，本质都是把「AI 不知道但你知道」的上下文持续补给它。这和我做内容运营时沉淀 SOP 的思路一致：隐性经验显性化，AI 才真正可复用。
三个心法里「慢下来」最扎心：生成成本趋近于零时，思考反而成了稀缺品。对内容创作者同样成立——AI 一天能出十篇稿，但「哪几篇值得发、为什么」还是得自己想清楚。
原文链接：深度长文｜2026产品经理AI实践手册（作者：奔跑的大毛腿 @run_maotui）
转载声明：本文转载自 奔跑的大毛腿的 X 帖子，内容有删改，版权归原作者所有。