Prompt 实验手册

本文来自《AI 应用开发课程》月份 1 课程文档，已整理为网站文章版本。

学习目标

学完本节后，你应当能够：

• 用实验而不是感觉来比较 Prompt 效果。
• 系统测试 system prompt、few-shot、结构化输出等策略。
• 为月份 1 保留最基本的 Prompt 实验记录。

前置知识

• 已理解普通调用、结构化输出和上下文管理

1. 本节核心原则

Prompt 学习不能停留在“记概念”。你必须像做实验一样记录：

• 输入是什么
• Prompt 写法是什么
• 输出有什么差异
• 哪种写法更稳定

2. 建议你比较的 5 类策略

策略一：无 system prompt vs 有 system prompt

观察模型角色稳定性和输出风格变化。

策略二：无示例 vs few-shot

观察格式稳定性是否提升。

策略三：自由文本 vs 结构化输出

观察可解析性和可程序消费性差异。

策略四：单步请求 vs prompt chaining

先让模型分析，再让模型生成，观察是否更稳。

策略五：不同温度设置

观察稳定性和多样性差异。

3. 实验记录模板

建议在 notes/experiment-log.md 中按下表记录：

4. 推荐实验任务

因为本月主线是“研发助手”，所以实验任务也围绕研发场景：

• 总结一段需求描述
• 生成 commit message
• 从一段 bug 描述中抽取修复步骤
• 将自然语言任务转成结构化待办列表

5. 评价标准

不是“像不像人写的”，而是优先看：

• 是否稳定
• 是否符合格式
• 是否方便程序继续处理
• 是否适合你的主场景

6. 一个最小实验流程

1. 固定输入任务
2. 每次只改一个变量
3. 记录输出
4. 给出结论

这和后续月份 2 的 RAG 实验方法是一致的。

7. 实操任务

至少完成以下 4 组实验：

1. 有无 system prompt
2. 有无 few-shot
3. 自由文本 vs JSON 输出
4. temperature=0.2 vs temperature=0.8

8. 自测题

1. 为什么 Prompt 不应该只靠直觉判断优劣？
2. 为什么实验中每次最好只改一个变量？
3. 对月份 1 来说，Prompt 的首要评价标准应该是什么？

9. 作业与验收

作业：

• 产出一份 prompt_experiments.md

验收标准：

• 至少 4 组对比实验
• 每组实验有明确输入与结论
• 至少指出 1 个“看起来高级但对当前场景没帮助”的 Prompt 写法

10. 常见错误

• 一次改很多变量，最后不知道哪个生效
• 只保留感觉，不保留实验记录
• 只看文案优美，不看格式稳定性

11. 本章与前文关系

前面几章让你已经有了：

• 模型调用链路
• 消息结构意识
• 结构化输出意识
• 流式与记录意识

现在开始进入月份 1 的“方法论层”：当你面对多个 Prompt 写法时，如何不用拍脑袋，而是像工程实验一样做判断。

12. 本章在研发助手项目中的位置

研发助手项目后面涉及的很多能力，都不是只靠代码结构能解决的：

• 总结 diff 的语气是否稳定
• 抽取待办项是否完整
• commit message 是否更像工程团队会接受的风格

这些都需要 Prompt 实验支撑。

13. 为什么 Prompt 学习最容易流于表面

因为它看起来门槛很低：

• 改几句文字
• 输出立刻变化

但也正因如此，它最容易变成“印象流”：

• 这个写法好像更好
• 那个写法感觉更聪明

月份 1 必须建立的不是“记住很多技巧”，而是下面这个习惯：

每次只改一个变量，记录输入、输出和结论。

14. 错误示例 vs 正确示例

错误示例：一次改动 system prompt、few-shot、temperature

这样即使结果更好了，你也不知道是哪一个因素真正起作用。

正确示例：控制变量

例如只改 system prompt，其余条件不变：

• 同一输入
• 同一模型
• 同一温度
• 同一输出格式要求

这才是可比较的实验。

15. 一个固定的研发助手实验集合

建议你在月份 1 里固定使用 4 组任务，这样实验更有可比性：

任务 1：总结需求描述

目标：看模型是否能抓住主要目标和限制。

任务 2：从需求中抽取待办项

目标：看结构化输出是否稳定。

任务 3：根据 diff 生成 commit message

目标：看输出是否符合研发场景。

任务 4：总结错误日志并给出排查步骤

目标：看模型能否按分析型风格输出。

16. 一个更完整的实验记录模板

建议把 notes/experiment-log.md 升级为下表：

这个模板的重点在于：你不只是记录“结果”，还记录“这次到底改了什么”。

17. 评价标准如何定得更工程化

不要只看“写得像不像人话”，而是优先看：

• 是否稳定
• 是否更符合后续程序消费
• 是否减少歧义
• 是否更符合研发助手场景

例如：

• 对待办项抽取任务来说，结构稳定比文采更重要
• 对 commit message 任务来说，风格一致性比创造力更重要

18. 一个推荐的实验节奏

对每组任务，按这个顺序做：

1. baseline：无特别优化
2. 增加 system prompt
3. 增加 few-shot
4. 增加结构化输出要求
5. 调整 temperature

这样你会自然看到：有些“高级技巧”其实没有你想象中那么重要，而有些简单约束却非常有效。

19. 调试与排错：Prompt 实验里最值得记录的 bad cases

Bad Case 1：输出多了无关解释

尤其在要求 JSON 时很常见。

Bad Case 2：字段看起来对，值却不稳定

例如 priority 一会儿是 urgent，一会儿是 high。

Bad Case 3：同一个任务，模型关注点漂移

例如本来要总结需求，却跑去解释背景。

这些 bad cases 的价值非常高，因为后面做 RAG 和 Agent 时，你会发现“记录失败案例”的能力比“记成功案例”更有用。

20. 本章完成后你应该具备的能力

完成本章后，你应当做到：

1. 能按实验方式比较 Prompt。
2. 能控制变量，而不是凭感觉改一堆参数。
3. 能围绕研发助手场景设计稳定的 Prompt 测试任务。
4. 能记录 bad cases 和结论。

21. 如果你卡在这里，先回看哪几章

• 结构化输出还不稳：回看 03-结构化输出与JSON Schema.md
• 消息结构意识不稳：回看 02-消息结构与上下文管理.md

22. 从本章过渡到下一章的桥接说明

接下来进入 04-Tool_Calling基础 模块。

到这里，你已经把“模型如何输入、如何输出、如何实验”打通了。下一步就是让模型不只会生成文本，还能通过工具与程序能力协作。这会把月份 1 从“聊天应用”正式推向“最小智能助手”。