参考答案
核对日期：2026-05-13。
1. 阶段练习参考方向
1.1 五要素重写
合格 Prompt 应包含：
- 目标：要完成什么任务。
- 上下文：可用资料、用户输入、业务背景。
- 约束：禁止事项、边界、优先级。
- 输出格式：字段、类型、结构、语言。
- 验收标准：什么算通过，什么必须拒绝或标记不确定。
不合格 Prompt 的典型问题是“请帮我总结一下”，没有对象、用途、长度、格式、事实边界和失败处理。
1.2 结构化输出练习
抽取任务的 JSON schema 应定义字段类型、必填项、枚举和空值策略。校验失败后的重试 Prompt 不应只说“重新输出 JSON”，而要附上具体错误：
上一次输出未通过 schema 校验：
- amount 应为 number，但收到 string
- date 缺失
请只修复结构，不新增证据中没有的信息。
恶意和噪声样例要覆盖 prompt injection、乱码、缺字段、字段冲突和超长输入。
1.3 上下文包设计
RAG context packet 建议字段：
| 字段 | 作用 |
|---|---|
| doc_id / chunk_id | 引用和追踪 |
| title | 帮助模型理解来源 |
| source_url 或 path | 回溯原文 |
| version / updated_at | 处理新旧冲突 |
| permission_scope | 权限过滤 |
| relevance_score | 排序依据 |
| content | 证据正文 |
排序优先级通常是：权限通过 -> 相关性 -> 新鲜度 -> 权威来源 -> 去重。token 超预算时先裁剪低相关、重复、过旧、无权威来源的证据。
1.4 Prompt 回归评测
20 条 eval 样例应覆盖正常、边界、缺信息和注入。对两个版本比较时至少记录：
- 格式通过率。
- 事实正确率。
- 拒答准确率。
- 注入防护通过率。
- 平均 token 和延迟。
改动结论要写成“保留、回滚或继续实验”，并说明证据。
1.5 Prompt / 代码边界判断
判断原则：
- 表达任务和输出风格：Prompt。
- 可配置阈值、开关、模型参数：配置。
- 权限、金额、状态流转、数据过滤：代码或数据库。
- 高风险动作：人工审核。
- 法规、合同、组织规则：数据库或知识库，Prompt 只负责引用和解释。
2. 项目评分样例
高分 Prompt 模板库应具备：
- 至少 5 类任务，每类有版本、输入变量、输出 schema 和 eval。
- 模板能被另一个工程师直接复用。
- 每个模板有失败模式和回滚记录。
- eval 覆盖正常、边界、缺信息和恶意输入。
- 清楚说明哪些规则不放 Prompt。
不合格表现：
- 只有几段“神奇话术”。
- 没有 schema 和校验失败策略。
- 没有版本记录，线上手改无法回滚。
- 把权限和业务规则写在 Prompt 里。
3. 验收题参考答案
- Prompt 五要素分别是什么？
目标、上下文、约束、输出格式、验收标准。它们分别回答做什么、依据什么、不能做什么、怎么输出、如何判断好坏。
- Prompt 工程和上下文工程的区别是什么？
Prompt 工程关注指令表达和输出控制；上下文工程关注哪些信息进入模型、如何排序、裁剪、隔离和更新。后者更接近系统设计。
- 为什么 system instruction 不能替代权限控制？
system instruction 仍然是模型输入的一部分，可能被注入影响或被模型误执行。真正的权限控制必须由后端、工具、数据库和审计机制执行。
- Few-shot 示例应该如何选择？
选择代表真实分布的样例，覆盖正常、边界、反例和期望格式。样例要短、清晰、无歧义，避免把错误模式教给模型。
- 为什么结构化输出仍需要 schema 校验？
模型可能输出缺字段、类型错误、额外字段、截断 JSON 或编造值。schema 校验是程序边界，能触发重试、降级或人工处理。
- 上下文包应该包含哪些字段？
至少包含内容、来源、ID、版本、更新时间、权限范围、相关性分数和引用信息。RAG 场景还应包含 chunk_id 和原文位置。
- Prompt 版本管理至少要记录哪些信息？
版本号、适用模型、推理参数、Prompt 正文、变更原因、eval 结果、上线时间、回滚方式和已知失败模式。
- Prompt eval 应该覆盖哪些样例类型？
正常样例、边界样例、缺信息样例、格式异常样例、恶意注入样例、多语言或噪声样例、历史失败样例。
- 哪些业务规则必须放在代码里，而不是 Prompt 里？
权限、金额阈值、状态流转、数据过滤、合规限制、不可回滚动作、审计记录和安全拦截必须放在代码、配置、数据库或审批系统里。
- Prompt injection 的核心风险是什么，如何降低？
核心风险是用户或外部内容试图覆盖系统指令、泄漏数据或诱导工具越权。降低方式包括输入隔离、权限过滤、工具最小权限、引用校验、安全 eval、输出校验和人工审批。