AI产品经理的核心工作方法：负样例、竞品分析、产品架构，我整理了一套实战框架

做AI产品经理，技术要懂，但更关键的是方法论。这篇文章把我认为最重要的三个工作方法梳理出来——负样例设计（让Agent知道什么时候"不该动手"）、竞品分析（用结构化Prompt替代拍脑袋）、产品架构（中台思维+知识问答系统搭建）。都是实战中反复验证过的逻辑，不是纸上谈兵。

---

一、负样例：Agent的"刹车系统"，没有它就是"脱缰野马"

什么是负样例？

	正样例	负样例
教模型什么	怎么正确调用函数	什么时候不该调用函数
类比	教新手怎么开车	教新手什么时候该踩刹车

没有负样例的Agent会怎样？

• 遇事就调工具——用户随口说"今天天气不错"，Agent就把天气API调了一遍
• 参数格式错了也照调——日期传了"明天"，模型不知道拒绝
• 调错函数——用户想查天气，模型调了股票接口
• 提前调用——用户说"我在考虑要不要订酒店"，Agent直接下单了

在生产系统中，这些行为意味着：接口浪费、用户困惑、甚至造成实际损失。

负样例解决四类问题

问题类型	举例	负样例教什么
不该调用但乱调用	用户闲聊"今天好热"，Agent调了天气API	判断"是否满足调用条件"——槽位不全、只是闲聊就不调
参数格式不合规	日期传了"下周三"而非标准格式	强化格式敏感性，做位置/类型检查
调错函数	用户想查天气，调了get_stock_price	函数名和意图要对得上
调用时机不对	用户说"考虑一下"，Agent已经执行了	避免提前执行，等用户确认后再动手

但负样例构建很难——这是真实的业务痛点

难点	说明
构造困难	很少有真实场景中"系统性失败的调用日志"，需要手工设计或模拟
数据比例	负样本过多→模型过于保守不敢调用；负样本过少→模型"野路子泛滥"。建议初期负:正=8:2
分类细度	不同类型的"错"需要不同标签——调错函数 vs 格式错 vs 早调 vs 意图模糊，不能一锅炖

我的观点：负样例是Agent产品从"能用"到"靠谱"的分水岭。 很多团队只顾着教Agent"怎么做事"，忘了教它"什么时候不该做事"。一个不知道踩刹车的Agent，比没有Agent更危险。

---

二、竞品分析：用结构化Prompt替代"拍脑袋"

我总结的六维竞品分析框架

用一个结构化Prompt，让竞品分析从"拍脑袋"变成"有据可依"：

维度	分析什么	关键问题
功能设计	一级/二级/三级功能拆解	AI能力集成点在哪？RAG？插件？数据闭环？
用户体验	界面结构、操作流程、信息架构	响应速度、内容质量、辅助能力如何？
盈利模式	免费/付费/广告/ToB打包	用户留存与转化闭环怎么设计的？
市场推广	渠道、打法、品牌定位、冷启动策略	抖音/小红书/开发者大会/合作生态怎么组合？
团队背景	创始人/CTO背景、专利、技术壁垒	是AI技术驱动还是商业转化驱动？
企业战略	产品路径演进、重资产/轻资产、海外策略	长期方向是什么？

竞品选择的三层逻辑

不是所有"看起来差不多"的产品都是竞品：

层级	定义	举例（以百度灵医为例）
核心竞品	直接竞品，目标用户和功能高度重叠	阿里健康AI医疗助手、腾讯觅影、平安好医生
潜在竞品	功能接近，但目标用户不同	面向C端的健康问诊类产品
间接竞品	场景重合，解决方式不同	线下智能医疗设备厂商

分析工具组合

工具	用在什么时候
波特五力模型	分析行业竞争格局、替代威胁、上下游议价
SWOT分析	梳理优劣势、机会威胁
竞品画布	对比用户价值、成本结构、渠道策略

数据来源要标注

竞品分析最忌"来路不明"的数据。每项结论都要标注出处：

• 公司官网/发布会/招股书
• 行业研究报告（天眼查、IT桔子）
• 媒体资讯（知乎、极客时间、虎嗅）
• 数据平台（百度指数）
• 亲身使用体验
• 内部/外部访谈

