最近重新拆了一个 AI 产品，过程里好几次让我自己脸有点发烫——发现以前我看一个产品，看的根本不是产品，是它的皮。今天想说说从这次重新拆解里掉出来的几件事。不是教程，也不是攻略，就是想找点同感。

我做赛事这个行业有点年头。比赛场馆里那些彩色围挡、指引牌、颁奖台背板、开闭幕式视觉物料，就是我们这行干的活儿。

最近在转型做 AI 产品经理。这件事还没干完，也还没干好。

最近忍着把一个 AI 产品从头到尾拆了一遍——一家做 AI 短剧的平台。拆得越深越觉得自己之前对”看产品”这件事的理解，浅得有点不像话。

下面想说几件这次拆完之后留下来的事。不是知识点，也不是清单。就是落在心里的一些回响。

一

我以前最怕被人问一句话——”你对这个产品怎么看？”

不是怕得说不出话，是怕自己只能说出”挺好的””我觉得不错””逻辑清晰”这种话。我心里隐约知道这种回答是在丢分，但又说不清楚到底应该怎么答。

后来我才明白，这种回答之所以丢分，是因为它没层次。一个产品其实是分层的——上面是市场和商业，中间是用户和功能，底下是技术、模型、数据。我以前看产品的时候，眼睛全部停在中间那一层——”这个交互我喜不喜欢””这个流程顺不顺”。底下三层我没看，上面两层我也没看。

而这上下两端，恰恰是真正决定一个产品能不能活的地方。

上面这两层——这个赛道值不值得做？怎么赚钱？谁是第一批用户？——我以前觉得”那是创始人考虑的事”。后来我意识到，真正能拿到好 offer 的产品经理，恰恰是能把这两层讲清楚的人。我之前几次面试卡在二面三面，回头想，就是这两层没说出来。

底下这三层——技术架构、模型选型、数据底座——我以前觉得”那是技术同事的事”。后来我意识到，AI 时代的产品经理如果不懂这三层，就只能做需求传话筒，做不了产品。

把这件事想明白后，我重新看了几个我以前”看过”的产品，发现自己其实一个都没真正看懂。

一个产品有六层

二

我以前研究一个竞品的方式是这样的——刷十个测评视频、读十篇分析文章、自己用一两次、写一份”我的看法”。我以为这就是研究。

这种方式我用了好几年。直到我真正坐下来逆向拆解一个 AI 产品，才意识到——这种“研究”获得的东西，其实是别人观点的二手堆叠，不是我自己的理解。

真的研究，是把这个产品一层一层倒推出来。每个交互背后是哪个 Agent？这些 Agent 之间怎么协作？这个 Agent 收到什么、又输出什么？为什么这一步用这个模型而不是那个？产品的护城河到底落在哪儿？

我用这种方式拆完一个产品后的体感是：之前那种“看十个测评”的研究方式，其实是在做无效输入。我以为我懂了，其实我只是知道了别人怎么看。

这件事让我有点不太舒服。因为我意识到自己过去几年研究过那么多产品，每一个其实都没有真正“研究”过。

三

我以前对”多 Agent”这件事有种隐约的崇拜。

每次看到一个产品宣传”我们有 7 个 Agent 协作”，下意识就觉得这个产品比”只有一个 Agent”的牛。

后来我把这件事想清楚了——多 Agent 升级，唯一的原因是单个 Agent 已经搞不动了。不是因为多 Agent 更高级，是因为任务复杂到必须拆。

这其实就跟做赛事项目一个道理——一个项目经理能扛下来的活儿，没必要再招一个。两个人到位之后职责必须切清楚，否则就是互相内耗。AI 里的多 Agent 也一样——不是越多越好，是越精准越好。

把这件事想清楚后，我把脑子里之前研究过的几个”花哨多 Agent 应用”重新评了一遍——发现大部分其实根本不需要多 Agent。一个写得扎实的单 Agent 配上一些工具调用，能干掉它们里 80% 的功能。那些拆出来的多 Agent 看起来酷，但本质上是过度设计。

我以前没看出来，是因为我把”多 Agent”当成了一种”先进性”标签，没去想它解决了什么。

四

我以前对”产品经理写提示词”这件事的理解非常轻——不就是几句指令嘛。

直到我看到一个真实在跑的产品的主 Agent 提示词。那东西是几百行的 SOP + 工具调用规范 + 防御规则 + Few-shot 示例。每一条”必须注意的事项”背后都是一次踩坑、一次评测、一次迭代。

我看完之后楞了一会儿。

楞是因为我突然反应过来——传统产品经理写的 PRD 内容，现在全部浓缩到了 Agent 的系统提示词里。需求描述、流程逻辑、异常处理、交互规范、边界条件——以前是 PRD 的章节，现在是提示词的段落。

这件事的分量是——提示词不是产品经理的“附加技能”，是产品经理的核心工作产出。这跟我之前想的完全是两回事。

