

### 题目分类
- 方向：Prompt 工程

### 考察点
- 能否把高质量 Prompt 理解为可执行、可验证的任务契约，而不是固定话术或关键词集合
- 能否围绕任务目标、输入上下文、边界约束、输出契约、示例和验收标准组织 Prompt
- 能否解释角色设定、分隔符、few-shot 示例分别适合解决什么问题，以及它们的能力边界
- 能否根据失败样本迭代 Prompt，而不是不断追加“请认真”“必须严格”等无效强调
- 能否通过版本管理、固定评估集和线上指标验证 Prompt 修改是否有效
- 能否区分软约束与硬约束，知道何时使用 RAG、工具、Schema、代码校验或人工审核

### 知识讲解
#### 1. 高质量不等于写得长
高质量 Prompt 的判断标准不是字数多、格式复杂或语气强硬，而是模型能否准确理解任务，并在一组真实输入上稳定地产生符合要求的结果。Prompt 的作用是减少模型不必要的猜测：要做什么、依据什么、哪些事情不能做、结果交给谁使用，以及怎样才算完成。

一句“你是一位世界顶级专家，请认真分析”可能改变表达角度和语气，但不会给模型补充缺失的业务数据，也不能保证事实正确。真正影响结果的通常是任务是否具体、输入是否相关、规则是否一致、输出是否可验证，以及失败时有没有明确处理方式。

因此，高质量 Prompt 更像一份面向概率模型的接口契约。它不追求一次回答看起来惊艳，而是追求同类请求可复现、可评估、可维护。

#### 2. 六个核心组成部分
**任务目标**要说明模型具体做什么、结果给谁使用，以及完成任务的目的。相比“总结文档”，“为采购负责人提取会影响付款和交付的合同风险”明显减少了目标歧义。

**输入上下文**要提供完成任务真正需要的材料，并清楚标记材料边界和来源。系统规则、用户输入、检索证据和工具结果不应混成一段。分隔符或 XML 风格标签能帮助模型识别结构，但不能自动消除提示词注入风险；不可信内容仍要隔离、过滤并限制权限。

**边界约束**要把决策规则写成可执行条件，例如只依据给定材料、不得补充未出现的事实、信息不足时返回什么状态。约束应具体且互相一致，十次重复“不要幻觉”不如明确说明允许使用的证据和缺失信息处理方式。

**输出契约**要根据消费方定义结构、字段、长度、语气、引用和异常状态。给人阅读可以规定章节和重点；给程序消费应配合 Structured Outputs、JSON Schema 和运行时校验，不能把自然语言要求当成强协议。

**示例校准**适合表达抽象规则难以覆盖的分类边界、格式、语气和反例。示例要少而有代表性，输入与输出必须符合当前规则。错误、过时或互相冲突的示例会被模型模仿，示例数量增加也不等于效果一定提高。

**验收标准**说明怎样判断输出是否合格，例如事实只能来自证据、每个结论必须有引用、必须覆盖五类风险、无法判断时不得猜测。没有验收标准，团队只能凭“看起来不错”迭代，很难证明新版本是否真的更好。

图解：高质量 Prompt 由六类信息共同组成，并通过评估集、失败分桶、最小修改和回归验证形成迭代闭环。

![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/45d24b552e0c501462a39f678659e3d0.png)

#### 3. 从模糊需求改成可执行 Prompt
下面两段 Prompt 使用同一个模型，但模型需要猜测的信息量完全不同。

```text
较弱的 Prompt：
帮我看看这份客服对话有什么问题，写得专业一点。

较高质量的 Prompt：
角色：你是 SaaS 客服质检员，结果供客服主管复盘使用。

任务：分析对话中影响问题解决率的服务问题，并给出可执行改进建议。

质检范围：
1. 是否正确识别用户诉求。
2. 是否给出与现有知识库一致的解决步骤。
3. 是否出现推诿、过度承诺或遗漏关键信息。

证据边界：
- 只依据 <conversation> 和 <knowledge> 中的内容。
- 不推测用户身份、情绪或未发生的操作。
- 证据不足时写“无法判断”，并说明缺少什么信息。

输出：
- 总结：不超过 80 字。
- 问题列表：每项包含问题类型、原对话证据、影响和改进建议。
- 没有发现问题时返回“未发现可证实问题”，不要凑数。

验收标准：
- 每个问题都能定位到原对话。
- 建议必须对应具体问题，且不超出知识库能力范围。

<knowledge>{{知识库片段}}</knowledge>
<conversation>{{客服对话}}</conversation>
```

改进点不在于模板变复杂，而在于补齐了目标、检查范围、证据边界、异常状态和结果结构。实际使用时不必机械保留“角色、任务、要求”这些标题，只要信息边界清楚、规则可执行即可。

