跳至主要內容

面试高频：如何设计一个高质量 Prompt？

安逸Ai2026/7/16大约 14 分钟大模型100讲Prompt

面试高频：如何设计一个高质量 Prompt？

一句话核心：Prompt Engineering 是通过设计、测试和优化 AI 模型的输入提示词，在不重新训练模型的情况下获得准确、相关且安全输出的核心技术，是 AI Agent 的灵魂

核心概念（术语表）

  • Prompt（提示词）：引导语言模型产生期望输出的输入文本，解决"同一个模型因提示不同给出截然不同回答"的问题
  • System Prompt（系统提示词）：定义 Agent 身份、行为规范、工具使用指导和安全性约束的核心配置，是 Agent 的"宪法"
  • Skill（技能）：按场景按需加载的专家手册，将 prompt 工程化的手段，降低 token 消耗的同时提升行为质量
  • 零样本提示（Zero-shot）：不提供任何示例，期望模型能够泛化出回答，适用于简单明确的任务
  • 少样本提示（Few-shot）：提供 2-5 个示例帮助模型理解需求，通过模式匹配提高复杂任务准确率
  • 思维链提示（CoT, Chain-of-Thought）：引导模型在给出答案前进行逐步推理，适用于数学、逻辑和多跳问题
  • KV Cache：LLM 推理时缓存 token 的 Key-Value 对，前缀越稳定命中率越高，推理越快
  • 提示注入（Prompt Injection）：用户输入试图操纵或覆盖提示指令的安全攻击方式
  • RAG（检索增强生成）：先检索相关文档再提示模型，适用于时效性强或特定领域问题
阅读全文

历史背景 / 来源

  • 提出时间：2020-2023 年，随着 GPT-3（2020年）展示 Few-shot Learning 能力后逐渐受到关注
  • 核心人物：OpenAI 研究团队、Anthropic 等 LLM 厂商推动了提示工程最佳实践的系统化
  • 解决的问题：如何在不微调模型的情况下，通过优化输入获得更好的输出质量
  • 演进路径：从简单的角色定义 → 分层架构 → Skill 系统 → 动态按需加载

工作原理 / 核心机制

整体思路

高质量 Prompt 的设计遵循"角色 + 任务 + 上下文 + 约束 + 输出格式"的框架，通过结构化的输入引导模型产生期望输出。

输入/输出

  • 输入：用户原始查询 + System Prompt（角色定义、行为规范、工具指导、安全约束）+ 上下文（Skill、项目上下文）+ 历史对话
  • 输出：符合角色设定、满足任务要求、遵循约束条件的模型响应

核心步骤详解

第一步：角色定义（Role Definition）

  • 具体输入："你是 PaiCLI，一个面向代码库工作的智能编程 Agent"
  • 具体处理：明确 Agent 身份、能力边界、擅长领域
  • 具体输出：模型获得清晰定位，后续响应围绕该角色展开

第二步：任务与约束拆解（Task Decomposition）

  • 具体输入：具体任务描述 + 约束条件（如"用中文回复"、"代码和 API 名称保留原文"）
  • 具体处理：LLM 将任务分解为可执行的子步骤
  • 具体输出：结构化的执行计划

第三步：上下文注入（Context Injection）

  • 具体输入：Skill 文件（Markdown 格式）、项目上下文、RAG 检索结果
  • 具体处理：按"不变在前、动态在后"的顺序组装 prompt
  • 具体处理：Skill 延迟加载，只在需要时注入相关技能
  • 具体输出：完整的 system prompt，包含所有必要上下文

第四步：输出格式化（Output Formatting）

  • 具体输入："以 JSON 格式返回结果"、示例输出
  • 具体处理：模型按指定格式生成响应
  • 具体输出：结构化的机器可解析或人类可读的响应

