在上一年里，已经有不少的企业在工具链上落地了生成式 AI，结合我们对于这些企业的分析，以及最近在国内的一些 “新技术” 趋势，诸如于鸿蒙原生应用的初步兴起。从这些案例与趋势中，我们也看到了一些新的可能方向。
结合我们在 LLM as-Copilot，LLM as-Integrator，LLM as-Facilitator 的三阶段框架，以及我们内部的分析材料，我大体将其总结为 6 个趋势：
- 从单角色辅助到端到端辅助。
- 辅助决策的知识管理。
- AI 应用的 DevOps 设施。
- 线上故障定位和问题解决。
- AI 辅助 UI 设计的涌向。
- 代码翻译与系统间翻译。
其中的部分知识几乎是我们先前达到一致的，所以让我们反过来来讲述这个故事。
0. 生成式 AI 倒逼的研发数字化
在开始新的趋势总结之前，我们不得不提及的一点是：研发数字化。在过去的一年里，我与差不多 10 家公司的研发相关负责人交流 AI 辅助研发。事实上，阻碍大部分企业应用生成式 AI ，原因除了模型限制之外，还有研发的数字化水平差。
我们要面临的第一个问题是：标准化没有落地。简单来说，规范化、平台化、指标驱动四个成熟度来考虑问题时，有些组织还处于规范落地难的问题，更谈不上指标驱动改进。幸运的是生成式 AI 结合工具可以改进规范落地难的问题，也算是一个潜在的弯道机会 —— 前提是要有足够的魄力推进。
除此，我们还要面临的第二个问题是：知识的管理 —— 组织中存在大量不可言传的知识（歪个楼，比如内容八卦）。我们会遇到的挑战有：
- 没有记录、没有显性化。
- 大量的过时的知识 —— 你不知道哪个文档是旧的。
- 大量的非文本知识 —— 某天拍的会议白板，字都不认识了。
简单来说，这些是我们知识债务的一部分。
6. 代码翻译与系统间翻译
场景一：遗留系统迁移。生成式 AI 的特性在自然语言翻译上表达得不错，在编程语言上也有非常突出的表现。所以，去年我们也在 AutoDev 做了相关特性的分析，并构建了一系列相关的遗留系统功能。而在商业产品上，我们也可以看到诸如 IBM watsonx Code Assistant for Z 这样的 Cobol 转 Java 专用工具。
而如何分析遗留系统迁移，依旧是一个复杂的问题。现有的工具更多的是由人来设计迁移，由 AI 来辅助。
场景二：系统间翻译。随着，越来越多的大厂开始开发鸿蒙应用，我们在实践中也发现了生成式 AI 在这方面的优势。由于移动系统的 UI 差异并不大，可以通过翻译来实现部分功能迁移。尽管，我们遇到大量的生成式 AI 缺少新的专有知识（ArkUI、ArkTS、HarmonyOS API），但是结合将思维链和 RAG 与之相结合可以达到更可接受的结果。
5. AI 辅助 UI 设计的涌现
AI 生成代码需要结合现有的规范等信息，才能生成行之有效的代码。对于 Spring 一统江湖的后端代码开发来说，构建这种生成式 AI 友好的架构是一件很容易的事。但是，由于大中小型组织都有自己的品牌指南、风格指南、设计系统，所以生成式 AI 在前端领域颇有挑战。
从现有的模式来看，主要 AI 辅助 UI 设计可以分为三类：
- 辅助需求沟通的原型生成。
- 结合低代码平台的 UI 设计生成。
- 结合 IDE 插件的 UI 代码生成。
考虑到前端需求的复杂式，显然如果能从第二种场景入手会更容易，而场景三更适合于新手学习和使用框架、开发人员使用新框架。
4. 线上故障定位和问题解决
线上问题修复。在没有生成式 AI 之前，传统的判定式 AI 已经能实现大量的自动化。常规应用程序性能监控（APM）工具，可以从线上运行时报的错误，映射到对应的出错代码。PS：再结合需求与代码的关联信息，我们可以准确推断出哪次需求变更造成的影响。在有了生成式 AI 之后，线上的问题可以直接转换为问题的修复 PR，辅助你修复问题，诸如于 NewRelic 也有类似的功能上线。
故障定位。在包含大量子系统（如单个微服务）复杂的系统中，网络与问题的排除变得异常重要。在缺乏工具时，人类也经常在某个丢失关键信息，而 AI 正好可以辅助我们去解决此类问题，诸如于 AWS 的 AI 辅助网络故障排除。
考虑到我只是 Dev 领域的专家，而非是 Ops 领域的专家，也不能解读出更多了。
3. AI 应用的 DevOps 设施
现如今已经有大量的线上应用引入了 AI 能力，诸如于星巴克推出的换脸活动等等，这一类的 AI 应用引入了一系列的 AI 基础设施。因此，对于中大型组织来说 ，除了考虑合适的私有化部署模型，还需要构建快速的 AI DevOps 基础设施，以作为支撑。
除了大模型本身的各类监测之外，我们还需要模型本身的运营成本 —— 特别是当你调用第三方 API 之后，以构建更好的 AiBizDevFinGitSecOps 体系（
