过去很多人把提示词讲成魔法。通过几句固定模板几个角色扮演几个“请一步步思考”。然后包装成一门秘术。现在模型能力变强很多老技巧看起来不那么神奇了。于是另一种声音又来了提示词没用了。 直接上 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_formatXML 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 APIHow prompt engineering works | OpenAI Help CenterPrompt engineering overview | AnthropicAnthropic Prompt Engineering Interactive TutorialEffective context engineering for AI agents | Anthropic EngineeringA practical guide to building agents | OpenAI参考文献Prompt Engineering 没死只是它不再够用了