推荐几个查行业报告的渠道：

平台	链接
艾媒网	艾媒网-全球领先的新经济行业数据分析报告发布平台
艾瑞咨询	艾瑞网_互联网数据资讯聚合平台
行行查	行行查 | 行业研究数据库
虎嗅网	https://www.huxiu.com
36Kr	https://36kr.com/

报告最终输出的三件事

1. 一句话总结：这个产品的优势和机会
2. 当前缺陷或战略风险
3. 对标行动指南：重点参考什么、规避什么、超越什么

我的经验：好的竞品分析不是"把竞品夸一遍"，而是明确告诉团队"我们该学什么、别学什么、要赢在哪里"。

---

三、需求分析：复杂业务必须出"调研报告"

简单的功能迭代，产品文档够用。但遇到特别复杂的业务流程和场景，产品经理必须产出"业务调研报告"。

这份报告有两个核心用途：

1. 对外：和甲方/业务部门做需求细节和范围的确认——别等开发做完了才发现理解偏差
2. 对内：和研发团队做需求评审和沟通对齐——复杂场景不能只靠口头沟通，必须落文档

我的理解：调研报告的本质是"降低理解偏差的成本"。 一个复杂的业务场景，如果PM理解错了、开发也理解错了、甲方验收时才发现——返工的成本是写调研报告的十倍。

---

四、产品架构：中台思维是AI产品经理的高阶能力

4.1 中台：SaaS产品的"能力底座"

中台是什么？一句话：把多个业务场景都要用的能力沉淀下来，避免重复开发。

不用中台	用中台
每个业务线各自开发用户管理、权限、计费	用户/权限/计费统一在中台，各业务线直接调用
改一个规则要改N个系统	改一次全业务线生效
新业务从零搭建	新业务在中台上快速组装

常见的中台能力模块：用户中心、权限中心、订单中心、计费中心、消息中心……

中台理念最早由阿里巴巴提出——本质上是应对快速变化商业环境的组织模式。 不是技术问题，是效率问题。

4.2 SaaS：理解你的产品交付模式

SaaS（软件即服务）的核心特征：

• 云交付：用户不需要安装，打开浏览器就用
• 自动更新：版本升级用户无感知
• 按需付费：订阅制，不是一次性买断
• 多租户：一套系统服务多个客户，数据隔离

做AI产品经理，你大概率是在做SaaS产品。 理解SaaS的交付模式，才能理解客户的付费逻辑——他们买的不是软件，是"持续的服务"。

4.3 知识问答系统的产品架构

这是AI产品最常见的产品形态之一，典型的分层架构：

层级	职责	核心组件
端层	用户交互	PC端、小程序、Word插件、企微/钉钉集成
产品层	业务功能	合同审查、法律问答、起诉状生成、文件起草……
能力层	AI引擎	法律大模型、专家知识图谱、意图识别、文档解析
支撑层	基础服务	权限管理、日志审计、模型评估、规则引擎、推荐引擎
数据层	数据存储	向量数据库、关系数据库、知识图谱、文件存储

我的理解：好的产品架构是"搭积木"——端层可以换（小程序换成APP），产品层可以扩展（加一个合同审查模块），能力层可以升级（换个更强的模型），但底层不动。 这就是中台思维在AI产品中的体现。

---

写在最后

产品经理的核心工作方法，说到底就是三件事：

1. 定义边界——负样例教Agent"什么时候不该做"，竞品分析教团队"该学什么不该学什么"，需求调研教甲方"这个做那个不做"
2. 结构化思考——竞品分析用六维框架而不是拍脑袋，产品架构用分层设计而不是堆功能
3. 沉淀复用——中台思维把重复能力变成底座，调研报告把业务理解变成文档

这三件事看起来都不"性感"，但它们决定了产品能不能从"一次做好"变成"持续做好"。

很多AI产品经理的焦虑在于：技术更新太快、模型迭代太猛、总觉得跟不上。但我的体会是——方法论比技术更持久。 模型会换、工具会变，但"教Agent踩刹车"、"用结构化框架做分析"、"用中台思维搭架构"这些方法，不管技术怎么演进都不会过时。