AI产品经理必备：Prompt Engineering如何影响产品定义
一句话总结
Prompt Engineering 不是技术人员的工具实验，而是 AI 产品定义的核心控制层。大多数公司误以为它只是调参技巧，实则是在重新定义“用户需求”本身——从“用户想要什么功能”，变为“用户如何被系统理解”。正确看待 Prompt Engineering 的 PM，已经开始用它重构产品逻辑、交互路径和商业模式；
而仍把它当作 NLP 优化手段的人，正在设计注定失败的 AI 功能。这不是工程问题，是产品哲学的分水岭。
适合谁看
本文适用于三类人：第一类是正在从传统 PM 转向 AI PM 的从业者，你可能已经面试过 2-3 家 AI 公司但总在 final round 被卡住，原因是你还在用功能拆解思维做 AI 产品；第二类是入行 1-3 年的初级 AI PM，你每天在写 prompt 文档但感觉像在打杂，因为你没意识到自己其实在设计产品的“认知边界”；第三类是 tech lead 或 founding PM，在决定是否将 Prompt Engineering 纳入产品架构时犹豫不决，你需要知道：你现在不做，竞品会用它反过来吞噬你的用户心智。如果你 base 在湾区，目标公司是 Google、Meta、Anthropic 或前 100 的 AI 初创，且 base salary 在 $130K–$180K 区间，这篇就是为你写的。
薪资结构上，头部公司 AI PM 的典型 package 是 base $160K + RSU $200K/year + bonus 15%，总包接近 $400K；中型初创可能是 base $140K + RSU $150K + 10% cash bonus，但早期期权可能翻倍。这些数字背后，反映的是市场对“能定义 AI 交互”的 PM 的极端渴求。
Prompt Engineering 是产品设计，不是技术调优？
大多数 AI 产品会议里，Prompt Engineering 被当作一个技术环节塞进“模型上线前优化”阶段。典型场景是：产品原型已定，UI 画完，突然发现 LLM 输出不稳定，于是 PM 扔给工程师一句“你去调一下 prompt”。这种流程注定失败。
真正的事实是：Prompt Engineering 应该发生在产品定义的第一天，甚至在 PRD 写之前。它不是对已有设计的修补，而是设计本身的源头。
我在一次 Meta 的 hiring committee（HC）debate 中亲眼见过这个冲突。候选人设计了一个“AI 写周报”功能，架构是“用户输入本周工作 → AI 生成正式汇报”。他的 prompt 是：“请根据以下内容生成一份专业周报，语气正式，结构清晰。”面试官问：“如果用户只写了‘改了三个 bug’，你会怎么处理？”候选人回答：“那 prompt 就需要更详细，比如要求模型追问细节。”面试官立刻否定：“错。
问题不在 prompt 本身，而在你对‘用户输入’的假设。你预设用户会提供结构化信息，但现实是碎片化输入。正确的做法是：把 prompt 当作交互设计的一部分，让用户在输入时就被引导补全信息——比如自动追问‘这三件事的目标是什么？影响了哪个模块？下一步计划？’”这轮 debrief 的结论是：“他还在把 prompt 当输出控制，而不是输入塑造。”
不是你在优化输出，而是你在设计输入路径。
不是 prompt 要更精准，而是产品要更适应模糊输入。
不是技术问题，而是信息架构问题。
Google 内部有个不成文规则：所有 AI 功能的 first draft PRD，必须附带三个 baseline prompt variants，并附上 mock 输出对比。这不是为了测试模型，而是强迫 PM 思考：“用户到底在请求什么？”例如，同样是“总结会议”，不同 prompt 会导向完全不同产品路径：
- “用三点总结会议要点” → 输出结构化摘要
- “告诉我哪些决策需要跟进” → 输出 action items
- “用老板能听懂的方式重述讨论” → 输出向上汇报版本
这三个 prompt 实际上定义了三个不同产品。但如果你先画了 UI 再写 prompt，你只会得到一个“看起来能用”的功能，而不是一个“解决真实问题”的产品。
为什么你的 AI 功能总被用户“绕过”？
用户不用你的 AI 功能，不是因为模型不准，而是因为交互逻辑与用户认知错位。典型场景是：你在产品里加了个“AI 帮写回复”按钮，用户点开，输入“回复老板”，AI 输出一段正式邮件。用户看完，删掉重写。你复盘时归因为“prompt 不够个性化”，于是加了 tone 调节滑块。结果使用率还是上不去。
真实原因不是个性化不足，而是你误解了用户的“决策节点”。在一次 Slack 的 user debrief 会上，研究员播放了一段用户录屏：用户收到老板消息“下周能上线吗？”，他点开 AI 回复，输入“告诉老板我们还在测试”，AI 输出：“尊敬的老板，目前我们正处于测试阶段，预计下周可以上线。”用户直接删掉，手打：“还在测，可能要拖到下周二。
”研究员问：“为什么不改 AI 的？”，用户说：“它说得太肯定了。我要留余地。”
这里的关键洞察是：用户不是在“写回复”，而是在“管理预期”。AI 生成的“预计下周可以上线”传递了确定性，但用户的真实意图是“推迟但不承诺”。这不是 tone 问题，是策略问题。正确的 prompt 设计应该捕捉这种“模糊表达”的需求。比如：
“生成一个推迟请求的回复，保持礼貌但不承诺具体时间，暗示可能延迟”
而不是：
“用中性语气回复，说明还在测试”
不是用户需要更准的输出，而是产品需要理解用户的社交策略。
不是 AI 要更像人，而是要理解人在不同场景下的“表达面具”。
不是功能缺失，而是意图识别漏掉了权力关系这一层。
我在一个 early-stage AI startup 做顾问时，看到他们的“AI 写 OKR”功能使用率极低。PM 的辩解是：“用户不习惯 AI 写目标。”但数据看，用户在其他文本生成场景使用频繁。
深入看 session log 发现：用户输入“写一个 Q3 OKR”，AI 输出：“O: 提升用户留存率，KR1: DAU 提升 10%…” 用户直接关闭。而当 PM 改为 prompt：“生成一个向上汇报用的 OKR，看起来有挑战但可解释”，输出变成：“O: 探索用户留存新策略，KR1: 完成三项留存实验设计…” 使用率立刻翻倍。
差别在哪？前者是“真实目标”，后者是“组织政治可接受的目标”。用户不是在写 OKR，是在写“让老板觉得我有 ambition 又不冒进”的文档。Prompt Engineering 的本质，是解码这种组织语境下的“表面意图”与“真实诉求”的差距。
如何用 Prompt Engineering 重构产品边界？
多数 AI 产品把功能边界定在“输入 → 输出”，但真正的竞争发生在“输出 → 行动”这个隐性链条。Prompt Engineering 的战略价值，是让你提前设计用户拿到输出后的下一步行为。这才是产品护城河。
典型例子是 Notion AI 的“继续写”功能。表面看，它只是补全文本。但它的 prompt 隐含了产品逻辑：“在用户停顿处预测下一个合理动作”。比如用户写完“会议结论：”，prompt 会触发“列出 3-5 个要点”的生成模式；如果写完“待办：”，则触发“生成可勾选任务项”。这背后不是简单的文本补全，而是通过 prompt 定义了“什么是合理的延续”。
我在参与一个 enterprise SaaS 的 AI 重设计时，客户抱怨“AI 生成的报告没人看”。我们审查了流程：用户上传数据 → AI 生成 PPT → 用户下载。看似完整，但用户行为数据显示，87% 的人在生成后立刻关闭页面。
访谈发现，他们真正需要的不是“报告”，而是“说服老板的依据”。于是我们重构 prompt：不再生成完整 PPT，而是生成“三个可用于汇报的关键洞察”，并自动附加“数据来源标注”和“可能被挑战的应对话术”。结果：分享率从 12% 提升到 61%。
这里的关键转变是：从“交付输出”变为“赋能行动”。
不是你在生成内容，而是在降低用户的下一步成本。
不是功能完整性，而是行动闭环性。
更进一步，Prompt Engineering 可以成为商业模式的杠杆。比如，一个 legal tech startup 发现，用户不愿为“合同生成”付费，但愿意为“风险点提示”买单。他们调整了 prompt 优先级：不是先生成合同，而是先用 prompt 提取“本条款可能引发的三种诉讼场景”。
用户拿到这个输出后，更愿意继续使用完整功能。这里，prompt 成了漏斗前端的钩子。
我在一次 investor pitch review 中听到创始人说：“我们的 prompt 优化使 conversion 提升 40%。”我问：“你怎么定义 conversion？”他说：“从免费生成到付费下载。”我追问：“为什么用户愿意付？
”他答不上来。后来我们发现，真正起作用的是付费前的“AI 建议”环节：免费用户能看到“以下是高风险条款”，但只有付费才能看“如何修改”。这个“信息分层”是由 prompt 控制的——免费 prompt 只提取问题，付费 prompt 才提供解决方案。这不是技术实现，是商业设计。
AI 产品经理的面试流程，考察什么？
想进一线公司做 AI PM，你必须理解面试官在找什么。以 Google 为例，AI PM 面试共 5 轮，每轮 45 分钟，全程 2 天完成。
第一轮：Product Sense（考察产品直觉）。典型题：“设计一个 AI 助手帮销售写客户邮件。”面试官不要你画 UI，而是问：“如果客户只说‘写个跟进邮件’，你怎么知道该用什么 tone？要不要提价格？要不要设 deadline？
”正确回答不是列功能，而是反问：“销售和客户处于什么阶段？上次互动是什么？公司当前的 push 重点是什么？”你在用问题定义 prompt 的上下文边界。这一轮淘汰 40% 的人，败因往往是“直接跳解决方案”。
第二轮：Execution（执行能力）。给你一个已上线的 AI 功能，说“使用率下降”，让你分析。关键不是给改进方案，而是先定义指标：“使用率”是指点击？生成？
还是采纳？我在一个 debrief 会上听到面试官说：“候选人一上来就说要优化 prompt，但连 baseline 数据都没要。他以为问题在模型，其实可能在触发时机。”正确做法是先问数据维度，再推断问题层。
第三轮：Technical Dive（技术理解）。不是考你写代码，而是问：“如果 prompt 变长，模型 performance 下降，你怎么定位？”你要能区分是 context window 限制、attention dilution，还是 semantic drift。一个优秀回答是：“先做 ablation test：固定输入，逐步增加无关文本，看输出偏差何时出现。
如果是 linear degradation，可能是 attention 问题；如果 sudden break，可能是 token limit 截断。”这轮考的是你能否把 prompt 行为映射到模型机制。
第四轮：Leadership & Influence（领导力）。场景题：“工程师说 prompt engineering 是临时方案，拒绝投入资源。你怎么说服？”错误回答是“我用数据证明有效”。正确回答是：“我先承认他的观点——长期确实要 fine-tuning。
但指出：现在每改一次 prompt，我们能 10 分钟验证一个假设；而 retrain 模型要 2 周。在产品探索期，速度决定生死。prompt 是我们的低成本实验层。”你要把技术争论升维到产品节奏。
第五轮：Case Study（综合应用）。现场给一个模糊需求：“帮客服团队用 AI 提效。”你有 10 分钟提问，30 分钟设计方案。高分者会先问：“客服的 pain point 是打字慢，还是决策难？如果是决策，那 prompt 应该聚焦‘推荐解决方案’；如果是打字，才是‘生成回复’。”他们用 prompt 的设计方向反推问题本质。
整个流程不考“你知道多少 prompt 技巧”，而是考“你是否把 prompt 当作产品控制点”。败因往往是：把 AI 当工具，而不是产品本身。
准备清单
- 系统性拆解 prompt 的四个维度：角色（role）、任务（task）、格式（format）、约束（constraints）。每次写 prompt 前自问：“我在定义产品边界吗？”例如，“你是一位资深律师，用 bullet point 列出本条款的三个法律风险，每个不超过 20 字” 比 “分析合同风险” 更具产品控制力。
- 掌握至少三种 prompt pattern：zero-shot（直接指令）、few-shot（给例子）、chain-of-thought（要求分步推理）。在设计产品时，选择哪个 pattern 实际上是选择“用户教育成本”与“输出可靠性”的权衡。few-shot 虽准确但需 UI 展示示例，增加认知负荷。
- 建立 prompt 版本控制系统。不是用 Git 管代码，而是用 Airtable 记录每次 prompt 修改对应的输出样本、用户反馈、指标变化。我在 Airbnb 看到一个团队用“prompt A/B test”替代功能迭代，两周内将采纳率提升 35%。
- 学会在 PRD 中嵌入 prompt 设计。不是附加文档，而是写在“用户流程”节点里。例如：“当用户选择‘正式’语气时，系统调用 formal-tone-v3 prompt，其约束条件包括：禁用缩写、使用被动语态、每段不超过 3 句。”
- 理解模型的上下文机制。知道 4K、8K、32K context window 的实际意义——不是你能输多少字，而是模型能“记住”多少信息做推理。在设计长文档处理功能时，prompt 必须包含“分块摘要 → 跨块关联”的指令，否则输出会丢失全局逻辑。
- 准备 3 个实战案例，说明你如何用 prompt 改变产品路径。例如：“原计划做 AI 写简历，测试发现用户不信任全自动生成。改为用 prompt 引导用户输入关键词，实时生成优化建议，转化率翻倍。”这不是技术优化，是产品 pivot。
- 系统性拆解面试结构（PM面试手册里有完整的AI PM实战复盘可以参考）——包括如何在 case interview 中用 prompt 设计展现产品深度。
常见错误
错误一：把 prompt 当作一次性配置
BAD：在开发后期才写 prompt，发现输出不准，于是反复调整词句，如从“总结内容”改为“简洁总结内容”。这就像 UI 定稿后才改交互逻辑。
GOOD：在产品构思阶段，用 prompt mockup 验证假设。例如，先写三个不同 prompt，用 GPT-4 生成输出，给用户盲测：“哪个最像你会发的？”用反馈决定功能方向。我在一个 health tech 初创见到这种做法，省去了两个月开发浪费。
错误二：忽视 prompt 的可维护性
BAD：一个 500 字的 prompt 嵌套 10 层指令，团队无人敢改。上线后发现模型更新导致输出漂移，但没人知道哪条规则冲突。
GOOD：采用模块化设计。如将 prompt 拆为：roleprompt + taskprompt + style_prompt，通过变量组合。Google Docs AI 团队就用这种架构，使 prompt 迭代速度提升 3 倍。
错误三：混淆 prompt 与 fine-tuning 的职责
BAD：因为 prompt 无法稳定输出专业术语，就决定 fine-tune 模型。耗时 3 周，成本 $20K，结果发现用户根本不需要那么专业。
GOOD：先用 few-shot prompt 验证需求真实性。在 legal AI 项目中，我们加了 5 个示例，输出立刻改善。用户测试显示已满足需求，省下 retraining。Fine-tuning 是产品确定后的加速器，不是探索期的拐杖。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
Q：Prompt Engineering 会取代传统产品需求文档（PRD）吗？
不会取代，但会重构其核心。传统 PRD 以功能模块为中心，比如“用户可点击按钮生成摘要”。而 AI 时代的 PRD，必须以“交互路径+prompt策略”为中心。例如，PRD 应写：“当用户选择‘快速摘要’模式，系统调用 quick-sum-v2 prompt（见附录），其设计原则是牺牲细节换速度，输出不超过 3 句。
用户反馈‘太简略’时，自动推荐切换至‘详细版’。”我在 Amazon 的一个项目中见过，团队用 prompt 变更替代了 70% 的 UI 改动——原本要加“长度滑块”，后来发现用“生成短版，点击展开”配合两个 prompt 就解决了。PRD 从“画界面”变为“定义决策树”，这才是本质变化。
Q：小公司没有专门 prompt engineer，PM 要自己写吗？
必须自己写，至少在早期。不是因为你技术强，而是因为 prompt 是产品意图的直接表达。我在一个 15 人 AI 初创看到，CEO 要求所有 PM 每天 hand-write 20 个 prompt 并记录输出。他说：“你不亲手试，就不知道用户会怎么被误导。”一个典型例子：PM 想做“AI 写情书”，初始 prompt 是“写一封浪漫的情书”。
测试发现输出过于华丽，不像真人。改为“用普通人会说的话，表达在乎但不肉麻”，立刻改善。这个洞察只能来自 PM 对用户的理解，不是工程师能猜到的。你的 prompt 要体现产品人格，而人格是 PM 定义的。
Q：如何衡量 prompt 的效果，而不只是模型 accuracy？
别看 BLEU 或 ROUGE 分数，那都是伪指标。真实衡量是看用户行为。例如，在一个 email assistant 产品中，我们跟踪“AI 生成 → 用户修改 → 发送”的编辑量。发现平均修改 7.2 个词时使用率最高——说明输出足够好用，但留有控制感。完全不改（0 词）和大改（>15 词）的用户都流失快。
于是我们将 prompt 优化目标定为：“引导输出接近 7 词修改区间”。另一个指标是“二次生成率”：如果用户生成后立刻点击“再试一次”，说明第一次输出偏离预期。我们将这个 rate 从 38% 降到 14% 后，留存提升 22%。效果不在模型输出，而在用户下一步动作。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。