如何用AI从零做一个属于你自己的日志分析工具

目录

• • [为什么写这篇]
• • [动手之前，先把这几样东西准备好]
• • [核心版：先把骨架做出来]
• • [通用的坑，不管你用什么技术栈都可能踩到]
• • [进阶版：如果骨架做完了，还想继续加]
• • [最后]

为什么写这篇

上一篇笔记发出来之后，有读者问能不能分享源代码。

想了想，不太合适直接给代码，倒不是藏着掖着——是这个工具从头到尾都是照着我自己的服务器环境、自己的日志格式定制出来的，你的服务器大概率跟我不是一套东西（可能是Apache不是Nginx，可能日志格式完全不一样，可能你用的是PHP不是Python），直接把我的代码拿去，改起来的工作量说不定比重新做一个还大。

不如把"我是怎么想清楚这个东西该怎么做、又是怎么一步步跟AI把它撬出来的"这个过程写出来，你照着这个思路，让AI帮你做一份真正贴合你自己情况的，反而更好用。

顺便说一句，可能会打消一些人的顾虑：这整个工具我用的是CodeBuddy里的DeepSeek，不是什么顶级模型，每天免费额度是100积分，做这种工具类的项目，半天到一天基本能出一个能跑起来的版本，积分完全够用，不需要花钱订阅什么高级服务。真正决定这事能不能成、做出来好不好用的，从来不是模型多强，是你自己能不能把需求想清楚、能不能看懂AI给你的东西去判断它对不对——这篇笔记大部分篇幅其实都在讲这个。

动手之前，先把这几样东西准备好

不管你打算做成什么样，下面这几样是必须先搞清楚的，AI没办法替你猜：

核心版：先把骨架做出来

这段可以直接复制给你的AI工具，开头那句"先看我的日志格式"很关键，别跳过，这是让AI基于你的真实情况设计，而不是套用一个假想的格式。

我想做一个个人使用的Web服务器日志分析工具，用来替代GoAccess这类固定报表工具，需要能在网页上自由组合筛选条件、一层一层往下查，类似Cloudflare的Log Explorer那种体验。在开始设计任何解析规则之前，请先问我要这两样东西，不要自己假设：1. 我的Web服务器访问日志格式配置（原文贴给你）2. 几行真实的日志样本拿到这两样之后，你再基于这个真实格式设计解析规则，不要照搬任何现成模板。## 使用场景和约束- 数据量级：每天大概[几十万/几百万]条（这里换成你自己的实际情况）- 只需要查看最近几天的数据，不需要保留很久以前的历史- 不需要实时监控，是我自己想看的时候手动运行一次- 部署在我自己的服务器上，通过防火墙IP白名单限制访问，不需要账号  登录体系## 技术方案的选型原则（请遵循，不要引入超出这个复杂度的方案）- 不要用Elasticsearch/ELK这类为海量历史数据+实时监控设计的重量级  方案，这对我的使用场景是杀鸡用牛刀，配置门槛也高，我不需要- 存储用DuckDB这类轻量级、单文件、SQL友好的分析型数据库，不需要  单独部署数据库服务，适合"批量处理一次、查询很快"这种场景- Web层用简单直接的方式实现（不强制要求具体框架，你可以推荐，但  不要引入不必要的复杂框架/ORM等抽象层，这个项目逻辑不复杂，能  直接操作数据库就不要绕弯路）- 前端不需要复杂的构建工具链，能正常交互、展示图表和筛选界面就行## 数据处理流程1. 一个脚本，负责：读取日志文件 → 解析成结构化字段 → 用一个IP/地理   位置信息库（如MaxMind GeoLite2）把IP转换成国家/城市/网络运营商   信息 → 存进数据库2. 每次运行都是全新处理、覆盖旧数据，不需要做增量更新（我用得频率   不高，全量重新处理完全能接受）3. 处理完成后，同一个命令里紧接着启动网页服务，网页服务是前台运行   的，不是常驻后台服务，我用完直接关掉进程即可## 解析容错要求（这几点很重要，请务必遵守）- 日志里总会有格式不完全标准的行（比如恶意请求、爬虫的畸形请求），  解析失败的行不要直接丢弃，要设计成"严格模式"和"宽松兜底模式"  两层：严格模式覆盖大多数标准行，兜底模式在严格模式失败时，尽量  抢救出核心字段（比如至少保留IP、时间、状态码），实在无法解析的  才跳过，并把原始行记录到一个单独的错误日志文件里，方便我事后  排查- 很多日志格式里，"字段没有值"不是空字符串，而是用一个占位符表示  （比如Nginx常用`-`表示无数据），请在解析前先确认我的日志格式里  缺失值是怎么表示的，不要直接当成普通字符串处理导致后续统计出错- 给每条数据加一个标记字段，区分它是"完整解析的"还是"只解析出  部分字段的"，方便我以后筛选查看- 保留每一行的原始日志文本（哪怕已经解析成了结构化字段），方便我  以后对照原文核实解析得对不对## 需要重点确认的字段：客户端真实IP如果我的服务器前面有CDN（比如Cloudflare），日志里记录的IP字段可能不是真实访客IP，而是"客户端可能伪造的值 + CDN追加的真实值"这种逗号分隔的组合。不要凭字段名就假设该取第一个还是最后一个，请指导我用以下方式验证：自己发一个带假IP的测试请求（比如用curl加一个自定义的请求头字段），看日志里实际记录成什么样，再确定该怎么解析。## 自由筛选功能设计要求- 页面上要有一个时间趋势图，可以拖拽选中一段时间，联动下面所有的  维度统计和明细数据- 除了时间，其他任意字段（比如访问路径、状态码、IP来源、User-Agent  等）都要支持自由组合筛选，规则是：同一个字段选中多个值时是"或"  的关系，不同字段之间是"且"的关系，这是最符合直觉的默认逻辑- 除了"只看这个值"，还要支持"排除这个值"- 出现次数可能有几十万种不同取值的字段（比如具体访问路径、  User-Agent），不能把所有值都返回给前端，只显示出现次数最多的  前N个，其余归并成"其他"- 明细数据要支持分页浏览、可以自己选择要显示哪些字段（不是所有  字段都默认展示，避免表格太宽看不过来）请先跟我逐项确认我的日志格式和字段设计，不要自己假设完就直接开始写代码，确认清楚了再动手。

