前言
回望2023 年， 的突然爆火，讓AI 無疑成為最為值得注目的新興領域之一，我們也一起見證了生成式AI 的寒武紀大爆發。這一年來，國內外的生成式AI 、大模型和相關產品以令人眼花撩亂的速度更新迭代，新的創業浪潮風起雲湧。在這AI 浪潮下，也讓我們有了新的開發思考，探索著在各個環節中「前端& AI」的應用場景。勇於探索的前端開發者們已經開始揮舞著AI 的“魔法棒”，譬如代碼生成、輔助CR、低代碼、測試、業務提效等各類開發環節都被賦予了新的活力和可能性。
在經歷長時間與複雜項目「搏鬥」 的你，是否對不斷重複的工作感到厭倦？
當你面對上萬行的程式碼的Code 時，是否也曾讓你感到力不從心？
業務遇到發展瓶頸，是否你也會把希望寄託於AI 相關應用為其註入活力？
當面對種種類似問題時，你是否也曾幻想過有這樣一個神器幫你勝任瑣碎的語法檢驗、程式碼梳理、模組測試甚至是整體搭建呢？
AI 技術的不斷成熟，讓這些夢想開始變得觸手可及。 AI 工具如同瑞士軍刀般，其功能與用途變得越來越多樣，它們正在幫助我們更有效地解決問題、提高效率，將想像中的可能變成現實。在本次大盤點中，我們將聚焦近一年AI 相關技術在前端領域的趨勢與未來展望，將一一回答上述疑問，幫助讀者挖掘從業者的新機會，迎接AI 的挑戰與機遇。
如果你對AI & 前端有興趣，請一定要讀下去，相信我們的精心準備一定不會讓你失望～
“勇敢實踐AI 的人，將最先享受世界”
AI & 代碼生成
一切故事開始來自於的橫空出世，讓世界看到了AI 寫程式的能力。大語言模型能寫演算法題、能寫遊戲、能寫網站，不僅寫的又快又好，還能直接運行，AI 的表現讓人驚訝，人們開始感嘆：「程式設計師的職業恐將不復存在！
不過只是在的對話框裡和AI 交流代碼技術還是不夠方便，於是，已經默默存在了一段時間的AI 代碼生成輔助工具們乘勢而起，成為了爆火產品。代表有，，，，， 等，其中有自研模型工具，也有套用模型服務主打產品互動和的工具。
AI 程式碼產生可以細分為許多場景，例如自然語言產生程式碼，單元測試，程式碼重構，程式碼續寫，程式碼解釋，程式碼評審，問答助理。 AI 代碼生成工具的出現顛覆了程式設計師的工作方式，影視作品中對著機器人說兩句話就完成程式設計的時代彷彿就在眼前了。
生態現狀及使用體驗
但我們拋開博人眼球的新聞，AI 代碼生成效果如何？程式設計師真的要失業了嗎？
以下是AI 產生的程式碼在日常開發過程中的一些親身體會：
總的來說，AI 代碼生成這件事經過了一年時間的考驗，彷彿變成了食之無味棄之可惜的雞肋骨，程式設計師戰戰兢兢使用AI 生成著代碼，卻驚喜地發現這東西一時半會還替代不了自己。
退而求其次，讓AI 打打下手吧，AI 產生的程式碼，修改一下，可以使用嗎？
在日常開發中，AI 已被業界許多工具證明可以提高開發效率。但如果程式碼量快速膨脹，人類還改的過來嗎？如果隨著AI 生產力進一步提升，當程式碼檢查成為效率的瓶頸時，大量未經人類把關的AI 程式碼直接用在生產環境，人類真的敢用嗎？
AI & 程式碼重構的探索為什麼要做重構？
在AI 程式碼產生的眾多細分場景中，程式碼重構是相對來說是一次產生程式碼量最大的場景之一，同時又因為有原始程式碼邏輯可對照，它產生的程式碼的評判標準又相對明確。於是程式碼重構場景成為了很好的觀察對象。
在沒有AI 工具的時代，程式設計師們也持續做程式碼重構，工程在迭代過程中逐漸腐壞，需要不同程度的重構去確保迭代效率。同時重構的專案總不會是剛寫沒多久就開始重構的，所以重構總是伴隨著大量的、難以追溯的業務邏輯。在這個過程中，陳年邏輯理解到位？再次實作是否能保證沒有bug？這些問題都折磨著每個做重構專案的程式設計師。
AI 隨著時代的洪流登場了。大家都知道程式碼重構是麻煩又危險的操作，如果AI 能代勞，既保持了程式碼的可維護性，又沒有程式設計師因為實施重構而失去頭髮。在實務中，我們的業務剛好有程式碼重構的需求： 陳年的Vue 程式碼希望重構成React 版本，目標透過重構使團隊技術堆疊保持統一，同時完成一些針對舊專案的效能最佳化動作。
AI 的表現如何？
考慮到AI 已經被鼓吹可以取代人類，那麼人類程式設計師能做到的程式碼重構效果，AI 也一定能做到，所以一開始在提示詞中希望它在重構的過程中優化文件結構，移除冗餘程式碼，同時保持原始邏輯不變。這是一個非常「普通且自信」的想法：既要、又要、還要。
於是溝通遇到的第一個問題出現了，即使將複雜的任務拆分，人類也很難用自然語言明確告知模型，怎麼樣算優化文件結構，什麼樣的邏輯是冗餘邏輯，畢竟人類程序員還要經過反覆的需求討論才能逐漸確認需求的全部細節。於是一步到位的提示詞方案被否定。
接下來對AI 的要求是：文件對文件，邏輯對邏輯進行程式碼轉換，不必做過程中的最佳化和調整。這樣任務就簡單了許多，降低了溝通成本，指令的下達變得明確而有效率。
隨著專案的推進，又遇到了類似的問題：對於混雜在多任務中的簡單小任務，AI 無法做到，無論是明確定義、增加範例、反覆強調、給予鼓勵。 例如特定第三方元件庫的使用參數，JSX 條件渲染的實作等。這時問題可能出現在這些小任務集合觸碰到了AI 能力的上限，除非針對特定任務精調，去提升它在任務中的表現。
去評判AI 的表現，總的來說還是溝通和能力邊界的問題。對於業務中使用的某個具體模型，它的能力邊界不完全確定，由於模型內部邏輯原理的不可解釋性，提示詞工程師（ ，PE）們只能不斷猜測、試驗，而在這其中投入多少精力的度，是不確定的。另外考慮到AI 的幻覺問題，如何評判“勝任”，如何確保AI 每一次任務都“勝任”也是一個挑戰。所以這充滿不確定的溝通調試過程，影響了AI 程式碼產生的效果，較低的程式碼產物品質讓它們暫時無法被信任地直接用於生產環境。
總結
就像人之間的信任一樣，AI 的信任是逐漸建立的，從簡單的任務到複雜的任務如果都能逐一勝任，那麼人類對AI 的信任就會增加。對於AI 出現的失誤，並不是不被允許，只是這些失誤需要是可解釋的，並且有規律可規避的。 對AI 更進一步的期待是，其內部的運作邏輯是可解釋的，其行為是可控的。
我們期待這一天的到來，期待AI 成為人類更可信任的工作夥伴。
AI & 測試
你可能會覺得“啊，既然AI 程式碼生成問題那麼多，那麼退一步讓AI 來測試吧”，但是，實際上AI 測試當前也有著數不盡的問題。本小節將會詳細拆解這些問題來逐一分析。
AI 與測試相關的問題
這裡面牽涉到很多很虛無縹緲的東西，你可能還會說「廢話少說，直接告訴我最佳實踐」。然而事實是，別說最佳實踐，以至於截止到2023 年，前端+ 大語言模型+ 測試的實踐幾乎為0。如果你在搜索，倉庫不超過10 個，合計的Star 數加起來5 個都不到。
為什麼？為什麼感覺這麼「前途無量」的場景連倉庫都沒幾個？
這個問題很難用一句話來解釋清楚，但是我向你保證，看完這節，你一定會得到答案。
單元測試
先說實作起來最簡單的單元測試。單元測試非常的直白，就是用一段純JS 程式碼來測試另一段純JS 程式碼，比較結果，一樣就成功不一樣的就失敗。這麼簡單的任務，強如GPT-4，不會做不到吧？
能做到，但是不能完全做到。
其實在AI + 單元測試，在LLM 出現之前，業界就已經有很多很多的實踐了，而在LLM 後，又崛起了一批LLM + 單元測試的試驗品。但我打賭讀者一個也沒聽過對不對？沒聽過就對了，因為就算有了LLM 的助力，效果依舊一言難盡，根本拿不出手。
接受率
在這裡引入一個接受率的概念。簡單來說就是AI 產生了100 個用例，哪些是可以直接使用的。假如有80 個可以不經修改的直接使用，那麼接受率就是80 / 100 = 80%。
但這裡有個非常尷尬事情——並不是說接受率> 0% 那麼就可以用，因為你依舊需要花精力在那些「不可用的用例」中。
假如接受率是40%，AI 產生了100 個用例，你其實並不知道這100 個用例中哪40 個是正確的，而為了使用這40 個正確的用例，你需要：
想辦法將可用的用例挑出來，並逐一驗證將剩下不可用的用例一個一個改好重新整體檢查，手動填補用例遺漏
假如接受率真的是40%，這個過程將會是地獄，將遠遠超越你自己寫100 個用例的時間。
好了，那麼讀者不妨在此猜測一下，那麼在LLM 之前和之後，AI 單元測試的接受率是多少？
單元測試的進一步分析
透過接受率小節，我們所了解的接受率必須高到一定閾值才有意義，否則就是單純的把「寫用例」變成了「調用例+改用例」。根據我們的估計，接受率至少要達到80% 以上，否則就完全是在幫忙。
而目前LLM + 單元測試普遍的接受率僅為50% 不到，而如果是用NLP 來代替LLM，則接受率將低到30% 以下：
Pass@10[%] 代表AI 拿到錯誤訊息再次迭代，嘗試了10 次
這就好比有個實習生，寫了10 個頁面，其中：
2 個頁面看起來正常，實際上交互有各種問題和巧妙的Bug4 個頁面運行正常，但是和上面這種頁面混在一起了，你需要測試後才能找到他們2 個頁面打開就白屏，你簡單修改幾次它還是白屏，你也不知道具體為啥，需要慢慢調2 個頁面忘做了
這種實習生你要嗎？因此，AI & 單元測試依舊要求程式設計師擁有極強的單測完善能力，它不能取代你來直接完成單元測試。
其他測試
單元測試包含了太多的細節和邊界情況，那麼我們把視野拉遠，例如E2E 測試，是不是會好一點呢？正好前端單測用的也不多。
別說，你還真別說，當我們聚焦在E2E 而不是單測後，各種問題確實是迎刃......增加了~！
當你想使用AI + E2E 後，第一件事就是－怎麼讓AI 和瀏覽器互動。目前在這方面，業界沒有任何的實踐，所有的膠水程式碼都必須由你來發展。
目前GPT 確實有檢索和理解網頁的能力，但僅限於內容的理解。無法做到對於前端頁面互動的理解，例如在選擇框來選擇某項
在單元測試中，我們可以很容易的“報錯後直接發給AI，讓AI 多試幾次”，但是這個交互流程在E2E 情景下是沒有相關實踐的，其中伴隨很多的開發工作。
同樣的，AI 對於一個網頁的理解是非常有限的，他並不知道一個使用者互動是錯誤的還是正確的，你可能還需要傳遞給AI 一些背景資料，例如產品文件、測試案例、互動圖、程式碼。這部分的序列化工作也是一個全新的領域，所有的膠水程式碼都必須由你來發展。
如果你不是在大型IT 公司，開發膠水程式碼成本是難以接受的。它可能要花費一年的時間，且過程中沒有任何階段性產出，部分功能隨時可能被新一代的LLM 所取代。
總結
透過單元測試和E2E 測試的分析，相信讀者已經明白了的當前AI & 測試面臨的主要挑戰：
如何序列化讓AI 理解現況上下文過低接受率導致的額外人工介入的成本
但是我們相信這些這些問題都是有解的。可能是更聰明的LLM 提高了接受率，可能是規範的合作方合作流程，例如測試用例寫的足夠可讀，並能直接導出為表格發送給LLM，也可能是某個公司大筆一揮，決定花一年來開發一個AI E2E 測試框架。
現在，軟體測試的世界在等待一位英雄，他手持LLM 的利劍，徹底斬除軟體開發的品質痛點。而那位英雄，會不會是正在閱讀這篇文章的你呢？
AI & 輔助CR
除了開發與測試，換個角度看問題，如果讓AI 來當我們的CR 助理呢？
程式碼審查（）是軟體開發過程中的重要環節，Code 是指開發人員對彼此的程式碼進行審查和評估的過程。透過Code ，團隊成員可以相互檢查程式碼的正確性、可讀性、可維護性以及是否符合編碼規範等方面的問題。可以幫助開發者發現並修復程式碼中的錯誤和缺陷，提高程式碼質量，減少技術債。
傳統的程式碼審查由人工完成，團隊在Code 上花費了大量時間，且容易出現疏漏。隨著大型語言模型（LLM）的發展，LLM 在程式碼審查領域得到了越來越多的關注。 LLM 可以透過對程式碼的語意理解，快速識別程式碼中的錯誤和缺陷，從而提高程式碼審查的效率和準確性，以下是AI Code 的幾個好處：
AI 在Code 的場景
LLM 在程式碼審查領域的應用主要有以下幾個面向：
目前應用
目前業界有不少AI Code 的能力應用，除了大家熟知的，開發者對其進行提問可以幫助完成Code 的動作，我們再看一下還有哪些成熟的應用。
-
透過所呼叫的Open API 以的形式整合到裡面，機器人會自動進行程式碼審查，審查資訊將顯示在pr / file 部分。在git push更新PR 之後，CR bot 將重新審查更改的檔案：
PR-Agent
PR-Agent：一款基於的開源工具，可協助高效審查和處理拉取請求。它自動分析pull ，並提供多種類型的命令：自動產生PR 描述、可調整的回饋、問題解答、程式碼建議、更新.md 檔案、尋找類似問題、自動新增文件、產生自訂標籤和自動分析PR變更。
總結
如果你決定開始使用AI 能力作為團隊CR 助手，請注意：
一言以蔽之，當前只是輔助人工幫助快速發現一些問題，減輕人工的簡單重複的勞動，但無法完全取代人，最終還得由人作判斷，但我們可以用節省下來的人力關注到更高優的事情上面。
AI & 低代碼
前兩年火爆的低程式碼概念，似乎和AI 有不錯的“緣分”，兩者結合往往能達到一加一大於二的效果。
什麼是低程式碼
低程式碼開發平台（英文：Low-Code ，簡稱LCDP），是一種方便產生應用程式的平台軟體，軟體會讓使用者以圖形化介面以及配置編寫程序，而不是用傳統的程式設計作法。此平台是針對某些種類的應用而設計開發的，例如資料庫、業務流程以及使用者介面（例如網頁應用程式）。這類平台一般可以產生完整且可運作的應用程式碼， 但在一些特殊的情況下仍需要編寫程式。
低程式碼概念最早出現在1982 年《無程式設計師的應用程式開發》一書中，美國低程式碼產品的研究和實踐過程較長，累積了較豐富的經驗。中國最早出現低程式碼平台大概是在2014 年，產品的形態從最初的資料庫交付，到資料集結構搭建逐漸演變抽象化各種流程引擎、視覺化介面等產品能力，應用能力也從BPM 延伸到ERP、 CRM 等大型複雜應用，整個產業經歷了2017-2020 年的快速發展階段，市場成長率開始放緩，但相對於其他企業服務賽道仍處於高成長階段，預計2025 年中國低程式碼產業市場規模將達到118.4 億。
存在問題
但低程式碼自出現以來，一直還是飽受質疑，核心的點在於透過低程式碼的視覺化搭建大大降低了建設成本，且使用群體從開發人員逐步向業務人員滲透，但低程式碼本身是存在一定的上手門檻，包括各類物料的用法、如何實現與後端接口通信、物料之間如何配置交互等等，這使得業務人員無法快速上手完成頁面搭建，而開發人員需要學習特定搭建規則和限制，可能不如實際開發來的快。
在不同類型的低程式碼產品的相關的限制又會有所差異，從應用場景上可以劃分通用型和垂直型
低程式碼產品本身的易用性有待進一步提升，包括底層技術框架和視覺化介面的呈現，另外低程式碼相關的訓練機制有待完善，訓練不足導致使用者對於低程式碼產品的接納度低，使用者本身對於繁重的產品使用學習的意願不足，也會大大阻礙低程式碼產品的推廣與應用。
如何賦能
隨著GPT 為代表大模型爆火，AIGC 也開始在各行業滲透，借助大語言模型的能力精準識別用戶需求，進而徹底改變當前低程式碼搭建工作流程。透過自然語言互動取代原有選擇、編輯、拖曳等操作，從而屏蔽了低程式碼平臺本身的使用規則，這大大降低用戶的學習上手成本，進而提升低程式碼的應用場景和建置效率。未來AI 能力將會成為低程式碼平台的標配，成為未來重要的發展方向。
目前階段，各個低程式碼平台都在摩拳擦掌，躍躍欲試，許多平台已經逐步上線自己的AI 融合能力，一些典型場景包括：
透過自然語言完成頁面創建，主要應用在通用型低代碼平台中，來避免大量物料和模版的學習選擇成本，釘釘宜搭、織信、易鯨雲都上線了這部分能力，比如在宜搭平台上線了透過簡要描述入口網站的基本訊息，系統將智慧化地按需產生入口網站的能力。
核心邏輯在於透過自然語言精準辨識使用者需求，搭配合適的物料、模版，完成內容生成，進一步組裝形成DSL 進行渲染。
聚焦低程式碼平台建構中的局部場景，如公式編輯器、流程編排、智慧表格、輔助程式設計等，透過自然語言來取代原有搭建方式，進而降低整體搭建複雜度，這麼做的優勢在於將自然語言聚焦特定局部場景的優勢，也可以讓需求辨識更加精準，下圖是易鯨雲透過自然語言自動化完成流程編輯的效果。
透過將低程式碼平台中沉澱的大量的文字、視訊資料餵給大語言模型，來提升用戶問題解決效率，節省營運成本。當然不只是低程式碼，智慧文檔這一幕適用各類平台。
總結
當然AIGC 與低程式碼的融合還處於早期階段，目前應用範圍也主要還是在一些容錯率較高的場景，透過大語言模型可能無法完全理解使用者的真實需求，這需要龐大的脈絡做支撐，雖然融合方向仍有許多問題亟需解決，但未來低程式碼平台必將會全面擁抱AIGC，這也意味著我們需要重新去思考低程式碼平台的互動介面的設計，充分利用自然語言互動特點，提升使用者體驗。
另外資料安全風險也是在商業化產品中必須考慮的一點，因此多數企業都在嘗試走自研大模型的路子，然而這並不是一件容易的事。它需要大量高品質資料的收集、清洗和標註，以及昂貴的運算資源來支援模型訓練。這也意味著未來AI 加持下的低程式碼平台的競爭成本會更高，會更聚焦在有雄厚實力的頭部企業。
除了AIGC +低程式碼融合之外，還有一方觀點認為既然AIGC 能力越來越強，是否會完全取代低程式碼，直接產生原始應用？我們認為至少在可以預見很長範圍內低程式碼不會被完全替換掉，就像上面幾部分提到的，大模型透過語意直接產生程式碼並不能保證其完全的準確性，且程式碼可用性需要大量的人工校正。而低程式碼融合AIGC 可以透過語意產生模型，加速需求分析工作進程，可以讓AI 更快的進入業務。
AI & 業務
說到業務，以下就用各大互聯網企業中最常見的審核業務作為例子來進行探討：
思考
對於審核業務與AI ，可能大家的第一反應就是，AI 是否能完全取代審核員對內容進行審核呢？
我們認為未來是可以的。 內容對人類來說，無非也是來自聲光電的刺激。而當這些聲光電的刺激能被模型接受、理解、推理後，就做到了和人類一樣的事。而且，相比較人，它更容易管理，標準更統一，成本也會更低。
但現階段，就像推測會被替代的所有工作類型一樣，還有太多的問題要解決了。 AI 會作為不同的工具形態，慢慢融入人們的工作；但距離完全替代，還有不小的距離。
所以業務上，我們也在思考，它能不能也輔助審核員，取得更好的審核品質與效率。也嘗試了一些demo 項目，想知道AI 能做到什麼地步，這有助於我們探索業務場景上所能做到的極限。
但即使我們只是想讓他作為一個額外的資訊來源，來輔助審核員來的判斷，也存在著非常多現階段需要解決的問題：
其中，合規和標準、人為限制可以透過使用私有的開源大模型來解決，但也需要持續進行效果的調優。
但依然也可以看到，在過去的2023年，大模型業界，很多問題被研究，很多的方案被提出，也有很多的場景逐步落地，曙光變成了朝霞，荒野也被勇敢探索的人踏出了小路。
當然，除了審核本身，對於其他平台業務來說，什麼是未來平台產品的範式：AI 在其中解決什麼問題，扮演什麼樣的角色。隨著業界方案成熟和持續的思考，也可以有計劃地整合到我們的平台中。
可能性
23年，AI 技術上也在不斷的發展，這給了業務更多思考空間，如何合理的在業務中使用這些技術。
在模型和基礎建設上，能看到下面這些現象：
有不同參數量、架構、資料集的模型探索
開源大模型能力的不斷提升
不同參數量級的，影片/圖片理解，各項的分數上限不斷刷新。
.co//Hugg…
本地小模型對性價比的平衡
模型工程化與部署的難度降低，規範增強
而在應用層，我們可以參考一些現在實用程度較高的方案，思考它們如何在業務中結合：
基礎能力
RAG： 在基礎的方案中，基於索引以及固定資料分片的檢索，會不會得到那麼好的效果。所以到現在大多數都是結合其他的技術進行，以便在不同的場景中使用最適合的方案，例如：
RAG + Call +
會設定多個外部資訊來源，用的方式整合到LLM 中，並使用call 來按情況調用這些外部資訊來源（例如： / 論文/ 新聞等），並透過對收集到的問題進行再提問，得出最終的答案。
/ + RAG
使用特定資料集對私有模型進行調優，並對資料集建立索引，結合RAG 來進一步提供上下文結合以獲得準確度較高的結論。相對原始的RAG 來說，透過增加訓練成本來提升回答與情境的相關度，提升回答品質。
AI Agent + 自訂工作流程
設定多個角色，可以由多個不同的模型基於不同的資料進行，以及他們配合的模式。
目前其實可用的開源方案有不少，例如：
最後的最後
隨著2023 年的日曆緩緩翻至尾頁，我們站在新的起點上，回首這一年AI 技術尤其是生成式AI 的巨大飛躍， 的崛起不僅標誌著技術的飛速進步，更是我們共同見證的歷史性時刻。在過去的一年裡，AI 的變革觸及了從程式碼生成到業務優化的各個方面，前端開發者大膽擁抱這場變革，將AI 的巨大潛力轉化為實際的生產力。
然而，正如我們所經歷的，AI 並非全能。它在程式碼產生、測試和重構等領域雖有所進步，卻也顯露出一些限制。不盡完美的接受率、結果的隨機性，以及對複雜任務處理的不足，都提醒著我們：AI 目前只是輔助工具，而非全能替代者。它能幫助我們，但最終的創新和決策仍需人類來掌握。
面對AI 在程式碼審查和低程式碼開發等領域的實踐應用，我們看到了潛力與挑戰的共存。
AI 技術的發展，不僅是科技層面的進步，更是對我們工作方式的深刻挑戰與重塑。我們熱切期待在新的一年中AI 技術帶來的更多創新與變革，同時也清楚地認識到，在與AI 攜手共進的道路上，還有許多未知和挑戰等待我們去克服和探索。
展望2024 年，我們滿懷期待地看向在AI 的助力下，不僅在技術上實現更多突破，還能在業務層面實現新的飛躍。
帶著這一年的收穫和經驗，讓我們共同邁向全新的一年。我們堅信，憑藉對科技的持續探索和對業務的深入理解，我們得以在AI 的支持下，開拓更寬廣的業務領域，創造更卓越的未來。
迎著2024 年，我們滿載信心地向前！
一則小廣告
歡迎加入我們！ 「Data-TnS-FE」部門為國際化產品的內容安全業務提供各類能力，其目標是從用戶/業務視角出發，結合技術賦能於業務，打造更多普適便捷的業務中台、基礎架構、解決方案等，為團隊所有業務的運作提供穩定、高效、易用的能力支撐。
北京職位：
上海職位：
參考連結