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