操作日志没人看得过来？一个SaaS后台的AI摘要方案，把排查时间从40分钟压到3分钟

业务痛点：日志在涨，人在耗

我给一个多租户SaaS后台做运维支持时，最深的感受是：操作日志的量增长速度，远超团队阅读它的能力。

具体场景是这样的：后台每天产生约5万条操作日志，涵盖登录、权限变更、数据导出、配置修改、订单操作等十几类事件。安全合规要求每周出一份操作审计摘要，客户出问题时要快速回溯“这个账号上周到底干了什么”。

之前的处理方式很原始：

• 每周审计摘要：人工按租户筛选、分类、统计，一个熟悉业务的运营同学要花约 6小时，最后产出的是一份流水账式的表格，老板基本不看；
• 问题回溯：客户投诉“数据怎么被动了”，开发同学要在几十万条日志里捞线索，平均排查一次 40分钟左右，还经常漏看关键事件；
• 成本账：按每月4次审计 + 20次回溯计算，每月大约消耗 104人时，折算人力成本接近万元，而这些工作里80%是机械性的筛选和归纳。

这正是一个典型的“LLC任务”——大量、低创造性、但需要语言理解能力。适合AI来做，但要做得便宜、稳定、可落地。

架构设计

核心思路：不追求让AI直接“读懂全部日志”，而是让AI做它最擅长的一层——把结构化事件序列翻译成人类可读的摘要和风险提示。

操作日志（DB/ES）
      │
      ▼
预处理层（规则代码）
  - 按租户+时间窗口聚合
  - 归并重复事件（如连续失败登录压成一条）
  - 压缩日志为紧凑格式（只留关键字段）
      │
      ▼
统一AI API网关（一个 base_url）
  - 日志分类打标 → 小模型（便宜）
  - 摘要生成/风险解释 → 中档模型
  - 复杂异常叙事 → 大模型（按需）
      │
      ▼
输出层
  - 周报Markdown摘要（按租户分节）
  - 回溯场景：给定账号+时间窗，生成时间线叙事

三个关键设计决策：

1. 预处理用代码，理解用AI。重复事件归并、格式压缩这类确定性工作用规则做，能砍掉70%以上的token。实测一个租户一周的原始日志约3万token，压缩后只需2500 token左右——成本直接降到原来的十分之一以下。

1. 任务分层路由到不同模型。简单的日志分类（“这是导出行为还是配置变更”）用小模型，一份周报的调用成本不到1分钱；只有最终的租户级摘要和风险解释用中档模型。整套方案跑下来，5万条日志/天的全量处理，每月token成本不到200元，对比之前每月近百人时的人力，ROI一目了然。

1. 摘要不替代原始日志。AI输出永远附带事件ID引用，方便点回原始记录核实。审计场景宁可保守，不追求“AI全自动结论”。

为什么坚持走统一AI API网关

这个方案上线后我最大的体会是：接入层统一，比选对模型更重要。

早期版本我们直接对接某家模型API，key、鉴权、参数格式都硬编码。三个月后遇到两个问题：一是该模型在中文长文本归纳上翻车率偏高想换；二是想给不同租户用不同模型（大客户用更好的模型）。每次调整都意味着改代码、改配置、重新测试，估算下来一次切换要花 2-3人天。

迁移到统一AI API网关后，情况完全不同：

• 一个base_url + 一个key，所有模型调用走同一入口，切换模型只是改一个模型名参数，从2-3人天变成10分钟的配置修改；
• 成本可观测：网关层面的用量统计天然按租户/任务归因，不用自己埋点，就能回答“AI摘要这个功能每个租户烧多少钱”；
• 失败降级简单：某个模型超时，网关侧配置fallback到备用模型，应用代码一行不改；
• 新能力零成本接入：后来想加“日志异常检测”，直接换个模型名就行，不用再走一遍接入流程。

对于小团队，维护成本才是隐形成本的大头。假设模型每季度迭代一次、每年做两次架构调整，直连模式下光接入层的维护一年就要吃掉 10人天以上；网关模式下基本趋近于零。省下来的时间，够你再落地两个AI功能。

关键实现步骤

如果你想复刻这个方案，建议按这个顺序推进：

# 核心流程清单（伪代码）
def weekly_digest(tenant_id):
    # 1. 取一周日志，按事件类型聚合
    events = query_logs(tenant_id, days=7)

    # 2. 规则预处理：归并重复、压缩字段
    compact = []
    for type, group in group_by(events, "type"):
        if is_repetitive(type):          # 如失败登录
            compact.append(f"{type}: {len(group)}次, 涉及{uniq_users(group)}个账号")
        else:
            compact += [compact_format(e) for e in group]  # 只留who/what/when/target

    # 3. 小模型先打风险标（便宜，可大量调用）
    tagged = llm_small("对以下事件分类并标记可疑项", compact)

    # 4. 中档模型生成摘要（只对压缩后内容）
    digest = llm_mid(f"""为租户{tenant_id}生成周审计摘要：
    - 高风险操作及涉及账号
    - 异常模式（时间、频率）
    - 每条结论附事件ID引用
    事件列表：{tagged}""")
    return digest  # 平均延迟 < 20s，成本 < 0.05元/租户

落地节奏建议：

1. 第1周：选一个租户的历史日志做离线试点，验证摘要质量，人工对比准确率；
2. 第2周：接入统一网关，接通日志管道，先只做“回溯场景”（价值最快兑现）；
3. 第3周：上线周报自动化，加人工抽检机制（每周随机抽3份人工复核）；
4. 第4周：根据抽检反馈调prompt和压缩规则，稳定后逐步放开全部租户。

效果对账

上线三个月后的实际数字：

省下的时间不是全部重点——更重要的是回溯从“开发同学的负担”变成了客服同学自己就能完成的操作，问题响应链路少了一环。

写在最后

对小团队来说，AI应用落地的门槛已经不在模型能力，而在工程化的琐碎：接入、切换、计费、降级。把这些交给一个统一的AI API网关，你才能把精力放在真正的业务摘要逻辑上。

如果你也想快速跑通第一个AI场景，可以先注册一个网关账号，用同一个base_url把摘要功能跑起来：

👉 https://api.thistoken.ai/register

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。