跳到主要内容

提示词工程 (Prompt Engineering)

提示词工程是一门通过精心设计输入（提示词）来引导大语言模型（LLM）产生预期输出的艺术与科学。这门学科融合了对 LLM 行为的深度理解、语言的精确表达以及持续的迭代优化。

核心原则​

1. 具体且明确 (Be Specific)​

模糊的提示词只会得到模糊的答案。请精确描述你的需求。

❌ 错误示范：

“写点关于 AI 的东西。”

✅ 正确示范：

“请写一段关于大语言模型（LLM）的技术简介。要求：包含架构简述、训练流程及常见用例；篇幅为 3 个段落；目标读者为软件工程师。”

2. 提供充分的背景信息 (Context)​

为模型提供相关的背景，使其能做出更贴合场景的决策。

背景：你是一位资深的 Java 架构师，正在评审一个处理支付交易的 Spring Boot 应用。该应用集成了 Spring AI 进行欺诈检测，需支撑每秒 1 万次的并发交易。

任务：请评审以下控制层代码，识别潜在的性能瓶颈...

3. 使用示例 (Few-Shot Learning)​

通过展示“输入-输出”对，让模型快速掌握你期望的模式。

将以下技术术语从正式转换为非正式：

输入：异步编程 -> 输出：异步代码 输入：微服务架构 -> 输出：微服务 输入：服务器端渲染 -> 输出：SSR

4. 规定输出格式 (Output Format)​

明确告诉模型响应应如何组织（如 JSON、Markdown 表格或特定标题）。

请分析以下代码并按此格式输出：

安全隐患​

  • [漏洞列表]

性能建议​

  • [调优建议]

5. 设定硬性约束 (Constraints)​

为响应划定明确的边界。

请编写一个验证邮箱地址的 Python 函数。 约束：代码行数不超过 50 行；仅使用标准库；包含类型注解；提供 3 个测试案例。

常用提示词框架​

CO-STAR 框架​

  1. Context (上下文) - 设定背景。
  2. Objective (目标) - 明确任务。
  3. Style (风格) - 规定语气。
  4. Tone (基调) - 设定情感色彩。
  5. Audience (受众) - 针对谁写。
  6. Response (响应) - 规定格式。

RTF 框架​

  1. Role (角色) - 模型是谁（如：高级 DevOps 工程师）。
  2. Task (任务) - 要做什么（如：设计 K8s 部署方案）。
  3. Format (格式) - 怎么呈现（如：架构图描述 + 检查清单）。

进阶技术​

  • 思路链 (Chain-of-Thought)：通过“让我们一步步思考”引导模型进行逻辑推演，显著提升复杂数学和逻辑问题的准确率。
  • 自洽性 (Self-Consistency)：让模型生成多个答案并进行内部对比或投票，以排除随机错误。
  • 角色扮演 (Role Prompting)：赋予模型特定的职业身份（如“资深 Linux 内核开发者”），激发其专业领域的深度知识。

生产环境最佳实践​

开发阶段​

  1. 版本化管理：像管理代码一样管理提示词，追踪变更与效果。
  2. 系统化测试：在多样化的输入集上验证提示词的鲁棒性。
  3. 量化评估：跟踪准确率、延迟和 Token 成本。

生产阶段​

  1. 输入校验：在提示词模板填充前进行安全性检查（防止注入攻击）。
  2. 输出监控：实时监控响应质量，捕获异常输出。
  3. A/B 测试：持续对比不同提示词方案的业务转化率。

总结​

提示词工程的核心在于消除歧义。

  1. 结构化 优于 碎片化。
  2. 引导性 优于 命令性。
  3. 工程化 优于 随机性。

下一章：2.1 提示词剖析 → stone