提示词与任务设计

「产品经理的大模型基础」系列之三
上一篇：大模型的训练与推理 · 系列入口 · 下一篇：模型 API 与基础编程

提示词通常是人接触大模型时最先学习的内容，也最容易被误解成一套“特殊话术”。

实际上，稳定的大模型应用很少依靠一句神奇指令。提示词更接近一份任务说明：它需要告诉模型要做什么、为什么做、输入是什么、遵守什么规则，以及结果应该是什么形式。

这篇文章主要介绍五部分：结构化提示词、Few-shot 示例、任务拆解、结构化输出，以及程序校验。它们共同解决的不是“怎样让模型更聪明”，而是怎样把任务说清楚、把结果接住，并在出错时知道错在哪里。

一、提示词的本质是任务说明

假设产品经理把一份用户访谈交给模型，只说：

帮我分析一下。

模型当然可以生成内容，但“分析”可能意味着摘要、提取痛点、判断需求、分析情绪或提出方案。读者脑中想要的结果，并不会自动出现在模型上下文中。

一个相对完整的提示词通常包含：

并不是每次都必须把八项写得很长。简单翻译可能一句话就够；涉及企业规则、特定分类口径和后续程序处理时，则需要更明确的说明。

其中，“角色”不是让模型进行神奇的角色扮演。它真正的作用是限定责任、视角和术语。例如，“你负责从访谈中提取证据，不负责提出方案”，就比“你是世界顶级产品专家”更容易执行和检查。

二、结构化提示词怎样减少歧义

“帮我分析访谈”可以改成：

角色：你是一名用户研究分析员，只负责整理访谈证据，不替受访者补充观点。

任务：从访谈中提取用户目标、痛点和现有解决方式。

背景：分析结果用于发现产品机会，不直接用于功能排期。

约束：
1. 只能使用访谈中出现的信息。
2. 每条痛点必须附一段用户原话。
3. 不要把单个受访者的观点写成普遍结论。
4. 信息不足时明确标记。

输出：按“用户背景、核心诉求、痛点、原始证据、现有方案、高频观点、产品机会、未知信息”八部分返回。

这段提示没有使用复杂技巧，只是把产品经理原本隐含的判断标准写了出来。

结构化提示词的价值主要体现在三点：模型更容易理解任务；不同人可以重复使用同一口径；结果不符合要求时，团队能找到需要修改的部分。

三、Zero-shot 与 Few-shot

如果只给任务说明，不给示例，通常称为 Zero-shot。如果在上下文中提供一个或多个输入输出示例，则称为 Few-shot。

示例能够向模型传递很多抽象规则难以表达的内容，例如：

• 分类边界。
• 表达风格。
• 字段填写方式。
• 什么情况下应该标记不确定。
• 团队内部术语的真实用法。

例如，团队把用户问题分成“使用障碍”和“价值质疑”。用户说“这个功能在哪里”比较像使用障碍；用户说“这个功能对我没用”更像价值质疑。只写标签名称可能不够清楚，加入两三个典型例子会更有效。

Few-shot 也可能带来问题。示例错误或过于单一，模型会模仿错误规律；示例太多会占用上下文；示例与当前任务不一致，会导致冲突。

因此，示例的价值不在数量多，而在于准确覆盖典型情况和容易混淆的边界。

四、任务拆解：不要让模型一次承担所有判断

复杂任务常常包含多个不同动作。比如“根据用户访谈提出产品方案”，至少包括：

1. 从原文中提取事实和观点。
2. 把相似观点归纳成主题。
3. 判断哪些主题值得关注。
4. 根据主题提出产品机会。

如果让模型一次完成，最终结果即使有问题，也很难判断是事实提取错了、主题归纳错了，还是产品判断过度。

拆成多个步骤后，每一步都更简单：

提取用户原话与事实
→ 根据证据归纳主题
→ 保留矛盾观点和未知信息
→ 基于主题提出机会

任务拆解的目的不是让流程显得复杂，而是降低每一步的认知负担，并让中间结果可以检查。它也是后续 Workflow 的基础。

一种常用模式是“先分类，再处理”。例如，先判断一条反馈属于缺陷、需求、咨询还是无效信息，再根据类别选择不同的提取字段和后续流程。专业上，这相当于先完成 Routing（路由），再执行专门任务；大白话就是先决定“这件事该送到哪条流水线”，不要让同一个提示词包办所有情况。

