企业官网建设流程全解析

做提示工程快两年，最深的感受是：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管理上，思路一下就清晰了：

这套映射不是硬套，而是因为Prompt管理本质上就是一个“小步快跑+持续验证”的问题。敏捷的底层逻辑是：快速反馈、小批量变更、持续改进，这在提示工程里比在传统软件开发中更重要——因为LLM的行为不确定性太高，一次大改版的风险远比一次小迭代大。

2. 场景化拆解：把“全场景适配”这种大话拆成能落地的活

多场景适配听起来很高级，但很多团队一开始就死在“适配”二字上——没有定义清楚到底要适配哪些场景。

2.1 场景矩阵：先盘点再说适配

我们落地敏捷的第一步，不是写代码，而是拉了一张“场景大盘”。把所有需要Prompt支撑的业务场景全部列出来，然后给每个场景打上标签。常用维度包括：

• 业务线（客服、营销文案、内容审核、代码辅助等）；
• 使用的模型（不同模型能力差异很大）；
• 用户群体（C端用户、内部员工、审核人员）；
• 输出格式（自由文本、JSON、Markdown、表格）；
• 语言（中文、中英混合、方言口语）；
• 评估指标（准确率、风格一致性、格式合规率、拒答率）。

做成表格大概长这样：

做完这张表，你才会发现所谓的“多场景适配”到底有多少工作量。我们当时盘完直接沉默了：三四十个场景，每个场景的Prompt都长得不一样，有些还互相“串味”。

2.2 用“用户故事”重新描述Prompt需求

完成了场景盘点，下一步是把每个场景的需求改写成“用户故事”。为什么要这么做？因为传统需求描述太模糊，比如“优化客服Prompt”，这句话等于没说。改成用户故事后就清晰多了：

“作为客服机器人，当用户询问退款政策时，我希望先判断订单是否已发货，再引导用户补充订单号，以便在不激怒用户的前提下准确解答。”

这种描述方式有三个好处：

• 需求来源清晰：知道这个Prompt是为谁、为什么而写；
• 验收标准可预判：从“当用户...我希望...”里能推演出测试用例；
• 变更触发点明确：哪天业务策略变了，直接改对应故事就行，不会误伤其他场景。

2.3 优先级排序：别指望一次迭代解决所有场景

多场景适配最容易犯的错，就是想“一把梭”——试图做一个万能Prompt覆盖所有场景。实践告诉我们这基本不可能。一个客服场景和一个代码生成场景的Prompt在系统人格、示例格式、约束条件上差异太大，硬塞在一起只会互相拖累。

我们用MoSCoW法则给场景排序：Must（这一轮必须修）、Should（应该修）、Could（可以修）、Won't（本轮不修）。排序基于三个原则：业务影响面最大优先、线上正在出错的优先、评估集容易构建的优先。这个排序直接决定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的Tag：scene-customer_service_refund-v1.2.0。每次线上变更都打Tag，出问题直接git revert或切回旧Tag重新部署。

3.3 短迭代节奏：一周一个Sprint

迭代周期我们最终定为一周。为什么不是两周？因为Prompt领域的变化速度实在太快了。

• 模型侧：某模型厂商可能两周就更新一次版本，行为分布一变，旧Prompt可能立刻失效；
• 业务侧：运营活动、平台规则、用户需求随时在变，拖两周意味着业务要忍受两周的“劣质适配”；
• 认知侧：我们对LLM行为的理解是逐步加深的，太长的迭代会让错误假设在错误的路上走很久。

一周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里的输入；
• 调用目标模型生成输出；
• 按预设指标打分，输出对比报告。

打分分两类：

这里有个细节：裁判模型不能和被测模型是同一个，否则相当于“自己批自己作业”。我们一般用能力更强的闭源模型做裁判，或者用人工抽检的比例在关键场景加一道保险。

4.3 回归节奏：小步快跑导致的问题

回归测试的触发时机有四个：每次提交变更时（本地跑）、合入主干前（CI跑）、上线前（全量跑）、模型升级后（全量跑）。前三个都好理解，第四个最容易忽略——我们有一半的Prompt“翻车”不是因为我们改了Prompt，而是因为模型升级了。

模型升级后的回归尤为关键。具体做法是：在模型方发布升级通知后，先把50%的流量切到新模型，另一边用main_prompt.md的当前线上版本在新模型上跑全量评估集，对比新旧模型的得分差异。如果核心指标下滑超过5个百分点，要么临时锁版本，要么立即启动Prompt适配迭代。

这个环节一开始很难推，因为它比平时的Prompt修改周期长，还要占用团队人力。但经历过一次“模型升级导致全线回答质量崩盘”之后，所有人都默认这是必须做的。因为测试不是成本，是保险。

5. 让进度透明：看板和站会怎么开才不流于形式

有版本控制、有回归测试，接下来就要解决“团队协作”环节。多场景适配不是一个人能完成的，通常涉及提示工程师、业务方、算法研发、QA等多角色协作。透明化不是走形式，是为了暴露“谁被阻塞了”“哪个场景在卡壳”。

5.1 Prompt迭代看板：每一列都要有明确“出口条件”

我们用物理白板，也用过在线看板工具。核心不是选工具，而是设计列和出口条件：

每个卡片代表“一个场景的一版变更”，而不是“一个需求”。这样做的原因是多场景适配中，一个需求可能拆成多个场景卡片，比如“优化物流相关话术”可能横跨退货、收货、投诉三个场景，必须拆开跟踪，因为它们的变更节奏和风险等级完全不同。

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已经完美了，它离失灵就不远了。