当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，给大模型定义了两个”垃圾桶”：
{ “status”： “success”， “product_name”： “…”， “xiaohongshu_copy”： “…” }
{ “status”： “error”， “reason”： “异常数据：输入商品信息不合逻辑或无法识别”， “raw_input”： “一个很便宜的粉白色老头，玩耍效果很好。” }
我没有消灭 AI 的判断力，而是给它判断的出口。我允许它识别出”这是脏数据”，但规定它识别之后的行为——不是用自然语言抱怨(Claude 模式)，不是擅自修正(DeepSeek 模式)，而是用结构化数据报告。我把”拒绝”这个动作，也封装进了 JSON。
我把一份混着乱码、”粉白色老头”、正常商品和空值的测试文档，分别丢给 Claude 和 DeepSeek。
两个模型都乖乖把正常商品送进了 success 通道，把”粉白色老头”和其他奇葩输入送进了 error 通道。整个输出仍然是一份 100% 结构化的 JSON 数组，系统解析零报错。运营在后台一键筛选 status == “success” 直接批量上架，一键筛选 status == “error” 把所有脏数据揪出来人工修正。
那一刻我才意识到——大模型在这里，顺手干完了一个数据清洗工的活。
这就不只是”保证系统不崩溃”的防御性价值了。我把”AI 文案生成”和”自动化数据清洗”这两个原本独立的研发步骤合到了一起。过去你需要一个 NLP 模型做数据清洗，再用一个大模型做文案生成，两套系统、两个团队、两份成本。现在一套 Prompt 设计，让同一个大模型在生成内容的同时，顺带把数据质检做了。
写到这里我得诚实交代一件事。我做完这套设计、有点小得意的时候，跟一个做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 产品，我的建议是：别贪多，带着一个真实问题去和它打交道。被它坑过几次，你比读十本书学得快。
至少对我来说是这样。
本文由 @汪仔0414 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。