Prompt 设计原则有哪些?

回答与解析

回答边界

这类题既考查 Prompt 机制，也会核验候选人是否真的做过迭代。先讲可复用原则，再用本人可核验的 bad case、版本记录和评测结果补充；不能把下面的教学框架直接说成个人经历。

核心设计框架

可以从任务、上下文、约束、输出契约四层分析：

【任务】目标、输入和成功条件是什么
【上下文】只提供完成任务所需的事实与工具结果
【约束】权限、拒答、引用和不确定性边界
【输出契约】Schema、字段含义及校验失败后的处理

关键优化顺序

1. 先建立固定评测集和 bad case 分类，再修改 Prompt。
2. 长上下文只注入相关证据，并记录截断和检索策略。
3. Few-shot 示例覆盖正常、模糊、拒绝和格式边界，避免只放成功样本。
4. 结构化输出使用 Schema 校验和有限重试，不能只依赖自然语言要求。
5. Prompt 版本与模型版本、评测集版本一起记录，通过回归测试再发布。

不应默认要求模型输出隐藏推理过程；复杂任务可以要求简洁的依据或检查步骤，但生产系统更应依赖工具结果、结构化状态和可观测日志。

项目事实填空

如果结合本人项目回答，只填写可核验信息：任务是【真实任务】；最初失败类型是【真实 bad case】；修改了【真实 Prompt 或链路环节】；用【真实评测集与指标】验证；副作用是【真实成本、延迟或退化】；版本证据是【真实提交、实验或日志】。没有做过 A/B 测试或没有线上指标时应明确说明。

口语版讲法(约4分钟)

• 题目本质是问Prompt工程在真实项目中的系统化落地
• 四层结构作为基础模板
• 动态上下文管理与少样本设计
• 思维链触发与迭代优化
• 工程化实践与风险意识

这道题不能只背一个 Prompt 模板。比较稳的回答顺序是：先定义任务和成功条件，再讲上下文、约束与输出契约，最后说明如何通过评测和版本记录迭代。

任务层要说清输入、目标和失败边界；上下文层只注入完成任务所需的事实、检索证据和工具结果，避免把无关长文档全部塞入；约束层明确权限、拒答、引用和不确定性处理；输出层使用 JSON Schema 等契约校验字段，而不是只写一句‘请按 JSON 返回’。

Few-shot 示例的价值不在数量，而在覆盖边界。正常、模糊、拒绝和格式异常都要有样本，并且不能让示例泄露评测答案。Query 改写、摘要记忆和长上下文压缩也不是默认开启，要用 bad case 证明它们解决了什么问题，同时记录新增的延迟和信息损失。

迭代时先固定评测集，将错误分成事实性、指令遵循、格式、拒答和安全等类型。每次只改有限变量，记录 Prompt、模型和评测集版本，再跑回归测试。结构化输出失败可以有限重试，但重试仍失败时必须进入明确的降级路径。评测集还要包含历史回归样本与新出现的线上切片，避免只针对当前几个 bad case 调到过拟合。

Prompt 注入和越权不能只靠一句‘忽略恶意指令’。系统消息、用户输入、检索文档和工具返回需要区分信任级别；外部内容只作为数据，不能获得修改系统规则的权限。工具参数在执行前还要做类型、范围和权限校验，高风险写操作需要二次确认或人工审批。这样才能把自然语言约束落到确定性的执行边界。

还要注意，要求模型展示完整思维过程并不是可靠性的保证。生产系统更需要可核验的引用、工具结果、结构化状态和 Trace。Prompt 也不能弥补模型能力、知识库质量或权限设计的根本缺陷。若一个改动只提升格式正确率，却降低事实性或增加拒答，也不能简单判断为更优。

版本管理需要同时记录 Prompt 模板、模型、温度、工具 Schema、知识库和评测集。回滚时必须恢复一套相互兼容的组合，不能只回滚提示词。发布前可以用影子流量或离线回放比较新旧版本，并人工抽查高风险类别，确认改动没有破坏原有能力。

如果面试官要求结合项目，回答者只补充自己的真实任务、bad case、修改记录、评测方法和副作用。没有做过线上 A/B 测试或没有可核验指标时直接说明，不能把教学示例包装成亲历方案。

关键一句:RAG引入后需要做Faithfulness校验，确保模型输出与检索文档一致。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服，用户问“我的订单到哪了”，你Prompt怎么写的？如果用户接着问“我什么时候能退款”，你会怎么调整Prompt让它不跑偏？

2. 问法 2 · 层层追问

   Prompt设计你一般怎么入手？……怎么保证模型每次都按你想要的格式输出？……如果模型偶尔不遵循指令，你是改Prompt还是加后处理？

3. 问法 3 · 直球架构

   设计一个Prompt模板，要求能稳定输出JSON格式的意图和实体，并且适应不同业务场景。你用什么结构？怎么处理边缘Case和注入攻击？