在上一年里，已經(jīng)有不少的企業(yè)在工具鏈上落地了生成式 AI，結(jié)合我們對(duì)于這些企業(yè)的分析，以及最近在國內(nèi)的一些 “新技術(shù)” 趨勢(shì)，諸如于鴻蒙原生應(yīng)用的初步興起。從這些案例與趨勢(shì)中，我們也看到了一些新的可能方向。

結(jié)合我們?cè)?LLM as-Copilot，LLM as-Integrator，LLM as-Facilitator 的三階段框架，以及我們內(nèi)部的分析材料，我大體將其總結(jié)為 6 個(gè)趨勢(shì)：

1. 從單角色輔助到端到端輔助。
2. 輔助決策的知識(shí)管理。
3. AI 應(yīng)用的 DevOps 設(shè)施。
4. 線上故障定位和問題解決。
5. AI 輔助 UI 設(shè)計(jì)的涌向。
6. 代碼翻譯與系統(tǒng)間翻譯。

其中的部分知識(shí)幾乎是我們先前達(dá)到一致的，所以讓我們反過來來講述這個(gè)故事。

0. 生成式 AI 倒逼的研發(fā)數(shù)字化

在開始新的趨勢(shì)總結(jié)之前，我們不得不提及的一點(diǎn)是：研發(fā)數(shù)字化。在過去的一年里，我與差不多 10 家公司的研發(fā)相關(guān)負(fù)責(zé)人交流 AI 輔助研發(fā)。事實(shí)上，阻礙大部分企業(yè)應(yīng)用生成式 AI ，原因除了模型限制之外，還有研發(fā)的數(shù)字化水平差。

我們要面臨的第一個(gè)問題是：標(biāo)準(zhǔn)化沒有落地。簡單來說，規(guī)范化、平臺(tái)化、指標(biāo)驅(qū)動(dòng)四個(gè)成熟度來考慮問題時(shí)，有些組織還處于規(guī)范落地難的問題，更談不上指標(biāo)驅(qū)動(dòng)改進(jìn)。幸運(yùn)的是生成式 AI 結(jié)合工具可以改進(jìn)規(guī)范落地難的問題，也算是一個(gè)潛在的彎道機(jī)會(huì) —— 前提是要有足夠的魄力推進(jìn)。

除此，我們還要面臨的第二個(gè)問題是：知識(shí)的管理 —— 組織中存在大量不可言傳的知識(shí)（歪個(gè)樓，比如內(nèi)容八卦）。我們會(huì)遇到的挑戰(zhàn)有：

• 沒有記錄、沒有顯性化。
• 大量的過時(shí)的知識(shí) —— 你不知道哪個(gè)文檔是舊的。
• 大量的非文本知識(shí) —— 某天拍的會(huì)議白板，字都不認(rèn)識(shí)了。

簡單來說，這些是我們知識(shí)債務(wù)的一部分。

1. 代碼翻譯與系統(tǒng)間翻譯

場景一：遺留系統(tǒng)遷移。生成式 AI 的特性在自然語言翻譯上表達(dá)得不錯(cuò)，在編程語言上也有非常突出的表現(xiàn)。所以，去年我們也在 AutoDev 做了相關(guān)特性的分析，并構(gòu)建了一系列相關(guān)的遺留系統(tǒng)功能。而在商業(yè)產(chǎn)品上，我們也可以看到諸如 IBM watsonx Code Assistant for Z 這樣的 Cobol 轉(zhuǎn) Java 專用工具。

而如何分析遺留系統(tǒng)遷移，依舊是一個(gè)復(fù)雜的問題?，F(xiàn)有的工具更多的是由人來設(shè)計(jì)遷移，由 AI 來輔助。

