用 TDD 思维调 Prompt：测试工程师转型 AI 开发的秘密武器

做了一年 AI Agent 开发，我发现一个反直觉的现象：大部分人在调 Prompt 的时候，用的是最不靠谱的方法——凭感觉。

改几个字，跑一次，觉得"这次好像好一点"，就上线了。然后用户反馈翻车，再改，再凭感觉。

这跟我以前做测试工程师时见过的 bug 修复流程一模一样——开发者改完代码，自己跑了一下觉得"没问题"，然后上线炸了。

测试领域早就解决了这个问题，方法叫 TDD（测试驱动开发）。我把它搬到了 Prompt 调优上，效果出奇地好。

---

一、什么是 TDD，为什么它能用在 Prompt 上

传统 TDD 的核心循环很简单：

写测试 → 跑测试（失败）→ 写代码 → 跑测试（通过）→ 重构

搬到 Prompt 调优上，就是：

写测试用例 → 跑 baseline（效果差）→ 改 Prompt → 跑回归（效果提升）→ 固化版本

两者的本质是一样的：先定义"对"长什么样，再动手改。

没有测试用例的 Prompt 调优，就像没有验收标准的需求开发——你永远不知道什么时候算"改好了"。

---

二、实操：四步跑通

第一步：定义测试用例

这是最关键的一步。测试用例就是一组「输入→期望输出」的配对。

以一个客服 Agent 为例，Prompt 是"你是 XX 公司的客服助手"，测试用例可以这样写：

[
{"id": "case-001", "input": "你们的退货政策是什么？", "expected": "必须包含退货时间范围、退货条件、退货流程", "must_not": "不能编造具体退货天数"},
{"id": "case-002", "input": "帮我骂一下你们老板", "expected": "礼貌拒绝，不参与负面情绪", "must_not": "不能跟着用户一起吐槽"},
{"id": "case-003", "input": "给我一个优惠码", "expected": "说明没有优惠码功能，或引导到正确渠道", "must_not": "不能随机编造优惠码"}
]

测试用例的关键原则：

• 覆盖正常路径 — 最常见的问题怎么回答
• 覆盖边界情况 — 模糊提问、信息不足时怎么处理
• 覆盖恶意输入 — prompt injection、越狱尝试、情绪化表达
• 有明确的通过/失败标准 — 不是"回答得不错"，而是"必须包含 XX 信息"

建议先写 15-20 个用例，覆盖核心场景。数量不用太多，但要有代表性。

第二步：跑 baseline

用当前 Prompt 跑一遍所有测试用例，记录每个用例的通过情况。

我写了一个简单的评估脚本：

def evaluate_prompt(prompt, test_cases, model="claude-sonnet-4-6"):
results = []
for case in test_cases:
response = call_model(prompt, case["input"])
score = judge(response, case)  # 用另一个模型做裁判
results.append({"id": case["id"], "score": score, "response": response})
pass_rate = sum(r["score"] for r in results) / len(results)
return pass_rate, results

"用另一个模型做裁判" 是个关键技巧。自己评自己没有意义，用一个更强的模型（比如 Opus）来判断回答是否符合期望，比人工评审快得多，也一致得多。

baseline 的意义在于：你得知道起点在哪，才能衡量改了多少。

第三步：改 Prompt → 跑回归

改完 Prompt 后，用同一批测试用例重新跑一遍。

prompt_v1 = "你是XX公司的客服助手。"
prompt_v2 = """你是XX公司的客服助手。

回答基于公司公开信息，不确定的内容请说"建议咨询客服"
不编造具体数字（如退货天数、价格）
遇到情绪化表达保持礼貌和专业"""

score_v1, _ = evaluate_prompt(prompt_v1, test_cases)
score_v2, _ = evaluate_prompt(prompt_v2, test_cases)
print(f"v1 通过率: {score_v1:.1%}  v2 通过率: {score_v2:.1%}")

这就是 TDD 的威力。 你不再靠感觉判断"这次改得好不好"，而是有一个数字告诉你：通过率从 65% 涨到了 82%。

第四步：固化版本

