大模型应用开发

Prompt · 基础四要素

为什么 Prompt 是「核心抓手」

普通人不需要训练模型就能操控大模型完成复杂任务的唯一手段，就是写好 Prompt。

Prompt 的质量直接决定大模型输出的：

• 准确性：是否答中要害、没幻觉
• 可用性：输出能否被下游程序直接消费（JSON / 表格 / Markdown）
• 专业性：行业 jargon 是否到位、术语是否准确
• 稳定性：同一类任务的输出一致性（评测时这个最关键）

四要素：写好 Prompt 的万能公式

经过大量实验和工业实践沉淀，结构化高质量 Prompt 的核心框架就 4 块：

┌─────────────────────────────────────┐
      │  角色 (Role)        + 设定身份与视角     │
      │  目标 (Goal)        + 说清要做什么       │
      │  执行方案 (Plan)    + 拆解步骤与边界     │
      │  输出格式 (Output)  + 规定结构与字段     │
      └─────────────────────────────────────┘

1. 角色 (Role)

给模型设定一个明确身份 —— 本质是激活模型在该身份下的认知模式。

# ❌ 没有角色
      帮我分析一下这段代码
      
      # ✅ 有角色
      你是有 10 年经验的 Python 性能优化专家

模型在「Python 性能优化专家」身份下，会自动关注：内存分配、循环复杂度、I/O 阻塞这类话题，而不会去聊代码风格。

2. 目标 (Goal)

清晰告知最终要达成的结果，避免歧义。

# ❌ 模糊
      帮我看看这段 SQL
      
      # ✅ 明确
      找出这段 SQL 中导致全表扫描的语句，并给出索引优化建议

3. 执行方案 (Plan)

给模型明确的步骤、逻辑、边界，规范完成路径。

请按以下步骤执行：
      1. 先识别出所有 JOIN 语句
      2. 检查每个 JOIN 字段是否有索引
      3. 对缺失索引的字段，给出 CREATE INDEX 语句
      4. 评估每个索引的存储成本（粗略估算）
      
      约束：
      - 只关注 PostgreSQL 14+ 的语法
      - 不考虑分区表（暂不支持）

4. 输出格式 (Output)

指定结构化输出，让结果可直接被下游程序消费。

请输出 Markdown 表格，包含 4 列：
      | 字段名 | 是否缺失索引 | 建议 SQL | 预估存储 (MB) |
      
      如果某字段无需索引，「建议 SQL」填「不需要」。

完整模板示例

下面这条 prompt 把四要素全部用上：

你是 PostgreSQL 14+ 性能优化专家。
      
      任务：分析以下 SQL，找出可能导致全表扫描的写法，并给出索引优化建议。
      
      执行步骤：
      1. 识别所有 WHERE / JOIN / ORDER BY 字段
      2. 判断每个字段的索引情况
      3. 对缺失的，输出 CREATE INDEX 语句
      4. 评估索引对写入性能的影响
      
      约束：
      - 只考虑 PostgreSQL 14+ 语法
      - 不考虑分区表
      - 索引名格式: idx_{table}_{column}
      
      输出格式：Markdown 表格
      | 字段 | 索引缺失 | 建议 SQL | 写入影响 |
      
      待分析 SQL：
      {sql_here}

真实效果对比

同一个任务，模糊 vs 结构化 prompt 的差距：

何时不需要四要素

四要素是复杂任务的标配。简单任务可以省略部分：

下一节学：5 大设计原则 —— 让四要素的每一块都更精准。