場景二：系統(tǒng)間翻譯。隨著，越來越多的大廠開始開發(fā)鴻蒙應(yīng)用，我們?cè)趯?shí)踐中也發(fā)現(xiàn)了生成式 AI 在這方面的優(yōu)勢(shì)。由于移動(dòng)系統(tǒng)的 UI 差異并不大，可以通過翻譯來實(shí)現(xiàn)部分功能遷移。盡管，我們遇到大量的生成式 AI 缺少新的專有知識(shí)（ArkUI、ArkTS、HarmonyOS API），但是結(jié)合將思維鏈和 RAG 與之相結(jié)合可以達(dá)到更可接受的結(jié)果。

2. AI 輔助 UI 設(shè)計(jì)的涌現(xiàn)

AI 生成代碼需要結(jié)合現(xiàn)有的規(guī)范等信息，才能生成行之有效的代碼。對(duì)于 Spring 一統(tǒng)江湖的后端代碼開發(fā)來說，構(gòu)建這種生成式 AI 友好的架構(gòu)是一件很容易的事。但是，由于大中小型組織都有自己的品牌指南、風(fēng)格指南、設(shè)計(jì)系統(tǒng)，所以生成式 AI 在前端領(lǐng)域頗有挑戰(zhàn)。

從現(xiàn)有的模式來看，主要 AI 輔助 UI 設(shè)計(jì)可以分為三類：

• 輔助需求溝通的原型生成。
• 結(jié)合低代碼平臺(tái)的 UI 設(shè)計(jì)生成。
• 結(jié)合 IDE 插件的 UI 代碼生成。

考慮到前端需求的復(fù)雜式，顯然如果能從第二種場景入手會(huì)更容易，而場景三更適合于新手學(xué)習(xí)和使用框架、開發(fā)人員使用新框架。

3. 線上故障定位和問題解決

線上問題修復(fù)。在沒有生成式 AI 之前，傳統(tǒng)的判定式 AI 已經(jīng)能實(shí)現(xiàn)大量的自動(dòng)化。常規(guī)應(yīng)用程序性能監(jiān)控（APM）工具，可以從線上運(yùn)行時(shí)報(bào)的錯(cuò)誤，映射到對(duì)應(yīng)的出錯(cuò)代碼。PS：再結(jié)合需求與代碼的關(guān)聯(lián)信息，我們可以準(zhǔn)確推斷出哪次需求變更造成的影響。在有了生成式 AI 之后，線上的問題可以直接轉(zhuǎn)換為問題的修復(fù) PR，輔助你修復(fù)問題，諸如于 NewRelic 也有類似的功能上線。

故障定位。在包含大量子系統(tǒng)（如單個(gè)微服務(wù)）復(fù)雜的系統(tǒng)中，網(wǎng)絡(luò)與問題的排除變得異常重要。在缺乏工具時(shí)，人類也經(jīng)常在某個(gè)丟失關(guān)鍵信息，而 AI 正好可以輔助我們?nèi)ソ鉀Q此類問題，諸如于 AWS 的 AI 輔助網(wǎng)絡(luò)故障排除。

考慮到我只是 Dev 領(lǐng)域的專家，而非是 Ops 領(lǐng)域的專家，也不能解讀出更多了。

4. AI 應(yīng)用的 DevOps 設(shè)施

現(xiàn)如今已經(jīng)有大量的線上應(yīng)用引入了 AI 能力，諸如于星巴克推出的換臉活動(dòng)等等，這一類的 AI 應(yīng)用引入了一系列的 AI 基礎(chǔ)設(shè)施。因此，對(duì)于中大型組織來說 ，除了考慮合適的私有化部署模型，還需要構(gòu)建快速的 AI DevOps 基礎(chǔ)設(shè)施，以作為支撐。

除了大模型本身的各類監(jiān)測之外，我們還需要模型本身的運(yùn)營成本 —— 特別是當(dāng)你調(diào)用第三方 API 之后，以構(gòu)建更好的 AiBizDevFinGitSecOps 體系（????????）。自然而然的，我們需要有一個(gè) AI 對(duì)您的 AI + Finance 進(jìn)行建議，諸如構(gòu)建緩存機(jī)制、 Prompt 長度優(yōu)化等等。

5. 輔助決策的知識(shí)管理