五、结构化输出：让结果能够继续被系统使用

如果模型结果只是给人阅读，普通段落或 Markdown 已经足够。如果结果还要进入数据库、看板或下一步程序，结构化输出更合适。

例如，访谈分析可以使用这样的 JSON：

{
  "user_background": {
    "summary": "",
    "evidence": []
  },
  "core_needs": [],
  "pain_points": [
    {
      "description": "",
      "evidence": "",
      "confidence": "high | medium | low"
    }
  ],
  "current_solutions": [],
  "frequent_views": [],
  "contradictions": [],
  "product_opportunities": [
    {
      "description": "",
      "based_on_evidence": []
    }
  ],
  "unknowns": []
}

结构化输出带来几个好处：

• 程序可以检查必填字段。
• 多份结果可以统一统计。
• 下一步模型调用可以准确读取字段。
• 不同版本的输出更容易比较。

但需要注意，格式正确不等于内容正确。模型完全可能返回符合 JSON 结构的错误结论。因此，结构校验解决的是“能否被系统处理”，事实与质量仍需其他评估。

六、程序校验：不要直接相信模型返回的 JSON

当模型输出要进入数据库、自动化流程或下一个模型调用时，程序通常还要做 Validation（校验）。校验至少分三层：

1. 结构校验：能否解析为 JSON，必填字段是否存在，字段类型是否正确。
2. 业务规则校验：枚举值是否合法，分数是否在范围内，日期和 ID 是否符合系统规则。
3. 证据校验：引用的原话是否真的出现在输入中，结论是否有对应材料支持。

JSON Schema 是常见的结构约束工具。它可以规定 confidence 只能是 high、medium、low，也可以规定 pain_points 必须是数组。但它无法判断一条痛点是否真的来自访谈，因此证据校验和人工抽查仍然必要。

校验失败后的处理也要预先设计：可以把明确的格式错误连同错误原因交给模型有限重试；如果缺少证据、涉及高风险判断或多次重试仍失败，则应转人工。所谓“程序验证模型输出”，大白话就是模型负责起草，程序负责验收，不让一段看起来像数据的文字直接驱动系统。

七、提示词在真实产品中的位置

用户在界面中输入的内容，只是最终提示上下文的一部分。一个真实产品还可能自动加入：

• 系统角色和安全要求。
• 用户身份和权限。
• 企业术语和业务规则。
• 从知识库检索到的材料。
• 工具定义。
• 之前步骤产生的结构化结果。

所以，产品中的提示词设计不仅是编写一句文案，还包括上下文怎样组装、不同信息的优先级、超长内容怎样压缩，以及哪些信息不能进入模型。

这类工作常被称为上下文工程。

八、提示词不能解决所有问题

提示词能够减少任务歧义，但不能替代：

• 最新事实和企业知识。
• 精确计算与数据库查询。
• 权限控制。
• 工具参数校验。
• 结果评估。
• 高风险场景中的人工判断。

如果模型不知道最新退款政策，不断修改措辞不如把正确政策提供给它；如果系统要真正创建任务，仅让模型输出“已创建”也不会改变业务系统状态。

九、产品经理常见的提示词误区

追求万能长 Prompt

把所有规则堆进一个提示词，最终会出现冲突、重复和难维护。稳定规则、动态知识、用户输入和工具说明应分开管理。

用角色扮演代替任务定义

“你是世界顶级产品专家”可能影响表达风格，却不能代替清晰的输入、约束和验收标准。

只看一次结果

大模型输出具有概率性。一个提示词是否稳定，需要在多种真实和边界输入上观察，而不是只看最理想的一次回答。

要求模型自行保证绝对正确

“请确保百分之百准确”不会自动增加知识、权限或验证机制。

本篇小结

提示词的核心不是特殊话术，而是任务设计：

用明确的角色、任务、背景、输入、约束、格式、标准和示例减少歧义；用任务拆解暴露中间判断；用结构化输出连接系统；再用程序校验守住格式、业务规则和证据边界。

下一篇将介绍产品怎样真正调用模型：Python、JSON、HTTP 和模型 API 分别承担什么角色。

上一篇：大模型的训练与推理　下一篇：模型 API 与基础编程