AI项目实战日记ep1：从零做一个 AI 日志分析助手

最近趁着DeepSeek要涨价了，研究了个小项目。（当然接的还是GPT）

以前我们可能需要针对不同模型厂商分别处理 API 地址、鉴权方式、请求格式，代码里也容易到处出现各种 if model == xxx。错误日志有时候也有一些阅读门槛。那么有什么方法能帮助我们快速理解日志内容从而做出针对性举措呢？于是我就研究了这个

AI 日志分析助手

它的功能很简单：

把一段服务器日志扔进去，让 AI 帮我们回答三个问题：

这里发生了什么？
最可能的问题在哪里？
下一步应该怎么排查？

模型部分使用 蓝耘元生代 MaaS 提供的模型服务。

蓝耘元生代目前提供统一的 OpenAI 兼容接口，并聚合了 DeepSeek、Qwen、Kimi、MiniMax、Claude、GPT、Gemini 等多种模型。官方平台目前展示为 50+ 主流模型，并支持通过统一 API 接入。

这意味着对于我们这个项目来说，代码不需要围绕某一家模型厂商重新设计一遍，只需要把模型服务接进来即可。

一、先看看我们到底要做什么

先给最终效果定个目标。

假设服务器出现下面这样的日志：

text 复制代码

2026-08-24 18:21:31 ERROR database connection failed
2026-08-24 18:21:31 ERROR pymysql.err.OperationalError:
(1045, "Access denied for user 'app'@'10.0.0.12'")
2026-08-24 18:21:32 WARNING retry connection 1/3
2026-08-24 18:21:35 WARNING retry connection 2/3
2026-08-24 18:21:38 ERROR retry connection 3/3 failed
2026-08-24 18:21:38 CRITICAL service startup failed

传统做法是开发人员自己翻日志，然后判断：

数据库连接失败 → 用户认证失败 → 重试三次 → 服务启动失败。

我们希望 AI 最终能够给出类似这样的分析：

text 复制代码

问题类型：
数据库认证失败

核心异常：
MySQL 返回 1045 Access denied。

问题链路：
1. 应用尝试连接 MySQL
2. MySQL 拒绝 app 用户认证
3. 应用连续重试 3 次
4. 最终导致服务启动失败

建议排查：
1. 检查数据库用户名和密码
2. 检查 MySQL 用户允许访问的 Host
3. 检查应用当前使用的数据库配置
4. 确认数据库实例是否发生过账号权限变更

优先级：
P1

这就比单纯让 AI"总结一下日志"实用多了。

项目结构也不用搞得特别复杂：

text 复制代码

ai-log-analyzer/
├── app.py
├── analyzer.py
├── requirements.txt
└── logs/
    └── demo.log

整个项目的核心其实只有一个文件：

text 复制代码

analyzer.py

二、前提：使用云平台开发的好处

实际上，现在能提供大模型 API 的平台并不少，选择哪个服务，最终还是应该看自己的项目需求。

使用云平台开发，主要有三个比较实际的原因。

1. 接口比较容易接入现有项目

蓝耘元生代 MaaS 提供 OpenAI 兼容 API。

官方给出的 Python 调用方式也是直接使用 openai SDK，通过修改 base_url 来访问蓝耘的模型服务。

这点对于开发者来说很重要。

因为我们本来就可以使用：

bash 复制代码

pip install openai

然后：

python 复制代码

from openai import OpenAI

而不是为了接入一个新的模型服务，再专门学习一套完全不同的 SDK。

2. 模型选择比较集中

这个项目现在只需要一个模型。

但如果以后想做类似：

text 复制代码

日志分析 → DeepSeek
代码解释 → Qwen
长文档总结 → 其他长上下文模型

就不用重新设计整个应用。

蓝耘官方目前提供 50+ 主流模型，并支持统一接口调用。

对于正在做原型验证的小项目来说，这种方式挺方便。

3. 模型和项目代码可以解耦

这是我认为比较值得注意的一点。

程序真正关心的只有response，那为何不把模型服务和日志分析逻辑分开来，减小耦合性呢？

把两者分开之后，以后换模型的时候，核心业务逻辑基本不用动。

接下来进入实操阶段。

三、注册蓝耘元生代并创建 API Key

首先进入蓝耘元生代平台。

蓝耘元生代 MaaS 平台

注册账号后进入控制台，创建自己的 API Key。

这里建议大家不要把 API Key 直接写进代码。

比如不要这样：

python 复制代码

client = OpenAI(
    api_key="sk-xxxxxxxxxxxxxxxx"
)

虽然 Demo 能跑，但是一旦把代码上传 GitHub，Key 就有泄露风险；推荐使用环境变量，至于环境变量怎么添加，这里只做简单介绍，大家可以去问问ai或者上网搜索详细教程。

