上周和一個(gè)四人創(chuàng)業(yè)團(tuán)隊(duì)聊天他們說現(xiàn)在最痛苦的不是寫代碼也不是畫圖而是設(shè)計(jì)師交付完 Figma 后開發(fā)者用 AI 生成了一版界面結(jié)果兩邊都覺得對(duì)方?jīng)]把自己的東西當(dāng)回事。設(shè)計(jì)師覺得開發(fā)沒有還原視覺細(xì)節(jié)開發(fā)覺得 AI 生成已經(jīng)夠好了再改成本很高。這不是個(gè)例。AI 時(shí)代小團(tuán)隊(duì)里開發(fā)者和 UI/UX 設(shè)計(jì)師的協(xié)作正在從一個(gè)“交接問題”變成“誰對(duì)最終體驗(yàn)負(fù)責(zé)”的問題。過去大家默認(rèn)流程是設(shè)計(jì)稿、評(píng)審、切圖、開發(fā)、還原邊界清晰?，F(xiàn)在設(shè)計(jì)師可以用 AI 批量生成樣式開發(fā)者可以用 AI 把圖片直接轉(zhuǎn)成代碼AI 甚至能根據(jù)一句描述生成完整布局。工具變強(qiáng)了但模糊地帶也變多了。我的核心判斷是小團(tuán)隊(duì)要真正用好 AI不是讓設(shè)計(jì)師和開發(fā)各自用 AI 提升單點(diǎn)效率而是要把協(xié)作流程重新設(shè)計(jì)成一套以 AI 為中間層的反饋系統(tǒng)。換句話說AI 不是替代設(shè)計(jì)師或開發(fā)者而是逼著兩邊把過去靠“默契”和“口頭溝通”的東西變成顯性的輸入、輸出和驗(yàn)收標(biāo)準(zhǔn)。誰先把這件事想清楚誰就能省下大量返工時(shí)間。1. 先搞清楚 AI 時(shí)代協(xié)作問題到底變了沒有1.1 表面是工具變了實(shí)際是“交接物”變了過去設(shè)計(jì)師交付的核心是設(shè)計(jì)稿設(shè)計(jì)稿里包含布局、顏色、字號(hào)、間距、組件狀態(tài)甚至標(biāo)注。開發(fā)者拿到設(shè)計(jì)稿后按照標(biāo)注去還原。這個(gè)交接物是雙方協(xié)作的錨點(diǎn)它越完整協(xié)作越順利。AI 時(shí)代這個(gè)錨點(diǎn)開始松動(dòng)。設(shè)計(jì)師可以用 AI 快速生成多套視覺方案開發(fā)可以用 AI 直接從設(shè)計(jì)稿生成代碼甚至后端的同事也能用 AI 生成一個(gè)看起來不錯(cuò)的前端頁面。于是“設(shè)計(jì)稿”這個(gè)中間產(chǎn)物不再是唯一的事實(shí)來源取而代之的是設(shè)計(jì)系統(tǒng)的 token 定義組件的行為描述頁面狀態(tài)和數(shù)據(jù)流一條條能復(fù)用的提示詞換句話說交接物從“一張圖”變成了“一套結(jié)構(gòu)化上下文”。如果團(tuán)隊(duì)還在用過去的方式只傳一張 Figma 截圖讓開發(fā)去定位 AI 生成代碼里的具體樣式就會(huì)非常低效。問題就出在這里工具已經(jīng)變了但工作流還沒有跟上。所以我建議小團(tuán)隊(duì)先不要急著買各種 AI 工具先梳理一個(gè)問題設(shè)計(jì)師最終交付的到底是一張圖還是一份包含設(shè)計(jì)意圖和約束條件的文檔1.2 過去的分工為什么容易產(chǎn)生摩擦先回顧一下非 AI 時(shí)代小團(tuán)隊(duì)里設(shè)計(jì)和開發(fā)為什么經(jīng)常打架。最常見的原因是信息損耗。設(shè)計(jì)師在 Figma 里精心調(diào)整了 8px 的間距、一個(gè) hover 狀態(tài)、一個(gè) loading 態(tài)樣式但開發(fā)在實(shí)現(xiàn)時(shí)往往只能看到靜態(tài)稿看不到背后的判斷邏輯。開發(fā)基于自己對(duì)“合理”的理解去實(shí)現(xiàn)結(jié)果做出來和設(shè)計(jì)預(yù)期不一致。另一個(gè)原因是專業(yè)語言不同。設(shè)計(jì)師會(huì)說“留白不夠透氣”“這個(gè)按鈕層級(jí)不夠突出”開發(fā)者聽到的是“具體哪里改間距多少顏色值多少”如果中間沒有人能翻譯討論就會(huì)變成互相覺得對(duì)方不專業(yè)。AI 的出現(xiàn)放大了這個(gè)摩擦。過去設(shè)計(jì)師用一套固定組件開發(fā)至少能照著做現(xiàn)在設(shè)計(jì)師用 AI 生成了一版非常規(guī)布局開發(fā)用 AI 一鍵生成代碼結(jié)果生成出了一個(gè)“看起來很像但細(xì)節(jié)沒有對(duì)齊”的頁面。于是兩邊都覺得自己沒錯(cuò)錯(cuò)的是 AI 沒有完全理解需求。本質(zhì)問題是過去的交接物里藏了很多隱性信息比如設(shè)計(jì)決策背后的用戶場(chǎng)景。AI 時(shí)代隱性信息不會(huì)自動(dòng)消失反而因?yàn)榱鞒套兛於菀妆惶^。1.3 AI 工具讓邊界變模糊在傳統(tǒng)團(tuán)隊(duì)里設(shè)計(jì)師負(fù)責(zé)“視覺”開發(fā)負(fù)責(zé)“實(shí)現(xiàn)”?，F(xiàn)在這個(gè)邊界已經(jīng)模糊了。開發(fā)者用 AI 生成一個(gè)頁面本質(zhì)上也是在“設(shè)計(jì)”設(shè)計(jì)師用 AI 生成代碼塊本質(zhì)上也在觸碰“實(shí)現(xiàn)”。這不一定是壞事。邊界模糊意味著更多人可以參與之前自己不擅長(zhǎng)的環(huán)節(jié)小團(tuán)隊(duì)尤其受益。但同時(shí)也意味著如果沒有人對(duì)最終結(jié)果負(fù)責(zé)就會(huì)出現(xiàn)“大家都在產(chǎn)出版本但沒有人在做決策”的局面。我比較認(rèn)可的一種處理方式是保持角色分工但把“決策權(quán)”重新劃清。設(shè)計(jì)師仍然是視覺體驗(yàn)的負(fù)責(zé)人開發(fā)仍然是技術(shù)實(shí)現(xiàn)和性能的負(fù)責(zé)人AI 是雙方的協(xié)作者而不是裁判。更具體一點(diǎn)設(shè)計(jì)師要負(fù)責(zé)定義“為什么長(zhǎng)這樣”開發(fā)要負(fù)責(zé)定義“怎么高效穩(wěn)定地實(shí)現(xiàn)”而 AI 負(fù)責(zé)把雙方的需求轉(zhuǎn)換成初始版本。2. 從設(shè)計(jì)稿到代碼AI 到底能接管哪一段2.1 設(shè)計(jì)側(cè)AI 生成 UI 和設(shè)計(jì)系統(tǒng)現(xiàn)在很多設(shè)計(jì)工具已經(jīng)內(nèi)置了 AI 能力可以基于文本描述生成布局、配色、圖標(biāo)甚至整頁 UI。這類工具對(duì)早期探索很有價(jià)值設(shè)計(jì)師不需要花 2 小時(shí)從空白畫布開始而是先生成幾個(gè)方向再篩選、微調(diào)。但這里有一個(gè)常見誤解AI 生成的 UI 看起來完整實(shí)際上缺少“設(shè)計(jì)約束”。比如 AI 可能生成一套鮮艷的漸變卡片視覺上很搶眼但不滿足你們產(chǎn)品的可訪問性對(duì)比度要求也沒有考慮狀態(tài)變化。如果設(shè)計(jì)師直接把 AI 結(jié)果當(dāng)作終稿開發(fā)再用 AI 照著實(shí)現(xiàn)最后出來的產(chǎn)品可能會(huì)很好看但用戶操作時(shí)會(huì)有很多細(xì)節(jié)問題。所以我建議設(shè)計(jì)團(tuán)隊(duì)把 AI 生成當(dāng)作“前期發(fā)散”階段。具體做法是先用 AI 生成 3 到 5 個(gè)視覺方向。再人工篩選并確定一個(gè)方向。然后基于選定方向手動(dòng)整理出關(guān)鍵設(shè)計(jì) token例如主色、輔助色、圓角、間距、字體大小。最后把 token 和視覺案例一起交給開發(fā)。這一步看起來多了一些工作但在 AI 時(shí)代反而更省時(shí)間。因?yàn)殚_發(fā)側(cè)的 AI 代碼生成能力再?gòu)?qiáng)也需要明確約束條件否則每次生成都會(huì)偏離。2.2 開發(fā)側(cè)AI 從設(shè)計(jì)稿生成代碼但離生產(chǎn)還有距離開發(fā)側(cè)的場(chǎng)景更直接拿到一張?jiān)O(shè)計(jì)圖讓 AI 生成 HTML/CSS 或 React 組件。很多 AI 編程工具已經(jīng)能識(shí)別圖片生成結(jié)構(gòu)不錯(cuò)的代碼。對(duì)于中后臺(tái)頁面或營(yíng)銷頁這個(gè)能力已經(jīng)能節(jié)省 50% 以上的初始工作量。但“生成代碼”和“可運(yùn)行代碼”之間還差三層狀態(tài)與交互邏輯。設(shè)計(jì)稿可能是靜態(tài)的AI 生成的代碼也大概率是靜態(tài)的但真實(shí)頁面需要處理 loading、空數(shù)據(jù)、錯(cuò)誤提示、點(diǎn)擊反饋、表單校驗(yàn)等狀態(tài)。這部分 AI 很難從一張圖里推斷出來。數(shù)據(jù)層對(duì)接。生成出來的組件還需要接入接口、鑒權(quán)、路由、權(quán)限控制。這些和環(huán)境強(qiáng)相關(guān)AI 只依賴單張圖片無法完成。設(shè)計(jì)系統(tǒng)一致性。AI 生成的代碼會(huì)隨意使用顏色值、字號(hào)、間距不一定符合團(tuán)隊(duì)已有的設(shè)計(jì)系統(tǒng)。 比如團(tuán)隊(duì)統(tǒng)一用 CSS 變量--color-primaryAI 生成的代碼可能寫死#3B82F6。所以一個(gè)實(shí)用判斷是AI 可以生成初始版本但開發(fā)者不能把 AI 生成的結(jié)果直接推上線。開發(fā)者需要把 AI 生成的代碼納入原有的工程規(guī)范里比如把顏色值替換成設(shè)計(jì) token把組件狀態(tài)補(bǔ)全再接入數(shù)據(jù)。2.3 真正適合 AI 接管的環(huán)節(jié)是“重復(fù)轉(zhuǎn)換”而不是“產(chǎn)品判斷”如果讓我用一個(gè)詞概括 AI 在設(shè)計(jì)與開發(fā)之間的價(jià)值那就是“轉(zhuǎn)換”。它能高效完成從設(shè)計(jì) token 到 CSS 變量、從組件描述到基礎(chǔ)代碼、從視覺稿到 HTML 結(jié)構(gòu)這類轉(zhuǎn)換任務(wù)。更適合 AI 接管的環(huán)節(jié)通常具備三個(gè)特征輸入和輸出都是結(jié)構(gòu)化的比如設(shè)計(jì) token、JSON、CSS。規(guī)則相對(duì)明確比如命名規(guī)范、間距倍數(shù)、狀態(tài)后綴。重復(fù)度高比如批量生成表單頁、列表頁。不適合 AI 接管的環(huán)節(jié)是“產(chǎn)品判斷”。比如這個(gè)頁面是否滿足用戶目標(biāo)這個(gè)按鈕放在這里是否會(huì)分散注意力這個(gè)表單到底該分幾步這類問題需要人來決策不取決于 AI 生成的代碼多快。如果小團(tuán)隊(duì)希望建立穩(wěn)定協(xié)作流程最好先盤點(diǎn)一遍團(tuán)隊(duì)里有多少任務(wù)是“重復(fù)轉(zhuǎn)換”并把它們交給 AI再把“產(chǎn)品判斷”留到人工階段。這個(gè)區(qū)分越清晰AI 帶來的效能提升就越可預(yù)測(cè)。3. 小團(tuán)隊(duì)協(xié)作的四個(gè)關(guān)鍵動(dòng)作3.1 建立單一事實(shí)源設(shè)計(jì)稿、組件庫(kù)和代碼庫(kù)怎么對(duì)齊AI 時(shí)代最怕的是同一個(gè)組件有多個(gè)版本。設(shè)計(jì)師在自己的文件里維護(hù)一份規(guī)范開發(fā)在代碼倉(cāng)庫(kù)里維護(hù)一份AI 生成時(shí)又可能產(chǎn)生第三份。小團(tuán)隊(duì)沒有專門資源去維護(hù)三份同步所以必須建立單一事實(shí)源。我的建議是這樣設(shè)計(jì)系統(tǒng)以代碼倉(cāng)庫(kù)中的 token 和組件實(shí)現(xiàn)為準(zhǔn)。設(shè)計(jì)師在 Figma 中使用同一套 token 的插件或鏈接而不是自己維護(hù)一套顏色值。AI 生成代碼時(shí)需要提供當(dāng)前項(xiàng)目已有的 token 定義作為上下文。每次組件或 token 修改都要同步到設(shè)計(jì)工具和開發(fā)倉(cāng)庫(kù)的文檔中?？梢韵扔靡粋€(gè)簡(jiǎn)單的表格記錄當(dāng)前協(xié)作的事實(shí)源對(duì)象唯一事實(shí)來源維護(hù)者顏色、間距、字號(hào)代碼倉(cāng)庫(kù)中的 design-token 文件開發(fā)者組件行為與使用場(chǎng)景組件文檔MDX 或 Markdown設(shè)計(jì)師與開發(fā)者共同維護(hù)頁面整體布局Figma 設(shè)計(jì)稿設(shè)計(jì)師業(yè)務(wù)狀態(tài)與交互邏輯產(chǎn)品需求文檔或 Issue 描述產(chǎn)品經(jīng)理與開發(fā)者共同維護(hù)一旦每類信息有了明確歸屬AI 就能更準(zhǔn)確地被使用。否則AI 只是一個(gè)“更快的生成器”還會(huì)放大混亂。3.2 讓設(shè)計(jì)師參與“AI 提示詞”的制定而不是只交付靜態(tài)圖很多小團(tuán)隊(duì)現(xiàn)在讓開發(fā)用 AI 工具讀取設(shè)計(jì)稿生成代碼。但如果設(shè)計(jì)師只發(fā)一張圖開發(fā)把它喂給 AIAI 生成的代碼往往不夠準(zhǔn)確。問題在于圖片沒有表達(dá)出設(shè)計(jì)背后的約束。更有效的方法是設(shè)計(jì)師在交付設(shè)計(jì)稿時(shí)同時(shí)附上一份“設(shè)計(jì)意圖描述”。這份描述可以很短但必須包含頁面對(duì)應(yīng)什么用戶場(chǎng)景。不同屏幕尺寸下布局如何變化。哪些狀態(tài)必須保留。哪些視覺風(fēng)格是硬性約束哪些可以靈活處理。例如一個(gè)表單頁的設(shè)計(jì)意圖描述可以這樣寫這是一個(gè)倒計(jì)時(shí)抽獎(jiǎng)活動(dòng)的報(bào)名表單。移動(dòng)端優(yōu)先操作按鈕始終在視口底部保證單手操作。 展示字段按優(yōu)先級(jí)排列手機(jī)號(hào)、姓名、城市。 提交成功后顯示成功態(tài)卡片失敗時(shí)保留用戶輸入并在按鈕上方顯示錯(cuò)誤提示。 視覺上使用品牌主色 #FF6A00圓角 12px卡片間距 16px。開發(fā)拿到這個(gè)描述后再結(jié)合設(shè)計(jì)圖去生成代碼AI 輸出的結(jié)果會(huì)貼近很多。而且設(shè)計(jì)師參與提示詞制定還有一個(gè)好處它能倒逼設(shè)計(jì)師把“感覺”翻譯成“規(guī)則”這對(duì)設(shè)計(jì)系統(tǒng)和后續(xù)維護(hù)都是加分項(xiàng)。3.3 開發(fā)者在 AI 生成代碼后要負(fù)責(zé)“設(shè)計(jì)驗(yàn)收”過去設(shè)計(jì)稿到開發(fā)的驗(yàn)收通常由設(shè)計(jì)師來做。但 AI 生成代碼后一些細(xì)節(jié)問題會(huì)大量出現(xiàn)比如顏色被寫死、間距不統(tǒng)一、 hover 狀態(tài)缺失。如果等到設(shè)計(jì)師在看已經(jīng)上線的頁面時(shí)才發(fā)現(xiàn)返工成本很高。我建議小團(tuán)隊(duì)把設(shè)計(jì)驗(yàn)收前置到開發(fā)階段。開發(fā)者在拿到 AI 生成代碼后要先做一輪“設(shè)計(jì)還原檢查”而不是直接合并代碼。檢查清單可以包含這幾項(xiàng)顏色是否使用了設(shè)計(jì) token而不是寫死的十六進(jìn)制值。間距是否符合設(shè)計(jì)稿的 4px 或 8px 基準(zhǔn)。按鈕、輸入框、卡片是否有定義 hover、active、focus、disabled 狀態(tài)。頁面在 375px、768px、1440px 寬度下是否不破版。字體大小、行高是否落在設(shè)計(jì)系統(tǒng)范圍內(nèi)。這件事不需要很復(fù)雜只要在代碼 review 的模板里多加一個(gè)“設(shè)計(jì)驗(yàn)收”復(fù)選框。它會(huì)把很多問題提前吃掉而不是留到設(shè)計(jì)師和開發(fā)者互相拉扯時(shí)才處理。3.4 用版本管理和評(píng)論機(jī)制替代“口頭同步”小團(tuán)隊(duì)最大的敵人不是技術(shù)而是“口頭同步”。設(shè)計(jì)稿更新了一個(gè)按鈕位置開發(fā)在聊天群里看到但沒來得及改AI 重新生成了一版代碼保存在本地沒有提交倉(cāng)庫(kù)設(shè)計(jì)師對(duì)某個(gè)樣式有意見直接在會(huì)議里說了但沒有留下記錄。AI 時(shí)代流程更快這些臨時(shí)信息更容易被漏掉。所以我的建議是所有設(shè)計(jì)變更和協(xié)作反饋都盡量落到可追蹤的地方。設(shè)計(jì)變更在 Figma 或設(shè)計(jì)文件里留下版本說明讓開發(fā)者知道這一版改了什么。代碼變更通過 PR 提交附帶設(shè)計(jì)稿鏈接和實(shí)現(xiàn)說明。樣式反饋在組件庫(kù)或設(shè)計(jì)系統(tǒng)倉(cāng)庫(kù)中提 issue而不是在聊天里描述。AI 生成結(jié)果保存為可復(fù)現(xiàn)的 prompt 和輸出樣例方便回溯。這不是為了讓流程變得繁瑣而是因?yàn)?AI 生成的版本足夠多以后團(tuán)隊(duì)必須能回答一個(gè)問題當(dāng)前線上版本對(duì)應(yīng)的是哪一版設(shè)計(jì)、哪一版代碼、哪一條提示詞生成的。如果沒有版本管理排查問題時(shí)所有環(huán)節(jié)都會(huì)變成問號(hào)。4. 在真實(shí)項(xiàng)目里跑通一條最小協(xié)作流程4.1 準(zhǔn)備階段確定設(shè)計(jì)系統(tǒng)與組件邊界不要一開始就在整個(gè)項(xiàng)目里鋪開 AI 協(xié)作。更穩(wěn)妥的方式是挑一個(gè)中后臺(tái)頁面或一個(gè) MVP 功能跑通一條最小協(xié)作流程。準(zhǔn)備階段建議做三件事梳理當(dāng)前項(xiàng)目已經(jīng)有的設(shè)計(jì) token包括顏色、字號(hào)、間距、圓角、陰影。確認(rèn)組件邊界哪些是基礎(chǔ)組件按鈕、輸入框、卡片哪些是頁面級(jí)組件表單頁、列表頁、詳情頁。約定 AI 生成的代碼要放置到哪里通常是在業(yè)務(wù)頁面目錄中基礎(chǔ)組件不直接用 AI 生成除非是一次性原型。如果項(xiàng)目還沒有設(shè)計(jì) token可以先花半天時(shí)間從當(dāng)前頁面上抽取一份“臨時(shí) token 清單”。這個(gè)清單不追求完整但必須覆蓋主色、輔助色、文本色、主字體、間距基礎(chǔ)單位、圓角基礎(chǔ)值。這樣 AI 生成時(shí)就有約束?？梢杂靡粋€(gè)簡(jiǎn)單模板{ colors: { primary: #FF6A00, text: #1A1A1A, background: #FFFFFF, border: #E5E5E5 }, spacing: { base: 8, cardPadding: 16 }, radius: { card: 12, button: 8 } }這個(gè) JSON 可以作為 AI 提示詞的一部分輸入讓生成的代碼盡量遵守現(xiàn)有規(guī)范。4.2 從設(shè)計(jì)稿到可運(yùn)行頁面一個(gè)通用流程當(dāng)準(zhǔn)備完成后一個(gè)常見的協(xié)作流程可以這樣定設(shè)計(jì)師輸出設(shè)計(jì)稿并附上設(shè)計(jì)意圖描述。開發(fā)者把設(shè)計(jì)稿截圖和設(shè)計(jì)意圖描述一起發(fā)給 AI生成頁面級(jí)代碼。開發(fā)者檢查生成結(jié)果主要是樣式 token、布局和狀態(tài)是否完整。開發(fā)者把 AI 生成代碼接入項(xiàng)目的數(shù)據(jù)層、路由和權(quán)限邏輯。設(shè)計(jì)師在瀏覽器里查看已實(shí)現(xiàn)頁面給出反饋。開發(fā)者根據(jù)反饋迭代同時(shí)把反饋中涉及的設(shè)計(jì)規(guī)范更新到項(xiàng)目文檔里。這種流程下AI 承擔(dān)的是“第一版生成器”的角色節(jié)省的是從空白頁面到完整結(jié)構(gòu)的時(shí)間。但它不是終局流程因?yàn)檎鎸?shí)項(xiàng)目還有數(shù)據(jù)、交互和異常狀態(tài)。4.3 常見坑樣式漂移、上下文丟失、視覺還原度不足實(shí)際用下來最容易遇到三個(gè)坑。第一個(gè)是樣式漂移。AI 在第一次生成時(shí)通常能夠遵循給定的 token但在后續(xù)“幫我改一下這個(gè)按鈕”的增量修改中AI 可能只改按鈕本身卻把附近的間距和文字樣式也帶跑偏了。原因是模型只關(guān)注局部請(qǐng)求沒有全局上下文。解決辦法是把設(shè)計(jì) token 和基礎(chǔ)組件文檔一直放在提示詞里即使是在局部修改時(shí)也不省略。第二個(gè)是上下文丟失。AI 對(duì)話窗口能保留的信息有限。如果你們連續(xù)討論了很多輪AI 很可能忘記原始的頁面目標(biāo)和設(shè)計(jì)約束。所以我建議不要在同一個(gè)對(duì)話里無限堆需求而是每完成一個(gè)獨(dú)立頁面或獨(dú)立組件就開一個(gè)新對(duì)話并把核心設(shè)計(jì)上下文重新粘貼進(jìn)去。第三個(gè)是視覺還原度不足。AI 生成的代碼和設(shè)計(jì)稿相比往往在圓角、陰影、字體間距等細(xì)節(jié)上有偏差。這不是 AI 能力不行而是設(shè)計(jì)稿里的信息密度太高模型很難從一張圖里完整提取。對(duì)策是不要只給一張全屏圖還要給出關(guān)鍵局部的截圖和說明。比如按鈕的 hover 狀態(tài)、列表的間距、空數(shù)據(jù)的展示。4.4 排查鏈路先看數(shù)據(jù)再看樣式最后看邏輯當(dāng)頁面出現(xiàn)問題團(tuán)隊(duì)不要一上來就怪 AI。建議按照固定鏈路排查先確認(rèn)使用的設(shè)計(jì)稿版本是否正確。很多時(shí)候是設(shè)計(jì)師更新了圖但開發(fā)還用的是舊版。再檢查生成的代碼是否使用了設(shè)計(jì) token。如果顏色寫死大概率是提示詞里沒有提供 token 清單。然后看組件在不同寬度下是否正常。如果只在某個(gè)斷點(diǎn)破版很可能需要單獨(dú)的媒體查詢。最后看交互狀態(tài)和業(yè)務(wù)邏輯。樣式對(duì)了但點(diǎn)擊沒反應(yīng)那就是狀態(tài)層沒有接好和設(shè)計(jì)還原無關(guān)。這個(gè)排查順序能幫助團(tuán)隊(duì)快速定位問題在哪一層。如果一上來就糾結(jié)“AI 生成得不準(zhǔn)確”往往會(huì)漏掉真正的問題。5. 哪些場(chǎng)景適合 AI 協(xié)作哪些還是要人盯5.1 適合中后臺(tái)表單、MVP 頁面、設(shè)計(jì)系統(tǒng)維護(hù)、組件版本遷移從我的經(jīng)驗(yàn)看下面幾類場(chǎng)景最能在 AI 協(xié)作中受益。中后臺(tái)表單是典型代表。它的布局規(guī)則相對(duì)固定無非是標(biāo)簽、輸入框、校驗(yàn)、提交。AI 能很快生成一版接近需求的代碼開發(fā)者只需要改字段配置和提交邏輯。MVP 頁面也適合。創(chuàng)業(yè)團(tuán)隊(duì)想快速驗(yàn)證一個(gè)概念不需要像素級(jí)還原但需要把前后端串起來。AI 生成頁面代碼開發(fā)者接入數(shù)據(jù)一天內(nèi)就能跑通一個(gè)原型。設(shè)計(jì)系統(tǒng)維護(hù)同樣值得用 AI。比如把舊的 antd 主題改成自定義主題把散落頁面的顏色統(tǒng)一成新的 token。這類工作重復(fù)度高AI 可以批量處理。組件版本遷移也是好場(chǎng)景。比如設(shè)計(jì)規(guī)范里把圓角從 4px 改成 8px全站影響幾十個(gè)組件AI 可以基于 token 替換快速完成人工只需要 review 異常情況。5.2 不適合強(qiáng)品牌調(diào)性、復(fù)雜動(dòng)效、無障礙細(xì)節(jié)、高風(fēng)險(xiǎn)交互有些場(chǎng)景不適合讓 AI 做最終決策尤其是強(qiáng)品牌調(diào)性頁面。品牌頁面往往依賴設(shè)計(jì)師對(duì)目標(biāo)用戶的深刻理解AI 生成的“好看”可能只是平均水平不能代表品牌個(gè)性。復(fù)雜動(dòng)效也不適合。AI 能生成 CSS 動(dòng)畫但一個(gè)微交互的物理曲線、時(shí)序、觸發(fā)條件需要設(shè)計(jì)師和開發(fā)者緊密配合AI 目前還很難理解“這個(gè)動(dòng)效要傳達(dá)什么感覺”。無障礙細(xì)節(jié)是容易被忽略的重災(zāi)區(qū)。AI 生成的代碼可能忽略了鍵盤導(dǎo)航、focus 狀態(tài)、屏幕閱讀器標(biāo)簽。小團(tuán)隊(duì)一般沒有專業(yè)無障礙團(tuán)隊(duì)所以這部分必須有人工檢查尤其是面向公眾用戶的產(chǎn)品。高風(fēng)險(xiǎn)交互也不適合全自動(dòng)。比如支付流程、刪除確認(rèn)、權(quán)限設(shè)置這些頁面的交互文案、順序、誤操作保護(hù)都需要人工仔細(xì)推敲。AI 可以生成初稿但必須經(jīng)過嚴(yán)格的代碼 review 和測(cè)試。5.3 邊界判斷如果一次修改涉及多變數(shù)先別急著全自動(dòng)一個(gè)比較實(shí)用的判斷標(biāo)準(zhǔn)是如果這次修改只涉及“單一維度”例如把全站主色從綠色改成藍(lán)色可以放心讓 AI 批量處理如果這次修改同時(shí)涉及布局、文案、交互、視覺層級(jí)還要適應(yīng)多種用戶狀態(tài)那就不要全自動(dòng)。AI 擅長(zhǎng)的是在約束明確的情況下快速生成而不是在模糊目標(biāo)里做創(chuàng)造性決策。團(tuán)隊(duì)里需要有人先定義清楚“這次修改屬于設(shè)計(jì)升級(jí)、功能新增、還是策略調(diào)整”再?zèng)Q定 AI 參與的程度。另外無論 AI 參與多深最終上線前都建議做一次人工驗(yàn)收。這不是不信任 AI而是確保任何由 AI 引入的細(xì)節(jié)偏差都能被捕獲。6. 把協(xié)作經(jīng)驗(yàn)沉淀成團(tuán)隊(duì)可復(fù)用的框架6.1 極簡(jiǎn)協(xié)作協(xié)議輸入、輸出、驗(yàn)收標(biāo)準(zhǔn)與其每次都靠開會(huì)和聊天對(duì)齊不如沉淀一個(gè)極簡(jiǎn)協(xié)作協(xié)議。它不需要很長(zhǎng)只需要回答三句話誰給誰什么產(chǎn)出什么怎么算完成。我用過的一個(gè)模板是這樣的角色輸入輸出驗(yàn)收標(biāo)準(zhǔn)設(shè)計(jì)師用戶需求、競(jìng)品分析設(shè)計(jì)稿 設(shè)計(jì)意圖描述 token 清單開發(fā)者能夠基于輸入生成不偏離視覺風(fēng)格的首版代碼開發(fā)者設(shè)計(jì)稿 設(shè)計(jì)意圖描述 工程上下文可運(yùn)行的頁面代碼 PR 說明頁面在主流分辨率下視覺還原度達(dá)標(biāo)狀態(tài)完整無樣式寫死AI結(jié)構(gòu)化的設(shè)計(jì)上下文初始代碼或視覺方案輸出符合提示詞中的約束允許人工修正這個(gè)協(xié)議最好貼在每個(gè)項(xiàng)目的 README 里并寫成一個(gè)可以直接復(fù)制的提示詞模板。比如“PR 描述模板”里強(qiáng)制要求填寫關(guān)聯(lián)設(shè)計(jì)稿鏈接、使用的 token、設(shè)計(jì)意圖描述、AI 生成部分與人工修改部分。6.2 用“設(shè)計(jì)到代碼還原度”作為檢查指標(biāo)團(tuán)隊(duì)可以約定一個(gè)“設(shè)計(jì)還原度”檢查指標(biāo)不一定要非常嚴(yán)格但至少要有統(tǒng)一標(biāo)準(zhǔn)。我一般會(huì)從五個(gè)維度檢查色彩是否使用了設(shè)計(jì) token和設(shè)計(jì)稿色值是否一致。間距是否遵循 4px/8px 基準(zhǔn)卡片間距、輸入框高度是否符合設(shè)計(jì)稿。字體字號(hào)、行高、字重是否匹配。狀態(tài)按鈕、鏈接、輸入框是否有 hover、focus、active、disabled。響應(yīng)式在幾個(gè)常見寬度下布局是否不破版。每一項(xiàng)可以打“通過、略有偏差、不通過”。當(dāng)偏差比較多時(shí)團(tuán)隊(duì)就暫停 AI 生成回過頭補(bǔ)充設(shè)計(jì)意圖描述或 token 清單。這個(gè)指標(biāo)不僅用于驗(yàn)收也能反過來指導(dǎo) AI 提示詞怎么寫。如果連續(xù)兩周發(fā)現(xiàn)“間距”問題最多說明提示詞里的“間距遵循 8px 基準(zhǔn)”沒有寫清楚下次生成前就要單獨(dú)強(qiáng)調(diào)。6.3 定期復(fù)盤哪些 AI 生成內(nèi)容省力哪些反而增加返工每?jī)傻饺軋F(tuán)隊(duì)可以花半小時(shí)做一次 AI 協(xié)作復(fù)盤。不用復(fù)盤所有細(xì)節(jié)只回答三個(gè)問題本周哪些頁面或組件用 AI 生成后幾乎沒有返工原因是提示詞清晰、設(shè)計(jì)系統(tǒng)成熟還是場(chǎng)景簡(jiǎn)單。哪些任務(wù)看起來用了 AI但實(shí)際返工更嚴(yán)重原因往往是目標(biāo)模糊、缺少設(shè)計(jì) token、或 AI 輸出太泛化。哪些環(huán)節(jié)應(yīng)該改用更結(jié)構(gòu)化的人工流程比如復(fù)雜交互頁面也許一開始就不該讓 AI 直接生成完整頁面。通過復(fù)盤團(tuán)隊(duì)能逐步建立一張“適合用 AI / 不適合用 AI”的任務(wù)清單。這張清單比任何工具都重要因?yàn)樗銈冏约旱捻?xiàng)目特征。6.4 小團(tuán)隊(duì)的長(zhǎng)期路徑從工具鏈到工作流最后想說的是小團(tuán)隊(duì)不需要一步到位建設(shè)復(fù)雜的 AI 工作流。更合理的路徑是先用 AI 生成一個(gè)簡(jiǎn)單頁面跑通從設(shè)計(jì)到代碼的基礎(chǔ)鏈路。積累一批提示詞模板和設(shè)計(jì) token 清單讓 AI 輸出更穩(wěn)定。在真實(shí)項(xiàng)目中驗(yàn)證效果同時(shí)建立設(shè)計(jì)還原度檢查和 PR 模板。遇到批量替換、組件遷移等重復(fù)任務(wù)時(shí)再逐步擴(kuò)大 AI 使用范圍。最后形成一套屬于你們團(tuán)隊(duì)的協(xié)作流程而不是盲目模仿別的團(tuán)隊(duì)。這個(gè)過程不需要一個(gè)專門負(fù)責(zé)人只要設(shè)計(jì)師和開發(fā)者都愿意把“輸入寫清楚”當(dāng)成重要工作AI 帶來的收益就會(huì)越來越明顯。AI 時(shí)代最有價(jià)值的能力可能不是會(huì)用某個(gè)模型也不是能寫出一段復(fù)雜提示詞而是把團(tuán)隊(duì)里原本模糊的協(xié)作關(guān)系變成一套清晰、可迭代、讓 AI 也能參與的協(xié)議。小團(tuán)隊(duì)的優(yōu)勢(shì)在于人少、溝通路徑短更容易改變流程。抓住這個(gè)窗口先把前面提到的單一事實(shí)源、設(shè)計(jì)意圖描述、AI 生成后的驗(yàn)收跑通你們的協(xié)作就會(huì)比大多數(shù)團(tuán)隊(duì)更順滑。