想象你是一家米其林餐厅的老板。主厨老王把每道菜的秘方都记在随身小本子上：“红烧肉：酱油三勺，糖两勺”。客人夸好，他想不起来当初怎么写下的；客人说咸，他也说不清是哪一版改的。直到你们建了一座“菜谱档案馆”：每道菜谱都有独立档案，每次改良都记下日期、作者、改动原因；想试新口味，先在实验厨房做小样，请品鉴团打分，通过才正式收录；每月新菜单发布日，所有分店同步换菜，出问题还能一键退回上个月的经典版本。 现在把角色平移过来：AI 大模型就是那位主厨，你写给它的提示词（Prompt）就是菜谱。提示词的每一句措辞都会直接影响 AI 输出的质量，它完全值得拥有和代码一样的“档案管理”。而 Git——程序员们用了二十年的版本管理工具——就是现成的“档案馆管理系统”。本文就用这个菜谱档案馆的比喻，带你从零学会用 Git 管理提示词版本：怎么建仓库、怎么改版本、怎么自动质检、怎么和代码一起发布。

岗位关联

学会用 Git 给提示词建“档案馆”，Prompt 从此可追溯、可评审、可回滚、可自动部署——这是 Prompt 工程化落地的第一步。

目录
  1. 可视化演示
  2. Git核心概念：提示词的时间机器
  3. 仓库结构设计：给提示词一个家
  4. 版本管理流程：改良有据可查
  5. CI/CD自动化：自动试菜流水线
  6. 代码审查流程：品鉴委员会把关
  7. 协同发布策略：新菜单同步上桌
  8. 仓库最佳实践：长期经营之道
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示用Git管理Prompt提示的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

用Git管理Prompt提示：Prom Prompt纳入Git管理的工 Prompt仓库结构设计 核心机制可视化 用Git管理Prompt提示整体架构与关键组件

Git核心概念：提示词的时间机器

档案馆的档案员每收到一份新菜谱，都会做两件事：给这道菜的完整成品拍一张“全景照片”，然后贴上一个档案编号。更重要的是，档案上还会记下“上一版档案的编号”。这样一来，任何一份档案都能顺着编号往前追溯——昨天、上周、甚至三个月前，这道菜分别长什么样，一目了然。

Git 干的正是这件事。你每一次 git commit（提交），就好比拍下一张“全景照片”：它保存的是当前整个仓库的完整快照，而不是“改了几行字”的补丁，同时自动生成一个唯一的哈希编号（H），并记下父提交（上一版）的编号。无数个提交串起来，就形成了一条完整的历史链。

在这个基础上，还有两个常用工具：分支（branch）和标签（tag）。分支是一个可以移动的指针，就像实验厨房里铺开的一本“试做草稿本”，你可以放心大胆地改，不影响正式菜单；标签则是给某个提交贴上的永久锚点，比如“米其林评审版 v3”。把分支合并（merge）回主分支，相当于草稿本上的成功实验被正式收编进主菜谱。

对提示词来说，这意味着你的每一条 Prompt 从诞生那天起就有了完整档案。哪一版让客服语气变生硬了？哪一版加了“分点回答”后效果最好？只要档案编号还在，随时能调出任何一天的状态。这就是 Git 给提示词带来的第一重保险。

H=SHA1(内容+父提交哈希+作者+时间戳)H = \mathrm{SHA1}(\mathrm{内容} + \mathrm{父提交哈希} + \mathrm{作者} + \mathrm{时间戳})
公式的通俗解释：提交的档案编号（H）是把“文件快照内容、上一版编号、谁改的、什么时候改的”这四样东西混在一起，经过一个固定算法（SHA1）压缩成的短字符串。任何人拿到这个编号，都能验证提交是否被篡改。
  1. H提交档案的唯一“身份证号”，只要记住它，就能从档案馆里调出这一版菜谱的完整内容。
    HH
  2. SHA1()一个“搅碎机”式的哈希函数，把任意长度的输入压缩成固定长度的十六进制串，输入有一点变化，输出就面目全非。
    SHA1(⋅)\mathrm{SHA1}(\cdot)
  3. 内容本次提交保存的完整文件快照数据——不是几行差异，而是所有文件此刻的样子，相当于菜谱的完整照片。
    内容\mathrm{内容}
  4. 父提交哈希指向上一个提交的指针，正是它把松散的单张照片串成一条可追溯的历史链条。
    父提交哈希\mathrm{父提交哈希}
  5. 作者与时间戳记录“谁在什么时候做了这次改动”，让每一次菜谱改良都能找到责任人。
    作者+时间戳\mathrm{作者} + \mathrm{时间戳}

