在上一年里，已经有不少的企业在工具链上落地了生成式 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 体系（🐶🐶🐶🐶）。自然而然的，我们需要有一个 AI 对您的 AI + Finance 进行建议，诸如构建缓存机制、 Prompt 长度优化等等。
2. 辅助决策的知识管理
知识管理在过去的是一个头疼的问题，现在变成了一个全身疼的问题（暂时想不到更好的词）。相信各位读者已经非常理解生成式 AI 了：
如果你不给他足够的信息，它生成的结果能不能接受要靠运气。
如果你给他足够的信息，它总会忽略一些重要的信息，以让你生气。
不管气不气的，当你开始思考落地的时候，就会开始假设：当我有一个架构规范的时候，生成式 AI 可以辅助会做架构决策。然后，你会发现找不到一个符合要求的架构规范。相似的，在其他的场景之下，也有类似的问题。
PS（歪个楼）：所以，你应该考虑到知识管理的优先级也提上去，这样当你和领导汇报的时候，就可以合理的甩锅了。
1. 从单角色辅助到端到端辅助
事实上，上述的大部分内容都是关于 AI 如何从单角色辅助转换为端到端辅助，只是需求从不同的场景出发。
端到端辅助的难点并非工具或者 prompt 本身的设计难问题，而是流程、规范是否实施到位。如果流程与规范本身存在问题，那么就需要从不同的场景出发，探索是否存在更合适的策略。
其它以及 AI 的总结
当然了，还有过去我们讨论的即时辅助问题修复等等 AI 辅助研发场景。
这篇文章展望了 2024 年 AI 辅助研发的趋势，特别强调了 AI 技术从简单辅助单一角色向端到端辅助的发展。作者首先提及了研发数字化在AI应用中的重要性，并指出了标准化和知识管理的挑战。然后，他详细介绍了六大趋势：
从单角色辅助到端到端辅助：AI 技术不再局限于单一角色的辅助，而是扩展到整个研发流程的各个环节。
辅助决策的知识管理：AI 在知识管理方面的应用变得更加重要，但也面临着信息不完整和信息选择的问题。
AI 应用的 DevOps 设施：AI 应用的引入需要建立适应性强的 DevOps 基础设施来支撑其运行和监控。
线上故障定位和问题解决：AI 在线上故障定位和问题解决方面的应用也逐渐成熟，能够帮助快速定位问题并提供解决方案。
AI辅助UI设计的涌现：AI 在 UI 设计方面的应用呈现出多种形态，包括辅助需求沟通、低代码平台的 UI 设计生成以及 IDE 插件的 UI 代码生成。
代码翻译与系统间翻译：AI 在代码翻译和系统间翻译方面的应用逐渐成熟，特别是在遗留系统迁移和系统间功能迁移方面的表现。
文章最后提到了即时辅助问题修复等其他AI辅助研发场景，并总结了端到端辅助的难点在于流程和规范的实施。