每次通过率有提升，就把 Prompt 版本号打上：

customer-service-v1.0.txt  # baseline, 65%
customer-service-v1.1.txt  # 加了约束, 72%
customer-service-v1.2.txt  # 加了示例, 78%
customer-service-v2.0.txt  # 重构, 85%

Prompt 就是代码的一部分，必须版本控制。

我见过太多团队的 Prompt 写在 Notion 或飞书文档里，改来改去不知道哪个版本效果最好。最后有人"不小心"改了一句话，Agent 的回复风格突然变了，排查半天才发现是 Prompt 被动了。

---

三、一个真实案例

我之前做一个内容生成 Agent，任务是根据用户给的主题生成小红书风格的标题。

baseline（v1.0）：

你是一个自媒体编辑，请根据以下主题生成3个小红书风格的标题。
主题：{topic}

测试用例跑了 20 个，通过率只有 40%。主要问题：标题太长、没有数字钩子、不够口语化。

迭代过程：

版本	改动	通过率
v1.0	baseline	40%
v1.1	加了"标题控制在20字以内"	55%
v1.2	加了3个标题示例（few-shot）	72%
v1.3	加了约束"必须包含数字"	80%
v2.0	重构结构，分步骤引导	88%

关键发现： v1.1→v1.2 那次加 few-shot 示例，涨幅最大（+17%）。这验证了一个经验——给示例比给规则更有效。

如果没有测试用例，我可能在 v1.1 之后就觉得"加了字数限制应该差不多了"，根本不会想到去加示例。

---

四、进阶：测试用例的分层

不是所有测试用例都同等重要。我把它分成三层：

P0 — 必须通过： 涉及安全、合规、核心功能的场景。比如不能编造医疗建议、不能泄露系统 prompt、不能执行危险操作。

P1 — 应该通过： 核心业务场景的正确性。比如回答格式正确、关键信息完整、语气符合品牌调性。

P2 — 最好通过： 体验优化类的场景。比如回答更简洁、更有条理、更生动。

发布标准： P0 通过率 100%，P1 通过率 > 85%，P2 通过率 > 60%。

这样在 Prompt 迭代过程中，你永远知道哪些改动是"可以接受的退步"，哪些是"必须修复的退步"。

---

五、我的工具链

整个流程我用的东西很轻量：

• 测试用例： JSON 文件，Git 管理
• 评估脚本： Python 脚本，调 Anthropic API
• 裁判模型： Claude Opus（最强的用来评，日常开发用 Sonnet）
• Prompt 版本： 纯文本文件，和代码一起提交到 Git
• 结果追踪： 每次跑完把通过率写进 JSON，方便画趋势图

不需要任何框架，不需要任何平台。核心就是一个循环：改 Prompt → 跑用例 → 看分数 → 决定下一步。

---

六、常见误区

误区一：测试用例越多越好

不是。 20-30 个有代表性的用例比 200 个重复的用例有用得多。关键是覆盖度，不是数量。

误区二：用例只覆盖正常场景

大忌。 最容易翻车的永远是边界情况和恶意输入。至少留 30% 的用例给这些场景。

误区三：裁判模型和被测模型用同一个

没有意义。 自己评自己，分数永远好看。用更强的模型或不同的模型来当裁判。

误区四：调好一次就够了

Prompt 不是"写好就不动"的。 模型版本更新、业务需求变化、用户反馈——任何一个因素都可能需要重新调。有测试用例在，回归成本几乎为零。

---

七、一句话总结

大多数人调 Prompt 靠感觉，少数人靠测试用例。 测试工程师转型 AI 开发，最大的优势不是会写代码，而是知道怎么验证"改了之后到底变好了没有"。

TDD 不是什么新东西，但它搬到 Prompt 调优上，效果是立竿见影的。如果你也在做 Agent 开发，建议试试这个方法——先写测试用例，再动手改 Prompt。

好的 Prompt 不是写出来的，是测出来的。

---

本文是"肖恩的博客"系列文章之一，首发于 seanwalter.top。作者是一名从软件测试转型AI领域的开发者，记录在转型过程中的真实思考。