年初接了一批可視化大屏的需求連續(xù)給 15 個不同行業(yè)做設(shè)計產(chǎn)出。做完之后最大的感觸是Codex 這類 AI 輔助工具已經(jīng)不只是寫代碼的加速器它真正改變了大屏設(shè)計的工作流組織方式。這篇內(nèi)容就是把整套實踐的思路、場景拆解、落地過程和踩坑記錄整理出來給正在做數(shù)據(jù)可視化項目的同行做個參考。15 個行業(yè)看似很多但拆解之后會發(fā)現(xiàn)大多數(shù)需求都能落到一套相對穩(wěn)定的工作流里先明確業(yè)務(wù)方要什么再定數(shù)據(jù)指標和視覺層級然后用 Codex 輔助完成從代碼骨架到組件調(diào)優(yōu)的整個鏈路。這篇博文不會有太玄乎的東西都是我在實際項目里反復(fù)驗證過的做法包括提示詞怎么組織、組件怎么抽象、效果怎么驗收踩過的坑也一并寫出來希望能幫你少走點彎路。1. 大屏項目為什么值得引入 Codex 工作流要說清楚這件事得先從傳統(tǒng)大屏開發(fā)的痛點講起?？梢暬笃吝@類項目有個特點業(yè)務(wù)邏輯不算復(fù)雜但重復(fù)勞動極其驚人——每個行業(yè)換了指標、換了配色、換了布局代碼框架卻高度相似。以前接一個智慧園區(qū)的大屏光是把底圖調(diào)好、把邊框元素擺齊、把圖表組件接上數(shù)據(jù)就得花掉兩三天純手工時間。遇到需求方中途改指標名稱又是全局搜索替換非常消磨耐心。Codex 加入之后這套流程被改造成了人機協(xié)作的模式。我的分工是這樣的我負責理解業(yè)務(wù)目標、梳理數(shù)據(jù)口徑、確認視覺風格把需求翻譯成足夠精準的指令Codex 負責把指令轉(zhuǎn)成代碼完成布局搭建、圖表配置、樣式調(diào)整、數(shù)據(jù)接入這些相對模式化的環(huán)節(jié)。也就是說AI 解決的是“怎么畫”的問題我解決的是“畫什么”和“為什么畫”的問題。這套工作流能跑通關(guān)鍵在于大屏項目本身的高度模塊化。一個成熟的大屏頁面本質(zhì)上就是幾類元素的組合背景與裝飾框、頭部標題區(qū)、圖表卡片、指標卡、表格、地圖或其他定制組件。只要把這幾類元素的代碼模板沉淀好再配合一套清晰的提示詞規(guī)范Codex 就能穩(wěn)定地產(chǎn)出可用的初版代碼我再在此基礎(chǔ)上做細節(jié)調(diào)整和邏輯核對。還有一個容易被忽略的原因Codex 特別適合處理數(shù)據(jù)映射這類機械但容易出錯的活。比如一份 CSV 里 30 個省份的銷量數(shù)據(jù)手工寫映射代碼很容易漏行或者對錯列但 Codex 只要把數(shù)據(jù)樣例和映射規(guī)則描述清楚它生成的代碼幾乎不會犯這種低級錯誤。省下來的時間可以用來做真正需要人的判斷力的事情。2. 15 個行業(yè)場景怎么選出來的設(shè)計坐標系15 個行業(yè)場景不是隨手湊數(shù)的而是先定了一張“行業(yè)大屏設(shè)計坐標系”再按這張圖去覆蓋不同維度的組合。坐標系里主要有三根軸數(shù)據(jù)復(fù)雜度、空間屬性、實時性要求。數(shù)據(jù)復(fù)雜度決定圖表選型和布局密度空間屬性決定要不要做地圖、有沒有地理坐標系實時性要求決定輪詢刷新機制和數(shù)據(jù)流方案。以下是這套工作流實際覆蓋的場景清單序號行業(yè)場景核心指標方向常用圖表類型Codex 輔助重點1電商零售大屏銷售額、訂單量、轉(zhuǎn)化率、客單價柱狀圖、折線圖、漏斗圖、指標卡多指標卡片布局與數(shù)據(jù)聚合2智慧物流大屏車輛位置、時效達成率、異常事件地圖散點、軌跡線、實時列表地圖組件接入與實時刷新3制造業(yè)產(chǎn)線大屏OEE、良品率、設(shè)備狀態(tài)、工單進度儀表盤、狀態(tài)燈格、趨勢折線設(shè)備狀態(tài)映射與告警邏輯4能源環(huán)保大屏能耗總量、碳排放、分項占比環(huán)形圖、面積圖、指標趨勢分項能耗對比與減排預(yù)測5智慧園區(qū)大屏樓宇入駐率、訪客流量、設(shè)備在線率3D 樓宇簡模、熱力圖、柱狀圖3D 場景與 2D 圖表的聯(lián)動6醫(yī)療健康大屏門診量、床位使用率、科室負荷分組柱狀圖、進度條、排名表醫(yī)療流程節(jié)點數(shù)據(jù)可視化7金融風控大屏交易金額、風險事件、實時攔截率實時刷新表格、?；鶊D、雷達圖風控規(guī)則觸發(fā)邏輯可視化8智慧教育大屏在校人數(shù)、課程熱度、資源使用率氣泡圖、堆疊柱、詞云多維度數(shù)據(jù)鉆取聯(lián)動9文旅景區(qū)大屏游客量、客流密度、輿情熱度地圖熱力、時間軸、輿情列表客流高峰時段分析與預(yù)測10智慧農(nóng)業(yè)大屏土壤墑情、氣象數(shù)據(jù)、設(shè)備狀態(tài)雷達圖、折線圖、狀態(tài)卡片物聯(lián)網(wǎng)時序數(shù)據(jù)接入11交通樞紐大屏客流、班次準點率、換乘效率站點地圖、甘特圖、指標卡班次動態(tài)與客流的聯(lián)動展示12樓宇運維大屏能耗、設(shè)備壽命、工單響應(yīng)環(huán)形進度、樹狀圖、告警列表設(shè)備樹結(jié)構(gòu)可視化13公共安全大屏事件總數(shù)、響應(yīng)時長、區(qū)域分布區(qū)域地圖、事件列表、柱狀圖事件分級與區(qū)域聯(lián)動14水務(wù)水利大屏水位、流量、水質(zhì)指標水位曲線、流向圖、指標卡多點監(jiān)測數(shù)據(jù)的標準化掛接15影視傳媒大屏播放量、熱度趨勢、受眾畫像曲線圖、玫瑰圖、畫像標簽多渠道數(shù)據(jù)聚合比對這張表本身就是一套可以復(fù)用的資產(chǎn)。后接新項目的時候先找出它落在坐標系里的哪個象限再對照表格找最接近的場景模板改動成本能下降一個量級。3. 四個代表性場景的完整拆解15 個場景全部展開篇幅太長我挑四個最能體現(xiàn)工作流優(yōu)勢的場景做完整拆解。這四個場景分別對應(yīng)了不同復(fù)雜度組合電商零售是純數(shù)據(jù)型、智慧物流是空間型、制造業(yè)是狀態(tài)映射型、能源環(huán)保是預(yù)測分析型覆蓋了坐標系里的典型位置。3.1 電商零售大屏標準化程度最高的場景電商零售大屏是這套工作流里最容易出效果的場景。原因在于零售業(yè)務(wù)的指標體系極度成熟銷售額、訂單量、轉(zhuǎn)化率、客單價、退款率這些指標業(yè)務(wù)方自己都有一套約定俗成的口徑?？趶揭坏R剩下的事情基本就是布局設(shè)計。這個場景我通常會采用四層布局方案頂部放品牌區(qū)與全局指標卡左邊欄放商品類目排行和轉(zhuǎn)化漏斗中間核心區(qū)放銷售趨勢主圖右邊欄放地域銷售熱力和實時訂單列表。布局確定后我會把設(shè)計意圖寫進提示詞然后讓 Codex 一次性生成完整的頁面骨架。關(guān)鍵詞和提示詞的關(guān)鍵不是讓 AI 自由發(fā)揮而是把每一塊區(qū)域的尺寸比例、數(shù)據(jù)源字段、圖表類型都限定死。代碼生成之后需要重點檢查的是數(shù)據(jù)聚合邏輯。電商數(shù)據(jù)表通常非常寬幾十個字段里挑出真正要展示的 8 到 10 個字段分析維度是按店鋪、按類目還是按渠道聚合這些判斷必須由人來確認Codex 只負責按指令聚合。我在實踐中發(fā)現(xiàn)讓 Codex 生成銷售趨勢圖的時候必須顯式告訴它“按日聚合、取含稅金額、排除退款訂單”否則它經(jīng)常會默認把原表所有訂單全部算進去導(dǎo)致數(shù)據(jù)虛高。3.2 智慧物流大屏空間數(shù)據(jù)的處理難點智慧物流場景的核心難點不在圖表在于地圖。貨車實時位置、區(qū)域分布、軌跡回放這些信息都需要疊加在地理底座上。實施時最大的坑是經(jīng)緯度數(shù)據(jù)的坐標系問題——有的數(shù)據(jù)源用的 GCJ-02 坐標火星坐標系有的用的是 WGS-84 標準如果不做轉(zhuǎn)換直接疊加到底圖上車輛點位會整體偏移上百米。這個場景的提示詞設(shè)計要特別強調(diào)坐標系轉(zhuǎn)換邏輯先驗證數(shù)據(jù)源坐標類型再統(tǒng)一轉(zhuǎn)換到目標地圖坐標系最后再做點位渲染。Codex 在處理坐標轉(zhuǎn)換這類有明確公式的任務(wù)時非?？煽康疤崾悄愕冒褦?shù)據(jù)源樣例和坐標系類型給它說清楚。第二個痛點是實時數(shù)據(jù)的渲染性能。幾百臺車輛每 5 秒刷新一次點位如果每次全量重繪地圖頁面會明顯卡頓。我們在某物流大屏項目里采用的方案是增量更新地圖底圖只初始化一次點位圖層使用增量更新機制新點位進入、舊點位移除、保持點位復(fù)用。Codex 生成的初始化代碼能直接跑通但增量更新部分需要人工介入設(shè)計 dispatch 策略這也說明人機協(xié)作的邊界在哪。3.3 制造業(yè)產(chǎn)線大屏狀態(tài)映射比圖表更重要制造業(yè)大屏跟前面兩類完全不同它的核心挑戰(zhàn)是設(shè)備狀態(tài)的數(shù)據(jù)到視覺映射。一臺注塑機可能有運行、待機、故障、保養(yǎng)四種狀態(tài)如何用顏色和圖形讓車間主任 3 秒內(nèi)看懂整條產(chǎn)線的健康度這是設(shè)計的核心命題。四個狀態(tài)對應(yīng)四色體系運行用綠色、待機用黃色、故障用紅色、保養(yǎng)用藍色這套映射規(guī)則必須在項目啟動時就定義清楚。Codex 在狀態(tài)映射場景能做的事情非常具體根據(jù)設(shè)備狀態(tài)字段自動生成對應(yīng)的樣式代碼狀態(tài)切換時的高亮邏輯、閃爍提醒、聲音告警的代碼骨架都可以交給它。我通常會先給它一個狀態(tài)字段樣例讓它生成一個狀態(tài)到樣式的映射配置表由人工確認后再統(tǒng)一應(yīng)用到所有設(shè)備卡片上。這樣操作比人肉寫幾百行 if-else 高效得多且不容易漏掉狀態(tài)分支。產(chǎn)線大屏還有一個容易踩的坑是告警邏輯重疊。同一臺設(shè)備可能同時出現(xiàn)“溫度過高”和“潤滑油不足”兩個告警狀態(tài)卡片只能展示最高優(yōu)先級的一種。這個優(yōu)先級規(guī)則需要人工設(shè)計成一張告警矩陣然后讓 Codex 按照矩陣生成判定邏輯。純讓 AI 自行判斷優(yōu)先級的話它給的方案在單條告警時沒問題復(fù)合告警時就會邏輯混亂。3.4 能源環(huán)保大屏預(yù)測趨勢要讓數(shù)據(jù)解釋得通能源場景跟前面幾個場景的區(qū)別在于它既要展示歷史數(shù)據(jù)和實時數(shù)據(jù)還要做趨勢預(yù)測。用水電氣分項能耗、碳排放、減排目標完成度來組織頁面視覺上是典型的“總—分—析”結(jié)構(gòu)?？傆[區(qū)放能耗總量與同比變化分項區(qū)放各能源類型占比與趨勢分析區(qū)放減排目標完成進度與預(yù)測曲線。預(yù)測曲線的生成方法是直接使用歷史數(shù)據(jù)的移動平均或者線性外推而不是引入復(fù)雜的機器學習模型。原因是大部分能耗項目的預(yù)測精度要求沒那么高業(yè)務(wù)方要的是一個“按當前趨勢下去月底會不會超用能預(yù)算”的判斷。Codex 可以很好地實現(xiàn)移動平均算法的代碼我在提示詞里給它設(shè)定窗口大小和預(yù)測區(qū)間它能穩(wěn)定生成符合周期的預(yù)測線。不過有個細節(jié)必須人工把關(guān)預(yù)測結(jié)果要能和業(yè)務(wù)邏輯自洽。比如某工廠在 7 月能耗曲線突然下降那可能是設(shè)備年檢全部停了產(chǎn)不能直接用這個月的數(shù)據(jù)去外推 8 月趨勢。這種數(shù)據(jù)異常點的剔除決策需要項目人員跟客戶確認生產(chǎn)計劃后才好拍板。技術(shù)工具在這個環(huán)節(jié)無能為力這也是行業(yè)經(jīng)驗真正產(chǎn)生價值的地方。4. 落地工作流的三個關(guān)鍵環(huán)節(jié)場景拆解完把視角拉回到工作流的整體組織上。我走完 15 個場景之后發(fā)現(xiàn)在實際操作層面有三個環(huán)節(jié)決定了項目能不能按期交付、質(zhì)量是否穩(wěn)定。這三個環(huán)節(jié)分別是提示詞工程、組件資產(chǎn)沉淀、以及需求變更的應(yīng)對機制。4.1 提示詞工程把不確定變成確定提示詞是整個工作流中最容易被低估的部分。很多人以為給 Codex 一個“幫我做個大屏”的指令就夠了實際產(chǎn)出的代碼往往需要大改。我在實踐中總結(jié)出一套提示詞模板包含七個要素項目背景、頁面尺寸、整體布局、配色規(guī)范、數(shù)據(jù)源描述、圖表類型清單、交互要求。以智慧物流大屏為例我組織出的提示詞大概是這樣的背景是某區(qū)域物流運營調(diào)度中心頁面尺寸 1920x1080頂部為標題與時間區(qū)左側(cè)為運營指標卡片與線路排行中間為車輛實時位置地圖右側(cè)為準點率趨勢與異常事件列表。配色以深藍色底、青色數(shù)據(jù)點、橙色告警點為主。數(shù)據(jù)源為車輛位置接口包含車牌、經(jīng)度、緯度、方向角、速度五個字段。地圖用散點層渲染車輛位置方向角換算為旋轉(zhuǎn)箭頭。需要支持三秒輪詢刷新。這段描述里面有明確的技術(shù)決策比如“方向角換算為旋轉(zhuǎn)箭頭”也有明確的視覺決策比如“深藍色底、青色數(shù)據(jù)點”。Codex 拿到的信息越接近最終交付形態(tài)產(chǎn)出的初稿就越接近成品后期修改成本就越低。把需求描述清楚的能力直接決定了工作流是省力還是添亂。這個環(huán)節(jié)沒有捷徑只能靠反復(fù)迭代提示詞找到自己順手的表達粒度。4.2 組件資產(chǎn)沉淀一次開發(fā)多次復(fù)用15 個場景做完積累最多的不是代碼量而是可以復(fù)用的組件資產(chǎn)。這個啟發(fā)是在第三、第四個場景時明顯感受到的電商用的指標卡組件簡單改改字段就能用在教育場景物流用的實時地圖散點組件調(diào)整一下數(shù)據(jù)接入就能用于文旅客流密度展示。組件資產(chǎn)的沉淀能讓后續(xù)新項目的開發(fā)周期明顯縮短。我沉淀組件的方式是按層管理基礎(chǔ)視覺層包含邊框、標題、背景、裝飾元素圖表功能層包含各類 ECharts 圖表封裝、數(shù)據(jù)請求邏輯、輪詢機制場景業(yè)務(wù)層包含具體行業(yè)才有的組件比如產(chǎn)線狀態(tài)卡、物流車輛標記、景區(qū)熱力分析。前兩層是跨行業(yè)復(fù)用的核心第三層按項目維度單獨管理。組件沉淀的過程必須堅持“不帶數(shù)據(jù)”原則所有組件內(nèi)部只接收標準化接口的數(shù)據(jù)決不允許把某一個項目的字段寫死在另一個項目的組件里。比如指標卡組件接受的參數(shù)是名稱、數(shù)值、同比、單位、趨勢方向這五個字段不同行業(yè)接入時只需要把自身數(shù)據(jù)映射成這五個字段就行。這樣做的好處是后續(xù)換項目時組件代碼幾乎零改動只需要替換數(shù)據(jù)映射層。4.3 需求變更應(yīng)對工具解決不了的部分大屏項目有一個公認的痛點需求變更是常態(tài)而非例外。有些變更幅度很小比如把某個指標的顯示顏色從紅色改成橙色有些變更則是結(jié)構(gòu)級的比如業(yè)務(wù)方看完初版后說“中間這塊地圖不要了換成一個大的趨勢圖”。變更管理能力直接決定了項目推進是否順暢。Codex 在結(jié)構(gòu)級變更面前表現(xiàn)得比很多人預(yù)想的更靈活。直接把變更后的布局描述發(fā)給它它會重新生成布局代碼基本能保留原有數(shù)據(jù)邏輯和樣式體系。但有個前提是原代碼的模塊化程度足夠高——如果圖表代碼和數(shù)據(jù)請求代碼耦合在一起生成新的布局時容易出現(xiàn)圖表掛接錯亂。這也倒逼我在項目前期就讓 Codex 按“布局層、數(shù)據(jù)層、圖表層”分離的方式組織代碼。人要做的工作是變更影響評估。業(yè)務(wù)方提一個變更需求時我會先判斷這個變更動了哪個層——只動視覺層是低成本改動動數(shù)據(jù)層意味著數(shù)據(jù)口徑可能變化動交互層則要評估設(shè)備性能是否支持。這層判斷做完才能決策是直接改還是需要重新走一輪設(shè)計確認。AI 工具能在一定程度上減少重復(fù)編碼的時間但需求變更的管理思路還是得靠項目經(jīng)驗來支撐。5. Codex 工作流中的高頻問題與修復(fù)鏈路自動化和效率提升背后必然伴隨新類型的問題。我集中遇到的高頻問題有三類圖表渲染異常、數(shù)據(jù)口徑錯誤、以及 AI 代碼與既有項目的兼容性沖突。每類問題都有比較典型的排查鏈路記錄下來供參考。5.1 圖表不顯示的排查思路從渲染層到容器層逐層定位有一回做文旅景區(qū)大屏地圖組件在本地開發(fā)環(huán)境一切正常部署到客戶服務(wù)器后熱力圖不顯示。這類問題最怕一上來就懷疑代碼邏輯直接重寫一遍那樣既浪費時間又容易引出新問題。正確的做法是逐層定位。第一層檢查控制臺報錯確認是不是接口跨域或 HTTP 與 HTTPS 混合內(nèi)容阻止導(dǎo)致數(shù)據(jù)沒加載第二層檢查容器高度這是前端圖表開發(fā)最常見的問題——容器父級高度為 0 導(dǎo)致圖表被壓扁隱藏第三層檢查地圖底圖資源是否被安全策略攔截。那次問題的鏈路最后定位到的是客戶服務(wù)器的資源域名沒有加白名單地圖底圖無法加載不是代碼本身的錯。Codex 生成的圖表代碼項目里通常已經(jīng)內(nèi)置了 resize 監(jiān)聽和容器自適應(yīng)邏輯所以這類問題較少出在布局階段更多出在部署環(huán)境差異上。建議在每個項目啟動時就把部署環(huán)境參數(shù)交接清楚包括資源域名、協(xié)議類型、接口鑒權(quán)方式避免后期在環(huán)境問題上反復(fù)拉鋸。5.2 數(shù)據(jù)對不上的排查思路先核對口徑再核對代碼數(shù)據(jù)口徑問題是所有大屏項目里最隱蔽的問題。某次做某零售企業(yè)門店大屏時幾張圖表的數(shù)據(jù)彼此對不上頭部指標卡顯示昨日銷售額 82 萬趨勢圖昨日某個時段卻明顯偏低。業(yè)務(wù)方截圖反饋過來第一反應(yīng)當然是檢查數(shù)據(jù)接入代碼是否有誤。排查過程分了三步第一步拉出原始查詢 SQL在數(shù)據(jù)庫里單獨跑一遍確認數(shù)據(jù)源沒問題后排除數(shù)據(jù)倉庫側(cè)故障第二步檢查前端是否做了二次聚合把 ECharts 接到的明細數(shù)據(jù)反推匯總對照之下發(fā)現(xiàn)前端確實做了一次過濾把部分已退款訂單從趨勢圖中剔除了這屬于設(shè)計邏輯不一致第三步把問題上升為數(shù)據(jù)口徑定義跟業(yè)務(wù)方確認統(tǒng)一規(guī)則后同步修改指標卡和趨勢圖的過濾條件。這個案例說明數(shù)據(jù)對不上的時候要先核對數(shù)據(jù)口徑在頁面各處的定義是否一致。Codex 生成代碼時是按指令執(zhí)行的但如果指令本身就存在口徑不一致它會忠實地把不一致展現(xiàn)在成品里。AI 不背這個鍋前期的口徑對齊才是真正的防線。5.3 AI 代碼與舊項目兼容性問題的兩類典型情況用 Codex 做新項目很順手和舊項目結(jié)合時則容易遇到兼容性坑。典型情況一是依賴版本沖突Codex 默認會按最新的依賴版本生成代碼而老項目里鎖定的還是舊版本把新代碼放進舊項目后直接報錯。解決方法是給 Codex 提供舊項目的依賴清單并在生成指令中顯式聲明版本范圍。這個差異在初始化階段處理成本極低如果在項目中途才發(fā)現(xiàn)處理成本會成倍增加。典型情況二是編碼風格不一致Codex 生成的代碼默認是 ES Module 風格而老項目還在用 CommonJS混用會觸發(fā)模塊加載錯誤。這類問題本身不難改但需要在項目啟動前就和團隊約定好統(tǒng)一的代碼風格參數(shù)把它作為提示詞的基礎(chǔ)配置寫入模板。老話說磨刀不誤砍柴工用 AI 工具時這句話同樣適用——前期約定越細后期返工越少。6. 產(chǎn)出如何過驗收關(guān)跟業(yè)務(wù)方對齊的三個動作大屏項目做得好不好最終要過業(yè)務(wù)方那一關(guān)。技術(shù)指標滿足只是底線要求業(yè)務(wù)視角的價值確認才是項目驗收的關(guān)鍵。我總結(jié)了三個動作能夠讓驗收環(huán)節(jié)少一些反復(fù)拉扯。第一個動作是在動工前做“一張紙確認”。把所有要展示的指標列在一張紙上每個指標后標注定義口徑、數(shù)據(jù)來源、刷新頻率和負責人。業(yè)務(wù)方通常會在這個環(huán)節(jié)糾正很多原先想當然的認知偏差比如“銷售額到底是含稅還是不含稅”“在線率是按設(shè)備臺數(shù)還是按工時算”等問題越早確認成本越低。第二個動作是初版交付時做“數(shù)據(jù)走查”而不是視覺效果檢查。很多業(yè)務(wù)方第一次看到大屏時容易被視覺效果帶偏注意力放在顏色和動畫上忽略了數(shù)據(jù)本身是否正確。我會刻意引導(dǎo)他們把注意力放在數(shù)據(jù)鏈路校驗上隨機挑幾個數(shù)據(jù)點位讓他們自己去查對應(yīng)的業(yè)務(wù)系統(tǒng)確認數(shù)值一致。數(shù)據(jù)沒問題后面其他環(huán)節(jié)基本不會為數(shù)據(jù)返工。第三個動作是預(yù)留“數(shù)據(jù)模擬模式”。項目開發(fā)和測試階段往往等不到生產(chǎn)環(huán)境的真實數(shù)據(jù)這時候如果直接用空數(shù)據(jù)展示大屏會顯得沒有說服力業(yè)務(wù)方也沒法判斷效果。我們在交付初版時總是默認帶上一套模擬數(shù)據(jù)數(shù)據(jù)形態(tài)和量級與真實業(yè)務(wù)高度接近業(yè)務(wù)方對著模擬數(shù)據(jù)也能直觀判斷布局和信息層級是否合理。和 Codex 的交互中模擬數(shù)據(jù)也要在提示詞階段明確因為圖表類型的選擇和數(shù)據(jù)的分布形態(tài)直接相關(guān)——偏態(tài)分布數(shù)據(jù)適合箱線圖時序數(shù)據(jù)適合折線圖這些判斷在模擬階段就能提前做完。這三個動作做完剩下的問題基本都是細節(jié)微調(diào)比如顏色偏好、指標卡大小、字體大小這類主觀審美問題。這類改動交給 Codex 處理非常高效幾乎不影響整體交付節(jié)奏。7. 最后分享一個我反復(fù)在用的模板正文內(nèi)容到這里核心經(jīng)驗基本都交代完了。最后分享一個當前項目里最常用的大屏工作流提示詞模板片段它經(jīng)過多輪迭代后相對穩(wěn)定性價比極高適合作為起手式使用。你是資深數(shù)據(jù)可視化前端工程師。請基于以下需求生成可視化大屏頁面代碼 【項目背景】一句話介紹業(yè)務(wù)場景 【頁面尺寸】1920x1080 或其他指定尺寸 【整體布局】分區(qū)描述每個區(qū)域的位置與功能頂部/左/中/右/底部 【配色規(guī)范】指定背景色、主題色、告警色、成功色 【數(shù)據(jù)說明】數(shù)據(jù)源格式、字段列表、單位、取值口徑 【圖表清單】每個區(qū)域使用的圖表類型以及每個圖表綁定哪些字段 【交互要求】輪詢刷新、點擊聯(lián)動、Tooltip 定制等 【技術(shù)約束】框架版本、圖表庫版本、組件化要求 要求代碼結(jié)構(gòu)清晰布局層/數(shù)據(jù)層/圖表層分離接口字段使用配置項驅(qū)動不使用任何 mock 數(shù)據(jù)。這個模板不是什么靈丹妙藥它解決的核心問題是給 AI 劃定明確的創(chuàng)作邊界。項目背景決定了整個大屏的敘事主題整體布局決定了視覺動線數(shù)據(jù)說明決定了圖表能不能正確綁定字段技術(shù)約束決定了代買能不能直接融入既有工程。四者缺一的話產(chǎn)出都會有不同程度的偏離。在實際項目里我一般會讓 Codex 按這個模板生成初版代碼然后人工過一遍布局和樣式再進入數(shù)據(jù)接入階段。整個流程走順之后單個行業(yè)場景從零到初版的時間基本能控制在半天以內(nèi)相比純手工開發(fā)有明顯的時間節(jié)省。但節(jié)省時間的前提始終是對業(yè)務(wù)的理解、對數(shù)據(jù)口徑的確認、對設(shè)計的判斷——這些永遠不會被工具替代反而是工具能發(fā)揮多大價值的前提。