【学习笔记】Prompt Engineering 没死，只是它不再够用了-2/16

过去很多人把提示词讲成魔法。通过几句固定模板，几个角色扮演，几个"请一步步思考"。

然后包装成一门秘术。现在模型能力变强，很多老技巧看起来不那么神奇了。

于是另一种声音又来了：

复制代码

提示词没用了。
直接上 Agent。
直接上工具。
直接上框架。

这同样是误判。Prompt Engineering 没死。它只是从"玄学技巧"，变成了 AI 工程系统里的第一层契约。如果这层契约写不清楚，后面的 Context、Tools、Harness、Loop 都会被污染。

一、Prompt 解决什么

Prompt Engineering 解决的是：

复制代码

一次模型调用里，怎样让模型稳定理解任务、约束、格式和成功标准。

这句话里有几个关键词。

第一，单次调用。

Prompt 最擅长的是一次输入到一次输出。

第二，稳定理解。

Prompt 不是为了让模型"灵感更强"。

而是让模型少猜。

第三，成功标准。

很多提示词失败，不是因为写得短。

而是因为没有告诉模型什么算对。

比如你让模型：

复制代码

帮我分析这段用户反馈。

这句话没有定义：

复制代码

分析什么？
输出给谁看？
是否要分类？
是否要引用原文？
是否要判断情绪？
是否要给行动建议？
格式是什么？
不确定时怎么办？

模型只能补全。

补全不是错误，补全是模型的本能。

Prompt Engineering 的目标，就是减少不必要的补全空间。

二、一个高质量 Prompt 的结构

OpenAI 和 Anthropic 的提示工程方法细节不完全一样。

但落到工程上，我会把一个高质量 prompt 拆成七块。

复制代码

Role
Task
Context
Constraints
Examples
Output Format
Evaluation Criteria

不一定每次都七块齐全，但你要知道每一块解决什么问题。

2.1 Role。

Role 不是让模型 cosplay。它的作用是限定专业视角。

复制代码

你是一个资深财务审核员。
你是一个安全代码审查员。
你是一个面向初级开发者的技术编辑。

好的 role 会影响关注点。差的 role 只是装饰。

比如：

复制代码

你是世界顶级专家。

这类话通常信息密度很低。

2.2 Task。

Task 要写清楚动作。

复制代码

从用户反馈中提取主要问题，并按严重程度排序。

比：

复制代码

分析一下。

稳定得多。

2.3 Context。

Context 是当前任务需要知道的背景。不是所有资料。

比如：

复制代码

这是一个 B2B SaaS 工具，目标用户是 20-200 人的销售团队。
我们最关心 onboarding 流失原因，不关心价格反馈。

这比塞一堆产品介绍更有用。

2.4 Constraints。

Constraints 是限制条件。

复制代码

不要编造用户没有提到的问题。
只根据输入文本判断。
如果证据不足，输出 unknown。

很多幻觉不是模型不知道，而是你没有告诉它不准猜。

2.5 Examples。

Few-shot 示例适合任务边界微妙的场景。

尤其是：

复制代码

分类标准不直观
语气风格有要求
输出格式容易偏
业务规则难以一句话讲清楚

示例不是越多越好。示例越多，上下文越贵，也越可能引入冲突。

2.6 Output Format。

结构化输出能显著降低接入成本。

复制代码

{
  "category": "billing",
  "severity": "high",
  "evidence": ["原文证据"],
  "recommended_action": "建议动作"
}

如果输出要进入程序，就不要只写"请简洁回答"。

给 schema。

2.7 Evaluation Criteria。

这是很多 prompt 缺失的一块。你要告诉模型怎么判断答案好坏。

比如：

复制代码

好答案必须满足：
1. 每个结论都有原文证据。
2. 不输出输入中没有的信息。
3. 严重程度只允许 low / medium / high。
4. 如果没有足够证据，必须输出 unknown。

这不是废话。这是把评审标准前置。

三、OpenAI 和 Anthropic 的侧重点

OpenAI 的 prompt engineering guide 强调清晰指令、参考文本、拆分复杂任务、给模型时间思考、使用外部工具和系统化测试。

Anthropic 的 prompt engineering overview 说得更工程化一点：

并不是所有失败 eval 都适合靠 prompt 修。

有些问题应该换模型。

有些问题应该降成本。

有些问题应该引入检索、工具或评测。

这点非常关键。

Prompt Engineering 不是万能修复层。

如果你的系统失败是因为：

复制代码

模型没有看到关键资料
工具返回了错误数据
业务规则互相冲突
输出没有验证器
用户输入里有提示注入
任务需要多步恢复

继续调 prompt，收益会越来越低。

这时候要升级系统。

四、常见失败模式

Prompt 失败通常不是随机的。

它有固定模式。

4.1 指令冲突。

复制代码

请详细分析。
输出不超过 50 字。
请严格只用 JSON。
最后补充一段建议。

这种 prompt 会让模型在多个目标之间摇摆。

修法不是加一句"严格遵守"。

修法是删掉冲突，明确优先级。

复制代码

优先级：
1. 必须输出合法 JSON。
2. 每个字段不超过 50 字。
3. 无法满足时输出 error 字段。

4.2 格式漂移。

模型第一次输出对了，第二次多了说明，第三次漏了字段。

常见原因：

复制代码

格式要求不够硬
没有 schema
示例和要求不一致
没有程序侧校验

修法：

复制代码

给 JSON schema
给反例
输出后做解析校验
失败时让模型只修格式

4.3 幻觉补全。

模型补出了输入里没有的事实。

常见原因：

复制代码

