日志与追踪：建立提示词输出日志的方法
说实话，我见过太多人调试提示词全靠「感觉」。
改一句词，跑一次，觉得效果还行？那就用这个版本了。下次效果差了？再改回来。你想想看，这跟蒙着眼睛走路有什么区别？
我在项目中遇到过最离谱的一次——一个同事花了三周调一个客服提示词，最后发现最优解是他第一天写的版本。为什么？因为他根本没记录每次改了什么。
所以这一章，咱们就来聊聊怎么用日志和追踪，把提示词调试这件事从「玄学」变成「科学」。
为什么要建日志？
说白了，日志就是你的「记忆」。没有日志，你根本不知道：
- 上次改了什么
- 为什么改
- 改完效果是变好还是变差
我个人的习惯是，每次跑提示词之前，先问自己三个问题：
- 当前版本号是多少？
- 这次改动的目标是什么？
- 我怎么判断改动是否成功？
这三个问题写下来，你的日志就有了骨架。
核心原则：没有日志的调试，等于没有调试。你改了什么、为什么改、效果如何——这三件事必须同时记录。
日志应该记什么？
我建议你至少记录以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 版本号 | 唯一标识，建议用日期+序号 | v2024-03-15-01 |
| 修改时间 | 精确到分钟 | 2024-03-15 14:30 |
| 修改内容 | 具体改了哪句话、哪个参数 | 将「请用简洁的语言」改为「请用不超过50字回答」 |
| 修改原因 | 为什么做这个改动 | 之前回答太长，用户反馈阅读体验差 |
| 测试输入 | 用来测试的样例 | 「帮我总结一下这篇文章」 |
| 模型输出 | 完整的输出结果 | （粘贴输出内容） |
| 评估结果 | 好/中/差，或具体评分 | 好（回答简洁，信息完整） |
| 备注 | 其他想记的东西 | 这个版本在长文本上表现更好 |
嗯，这里要注意——不要只记「改了什么」，一定要记「为什么改」。我踩过这个坑：翻看日志发现某次改动了温度参数，但完全想不起来当时为什么调低它。后来复盘才发现，那次是因为模型输出太随机了。但如果没有「修改原因」这个字段，这个信息就永远丢失了。
怎么建日志？两种方式
方式一：纯文本日志（适合个人）
最简单的方式，一个 Markdown 文件搞定。我习惯用这种格式：
# 提示词日志 - 客服助手项目
## v2024-03-15-01
- **修改时间**：2024-03-15 14:30
- **修改内容**：将 system prompt 中的「请用简洁的语言」改为「请用不超过50字回答」
- **修改原因**：之前回答太长，用户反馈阅读体验差
- **测试输入**：「帮我总结一下这篇文章」
- **模型输出**：文章主要讨论了...（输出内容）
- **评估结果**：好。回答简洁，信息完整，字数控制在50字以内
- **备注**：无
## v2024-03-15-02
- **修改时间**：2024-03-15 16:00
- **修改内容**：将 temperature 从 0.7 改为 0.3
- **修改原因**：v2024-03-15-01 版本输出太随机，有时会跑题
- **测试输入**：「帮我总结一下这篇文章」
- **模型输出**：文章主要讨论了...（输出内容）
- **评估结果**：中。回答稳定了，但有点死板，缺乏灵活性
- **备注**：考虑后续尝试 temperature=0.5
小技巧：每次修改后，把完整的提示词文本也保存一份。不要只记「改了什么」，因为有时候上下文变了，光看改动点看不出全貌。
方式二：结构化日志（适合团队）
如果团队协作，我建议用表格或数据库。比如用 Google Sheets 或 Airtable，每个人都能看到历史记录。字段和上面一样，但多了「修改人」和「审核状态」。
我曾经在一个项目里，团队五个人同时调同一个提示词。没有结构化日志的结果就是——有人改了 prompt，另一个人不知道，又改回去。浪费了整整两天。后来上了共享表格，每个人改之前先看最新版本，改完立刻更新日志，效率翻倍。
如何追踪每次修改的效果？
光记日志还不够，你得能对比。我常用的方法是「A/B 测试对比表」：
| 评估维度 | v2024-03-15-01 | v2024-03-15-02 | 变化 |
|---|---|---|---|
| 回答长度 | 120字 | 45字 | ✅ 缩短 |
| 信息完整性 | 90% | 85% | ⚠️ 略降 |
| 输出稳定性 | 60% | 95% | ✅ 大幅提升 |
| 用户满意度 | 3.2/5 | 4.1/5 | ✅ 提升 |
你看，光看「回答长度」和「信息完整性」，v2 好像不如 v1。但加上「输出稳定性」和「用户满意度」，v2 明显更好。这就是为什么不能只看单一指标。
避坑指南：我曾经只盯着「回答长度」这一个指标，把 prompt 改得越来越短。结果呢？回答是短了，但信息丢失严重，用户反而更不满意。所以一定要多维度评估，至少 3-5 个指标。
版本控制管理提示词
日志是记录，版本控制是管理。我强烈建议你把提示词纳入 Git 管理。
为什么？因为 Git 能帮你：
- 回滚到任意历史版本
- 对比两个版本的差异
- 分支管理不同实验方向
- 多人协作时避免冲突
具体怎么做？很简单：
# 1. 创建提示词仓库
mkdir prompt-repo
cd prompt-repo
git init
# 2. 保存提示词文件
# 比如：customer_service_prompt.md
# 3. 每次修改后提交
git add customer_service_prompt.md
git commit -m "v2024-03-15-01: 将回答长度限制改为50字"
# 4. 查看历史
git log --oneline
# 5. 对比两个版本
git diff v2024-03-15-01 v2024-03-15-02
我个人习惯在 commit message 里写上版本号和改动原因。比如：
v2024-03-15-01: 缩短回答长度，提升阅读体验v2024-03-15-02: 降低 temperature，提高输出稳定性
这样以后翻 git log，一眼就能看出每个版本做了什么。
进阶技巧：用 Git 分支来管理不同实验方向。比如 main 分支放稳定版本，experiment-1 分支尝试加 few-shot 示例，experiment-2 分支尝试改角色设定。哪个效果好，就合并到 main。
我的工作流总结
说了这么多，给你看看我实际怎么做的：
- 写 prompt：在 VS Code 里写，保存为 .md 文件
- 跑测试：用脚本批量跑 5-10 个测试用例
- 记日志：在日志文件里记录版本号、改动、原因、结果
- 提交 Git：commit message 写清楚版本号和改动
- 对比评估：用对比表看效果变化
- 决定下一步：效果好就继续，效果差就回滚
整个过程不超过 15 分钟。但就是这 15 分钟，能让你少走无数弯路。
你想想看，如果没有日志和版本控制，你改了一百次 prompt，最后发现最好的版本是第 37 次——你还能找回来吗？有了 Git，一个 git checkout 就搞定了。
好了，这一章就到这里。下一章咱们聊聊怎么用自动化工具来跑批量测试，让调试效率再上一个台阶。