大模型应用上线后，Prompt很少能一次写到位。当业务团队不断提出新的指令调整、示例替换或输出格式要求时，如果直接覆盖线上Prompt，一旦效果下降就很难回滚，也无法知道是哪一次修改导致变化。把Prompt当作代码一样进行版本管理，并用A/B测试验证每个候选版本，是解决这类问题的有效方式。
一、把Prompt当作版本化资产来管理
Prompt版本迭代的第一件事是给每个提示词分配唯一版本号，并保留完整变更历史。与代码版本管理类似，推荐使用语义化版本号，例如v1.2.0。主版本号在Prompt结构或任务目标发生重大变化时递增，次版本号用于新增示例、调整措辞，修订号用于修复错别字或格式细节。不要把这次改动简单保存为prompt_final_v2，否则几周后就会失去可追踪性。
在工程实现中，可以把Prompt内容放在独立文件或配置中心，而不是硬编码在业务代码里。每个版本保存为单独的文本文件，文件名包含版本号，例如prompt_v1_2_0.txt。提交记录中需要写明修改原因、影响的业务场景和预期变化。这样当线上指标异常时，可以快速对比两个版本的差异。
除了文件管理，也可以直接使用数据库表存储Prompt版本。下面是一个简单的表结构示例，记录版本号、内容、状态和创建时间。
CREATE TABLE prompt_versions (
id INT PRIMARY KEY AUTO_INCREMENT,
prompt_key VARCHAR(100) NOT NULL,
version VARCHAR(20) NOT NULL,
content TEXT NOT NULL,
status ENUM('draft','testing','online','archived') NOT NULL DEFAULT 'draft',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_prompt_version (prompt_key, version)
);
这种管理方式的关键在于把Prompt的修改从个人行为变成可审计的团队行为。每次创建新版本时，都需要在说明中回答两个问题：本次修改希望改善什么，以及失败时如何回滚。只有可回滚的版本，才适合进入下一步的A/B测试。
二、搭建Prompt A/B测试的流量与分组机制
A/B测试的核心是让不同用户或请求随机进入控制组和实验组，控制组使用当前线上Prompt，实验组使用候选Prompt。分组要尽量做到随机，同时避免同一用户在短时间内看到不同版本导致体验混乱。对于API调用场景，可以按session_id或user_id做哈希分流。
分流函数需要保证稳定性和均匀性。下面的Python函数根据用户ID的哈希值将流量分配到不同组，hash值取模后小于20进实验组，否则保留在控制组，这样实验组大约获得20%流量。
import hashlib
def assign_prompt_group(user_id: str, experiment_ratio: float = 0.2):
digest = hashlib.md5(user_id.encode('utf-8')).hexdigest()
bucket = int(digest[:8], 16) % 100
if bucket < int(experiment_ratio * 100):
return "experiment"
return "control"
实际项目中还需要记录每次请求命中的Prompt版本，方便后续关联结果指标。可以在日志中增加prompt_version字段，或者写入实验分析表。比如请求表可以设计为包含request_id、user_id、prompt_version、model_version、answer_text和latency_ms等字段。
流量比例并不是固定不变的。候选Prompt如果风险较高，可以先从5%的流量开始，观察一到两天没有明显异常再逐步放量。放量过程也可以看作阶段性实验，比如5%、10%、20%分别记录效果。不要一次性切50%流量，因为一旦候选Prompt存在严重缺陷，影响面会很大。
上下文隔离同样重要。如果用户在一次会话中多次调用模型，应该固定使用同一个Prompt版本，否则可能因为前后回答风格不一致影响用户体验。对于无用户ID的匿名请求场景，可以用设备指纹或IP加会话开始时间生成临时ID。
三、用合适的指标衡量Prompt版本效果
Prompt迭代容易只关注生成文本是否看起来更好，但A/B测试需要可量化的业务指标。常见指标包括任务成功率、用户点击率、留存率、平均对话轮次、人工审核通过率等。如果只是让模型改写文案，可以设置一个自动打分器，从相关性、流畅性、事实准确性三个维度给结果打分，再计算两个组的平均分差异。
下面展示一个简单的打分逻辑，用来评估生成答案是否包含预期关键词，并给出0到1之间的分数。这个分数可以作为A/B测试中的核心指标之一，当然真实场景中建议结合人工标注和业务指标。
def keyword_score(answer: str, expected_keywords: list) -> float:
hit = 0
for kw in expected_keywords:
if kw in answer:
hit += 1
return round(hit / len(expected_keywords), 4) if expected_keywords else 0.0
有了每个样本的指标值后，还需要比较两组均值是否存在显著差异。不能只比较两组的平均值大小，因为样本量较小时随机波动可能很大。可以使用独立样本t检验，或者对比例类指标使用卡方检验。Python中的scipy库可以完成这些检验。
from scipy import stats
def test_mean_difference(control_scores, experiment_scores, alpha=0.05):
t_stat, p_value = stats.ttest_ind(control_scores, experiment_scores)
significant = p_value < alpha
return {
"t_stat": round(t_stat, 4),
"p_value": round(p_value, 4),
"significant": significant
}
对于用户是否点击这种二分类指标，应该统计两个组的点击次数和总样本数，再使用卡方检验。下面是一个示例，假设控制组1000次请求中有120次点击，实验组800次请求中有112次点击，判断点击率提升是否显著。
import numpy as np
from scipy.stats import chi2_contingency
control_click, control_total = 120, 1000
experiment_click, experiment_total = 112, 800
table = np.array([
[control_click, control_total - control_click],
[experiment_click, experiment_total - experiment_click]
])
chi2, p_value, dof, expected = chi2_contingency(table)
print("p_value:", round(p_value, 4))
实验开始前还需要估算所需样本量。样本量过小会导致即使真实效果存在，统计检验也无法检测出来。对于比例类指标，可以根据基线转化率、最小可检测提升、显著性水平和统计功效，使用专业工具计算每组所需样本量。通常基准转化率越低，要检测出同样幅度的提升，所需样本量越大。不要把实验跑三天就下结论，先算清楚需要多少数据才能支撑判断。
如果p值小于0.05，通常认为差异在统计上显著，可以把实验组Prompt发布为新的线上版本；如果p值不显著，则说明现有样本还不足以证明新Prompt更好，需要继续收集数据或放弃该候选版本。
四、Prompt迭代与实验记录的最佳实践
A/B测试结束后，不应只保留新版本胜出的结论，还要把实验设计、样本量、指标变化和最终决策记录下来。这些记录可以帮助团队后续分析为什么某些Prompt改动有效，避免重复试验已经验证无效的改法。
建议每次Prompt变更都关联一个实验记录文件，包含以下内容：实验ID、候选版本号、控制组版本号、分流比例、开始和结束时间、核心指标、p值、最终决策。可以使用Markdown或YAML格式保存，但本文不展开具体格式，重点是要形成团队统一模板。
在接入自动化流程时，可以把Prompt版本管理、A/B测试和CI/CD结合起来。当开发者提交一个新的Prompt版本时，CI流程先执行格式校验和少量样例回归，通过后自动部署到实验环境，分配5%流量。实验运行足够长时间后，系统根据预设指标自动计算统计显著性，并输出实验报告。如果候选版本显著优于控制组，则自动或人工确认发布为新的线上版本；否则自动归档。
最后需要提醒的是，A/B测试只能回答在给定指标下哪个版本更好，不能替代对Prompt质量的整体思考。测试周期过短、指标定义不当或分组偏差都会导致错误结论。实践中建议先从单一指标开始，等流程稳定后再扩展到多个指标，避免因为同时优化太多目标而无法判断优先级。