模型与 Prompt
用可验证实验改进 Prompt
固定任务、失败样本和输出契约，一次验证一个改动。
先做什么
先把任务要求写成可验收的输出，再修改提示词。没有失败样本和固定评测，只能知道新版本看起来更好，不能知道它是否更可靠。
理解这条链路
任务与输出契约失败样本单项改写同题运行配对检查版本发布
一个足够实用的结构
写清角色与任务、允许使用的证据、输出格式、工具触发条件和证据不足时的行为。示例覆盖容易混淆的边界，而不是堆很多正常答案。把用户材料与应用指令分隔，但不要误认为 Markdown/XML 边界能独立阻止提示注入。
按错误类型修改
答案冗长：限制用户需要的字段和长度；事实无依据：要求回引材料并明确未知；工具误调用：写清前置条件并加服务端权限；格式不稳定：用 Schema 而不是重复强调格式。一次只调整一个主要因素，比较新增退化样本。
按这个顺序操作
- 收集代表性正常、困难、拒答与工具边界案例，固定期望结果。
- 把提示词拆为稳定指令与动态材料，记录版本和输入字段。
- 修改一个假设并做同题比较，人工复核关键差异。
- 保存最佳版本、失败样本和回滚目标，模型升级后重新评测。
可直接复用的记录模板
# 任务 根据已提供的有效资料回答客户问题。 # 证据 只使用给定材料；材料冲突时指出冲突，缺少依据时明确未确认。 # 工具 查询前核验目标；有副作用的操作由业务服务校验并执行。 # 输出 结论、对应依据、需要用户补充的信息；避免冗长铺垫。 # 验收 事实可回源；没有多余工具动作；满足格式；保留未知。
做到什么程度才算通过
- 修改对应一个可验证假设。
- 正常与边界案例一起测试。
- 输出约束在合适的系统层实现。
- 版本与模型快照可回滚和比较。
当前证据的限制
示例是通用起点，未针对用户某个实际模型与业务做效果验证。
本轮确认的事实与来源
以下为公开资料支持的具体结论；操作流程和验收建议属于工程推导。仓库说明或厂商效果表述不等于独立实测。
[1] OpenAI · Prompt engineering
OpenAI 当前文档建议在代码中管理生产提示词，采用明确输入、示例和评测；同时提醒不同模型快照会产生不同行为。
资料日期：页面未统一标注；以复核日期为准 · 复核：2026-09-08
阅读原始来源 ↗[2] OpenAI · Function calling
函数调用的参数约束由工具 Schema 表达，严格格式依然需要应用校验和执行；单在 Prompt 里说“务必正确”不足以保证业务结果。
资料日期：页面未统一标注；以复核日期为准 · 复核：2026-09-08
阅读原始来源 ↗这次更新了什么
将从小白到大师的泛化层级改为一次完整调优实验；更新当前官方关于代码管理 Prompt 的建议。
合并前的内容入口
以下旧地址仍可访问，并会带你来到本篇。完整重构前材料已留存本地备份。
- research-hub/prompt-engineering-mastery.html