0Pricing
AI Prompt Engineering · 课时

提示词的版本控制

用于提示词的 Git 风格版本控制、语义化版本和变更日志管理。

提示词的版本控制 是 CoddyKit 上的免费 AI Prompt Engineering 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 AI Prompt Engineering 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 AI Prompt Engineering 课程共包含 4 节课。

为什么要对提示词进行版本控制?

提示词会持续演进——措辞上的微小变化就可能显著改变模型行为。没有版本控制,团队就无法追踪改了什么、何时改的以及为什么改。像对待代码一样对待提示词,可以获得历史记录、rollback、协作和变更归因。

基于 Git 的提示词版本管理

将提示词文件存储在 Git 中是最简单的版本管理策略。每个提示词都是纯文本文件;Git 提交记录每一次变更。分支代表实验,标签标记生产版本。

# Initialize a prompt repo
git init prompt-library
cd prompt-library
mkdir -p prompts/summarize-article

# First version
cat > prompts/summarize-article/prompt.txt << 'PROMPT'
Summarize the article in {num_sentences} sentences.

Article:
{article_text}
PROMPT

git add prompts/summarize-article/prompt.txt
git commit -m 'feat(summarize-article): initial prompt v1.0.0'
git tag v1.0.0

# Experiment on a branch
git checkout -b experiment/add-focus-area
# ... edit prompt ...
git commit -m 'feat(summarize-article): add focus_area variable'
git tag v1.1.0-rc1

提示词的语义版本管理

采用适用于提示词语义的语义版本管理(MAJOR.MINOR.PATCH):

  • PATCH(1.0.0 → 1.0.1):修正拼写错误、修改空白字符——输出不变
  • MINOR(1.0.0 → 1.1.0):新增可选变量、改进措辞——向后兼容
  • MAJOR(1.0.0 → 2.0.0):新增必需变量、改变输出格式、产生不兼容的行为变化
# semver.py — helper to validate version bumps
import re

def parse_semver(v):
    m = re.match(r'^(\d+)\.(\d+)\.(\d+)$', v)
    if not m:
        raise ValueError(f'Invalid semver: {v}')
    return tuple(int(x) for x in m.groups())

def classify_bump(old, new):
    o = parse_semver(old)
    n = parse_semver(new)
    if n[0] > o[0]:
        return 'MAJOR'
    elif n[1] > o[1]:
        return 'MINOR'
    elif n[2] > o[2]:
        return 'PATCH'
    else:
        raise ValueError('New version must be greater than old')

print(classify_bump('1.0.0', '1.1.0'))  # MINOR
print(classify_bump('1.1.0', '2.0.0'))  # MAJOR
print(classify_bump('2.0.0', '2.0.1'))  # PATCH

变更日志格式

每个提示词版本都应有结构化的变更日志,以便团队了解改了什么以及为什么改。请采用适用于提示词的“保持变更日志”格式。

# CHANGELOG.md for prompts/summarize-article/

## [2.0.0] - 2024-08-10
### Breaking Changes
- Renamed variable 'text' to 'article_text' (update all call sites)
- Output now always includes a headline sentence before the summary

### Changed
- Improved instruction specificity to reduce hallucination rate by ~12%

## [1.1.0] - 2024-07-01
### Added
- New optional variable 'focus_area' to direct summary emphasis
- Fallback instruction when 'focus_area' is not provided

### Changed
- Reworded opening instruction for clarity

## [1.0.0] - 2024-06-01
### Added
- Initial prompt: basic summarization with 'num_sentences' control

为生产版本添加标签

Git 标签标记部署到生产环境的确切提交。请使用带注释的标签,将版本说明与标签一同存储。这样就能轻松准确地重建任意时间点处于上线状态的提示词。

# Annotated git tag with release notes
git tag -a v2.0.0 -m 'Release 2.0.0

Breaking: renamed variable text -> article_text
Improved: reduced hallucination rate by 12%
Author: alice@company.com
Reviewed-by: bob@company.com'

