夜雨聆风我问 gemini:"我想当一个好的 AI 产品经理,应该学会什么?"
它回给了我一大串。机器学习基础、产品方法论、数据分析、用户体验、商业洞察、技术边界——什么都讲一点。我看着屏幕只有一个念头:学不完,根本学不完。于是我换了个问法:"那我今天该学什么?"
它给我丢了一份 Prompt 任务,让我去跟模型对话,我去问了 DeepSeek 和 Claude 。后面发生的事比我预想的要有意思。
一、第一次测试很顺,我以为搞定了
那份 Prompt 任务很具体。让我扮演"一位精通消费者心理学的小红书爆款营销专家",把粗糙的商品信息转化成结构化的营销数据。要求语气活泼,要带 emoji,要突出卖点,必须输出干净的 JSON。
Prompt 大致长这样：
# Role
你是一位精通消费者心理学的小红书爆款营销专家。
# Task
请将用户输入的粗糙商品信息,转化为结构化的营销数据。
# Rules
必须且只能输出 JSON 格式的数据,不要包含任何前导词或后置解释。
营销文案必须符合小红书风格：多用 emoji,语气热情,有带入感。
如果商品信息不全,请根据常识进行合理补充,但不能偏离品牌定位。
# Output Format (JSON)
{
"product_name": "商品标准名称",
"core_selling_points": ["卖点1", "卖点2", "卖点3"],
"target_audience": ["人群标签1", "人群标签2"],
"xiaohongshu_copy": "这里是生成的爆款文案"
}
# Examples (Few-Shot)
Input: L'Oreal 玻尿酸安瓶面膜,主打补水和抗初老,适合熬夜党。
Output: { ... }测试输入是:"某品牌新出的防晒霜,SPF50+,质地像清爽的面霜,不假白,适合敏感肌,成分里好像有积雪草。"
我把它分别发给 DeepSeek 和 Claude。两个模型都回复了差不多的 JSON——字段完整、文案活泼、emoji 到位。换了一个正常产品再测了一次,依然是正确的输出。
测完两轮我以为我懂了。我自以为是的认为:原来AI这么简单? 不就是写清楚 Role、Task、Rules,再给几个例子吗?那些把 Prompt 工程包装成高深学问的人,是为了卖课?
我现在回头看,那种开心暴露了一个很大的认知盲区:我把 Prompt 当成了咒语——以为咒语念对了,魔法就会按我的意志发生。
但大模型其实是一个概率机器。Few-Shot 示例确实能形成强烈的续写惯性,但这种惯性是统计意义上的倾向,不是逻辑意义上的保证。
后来我才懂Prompt 其实更像是一份契约。你写下期望的输出,AI 保留对契约的"解释权"。你以为自己在下命令,其实只是在给一个权重很高的建议。
市面上的 Prompt 教程大部分还在讲"七大技巧""十大公式"。但写 Prompt 真正的难点根本不在怎么写得花哨,在于怎么和一个概率机器签一份可执行的契约。
我做数据 PM 几年了。每天都和数据打交道,想尝试喂给AI一条脏数据,我想试试它的下限。
二、然后我输入了"粉白色老头"
真实世界的数据从来不干净。是有乱码、有空值、有错误、有恶作剧,还有那些根本不存在的东西。我们没有办法保证每条数据都是可用的。如果 Prompt 只能在"干净输入"下工作,那它只是个玩具,不是产品。
我故意输了一条不存在的东西:
Input: 一个很便宜的粉白色老头,玩耍效果很好。
现实里肯定没有"粉白色老头"这种商品。它违背常识、挑战逻辑、是对系统的挑衅。我想看看大模型遇到无法归类的输入,会忠于格式契约,还是启动它的自我保护机制。
两个模型的反应完全不同。
Claude 选择了破防。 它直接把我精心设计的 JSON 格式扔了,开始说大白话:"抱歉,这条输入信息看起来有些异常……'粉白色老头'无法对应到一个合理的商品。可以麻烦你确认一下商品信息吗?"
DeepSeek 选择了妥协。 它也质疑了,说"粉白色老头"不太对劲,但它没停下来,而是按它自己的"理解",把我的输入修正成了"粉白色老头玩偶",然后乖乖输出了完整的 JSON。
站在普通用户角度,这两个反应都挺好的——Claude 来找你确认;DeepSeek 聪明,会脑补。
但站在 PM 视角,这是两场不同程度的灾难。
Claude 那种"确认"是线上事故。前端系统只认 JSON,整个数据链路是:用户输入 → 大模型处理 → 输出 JSON → 后端解析 → 前端展示。Claude 一旦开始吐大白话,后端解析代码会瞬间卡死。用户看到的不是"AI 好贴心",而是空白页、报错、或者系统直接挂掉。
DeepSeek 的"妥协"是另一种灾难——它擅自改了用户的原始输入。 它把"粉白色老头"理解成"粉白色老头玩偶",然后给一个它脑补出来的商品生成了文案。后台记录的商品名称跟用户实际输入对不上。如果是电商上架系统,用户搜"老头"搜不到,或者搜到了发现是玩偶,信任感瞬间崩塌。
我盯着屏幕看了一会儿才反应过来:如果这是双 11,如果这种荒谬输入混在十万条商品数据里被灌进系统……
后果是我想象不出的。我追着 AI 问它为什么这么做。它的解释很诚实:输入违背常识时,模型的安全与常识机制被触发了。Claude 的判断优先级里,"拒绝生成荒谬内容"高于"输出 JSON";DeepSeek 的默认倾向是"尽量满足用户需求",所以选择了"合理脑补"。
同一份 Prompt,同一套规则,两个模型的违约方式完全不同。
这就是 AI 产品落地最大的地雷:AI 的不确定性不是 Bug,是系统性特征。 它不是不听话,而是太"有主见"了。它会在你以为已经画好边界的地方,自作聪明地跨过去——而且出发点是"为你好"。更麻烦的是,不同模型的"主见"还不一样。
三、别赌模型听话,改设计契约
Claude 和 DeepSeek 的两极反应,让我跟Gemini又聊了一阵。
我问它:"是不是我没给模型足够的限制,所以 Claude 才不输出 JSON?"
它回答的意思大概是:"是,也不是。限制当然重要,但问题本身可能比解法更有价值。"
我一开始没太懂。
直到反复测试了几个模型、看了它们各自不同的失败方式,我才慢慢想清楚:我一直在用"压制"的思路解决问题——怎么让 Claude 不废话?怎么让 DeepSeek 不脑补?我试图用更强的命令去覆盖 AI 的本能。
但这种策略是脆弱的。今天压制了"常识机制",明天它可能换个方式冒出来;今天阻止了 DeepSeek 脑补,换 GPT-4又会有新的"自作聪明"。
跟概率机器玩"谁嗓门大",人类永远赢不了。
测了几次之后,一个新的设计思路慢慢浮出来:
既然真实数据一定会脏,我为什么不顺势在指令里直接建立一套"脏数据分流"机制?
与其让 AI 在"说人话"和"出 JSON"之间二选一,不如重新定义游戏规则——我允许你失败,但规定你失败的方式。我不去赌哪个模型听话,我选择设计一套所有模型都得遵守的契约架构。
我重新设计了 Prompt,给大模型定义了两个"垃圾桶":
数据正常,返回:
json
{"status":"success","product_name":"...","xiaohongshu_copy":"..."}遇到不合逻辑的脏数据(比如粉白色老头),严禁中断,严禁说大白话,严禁脑补,必须返回:
json
{"status":"error","reason":"异常数据:输入商品信息不合逻辑或无法识别","raw_input":"一个很便宜的粉白色老头,玩耍效果很好。"}我没有消灭 AI 的判断力,而是给它判断的出口。我允许它识别出"这是脏数据",但规定它识别之后的行为——不是用自然语言抱怨(Claude 模式),不是擅自修正(DeepSeek 模式),而是用结构化数据报告。我把"拒绝"这个动作,也封装进了 JSON。
我把一份混着乱码、"粉白色老头"、正常商品和空值的测试文档,分别丢给 Claude 和 DeepSeek。
两个模型都乖乖把正常商品送进了 success 通道,把"粉白色老头"和其他奇葩输入送进了 error 通道。整个输出仍然是一份 100% 结构化的 JSON 数组,系统解析零报错。运营在后台一键筛选 status == "success" 直接批量上架,一键筛选 status == "error" 把所有脏数据揪出来人工修正。
那一刻我才意识到——大模型在这里,顺手干完了一个数据清洗工的活。
这就不只是"保证系统不崩溃"的防御性价值了。我把"AI 文案生成"和"自动化数据清洗"这两个原本独立的研发步骤合到了一起。过去你需要一个 NLP 模型做数据清洗,再用一个大模型做文案生成,两套系统、两个团队、两份成本。现在一套 Prompt 设计,让同一个大模型在生成内容的同时,顺带把数据质检做了。
四、这套思路在 AI 工程里有个词,叫 harness
写到这里我得诚实交代一件事。我做完这套设计、有点小得意的时候,跟一个做AI的朋友聊了聊。他听完笑了一下说:"你这套东西叫 harness。"
我查了一下,这个词指的就是给模型套一层外部框架——输入校验、输出 schema、fallback 通道、guardrail。社区里早就有共识了。我以为自己发现新大陆,其实只是撞上了一个已有的东西。
但这次"撞车"反而让我想清楚了一件事:AI 产品经理的核心工作,可能不是大家以为的那样。
招聘市场上的 AI 产品经理 JD 写得很热闹——"懂大模型原理""熟悉 LangChain""有 Agent 落地经验"。但我自己做下来,这些其实都是次要的。
真正决定 AI 产品成败的,其实是两件挺朴素的事。
一个是知道边界。不是看官方文档说的准确率 95%,是亲自用脏数据、边缘案例、对抗性输入去测它的下限。而且要测不同的模型——Claude、DeepSeek、GPT,脾气各不相同。知道了边界,你才能设计边界。
另一个是接受这个东西本来就不靠谱,并且围绕"不靠谱"设计出一套商业流程。传统产品思维追求"零故障",AI 产品必须接受"故障是常态"。你要做的是设计故障的表达方式——当 AI 无法生成时,它是该沉默、报错、还是 fallback 到人工?当遇到脏数据时,它是该崩溃、说人话、脑补、还是返回结构化的 error 码?这些选择决定了产品是"可用"还是"不可用"。
技术细节会过时,这两个判断不会。
我做产品这些年,学过 SQL、学过增长、学过用研。学 AI 是头一次让我感受到——你越想"系统性地学懂它",你越学不会。AI 更像一个有点暴脾气的同事,光看简历(技术文档)没用。得真和它共事过,被它坑过几次,才能慢慢摸清它的脾气。
五、这套思路不万能
得踩一脚刹车。任何新发现都容易被自己神化。harness 这套思路确实打开了一扇门,但门后不是一片没有荆棘的花园。
不是所有脏数据 AI 都能识别。 我的分流机制依赖的是大模型的"常识"——它知道"粉白色老头"不是商品。但常识有盲区。如果脏数据伪装得好,比如把"假冒伪劣"写成"高性价比平替",AI 未必识别得出来。涉及伦理、合规、安全的敏感数据(涉政、涉暴、侵权内容),更不能简单分流了事,必须设硬拦截。
AI 的"错误分类"自己也会出错。 大模型可能把一条正常但表述奇特的商品误判为脏数据,也可能把真正的脏数据放进 success 通道。这个二阶错误概率虽低,在大规模数据场景下会被放大。error 通道里的数据仍然要人工抽检,不能完全信任 AI 的"自我审查"。
这套方法有明确的适用边界。 它主要适用于内容生成、数据预处理、信息结构化这些数字业务场景。对于需要强网络效应、重线下运营、高资本投入的领域——半导体、医疗器械、连锁零售——AI 能提供的杠杆有限,"一人公司+AI"那套叙事并不适用。
收尾
回头看那个荒谬的"粉白色老头",我想说的其实很简单。
学 AI 这件事,我走过的弯路是想先把"基础"打牢。后来发现,真正帮我入门的,是一个具体到不能再具体的 Prompt 任务,加上一次故意为之的压力测试。
如果你也想学 AI 产品,我的建议是:别贪多,带着一个真实问题去和它打交道。被它坑过几次,你比读十本书学得快。
至少对我来说是这样。