Linux/macOS：

bash 复制代码

export LANYUN_API_KEY="你的API Key"

Windows PowerShell：

powershell 复制代码

$env:LANYUN_API_KEY="你的API Key"

代码里：

python 复制代码

import os

api_key = os.getenv("LANYUN_API_KEY")

这样安全很多。

四、创建项目

点击应用云，创建自己的应用。

创建之后，准备 Python 环境。

bash 复制代码

mkdir ai-log-analyzer
cd ai-log-analyzer

创建虚拟环境：

bash 复制代码

python -m venv .venv

Windows：

powershell 复制代码

.venv\Scripts\activate

Linux/macOS：

bash 复制代码

source .venv/bin/activate

安装 OpenAI SDK：

bash 复制代码

pip install -U openai

五、先做最小可运行版本

创建：

text 复制代码

analyzer.py

代码如下：

python 复制代码

import os
from openai import OpenAI


client = OpenAI(
    api_key=os.getenv("LANYUN_API_KEY"),
    base_url="https://maas-api.lanyun.net/v1/chat/completions"
)


def analyze_log(log_text: str):
    prompt = f"""
你是一名资深后端工程师和 SRE。

请分析下面的服务器日志，并按照以下结构输出：

1. 问题类型
2. 核心异常
3. 问题发生过程
4. 最可能的原因
5. 建议排查步骤
6. 严重程度

要求：
- 只根据日志中能够观察到的信息进行判断
- 不要编造不存在的错误
- 如果无法确定原因，请明确说明
- 排查建议尽量具体

日志：

{log_text}
"""

    response = client.chat.completions.create(
        model="deepseek-v3",
        messages=[
            {
                "role": "system",
                "content": "你是一名专业的服务器故障分析助手。"
            },
            {
                "role": "user",
                "content": prompt
            }
        ],
        temperature=0.2
    )

    return response.choices[0].message.content


if __name__ == "__main__":
    with open("logs/demo.log", "r", encoding="utf-8") as f:
        log_text = f.read()

    result = analyze_log(log_text)

    print("=" * 60)
    print("AI 日志分析结果")
    print("=" * 60)
    print(result)

这里最关键的其实就三行：

python 复制代码

client = OpenAI(
    api_key=os.getenv("LANYUN_API_KEY"),
    base_url="https://maas-api.lanyun.net/v1/chat/completions"
)

以及：

python 复制代码

model="deepseek-v3"

剩下的内容都是我们的业务逻辑。

蓝耘官方也提供了类似的 OpenAI SDK 调用示例，包括 API Key、统一接口和模型名称的配置方式。

这里我们要做AI日志助手，只需要按照上面来即可，如果有额外需求可以后续添加。

虚拟仓库在这里添加。

六、第一次运行

准备：

text 复制代码

logs/demo.log

把刚才的测试日志放进去。

然后运行：

bash 复制代码

python analyzer.py

如果 API Key、模型名称和网络环境都正常，就应该能够看到模型返回的分析结果。

七、把它从"调用模型"变成一个真正的项目

到这里其实还只是完成了：

Python → 蓝耘 MaaS → 大模型 → 返回文本

所以接下来才是这个项目真正有意思的地方。

我们给它增加一个简单的 HTTP 接口。

创建：

text 复制代码

app.py

代码：

python 复制代码

from fastapi import FastAPI, UploadFile, File
from analyzer import analyze_log


app = FastAPI(
    title="AI Log Analyzer"
)


@app.post("/analyze")
async def analyze(file: UploadFile = File(...)):
    content = await file.read()

    log_text = content.decode(
        "utf-8",
        errors="ignore"
    )

    result = analyze_log(log_text)

    return {
        "filename": file.filename,
        "analysis": result
    }

启动：

bash 复制代码

uvicorn app:app --reload

打开：

text 复制代码

http://127.0.0.1:8000/docs

就能看到 FastAPI 自动生成的接口页面。

选择：

text 复制代码

POST /analyze

上传：

text 复制代码

demo.log

点击：

text 复制代码

Execute

整个调用链就变成了：

text 复制代码

日志文件
   ↓
FastAPI
   ↓
日志读取
   ↓
Prompt 构造
   ↓
蓝耘 MaaS
   ↓
大模型
   ↓
结构化分析结果
   ↓
JSON

这时候它已经不再只是一个 API Demo，而是一个可以继续开发的 AI 应用雏形。

八、这里我遇到的一个实际问题：API 能通，但代码还是报错

第一次调试时，比较容易遇到一个问题：

text 复制代码

401 Unauthorized

或者：

text 复制代码

model not found

这种问题第一反应很容易认为：

是不是代码写错了？

实际上需要分层排查。

我建议按照下面的顺序检查。

