Prompt工程团队协作Code Review工程规范

AI 应用 Prompt 工程化协作流程：从个人技巧到团队规范

2026-09-07 · 约 11 分钟阅读

"Prompt 是某位工程师在自己笔记本上写的，没人知道长什么样、改了什么、效果怎么样。"——这是大多数团队 AI 应用的真实状态。Prompt 在生产环境里其实就是"代码"，但它没有 Code Review、没有版本管理、没有测试、没有 owner。本文讲怎么把 Prompt 工程从"个人技艺"升级为"团队规范"。

一、为什么 Prompt 必须工程化

很多团队的 Prompt 演进过程：

阶段1: 工程师 A 在自己电脑的 notes.txt 里写了一段 Prompt
阶段2: A 把 Prompt 复制到代码里，跑通了
阶段3: 业务上线，Prompt 改了几十次，每次都是群里说一声
阶段4: 出问题了，回滚都不知道 Prompt 上一个版本长什么样
阶段5: A 离职了，没人能接手这块 Prompt 的维护

这是典型的"没有工程化的代码债"。后果包括：

  • 改 Prompt 不敢上线，怕出问题回不去
  • 多人改同一段 Prompt，互相覆盖
  • Prompt 质量参差不齐，新人接手完全靠口口相传
  • 评测效果无法对比，每个版本"感觉差不多"

工程化的目标是让 Prompt 像业务代码一样：有规范、有评审、有版本、有测试、有 owner。

二、Prompt 的标准化结构

团队里每个 Prompt 都应该用统一结构存储，避免"一段散文"式的 Prompt：

# prompts/customer_service/main.yaml
meta:
  name: customer_service_main
  version: v2.3.1
  owner: "@zhangsan"
  description: "客服主对话 Prompt，处理 80% 标准咨询"
  last_review: "2026-08-15"
  reviewers: ["@lisi", "@wangwu"]

model:
  preferred: gpt-5.6-sol
  fallback: claude-opus-5
  temperature: 0.3
  max_tokens: 1024

system: |
  你是 {{ company_name }} 的智能客服助手，名字叫 {{ bot_name }}。
  严格遵循以下规则：
  1. 只能基于"已知信息"回答，禁止编造产品参数、价格、活动
  2. 用户情绪激动时先共情，再解决问题
  3. 退款/投诉类问题必须转人工（返回 structured_intent: transfer_to_human）
  4. 回答控制在 200 字以内，超过则分点列出

context:
  known_info: |
    - 公司：{{ company_name }}
    - 产品：XX 智能音箱
    - 价格：¥299 - ¥999
    - 退换货政策：7 天无理由，15 天质量问题

few_shots:
  - user: "我的音箱充不进去电"
    assistant: "请先尝试用原装充电线 + 18W 以上充电器充电 2 小时。如果仍无效，我帮你安排售后检测。"
  - user: "你们双 11 打折吗？"
    assistant: "目前没有双 11 活动，但会员日每周三有专属折扣。"

好处：

  • 可读性强：新人 5 分钟理解 Prompt 是干嘛的
  • 可配置：变量化字段（company_name、bot_name）让同一份 Prompt 复用到多个客户
  • 可测试：YAML 结构可以直接解析跑自动化评测
  • 可追溯：meta 字段记录 owner、reviewer、版本

三、Prompt 的 Code Review 清单

Prompt 不是"改一个字都行"，也不是"改一个字都要走 3 轮评审"，关键是要看改了哪里、为什么改、效果如何。建议的 PR 模板：

## Prompt 改动说明

### 改动文件
- [ ] `prompts/customer_service/main.yaml`
- [ ] `prompts/customer_service/changelog.md`

### 改动类型
- [ ] 修复问题（线上客诉/评测分数下降）
- [ ] 优化体验（提升评测分数 / 用户满意度）
- [ ] 适配新场景（新增业务线 / 新用户群体）
- [ ] 重构（不改效果，只改结构）

### 改动原因
（为什么要改？是什么数据/反馈触发的这次改动？）

### 改动内容
（具体改了哪些段落/规则？请贴出 diff）

### 评测结果
| 指标 | 改动前 | 改动后 | 变化 |
|------|--------|--------|------|
| Pass Rate | 92% | 95% | +3% |
| 平均成本 | ¥0.045 | ¥0.038 | -16% |
| 用户点赞率 | 78% | 84% | +6% |

### Checklist
- [ ] 已在 golden set 上跑过离线评测
- [ ] 已和上版本对比，质量不退化
- [ ] Changelog 已更新
- [ ] 至少 1 位 Prompt 评审人 approve
- [ ] 配置了灰度比例（5% → 25% → 100%）

四、Prompt 评审人的角色

建议团队里至少有 2 类 Prompt 评审人：

角色关注点谁来当
业务评审Prompt 输出是否符合业务规则、品牌调性PM、运营、客服主管
技术评审Prompt 结构是否合理、可测试、无歧义资深工程师、Tech Lead

业务评审比技术评审更重要——因为 Prompt 的"对错"主要看业务效果，而不是看代码格式。

五、Prompt 的版本管理与回滚

Prompt 的版本管理走 Git（参考 CI/CD 流水线设计），关键是配套回滚 SOP：

