GenAI 在云电话运维中的实战应用

生成式 AI 如何改变了我的运维日常——以及为什么真正的收益并不是速度

我是 Vanessa Mendes，Telecom 领域的一名实习生。在过去 4 个月里（2026 年 4 月至 7 月），我的日常工作主要是维护多个客户的 cloud 电话系统——每个客户采用的技术栈不同，基础设施各有特点，紧急程度也不尽相同。

我负责维护的生态系统包括：

• 面向大型业务的 Amazon Connect（队列、flow、callback、view）
• 面向小型业务的 PBX Issabel/Asterisk（部署在 EC2 上的本地系统）
• AWS（Lambda、DynamoDB、S3、CloudWatch、Security Groups）
• Jira + Confluence（ticket 管理与文档）

我所在的是一个 Telecom 运维团队，知识共享始终贯穿其中，协作也是日常工作的一部分。

在运维工作之外，我还采用了 Kiro CLI——一款通过 MCP（Model Context Protocol）集成到工作环境中的 AI 助手——作为辅助生产力工具。这篇文章讨论的并不是工具本身，而是 AI 如何改变了我的工作方式。

挑战：多个客户、多套系统、快速决策

先交代一下背景：我需要同时服务多个客户，每个客户都有自己的 AWS 访问权限、SSO profile、Connect instance、PBX 及其他特有配置。处理一个事故 ticket 可能需要：

• 阅读 Jira 中的 ticket（了解上下文）
• 访问 CloudWatch Logs（获取证据）
• 检查 Security Groups 或 DynamoDB（核查基础设施）
• 查阅 Confluence 文档（了解历史情况）
• 通过 SSH 连接 PBX（进行诊断）
• 与同一客户过去的 ticket 交叉比对（寻找规律）

在使用 AI 之前，每次在不同系统之间切换都会消耗时间，还会增加丢失上下文的风险。调查工作高度依赖我的记忆和经验——而对于一个入职只有 4 个月的人来说，这确实是一项现实限制。Telecom 团队一直愿意为我答疑并帮助验证假设，但有一款工具能够协助我整理信息，并在不同系统之间保持上下文，确实带来了决定性的改变。

我在上半年完成的工作

1. Callback 系统：历经 4 个版本走向生产环境

我的主要项目是完整开发一套用于 Amazon Connect 的 callback 系统，并先后迭代了 4 个版本。

最终成果包括：一个包含 113 个 block、支持 3 种语言（PT/EN/ES）的 Flow Module；一个负责拼接国际电话号码的 Python 3.12 Lambda；以及一项技术发现，它让我们得以从 flow 中彻底移除一个 Lambda——原来 UpdateContactCallbackNumber block 本身就可以充当号码可拨通性验证器。

完整文档已经发布到 Confluence。在 AI 的协助下，信息组织更加高效，从“代码完成”到“文档发布”的时间显著缩短。

2. VIP 优先级系统：智能管理

我在 Amazon Connect workspace 中开发了一套 VIP 客户管理系统：

• 为主管提供带有可编辑表格的 View（inline editing）
• 包含 5 种 CRUD 操作的 Python Lambda
• 使用 DynamoDB on-demand 存储数据
• 队列优先级（Priority 1）+ 用于身份识别的 Whisper Flow

有一点非常重要：第一版 View 是由 Amazon Connect 原生 AI 生成的，但由于 schema 错误、TableAction undefined 和字段过于通用等问题而失败。最终有效的解决方案，是以 BlockList 为 template 手动创建。AI 并非永远正确——人工验证没有商量的余地。

3. 修复 CSAT 调查：大规模数据审计

一个存在了将近 2 个月的 bug，导致满意度调查以错误的 ID 写入数据——超过一千通电话受到影响，DynamoDB 中近 200 条记录的评分不正确。

• 找到了 root cause（flow 中 3 个 node 的 ID 被调换）
• 生成了带有 DRY_RUN 模式、备份机制和条件验证的历史数据修复脚本
• 在 DynamoDB 中定位了 270 多条需要修正的记录
• 编写了验证报告，提交主管审批

这种需要在确保安全的前提下进行大规模审计的工作，如果完全依靠人工，在有限时间内几乎不可能完成。

4. 解决事故：调查能力才是差异所在

在这段时间里，我总共担任了约 20 个 ticket 的 assignee。

核心认识：AI 并没有节省时间，而是改变了工作

