别把 Prompt 当成代码：在 AI 工程化中建立“配置-逻辑”的分离机制

在很多 AI Lab 的交付现场，我经常看到一种极其危险的模式：开发者将复杂的业务逻辑、数据清洗规则、甚至部分条件判断，全部通过一个巨大的 Prompt “硬编码”在 LLM 的输入中。

这种做法在 Demo 阶段非常高效——你只需要修改一段话，就能让 AI 表现出截然不同的行为。但当项目进入生产环境，面对成千上万次请求和多变的业务场景时，这种“Prompt-as-Code”的模式会迅速演变成一场维护噩梦。

1. “Prompt 膨胀”带来的工程危机

当业务逻辑被塞进 Prompt 时，你会发现自己陷入了以下循环：
- 不可预测的回归：为了修复 A 场景的一个 Bug，你微调了 Prompt 中的一句话，结果导致原本正常的 B 场景突然崩溃。
- 调试黑盒：当输出结果不符合预期时，你无法通过断点或日志知道是哪个“指令”失效了，只能通过不断尝试不同的措辞（Prompt Engineering）来祈祷它生效。
- 版本管理缺失：Git 对代码的 Diff 非常清晰，但对一个 2000 字 Prompt 的微小措辞修改几乎没有语义上的追踪能力。

2. 核心方案：配置与逻辑的彻底分离

真正的 AI 工程化应该是：LLM 只负责执行原子化的认知任务，而流程控制、状态管理和数据校验由确定性的代码（Python/TS）掌控。

A. 将“指令”转化为“参数化模板”

不要写 如果用户是 VIP 请用礼貌语气，而应该在代码层判断用户等级，然后向 LLM 传递一个明确的参数：{ "tone": "polite", "user_status": "VIP" }。
Prompt 应该是一个纯粹的模板（Template），所有的变量在运行时由代码注入。这样你可以独立地对模板进行版本控制（例如存储在数据库或配置文件中），而无需触动核心逻辑代码。

B. 用“结构化输出”替代“自然语言约定”

很多团队习惯在 Prompt 里写 请以 JSON 格式返回，不要包含任何解释。这依然是不稳定的。
工程化的做法是强制要求 LLM 输出严格的 Schema（如使用 JSON Mode 或 Function Calling），并在接收端立即进行 Pydantic 等强类型校验。如果校验失败，直接触发重试机制或回退到兜底方案，而不是让错误的结果流向下一个环节。

C. 构建“认知原语”而非“全能助手”

不要试图构建一个能处理所有事情的“超级 Agent”。将复杂的任务拆解为一系列原子化的认知原语（Cognitive Primitives）：
- 原语1：提取实体 $\rightarrow$ 输出 JSON $\rightarrow$ 代码校验 $\rightarrow$ 保存数据库。
- 原语2：根据数据库上下文生成摘要 $\rightarrow$ 输出文本 $\rightarrow$ 代码过滤敏感词 $\rightarrow$ 返回用户。

3. 实战教训：从“调优措辞”到“优化链路”

在一个实际的法律文档分析项目中，我们最初尝试通过一个超长 Prompt 让 AI 完成【阅读 $\rightarrow$ 分类 $\rightarrow$ 提取条款 $\rightarrow$ 对比差异】的所有步骤。结果是模型经常遗漏细节且极不稳定。

我们将其重构为一条流水线：
1. 分段切片（确定性代码）$\rightarrow$ 2. 关键信息提取（原子 Prompt）$\rightarrow$ 3. 结构化存储（数据库）$\rightarrow$ 4. 对比算法（代码 + LLM 定点分析）。

重构后，系统的鲁棒性提升了 40%，且每次出错都能精准定位到是哪个环节的问题——是切片太碎？还是提取原语失效？还是对比逻辑有误？

结语

AI 工程化的本质不是研究如何写出完美的 Prompt，而是研究如何用确定性的软件工程手段去包裹不确定性的模型输出。当你开始把 Prompt 当成一种可替换的“配置”，而不是不可触碰的“黑盒逻辑”时，你的系统才真正具备了规模化交付的能力。