導(dǎo)語

AI 以超乎預(yù)期的速度席卷開發(fā)領(lǐng)域，AI 工程化也成為各業(yè)務(wù)團(tuán)隊(duì)優(yōu)先探討的命題。輸入法團(tuán)隊(duì)從實(shí)際需求出發(fā)，在Kuikly跨端項(xiàng)目中逐步探索并沉淀出一套 AI 工程化方案，目前已有不少需求按此流程完成開發(fā)并上線。以此文與大家分享其中的實(shí)踐經(jīng)驗(yàn)與思考，希望為同樣在 AI Coding 工程化路上探索的團(tuán)隊(duì)提供一些可參考的思路。

Kuikly是騰訊廣泛使用的跨端開發(fā)框架，提供了使用Kotlin語言開發(fā)Android、iOS、鴻蒙、Web、小程序、MAC跨端應(yīng)用能力。目前已在 QQ、騰訊新聞、QQ 音樂、搜狗輸入法、QQ 瀏覽器等30+業(yè)務(wù)深度使用，服務(wù)業(yè)務(wù)的總頁面數(shù)近2000+、日活用戶超5億，滿足了這些業(yè)務(wù)在眾多場(chǎng)景下的各類復(fù)雜需求。

一、背景

在AI時(shí)代，各業(yè)務(wù)團(tuán)隊(duì)都在積極探索AI Coding，目標(biāo)相似——希望實(shí)現(xiàn)需求自動(dòng)關(guān)聯(lián)、代碼生成、效果測(cè)試一站式的AI愿景，達(dá)到“L3級(jí)別”的代碼生成。網(wǎng)上各類Vibe Coding演示，從0到1搭建Demo應(yīng)用的過程已經(jīng)相當(dāng)流暢，似乎也印證了這一方向的可行性。

輸入法Kuikly跨端項(xiàng)目同樣面臨這樣的機(jī)遇，作為一個(gè)橫跨 Android、iOS、鴻蒙、H5 多端的復(fù)雜跨平臺(tái)工程，在跨端的背景下已經(jīng)大幅提升了開發(fā)效率，新頁面通常由單人完成多端交付。而在 AI 時(shí)代，我們希望更進(jìn)一步——借助 AI Coding 的能力，將開發(fā)效率再提升一個(gè)臺(tái)階。

從2025年下半年起，團(tuán)隊(duì)開始逐步落地實(shí)踐。輔助問答、文檔查詢、代碼生成等能力確實(shí)為開發(fā)帶來了一定提效，但在面對(duì)完整頁面需求時(shí)，AI生成的代碼雖然能運(yùn)行，但距離真正“可用”仍有差距。

存量工程理解有幻覺。輸入法 Kuikly 工程經(jīng)過多年積累，已封裝了大量基礎(chǔ)能力，但 AI 對(duì)我們工程的理解仍存在明顯偏差，常出現(xiàn) API 調(diào)用幻覺，遇到需求時(shí)傾向于重復(fù)造輪子等問題。此外，對(duì)于客戶端常見的頁面迭代場(chǎng)景，AI 也難有效處理。

需求缺乏結(jié)構(gòu)化輸入。Vibe Coding 模式下，需求細(xì)節(jié)往往依賴開發(fā)自己補(bǔ)全，模糊的需求交給 AI，產(chǎn)出的代碼同樣缺乏準(zhǔn)確性。當(dāng)發(fā)現(xiàn)方向偏離時(shí)，往往已經(jīng)經(jīng)歷了多輪修改。需求中未澄清的部分越多，返工成本越高。

基于以上問題，我們思考：要讓AI在真實(shí)工程中真正發(fā)揮作用，實(shí)現(xiàn)真正的工程化，需要滿足哪些條件？輸入法跨端Kuikly項(xiàng)目也在實(shí)際的頁面開發(fā)中探索。

AI 工程化