# 紧急回滚：切到上一个稳定版本
python scripts/prompt_rollback.py \
  --prompt customer_service_main \
  --to-version v2.3.0 \
  --reason "线上客诉激增，回滚上一版本"

# 一键发布新版本（带灰度）
python scripts/prompt_deploy.py \
  --prompt customer_service_main \
  --version v2.4.0 \
  --canary-pct 5,25,50,100 \
  --dwell-minutes 30

每次 Prompt 改动都应该在 changelog.md 留痕：

## v2.3.1 (2026-08-15)
- 调整规则 3："退款问题转人工" → "退款/投诉类问题转人工"
- 原因：投诉场景误识别率高
- 效果：人工接管准确率 +5%

## v2.3.0 (2026-08-01)
- 新增 few-shot：双 11 活动场景
- 评测 pass rate：92% → 95%

六、Prompt 的 A/B 测试

团队里多人对"哪个 Prompt 更好"经常意见不一致，靠讨论是没用的，靠 A/B 测试：

# 简单的 Prompt A/B 测试（按用户 ID 哈希分流）
PROMPT_VERSIONS = ["v2.3.0", "v2.3.1"]

def pick_prompt_version(user_id: str) -> str:
    bucket = hash(user_id) % 100
    return "v2.3.1" if bucket < 50 else "v2.3.0"  # 50/50 分流

def handle_request(user_id, message):
    version = pick_prompt_version(user_id)
    prompt = load_prompt("customer_service_main", version=version)

    response = call_llm(prompt, message, user_id=user_id)

    # 记录效果指标
    log_ab_result(
        user_id=user_id,
        prompt_version=version,
        message=message,
        response=response,
        latency=response.latency,
        cost=response.cost,
    )
    return response

跑 1-2 周后看数据：

SELECT
  prompt_version,
  COUNT(*) AS n,
  AVG(quality_score) AS avg_quality,
  AVG(cost) AS avg_cost,
  SUM(CASE WHEN thumbs_up THEN 1 ELSE 0 END)::float / COUNT(*) AS thumbs_rate
FROM ab_test_results
WHERE prompt_version IN ('v2.3.0', 'v2.3.1')
  AND created_at >= NOW() - INTERVAL '14 days'
GROUP BY prompt_version;

数据说了算，不靠拍脑袋。

七、Prompt 知识沉淀：避免"一个人走了就崩"

团队最怕的是"Prompt 专家"离职后没人能接手。建议建立三层知识沉淀：

1. 仓库内的 Changelog

每个 Prompt 文件配套 changelog.md，记录每次改动的原因和效果。

2. 仓库内的 ADR（架构决策记录）

对于重大 Prompt 决策（比如"为什么选 GPT-5.6 而不是 Claude"），单独写一份 ADR：

# ADR-007: 客服主对话 Prompt 选用 GPT-5.6 Sol 而非 Claude Opus 5

## 状态
已采纳 (2026-07-01)

## 背景
客服场景需要在"中文理解"、"成本可控"、"延迟稳定"三个维度平衡。

## 决策
主对话 Prompt 默认使用 GPT-5.6 Sol（输入 ¥2.5/百万 tokens）。

## 备选方案
- Claude Opus 5：中文略弱，成本 6 倍
- Gemini 3.1 Pro：成本接近 GPT-5.6，但延迟波动较大

## 后果
- 单次对话成本：¥0.038
- 每月预计总成本：¥45,000（按 100 万次/月）

3. 团队 Wiki：Prompt 工程实践手册

把团队共识写成 Wiki：

  • Prompt 编写规范（结构、命名、变量命名）
  • 评审流程（谁审、审多久、什么必须评审）
  • 评测方法（golden set 怎么维护、A/B 怎么跑）
  • 常见反模式（"Prompt 里有敏感信息"、"Prompt 没说清楚边界"）

新人入职先读 Wiki，3 天就能上手改 Prompt。

八、Prompt 协作的反模式

  • ❌ Prompt 只在某个工程师脑子里：没有文档、没有 owner
  • ❌ Prompt 改完不评测直接上线：靠"我觉得变好了"上线
  • ❌ 没有回滚机制：Prompt 改坏了只能紧急发版修
  • ❌ 多个版本并行不收敛：v1.0 和 v2.0 同时在生产跑，没人知道哪份是主版本
  • ❌ Prompt 评审只看代码不看效果：改了文字但没跑评测就合并

九、总结

Prompt 工程化的本质是把"个人技艺"变成"团队工程实践"——和传统软件工程一样，写代码、Code Review、版本管理、自动化测试、CI/CD、回滚 SOP 一样都不能少。短期看是增加流程成本，长期看是让团队的 Prompt 资产可积累、可传承、可放心迭代。

想了解 Prompt 进阶技巧本身，可以看 AI API Prompt 工程进阶实战；要了解 A/B 测试和评测框架的搭建，可以看 AI 应用 A/B 测试与效果评估框架。要选用稳定的中转 API 来跑团队评测流水线，可以去 openairouter.net 比较各家平台的多模型支持与延迟。

找到最适合你的 AI API 中转站

收录 125+ 服务商，按价格、模型、标签一键筛选

查看所有中转站 →
← 返回所有教程