仓库结构设计：给提示词一个家

档案馆最怕什么？所有菜谱堆在一个大箱子里，找“红烧肉”要翻半小时。所以档案馆的第一课是分类：按菜系分，再按品类分，最后按菜名编号上架。分类合理，找菜快；分类混乱，档案再全也是废纸。

Prompt 仓库同样需要稳定的目录结构。推荐的做法是：在仓库根目录下建 prompts/ 文件夹，按“领域 → 任务”逐层下钻。例如 prompts/customer-service/return-refund.md 表示“客服领域 → 退货退款任务”的提示词。文件名用短横线连接的小写单词（kebab-case），比如 booking-reminder.md，避免用 “最终版”、“真最终版” 这种让人崩溃的命名。

更重要的设计原则是“模板与示例分离”：提示词模板文件里只写指令骨架，用户输入用 {变量} 占位符代替；few-shot 示例单独放在 examples/ 目录；回归测试用例放在 tests/ 目录；根目录放一份 README.md 说明每个目录是干什么的。这样一来，提示词就变成了“可共享、可测试、可替换”的工程资产，而不是一段死死写死在代码里的字符串。

当每个提示词都住在固定的“格子”里，新成员入职第一天就能顺着目录找到需要的模板，测试代码也能自动扫描这些文件。结构化不是形式主义，它让“用代码的方式管理提示词”成为可能。

Prompt=系统指令+∑k=1n占位符k+示例+输出约束\mathrm{Prompt} = \mathrm{系统指令} + \sum_{k=1}^{n} \mathrm{占位符}_k + \mathrm{示例} + \mathrm{输出约束}
公式的通俗解释：一条合格的提示词模板，等于“告诉 AI 扮演什么角色 + 一堆等待填入的空格 + 几个示范回答 + 输出格式要求”。这四个部分就像菜谱的“开胃菜 + 主菜 + 配菜 + 装盘要求”，结构固定，内容可变。
  1. 系统指令整份模板的灵魂，定义 AI 的角色、任务目标和语气风格，相当于菜谱第一行写的“菜系与风味定位”。
    系统指令\mathrm{系统指令}
  2. Σ 占位符求和符号表示把 n 个可替换变量依次填入模板，例如 {用户问题}、{商品名称}、{订单编号}。
    ∑k=1n占位符k\sum_{k=1}^{n} \mathrm{占位符}_k
  3. 示例few-shot 样例，给 AI 几个“标准答案”作为参照，就像菜谱附上的成品照片，让新主厨知道做出来应该长什么样。
    示例\mathrm{示例}
  4. 输出约束规定回答的格式、长度、语气边界，相当于“装盘要求”——用白色圆盘、酱汁画圈、十分钟内上桌。
    输出约束\mathrm{输出约束}

版本管理流程：改良有据可查

餐厅改良菜谱分两种：一种是“大改”，比如把红烧肉彻底改成蒜泥白肉，吃法全变；一种是“小修”，比如糖从两勺减到一勺半，还是那道菜。档案馆对这两类改动的编号策略完全不同：大改要升“系列号”，小修只升“修订号”。如果全都叫“红烧肉改良版3”，厨房迟早要乱。

Git 世界把这套规则叫做语义化版本（Semantic Versioning）。一个版本号 vMAJOR.MINOR.PATCH 由三段组成：MAJOR（主版本）在提示词被不兼容地重写时增加，比如占位符全部更换、下游调用方必须改代码；MINOR（次版本）在新增能力且向后兼容时增加，比如多加了一条可选的输出格式指令；PATCH（修订版本）在修复小问题时增加，比如修正错别字、调整语气。版本号不再是随意涂改的编号，而是向所有消费者传达了“这次改动会不会影响你”的信号。

版本号之外，还要约定分支策略和提交规范。main 分支是正式菜单，永远保持可用；任何实验都在功能分支（feature branch）上进行，实验成功后再通过 Pull Request 合并回来。提交信息遵循固定格式：[类型] 一句话摘要，例如 [fix] 修正退货流程语气过于生硬、[feat] 新增商品比价指令。一旦线上出问题，git revert 会生成一个反向提交来抵消坏改动（历史保留），git reset 则直接把指针退回某个版本（历史可能抹掉）——前者适合公共分支，后者只适合本地。

