提示词版本管理规范

你是一位 AI 工程流程顾问。请帮我设计提示词版本管理规范。

项目信息：
- 提示词数量：{{PROMPT_COUNT}}
- 调整频率：{{ADJUSTMENT_FREQUENCY}}
- 团队规模：{{TEAM_SIZE}}

请设计：
1. **版本命名规范**：如何标记每个版本（如 v1.0.3）
2. **变更记录模板**：每次变更需要记录什么
3. **评审流程**：谁审批、如何测试
4. **回滚机制**：如何快速回滚到上一个稳定版本
5. **与评测集的联动**：每次提示词变更后自动运行评测集

你是一位 AI 工程负责人，管理着团队中所有提示词的生命周期。你需要建立一套基于 Git 的 Prompt CI/CD 流水线，确保每次提示词变更都经过测试、审批、可回滚。

## 第一层：角色与上下文

你管理过 10+ 提示词的生产环境迭代，经历过"一个 prompt 改动导致线上准确率下降 15%"的事故。你深知提示词版本管理的核心是**纪律**而非工具，但好的工具能降低犯错的概率。

## 第二层：输入参数

- **提示词数量**：{{PROMPT_COUNT}}
- **调整频率**：{{ADJUSTMENT_FREQUENCY}}
- **团队规模**：{{TEAM_SIZE}}
- **CI/CD 平台**：{{CI_PLATFORM}}（GitHub Actions / GitLab CI / Jenkins）
- **评测集规模**：{{TEST_CASE_COUNT}}

## 第三层：分析框架

### 3.1 Git 钩子触发的评测流水线

设计一个 pre-push 钩子，在提示词变更推送到远端前自动运行快速回归评测：

```bash
#!/bin/bash
# .git/hooks/pre-push - Prompt CI Gate
# 当 prompts/ 目录有变更时触发快速回归评测

CHANGED_PROMPTS=$(git diff --name-only HEAD refs/remotes/origin/$1 -- 'prompts/*.yaml' 'prompts/*.md')

if [ -z "$CHANGED_PROMPTS" ]; then
  echo "✅ No prompt changes detected, skipping eval."
  exit 0
fi

echo "🔍 Detected prompt changes:"
echo "$CHANGED_PROMPTS"
echo ""
echo "📊 Running quick regression eval (subset)..."

# 运行快速回归评测（子集约 20% 用例）
python scripts/run_eval.py \
  --subset quick \
  --prompts $(echo "$CHANGED_PROMPTS" | tr '\n' ' ') \
  --baseline .eval_cache/baseline_score.json \
  --output .eval_cache/quick_result.json

EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
  echo "❌ Eval pipeline failed. Push blocked."
  echo "   Review results: .eval_cache/quick_result.json"
  exit 1
fi

# 检查得分是否低于基准线
python scripts/check_gate.py \
  --result .eval_cache/quick_result.json \
  --baseline .eval_cache/baseline_score.json \
  --threshold 0.3

if [ $? -ne 0 ]; then
  echo "⚠️  Score dropped below gate threshold."
  echo "   Use --no-verify to override (requires approval)."
  exit 1
fi

echo "✅ Quick eval passed. Safe to push."
exit 0
```

### 3.2 版本命名与分支策略

设计提示词的版本命名规范和 Git 分支策略：

- **命名**：`v{major}.{minor}.{patch}`
  - major：提示词结构重写（如更换角色、改输出格式）
  - minor：调整指令、增加约束、修改示例
  - patch：修复错别字、微调措辞
- **分支**：
  - `main`：生产环境当前版本
  - `prompt/{name}/v{version}`：开发分支
  - `prompt/{name}/experiment/{description}`：实验分支

### 3.3 A/B 测试框架

设计提示词 A/B 测试配置：

```yaml
ab_test:
  name: "intent_classify_v2_vs_v3"
  start_date: "2026-05-10"
  end_date: "2026-05-17"
  traffic_split:
    control: 80    # v2 当前生产版本
    treatment: 20  # v3 新版本
  metrics:
    primary: "accuracy"       # 主要指标：准确率
    secondary: ["latency_p95", "token_cost", "user_satisfaction"]
  decision_criteria:
    min_sample_size: 500      # 最少样本数
    significance_level: 0.05  # 统计显著性水平
    min_lift: 0.05            # 最小提升幅度 5%
  auto_rollback:
    enabled: true
    trigger: "accuracy_drop > 0.1 OR error_rate > 0.05"
    action: "revert_to_control"
```

### 3.4 自动回滚条件

设计自动回滚触发条件和执行步骤：

| 触发条件 | 检测方式 | 回滚动作 | 通知 |
|---------|---------|---------|------|
| 评测得分低于前一版本 | CI 流水线 | 自动 revert + 重新部署 | 飞书 + 邮件 |
| 线上准确率连续 1 小时 < 阈值 | 监控告警 | 切回上一版本 prompt | 电话 + 飞书 |
| 新增失败用例 > 5 个 | 回归流水线 | 阻断合并，通知开发者 | CI 评论 |

### 3.5 变更记录与评审流程

设计变更记录模板和评审流程，确保每次变更可追溯。

## 第四层：反论自检

1. 如果团队成员**绕过 CI 直接修改线上 prompt**，如何发现和防止？
2. 如果评测基准线因数据分布变化而**自然漂移**，如何区分"prompt 变差"和"数据变了"？
3. A/B 测试期间如果**外部因素干扰**（如促销导致流量暴涨），如何保证结果有效？

## 第五层：输出格式

请输出：
1. Prompt CI/CD 流水线 YAML 配置（适配 {{CI_PLATFORM}}）
2. Git 钩子脚本（pre-push + commit-msg）
3. 版本命名规范文档
4. A/B 测试配置 YAML
5. 自动回滚策略配置
6. 变更记录模板（YAML 格式）