Prompt Engineering 技巧怎么选?

回答与解析

真实性边界

问题要求说明“使用过”的技巧和实际效果，因此只能填写真实任务、模型、Prompt 版本和评测结果。法务、客服等场景若未实际参与，只能作为明确标注的教学假设，不能写成个人业绩。

回答框架

• 任务：真实输入输出、风险、失败类型和评价指标。
• 技巧：说明实际采用角色/边界、上下文分隔、Few-shot、检索增强、工具 schema、结构化输出或结果校验中的哪些。
• 机制：解释每项技巧针对哪个可观察错误，而不是罗列名词。
• 实验：固定模型、数据与解码参数，对 Prompt 版本做消融和切片。
• 生产：版本管理、监控、提示注入防护、回滚和成本约束。

事实填空

在【真实任务】中，基线 Prompt 为【】，常见错误为【】。我负责【】，采用【真实技巧】解决【对应问题】，与【备选】比较。评测集【来源/规模】，真实结果【】，延迟或 token 变化【】，失败切片【】。

证据自检

每个效果数字应能关联 Prompt diff、测试样本、模型版本和统计口径。引用正确不等于答案正确；JSON 可解析不等于业务字段有效；LLM-as-Judge 需要人工校准。

追问入口

可继续追问上下文冲突、动态示例泄漏、结构化输出失败、工具参数安全、评测器偏差和 Prompt 与模型升级的回归关系。

口语版讲法(约90秒)

• Prompt工程本质是引导模型行为
• 基础技巧：角色锚定、格式约束、负面指令
• 场景化技巧：RAG用引用强制，Agent用ReAct框架
• 业务案例：法务问答的幻觉治理
• 工程师判断：Prompt是手感活，要结合校验和版本管理

我会从一个确实做过的应用讲，而不是把常见技巧全报一遍。场景是【真实场景】，我负责【本人职责】，基线最突出的问题是【主要错误】。我采用的【具体技巧】必须和这个问题一一对应：例如 Few-shot 用来示范边界，结构化输出配合服务端校验解决解析，RAG 提供外部证据，工具 schema 约束可执行参数。

实施时我固定模型、数据和解码参数，在同一回归集上比较 Prompt 版本。用【评测口径】同时看任务质量、格式、引用支持、危险动作、token 和延迟，并按【失败切片】检查平均分会不会掩盖高风险退化。自动 Judge 只作辅助，还要用人工样本校准。

最终只报告【真实结果】，能对应 Prompt diff、样本和线上记录的数字才说。来自用户或文档的内容都按不可信输入处理，敏感工具由服务端鉴权和确认。模型升级后重跑回归；如果失败根因是缺知识、缺权限或模型能力不足，就把问题交给 RAG、工具或微调，不继续堆提示词。

关键一句:自动化Prompt优化方法，根据bad case自动调整指令，类似Self-RAG的反思机制。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们做一个法务RAG系统，用户问‘合同无效的情形’，模型直接编了条法条。你平时写prompt会怎么防止这种幻觉？比如加什么约束或者格式要求？

2. 问法 2 · 层层追问

   你一般怎么用prompt来让模型输出更稳？……如果模型老是不按格式来，比如该输出JSON却输出自然语言，你会怎么处理？……那如果要保证引用来源准确，比如RAG里强制标出处，你觉得prompt上怎么做最有效？

3. 问法 3 · 直球架构

   聊一下Prompt Engineering技巧，重点是提升输出质量和一致性。你用过哪些？从基础的角色锚定、格式约束，到针对RAG的引用强制、Agent的ReAct框架，具体怎么设计、效果怎么样？