关键要点
- Prompt治理 = 角色（作者、审查员、批准人）+ 审查门控（自动测试、同行审查、安全扫描）+ 回滚程序
- Prompt会悄无声息地失败——治理能提供部署前后的可见性
- 最少三道门控：自动回归测试（≥90%通过率）、同行审查、安全扫描
- 在出事之前设置好回滚：版本标签、指向标签的部署配置、值班人员的访问权限
- 审计记录必须记录谁、改了什么、何时、为何，以及门控结果——这正是NIST AI RMF所建议、EU AI Act对高风险系统的记录保存规则所期望的可追溯性
- 把系统Prompt和链式Prompt的每一步都当作独立的、有版本、有负责人的资产
- 在企业规模下，通过工具强制执行角色（受保护的生产标签、分支保护），而不是依赖约定
- EU AI Act时间表：附件三（Annex III）高风险义务已从2026年8月2日推迟至2027年12月2日
- 最小可行栈：Git + Braintrust、Langfuse或Promptfoo。随着团队规模和流量增长，再加入Prompt管理平台
Prompt治理是什么及其重要性
📍 In One Sentence
Prompt治理是控制哪些Prompt进入生产环境以及上线后如何监控的角色、审查门控和部署规则体系。
💬 In Plain Terms
没有治理，Prompt变更是不可见的——没有谁改了什么的记录，出问题时无法回滚，输出质量悄然下降时也没有警报。
Prompt治理是控制哪些Prompt进入生产环境、谁可以修改它们以及失败时如何处理的体系。 它涵盖三个领域：访问控制（谁可以编写、审查和批准Prompt）、部署流程（上线前必须通过哪些测试）和事件响应（如何检测、诊断并回滚失败的Prompt）。
治理不是为了官僚而官僚。它之所以存在，是因为Prompt会悄无声息地失败。当Prompt变更导致输出质量下降时，没有错误日志、没有异常、没有警报——输出只是变差了。没有治理，团队往往要花数天去排查一处单行Prompt改动引起的质量回归。
当Prompt影响面向用户的功能、受监管的输出（法律、医疗、金融）或高流量自动化工作流时，请使用治理体系。内部的、低风险的一次性Prompt则无需正式治理。
⚠️ 静默失败
导致质量下降的Prompt变更不会产生错误、异常或警报。只能通过用户投诉或监控发现问题——两者都发生在损害已经造成之后。
谁拥有Prompt？3角色所有权模型
对大多数团队来说，三个角色足以覆盖Prompt治理：作者（Author）、审查员（Reviewer）和批准人（Approver）。 每个角色职责不同，各自拥有独立的否决点。
- 作者：编写Prompt，运行初始质量测试，提交审查。对功能正确性负责。
- 审查员：检查质量、合规性和安全性。在受监管领域（法律、医疗、金融），审查员必须具备领域专业知识。对于涉及安全的Prompt，审查中必须包含红队检查。
- 批准人：批准或拒绝部署到生产环境。无论审查员是否签字，都有单方面阻止发布的权力。
对高流量的生产Prompt，增设Prompt负责人（Prompt Owner）角色。Prompt负责人对该Prompt在其运行的每个模型系列和版本（例如OpenAI GPT、Anthropic Claude、Google Gemini）上的线上表现负责，并在事件发生时担任第一联系人。
避免由同一个人同时担任作者和批准人。自己批准自己的Prompt，会跳过能发现错误的独立检查。如果团队太小，无法设置三个独立角色，至少要求在任何Prompt进入生产环境之前，由另一个人签字确认。
📌 3角色模型的实际做法
作者-审查员-批准人的分离，对应软件开发中的代码审查：写代码的人不能自己批准自己的拉取请求（pull request）。同样的原则也适用于Prompt。
Prompt部署前必须通过的审查门控
Prompt在进入生产环境之前，必须至少通过三道门控：自动质量测试、同行审查和安全扫描。 每道门控只有两种结果——通过或阻止。没有例外。
- 门控1 — 自动测试：Prompt必须以 ≥ 90% 的通过率通过回归测试套件（黄金测试集 + 边界用例）。使用Braintrust或Promptfoo运行。测试失败会自动阻止部署。
- 门控2 — 同行审查：由审查员对质量和合规性签字确认。审查清单包括：任务完整性、格式合规、安全约束和模型相关行为（至少在你部署的两个模型系列上测试，例如OpenAI GPT和Anthropic Claude）。
- 门控3 — 安全扫描：检查注入向量、越狱易感性和敏感数据泄露。对没有用户输入的纯内部Prompt，该门控可简化为清单审查。对处理用户输入的Prompt，应运行自动化注入测试。
对于受监管领域，增加门控4 — 合规审查。由合格的领域专家确认Prompt输出符合适用标准（HIPAA、GDPR、SOC 2等）。该门控无法自动化。
在Prompt的变更日志中记录每道门控的结果。如果门控2被阻止后重新提交，必须记录最初被阻止的原因和解决办法。审计人员会查看这条记录。
💡 自动化门控1
门控1（自动测试）应当在每次提交时运行，而不仅仅是在部署前。在提交时发现回归只需几分钟修复；到部署时才发现则需要数小时。
如何回滚生产环境中失败的Prompt
如果版本控制已提前配置好，Prompt回滚应该在5分钟内完成。 回滚程序分四步：检测（监控警报或用户报告）、定位（哪个Prompt版本导致了回归）、还原（将部署配置指回之前的版本标签）和确认（验证输出质量已恢复）。
请在出事之前设置好回滚，而不是在事件发生时才动手。最小可行设置：
- 每个已部署的Prompt都有版本标签：v1.0、v1.1等
- 部署配置引用标签，而不是直接引用文件
- 保留之前3个版本，无需额外测试即可部署
- 值班人员无需经理批准即可写入部署配置
回滚之后，将事件作为事后复盘处理。记录：改了什么、什么失败了、多久才发现、多久才解决，以及哪道门控本应拦住它。更新审查清单，防止再次发生。
没有输出监控，用户往往是第一个发现回归的人。请在生产栈中加入输出质量监控：Braintrust和Langfuse等工具可以用与门控1相同的标准对生产流量打分，你还可以在监控栈中设置告警阈值。
审计记录：需要记录什么及为何记录
Prompt的审计记录必须包含：谁修改了Prompt、改了什么、何时、为何（变更理由），以及通过了哪些审查门控。 这是支持可追溯性和文档记录的最低记录要求——自愿性的NIST AI RMF对此提出建议，EU AI Act对高风险AI系统也有此期望。
将审计记录存放在与Prompt相同的版本控制系统中。小团队用Git提交信息即可。Langfuse等Prompt管理平台会自动保存不可变的版本历史；请确认你使用的方案是否也记录审查员签字，如果没有，就把签字保存在Git或工单系统中。
使用统一的提交格式：
- 作者：姓名
- 审查员：姓名 — 批准/拒绝
- 变更：变更内容的单行摘要
- 原因：变更原因
- 测试结果：通过率、测试数量、使用工具
- 版本：新版本标签
系统Prompt与链式Prompt的治理
把每个系统Prompt和Prompt链的每一步，都当作单独版本化、有负责人的资产。 系统Prompt影响每一次请求，所以改一行就会改变所有输出。在链式或编排式工作流中，上一步的输出是下一步的输入，因此某个Prompt中的回归可能在三步之后才显现出来。
- 每个Prompt（包括系统Prompt、路由Prompt和工具描述）都有一名负责人和一个版本标签
- 记录每个Prompt测试时所用的模型名称和版本，并在服务商更新或停用该模型时重新运行门控1
- 将链的定义（步骤顺序、变量、工具列表）与其Prompt一起做版本管理，使回滚能恢复到一致的整体
- 针对黄金测试集对整条链做端到端测试，而不仅仅是单独测试每个Prompt
- 从部署配置中按版本标签加载系统Prompt，而不是硬编码在发布节奏不同的应用代码里
关于链的设计，参见Prompt链式调用；关于两层Prompt的区别，参见系统Prompt与用户Prompt。
企业级Prompt治理：访问控制、审批与EU AI Act
企业级Prompt治理把3个角色变成强制执行的权限。 在小团队中，角色只是一种约定；在企业规模下，角色必须是工具中的规则，任何一个人都无法绕过。
- 基于角色的访问控制：只有批准人可以更改生产标签（label或tag）所指向的版本，作者不能发布自己的变更
- 在Prompt仓库上设置受保护的部署标签或分支保护，使审查门控无法被跳过
- 单点登录和可导出的变更历史，以便对照身份系统核查访问和编辑
- 保留期限：按记录保存政策或适用法规的要求，保留Prompt版本和门控结果
EU AI Act的时间表在2026年发生了变化。 Regulation (EU) 2026/1744（针对AI的数字综合法案，Digital Omnibus on AI）已于2026年7月27日生效。该法案将附件三（Annex III）所列系统（例如招聘、信用评分和教育）的高风险义务从2026年8月2日推迟至2027年12月2日，将嵌入受监管产品的AI（附件一，Annex I）的相应义务推迟至2028年8月2日。
AI Act并未提及Prompt治理这一名称。它要求高风险系统具备风险管理、文档记录、记录保存和人工监督，而驱动此类系统的Prompt正是需要记录和保存的内容之一。NIST AI RMF是自愿性指南，方向相同：有文档的问责、可追溯性和事件响应。以上为一般性信息，不构成法律意见。
Prompt治理最佳实践清单
七项做法覆盖了大部分风险：指定负责人、全部版本化、每次变更都测试、用门控把关部署、记录变更、演练回滚，以及在模型变化时重新审查。
- 为每个生产Prompt指定一名明确的负责人
- 将Prompt放入版本控制并使用不可变的版本标签，绝不原地修改已部署的Prompt
- 为每个Prompt维护一套黄金测试集，并在每次变更时运行
- 门控未通过就阻止部署——不接受口头批准
- 为每次变更记录谁、改了什么、何时、为何，以及门控结果
- 定期演练回滚（例如每季度一次），让值班人员在事件发生前就亲手做过
- 当服务商更新或停用底层模型时，以及按固定的审查周期，重新运行测试套件并重新审查Prompt
Prompt治理工具、平台与软件
最小可行治理栈是Git + 测试运行器。 Prompt管理平台在此基础上增加版本管理、环境和访问控制；请根据你需要强制执行的管控来选择。
- Git：Prompt文件的版本控制。免费。适用于任何团队规模。GitHub或GitLab上的分支保护可强制要求审查。需要坚持一致地使用。
- PromptHub：提供版本控制、基于分支的部署，以及在每次提交或合并时运行评估器的流水线的Prompt管理工具。提供免费方案；付费方案按月计费，Pro为$12/月，Team为$20/用户/月。其定价页面未列出审批工作流或审计日志，因此签字环节请搭配Git审查。
- Langfuse：开源的LLM工程平台，支持Prompt版本管理和production等标签。免费的Hobby云方案包含Prompt版本管理；用于限制谁能移动production标签的受保护标签，需要带Teams附加包的Pro方案或Enterprise方案。
- Braintrust：具有CI/CD集成的评估平台。在每个PR上运行自动质量测试。Starter方案免费；Pro为$249/月，并增加基于角色的访问控制和环境。最适合已经在运行自动化Prompt测试的团队。
- Promptfoo：用于门控1和门控3的开源测试与红队运行器。OpenAI于2026年3月9日宣布已同意收购Promptfoo；Promptfoo表示该开源项目将继续保持开源。在将其作为标准工具之前，请先查看仓库的许可证和路线图。
- Vellum：具有流量管理、A/B测试和实时评估的生产Prompt部署。最适合高流量应用，分阶段发布可缩小事件的影响范围。
- PromptQuorum：多模型测试，在部署前确认Prompt在你所部署的模型系列（OpenAI GPT、Anthropic Claude、Google Gemini）上都能正常工作。在门控2同行审查期间使用。
按需选择。如果只需要历史记录和审查，带分支保护的Git就够了。如果非工程人员也要编辑Prompt，请选择带角色和界面的平台。如果必须强制规定谁能把Prompt升级到生产环境，请确认你实际要购买的方案中包含受保护标签或审批规则。排名对比请参见最佳Prompt管理平台和LangSmith、Helicone与Langfuse对比。价格为厂商公开标价，可能变动；请查看参考来源中的厂商页面。
常见问题
什么是Prompt治理？
Prompt治理是控制哪些Prompt进入生产环境以及如何监控的角色、审查流程和部署规则体系。它包括谁可以编写Prompt、谁必须批准、部署前必须通过哪些测试，以及Prompt在生产中失败时如何处理。
Prompt治理在生产环境中为何重要？
Prompt会悄无声息地失败——没有错误日志、没有异常、没有警报。输出质量下降时不会有任何可见信号。治理增加了可见性：每个变更被追踪，每个版本可审查，每次部署可回滚。
Prompt治理需要哪些角色？
三个角色可覆盖大多数团队：作者（编写Prompt、运行初始测试）、审查员（检查质量和合规性）和批准人（批准部署到生产环境）。大团队会增设Prompt负责人角色。
Prompt治理有哪些最佳实践？
为每个生产Prompt指定一名负责人，将Prompt放入带不可变标签的版本控制，每次变更都运行黄金测试集，门控未通过就阻止部署，记录谁改了什么及原因，演练回滚，并在底层模型变化时重新审查Prompt。
什么是Prompt治理软件？
Prompt治理软件是指能强制执行治理流程某一部分的任何工具：版本历史、访问控制、测试自动化、部署标签或审计日志。大多数团队会组合使用Git、评估工具和Prompt管理平台，而不是依赖单一产品。
哪些Prompt管理工具支持审批工作流？
审批功能因厂商和方案而异。Langfuse在带Teams附加包的Pro方案和Enterprise方案中提供受保护标签，可限制谁能移动production标签。Braintrust Pro增加基于角色的访问控制。GitHub和GitLab通过分支保护强制要求审查。请核实你所购买方案的具体功能。
如何治理系统Prompt？
为每个系统Prompt单独做版本管理，指定负责人并打标签，记录其测试所用的模型版本，从部署配置中按标签加载，并在Prompt或模型变化时重新运行回归测试套件。对于Prompt链，应将整条链一起做版本管理和测试。
如何回滚生产环境中有问题的Prompt？
用版本标签将每个已部署的Prompt存放在Git或Prompt管理工具中。检测到回归时，在部署配置中还原到上一个版本并重新部署。如果提前配置好版本控制，耗时不到5分钟。
NIST AI风险管理框架是否要求Prompt治理？
不要求。NIST AI RMF 1.0（2023年）是自愿性指南。它建议实施治理控制，包括问责、可追溯性、部署前风险评估和事件响应，而Prompt版本控制和审查门控对这些方面都有支持作用。
EU AI Act是否要求Prompt治理？
EU AI Act并未提及Prompt治理这一名称。它要求高风险AI系统具备风险管理、文档记录、记录保存和人工监督，而驱动此类系统的Prompt正是需要记录的内容之一。Regulation (EU) 2026/1744将附件三（Annex III）的高风险义务推迟至2027年12月2日（附件一，Annex I所列产品：2028年8月2日）。版本控制、审查门控和审计记录有助于追溯Prompt变更。以上为一般性信息，不构成法律意见。
Prompt治理与模型治理有何不同？
模型治理涵盖模型选择、训练、偏见测试和部署策略。Prompt治理涵盖给已部署模型下达的指令。在受监管环境中两者都需要；它们互补但不同。
Prompt的审计记录应该包含什么？
Prompt审计记录必须包含：每个版本的Prompt文本、修改者、时间、原因、通过的测试、批准部署的人，以及归因于它的任何事件。记录必须可查询——如果审计人员问某个时间点上线的是哪个Prompt，你应能在5分钟内回答。