提示工程基础

用任务合同、消息角色、示例与评测组织提示，并通过固定数据集比较改写是否真正改善结果。

学习目标

能解释“提示工程基础”如何把提示当成可版本化、可评测的任务接口
能区分系统指令、任务合同、few-shot、提示模板、提示评测，并指出它们在请求、状态或执行边界中的位置
能固定输入，沿以下证据定位首个分叉：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本
能注入“根据一个成功样例反复改词，却没有冻结评测集和失败定义”，在同一预算和权限下完成故障、恢复与重放

来源、课程编排与适用边界

“提示工程基础”以Anthropic 公开全文《Building effective agents》为总纲，并用Anthropic《Effective context engineering for AI agents》核对本单元机制；工具与外部能力的角色再由MCP 官方规范交叉检查。

这不是一本具有“官方九章目录”的纸质书。平台把公开文章中的 augmented LLM、工作流、智能体、上下文和工具工程重组为 9 个教学单元；下列 72 个节点是站内课程地图，不冒充 Anthropic 原文目录。正文、代码、图表和练习均为独立教学重写，产品或模型版本变化时应重新验证。

本单元的八个课程坐标

提示工程基础：作为“把提示当成可版本化、可评测的任务接口”的第 1 个课程坐标，必须进入正文解释、交互观察或练习证据。
系统指令：作为“把提示当成可版本化、可评测的任务接口”的第 2 个课程坐标，必须进入正文解释、交互观察或练习证据。
用户输入：作为“把提示当成可版本化、可评测的任务接口”的第 3 个课程坐标，必须进入正文解释、交互观察或练习证据。
任务合同：作为“把提示当成可版本化、可评测的任务接口”的第 4 个课程坐标，必须进入正文解释、交互观察或练习证据。
上下文：作为“把提示当成可版本化、可评测的任务接口”的第 5 个课程坐标，必须进入正文解释、交互观察或练习证据。
示例：作为“把提示当成可版本化、可评测的任务接口”的第 6 个课程坐标，必须进入正文解释、交互观察或练习证据。
输出约束：作为“把提示当成可版本化、可评测的任务接口”的第 7 个课程坐标，必须进入正文解释、交互观察或练习证据。
提示评测：作为“把提示当成可版本化、可评测的任务接口”的第 8 个课程坐标，必须进入正文解释、交互观察或练习证据。

术语与状态合同

、、、、。

本页不变量是：提示版本、输入数据、模型配置与评分规则共同冻结后，改写效果才可比较。任何“成功”结论都要保存以下证据：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本，不能把模型口头确认当作环境事实。

关键机制与可推翻实验

角色分层避免指令与数据混淆

稳定策略放系统消息，具体任务放用户消息，工具结果作为结构化观察加入历史。把不可信数据拼进高优先级指令会扩大注入风险。

动手试：在用户文档中加入伪系统指令，验证它只被当作数据处理。

任务合同必须可判定

目标、输入边界、成功标准、允许动作和失败返回应能被测试。模糊要求可以产生顺畅文字，却无法决定任务是否完成。

动手试：把“写得更好”改成带长度、受众、事实源和验收样例的合同。

示例展示决策边界

few-shot 示例不只是格式模板，还应覆盖正常、边界和拒绝样本。示例与指令冲突时会造成不稳定，必须作为同一版本一起评测。

动手试：增加一个相邻边界反例，比较分类混淆矩阵而不是挑选单个漂亮输出。

提示优化依赖评测集

提示版本只能在冻结任务集、模型配置和评分规则下比较。凭一次对话调词容易过拟合样例，并把随机波动误认成提升。

动手试：对两个提示版本重复运行同一评测集，报告成功率、方差、成本和失败簇。

先预测，再操作三类证据

分步1 / 3

1. 模型与结构边界

在“提示工程基础”中先画出责任、数据或候选空间，再预测“把提示当成可版本化、可评测的任务接口”会在哪个节点改变结果。

一条好提示由四个区组成：角色（system 岗位说明书）定身份与规矩、指令说清要做什么、 few-shot 示例教它照样子做、输入（user）给本次待处理内容——缺一块都容易让模型跑偏。

最小可运行实现

def build_messages(policy, task, examples):
    return [
        {"role": "system", "content": policy},
        *examples,
        {"role": "user", "content": task},
    ]
 
def evaluate(prompt_version, cases, grader):
    return [grader(case, call_model(prompt_version, case)) for case in cases]

这段实现只负责暴露“把提示当成可版本化、可评测的任务接口”的最小合同。交付版本还要补齐超时、日志、权限、密钥隔离和可重复评测；缺少以下证据时，代码能运行也不代表本章结论成立：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。

练习与答案

练习

问题 1：系统边界。 怎样用最小输入证明“提示版本、输入数据、模型配置与评分规则共同冻结后，改写效果才可比较”？

问题 2：课程坐标。 提示工程基础、系统指令、用户输入、任务合同、上下文、示例、输出约束、提示评测如何进入可操作验证？

问题 3：故障恢复。 怎样证明“根据一个成功样例反复改词，却没有冻结评测集和失败定义”已经修复？

本章回顾

“提示工程基础”的主问题是把提示当成可版本化、可评测的任务接口。
核心不变量是提示版本、输入数据、模型配置与评分规则共同冻结后，改写效果才可比较。
首要反例是根据一个成功样例反复改词，却没有冻结评测集和失败定义。
最小证据包包含提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。

名词解释

本章出现的专业名词，用大白话再讲一遍。

系统指令: 描述稳定角色、策略和边界的高优先级消息。在“提示工程基础”中必须能按以下证据重新定位：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。
任务合同: 可判定的目标、输入、成功标准和失败返回。在“提示工程基础”中必须能按以下证据重新定位：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。
few-shot: 在上下文中提供少量输入输出示例的方法。在“提示工程基础”中必须能按以下证据重新定位：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。
提示模板: 把稳定结构与受控变量分离的构造方式。在“提示工程基础”中必须能按以下证据重新定位：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。
提示评测: 在冻结任务集和评分规则上比较提示版本。在“提示工程基础”中必须能按以下证据重新定位：提示版本、消息角色、任务集 hash、模型参数、逐项评分、失败样本、成本与回滚版本。

阅读导航

← 智能体解剖图 · 采样与解码 →