关键知识点

  • PaiCLI 的 System Prompt 包含四个核心模块：角色定义、行为规范、工具使用指导、安全约束
  • Prompt 分层架构将 system prompt 拆分为独立 Markdown 文件：base.md、personalities/、modes/、approvals/、context/
  • KV Cache 复用机制：前缀越稳定，cache 命中率越高，推理越快、成本越低
  • "不变在前、动态在后"原则：base.md 最稳定 → 语调风格 → 模式指令 → 审批策略 → 项目上下文 → Skill → 本轮对话
  • 三层覆盖机制（优先级从低到高）：jar 内置 < 用户级 ~/.paicli/prompts/ < 项目级 .paicli/prompts/
  • Skill 延迟加载：避免将所有 Skill 塞进 system prompt，节省 token 消耗
  • Skill 缓冲区容量控制：防止过度加载导致 prompt 膨胀
  • 安全性考虑：路径不能以 / 开头、不能包含 ..，防止路径穿越攻击
  • 零样本提示：不提供示例，适用于简单明确任务
  • 少样本提示：2-5 个示例，提高复杂任务准确率 30% 以上
  • 思维链（CoT）：引导模型逐步推理，适用于数学、逻辑、多跳问题
  • 温度（Temperature）：接近 0 更确定、更符合事实；创意任务可用更高值
  • top_p：调整考虑的概率质量大小，影响输出的多样性
  • 提示注入防御：输入清理、严格分隔符、将用户查询与系统提示分开
  • Skill vs RAG：Skill 是"做事的方法"，RAG 是"获取知识的途径"
  • 提示验证方法：BLEU/ROUGE 指标、用户反馈、边缘案例测试

应用场景

  • 场景 1：代码智能助手（PaiCLI） 用分层 Prompt 架构解决了"改一句话要重新编译"的问题，通过 Markdown 文件分离配置，支持动态组装，工具调用准确率提升
  • 场景 2：聊天机器人产品化 某项目通过重新设计提示（加入角色设定、任务上下文、输出约束），将输出相关性提高，回退响应减少 40%
  • 场景 3：数据提取任务 使用项目符号指令和字段示例替代模糊提示，准确率提高 30% 以上
  • 场景 4：多语言/跨文化场景 通过翻译提示、文化相关例子、当地习语，调整语气和正式程度适应不同市场
  • 场景 5：企业级 Agent 平台 通过 Skill 三层覆盖机制，支持 jar 内置 → 用户级 → 项目级的灵活定制，平衡标准化与个性化

常见误区 / 踩坑

  • ❌ 误区 1：认为 prompt 越详细越好
    ✅ 正解：需要平衡详细程度与 token 消耗，过长的 prompt 会增加推理成本且可能稀释核心指令

  • ❌ 误区 2：把所有 Skill 都塞进 system prompt
    ✅ 正解：Skill 应该延迟加载、按需注入，节省 token 的同时提升行为质量

  • ❌ 误区 3：提示词顺序无所谓
    ✅ 正解：LLM 对位置敏感，重要信息应放在 prompt 开头或结尾（首因效应/近因效应）

  • ❌ 误区 4：提示注入不重要
    ✅ 正解：提示注入是严重安全风险，必须对输入进行清理，使用严格分隔符

  • ❌ 误区 5：一次性设计完美的 prompt
    ✅ 正解：提示工程需要迭代优化，BLEU/ROUGE 指标 + 用户反馈 + 边缘测试缺一不可

  • ❌ 误区 6：忽视模型参数（temperature、top_p）
    ✅ 正解：提示词 + 参数共同决定输出质量，事实性任务用低温度，创意任务可用高值

性能 / 复杂度

  • KV Cache 命中率：稳定前缀越长，cache 命中率越高，推理速度提升可达 30-50%
  • Token 消耗优化：Skill 延迟加载可节省 20-40% 的 token 消耗
  • Skill 加载时机：首次触发时加载，缓冲区块级管理，避免频繁 IO

与替代方案对比

  • 方案 A：硬编码 System Prompt

    • 缺点：改一句话要重新编译，无法动态调整，token 固定浪费
    • 适用：小型项目、prompt 稳定不变的场景

  • 方案 B：纯 RAG 检索

    • 缺点：每次都要检索，知识获取但不会"做事"
    • 适用：知识问答类场景

  • 方案 C：分层 Prompt + Skill 系统（本方案）

    • 优势：标准化 + 个性化兼顾，动态按需加载，token 优化
    • 适用：企业级 Agent、需要灵活定制的场景