在正式探索 Spec coding 之前，我們最初直接以 Vibe Coding 的方式使用 AI，隨后接入了 Kuikly 團(tuán)隊(duì)提供的 AI 工具，在組件開發(fā)和小需求場(chǎng)景中已經(jīng)有不錯(cuò)的效果。在此基礎(chǔ)上，我們希望更進(jìn)一步，通過更規(guī)范的流程讓 AI 協(xié)作真正走向工程化。結(jié)合我們真實(shí)需求開發(fā)中的實(shí)踐，我們梳理出我們項(xiàng)目推進(jìn) Spec coding 落地的幾個(gè)關(guān)鍵層面：

推進(jìn) AI 友好型工程

在討論 AI 編程效果不佳時(shí)，很多人第一反應(yīng)是模型不行、提示詞沒寫好。但實(shí)際用下來，影響最大的往往是工程本身的質(zhì)量。AI寫代碼會(huì)讀取項(xiàng)目上下文——已有代碼、模塊結(jié)構(gòu)、依賴關(guān)系。如果工程本身質(zhì)量不佳，會(huì)把 AI 帶偏生成出同樣混亂甚至相互矛盾的代碼。在人工開發(fā)時(shí)代，可以憑借個(gè)人經(jīng)驗(yàn)和約束規(guī)避，但在AI時(shí)代，它們會(huì)被直接放大為幻覺和錯(cuò)誤。所以，如果你打算認(rèn)真用 AI 來提效，與其研究各種高級(jí)的提示詞技巧，不如先回頭看看自己的工程，給AI做些針對(duì)性的優(yōu)化。

在這一點(diǎn)上，輸入法的 Kuikly 跨端項(xiàng)目具備較好的基礎(chǔ)。從項(xiàng)目立項(xiàng)之初，到多個(gè)平臺(tái)多個(gè)模塊的逐步擴(kuò)展中，我們始終保持較為徹底的架構(gòu)設(shè)計(jì)——頁面與業(yè)務(wù)邏輯分離、系統(tǒng)能力統(tǒng)一封裝、模塊間依賴關(guān)系清晰。正因如此，即使在尚未引入任何額外流程，對(duì)工程做額外調(diào)整的情況下，僅讓 AI 參考現(xiàn)有模塊生成代碼，就已經(jīng)能有不錯(cuò)的效果。

構(gòu)建精準(zhǔn)的AI Context

隨著模型能力的提升，模型的上下文窗口也變得越來越大，似乎可以將整個(gè)項(xiàng)目一股腦塞給 AI，但實(shí)踐中效果可能并非如期。對(duì)于開發(fā)者來說，哪些系統(tǒng)能力已經(jīng)封裝、哪些基礎(chǔ)組件可以復(fù)用、哪些服務(wù)模塊應(yīng)該優(yōu)先使用，往往是“默認(rèn)常識(shí)”。

但對(duì)于AI，只能在龐雜代碼里盲目猜測(cè)和搜索，不僅容易漏掉已有能力、重復(fù)造輪子，也消耗大量token。另一方面，模型也是基于概率生成輸出，輸入信息的質(zhì)量直接影響結(jié)果，塞入大量無關(guān)代碼，AI無法自行判斷重要性，輸出質(zhì)量反而下降。

因此，我們構(gòu)建了AI上下文文檔生成器Skills的基礎(chǔ)上構(gòu)建了系統(tǒng)，為各模塊生成結(jié)構(gòu)化文檔。保留AI需要的關(guān)鍵信息：模塊職責(zé)、核心 API 、參數(shù)含義、模塊依賴關(guān)系。將這些內(nèi)容提前沉淀，為 AI 建立對(duì)項(xiàng)目的準(zhǔn)確理解。同時(shí)，這類高質(zhì)量的 Context 不只是服務(wù)于需求當(dāng)前，在后續(xù)模塊迭代、修改、擴(kuò)展時(shí)，它們也會(huì)成為穩(wěn)定的“工作記憶”，幫助AI保持實(shí)現(xiàn)思路一致、減少偏航，并在多輪協(xié)作中持續(xù)輸出更可靠的結(jié)果。