有了这套规则，团队在讨论“要不要升级 Prompt 版本”时，看版本号就能快速评估风险。每一版改良都有据可查，随时能退回顾客最爱的那个经典口味——这就是版本管理流程给 Prompt 的“后悔药”。

V=MAJOR.MINOR.PATCHV = \mathrm{MAJOR} . \mathrm{MINOR} . \mathrm{PATCH}
公式的通俗解释：版本号由三段数字用点号连接，从左到右分别表示“大改级别、小改级别、微修级别”。每一段递增都遵循明确的规则，让任何人都能仅凭版本号判断改动的影响范围。
  1. V提示词版本的代号，例如 v2.1.0，贴在某个具体提交上，就像菜谱档案封面上盖的“第几版”印章。
    VV
  2. MAJOR主版本号。提示词发生不兼容重写（如占位符协议变更）时 +1，并清零后面两段；消费者看到它变化就知道必须跟着改。
    MAJOR\mathrm{MAJOR}
  3. MINOR次版本号。新增向后兼容的能力（如新增一个可选指令）时 +1；消费者看到它变化就知道“有新功能，但老用法还活着”。
    MINOR\mathrm{MINOR}
  4. PATCH修订版本号。只做修复性小改动（如修正措辞、补齐边界条件）时 +1；消费者看到它变化就知道“什么都没变，只是更稳了”。
    PATCH\mathrm{PATCH}

CI/CD自动化：自动试菜流水线

大饭店后厨有一条自动质检台：新菜谱投进去，机器自动试做、拍照、与标准图比对、打出质量分。机器不会犯困、不会因为跟主厨关系好就放水，每道菜都必须过了它这一关才能端上桌。这条流水线，就是 CI/CD 在厨房里的化身。

CI（持续集成）在 Prompt 仓库里的含义是：每次有人把改动推送到分支，服务器自动拉取最新代码，跑一组回归测试（Golden Set）。这组测试是精心挑选的固定问题集——比如客服场景下固定的 50 个典型用户问题——把新提示词填进去，调用模型生成回答，再检查回答是否覆盖了该有的关键信息。CD（持续部署）则是在 CI 通过之后，把新提示词自动发布到线上的配置中心或 Prompt 管理平台，让线上应用立即使用最新版本。

要让机器“打分”，就需要一个可量化的质量门禁：每条回归用例根据关键信息覆盖率打一个 0 到 1 的分，取所有用例的平均分 Q；只有 Q 达到阈值 T（比如 0.8），代码才被允许合并；否则推送被拦截，提交人收到失败报告。这就像质检台给每道菜拍照比对，相似度不达标就红灯报警，退回后厨重做。

机器试菜不会腻也不会漏，每份提示词改动都在推送后几分钟内收到“过/不过”的判决。CI 把质量检查前置到合并之前，CD 把发布动作自动化——这是 Prompt 工程化从“人肉管理”走向“流水线管理”的关键一步。

Q=1n∑i=1nsi,通过条件: Q≥TQ = \frac{1}{n} \sum_{i=1}^{n} s_i, \quad \text{通过条件: } Q \ge T
公式的通俗解释：把 n 条回归用例的得分（每条满分 1 分）加起来除以 n，得到平均质量分 Q。只有 Q 不低于门槛 T，这份提示词改动才被允许合入主线。用数学语言给“好不好”下了个可执行的定义。
  1. s_i第 i 条回归用例的得分。例如用例“退货流程是什么”，模型回答里提到了“退货”“7天”“运费”三个关键信息，得 3/3 = 1 分。
    sis_i
  2. n回归用例的总条数。用例集越丰富，门禁越能代表真实场景，就像试菜要覆盖冷菜、热菜、汤品而不是只尝一道凉拌黄瓜。
    nn
  3. Q平均质量分，衡量“这份提示词在典型场景下表现如何”的单一数值。
    1n∑i=1nsi\frac{1}{n} \sum_{i=1}^{n} s_i
  4. T质量门槛。阈值设得太低，劣质提示词混进来；设得太高，团队改动成本剧增，需要根据历史数据调优。
    TT

代码审查流程：品鉴委员会把关

主厨老王改良了一道新菜，他不能自己拍板说“行了，上菜单”。正经餐厅会组织品鉴委员会：两三位资深厨师各自试吃、对照评审标准打分、写下改进意见。老王按意见改完，委员会再次确认，全员点头后新菜才被正式收编。