与相关概念的区别

  • vs 微调（Fine-tuning）：

    • 维度 1（成本）：微调需要 GPU 资源和大量数据，Prompt 不需要
    • 维度 2（灵活性）：Prompt 可实时调整，微调需要重新训练
    • 维度 3（适用）：微调适合改变模型底层能力，Prompt 适合引导现有能力
    • 怎么选：大多数场景先用 Prompt 优化，确实需要再考虑微调

  • vs RAG（检索增强生成）：

    • 维度 1（目的**：RAG 是"获取知识"，Skill 是"学会做事的方法"
    • 维度 2（内容**：RAG 检索文档片段，Skill 包含 SOP 和最佳实践
    • 维度 3（时机**：RAG 实时检索，Skill 预加载或延迟加载
    • 怎么选：知识问答用 RAG，流程任务用 Skill，二者可结合

  • vs Tool（工具）：

    • 维度 1（定义**：Tool 是具体的功能函数（如 read_file），Skill 是使用工具的方法论
    • 维度 2（粒度**：Tool 粒度细，Skill 粒度粗
    • 维度 3（关系**：Skill 指导何时用、怎么用 Tool
    • 怎么选：Tool 是执行层，Skill 是决策层

进阶 / 面试加分项

  • 最新进展：自动提示优化工具（如 DSPy）可根据任务自动生成/优化提示，减少人工试错
  • 业界趋势：提示工程正在与 UI 设计、模型微调、AI 安全操作深度融合
  • 未解问题：如何量化评估提示的"好与坏"，不同模型对同一提示表现差异大
  • 面试加分句："提示工程不是魔法，而是工程学——需要结构化的设计、科学的验证、持续的迭代"
  • 面试加分句："Prompt 是 AI 时代的 API 设计，好的 Prompt 如同好的函数签名：清晰、简洁、有据可查"

面试如何回答

🟢 什么是提示工程？为什么它很重要？

回答要点：

提示工程是设计输入的过程，这些输入可以引导语言模型产生期望的输出。它之所以重要，是因为同一个模型可能会根据提示的不同而给出截然不同的回答——掌握提示工程意味着你可以在不重新训练或微调模型的情况下，获得更准确、更相关且更安全的输出结果。在实际应用中，通过优化提示词，某聊天机器人项目将输出相关性提高了，同时将回退响应减少了 40%。提示工程不是魔法，而是工程学——需要结构化的设计、科学的验证、持续的迭代。

🟢 零样本、单样本和少样本提示有什么区别？各自适用什么场景？

回答要点：

零样本提示不提供任何示例，期望模型能够直接泛化出回答，适用于简单明确的任务（如"把这段文字翻译成英文"）。单样本方法为模型提供一个示例作为参考，帮助模型理解任务格式。少样本则包括 2-5 个示例，通过为模型提供模式来提高性能，尤其适用于复杂任务。在一个数据提取任务中，使用项目符号指令和字段示例替代模糊提示后，准确率提高了 30% 以上。少样本的核心价值在于"示范格式"，而不是"提供知识"，所以示例要有代表性、覆盖典型和边缘情况。

🟡 Agent 的 System Prompt 一般包含哪些内容？如何设计一个好的 System Prompt？

回答要点：

一个高质量的 System Prompt 通常包含四个核心模块：

  1. 角色定义：告诉 LLM "你是谁"，如"你是 PaiCLI，一个面向代码库工作的智能编程 Agent"
  2. 行为规范：负责输出格式、语调等，如明确要求"请用中文回复用户，代码和 API 名称保留原文"
  3. 工具使用指导：不能只写"合理使用工具"，要具体到场景——读文件用 read_file，不要用 execute_command cat
  4. 安全约束：明确哪些操作不能做、哪些需要用户确认
    设计原则是"清晰具体、有边界、可验证"。好的 System Prompt 应该像一份工作手册，既告诉 Agent 能做什么，也明确不能做什么。

🟡 为什么提示词的组装顺序要遵循"不变的在前、动态的在后"原则？

回答要点：

