★ FEATURED ARTICLE 做提示工程快两年最深的感受是Prompt一旦挂上生产环境就不是“写”出来的而是“养”出来的。我们团队早期是一个人手写几十条Prompt后来业务一多模型一换场景一细分Prompt直接在聊天记录里“炸”了——改了一版不知道覆盖了哪个场景模型升级后老Prompt集体翻车业务方拿着旧截图来质问谁都不知道线上跑的是哪个版本。最后我们决定把敏捷实践搬进提示工程团队用迭代、看板、回归测试去管理Prompt的多场景适配才慢慢把这件事从“艺术”变成了“工程”。这篇文章想聊聊我们是怎么把敏捷落地到Prompt管理上的。不是那种贴KPI式的敏捷而是真正能解决“Prompt换个场景就失灵”这个痛点的打法。适合正在做AI应用落地、提示工程、LLM Agent开发的同行参考也适合那些刚接手Prompt治理、发现版本乱成一锅粥的团队管理者。1. 从“写好”到“管好”Prompt敏捷化的触发点先说一个很现实的问题为什么提示工程团队需要敏捷很多人对Prompt的理解还停留在“一次性交付物”——需求方给个描述写Prompt的人润色一下上线完事。但在真实业务里Prompt的生命周期比绝大多数代码都要长而且活得非常“折腾”。1.1 Prompt是典型的“活性资产”代码写完要测试、要部署、要监控Prompt理应走同样的流程。但我们早期完全没这个意识。举一个真实的例子团队做了某客服场景的Prompt上线第一天表现很好回复礼貌、信息准确、能主动引导用户补充订单号。但三天后业务方反馈“回答开始有AI味儿了”一查发现是模型侧更新了版本行为分布发生了变化原来Prompt里某些措辞在新模型下的“温度”和跟随度完全不同。这件事给我们一个重要的触发点Prompt不是写一次就结束的东西它像一套需要持续维护的规则引擎模型在变、业务策略在变、用户问法在变Prompt就必须跟着变。只要有一个维度在变Prompt的“维护成本”就从“零”变成了“持续投入”。1.2 传统救火模式为什么撑不住在引入敏捷之前我们的工作模式是典型的“救火式”业务方提需求一会儿说“客服Prompt不够亲切”一会儿说“生成的内容不够专业”写手直接改改完就在群里丢一段说“试试这个”线上验证靠人品没人知道改了之后会不会影响另一个场景版本靠记忆过了两周问“当前生产环境到底是哪个Prompt”没人能答上来。这种模式的本质问题是提示工程团队把精力全花在了“改”上而没有花在“管”上。多场景适配这件事一旦场景数量超过十个靠人脑记忆和群聊记录就是灾难。1.3 敏捷方法论和Prompt管理的映射关系后来我们把敏捷的核心实践一一映射到Prompt管理上思路一下就清晰了敏捷实践在提示工程中的对应物用户故事场景化需求描述谁、在什么情境、需要什么表现Sprint短迭代Prompt版本迭代周期一周或两周每日站会Prompt变更同步昨天改了什么、今天要改什么看板Prompt状态可视化需求、开发、评审、灰度、上线持续集成自动化评测回归每次变更都跑一遍评估集迭代回顾Prompt复盘哪些改对了、哪些改坏了这套映射不是硬套而是因为Prompt管理本质上就是一个“小步快跑持续验证”的问题。敏捷的底层逻辑是快速反馈、小批量变更、持续改进这在提示工程里比在传统软件开发中更重要——因为LLM的行为不确定性太高一次大改版的风险远比一次小迭代大。2. 场景化拆解把“全场景适配”这种大话拆成能落地的活多场景适配听起来很高级但很多团队一开始就死在“适配”二字上——没有定义清楚到底要适配哪些场景。2.1 场景矩阵先盘点再说适配我们落地敏捷的第一步不是写代码而是拉了一张“场景大盘”。把所有需要Prompt支撑的业务场景全部列出来然后给每个场景打上标签。常用维度包括业务线客服、营销文案、内容审核、代码辅助等使用的模型不同模型能力差异很大用户群体C端用户、内部员工、审核人员输出格式自由文本、JSON、Markdown、表格语言中文、中英混合、方言口语评估指标准确率、风格一致性、格式合规率、拒答率。做成表格大概长这样场景模型用户群体输出格式核心指标当前版本客服-退货咨询某闭源模型-0412版消费者自由文本信息准确率、安抚语气评分v1.2营销文案-社媒短句某闭源模型-最新版市场运营短文本点击预估、风格达标率v2.0审核-评论分类某开源模型审核员JSON分类准确率、误判率v0.9做完这张表你才会发现所谓的“多场景适配”到底有多少工作量。我们当时盘完直接沉默了三四十个场景每个场景的Prompt都长得不一样有些还互相“串味”。2.2 用“用户故事”重新描述Prompt需求完成了场景盘点下一步是把每个场景的需求改写成“用户故事”。为什么要这么做因为传统需求描述太模糊比如“优化客服Prompt”这句话等于没说。改成用户故事后就清晰多了“作为客服机器人当用户询问退款政策时我希望先判断订单是否已发货再引导用户补充订单号以便在不激怒用户的前提下准确解答。”这种描述方式有三个好处需求来源清晰知道这个Prompt是为谁、为什么而写验收标准可预判从“当用户...我希望...”里能推演出测试用例变更触发点明确哪天业务策略变了直接改对应故事就行不会误伤其他场景。2.3 优先级排序别指望一次迭代解决所有场景多场景适配最容易犯的错就是想“一把梭”——试图做一个万能Prompt覆盖所有场景。实践告诉我们这基本不可能。一个客服场景和一个代码生成场景的Prompt在系统人格、示例格式、约束条件上差异太大硬塞在一起只会互相拖累。我们用MoSCoW法则给场景排序Must这一轮必须修、Should应该修、Could可以修、Wont本轮不修。排序基于三个原则业务影响面最大优先、线上正在出错的优先、评估集容易构建的优先。这个排序直接决定Sprint的容量避免团队在需求面前失去弹性。3. 版本控制与短迭代让Prompt像代码一样可追溯、可回滚Prompt管理的第二根支柱是版本控制。没有版本控制的Prompt在敏捷体系里根本跑不起来——因为敏捷要求“随时可以回退”但聊天记录里的Prompt回退全靠翻聊天记录。3.1 用Git管理Prompt的目录结构我们决定把所有Prompt纳入Git仓库管理目录结构按“场景”和“公共模块”拆分。这个设计来自一次痛苦的经历几个Prompt都复用了同一段“系统人格描述”后来改了一个场景的人格设定结果其他场景在模型升级后全部跟着跑偏。原因就是共享内容复制粘贴了多份没有统一管理。现在我们的目录大致长这样prompts/ ├── scenes/ │ ├── customer_service_refund/ │ │ ├── main_prompt.md │ │ ├── few_shot_examples.json │ │ └── eval_cases.json │ ├── marketing_short_copy/ │ │ ├── main_prompt.md │ │ └── eval_cases.json ├── shared/ │ ├── system_persona.md │ ├── output_format_rules.md │ └── few_shot_examples/这里最关键的是shared/目录。凡是两个以上场景共同依赖的内容一律抽到公共目录用Markdown的引用或模板变量引入。改一次全场景生效但每次修改都会走评审避免“改了一个公共模块炸了五个场景”的事故。3.2 Commit规范与版本命名Prompt的Commit信息不能随便写。我们定了一个简单但强制的格式[场景] 变更类型: 简述变更原因 示例 [customer_service_refund] fix: 调整退款话术以适配最新版模型对未发货订单的问答偏好 [marketing_short_copy] feat: 新增小红书风格示例提升互动率 [shared] refactor: 统一系统人格描述中的语气规范变更类型统一为fix修问题、feat新场景/新能力、refactor结构优化行为不变、perf降低token消耗。版本号不搞花活直接用Git的Tagscene-customer_service_refund-v1.2.0。每次线上变更都打Tag出问题直接git revert或切回旧Tag重新部署。3.3 短迭代节奏一周一个Sprint迭代周期我们最终定为一周。为什么不是两周因为Prompt领域的变化速度实在太快了。模型侧某模型厂商可能两周就更新一次版本行为分布一变旧Prompt可能立刻失效业务侧运营活动、平台规则、用户需求随时在变拖两周意味着业务要忍受两周的“劣质适配”认知侧我们对LLM行为的理解是逐步加深的太长的迭代会让错误假设在错误的路上走很久。一周Sprint的节奏大致是时间任务周一场景需求分析、变更排期、优先级Review周二-周三Prompt开发与修改同步补充/更新测试用例周四自动化评测 人工抽检 问题修复周五评审、灰度发布、上线、Sprint回顾3.4 变更评审Prompt也走Code Review这就是为什么说Prompt要“像代码一样管理”Prompt也在吃算力、也在影响用户体验、也可能输出有害内容它凭什么不走Review我们的Review不是走形式而是有明确的检查清单是否保持了统一的系统人格是否引入了“角色不连贯”的风险指令是否与shared/output_format_rules.md冲突Few-shot示例是否覆盖了边界情况而不是只挑最顺的写新增约束是否会增加token消耗约束越多推理越长是否包含了“如果模型无法理解指令时”的兜底设计。这个清单一开始是几个人拍脑袋列的后来每次踩坑就往里加一条。到现在光Review清单就有十几项它像一个“排雷手册”帮我们躲掉了大量线上事故。4. 多场景回归测试给每个Prompt配一份“体检报告”敏捷最核心的保障不是流程制度而是“随时知道改坏了没有”。在提示工程里这个保障就是多场景回归测试。4.1 评估集建设不然你就是在裸奔没有评估集就敢改Prompt等于闭眼换零件。我们吃过最大的亏就是改了一个客服Prompt让退货场景答得更好了结果收货场景的答案开始“文不对题”线上投诉量暴增。原因很简单两个场景Prompt里有一段共享的“物流解释话术”改的人根本不知道它还服务于另一个场景。后来我们要求每一个场景必须配套一个eval_cases.json评估集。评估集的构建原则每条case都是“真实历史对话人工修正”从线上日志里捞真实用户问题再由业务同学把标准答案修正一遍保证答案质量高于线上平均水平每个维度至少覆盖三类样本正常请求、边缘业务比如“发货了吗”但订单根本没创建、恶意输入攻击性、诱导性内容数量不贪多但覆盖必须全每个场景起步30条重点场景会到100条。数量少不可怕可怕的是50条全是“顺风局”一点抗风险能力都没有。4.2 自动化评测框架从人眼看到脚本打分人工看Prompt输出是必要的但不可能每次都人工看。我们搭了一个极轻量的自动化评测脚本核心逻辑是加载某场景的Prompt模板读取eval_cases.json里的输入调用目标模型生成输出按预设指标打分输出对比报告。打分分两类指标说明实现方式硬性指标格式合规率、JSON可解析率、必含字段率脚本解析软性指标语气风格、信息准确度、语义相关性用另一个更强的模型做裁判LLM-as-a-judge这里有个细节裁判模型不能和被测模型是同一个否则相当于“自己批自己作业”。我们一般用能力更强的闭源模型做裁判或者用人工抽检的比例在关键场景加一道保险。4.3 回归节奏小步快跑导致的问题回归测试的触发时机有四个每次提交变更时本地跑、合入主干前CI跑、上线前全量跑、模型升级后全量跑。前三个都好理解第四个最容易忽略——我们有一半的Prompt“翻车”不是因为我们改了Prompt而是因为模型升级了。模型升级后的回归尤为关键。具体做法是在模型方发布升级通知后先把50%的流量切到新模型另一边用main_prompt.md的当前线上版本在新模型上跑全量评估集对比新旧模型的得分差异。如果核心指标下滑超过5个百分点要么临时锁版本要么立即启动Prompt适配迭代。这个环节一开始很难推因为它比平时的Prompt修改周期长还要占用团队人力。但经历过一次“模型升级导致全线回答质量崩盘”之后所有人都默认这是必须做的。因为测试不是成本是保险。5. 让进度透明看板和站会怎么开才不流于形式有版本控制、有回归测试接下来就要解决“团队协作”环节。多场景适配不是一个人能完成的通常涉及提示工程师、业务方、算法研发、QA等多角色协作。透明化不是走形式是为了暴露“谁被阻塞了”“哪个场景在卡壳”。5.1 Prompt迭代看板每一列都要有明确“出口条件”我们用物理白板也用过在线看板工具。核心不是选工具而是设计列和出口条件列出口条件待分析该场景需求已完成用户故事描述和优先级标记开发中Prompt已修改本地评估集已跑通待评审已完成自查评估集得分不低于上一版本灰度中线上5%流量测试持续24小时无投诉已上线全量发布评估集全通过已回滚版本已回退原因已记录每个卡片代表“一个场景的一版变更”而不是“一个需求”。这样做的原因是多场景适配中一个需求可能拆成多个场景卡片比如“优化物流相关话术”可能横跨退货、收货、投诉三个场景必须拆开跟踪因为它们的变更节奏和风险等级完全不同。5.2 每日站会十分钟只讲三件事站会容易变成汇报会或技术讨论会。我们定的站会原则是“三句话若干个Block”昨天完成了哪个场景的哪一版Prompt得分变化多少今天计划推进哪个场景预期完成到什么状态有没有被外部阻塞——比如模型接口限流、评估集数据缺失、业务方没给到标准答案技术细节拉走小会绝不占用集体时间。我统计过团队规模五个人以内时站会控制在8分钟就能高质量完成。人一旦超过十个站会就开始变形提示工程团队早期根本不需要那么多专职人员三五个人配好工具比什么都强。5.3 协作边界谁负责写谁负责验收敏捷里的“角色模糊”是大忌。我们明确划分了几个角色的职责边界提示工程师负责Prompt实现、评估集编写、评测结果分析业务方负责场景需求描述、评估集里的标准答案修订、人工抽检算法/平台研发负责模型版本管理、评测框架的工程化、调用链路稳定性。最容易出问题的是“业务方要不要写Prompt”的问题。我们的答案是业务方最懂业务但Prompt工程经验不足允许他们提想法、给参考话术但最终改写和优化交给提示工程师。同样提示工程师不能闭门造车每周必须拉业务方过一遍本周上线的Prompt听一听“用户那些奇怪的反馈”。敏捷里面讲“用户参与”在提示工程这里就是“业务方参与验收”这句话是实打实的经验不是口号。6. 踩坑总结敏捷的边界在哪里讲了一堆好的实践我也想说说这里面的坑。因为敏捷管理Prompt这件事不是把流程拉满就能成的。做得过火敏捷反而会杀死敏捷。6.1 踩过的坑过度流程化导致效率下降有一段时间我们为了追求“规范”把每个Prompt变更都搞成“重型变更”——需要写变更申请、两个Reviewer签字、跑完整评估集、灰度48小时、验证三个看板指标。结果呢一个很简单的Prompt优化从提需求到上线要拖一周业务方等不了直接在线上“曲线救国”——绕过团队自己拿账号改。这次教训很深刻流程是为了降低风险不是为了增加仪式感。现在我们的流程分了“轻量变更”和“重量变更”两轨轻量变更比如调整Few-shot示例的用词、修改语气形容词、增加一个同义词走“单Reviewer跑核心评估集灰度8小时”即可重量变更比如重写系统人格、变更输出格式、更换底层模型才走完整流程。分轨的初衷是承认“不是所有变更风险都一样”。把全部变更都压在同一个重量级最终只会让团队人人都想绕流程。6.2 什么类型的Prompt不需要敏捷管理还有一个认知问题敏捷不是银弹。有些Prompt根本不需要进敏捷流程一次性探索型Prompt比如临时用工具生成的摘要、面试时写的Demo用完即弃没必要纳入版本管理纯内部辅助型Prompt比如给数据分析师自己用的脚本注释生成器它不面向外部用户改坏了也没人投诉模型内置能力适配比如某个模型本身就擅长中文摘要你只需要简单指令硬把它包装成“重要场景”反而浪费评审资源。判断要不要纳入敏捷管理的标准很简单这个Prompt会不会影响真实用户体验会不会被多人复用会不会需要跨版本回溯三个都不满足就让它自由生长。6.3 经验总结轻量敏捷 场景化治理花了这么多篇幅其实最终沉淀下来就是八个字轻量敏捷场景化治理。迭代周期要短但不要为了短而短一周是我们在“变化速度”和“管理成本”之间找到的平衡点版本控制要严但不要为了控制而控制Git的Tag和分轨评审机制足够用了测试回归要全但不要追求评估集数量上的“豪华”覆盖关键维度比堆数量管用团队协作要透明但不要让看板和站会变成行政负担五分钟能同步完的事情不要拖到十五分钟。敏捷做得好不好不看你贴了多少个看板、开了多少站会而看一件事从提需求到Prompt上线平均需要多久出错之后平均多久能定位并回滚这两个数字比任何流程制度都诚实。我们团队从救火式管理走到今天这套体系路径是可以复制的但节奏必须自己调。每位读者所处的团队规模、业务复杂度、模型使用方式都不一样照搬流程不如先把“场景矩阵评估集版本控制”这三件事落地其他的都可以慢慢长出来。最后再分享一个体会Prompt管理真正难的地方不是技术不是流程而是让每个参与者都持续保持对“变化”的警惕——一旦你觉得某个Prompt已经完美了它离失灵就不远了。
阅读完成 · 觉得有帮助？