知識(shí)管理在過去的是一個(gè)頭疼的問題，現(xiàn)在變成了一個(gè)全身疼的問題（暫時(shí)想不到更好的詞）。相信各位讀者已經(jīng)非常理解生成式 AI 了：

• 如果你不給他足夠的信息，它生成的結(jié)果能不能接受要靠運(yùn)氣。
• 如果你給他足夠的信息，它總會(huì)忽略一些重要的信息，以讓你生氣。

不管氣不氣的，當(dāng)你開始思考落地的時(shí)候，就會(huì)開始假設(shè)：當(dāng)我有一個(gè)架構(gòu)規(guī)范的時(shí)候，生成式 AI 可以輔助會(huì)做架構(gòu)決策。然后，你會(huì)發(fā)現(xiàn)找不到一個(gè)符合要求的架構(gòu)規(guī)范。相似的，在其他的場景之下，也有類似的問題。

PS（歪個(gè)樓）：所以，你應(yīng)該考慮到知識(shí)管理的優(yōu)先級(jí)也提上去，這樣當(dāng)你和領(lǐng)導(dǎo)匯報(bào)的時(shí)候，就可以合理的甩鍋了。

6. 從單角色輔助到端到端輔助

事實(shí)上，上述的大部分內(nèi)容都是關(guān)于 AI 如何從單角色輔助轉(zhuǎn)換為端到端輔助，只是需求從不同的場景出發(fā)。

端到端輔助的難點(diǎn)并非工具或者 prompt 本身的設(shè)計(jì)難問題，而是流程、規(guī)范是否實(shí)施到位。如果流程與規(guī)范本身存在問題，那么就需要從不同的場景出發(fā)，探索是否存在更合適的策略。

其它以及 AI 的總結(jié)

當(dāng)然了，還有過去我們討論的即時(shí)輔助問題修復(fù)等等 AI 輔助研發(fā)場景。

這篇文章展望了 2024 年 AI 輔助研發(fā)的趨勢(shì)，特別強(qiáng)調(diào)了 AI 技術(shù)從簡單輔助單一角色向端到端輔助的發(fā)展。作者首先提及了研發(fā)數(shù)字化在AI應(yīng)用中的重要性，并指出了標(biāo)準(zhǔn)化和知識(shí)管理的挑戰(zhàn)。然后，他詳細(xì)介紹了六大趨勢(shì)：

• 從單角色輔助到端到端輔助：AI 技術(shù)不再局限于單一角色的輔助，而是擴(kuò)展到整個(gè)研發(fā)流程的各個(gè)環(huán)節(jié)。
• 輔助決策的知識(shí)管理：AI 在知識(shí)管理方面的應(yīng)用變得更加重要，但也面臨著信息不完整和信息選擇的問題。
• AI 應(yīng)用的 DevOps 設(shè)施：AI 應(yīng)用的引入需要建立適應(yīng)性強(qiáng)的 DevOps 基礎(chǔ)設(shè)施來支撐其運(yùn)行和監(jiān)控。
• 線上故障定位和問題解決：AI 在線上故障定位和問題解決方面的應(yīng)用也逐漸成熟，能夠幫助快速定位問題并提供解決方案。
• AI輔助UI設(shè)計(jì)的涌現(xiàn)：AI 在 UI 設(shè)計(jì)方面的應(yīng)用呈現(xiàn)出多種形態(tài)，包括輔助需求溝通、低代碼平臺(tái)的 UI 設(shè)計(jì)生成以及 IDE 插件的 UI 代碼生成。
• 代碼翻譯與系統(tǒng)間翻譯：AI 在代碼翻譯和系統(tǒng)間翻譯方面的應(yīng)用逐漸成熟，特別是在遺留系統(tǒng)遷移和系統(tǒng)間功能遷移方面的表現(xiàn)。

文章最后提到了即時(shí)輔助問題修復(fù)等其他AI輔助研發(fā)場景，并總結(jié)了端到端輔助的難點(diǎn)在于流程和規(guī)范的實(shí)施。