#### 4. 编写顺序与常见误区
编写 Prompt 时可以先用一句话定义成功结果，再列出模型完成任务必须知道的材料和规则，然后设计输出契约，最后只为仍然模糊的边界添加示例。这样能避免一开始套用庞大模板，把与当前任务无关的要求全部塞进去。

正向、具体的指令通常比单纯禁止更容易执行。例如与其写“不要啰嗦”，不如写“先给结论，再列三条依据，每条不超过 40 字”；与其写“不要编造”，不如定义可用证据来源和 `insufficient_evidence` 状态。

还要避免规则堆叠。Prompt 在线上出现失败后，如果每次都在末尾追加一句补丁，很快会产生重复、冲突和优先级不清。修改前应先判断失败来自任务歧义、上下文质量、模型能力、工具缺失还是业务校验不足，再决定在哪一层修复。

#### 5. 怎样迭代出高质量 Prompt
先准备覆盖正常输入、边界输入、信息不足、冲突材料和恶意输入的固定评估集，并记录当前版本基线。不同任务使用不同指标，例如分类准确率、字段完整率、引用一致性、事实错误率、人工修改率、工具选择正确率、延迟和 token 成本。

每次修改尽量只验证一个主要假设。例如“模型漏掉合同自动续约条款”，可以先增加检查范围，而不是同时换模型、重排资料、增加五个示例并调整温度。单变量修改更容易判断收益来自哪里，也更容易发现回归。

对失败样本分桶比平均分更有价值。格式错误优先检查输出契约和 Schema；没有使用正确证据要检查检索、排序和上下文位置；事实缺失可能需要 RAG 或工具；权限、金额和数据隔离必须由代码保证。Prompt 只能提供软约束，不能成为安全边界。

#### 6. 一个可复用但不僵化的模板

```text
你需要完成：[具体任务]
结果将用于：[使用者和业务目的]

输入材料：
<context>
{{相关上下文}}
</context>

执行规则：
1. [决策规则或检查范围]
2. [允许使用的证据]
3. [禁止推断的内容]
4. [信息不足时如何处理]

输出要求：
[章节、字段、格式、长度、引用方式]

验收标准：
- [可观察、可检查的标准 1]
- [可观察、可检查的标准 2]

示例：
[只在规则仍有歧义时加入代表性示例或反例]
```

模板只是检查清单，不是每次都要完整填写。简单任务可以只有目标和输出要求；复杂任务才需要证据边界、示例和异常状态。最终是否高质量，要由评估结果决定，而不是由模板完整度决定。

### 代码示例
下面的 TypeScript 示例把 Prompt 结构定义成数据，而不是在业务代码中不断拼接零散字符串。这样更容易进行版本管理、评审和自动化测试。

```ts
type PromptSpec = {
  goal: string;
  audience: string;
  rules: string[];
  outputContract: string;
  acceptanceCriteria: string[];
};

type PromptInput = {
  knowledge: string;
  conversation: string;
};

export function buildQaPrompt(
  spec: PromptSpec,
  input: PromptInput,
): string {
  const numbered = (items: string[]) =>
    items.map((item, index) => `${index + 1}. ${item}`).join("\n");

  return [
    `<task>${spec.goal}</task>`,
    `<audience>${spec.audience}</audience>`,
    `<rules>\n${numbered(spec.rules)}\n</rules>`,
    `<output_contract>${spec.outputContract}</output_contract>`,
    `<acceptance_criteria>\n${numbered(spec.acceptanceCriteria)}\n</acceptance_criteria>`,
    `<knowledge>\n${input.knowledge}\n</knowledge>`,
    `<conversation>\n${input.conversation}\n</conversation>`,
  ].join("\n\n");
}
```

### 代码讲解
`PromptSpec` 保存相对稳定、需要评审和版本化的任务契约，`PromptInput` 保存每次请求变化的业务数据。二者分开后，可以单独测试规则是否完整、动态输入是否被放入正确边界，也可以在不改业务代码的情况下对 Prompt 版本做 A/B 评估。

`numbered` 让规则和验收标准拥有稳定顺序，标签用于区分任务、规则和不可信输入。标签本身不是安全措施：如果 `conversation` 中包含恶意指令，应用仍要把它当作数据处理，并通过权限、工具白名单、参数校验和人工审批限制真实影响。

生产中还应记录 Prompt 版本、模型版本、生成参数和评估结果。若输出由程序消费，`outputContract` 不应只写一段自然语言，还要连接实际的 Schema 和运行时校验。

### 面试回答
高质量 Prompt 不是写得越长越好，也不是套一个万能模板。它本质上是一份可执行、可验证的任务契约，目标是减少模型对任务的无效猜测，并让输出能被人或程序检查。