# Push tags to remote
git push origin --tags

# List all tags with dates
git tag -l --sort=version:refname -n9
# v1.0.0  Initial prompt
# v1.1.0  Add focus_area variable
# v2.0.0  Release 2.0.0 — Breaking: renamed variable ...

# View exact prompt at a tag
git show v1.1.0:prompts/summarize-article/prompt.txt

rollback 流程

当新提示词版本导致质量回归时,rollback 必须快速完成。有两种策略:代码 rollback(重新部署旧制品)和注册表 rollback(无需重新部署即可切换 is_active 标志)。

# Strategy 1: Registry rollback (fastest — no redeploy needed)
def rollback_prompt(registry, prompt_id, target_version):
    print(f'Rolling back {prompt_id} to {target_version}...')
    registry.activate_version(prompt_id, target_version)
    print(f'Rollback complete. {prompt_id} now serving {target_version}')

# Strategy 2: Git-based rollback with audit trail
# Create a revert commit (do NOT force-push, keep history clean)
git revert HEAD --no-commit   # stage the revert
git commit -m 'revert(summarize-article): roll back to v1.1.0 due to quality regression'
git tag v2.0.1-hotfix

# Then trigger re-deployment of the reverted artifact
# This preserves full history — nobody loses track of what happened

提示词差异工具

审查提示词变更需要专门的差异工具。纯文本可以使用 git diff,但语义差异工具能够突出显示变量和指令的结构变化。

# prompt_diff.py — highlight variable changes between versions
import re

def extract_variables(template):
    return set(re.findall(r'\{(\w+)\}', template))

def diff_prompts(old_template, new_template):
    old_vars = extract_variables(old_template)
    new_vars = extract_variables(new_template)
    added = new_vars - old_vars
    removed = old_vars - new_vars
    kept = old_vars & new_vars

    print('Variables added:', added or 'none')
    print('Variables removed:', removed or 'none')
    print('Variables kept:', kept)

    old_lines = set(old_template.splitlines())
    new_lines = set(new_template.splitlines())
    print('New lines:', new_lines - old_lines)
    print('Removed lines:', old_lines - new_lines)

old = 'Summarize in {num_sentences} sentences.\n\n{text}'
new = 'Summarize in {num_sentences} sentences focused on {focus_area}.\n\n{article_text}'
diff_prompts(old, new)

提示词实验的分支策略

请将软件开发的分支约定应用于提示词开发:

  • main — 仅包含可用于生产的提示词
  • experiment/<name> — 开发中的 A/B 测试变体
  • hotfix/<issue> — 生产环境的紧急修复
  • release/<version> — 发布候选版本的暂存

在将提示词变更合并到 main 之前,要求进行代码审查(拉取请求)——就像应用程序代码一样。

# Typical prompt development workflow

# 1. Create experiment branch
git checkout -b experiment/tone-formal

# 2. Edit and test prompt locally
python test_prompt.py --prompt prompts/summarize-article/prompt.txt \
                      --eval-set evals/summarize-100.jsonl

# 3. Open PR with eval results in description
gh pr create --title 'experiment: formal tone improves ROUGE by 8%' \
             --body 'Eval results attached. ROUGE-L: 0.61 -> 0.66'

# 4. After approval, merge and tag
git checkout main && git merge experiment/tone-formal
git tag v1.2.0 && git push origin main --tags

自动化版本验证 CI

用于提示词变更的 CI 流程应自动验证:语义版本升级是否正确、变更日志是否已更新、模板中的所有变量是否都有文档说明,以及 eval 得分是否出现回归。

# .github/workflows/prompt-ci.yml
# name: Prompt Validation
# on: [pull_request]
# jobs:
#   validate:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - name: Check semver bump
#         run: python scripts/check_semver.py
#       - name: Validate template syntax
#         run: python scripts/validate_templates.py
#       - name: Run eval suite
#         run: python scripts/run_evals.py --threshold 0.95

# scripts/validate_templates.py
import glob, json, sys

