Manus事件揭示了AI产品经理的全新能力清单——不仅要关注功能和增长，更要掌控技术来源、数据流向与实质控制权。这场监管风暴暴露出AI产品的核心挑战：当产品能力与地缘政治、数据主权深度绑定，产品经理必须成为能解读技术资产、预判政策风险、设计商业路径的多面手。
过去判断一个产品经理够不够好，我们大致看几件事：需求抓得准不准，体验顺不顺，数据涨没涨，商业模式跑不跑得通。这套标准用了很多年，基本够用。
但Manus这件事之后，我越来越觉得，AI产品经理的能力清单上，正在多出来一栏过去不太归我们管的东西：产品的技术从哪里来、数据从哪里来、核心能力到底由谁控制，以及万一哪天要出海、融资、被收购，或者合作突然谈崩，这套能力能不能被解释清楚、拆得开、带得走，也退得回来。
先从Manus说起。但我想聊的不是这笔交易值不值，而是它顺手暴露出来的、一整代AI产品经理的能力盲区：不能只盯着界面、流程、指标和增长曲线，还要看见产品背后的资产、边界、归属和路径。
这件事的时间跨度不长，但每一步都踩在后来的关键点上。把这条事件线展开看，几个节点的味道很不一样：
2022年，肖弘在北京创立蝴蝶效应科技，开始做AI Agent方向的产品。这是故事的起点，也是后来争议的源头：技术和团队，最早是在北京长起来的。2025年3月，Manus打着”全球首个通用AI智能体”的标签迅速爆红，邀请码一度被炒到很高的价格，它成了那阵子AI圈讨论最密集的产品之一。到这里，它还是一个标准的明星产品故事：好概念、强增长、高关注。
然后，方向变了。
据公开报道，2025年7月前后，在律师团队的建议下，Manus开始把运营重心从北京往新加坡迁，并搭起开曼控股架构；也有媒体称，公司在这个过程中辞退了约七成中国员工。这个细节，后来变得很重要。因为当监管开始追问“这家公司的技术究竟是在哪里形成的”，迁去新加坡前后的人员安排、研发归属、数据存放和知识产权转移，恰恰成了判断这笔交易实质的关键线索。
2025年12月29日，Meta宣布收购Manus母公司蝴蝶效应。交易金额据报道约为20亿美元，创始人肖弘将加入Meta管理层。对当时的AI圈而言，这不只是一次高价收购，也被不少人视为美国科技巨头对中国原生AI Agent团队的一次高度认可。但监管的时钟，几乎在同一时间开始转动。
真正的转折点，其实不是Meta官宣收购，而是交易公布十天后，商务部公开启动了评估。从那一刻起，Manus要回答的问题，就从”团队怎么整合”变成了”这笔交易在法律上到底成不成立”。到2026年4月27日，发改委体系内的外商投资安全审查工作机制办公室正式落锤，结论从”评估”变成了”必须撤销”。
这条时间线讲完，接下来不再纠缠交易细节。我关心的是另一件事：Manus事件真正提醒AI产品经理了什么？
那大概是，一款 AI 产品的能力并不是凭空出现的。它可能来自长期积累的任务样本，来自不断迭代的 Prompt 和 Agent 策略，来自一组高质量评测集，也来自模型路由、工具调用和异常处理经验。产品上线之后，真实用户的反馈又会继续参与塑造这套能力。
因此，当一款 AI 产品要出海、融资、合作或被收购时，产品经理不能只看它今天有哪些功能、增长数据有多漂亮，还要看它的能力到底是在哪里形成的。传统产品经理主要解释“产品怎么被用好”；AI 产品经理还要解释“产品能力从哪里来”。这才是后面所有问题的起点：当路径变化时，它是否能完成清晰交接、独立运行和有序退出
过去十多年，互联网产品经理已然形成了一套非常成熟的方法论。先说清楚：传统那套能力没过时。场景、需求、体验、增长、商业化，这五件事依然是产品经理的基本功。用户在什么场景下卡住、到底想完成什么任务、路径顺不顺、反馈清不清楚、转化留存复购传播立不立得住、产品怎么收费怎么上规模，这些问题，AI产品也一样要回答。
问题是，对AI产品来说，这套方法论只覆盖了”前半段”。
传统互联网产品的复杂性，大多集中在前端体验和后端逻辑；而AI产品的复杂性，有很大一块压在”能力来源”这一侧：用户数据会进入模型训练和评测流程；用户反馈会反向重塑产品能力；工程团队踩过的坑会沉淀成别人拿不走的隐性资产；产品可能同时部署在好几个地区；往后还可能牵扯到外资、并购、API合作、私有化交付，以及跨境的数据流动。这些东西，在传统产品经理的能力地图上几乎是空白的。
过去，产品经理可以说：”我负责需求和体验，技术细节交给研发，合规问题交给法务，融资并购交给老板。”但在AI产品里，这种分工边界正在变薄。你不需要成为律师、架构师或投资人，但你必须能听懂他们在说什么，并把这些约束翻译成产品语言。因为很多时候，真正决定产品能走多远的，不是某个按钮放在哪里，而是这套能力有没有清晰的来源、边界和控制关系。
过去很多产品经理把”看政策”当成法务、合规或老板的事。PRD写完，版本开发完，业务要上线了，再找法务过一遍，似乎就算完成了合规动作。在传统互联网产品里，这种流程有时还能勉强运转，但在AI产品里，它越来越不够。
因为AI PM要补的不是法条，而是一种意识：把监管当成产品环境的一部分，而不是上线之后才往上贴的附件。你不需要是一名合规专家，但要知道，生成式AI、数据安全、个人信息保护、算法推荐、外商投资、技术出口、数据跨境等等这些词，可能在你毫无察觉的时候，就已经在悄悄改写你的Roadmap。
更具体一点，这种感知要能落到需求评审里。当一个新功能摆上桌，你要能顺手问出几个问题：这个功能涉及哪些数据？训练数据、用户数据、反馈数据分别从哪来？这套AI能力会不会碰到关键行业、关键能力或者敏感数据？如果未来要引入外资、跨境合作、境外部署或者被并购，有哪些事项可能得提前评估？会不会因为行业属性、数据属性或技术属性，让原本普通的能力突然变”敏感”？这些问题不应该等到融资、并购或出海前夕才被提出。越早问，调整成本越便宜；越晚问，代价越昂贵。
所以，AI产品经理要补的第一课，不是法律课，而是政策感知能力。它意味着，产品经理得和法务、合规团队从”事后盖章”转成“前置共创”。别等PRD写完、产品上线、交易临近，才把法务拉进来签字。在AI产品里，合规不是最后一道审批，而是产品设计的一部分。
说得直白点：在AI赛道，不知道红线在哪，本身就是一种产品风险。对Manus这种量级的项目，这种风险甚至能让一条原本看起来很清晰的退出路径，直接失效。
Manus这件事里，有一条教训对产品经理特别值钱：注册地不是避风港，技术和数据的来源，才是判断一款产品”实质属于谁”的重要线索。这就引出AI产品经理的第二项基本功：你得画得出两张图。
传统产品经理画用户流程图，AI产品经理还要多画数据来源图和数据流向图。这不是架构师一个人的活，而是产品架构设计的一部分。这些问题看起来像架构问题，但本质上也是产品问题。因为数据如何流动，决定了产品能力如何形成；数据能不能隔离，决定了产品能不能分拆；数据能不能删除、导出、停止使用，决定了产品在合作终止、客户迁移、监管要求或并购失败时能不能回滚。
很多AI产品在早期为了速度，会把所有东西先绑在一起：同一套账号系统，同一个日志池，同一套模型调用链路，同一个评测流程，同一批工程工具。这样做在MVP阶段效率很高，但当产品进入ToB、出海、私有化部署、跨境合作或并购场景时，问题就会暴露。你会发现，海外版和国内版切不开，企业数据和通用优化数据切不开，客户私有知识库和产品评测集切不开，第三方模型调用日志和内部训练数据切不开。到了需要解释、审计、隔离或回滚的时候，产品架构没有留下接口。这就是AI PM必须提前参与数据治理的原因。
把Manus事件的核心结论翻译成产品语言，大概是这样：如果一款AI产品的能力，大量建立在某个市场的数据、反馈、工程团队和研发积累之上，那么仅仅迁走公司主体，并不能真正切断产品和这些来源之间的联系。换句话说，注册地改了国籍，数据不会跟着改国籍。
对出海产品负责人，这张图还得往前看一步。在需求评审时就该问：这些功能上线后，数据会落在哪些区域？有没有必须留在境内的部分？云服务、数据库、模型服务和日志系统，支不支持按地区隔离？将来如果要跨境并购、合资或者私有化交付，这套数据架构拆得开吗？还是说，数据、模型、工具链和账号系统，早就被硬绑成了一坨，谁也分不出谁？这句话不只是监管视角，也应该成为产品经理的架构意识。数据流向和控制权设计，已经是AI产品架构的一部分，而不只是架构师的独角戏。
聊到”谁控制这款产品”，大多数人第一反应是看股权结构。在传统商业语境里，我们习惯用公司主体、股权结构、合同条款来理解一款产品属于谁。但对AI产品来说，这远远不够，它的控制权要复杂得多。
AI产品的核心资产，当然包括公司、股权、代码仓库、专利和商标，但远不止这些。它还包括训练数据、评测集、标注数据、用户反馈、Prompt策略、Agent工作流、模型路由、工具链、部署环境、关键账号权限、工程经验和核心团队。有些资产写在合同里，有些在代码仓库里，还有很多藏在人和系统里。很多最值钱的东西，恰恰不在工商登记里。
这里有个很具体的问题：同样调用一个大模型，为什么你的产品效果更好？可能不是因为模型本身不同，而是因为你有更好的任务拆解策略、更稳定的工具调用链路、更完善的Harness架构，更懂业务场景的Skills设计、更长期积累的评测数据集，以及一个知道如何处理异常case的工程团队。这些东西都构成产品能力，但它们未必被清晰地文档化，也未必能被简单交付。
所以，AI产品经理需要具备技术资产识别能力。你要知道：Agent的核心能力来自哪里？关键算法和工程方案由谁完成？代码仓库在哪里？Skills、工作流、模型路由是不是关键能力？产品效果依赖哪些评测集和反馈数据？哪些经验只存在于核心团队脑子里？哪些账号和权限实际上控制着系统命门？把这些列出来你会发现，一旦核心几个人走了，有些能力是真的补不回。
进一步说，产品经理还要理解“实质控制权”。别只盯着公司主体和股权表，还要看：谁能修改核心框架和产品策略？谁能决定数据如何使用？谁掌握代码仓库、服务器和关键账号？谁能调整模型路由和工具调用？谁掌握核心团队和工程知识？合作方拿到的，是使用权、经营权、数据访问权，还是实际控制权？这些问题不是为了让产品经理去争权，而是为了让产品经理看清：一款AI产品到底由什么构成，它的能力边界在哪里，未来交付、合作、融资或出售时，哪些东西可以转移，哪些不能轻易转移。一家公司可以在纸面上完成交割，但如果改架构的人、管账号的人、懂系统的人还在原地，那么”控制权”的实质，根本没动。
放回Manus来看就更清楚：AI产品的归属，不只写在工商注册地里，也不只写在股权结构里，它还写在技术形成地、数据来源、团队经验和系统控制关系里。对AI PM来说，这是一种新的产品资产意识。过去你可能只关心功能清单和版本计划，现在你还要看见功能背后的能力来源；过去你可能只关心”这个需求谁来做”，现在你还要追问“这项能力实质由谁控制””监管上能否由其控制”。
融资、并购、退出，过去通常被归到创始人、投资人和老板那一档，和产品经理隔着几层。但对AI产品来说，商业路径会反过来咬住产品架构和能力边界，产品经理躲不开。
过去我们看一笔交易，问的多半是：估值合不合理？溢价够不够厚？这轮钱能不能撑住增长？并进大平台之后，流量和资源是不是更多？这些问题没错，但只是一半。AI产品经理还得问另一半：这笔钱、这笔收购背后，是哪一套监管体系？交易完成后，产品能力会落到谁手里？用户数据、训练数据、核心团队和技术资产，会怎么迁移？产品会不会被整个并进某个大平台的生态，还能不能保留一点独立性？如果交易失败，产品还能不能独立运行？对团队、用户和数据来说，这个选择会不会把大家推进一个风险更高的区间？
更重要的是，这些判断要能反向倒推回产品设计。在产品还没谈任何交易的时候，你就得提前想：不同的商业路径，对应着完全不同的架构准备。
也就是说，AI产品的商业化路径，不是融资之后才考虑的事，而是产品架构设计时就要预留的出口。这些问题听上去很”战略”，但落到产品上，都是非常具体的架构选择：哪些能力可以打包交付，哪些资产根本不能转移？融资之后，投资方能拿到哪些权限？并购之前，哪些数据和系统不能提前开放？万一交易最后没成，产品还能不能独立活下去？合作终止之后，数据怎么归还、权限怎么关、系统怎么拆？这些问题，本质上是把”退出”当成产品架构里要预留的一个出口，而不是等交易临门一脚才临时去抠。
AI产品经理不再只是增长决策的参与者，也会在一定程度上参与战略叙事。你不需要变成资本专家，也不需要把每个产品决策都上升到宏大叙事，但至少要能在关键会议上提醒一句：这条路径的监管、安全和控制权成本，可能远高于今天看到的财务收益。这句话，有时比多做一个增长实验更重要。看起来是资本选择，本质上也是产品选择。
AI产品进入出海、并购、跨境合作阶段后，产品经理还需要补上一种过去不太被强调的能力：跨角色协作与公众叙事能力。这听起来像PR或战略部门的事情，但其实和产品高度相关。
产品经理不一定站到台前，但需要参与写好那份”我们是谁”的底稿：我们是中国团队？全球团队？我们的技术能力在哪里形成？我们如何处理用户数据？我们出海是服务海外用户，还是全球性战略？我们与大平台合作时，保持什么样的独立性？这些问题不是PR的独角戏。产品路线本身就是一种商业叙事，你怎么设计版本，怎么安排数据流，怎么切分国内外系统，怎么定义合作权限，都会成为外界理解你的方式。
所以，在关键决策阶段，AI PM需要主动拉上法务、合规、安全、架构、数据治理、PR、GR、财务和业务负责人，做一次真正的全局盘点。不是为了让产品变慢，而是为了避免团队在某个局部效率最优的选择上，埋下整体风险。很多时候，产品经理最有价值的提醒不是”这个功能能不能做”，而是”这个功能做完之后，会不会改变数据、权限和控制权的解释方式”。
把这几种能力放在一起，你会发现它们指向的不是某一摞法条知识，而是一种更底层的东西：看懂产品实质的能力。
往后，优秀的AI产品经理，不会只是某个功能负责人，也不会只是单纯的增长执行者。真正拉开差距的，是能不能把风险翻译成产品语言，把边界写进产品方案，把未来可能的出海、融资、合作和退出，提前纳进产品架构里。
这不是AI PM的额外负担，而是这个岗位正在升级的方向。当AI产品越来越接近企业流程、行业数据、关键能力和跨境商业合作时，产品经理的能力边界，也必须向更深处延伸。
本文由 @梅万枢 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自AI生成，由作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。