通用的坑，不管你用什么技术栈都可能踩到

这几个是我自己踩过、觉得值得单独拎出来提醒的——不是"抄这段代码"，是"提前知道有这么回事，遇到了不会懵"。

IP字段的陷阱

只要你的服务器前面有CDN或者反向代理，日志里的IP字段就有可能不是真实访客IP，一定要自己动手测试验证，不要凭猜测处理，这个字段一旦解析错了，后面所有跟IP相关的分析全都是错的。

数据库里"空值"的坑

如果你的分析工具支持"筛选某个字段为空的记录"这种功能，要小心——大多数数据库里，"空"对应的是NULL，而NULL不能用普通的"等于"或者"在这些值里"这种方式判断，必须用专门的"是否为NULL"语法。

如果处理不对，筛选"为空"的时候会查出0条结果，这个坑很隐蔽，测的时候容易漏掉。

高基数字段别一股脑扔给前端

像访问路径、User-Agent这类字段，可能有几十万种不同的值，千万别设计成"把所有唯一值都返回给前端然后前端自己想办法展示"，这样页面会直接卡死。一定是后端做"取前N名+其他归并"这种聚合处理。

路径归并如果也想做，匹配逻辑要精确

如果你也想把相似的URL归并成一类看（比如把带具体ID的详情页路径归并成一个模板），一定要求AI用"路径按斜杠分段后逐段精确比较"的方式做匹配，不能用"这段字符串里有没有出现某个关键词"这种模糊搜索去判断，不然很容易把本来不相关的路径误伤进去（比如一个路径里恰好包含了关键词的字母，但整体含义完全不同）。

前端做进度条/图表宽度这类元素，小心CSS的flex属性

如果你打算做类似进度条这种"根据数值动态调整宽度"的元素，注意CSS的flex布局有时会覆盖你用JS算好的百分比宽度。做出来发现所有进度条都一样长的话，大概率是这个原因，这个坑排查起来会比较绕，提前知道能省不少时间。

进阶版：如果骨架做完了，还想继续加

这些不是必须做的，是"如果你也遇到类似需求，可以参考这几个方向"，同样是拿去给AI用的提示词思路，不是可以直接复制的成品（因为具体实现要看你已经搭好的骨架长什么样）。

识别真正的搜索引擎爬虫

主流搜索引擎通常会公开发布自己爬虫用的IP地址段（去搜"某公司 爬虫 IP 官方 verification"能找到），可以下载这份清单，判断访客IP是否落在这些官方网段里，命中就能确认这条访问真的来自这家公司，可信度很高。

但注意有些公司不发布IP清单，而是要用"反向DNS查询"这种完全不同的方式验证，实现复杂度不是一个量级，可以先跳过，专注在有官方IP清单的几家上。

还有一类是"UA字符串里自称是某个爬虫，但没有IP能核实"的情况——这类信息谁都可以伪造，可信度低，如果也想记录，务必用一个独立的字段，跟"IP已核实"的字段分开，不要混在一起统计，不然会分不清哪些是真的确认过的。

把相似路径归并成一类统计

前面"通用坑"那节提到的精确匹配问题解决了之后，具体做法是两条规则：路径里纯数字的部分自动换成一个占位符；再维护一份"关键词清单"，遇到清单里的词，把它后面紧跟的那一段也换成占位符。这份清单可以放在一个配置文件里，方便自己随时增减词。

聚合数据一键导出

如果只是看一条条的日志记录，不容易看出整体规律，可以做一个独立的导出功能——不是从明细表格里裁剪几列导出，而是后端专门做一次分组统计（按你关心的几个维度交叉分组、算出现次数），直接导出成CSV，方便用Excel这类工具做进一步分析。

最后

这几天做下来最大的心得是：AI给出的方案，能不能真的解决问题，最后都得自己动手验证一遍才知道——尤其是那些"听起来逻辑没问题"的地方，往往才是最容易踩坑的地方。多问一句"这个你实际测过吗，还是只是看代码逻辑判断的"，能省掉很多来回折腾的时间。