我现在重新看 AI 产品经理这个岗位，跟我刚转型那会儿看的，已经不是一个东西了。这一行真正的高手，是能把一个 Agent 的提示词写得像一份完整 PRD 那么扎实的人。我以前甚至没意识到这是一种能力。

配图（二）：提示词就是新形态的 PRD

五

如果让我说这次拆解里最颠覆我认知的一件事，我会选这个——

AI 产品的真护城河，不在模型，不在提示词，在“上下文工程”里。

这话第一次听到我没反应过来。后来才理解——上下文工程是一整套设计：什么时候用什么信息、什么时候不用、怎么存、怎么查、怎么传递。它比提示词大一个量级。提示词只是”喂给模型的话”，上下文工程是”决定喂什么、什么时候喂”的整套规则。

我以前研究 AI 产品的时候，眼睛全部盯在提示词上——觉得只要把提示词调得够好，产品就稳了。但其实即使两个产品的提示词差不多，背后上下文工程的差别能让最终效果天差地别。

举个我自己的体感——同样是”AI 写作助手”这种东西，看起来调用的都是 GPT，但有些用起来像有灵魂、有些用起来像复读机。差别根本不在模型，在它给模型喂了什么、什么时候喂、什么时候不喂。

这一层我以前完全没看见。看见之后我对”AI 产品的差异化在哪”这件事的判断翻了一遍。

六

这次拆解里有一个让我反复想了好几天的细节——

那家短剧 AI 平台的所有 Agent 共享一份全局上下文数据表。里面记录着项目元数据（项目 ID、版本号、影片比例、时长……）、角色字典、分镜资产等等。每个 Agent 完成一步任务后，都会更新这份数据表的某些字段。

这个东西看起来一点都不性感——就像传统软件里的一张数据库表。但它才是整个 AI 产品能跑得稳的根基。

为什么？因为没有这份共享的数据底座，Agent 之间就没办法传递信息。每个 Agent 都是孤岛，每次都从头开始。

我突然想到——这跟我做赛事项目时，团队里那个核心的”项目状态共享 Excel”，本质上是同一个东西。所有人都在改同一份表，每个人改完都告诉别人”我做到哪一步了”。没有这份表，整个项目协同就崩了。

所以”AI 产品的工程能力”和”传统软件的工程能力”，在底层其实是连着的。多 Agent 协作不是黑科技，是一种古老的协同模式套上了新名字。

意识到这一点的时候我心里挺安定的。因为我做赛事项目这几年攒下来的”项目协同感”，在 AI 产品里依然有用——只是要重新换个语言讲出来。

全局共享数据表

七

最后想说的是——逆向推导一个产品的能力，可能是 AI 时代最值钱的能力之一。

我以前以为产品经理的价值是”做新东西”。后来才意识到，AI 时代的产品经理，更值钱的能力是”拆开别人的东西“——不需要拿到源码，不需要内部信息，光靠”用一遍 + 观察 + 推导”，就能把一个产品 80% 的架构推出来。

为什么这能力值钱？因为这一行变化太快——你今天看到的”创新”，三个月后就遍地都是。真正能让你站住脚的不是”我做了一个新东西”，是“我能在两周内把任何一个新出来的爆款拆透”。

这是一种思维体力，跟做赛事时的”现场判断力”有点像——不是预先知道答案，是真碰到问题时能立刻看透到底下三层。

我现在每周强制拆一个 AI 产品，不为了写文章，就为了维持这个能力。一开始拆不动，慢慢能拆出 30%、50%、最后 80%。这个练习像健身，没有捷径，只能日常做。

如果你也在转 AI 产品方向，建议这件事做起来。不会有立竿见影的回报，但半年后会变成你跟同行之间最大的差距。

拆解像健身，是日常的事

不算结尾的尾巴

写到这儿想说的差不多说完了。

我自己重新画了一遍这次的清单——

我以前看产品只看中间一层，以为这就是产品；我以前研究产品靠堆别人的观点，以为这就是研究；我以前把”多 Agent”当成先进性标签，没去问它解决了什么；我以前以为提示词是几句话，其实是产品经理的核心工作产出；我以前以为护城河在模型和提示词，其实在上下文工程；我以前没看见全局共享数据表的分量，其实它是 AI 产品能跑稳的根基；我以前以为产品经理是”做新东西的人”，其实更值钱的是”能拆开别人东西的人”。

这堆东西换个角度说就一句话——我以前以为我“看懂”了的那些产品，其实一个都没看懂。

转型这件事最让人栽跟头的，永远不是”不会”，是”觉得自己已经会了”。

写完这篇我没有什么”接下来要做的清单”。就是把这几件事掏出来，放在桌面上，每天看着它们提醒自己——下次再被问”你对这个产品怎么看”，至少别开口就说”挺好的”。