正文
为了为未来做好准备，开发者需要加深对 AI 的理解，掌握提示词工程（了解 AI 擅长的领域和盲点在哪里），并学习新的工具和实践。工程师必须通过专注于系统设计、架构、领域专业知识和批判性思维技能来适应变化。AI 工具可以自动化某些编码任务，但理解复杂系统、确保安全性和将业务需求转化为技术解决方案的能力仍然是人类独有的，对于维持职业的持久性来说至关重要。软件工程的未来在于那些能够将人类解决问题的能力与 AI 功能相结合的人，他们能够提供更快更好的解决方案，而不仅仅是生成更多的代码。
现代分布式系统的规模和复杂性已经超出了人类对传统监控、故障排除、安全和运营的能力。随着 AI 辅助代码生成加快开发速度，未来应用程序的规模和复杂性只会随之增加。传统可观察性方法——手动检查日志、基于阈值的警报和静态仪表盘——正变得越来越不起作用。监控和维护 AI 生成应用程序的唯一可行途径将是使用 AI 驱动的工具，这些工具能够实现与可观察性数据的自然语言交互、预测性问题检测与模拟、自动化根本原因分析，以及在需要最少监督的情况下进行总结和补救。
主要的可观察性供应商，如 New Relic、Splunk 和 DataDog，已经将 AI 整合到他们的应用性能监控（APM）工具中。这些增强功能使得从海量遥测数据中提取可操作的见解成为可能，减轻了认知负担并加快了事件解决速度。传统机器学习和 GenAI 在现代可观察性和 安全性 领域的常见应用包括：
-
预测性分析：这种方法通过分析过去的攻击数据来发现复杂模式并识别潜在威胁。AI 可以使用真实和合成数据集模拟攻击场景。
-
行为分析：与预测性分析（检查历史趋势）不同，行为分析侧重于实时用户活动。AI 可以检测可能表明凭证被泄露或存在内部威胁的模式，而传统的安全工具通常会忽略这些模式。
-
异常检测：AI 持续监控网络流量、系统日志和 API 交互数据，以便发现与既定规范的意外偏差。AI 通过生成合成异常、对检测模型进行压力测试和加强针对零日攻击和新兴威胁模式的防御来增强这一过程。
-
根本原因分析：传统根本原因分析通常涉及筛选海量日志、关联指标、阅读非结构化文档和手动识别模式——这是一个缓慢且容易出错的过程。AI 驱动的平台（如 Resolve.ai）通过聚合整个操作堆栈的数据——从基础设施指标和应用追踪到部署历史和文档——来自动化这一过程。
自动化根本原因分析（示例：Resolve.ai）
对于运维团队而言，AI 将可观察性从认知密集型的信号匹配转变为自动化、可操作的洞见。AI 可以处理来自维基和聊天对话的非结构化数据，将遥测数据与代码变更联系起来，生成动态的事件仪表盘，并提出具体的解决方案，包括逐步的说明。例如，如果某个服务出现延迟峰值，AI 可以立即将这些峰值与最近的部署、基础设施变更以及过去类似的事件相关联。此外，AI 能够确定根本原因，并在一个自动生成的仪表盘上展示调查结果，同时在公司的 Slack 频道中请求恢复确认。这种程度的自动化减少了平均解决时间（MTTR），将运维从被动式的救火转变为主动式的问题预防。最重要的是，它捕获了记忆，将每个事件变成未来可参考的教训。
要在这个新的环境中生存下来并蓬勃发展，运维团队必须积累使用 AI 驱动的运维工具的专业知识，从编写长查询、解析日志和手动编写自动化脚本转变为设计全面的可观察性策略，引导 AI 系统做出我们所期望的行为。尽管 AI 可以处理大量的运维数据并提出解决方案，但运维人员需要理解系统架构、业务背景和影响分析策略，以便评估这些建议并做出明智的决策。
对于软件的采用来说，好的软件文档一直是至关重要的，无论是开源项目还是商业 SaaS 产品。软件 文档 包括：面向初学者的教程、针对特定任务的指南、提供详细信息的参考指南以及用于帮助人们进行深入理解的解释性内容。尽管这种结构仍然还有价值，但随着软件的演变速度越来越快，保持文档的准确性和相关性变得越来越具有挑战性。
基础 AI 模型的一个主要限制在于知识的陈旧和过时。但随着检索增强生成（RAG）的兴起，LLM 可以通过直接从代码库、API 规范和文档存储库中提取数据来提供实时且最新的响应。凭借这种能力，AI 正在改变文档的编写方式和开发者与文档的互动方式。CrewAI 的 “与文档聊天” 功能让开发者不再需要手动搜索大量文档或 StackOverFlow 网页，而是使用 AI 驱动的聊天界面来获取相关答案。在新的软件项目中，开发者越来越多地利用 LLM 的实时代码生成和执行能力，通过编码来了解项目。文档领域的最新发展包括：