Git 世界的品鉴委员会叫 Pull Request（PR），即“合并请求”。开发者把功能分支推送到远程后，发起一个 PR，请求把自己的改动合并进 main 分支。评审人可以在 PR 上查看 diff（差异视图）——新旧两个版本的提示词并排显示，新增的行是绿色、删除的行是红色，逐字可查——然后在具体某一行留下评论，整个过程与代码评审完全一致。

Prompt 评审不能凭感觉，要有一张审查清单：① 指令是否清晰无歧义；② 是否覆盖边界情况和异常输入；③ 占位符是否完整、能否被正确替换；④ 输出约束是否明确（格式、长度、语气）；⑤ 是否与调用它的代码逻辑耦合过深。评审人在 PR 评论区提出意见，作者修改后 push 新提交，评论标记为已解决（resolve），往复迭代直到通过。评审流程的通过条件可以量化：获得至少 2 个批准（approve）且没有未解决的阻断问题。

品鉴委员会的价值不止于把关：评审过程本身就是在给团队做知识传递。新人通过 review 老手的提示词，能快速学会“为什么这句话要这么写”。集体把关让菜谱质量稳定在“老主顾都满意”的水平线上，也让每一次 Prompt 改动都沉淀为团队的公共智慧。

R={通过,rapprove≥2  且  b=0打回,否则R = \begin{cases} \mathrm{通过}, & r_{\mathrm{approve}} \ge 2 \; \text{且} \; b = 0 \\ \mathrm{打回}, & \text{否则} \end{cases}
公式的通俗解释：这是一道“双重保险”的开关——只有同时满足“至少两位评审人点赞”和“阻断问题为零”两个条件，PR 才被放行合并；只要有一条不满足，改动就被打回重做。
  1. r_approve评审人点“批准”（Approve）的人数。一人拍板容易出错，至少两人是团队共识的底线。
    rapprover_{\mathrm{approve}}
  2. ≥ 2临界条件，表示“两个及以上资深厨师点头”，防止单人主观偏好决定菜谱走向。
    ≥2\ge 2
  3. b阻断性问题（blocker）的数量，比如“占位符 {商品名} 拼写错误会导致程序崩溃”这类必须修完才能合并的问题。
    b=0b = 0
  4. 且（∧）逻辑与，两个条件必须同时成立；就像品鉴委员会既要“多数通过”，也要“无人投反对票”。
    ∧\wedge

协同发布策略：新菜单同步上桌

每月新菜单发布日，餐厅要做的事远不止“改菜谱”：分店要同步更换后厨菜谱、前台要重印菜单、服务员要参加新菜培训、供应商要按新备料清单进货。任何一环掉队，就会出现“前台上新菜、后厨还在用旧菜谱”的混乱。这就像你改了 Prompt 却忘了更新引用了它的代码——AI 输出风格突变，而前端界面还按旧逻辑在解析。

Prompt 和代码是紧耦合的。Prompt 是“配置文件式”的资产：它不写业务逻辑，却决定生成式 AI 的输出行为；代码则负责调用模型、解析结果。两者必须统一发布节奏，否则会出现三类事故：代码更新了但 Prompt 没同步，新功能表现不符合预期；Prompt 更新了但代码没跟上，输出格式变了导致解析报错；两边都改了，但无法说清“这个版本到底是哪一套组合”。

协同发布的核心是版本对齐：每一次发布，都用一个 release 标签同时记录 Prompt 版本与代码版本的对应关系——同一个 tag 下，prompts/ 目录的版本和 src/ 目录的版本必须是配套的。同时维护 CHANGELOG（变更记录）：每条改动写明动机，例如“v2.3：新增文风指令，解决生成内容过于正式的问题”。发布时机选在流量低峰期，先灰度 10% 流量观察线上表现，一旦异常，一条命令回滚到上一个 tag——Prompt 和代码一起退回，绝不同步错位。

版本对齐让“回滚”也变成了一件简单事：线上出问题时，git checkout 到上一个双标签组合，Prompt 和代码瞬间回到上一个稳定状态。前台新菜单、后厨新菜谱、仓库新备料永远三合一，这就是协同发布策略给团队的安全感。

Ready=(Ptag=Ctag)∧(CHANGELOG≠∅)\mathrm{Ready} = (P_{\mathrm{tag}} = C_{\mathrm{tag}}) \wedge (\mathrm{CHANGELOG} \neq \varnothing)
公式的通俗解释：一次“可发布”的状态必须同时满足两个条件：Prompt 的版本标签与代码的版本标签完全一致；变更记录里写清楚了这次改了什么。两个条件缺一个，发布会就开不了。
  1. P_tag本次发布中 Prompt 仓库打上的版本标签，例如 prompts-v2.3。
    PtagP_{\mathrm{tag}}
  2. C_tag本次发布中代码仓库打上的版本标签，例如 app-v2.3。
    CtagC_{\mathrm{tag}}
  3. 相等两个标签指向同一发布批次，保证“AI 的指令”和“解析输出的程序”来自同一套配套组合。
    Ptag=CtagP_{\mathrm{tag}} = C_{\mathrm{tag}}
  4. CHANGELOG 非空发布必须附带人可读的变更记录，就像菜单更新必须附上新菜说明，否则顾客点了新菜却不知道里面有什么。
    CHANGELOG≠∅\mathrm{CHANGELOG} \neq \varnothing

仓库最佳实践：长期经营之道

档案馆建好之后不是一劳永逸。真正的档案馆有严格的借阅权限、定期的防潮检查、新档案员的培训手册。档案管理得越好，十年后这座档案馆就越值钱；管理得稀烂，它就是一个塞满废纸的储物间。

权限管理是第一条红线。main 分支要设置成受保护分支（protected branch）：任何人不能直接 push，所有改动必须通过 PR 且满足 CI 门禁和评审人数才能合入。这相当于正式菜单的“厨房重地，闲人免进”——即使主厨本人，也得走评审流程。文档维护紧随其后：README.md 说明仓库结构，CONTRIBUTING.md 写清楚提交规范、分支命名约定、评审流程，让新成员第一天就能独立贡献。

团队协作层面的实践包括：用模板统一 PR 描述（改动动机、测试结果、影响范围）；定期做评审复盘，把高频踩坑写进审查清单；用 git blame 追溯每行提示词的历史，回答“这句是谁在什么背景下加的”。最后是复用沉淀：把跨项目通用的提示词抽成公共模板库，用子模块（submodule）或独立包引入各项目，持续统计复用率，把团队最值钱的提示词资产沉淀下来。

当仓库有了权限保护、文档导航、协作规范和沉淀机制，它就不再是一个“存文件的地方”，而是团队真正的知识资产库。管理得当，十年后这座档案馆就是餐厅最值钱的家底；同样，治理良好的 Prompt 仓库，就是 AI 时代团队最核心的竞争力。

U=N复用N总U = \frac{N_{\mathrm{复用}}}{N_{\mathrm{总}}}
公式的通俗解释：复用率 U 等于“被多个项目共同使用的提示词数量”除以“仓库里提示词的总数量”。U 越高，说明提示词资产越通用、团队越少重复造轮子。
  1. N_reuse被两个及以上项目复用的提示词模板数量，相当于档案馆里“被多本菜谱引用的基础酱汁配方”。
    N复用N_{\mathrm{复用}}
  2. N_totalPrompt 仓库中提示词文件的总数量。
    N总N_{\mathrm{总}}
  3. U复用率，衡量提示词资产的通用化程度。数值越高，团队维护成本越低、一致性越好。
    N复用N总\frac{N_{\mathrm{复用}}}{N_{\mathrm{总}}}
  4. 复盘目标定期检查 U 值并识别“几乎相同却各自维护”的提示词，主动合并为公共模板，持续提升资产价值。
    U→max⁡U \rightarrow \max

AI 应用场景

客服 Prompt 的每日自动回归

阶段：Prompt 测试与部署（CI/CD 阶段）

解决的问题：客服提示词频繁优化迭代，过去靠人肉复制粘贴到线上配置平台，改坏了要等用户投诉才发现，且无法快速回滚。AI 通过 Git 接管整个链路：每次改动推送后，CI 自动跑一组固定客服问题的回归测试，质量分不达标直接拦截，达标后自动部署到线上客服系统。

具体案例：某电商团队把客服 Prompt 存入 prompts/customer-service/ 目录，GitHub Actions 监听 PR 事件，自动运行 50 条黄金用例，用评分模型检查“退货时效”“运费规则”等关键信息覆盖率。某次改动把“7 天无理由退货”误写成“3 天”，CI 红灯报警，PR 被自动打回，避免了一次线上事故。

大模型应用的 Prompt 与代码协同发版

阶段：发布管理（协同发布阶段）

解决的问题：代码更新与 Prompt 更新不同步，导致“新代码 + 旧指令”或“旧解析逻辑 + 新输出格式”的错位故障。AI 通过双标签版本对齐解决：一次发布同时打上 Prompt tag 和 Code tag，配套上线、配套回滚。

具体案例：某 AI 写作助手发布 v2.3 版本时，代码新增了“文章长度统计”功能，对应 Prompt 同步新增“输出字数约束”指令。团队在同一个 release 里记录 prompts-v2.3 与 app-v2.3 的对应关系，CHANGELOG 写明“新增文风指令，解决生成内容过于正式的问题”。上线后发现长文生成异常，一条命令回滚到 v2.2 双标签，五分钟恢复服务。

Prompt 模板库的团队复用

阶段：资产沉淀与管理阶段

解决的问题：各项目组各自维护一份“写周报 Prompt”“客服开场白 Prompt”，表达差异大、质量参差、重复造轮子。AI 通过统一仓库 + 公共模板沉淀解决：把通用提示词抽成标准模板库，按领域分层，通过 Git 子模块被多项目引用。

具体案例：某公司搭了统一 Prompt 仓库，prompts/common/ 存放通用模板（角色设定、格式化输出、安全护栏），业务组通过依赖引入。半年后仓库复用率从 22% 提升到 61%，评审清单中的高频问题从 15 条减少到 6 条，新人上手时间从两周缩短到三天。

Python 演示

python63 行
# prompt_ci_demo.py# 模拟 Prompt 仓库的 CI 质量门禁:# 对候选提示词跑回归用例, 计算平均质量分 Q, 达标才允许打标签发布 GOLDEN_CASES = [    {"query": "退货流程是什么", "keywords": ["退货", "7天", "运费"]},    {"query": "如何修改收货地址", "keywords": ["地址", "订单详情"]},    {"query": "订单多久发货", "keywords": ["发货", "48小时", "工作日"]}] QUALITY_THRESHOLD = 0.8 PROMPT_REPO = {    "v1": "你是客服助手, 请简洁回答用户问题. 用户问: {query}",    "v1.1": "你是金牌客服, 请详细分点回答, 覆盖步骤与注意事项. 用户问: {query}"}  class MockModel:    """模拟大模型: 提示词越详细, 回答越完整"""     def answer(self, prompt, query):        if "详细" in prompt:            return ("关于" + query +                    ": 请核对订单详情中的信息; 退货请在收货后7天内申请, "                    "并保留运费凭证; 工作日下单通常48小时内发货.")        if "简洁" in prompt:            return "请咨询在线客服."        return "您好, 请稍等."  def fill_prompt(template, query):    return template.replace("{query}", query)  def score_answer(answer, keywords):    hit = 0    for kw in keywords:        if kw in answer:            hit += 1    return hit / len(keywords)  def run_quality_gate(template):    model = MockModel()    scores = []    for case in GOLDEN_CASES:        answer = model.answer(fill_prompt(template, case["query"]), case["query"])        scores.append(score_answer(answer, case["keywords"]))    return sum(scores) / len(scores), scores  def main():    for version, template in PROMPT_REPO.items():        avg, scores = run_quality_gate(template)        status = "PASS" if avg >= QUALITY_THRESHOLD else "FAIL"        print("[%s] 用例得分=%s, Q=%.2f, 门禁=%s" % (version, scores, avg, status))        if status == "PASS":            print("  -> 允许打标签: git tag %s" % version)  if __name__ == "__main__":    main()
目的：实现正文中 CI 质量门禁的迷你版——对 Prompt 仓库里的候选版本跑回归用例，计算平均质量分 Q，模拟 Git 打标签动作。运行后输出 v1 被拦截、v1.1 被放行的对比结果，直观展示“提示词越详细，AI 回答越完整”。
  1. for version, template in PROMPT_REPO.items():遍历仓库里的候选提示词版本，模拟“每次推送触发一次 CI 流水线”
  2. answer = model.answer(fill_prompt(template, case["query"]), case["query"])把用户问题填进模板占位符，再交给模拟模型生成回答
  3. hit / len(keywords)计算关键信息覆盖率，这是回归打分的最小单元，相当于质检台比对“关键配料是否齐全”
  4. avg, scores = run_quality_gate(template)跑完整个回归用例集，算出平均质量分 Q 和每条用例得分
  5. status = "PASS" if avg >= QUALITY_THRESHOLD else "FAIL"质量门禁判定，相当于“平均分不到 0.8 一律打回”
  6. print(" -> 允许打标签: git tag %s" % version)门禁通过后模拟 Git 打标签动作，对应 CI 放行合并

常见误区

误区提示词就几行字，改动又频繁，用 Git 还要学命令、走流程，太麻烦。存在聊天记录或 Word 文档里，想找的时候翻一翻就行。

正解聊天记录没有版本差异对比、没有评审机制、没有回滚能力。Prompt 是直接影响线上 AI 输出的生产资产——改错一个字，客服话术就可能从“热情耐心”变成“敷衍冷淡”。Git 提供的快照追溯、分支隔离、评审门禁，恰恰是高频改动场景最需要的安全网。越是频繁改动，越需要版本管理，否则“改坏了”就是家常便饭。

为何常见：因为 Prompt 最初看起来只是“写给模型的一段话”，不像代码那样有明确的工程属性，人们天然低估它的影响面。

误区我们团队就三五个人，改 Prompt 很快，直接 push 到 main 分支改完就生效，开分支走 PR 太耽误事。

正解直接改 main 等于把实验厨房和正式菜单混在一起——任何实验性改动都会立即影响线上用户。分支策略的本质是“隔离风险”：功能分支上随便折腾，CI 和评审把关通过后，才把结果合入受保护的 main。哪怕只有一个人，用分支 + 合并也能让你随时回答“线上跑的是哪一版”，而不是“应该是刚才那版吧”。

为何常见：这是个人项目时代养成的习惯——一个人用 Git 时，直接改 main 确实省事，但团队协作场景下风险立刻被放大。

误区AI 生成是开放式的，同一句提示词每次输出都不一样，机器怎么可能打分？所以 CI 门禁对 Prompt 根本派不上用场。

正解面向业务场景，AI 输出是可以做“定向质检”的：设计固定回归问题集，检查回答是否覆盖了关键信息、是否符合格式约束、是否触发安全红线——而不是评“文学性好不好”。就像质检员不评价菜“好不好吃”这种主观项，只检查“熟没熟、咸没咸、分量够不够”这些可量化的标准。文中公式 Q = (1/n)Σsᵢ ≥ T 就是这种可执行的质量门禁。

为何常见：把“AI 输出评估”想象得过于玄学，忽略了可以在约束边界内建立客观测量标准。

误区Prompt 迭代这么快，版本号只是用来区分先后的标记，写 v1、v2，或者干脆写 latest 就行，反正自己知道是哪个。

正解无规则的版本号无法表达“兼容性语义”。语义化版本 vMAJOR.MINOR.PATCH 是在向所有下游消费者传达信号：MAJOR 变了说明要改代码、MINOR 变了说明有新能力、PATCH 变了说明只是更稳了。你的 Prompt 被多个服务、多个人引用时，一个规范的版本号能让所有人快速评估升级风险。写 "latest" 等于放弃了这个沟通工具。

为何常见：受日常文件命名习惯影响（“最终版”“最终版2”），没有意识到版本号是团队之间的“通信协议”。

面试题

Q1. Git 提交（commit）本质上是为仓库保存了什么？

单选题 · easy

  • A.只有文件变动的修补数据
  • B.一次完整的文件状态快照← 正确答案
  • C.文件的最新完整备份
  • D.所有历史文件的打包合集

答案：B。每次 commit 保存的是整个仓库的完整快照，并通过父提交指针串成链条，绝不是只存“改了几行”的补丁（那是 diff 的概念）。就像档案馆给每版菜谱拍一张完整全景照片，而不是只记录“这版少了半勺糖”。C 的错误在于“最新备份”暗示只保留一份，而快照是逐次完整保留的。

Q2. 打标签（tag）在 Prompt 版本管理中的作用相当于什么？

单选题 · easy

  • A.每天自动执行一个备份
  • B.把某版本标记为正式获批← 正确答案
  • C.删除旧版本并重新归档
  • D.创建一条全新的开发分支

答案：B。tag 是贴在某个提交上的永久锚点，用来标记“这是可发布的正式版本”，比如评审通过的 v1.3。它不像分支那样会随着新提交移动。A 说的是定时任务，C 是删除操作，D 是 branch 的功能，都与 tag 的本质不符。

Q3. 语义化版本 v2.1.0 中，MINOR 版本号（1）应该在哪类改动后增加？

单选题 · mid

  • A.提示词重写且占位符全部变更
  • B.修复错别字和语气等小问题
  • C.新增兼容旧调用方的能力← 正确答案
  • D.只修改了文档说明与注释

答案：C。MINOR 在“新增能力且向后兼容”时递增，比如新增一个可选的输出格式指令，旧调用方不受影响。A 属于不兼容重写，应升 MAJOR；B 属于修复，应升 PATCH；D 属于文档改动，通常连版本号都不用动。

Q4. 质量门禁 Q = (s1+……+sn)/n ≥ T 的目的在于什么？

单选题 · mid

  • A.防止提示词文件被过度膨胀
  • B.保证回归用例平均分达标才合并← 正确答案
  • C.让模型生成更长的回答内容
  • D.统计提示词被使用总次数

答案：B。该公式先把每条回归用例得分相加，再除以用例总数得到平均质量分 Q，只有 Q 不低于阈值 T 才允许合并，这是 CI 自动拦截的依据。A 与文件体积无关，C 与回答长度无关，D 与使用统计无关。

Q5. 关于 Prompt 仓库的目录设计，推荐做法有哪些？

多选题 · mid

  • A.按领域与任务进行分层组织← 正确答案
  • B.模板与示例文件分开存放← 正确答案
  • C.全部平铺在一个根目录下
  • D.用 README 说明目录用途← 正确答案

答案：ABD。优秀仓库按“领域 → 任务”分层（如 prompts/customer-service/return-refund.md），模板与示例、测试分离，并用 README 做导航。C 的平铺结构在提示词数量增长后会迅速失控，是典型反面教材。

Q6. 用 git revert 恢复某个提交，与 git reset 的主要区别是什么？

单选题 · mid

  • A.两者都会删除历史提交记录
  • B.新增反向提交保留历史← 正确答案
  • C.与 reset 的效果完全相同
  • D.只针对远程分支才有效

答案：B。git revert 会生成一个“反向提交”来抵消坏改动，历史链条完整保留，适合公共分支；git reset 是直接移动分支指针回到过去某个提交，可能抹掉后续历史，只适合本地。A 恰好说反，C 说两者相同，D 说 reset 只对远程有效，都错。

Q7. Prompt 代码审查（Review）的检查清单应包含哪些内容？

多选题 · hard

  • A.占位符完整且能正确替换← 正确答案
  • B.覆盖边界情况与异常输入← 正确答案
  • C.提示词读起来足够押韵
  • D.输出约束明确包含格式← 正确答案

答案：ABD。Prompt 评审关注工程质量：占位符能否被正确替换、边界输入是否会导致模型输出崩溃、输出格式约束是否清晰可解析。C 的“押韵”是审美要求而非工程标准，不属于检查清单的必查项。

Q8. Git 分支（branch）在“菜谱档案馆”比喻中最接近什么？

单选题 · easy

  • A.菜谱的最终印刷份数
  • B.实验厨房里独立试做版本← 正确答案
  • C.档案馆门的备用钥匙
  • D.菜谱目录的检索索引

答案：B。分支是一个可移动的指针，指向某个提交，让你在独立副本上大胆实验，不影响正式菜单——这正是“实验厨房”的角色。A 是复制品概念，C 是权限概念，D 是索引概念，都不对。

Q9. Prompt 与代码协同发布时，需要对齐的内容包括哪些？

多选题 · hard

  • A.提示词与代码的版本标签← 正确答案
  • B.变更记录中的改动说明← 正确答案
  • C.用户的每日访问量统计
  • D.发布时机与灰度策略← 正确答案

答案：ABD。协同发布要做到“双标签对齐 + 变更记录齐全 + 低峰期发布 + 灰度观察”，这样回滚时 Prompt 和代码能一起退回。C 的访问量统计是发布后观察指标，不属于发布前需要对齐的内容。

Q10. 仓库保护分支（protected branch）的核心作用是什么？

单选题 · mid

  • A.只允许管理员查看提交日志
  • B.只允许通过评审的改动合入← 正确答案
  • C.会自动清理所有历史分支
  • D.阻止任何人推送任何代码

答案：B。受保护分支（通常设在 main）禁止直接 push，所有改动必须通过 PR、满足 CI 门禁和评审人数要求才能合入。它的目的是“把关”而不是“禁止”。A 说的是权限查看，C 说分支清理，D 说完全禁止推送——都与保护分支的真实用途不符。