我通常从六个部分设计：先明确任务目标和使用者，再提供完成任务所需的上下文；然后写清决策边界和信息不足时的处理方式；接着定义输出结构；对难以用规则描述的边界加入少量正反例；最后给出可观察的验收标准。角色设定主要用于限定视角、受众和语气，不能代替领域知识。

例如“帮我分析客服对话”太模糊，我会补充质检范围、可用知识库、证据要求、无法判断的状态，以及每个问题需要输出的字段。这样模型知道检查什么、依据什么、何时不能猜，结果也更容易校验。

Prompt 写完后还不算完成。我会建立固定评估集，把失败分成任务理解、证据使用、格式、事实和安全等类别，每次只针对一个主要失败原因做最小修改，再比较任务成功率、引用一致性、格式通过率、延迟和成本。没有评估的 Prompt 优化很容易只是对少数样本过拟合。

最后要说明边界：缺少最新或私有知识时用 RAG，精确计算和实时动作交给工具，机器格式使用 Schema 和程序校验，权限及业务规则由代码保证。高质量 Prompt 能提高稳定性，但不能把概率模型变成确定性安全边界。

### 面试官追问
1. “你是一位顶级专家”这样的角色设定到底有没有用？
2. 为什么 XML 标签或分隔符不能解决 Prompt Injection？
3. Few-shot 示例应该怎样选择？正例和反例分别有什么价值？
4. System Prompt、用户输入、RAG 资料和工具结果应该怎样分层？
5. 怎样判断一个 Prompt 是信息不足，还是已经写得太长？
6. 如何为摘要、分类和 Agent 工具调用分别设计验收指标？
7. 修改 Prompt 后平均分提高，但关键场景退化了，应该怎样处理？
8. 哪些约束必须放进代码，不能只写在 Prompt 里？

### 高分回答要点
- 把 Prompt 定义为可执行、可验证的任务契约，而不是神奇话术
- 能围绕目标、上下文、边界、输出、示例和验收标准给出完整方法
- 说明角色、标签、few-shot 和输出格式各自解决的问题及边界
- 能用具体的弱 Prompt 与改进 Prompt 展示如何减少模型猜测
- 提出固定评估集、失败分桶、单变量修改、版本管理和回归验证
- 能把知识、执行、硬约束和安全问题正确分配给 RAG、工具、Schema 与代码

### 常见扣分回答
- 只背“角色、任务、背景、格式”模板，不能解释每部分解决什么问题
- 认为多写“请认真思考”“必须严格遵守”就能稳定提升效果
- 把 Prompt 写得越长越复杂，忽略无关信息、规则冲突和 token 成本
- 用一个漂亮示例证明效果，没有固定评估集和边界样本
- 认为分隔符可以完全防止提示词注入，或把 Prompt 当作权限控制
- 所有失败都继续调 Prompt，不知道何时使用 RAG、工具、Schema 或代码

### 项目结合话术
在项目中会先把 Prompt 拆成稳定契约和动态上下文：稳定部分包含任务、规则、输出 Schema 和验收标准，动态部分只注入当前请求真正需要的历史、检索证据和工具结果。Prompt、模型和参数都有版本号，每次修改针对明确失败桶，在固定评估集上比较效果、格式通过率、延迟和 token 成本。权限、事实 ID、金额与跨字段规则继续由应用校验，避免把 Prompt 当成系统的最后一道防线。

### 参考来源
- [OpenAI Prompt engineering 官方指南](https://developers.openai.com/api/docs/guides/prompt-engineering)
- [OpenAI Evaluation best practices](https://platform.openai.com/docs/guides/evaluation-best-practices)
- [Anthropic Prompt engineering overview](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
- [Google Gemini Prompt design strategies](https://ai.google.dev/gemini-api/docs/prompting-strategies)

### AI体系面试题
![dc9809429497249bbf1c26b16612ec5c.png](https://developer.qcloudimg.com/http-save/yehe-8338883/ebfbd16fb63e1248db002870901a5a7c.png)

能否把高质量 Prompt 理解为可执行、可验证的任务契约，而不是固定话术或关键词集合

2026AI面试题-怎么写一个高质量的 Prompt？

人工智能

前端

高质量Prompt是可执行、可验证的任务契约，核心在于明确目标、输入、边界、输出及验收标准。通过固定评估集与失败分桶迭代优化，区分软硬约束，将权限与事实校验交由代码与工具，而非依赖话术堆砌或标签隔离。

提示词注入

数据处理

代码解释

TypeScript 

Agent

SaaS

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2026AI面试题-怎么写一个高质量的 Prompt？-腾讯云开发者社区-腾讯云

2026AI面试题-怎么写一个高质量的 Prompt？

2026AI面试题-怎么写一个高质量的 Prompt？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