第一层：API Key

先确认：

bash 复制代码

echo $LANYUN_API_KEY

能够正常输出。

Windows：

powershell 复制代码

echo $env:LANYUN_API_KEY

如果这里是空的，就不用继续往下排查了。

第二层：模型名称

直接进入蓝耘 MaaS 的模型市场，看当前账号实际可以使用的模型名称。

例如官方当前示例使用：

text 复制代码

deepseek-v3

但模型列表和具体可用模型可能会变化，所以实际项目应该以控制台当前显示的名称为准。直接在下图这里看就行。

第三层：API 地址

项目里最容易出现的问题之一，就是把： base_url 和完整接口地址混在一起。

蓝耘官方当前 Python 示例使用：

python 复制代码

base_url="https://maas-api.lanyun.net/v1/chat/completions"

因此我建议第一次测试时，直接按照控制台/API 文档给出的代码运行，确认请求成功后，再根据自己使用的 SDK 版本调整封装方式。

九、为什么不用传统的 HTTP 请求？

意思是例如：

python 复制代码

import requests

requests.post(
    "https://xxx/v1/chat/completions",
    headers={
        "Authorization": "Bearer xxx"
    },
    json={
        "model": "xxx",
        "messages": []
    }
)

一样能完成工作。

但是使用 OpenAI 兼容 SDK 后，项目代码会更加干净。

我们的业务代码只需要关注信息和模型，而模型服务地址、认证信息则放到客户端配置中；这对于后面做模型切换尤其方便。

十、再做一个小实验：换模型

这也是我比较喜欢 MaaS 统一接口的一点。

假设我们的日志分析已经能够正常工作。

现在想换一个模型测试一下。

比如原来是ds的v3模型，现在我想换成qwen的话，可以直接在控制台进行更改，

业务代码、Prompt和FastAPI完全不用改。

这也就是我之前提到的模型能力和业务应用分离。

对于早期项目开发来说，这种架构还是比较舒服的。

十一、总结

整个项目其实可以非常明确地拆成三层：

text 复制代码

┌─────────────────────────────┐
│        AI 日志分析助手       │
│                             │
│ FastAPI / Prompt / 业务逻辑 │
└──────────────┬──────────────┘
               │
               ↓
┌─────────────────────────────┐
│       蓝耘元生代 MaaS        │
│                             │
│ API / 模型接入 / 模型管理     │
└──────────────┬──────────────┘
               │
               ↓
┌─────────────────────────────┐
│          大模型服务           │
│     DeepSeek / Qwen / ...    │
└─────────────────────────────┘

也就是说：

我负责写应用，蓝耘这类平台负责提供模型调用这一层基础设施。

蓝耘 MaaS 官方目前主打的就是统一模型接入、模型选择以及模型调度等能力，并提供 OpenAI 兼容接口。

实际开发中，我觉得可以按照项目情况选择。

需求	更应该关注什么
快速做 Demo	API 是否简单
多模型项目	是否提供统一接口
企业项目	稳定性、权限、审计
成本敏感	Token 价格、缓存、调用量
自建模型	是否支持自有算力/模型
国内业务	网络和服务可用性
模型频繁切换	是否容易迁移

十二、实际运行数据怎么记录？

我建议记录下面几个指标：

text 复制代码

模型：
API：
测试日志大小：
输入 Token：
输出 Token：
总 Token：
首字响应时间：
完整响应时间：
调用费用：

例如：

text 复制代码

测试时间：2026-XX-XX XX:XX
模型：DeepSeek V3
日志大小：XX KB
输入 Token：XXXX
输出 Token：XXX
总 Token：XXXX
首字响应：X.XX s
完整响应：X.XX s
本次费用：¥X.XXXX

十三、最终项目效果

完成之后，我们已经有了一个非常简单但完整的 AI 应用，看看效果~

后面继续扩展的话，还可以做很多东西。

例如：

1. 自动识别日志类型

text 复制代码

Nginx
MySQL
Java
Python
Docker
Kubernetes
Linux

根据日志内容自动选择不同 Prompt。

2. 增加知识库

把公司的：

text 复制代码

运维手册
故障记录
部署文档
API 文档

接入 RAG。

这样 AI 就不只是"看日志"，而是可以结合企业内部资料进行排查。

3. 增加多模型

例如：

text 复制代码

普通日志分析 → 小模型

复杂异常分析 → 强模型

代码 Stack Trace → 代码模型

通过统一接口，把不同模型安排到不同任务。

4. 接入监控系统

进一步可以变成：

text 复制代码

Prometheus
    ↓
异常指标
    ↓
日志
    ↓
AI 分析
    ↓
生成故障报告
    ↓
通知开发人员

这时候就已经从一个 Demo 逐渐变成真正的 AI 运维工具了。