别把 AI 交付当成“写代码”：为什么 AI Lab 需要一套“工程化交付”的 SOP

在很多 AI Lab 的交付现场，我经常看到一种极其普遍的误区：团队习惯性地将 AI 项目的交付逻辑等同于传统的软件开发。

传统的软件开发逻辑是：需求 $\rightarrow$ 设计 $\rightarrow$ 编码 $\rightarrow$ 测试 $\rightarrow$ 上线。在这个链路里，只要代码逻辑正确，输入 A 必然得到 B，确定性是最高优先级。

但在 AI 交付中，这种思维会导致严重的灾难。因为 LLM 的本质是概率分布，而非确定性逻辑。如果你试图用“写代码”的方式去交付一个 AI 应用，你很快会陷入一个死循环：微调 Prompt $\rightarrow$ 发现新 Bug $\rightarrow$ 修改 Prompt $\rightarrow$ 旧 Bug 回归 $\rightarrow$ 崩溃。

真正的 AI 工程化交付，不应该关注于如何写出那个“完美的 Prompt”，而应该关注于如何构建一套能够容纳不确定性的 SOP（标准作业程序）。

1. 从“单点调优”转向“数据集驱动”

很多开发者在交付时最喜欢做的事情就是：在 Playground 里试了 10 次，觉得效果不错，然后直接把 Prompt 贴进代码里提交。

这在工程上叫“幸存者偏差”。你看到的成功是随机抽样的结果，而不是系统性的能力。

工程化 SOP 要求：
- 建立黄金数据集 (Golden Dataset)：在开始任何调优前，必须先定义一个包含 50-100 个典型 Case 的测试集（包含正例、负例和边界 Case）。
- 量化评估指标：不要说“感觉好多了”，要说“在 Golden Set 上，准确率从 65% 提升到了 82%，且没有出现严重幻觉”。
- 回归测试机制：每一次 Prompt 的修改，必须全量跑一遍数据集。如果为了解决 Case A 而导致 Case B 退化，这次修改就是失败的。

2. 构建“可干预”的中间层

AI 应用最忌讳的是“黑盒端到端”。如果你把所有逻辑都塞进一个巨大的 System Prompt 里，一旦输出出错，你根本无法定位是哪个环节出了问题。

工程化 SOP 要求：
- 原子化任务拆解：将复杂的任务拆分为多个微小的 Step（例如：提取实体 $\rightarrow$ 查询知识库 $\rightarrow$ 生成草稿 $\rightarrow$ 自检修正）。
- 显式状态传递：每个 Step 的输出应该是结构化的（JSON），方便在中间层进行拦截和审计。
- 人工干预锚点 (Human-in-the-Loop)：在关键节点（如发送给客户前）预留人工审核接口。AI 完成 90% 的工作，人类完成最后 10% 的确认。这比追求那永远无法达到的 100% 全自动要高效得多。

3. 处理“概率性失效”的容错设计

在传统软件中，Bug 是需要被修复的；但在 AI 应用中，某些概率性的失效是不可避免的成本。

工程化 SOP 要求：
- 优雅降级 (Graceful Degradation)：当 LLM 输出格式错误或触发安全过滤时，系统应该能自动切换到预设的模板回复，而不是直接抛出 JSON 解析异常导致页面崩溃。
- 自省循环 (Self-Reflection)：引入一个轻量级的检查步骤（例如用更小、更快的模型检查输出是否符合格式要求），如果不符合则重新生成一次。
- 反馈闭环 (Feedback Loop)：在产品界面提供简单的 👍/👎 反馈按钮，将用户认为“差”的 Case 直接回流到 Golden Dataset 中进行迭代。

写在最后

AI Lab 的核心竞争力不在于谁能写出最精妙的 Prompt，而在于谁能将这种不确定性的能力，“封装”成一个确定性的产品体验。

当你不再试图通过一次性地编写完美指令来解决问题，而是开始构建数据集、拆解任务链、设计容错机制时，你才真正从一个“Prompt 工程爱好者”变成了一个“AI 工程专家”。