Marico's space
最近折腾了一个项目，是给在电信公司工作的老妈写的自动化工具。这篇说说踩坑过程和技术实现。
背景是这样的——我妈在尼日利亚一家电信公司做网络 field maintenance（现场运维），每个月都要做 SLA（服务水平协议）报告。以前这活儿全靠人工：要从 WhatsApp 上复制现场工程师发的故障描述，按公司标准分类，然后手动整理成 Excel 合规报表。一套流程下来，2 到 4 个小时没了。
有一次我亲自上手试了试，发现这活儿真不是人干的。机械重复、注意力高度集中，坐在那儿几个小时，脑子和身体都被榨干。
那时候我就想，能不能写个工具把这事儿自动化了？
于是有了这个 Telecom RCA Automation System（电信 RCA 自动化系统）。
上线之后，原来 2 到 4 小时的工作压缩到 5 分钟左右，效率提升超过 95%，而且出错率大幅下降。这项目其实不是周末肝出来的，断断续续搞了几个月。之前一直觉得不够完善，没脸发出来。这次开发者大赛给了动力，让我回去重新打磨分类引擎、修掉积累已久的 bug、优化用户体验，终于整出一个拿得出手的版本。
说白了，就是想给爱的人多省点晚上休息的时间。
在线体验
电信 RCA 自动化系统
演示视频
视频演示了从上传华为 RNATracker 可用性报告到生成最终 SLA 报表的完整流程，也展示了 Google Gemini AI 如何辅助处理模糊的故障分类。
项目地址
Telecom-RCA-Automation-System
技术方案
整个应用是个 6 步工作流，技术栈：React 19 + TanStack Start + TypeScript + Tailwind CSS v4，后端用 Supabase（PostgreSQL + 行级安全策略）做持久化和持续学习。
分类引擎是核心。这里用了 8 阶段分类管道，按优先级依次执行：
短时规则 → 硬编码覆盖 → 已学习修正 → 伙伴关键词引擎 → Google Gemini AI → 伙伴锁定 → 站点历史回退 → 通用模糊匹配
最难搞的部分：解析器
整个项目最棘手的就是写那个能读懂混乱 WhatsApp 消息的解析器。这些报告几乎没有一致的格式，经常遇到：
粘连的站点 ID 没有分隔符
开头零丢失
嵌套站点组
级联故障
多种时长格式混用
比如这样的：
EN0035+25(EN0707,EN0377):
DG fail to start =34mins 或者 1hr 20mins 或者 1:20hrs解析器能自动提取：
站点 ID
级联故障
故障描述
中断时长
用户不需要事先清理或格式化文本。
当解析器拿不准的时候，会通过安全的 server-side（服务端）代理把故障描述发给 Google Gemini，API key 永远不会暴露到客户端。
伙伴感知的分类逻辑
有个有意思的挑战：同一个故障描述不一定属于同一个 RCA（根因分析）类别。比如"DG fail to start"这个故障，根据受影响站点是由 IHS 还是 ATC 或其他基础设施合作伙伴管理，会归属到不同的 SLA 类别。
所以分类器是伙伴感知优先、关键词匹配次之，这样能给出更准确的分类结果。
持续学习
系统会越用越聪明。
当用户在审核步骤纠正分类时，这个修正会被存到 Supabase，形成一条"已学习映射"。下次遇到类似的故障，应用会自动套用纠正后的分类，不需要任何额外的训练流程。
不用用户专门去"教"模型，应用在日常使用中悄无声息地学习进步。
为什么用 Google Gemini
项目参加了 Best Use of Google AI（最佳 Google AI 使用）赛道。
大部分故障靠确定性规则分类，执行速度极快。只有模糊或从未见过的故障描述才会发给 Gemini 2.0 Flash，做结构化提取和智能分类。
为了保持系统高效和成本可控，请求会：
缓存 7 天
批量打包
仅在本地规则无法自信分类时才发送
这种方案兼顾了规则系统的速度和现代 AI 的灵活性。
效果
Telecom RCA Automation System 把一个重复性高、易出错的报表流程，从 2 到 4 小时压缩到 5 分钟左右。
它结合了智能解析、规则自动化、持续学习和 Google Gemini AI，实现了电信 RCA 和 SLA 报告生成的自动化。
更重要的是，它解决了一个真实的问题——给启发我写这个项目的人省点时间。
参赛类别
Best Use of Google AI
Google Gemini 2.0 Flash 负责对本地确定性规则无法覆盖的故障描述进行智能分类，提供准确的结构化提取能力，同时通过缓存和请求批量处理保持高速和低成本。
关于我
项目是我一个人开发的，设计、开发、分类逻辑、AI 集成、数据库架构、测试、部署，全流程一个人扛下来。