如果有人问我“AI 节省了多少时间？”，我会诚实地回答：不多。我的日程表并没有因此空下来。真正改变的，是我所做工作的类型。

• 基于有限经验提出假设（入职仅 4 个月）
• 将文档视为“技术债务”——要么匆忙完成，要么根本不写
• 线性调查：每次只检查一个系统，在系统切换中丢失上下文

转变为：

• 交叉分析多个数据源 → 提出有数据支撑的假设
• 文档自然成为工作过程的副产品
• 结构化调查：在我穿梭于不同系统之间时，由 AI 帮助保持上下文

真正重要的衡量指标，并不是“节省了多少小时”，而是：

从理论到实践：学习与落地之旅

上半年可以清晰地分为两个阶段。

阶段 1——学习与吸收（4 月至 6 月）

从 4 月到 6 月，我的重点是吸收内容并建立理论基础。我参加了 6 场 workshop（约 22 小时）——内容涵盖 Amazon Connect 基础知识，一直到关于 Agentic AI 的 Level 400 workshop——并在 AWS Skill Builder 上完成了约 11 小时的自主课程。

对我影响最大的 workshop 包括：

• KiroOps（Level 300，4 小时）——让我理解了 Kiro 在代码分析和文档编写方面的潜力
• Blackbelt Agentic AI（Level 400，5 小时）——通过 Kiro + 企业 SSO 的真实实践，巩固了理论知识
• 基于 MCP + Salesforce 的自主 CX（Level 300，3 小时）——在 contact center 中编排自主 Agent

我还获得了 Amazon Connect AI Fundamentals badge。

阶段 2——实践与构建（7 月）

到了 7 月，我决定走出理论阶段，开始以结构化方式将 AI 应用到日常工作中。

我创建了一个 time-tracker——这是一个用于工时管理的个人项目，我会在其中记录每个 ticket 的描述和投入时间。这也是我在开发过程中首次获得生成式 AI 主动协助的项目。

随后，我又开发了一个运维 dashboard——包含 13 个页面、28 个 endpoint，并集成了 Jira、Confluence 和 AWS CLI。这个项目将所有经验整合在了一起：使用 AI 进行开发的实践、在运维工作中获得的技术知识，以及对日常工作的组织管理。

如果只谈成功经验，那是不诚实的：

• 由 Connect 原生 AI 生成的 VIP View——由于未记录在文档中的 schema 错误而失败，最终解决方案来自人工逆向工程。
• AI 提供的 SSH 命令建议——AI 无法看到服务器的真实状态，执行命令前必须进行验证。
• 包含 100 多个 block 的 flow——其上下文可能超过 AI 的 context window，因此必须拆分后再进行分析。

得到的教训是：使用 AI 的专业人士需要更多技术知识，而不是更少。AI 会放大能力，而不是取代能力。

感谢 Telecom 团队

如果没有 Telecom 运维团队，这些成果一项都不可能实现。感谢整个团队给予我的耐心与支持，也感谢大家营造出的协作文化，让一个初学者同样能够快速成长。

尤其要感谢 Carlos 和 Wallace——日常工作中分享的技术技巧、诊断问题时敏捷的思路，以及耐心讲解时展现的慷慨，让我的学习曲线得以大幅加速，而这些是任何工具都无法替代的。面对技术问题时的快速响应，以及那些可以省去数小时反复试错的捷径——这些成绩属于真实的人，属于那些愿意伸出援手、慷慨投入自己时间的人。

生成式 AI 是一款强大的工具，但真正让我能够有效使用它的知识，来自整个团队。

结语：从被动操作员到主动调查者

在 4 个月里，我从“第一次接触 Amazon Connect”，成长到让一套包含 113 个 block 的系统投入生产、完成一次大规模数据 bug 审计，并逐步具备独立解决事故的能力。

生成式 AI 并没有替我完成这一切。它改变的是我处理每个问题的方式：

• 以前：被动、线性、受限于记忆
• 现在：主动、结构化、以数据为依据

对于刚刚进入这一领域的人来说：AI 不是捷径，而是杠杆。当你知道自己在做什么时，它的效果最好；而当你仍在学习，并且身后有一支支持你的团队时，它能带来彻底的改变。

喜欢这篇文章吗？欢迎在 Dev.to 关注我，获取更多关于 AWS、GenAI 和 cloud 运维的文章。🚀

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。