当AI产品经理遭遇'粉白色老头'的挑战，一场关于Prompt设计的深度实验就此展开。从最初的信心满满到发现模型'违约'的惊心动魄，再到设计出双通道数据分流机制，这篇文章揭示了AI产品落地的核心矛盾：如何在概率机器的'主见'与系统稳定性之间找到平衡点。跟随作者的实战历程，你将看到AI产品经理如何从失败中重构设计思维。

我问 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，给大模型定义了两个”垃圾桶”：

1. 数据正常，返回：

{ “status”： “success”， “product_name”： “…”， “xiaohongshu_copy”： “…” }

1. 遇到不合逻辑的脏数据(比如粉白色老头)，严禁中断，严禁说大白话，严禁脑补，必须返回：

{ “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 产品，我的建议是：别贪多，带着一个真实问题去和它打交道。被它坑过几次，你比读十本书学得快。

至少对我来说是这样。