接入大模型已经不难。调用 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 项目最难的从来不是第一次跑通而是变化发生之后它仍然能够稳定地跑下去。