这个原则背后的原理是 LLM 推理时的 KV Cache 复用机制。LLM 推理时，每个 token 会计算出一对 Key-Value（KV），缓存起来。如果连续两次请求的 prompt 前缀完全相同，服务端可以复用上次的 KV Cache，跳过重复计算。PaiCLI 的组装顺序是：先拼核心规则（base.md），再拼语调风格，然后是当前模式的指令，接着是审批策略、项目上下文、Skill，最后是本轮对话的交接信息。这样排列后，越靠前的稳定内容越容易持续命中 cache，动态变化的内容集中在后段，服务端只需重点处理新增或变化的上下文。反过来，如果把 Skill、项目上下文这类动态内容放到前面，即使 base.md 没有变化，也可能破坏前缀一致性，导致缓存收益下降，推理延迟和 token 成本都会受到影响。

🟡 什么是 Skill？它和 Tool、Agent 有什么关系？

回答要点：

Skill 是把 prompt 工程化的手段——从"一坨几千字的 system prompt"变成"按场景按需加载的专家手册"。Skill 和 Tool 的区别在于：Tool 是具体的功能函数（如 read_file、execute_command），是执行层的原子操作；Skill 是使用工具的方法论，告诉 Agent 什么时候该用什么工具、碰到异常怎么处理，是决策层的指导。Skill 和 RAG 的区别在于：RAG 是"获取知识的途径"，检索文档片段回答问题；Skill 是"学会做事的方法"，包含 SOP 和最佳实践。以 PaiCLI 的 web-access Skill 为例，它会告诉 Agent 如何正确地访问网页、提取信息、处理异常，而不是简单地塞一堆网页内容。

🟡 Prompt 改了怎么验证效果？有哪些系统化的评估方法？

回答要点：

提示验证需要系统化的方法，主要包括三个维度：

  1. 自动化指标：使用 BLEU 或 ROUGE 等指标评估输出质量，BLEU 衡量 n-gram 重叠度，ROUGE 衡量召回率
  2. 功能性测试：检查提示是否能在一次尝试中完成任务，回退响应率是核心指标（某项目通过优化提示将回退响应减少 40%）
  3. 边缘案例测试：在边界条件下验证可靠性，如空输入、超长输入、特殊字符等
  4. 用户反馈：收集真实用户的满意度评分
    验证流程应该是：先跑自动化指标快速筛选，再用功能测试验证正确性，最后上灰度收集用户反馈。提示工程是迭代过程，不存在一次设计完美的 Prompt，需要小步快跑、持续优化。

🔴 如何防止提示注入攻击？有哪些安全措施？

回答要点：

提示注入（Prompt Injection）是指用户输入试图操纵或覆盖提示指令的攻击方式。防范措施包括：

  1. 输入清理：对用户输入进行过滤，去除可疑的指令性内容
  2. 严格分隔符：使用明确的分隔符（如 ---INPUT---）将用户查询与系统提示分开
  3. 结构化设计：不要让用户输入直接拼接到 system prompt 的关键位置
  4. 路径校验：对于文件级覆盖（如 PaiCLI 的三层覆盖），必须校验路径不能以 / 开头、不能包含 ..，防止路径穿越攻击
    以 PaiCLI 为例，它在路径加载时做了两层校验：一是文件路径不能以 / 开头、不能包含 ..，防止路径穿越；二是解析后的路径必须落在对应根目录之内，超出范围的直接拒绝。这些措施看似繁琐，但在企业级应用中至关重要。

🔴 如何设计一个企业级的 Skill 体系？多个 Skill 之间冲突怎么办？

回答要点：

设计企业级 Skill 体系需要考虑以下几点：

  1. 分层结构：Skill 应该像代码一样组织，支持三层覆盖（jar 内置 → 用户级 → 项目级），优先级从低到高，粒度是整文件替换
  2. 延迟加载：不要把所有 Skill 塞进 system prompt，只在需要时加载，节省 token 消耗
  3. 容量控制：Skill 缓冲区需要容量控制，防止过度加载导致 prompt 膨胀
  4. 冲突处理：多个 Skill 之间可能出现指令冲突，解决方式包括：
    • 明确优先级（如 HITL 审批 Skill > 自动放行 Skill）
    • Skill 内部定义适用场景和互斥条件
    • 设计 Skill 的"元数据"（何时激活、何时失效）
  5. 效果衡量：跟踪 Skill 使用率、任务成功率、用户满意度等指标，持续迭代优化。好的 Skill 体系应该像乐高积木——标准化、可组合、可替换。