一句话定义
提示工程是在不改变模型参数的前提下，通过设计输入内容来引导模型输出。它关心的是「怎么说」，而不是「改模型」。
常用手段
- 明确角色与任务：说明你是谁、要做什么、交付什么形式。
- 给约束：长度、语气、禁止事项、必须包含的字段。
- 给示例：用少量输入输出样例（few-shot）固定格式和风格。
- 拆步骤：把复杂任务分解成子问题，或要求先列提纲再作答。
- 结构化输出：要求 JSON、表格或固定字段，便于程序解析。
- 提供上下文：把相关资料放进 上下文窗口，减少模型凭空编造。
怎么判断有效
提示词不是写完就结束，而要建立小规模评测集：固定一批典型输入，比较不同提示的通过率、格式正确率和稳定性。没有评测，只靠单次观感很难判断改动是否真的变好。同一个提示在不同模型/版本上效果可能不同，要做回归测试；提示工程的收益要用评测数据说话。
局限
- 提示无法给模型注入它没有的知识；知识密集场景需要 RAG 或微调。
- 对复杂多步任务，单轮提示的稳定性有限，通常要配合工具和 Agent 循环。
- 模型版本变化可能让原本有效的提示失效，需要回归测试。
- 提示越长，关键指令越容易被淹没，成本和延迟也越高。
用在哪里
- 任务定义清晰、但模型输出格式/风格不稳定时。
- 知识不足先补 RAG；多步任务用 Agent；提示工程负责约束输入输出，不替代它们。
常见误区
- 存在一套「万能咒语」：效果依赖任务、模型和数据，不能照搬。
- 提示工程可以替代评测：它恰恰最需要评测来收敛。
- 把所有要求堆进一段话就是好提示：结构清晰比篇幅更重要。