提示词工程是什么

提示词工程（Prompt Engineering）本质是：

通过设计输入结构（指令、上下文、示例、输出约束），提高模型输出质量、稳定性和可用性。

早期它主要是“单次调用优化”问题：

同一个问题怎么让模型更少跑偏
怎么让模型按格式输出，方便程序接入
怎么让模型在有限上下文中优先关注关键信息

一句话理解：

Prompt 工程 = 把自然语言需求，转成模型可稳定执行的输入规范

早期提示词工程要解决什么问题

在早期大模型使用阶段，主要痛点很直接：

输出不稳定

相同问题，不同轮次质量波动明显

指令跟随不一致

会漏条件、漏步骤，或者偏离任务边界

输出格式不可控

难以稳定产出 JSON、表格、结构化字段

幻觉与编造

在信息缺口场景下容易“补全事实”

工程接入成本高

无法可靠进入自动化工作流（解析、入库、调用）

提示词工程的实际价值，就是把这些“随机对话行为”转成“可重复调用行为”。

提示词工程的典型方法

1. 指令清晰化

把任务拆为明确动作，避免抽象要求。

你是后端代码审查助手。
目标：找出并发安全问题。
范围：仅检查 src/service/*.java。
输出：按 风险级别/文件路径/修复建议 三列输出 Markdown 表格。

2. 结构化约束

给固定输出 Schema，减少“好看但不可用”的回答。

{
  "risk_level": "high|medium|low",
  "file": "string",
  "issue": "string",
  "fix": "string"
}

3. Few-shot 示例

给 1-3 个高质量样例，提升风格一致性与任务理解。

4. 角色与边界

明确“能做什么”和“不能做什么”，特别是禁止臆测。

如果证据不足，返回“信息不足”，不要编造。

5. 迭代调优

把 prompt 当代码维护：版本化、回归测试、逐步收敛。

实际开发中怎么用（可执行流程）

第 0 步：先定义任务接口

先写清楚：

输入是什么
输出给谁消费（人/程序）
合格输出标准

这一步本质是“为 Prompt 定 API 契约”。

第 1 步：用模板化 Prompt

建议固定模板：

角色
目标
输入数据
约束
输出格式
失败处理规则

示例：

[角色]
你是资深前端 reviewer。

[目标]
检查以下 PR diff 是否存在可访问性问题。

[输入]
{{DIFF_CONTENT}}

[约束]
- 只依据提供的 diff 判断
- 不猜测未给出的代码

[输出格式]
JSON 数组：[{"severity":"","file":"","issue":"","fix":""}]

[失败处理]
证据不足时返回空数组并给出 reason 字段。

第 2 步：给 Prompt 加自动评测

不要只靠主观阅读结果。至少做两类检查：

格式检查：JSON 是否可解析、字段是否齐全
质量检查：是否命中关键规则（比如必须包含 file 和 fix）

第 3 步：把失败样本回灌到 Prompt

将典型失败样本沉淀为：

新约束
新示例
新反例

这一步是提示词工程最核心的“可学习回路”。

第 4 步：按场景拆分 Prompt

不要期望一个超级 Prompt 覆盖所有场景。按任务分开：

信息抽取 Prompt
代码审查 Prompt
规划 Prompt
生成 Prompt

拆分后更稳定，也更易测。

单独做提示词工程的不足

提示词工程很有效，但它有天然边界，尤其在 Agent/长任务开发里：

记忆能力不足

Prompt 优化的是“这一次怎么说”，不是“多轮历史怎么管理”

长上下文退化

历史越来越长时，仅靠 prompt 约束无法解决 token 与注意力稀释问题

状态不可持续

会话中断后，单条 Prompt 很难完整恢复任务现场

缺少执行闭环

Prompt 可以要求“请测试”，但不等于真的执行测试、采集日志、回写状态

缺少系统级治理

无法单独解决工具编排、失败恢复、可观测性、质量门禁

为什么会演化出上下文工程

当任务从“问答”变成“连续开发”后，主要矛盾变成：

需要保留哪些历史
何时压缩历史
旧信息如何检索回填
新窗口如何无损交接

这就是上下文工程（Context Engineering）要处理的问题：

Prompt 工程关注：怎么表达任务
Context 工程关注：怎么管理任务历史和状态

为什么还要演化到 Harness 工程

即使有了 Prompt + Context，仍有一个更大的问题：

如何让 Agent 在真实工程里稳定交付结果。

这要求引入系统级能力：

工具链编排（lint/test/build/deploy）
质量门禁与自动验证
失败恢复与重试策略
任务调度与状态追踪
规则沉淀与可观测性

这就是 Harness 工程的范围：

Harness 工程 = 把 Prompt、Context、Tools、Checks、Workflow 组装成可持续交付系统

三者关系总结

维度	提示词工程	上下文工程	Harness 工程
核心问题	如何让单次输出更好	如何管理多轮记忆与状态	如何让整套开发流程稳定交付
主要对象	单次输入文本	历史消息、摘要、检索、状态	工具链、规则、验证、编排
典型产物	Prompt 模板	状态快照、压缩摘要、记忆层	Agent 工作流、检查回路、运行策略
失效点	长任务漂移	缺少执行与治理	实施成本更高但最稳

我的实践结论

提示词工程不是过时，而是基础层能力。

实际开发里更合理的顺序是：

先把 Prompt 工程做好（稳定输入输出）
再上 Context 工程（解决长任务记忆）
最后用 Harness 工程做系统闭环（稳定交付）

如果直接跳到 Harness，但基础 Prompt 质量不稳定，系统复杂度会快速上升且难排查；反过来只做 Prompt，又无法支撑长流程开发。

参考文章

OpenAI: Prompt Engineering Guide
OpenAI: Best practices for prompt engineering
Anthropic: Prompt engineering overview
Anthropic: Use XML tags to structure prompts

Agent_提示词工程