任务要求过度开放
没有要求引用证据
没有 unknown / null 路径

修法：

复制代码

要求每个结论带 evidence
证据不足时输出 unknown
禁止使用外部常识填补输入缺口

4.4 上下文不足。

模型不是答错。它是没看到该看的信息。

这类问题不能靠 prompt 解决。

你要做 Context Engineering。

比如：

复制代码

检索更多相关片段
补充用户历史
读取业务规则
加载项目约定

4.5 无法自证正确。

模型给了答案，但你不知道能不能信。这类问题也不该只调 prompt。你需要验证器。

比如：

复制代码

schema validation
unit test
fact checking
source citation
LLM judge
human review

五、Chain-of-thought 要谨慎理解

很多旧提示词教程会强调：

复制代码

请一步步思考。

这句话有时有用。

但在工程系统里，要把它拆开看。

你真正需要的往往不是"展示完整思考过程"。

而是：

复制代码

把复杂任务分解
先列计划
检查中间条件
输出可验证理由

对外部用户，尤其是生产系统，不一定要展示模型完整推理。

更稳的做法是输出：

复制代码

结论
依据
不确定项
下一步建议

比如风控、法务、医疗、财务类系统，展示"思考过程"不等于可审计。

可审计依赖的是：

复制代码

输入事实
规则来源
决策路径
工具记录
人工审批

不要把 chain-of-thought 当成合规日志。

六、XML tags 和结构化提示

Anthropic 文档经常建议用 XML tags 组织提示内容。

这在 Claude 上很实用。

例如：

复制代码

<task>
从用户反馈中提取产品问题。
</task>

<context>
产品是 B2B CRM，目标用户是销售经理。
</context>

<input>
用户反馈文本放这里。
</input>

<output_format>
只输出 JSON。
</output_format>

XML tags 的价值不是语法本身。

价值在于边界清楚。

模型更容易区分：

复制代码

哪些是指令
哪些是数据
哪些是例子
哪些是输出格式

这对防 prompt injection 也有帮助。

但注意，只是有帮助。

不是安全边界。

恶意输入仍然可能写在 <input> 里诱导模型。

真正的安全边界要靠工具权限、策略检查和输出验证。

七、Prompt 什么时候不够用

我会用一张升级信号表。

信号	说明	应该升级到
需要查资料	prompt 里没有全部事实	Context Engineering
输入很长且混杂	信息需要筛选、压缩、隔离	Context Engineering
需要调用外部系统	不只是生成文本	Tools / Harness
需要写入或执行动作	有副作用和风险	Permissions / Audit
输出必须可验证	看起来对不够	Eval / Verification
任务要多轮推进	需要状态和恢复	State / Session
任务要长期运行	需要触发器和退出条件	Loop Engineering

这张表比"prompt 还行不行"更有意义。

Prompt 不是死了，它只是不能独自承担所有复杂度。

八、一个可复用的 Prompt 模板

下面是我建议的基础模板。

不是万能模板。但适合大多数业务任务起步。

复制代码

<role>
你是 [专业角色]。
</role>

<task>
你的任务是 [明确动作]。
</task>

<context>
[必要业务背景，不要塞无关资料]
</context>

<constraints>
- 只根据输入内容判断。
- 不确定时输出 unknown。
- 不编造事实。
- 遵守字段枚举和值域。
</constraints>

<input>
[用户输入或待处理内容]
</input>

<output_format>
输出合法 JSON，结构如下：
{
  "result": "...",
  "confidence": "low|medium|high",
  "evidence": ["..."],
  "unknowns": ["..."]
}
</output_format>

<evaluation_criteria>
好答案必须：
1. 每个结论都有 evidence。
2. 不包含输入外事实。
3. JSON 可被解析。
4. unknowns 不为空时，不强行给高置信度。
</evaluation_criteria>

这个模板的核心不是标签，是契约。

它告诉模型：

复制代码

你是谁
做什么
依据什么
不能做什么
怎么输出
怎么判断好坏

九、Prompt 也要被测试

工程化的 prompt 不能只靠感觉。

至少要有一个小型 golden set。

比如 30 到 100 条典型输入。

里面包含：

复制代码

正常样本
边界样本
异常样本
恶意输入
格式挑战
业务冲突

每次改 prompt，都跑一遍。

看三件事：

复制代码

正确率有没有变化
格式失败有没有增加
成本和延迟有没有变化

如果 prompt 是团队资产，还要记录版本。

复制代码

prompt.md
CHANGELOG.md
evals/
failures/
schemas/

不要把关键 prompt 藏在某个人的聊天记录里。

那不是资产，那是隐患。

十、Prompt Engineering 的新位置

所以，Prompt Engineering 没死。它的位置变了。

过去很多人把它当成 AI 应用的全部。现在它更像系统入口的接口定义。

它决定：

复制代码

任务是否清楚
边界是否明确
输出是否可消费
失败是否可处理

但它不负责：

复制代码

动态检索资料
管理长期状态
执行外部动作
权限控制
验证真实结果
长期循环

这些要交给后面的工程层。

下一篇，我们继续讲 Prompt Engineering 的工程纪律：

复制代码

模板、变量、评测和版本管理。

因为只要 prompt 进入生产，它就不再是"写得顺手"。

它应该像代码一样被设计、测试、审查和回滚。

参考资料

Prompt engineering | OpenAI API
How prompt engineering works | OpenAI Help Center
Prompt engineering overview | Anthropic
Anthropic Prompt Engineering Interactive Tutorial
Effective context engineering for AI agents | Anthropic Engineering
A practical guide to building agents | OpenAI

参考文献：

Prompt Engineering 没死，只是它不再够用了