从工具到 SaaS：AI 产品的工程化要点

把一个 AI 工具做出来 demo 很容易，但做成能给团队稳定用的 SaaS 产品，中间有一大堆工程化问题。这篇聊聊我做 AI 测试平台过程中踩的几个关键点。

1. LLM 路由：别一个模型打天下

不同任务对模型的要求不一样：

• 代码变更分析：要理解代码，用强模型
• 用例生成：要发散 + 遵循格式，用中等模型 + 严格 prompt
• 报告总结：要简洁有重点，用中等模型即可
• 简单的分类/提取：用小模型，省成本

所以平台里做了 LLM 路由层，按任务类型路由到不同模型。好处是：

• 成本可控：大头任务用便宜模型，关键判断用强模型
• 质量可控：每个任务用最适合的模型
• 可切换：模型升级或换厂商时只改路由配置

ROUTING = {
    "impact_analysis": "gpt-4-class",
    "test_generation": "gpt-4o-class",
    "report_summary": "gpt-4o-mini-class",
    "classification": "haiku-class",
}

2. 异步执行 + 进度可见

Agent 链路往往要跑几十秒到几分钟，不能同步等。所以：

• Celery 跑异步任务，API 立即返回任务 ID
• WebSocket 推送实时进度，前端能看到当前跑到第几步
• 任务状态持久化，刷新页面或断线重连能恢复

这点对用户体验很关键。用户点”执行”后如果只能转圈圈等结果，体验很差；如果能看到”正在分析变更 → 正在选测试范围 → 正在生成用例”，焦虑感会低很多。

3. 可追溯性：每一步都要留痕

AI 产品最容易出的问题是”这次为什么这么判断的？“——如果答不上来，用户就不敢信。

所以平台里每个 Agent 步骤都记录：

• 输入是什么（prompt、上下文）
• 调用了哪个模型、什么参数
• 输出是什么
• 耗时、token 消耗

这些不只是为了 debug，更是为了让结论可解释。报告里说”建议关注支付模块”，点进去能看到 Agent 当时的推理过程。

4. 成本控制

AI SaaS 的成本很容易失控。几个做法：

• 缓存：相同输入的 LLM 调用结果缓存，比如同一份代码变更的分析
• 分级调用：先用便宜模型做初步判断，需要深入再调强模型
• 预算告警：每个项目/每个任务的 token 消耗设上限
• Prompt 优化：prompt 越精炼，token 越省，质量还更高

5. 失败要优雅

LLM 会超时、会返回格式错误、会幻觉。产品层面要：

• 重试机制：网络抖动自动重试
• 格式校验 + 修复：返回的 JSON 不合规时尝试修复或重试
• 降级方案：关键步骤失败时有 fallback，比如 LLM 挂了至少能跑预设规则
• 明确失败原因：别只报”执行失败”，要告诉用户哪一步、什么原因

最后

AI 产品的技术门槛不在”调 API”，而在把不确定性变成可工程化的系统。LLM 是会犯错的组件，工程化的任务就是把它包进一个稳定、可追溯、可降级的系统里。

这和传统软件工程一脉相承，只是多了”处理概率性输出”这一层。