一场让人眼前一亮的AI产品经理面试：他开口，我就知道他很懂Prompt

最近面试了一位男生，谈到AI交互设计时，他对提示词的拆解思路让人眼前一亮。

当多数人还在纠结怎么写指令时，他已经把Prompt当成一个可迭代、可量化的产品模块来设计。

面试开场

我问他："如果让你设计一个'面试邀约邮件生成器'，帮HR自动生成个性化邀约文案，你会怎么考虑提示词设计？"

他没有直接写指令，而是从目标拆解切入：

"首先得定义什么是'好的邀约邮件'。是正式严谨，还是亲切活泼？要不要突出公司亮点？候选人关心的薪资、岗位匹配度怎么体现？我的第一步是拉取公司过去发出且回复率最高的5封邮件，提炼出共性要素。"

第一反应就让我刮目相看。 大多数人一上来就写"请帮我写一封面试邀约邮件"，而他要先定义"什么是好的"。

这一点背后体现的是一个很重要的思维习惯：在动手之前先定义验收标准。传统产品经理在做功能设计时，第一步也是明确"成功的标准是什么"，然后再考虑功能如何实现。把这个思路迁移到 Prompt 设计上，就是先定义"好的输出长什么样"，再用提示词来引导模型达到这个标准。这种目标导向的设计思维，正是优秀 AI 产品经理和普通用户之间的核心区别。

分层框架

"然后呢？"我追问。

"我会设计一套分层提示词框架。"他清晰地回答：

"第一层是角色设定，让AI扮演资深HRBP，熟悉公司文化和岗位要求。

第二层是任务描述，包括候选人信息、岗位名称、期望到岗时间等关键字段。

第三层是格式规范，规定标题写法、正文分段、落款格式、字数限制。

最后设置负面清单，明确禁止出现'薪资面议''急招'等容易被忽略但影响体验的词。"

我追问："这和传统功能设计有什么本质区别？"

他稍作停顿，给出了让我真正记住的回答：

"本质上是相同的——把模糊需求拆解成可执行的参数。但Prompt设计更需要'非功能需求'的预判。用户不会说'请生成一段400字以内、前三行突出亮点、结尾加一句期待面谈'，他们只会说'写得真诚一点'。所以好的Prompt框架要能把这句'真诚'映射到具体的语气词选用、句式长短、人称代词等可调节维度上。"

这个回答非常到位。传统软件开发中，功能需求相对明确（用户能操作什么），非功能需求需要开发者自行考虑（性能、安全、用户体验等）。Prompt 设计也是一样——用户对输出有一个模糊的感觉，但把这种感觉翻译成具体的模型可控参数，需要深刻的理解和系统化的思维。

关键亮点：Few-shot + 反馈闭环

更让我惊喜的是，他主动提到了两个大多数人忽略的设计：

关于Few-shot设计：

"我会在Prompt里嵌入1-2个真实的高转化案例，让模型直接模仿其语气和结构。"

这里涉及到一个重要的认知：与其花费大量文字描述你想要的风格，不如直接给 AI 一个例子。研究表明，Few-shot 示例对于稳定输出风格的效果远比文字描述好。一个具体的案例胜过一百个抽象形容词。

关于反馈闭环：

"当HR点击'换一版'时，记录被拒的版本特征，比如'太啰嗦'或'太官方'，下一次生成时自动调整。"

这个想法把 Prompt 变成了一个可以学习进化的"活系统"，而不是一段固定的文本。这也是个人认为 Prompt Engineering 最有价值的方向——让优质提示词在组织内部流动、迭代、沉淀为团队共识，而不是仅靠几只野生提示词打天下。

5个关键认知

他的回答展现出几个关键认知：

1. 解构能力

将"写得好"拆解成角色、格式、示例、负约束等具体维度。不是笼统地说"帮我写封邮件"，而是定义"好的邮件长什么样"。

这种解构能力从本质上反映了个体如何理解问题空间的深度。有些人看到的是一团混沌的需求，有些人看到的是一个个可以独立优化的变量。能够解构的人，才能在 AI 时代把模糊的感觉变成清晰的指令，真正驾驭模型的生成能力。

2. 框架化思维

用角色+任务+格式+约束四层结构管理生成质量。每一层都有明确的输入输出，而不是把所有要求塞进一段话。

这种分层框架还有一个好处：复用性。同一个角色设定可以复用在多个不同的任务上，同一种格式规范可以跨场景使用。当这些"组件"积累到一定数量后，产品经理就可以快速拼装出适用于新场景的 Prompt，而不需要从零开始。

3. 示例驱动

理解Few-shot对稳定输出风格的决定性作用。与其用语言描述"请写得亲切"，不如给一个真实的亲切案例让模型模仿。

Few-shot 的工作原理其实非常直观。模型通过观察示例中的模式（语气、结构、用词偏好），学会在新的上下文中复现这些模式。这里有一点需要注意的是，示例的质量直接决定了输出的质量——如果你给的是一封写得平平无奇的邮件作为示例，那生成的邮件大概率也平平无奇。所以选择高质量、有代表性的示例至关重要。

4. 反馈闭环

将用户"不满意"行为转化为可执行的优化信号。"换一版"不是失败，而是数据——记录被拒原因，下次自动调整。

这个环节的实际落地方式有很多种。最基础的做法是在数据库中记录每次"换一版"操作前后的 Prompt 版本和输出内容，然后用 LLM 做对比分析。更高级的做法是引入强化学习：把用户满意/不满意当作奖励信号，持续优化 Prompt 的每个组件（角色设定、任务描述、示例选择、约束条件等）。

5. 产品化视角

把提示词当成需要A/B测试、版本管理的核心资产。不是一次性写完就完事，而是持续迭代、数据驱动的"产品"。

版本管理这件事在实践中经常被忽视。很多团队拿一个 Prompt 在用，但没有人记录它经过了几次迭代、每个版本的差异是什么、哪个版本在哪个场景下效果更好。当团队人员变动时，这些"隐性知识"就丢失了。尽早建立 Prompt 的版本管理习惯，长远来看会节省大量的重复劳动。

为什么这些认知如此重要？

这位候选人让我意识到，Prompt Engineering 的本质不是"会写指令"，而是"会设计系统"。

传统产品经理设计功能时，会考虑：

• 用户是谁、需求是什么
• 功能流程、信息架构
• 异常处理、边界情况
• 数据埋点、效果验证

而优秀的AI产品经理设计Prompt时，同样需要考虑：

• 角色设定：AI是谁、有什么能力
• 任务拆解：输入什么、输出什么
• 质量框架：什么是"好"、怎么衡量
• 异常处理：模型幻觉、格式错误怎么办
• 反馈闭环：用户不满意时如何优化

两者的底层逻辑完全一致——把模糊的需求，变成可执行、可衡量、可迭代的系统。

给面试官的信号

这位候选人的回答，让我总结出几个判断"是否懂Prompt"的信号：

如果你正在招AI产品经理，不妨用这个问题面试。 候选人的回答层次，能快速帮你判断他的Prompt能力处于哪个阶段。

实际面试中，你还可以进一步深入追问："你怎么评估一个 Prompt 的效果？""如果模型在某个场景下表现不稳定但在另一个场景下滑，你怎么定位问题？""你如何把一个验证有效的 Prompt 推广到整个团队？"这些问题能帮你在候选人的回答框架之上，进一步看清他的实操深度。

📌 深入阅读： 想系统学习如何从"写指令"升级到"设计提示词系统"？推荐阅读 Prompt Engineering 进阶：从"写指令"到"设计可迭代的提示词系统"，深入讲解5个关键认知的实战方法和代码示例。