errors = []
for f in glob.glob('prompts/**/*.yaml', recursive=True):
    with open(f) as fh:
        data = fh.read()
    if '{' not in data:
        errors.append(f'{f}: no variables found (may be intentional — double check)')

if errors:
    print('Warnings:', errors)
print('Template validation complete')

带标签版本的不可变性

一项核心原则是:带标签的版本不可变。一旦为 v2.0.0 添加标签,其模板就绝不能再更改。修复应进入新版本(v2.0.1)。这能保证可复现性——您始终可以根据标签重建完全一致的生产状态。

# Enforce immutability in the registry
def register(self, prompt_id, version, template, ...):
    with self.conn.cursor() as cur:
        # Check if version already exists
        cur.execute(
            'SELECT id FROM prompt_versions '
            'WHERE prompt_id=%s AND version=%s',
            (prompt_id, version)
        )
        if cur.fetchone():
            raise ValueError(
                f'Version {version} of {prompt_id} already exists. '
                'Versions are immutable. Create a new version instead.'
            )
        # Proceed with insertion
        cur.execute(
            'INSERT INTO prompt_versions '
            '(prompt_id, version, template, author, tags, model) '
            'VALUES (%s, %s, %s, %s, %s, %s)',
            (prompt_id, version, template, author, tags, model)
        )
    self.conn.commit()

将提示词与评估结果关联

每个提示词版本都应关联其评估结果,以便团队比较不同版本之间的质量。请将 eval 元数据与提示词制品一同存储。

# Attach eval results to a prompt version
ALTER TABLE prompt_versions ADD COLUMN eval_results JSONB;

# Python: record eval scores
def attach_eval_results(self, prompt_id, version, results):
    with self.conn.cursor() as cur:
        cur.execute(
            'UPDATE prompt_versions SET eval_results=%s '
            'WHERE prompt_id=%s AND version=%s',
            (json.dumps(results), prompt_id, version)
        )
    self.conn.commit()

# Example eval results structure
eval_results = {
    'dataset': 'cnn-dailymail-100',
    'date_run': '2024-08-10',
    'metrics': {
        'rouge_l': 0.66,
        'bertscore_f1': 0.89,
        'human_quality_avg': 4.2
    },
    'sample_size': 100,
    'runner': 'alice@company.com'
}
registry.attach_eval_results('summarize-article', '1.2.0', eval_results)

快速检查

什么时候应该提升提示词的 MAJOR 版本?

版本控制总结

提示词版本控制借鉴了软件版本控制,并针对提示词进行了调整:

  • 语义版本管理:PATCH/MINOR/MAJOR 表示变更影响
  • Git 标签:用于生产版本的不可变带注释标签
  • 变更日志:按版本组织的结构化历史记录,便于审计
  • Rollback:切换注册表标志(快速)或执行 git revert(可审计)
  • CI 验证:自动执行语义版本检查、模板验证和评估回归防护
  • 不可变性:带标签的版本永不更改——修复总是创建新版本

常见问题解答

「提示词的版本控制」课时是免费的吗?

是的 — 「提示词的版本控制」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 AI Prompt Engineering 课程的其余内容,请升级到 CoddyKit PRO。 AI Prompt Engineering 课程共包含 4 节课。

「提示词的版本控制」这节课中我会学到什么?

用于提示词的 Git 风格版本控制、语义化版本和变更日志管理。 你通过在浏览器中直接运行的动手代码来练习 AI Prompt Engineering,全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 AI Prompt Engineering 需要有经验吗?

无需任何先前经验。CoddyKit 上的 AI Prompt Engineering 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。

「提示词的版本控制」课时需要多长时间?

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。

我能在这节 AI Prompt Engineering 课中编写并运行代码吗?

能。每节 AI Prompt Engineering 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 提示词注册表架构
  2. 提示词的版本控制
  3. 部署与回滚策略
  4. 监控生产环境中的提示词表现
← 返回 AI Prompt Engineering