接入大模型已经不难。

调用 API、编写 Prompt、增加一个聊天入口，几天内就能做出一个看起来不错的 AI Demo。但很多项目上线后很快出现问题：模型升级导致输出变化，业务规则调整后 Prompt 没有同步，知识过期无人更新，错误结果又很难追踪。

真正有价值的 AI 应用，不仅要“现在能用”，还要在半年、一年后依然可用、可维护、可升级。

Demo 与长期应用之间，差的不是一个模型

一个 AI Demo 通常只关心结果是否惊艳；长期运行的应用还必须回答更多问题：

• 模型换版本后，原有功能会不会失效？
• 业务字段变化后，AI 是否仍能返回正确结果？
• 知识内容过期时，谁来更新？
• AI 出错后，能否找到原始请求和执行过程？
• 成本突然升高时，能否快速定位原因？
• 关键操作能否回退到人工处理？

因此，AI 应用不能只是“业务系统调用一次大模型”，而应被设计成一套可以持续运营的软件能力。

第一，把模型与业务流程分开

大模型适合处理自然语言、文本总结、意图识别和内容生成；业务系统更适合管理数据、权限、规则和流程。

例如，用户输入：

根据这封客户邮件创建一张售后工单。

AI 可以提取客户、产品、问题类型和紧急程度，但不应该直接写入数据库。更稳妥的流程是：

这里可以用活字格低代码搭建工单数据表、确认页面、角色权限和处理流程，再通过接口接入大模型。AI 只负责它擅长的不确定任务，确定性的操作仍由应用系统完成。

这样做的好处是：即使以后更换模型，工单数据和业务流程也不需要推倒重来。

第二，不要把 Prompt 写死在功能里

Prompt 不是一次性文案，而是 AI 应用的重要配置。

它应该包含版本、适用场景、输入格式和输出要求，并能独立更新。每次修改后，还应使用固定测试样本检查：

• 字段提取是否准确；
• 输出格式是否稳定；
• 原有场景是否退化；
• Token 成本是否明显变化。

如果 Prompt、模型名称和业务代码混在一起，每次调整都需要重新发布整个系统，维护成本会越来越高。

第三，为 AI 建立可回归的测试集

传统程序通常有明确的正确答案，AI 输出却可能每次略有不同。因此，测试不能只看文字是否完全一致，而要检查业务结果。

以工单识别为例，可以长期保留一组匿名样本，重点验证：

模型、Prompt 或知识库发生变化后，先运行这组测试，再决定是否上线。

第四，保留日志、人工确认和降级方案

可维护的 AI 应用必须能够回答：“当时为什么得到这个结果？”

至少应记录：

• 用户的原始请求；
• 使用的模型和 Prompt 版本；
• 提供给模型的必要上下文；
• 模型返回结果；
• 校验失败信息；
• 人工修改内容；
• 最终执行结果。

对于修改订单、关闭工单、提交审批等操作，还应保留人工确认。模型不可用或结果不可信时，系统需要允许用户改为手工填写，而不是让整个业务停止。

第五，用业务指标判断 AI 是否值得继续维护

AI 回答得像不像人，并不是最重要的指标。

更值得关注的是：

• 一项任务节省了多少时间；
• 关键字段识别准确率是多少；
• 人工修改比例是否下降；
• 错误操作和回退次数有多少；
• 单次任务成本是否可控；
• 用户最终是否完成了业务目标。

如果 AI 生成的文字很漂亮，但员工仍需重新填写大部分内容，那么它并没有真正提高效率。

写在最后

AI 应用的竞争力，不是率先接入某个模型，而是建立一种能够持续改进的运行方式。

模型会变化，业务也会变化。把模型与流程解耦，把 Prompt 纳入版本管理，用测试集验证升级效果，并保留日志、人工确认和降级通道，AI 才能从一次性 Demo 变成长期可用的软件能力。

活字格在这个例子中只是承载数据、页面、权限和流程的开发环境。真正重要的方法是：

让 AI 负责理解，让系统负责约束，让测试和日志保证它可以持续维护。

AI 项目最难的从来不是第一次跑通，而是变化发生之后，它仍然能够稳定地跑下去。