2005年左右，我从Ant手动构建脚本，那是工程效能的一次革命。 那时候，我们建立了一个铁律：“只要构建是绿的（Green），代码就是安全的。” 只要测试通过，代码的逻辑就是确定的。输入A，必然得到输出B。这种确定性，是传统软件工程的基石。 但现在，这个基石动摇了。 当我们把大语言模型（LLM）引入应用，引入了一股“混沌”。模型是基于概率的，同样的输入，今天可能输出A，明天稍微调高一点温度，就输出了B。 如果你的CI/CD流水线还在只盯着语法检查和单元测试，那你其实是在裸奔。你可能在半夜三更，被一个突然“犯神经”的模型叫醒，因为它开始对用户胡言乱语。 在AI时代，重构CI/CD势在必行。我们需要把“模型评测”和“Prompt版本管理”，像当年的单元测试一样，强行塞进流水线里。

一、 Prompt版本管理：把“咒语”变成代码

以前，我们痛恨“硬编码”。所有的配置都该拿出来，放在配置中心。 但在AI开发的初期，我看到很多工程师（包括我自己）都在犯一个错：把Prompt写死在代码里。

# 这种写法是灾难
prompt = "你是一个资深的客服，请回答用户的问题..."
response = model.generate(prompt)

当你想优化模型回答时，你得改代码、重新部署应用。这太重了，而且无法回滚。Prompt本身也是一种逻辑，甚至是比代码更核心的逻辑。它应该像配置文件一样，拥有独立的版本号。 重构策略：

1. Prompt即代码（Prompt-as-Code）： 所有的Prompt必须抽离到独立的仓库或配置中心。给它们打上Tag：v1.0, v1.1。

2. A/B测试机制： 在CI/CD流水线中，允许同时存在两个版本的Prompt。比如，线上跑着v1.0，你新写的v1.1只对5%的流量开放。流水线会自动对比这两个版本的用户满意度和转化率。

3. Review流程： 修改一段Prompt，必须经过Code Review。因为“请把语气改得委婉一点”这个指令，可能会导致模型在某些极端场景下变得啰嗦甚至推卸责任。这种逻辑变更，必须有人把关。

二、 模型评测流水线：守住质量的底线

传统的CI跑的是单元测试：assert add(1,1) == 2。 但在AI应用里，你怎么测试“请写一段中秋节祝福语”？你不能assert它等于某段话，你只能判断它“好不好”。 这就需要引入LLM Eval（大模型评测）环节。这是AI原生CI/CD的心脏。 落地实战：

     构建“黄金数据集”： 这是技术团队最核心的资产。你需要准备一份精心设计的测试用例集。

• 例如：100个常见用户问题 + 人工撰写的“完美回答”。
• 这份集子必须覆盖正常场景、边缘场景和攻击性场景（如诱导模型说出敏感词）。

     自动化评判： 在每次构建（或Prompt变更）时，流水线自动运行这套数据集。

• 利用更强的模型（如GPT-4）作为“裁判”，去打分。比较“新模型输出”与“完美回答”的语义相似度。

• 如果分数低于阈值（比如0.85的相似度），构建直接失败（Fail the Build）。

     回归测试： 这一点至关重要。很多时候，为了提升某一方面的能力（比如让回答更有趣），我们可能会意外破坏另一方面的能力（比如变得不严谨）。 只有引入自动化评测，我们才能在提交的那一刻发现：“嘿，这个新Prompt虽然幽默了，但在法律合规性上的分数掉了10%！”

三、 成本与性能的“熔断器”

除了质量，还有一个经常被老架构师忽略的指标：钱。 AI应用是按Token计费的。如果你的工程师不小心把一段死循环的逻辑写进了Prompt里，或者让模型每次都去读取整个数据库，成本会瞬间爆炸。 在新的CI/CD里，我建议加入“成本预演”环节。 在发布前，用测试数据跑一遍，预估上线后的QPS成本。如果发现这个新版本的Prompt会导致成本上升50%，而效果只提升1%，流水线应该发出警告，甚至直接拒绝合并。

总结：为概率性世界建立确定性秩序

做技术管理这么多年，我深知混乱是效率的大敌。AI虽然带来了智能，但也带来了混乱。 我们重构CI/CD，不是为了炫技，而是为了在概率性的AI模型之上，强行建立一套确定性的工程秩序。 流水线不仅是在部署代码，更是在部署“智能”。 只有当每一次Prompt的微调、每一个模型的升级，都能被度量、被回滚、被自动化验证时，我们才能真正睡个好觉。 然而，即便我们的流水线再严密，有一个环节依然让我们头疼：测试。 当测试对象是一个“会撒谎、会变卦”的AI时，传统的测试方法论正在崩塌。

下一篇预告： 《测试工程的挑战：如何为“会撒谎”的代码写测试？》 —— 从断言到评估，从自动化测试到AI红队演练。