該系統(tǒng)的核心機(jī)制借鑒了 GAN（生成對(duì)抗網(wǎng)絡(luò)）的思想——文檔并非一次生成即定稿，而是通過生成器與評(píng)估器的多輪對(duì)抗迭代持續(xù)打磨。協(xié)調(diào)器設(shè)定逐輪遞增的質(zhì)量門檻（第 1 輪 ≥75 → 第 2 輪 ≥82 → … → 第 5 輪 ≥95），每一輪由生成器產(chǎn)出文檔，評(píng)估器打分并給出改進(jìn)建議，生成器據(jù)此修訂后再次提交評(píng)審，如此往復(fù)直至達(dá)到質(zhì)量標(biāo)準(zhǔn)，最終輸出高質(zhì)量的文檔，文檔從模塊職責(zé)、核心 API、參數(shù)含義、依賴關(guān)系等多個(gè)維度進(jìn)行結(jié)構(gòu)化描述，為 AI 提供更精準(zhǔn)的上下文支持。

經(jīng)過驗(yàn)證，通過本系統(tǒng)改造后處理出新的文檔在多個(gè)指標(biāo)上取得了提升：質(zhì)量層面，文檔準(zhǔn)確性達(dá)到與源碼完全一致、完整性覆蓋全部公開 API、示例代碼可直接復(fù)制使用。效率層面，新人上手項(xiàng)目提速 50%，理解模塊功能提速 107%，AI 編碼準(zhǔn)確率提升 114%，文檔更新維護(hù)效率提升 137%，真正實(shí)現(xiàn)了"讓 AI 更懂工程、讓開發(fā)更高效"的目標(biāo)。

標(biāo)準(zhǔn)化需求流程

工程化的一個(gè)特點(diǎn)是流程，在沒有流程約束的“提示詞開發(fā)”中，人與AI的協(xié)作是點(diǎn)對(duì)點(diǎn)、即興且不可復(fù)刻的。

這帶來幾個(gè)問題：

質(zhì)量無法保證：在沒有統(tǒng)一流程、缺少明確約束的情況下，產(chǎn)出往往高度依賴兩件事：一是當(dāng)次需求描述是否足夠準(zhǔn)確，二是 AI 當(dāng)下的“臨場(chǎng)發(fā)揮”是否穩(wěn)定。代碼質(zhì)量波動(dòng)巨大。

知識(shí)無法沉淀：個(gè)人開發(fā)摸索出來提示詞，有效經(jīng)驗(yàn)其實(shí)掌握在個(gè)人手里，每次開發(fā)都重頭開始，無法建立一套可復(fù)用，可持續(xù)的機(jī)制。

真正的工程化目標(biāo)，并不是“讓大家都會(huì)寫提示詞”，而是要有一條標(biāo)準(zhǔn)化AI參與流程。只有這樣，AI 的能力才能從個(gè)人技巧走向工程化的目標(biāo)。

在流程選擇上，我們結(jié)合近期的任務(wù)形態(tài)做了考量：當(dāng)前大多需求時(shí)是新頁面開發(fā)，而一個(gè)客戶端頁面天然就是邊界清晰、目標(biāo)明確、適合獨(dú)立交付的微型項(xiàng)目。因此我們最終采用了 Spec-Kit，它能很好地把 AI 協(xié)作納入標(biāo)準(zhǔn)流程，讓開發(fā)從“提示詞即興發(fā)揮”變成“基于明確規(guī)格的穩(wěn)定執(zhí)行”，關(guān)于 Spec-Kit 的原理和流程此處不再贅述。效果上，也讓Kuikly的同事嘗試過，基本可以復(fù)刻相同的效果。

Kuikly開箱即用的AI工具

在初步應(yīng)用 AI 輔助編程的過程中，我們注意到，往往需要人工介入修改的地方集中在框架規(guī)則與實(shí)現(xiàn)技能兩個(gè)層面。有些問題雖然可以通過人工在后續(xù)迭代中能夠修正，但如果能提前通過工具補(bǔ)齊，整體效率會(huì)更高、代碼產(chǎn)出也會(huì)更穩(wěn)定。

