在上一年裏，已經有不少的企業在工具鏈上落地了生成式 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輔助研發場景，並總結了端到端輔助的難點在于流程和規範的實施。