原因在于，即使AI已經(jīng)理解了具體的需求、項(xiàng)目上下文，但模型本身的訓(xùn)練語料覆蓋仍然有限，對(duì)于項(xiàng)目中特定的能力邊界和最佳實(shí)踐認(rèn)知不完整。針對(duì)這類問題，Kuikly 框架已經(jīng)提供了一整套的 AI 輔助工具KuiklyAI編程指南，包括基礎(chǔ)的AI能力： MCP 服務(wù)、Rules、Skills，也提供了AI調(diào)試、D2C和AI轉(zhuǎn)碼這類針對(duì)特定場(chǎng)景的工具，覆蓋了從編碼、調(diào)試到遷移的多個(gè)環(huán)節(jié)。

目前我們主要使用了 Rules、Skills 和 MCP 這幾項(xiàng)核心能力，AI 調(diào)試工具、D2C 和 AI 轉(zhuǎn)碼等能力也在規(guī)劃接入中。實(shí)際使用下來，即便是直接以 Vibe Coding 的方式，配合這些工具也已經(jīng)能取得相當(dāng)不錯(cuò)的生成效果，可以為 AI 補(bǔ)充Kuikly層面的知識(shí)，幫助它在生成代碼時(shí)更準(zhǔn)確地理解組件、API 和相關(guān)約束條件，從而大幅減少調(diào)用幻覺和錯(cuò)誤用法的出現(xiàn)。因此，在框架側(cè)的代碼生成上，業(yè)務(wù)并不需要過多操心模型理解Kuikly框架的能力，可以將更多精力聚焦在業(yè)務(wù)邏輯和存量工程的適配上?，F(xiàn)在Kuikly也提供了一件配置的CLI工具，Kuikly 團(tuán)隊(duì)持續(xù)對(duì)這些 AI 能力進(jìn)行維護(hù)和迭代更新，當(dāng)框架側(cè)有新的優(yōu)化或規(guī)則補(bǔ)充時(shí)，可以通過 CLI 一鍵更新即可同步到最新版本，無需手動(dòng)關(guān)注變更細(xì)節(jié)，實(shí)現(xiàn)真正的開箱即用。

同時(shí)，我們也結(jié)合自身項(xiàng)目在過往開發(fā)中積累的實(shí)際經(jīng)驗(yàn)和規(guī)范，進(jìn)一步沉淀了業(yè)務(wù)使用上的 Rules，明確了架構(gòu)層級(jí)和代碼層級(jí)的各項(xiàng)約定，從而在更細(xì)的粒度上引導(dǎo)和約束 AI 的編碼行為。

實(shí)踐與效果

以輸入法最新一期靈感詞庫功能頁面開發(fā)為例，靈感詞庫是搜狗輸入法鍵盤端的一個(gè)新功能面板，設(shè)計(jì)稿如下：

頁面細(xì)節(jié)上涉及動(dòng)態(tài)多列布局適配、多種頁面狀態(tài)管理、暗黑模式切換，同時(shí)需要對(duì)接網(wǎng)絡(luò)請(qǐng)求、路由跳轉(zhuǎn)、輸入客戶端交互、KV 存儲(chǔ)、埋點(diǎn)上報(bào)等多項(xiàng)服務(wù)能力。此外，靈感詞庫作為一個(gè)持續(xù)迭代的功能，后續(xù)還會(huì)有二期需求演進(jìn)，因此在頁面架構(gòu)設(shè)計(jì)上也需充分考慮可擴(kuò)展性，為后續(xù)迭代留足空間。

通過 Spec-Kit 的 /speckit.spec → /speckit.plan → /speckit.tasks 三個(gè)階段，將產(chǎn)品需求文檔、設(shè)計(jì)稿和交互稿做需求轉(zhuǎn)化為結(jié)構(gòu)化的工程文檔。整個(gè)過程由 AI 主導(dǎo)，過程做了在關(guān)鍵節(jié)點(diǎn)做確認(rèn)。最終輸出了一套完整的 Spec-Kit 文檔體系：

隨后進(jìn)入編碼實(shí)施階段，便得到了一個(gè) UI 與功能還原度都較高的版本，效果如下：

模塊組織、頁面核心框架、組件結(jié)構(gòu)、布局邏輯均無需大改，主要集中在UI細(xì)節(jié)調(diào)整上。

對(duì)比傳統(tǒng)開發(fā)模式，同等規(guī)模的新需求模塊頁面搭建通常需要 3 天的純編碼和技術(shù)方案時(shí)間，而借助 AI 工程化流程，1 天即完成了主體開發(fā)。同時(shí)，得益于 Spec 文檔的前置約束和 Rules 的規(guī)范引導(dǎo)，生成的代碼在架構(gòu)分層、狀態(tài)管理、跨端規(guī)范等方面都符合項(xiàng)目要求，代碼review階段基本不需要做架構(gòu)層面的返工。

需要說明的是，上述效果主要體現(xiàn)在新模塊、新頁面的場(chǎng)景中。這類任務(wù)邊界清晰、依賴可控，AI 的完成度也比較高。而對(duì)于存量代碼的修改和跨模塊的深度重構(gòu)等場(chǎng)景中，我們也嘗試過用同樣的流程去推進(jìn)，但AI 的完成度目前還是因情況而異，穩(wěn)定性還不夠理想，后續(xù)還需要持續(xù)沉淀各類場(chǎng)景的 Skills，幫助AI更好理解任務(wù)。

展望

相較于傳統(tǒng) Vibe Coding，當(dāng)前模式在迭代開發(fā)新模塊、新頁面搭建效率有不錯(cuò)的效果提升。當(dāng)然，距離 AI 全流程工程化的完整落地仍有一段路要走，我們也在以下幾個(gè)方向持續(xù)探索：

1. 打通 D2C 工具，減少 UI 修正成本

現(xiàn)階段，還有大量工作集中在 UI 層面的修正與調(diào)優(yōu)上，耗費(fèi)了較多人力。如果能夠打通 D2C 工具鏈，將設(shè)計(jì)稿自動(dòng)轉(zhuǎn)化為高質(zhì)量的代碼產(chǎn)物，從源頭上減少 UI 還原過程中的人工介入，提升開發(fā)效率。在這一點(diǎn)上Kuikly團(tuán)隊(duì)，也推出了視覺稿轉(zhuǎn)碼工具，未來我們的流程上也會(huì)持續(xù)往這方面繼續(xù)探索。

自動(dòng)化驗(yàn)證

隨著整體流程的跑通，仍有一部分環(huán)節(jié)依賴人工驗(yàn)證。下一步我們計(jì)劃結(jié)合 Kuikly 預(yù)覽、Inspector 等現(xiàn)有工具能力，逐步構(gòu)建驗(yàn)證機(jī)制。通過 AI 自動(dòng)化地對(duì) UI 渲染結(jié)果、交互行為、布局一致性等進(jìn)行校驗(yàn)與反饋，逐步替代人工驗(yàn)證環(huán)節(jié)，實(shí)現(xiàn)從"生成→預(yù)覽→驗(yàn)證→修正"的全流程自動(dòng)化閉環(huán)，進(jìn)一步提升質(zhì)量保障效率。

擴(kuò)展更多場(chǎng)景

但實(shí)際開發(fā)工作遠(yuǎn)不止于新頁面開發(fā)，后續(xù)我們計(jì)劃逐步將 AI 的能力延伸到更多場(chǎng)景——包括需求文檔的自動(dòng)解析與任務(wù)拆分、線上 BUG 的自動(dòng)定位與修復(fù)、跨端工程與端側(cè)工程聯(lián)動(dòng)等，在實(shí)踐過程持續(xù)沉淀更多的 Skills 和工具，將各項(xiàng)能力與研發(fā)流程深度編排集成，讓 AI 在更多場(chǎng)景中發(fā)揮作用，逐步覆蓋到最終的完整交付鏈路。

當(dāng)前Kuikly已經(jīng)開源，有興趣和有需要的產(chǎn)品，可以通過以下方式訪問 Kuikly 倉庫，歡迎Star、Watch與體驗(yàn)： Github 倉庫：https://github.com/Tencent-TDS/KuiklyUI

免責(zé)聲明：市場(chǎng)有風(fēng)險(xiǎn)，選擇需謹(jǐn)慎！此文僅供參考，不作買賣依據(jù)。

關(guān)鍵詞：