做可视化大屏开发这几年我越来越确认一件事真正拖慢进度的从来不是某个图表不会写而是从业务需求到最终成品的反复拉扯。业务方丢来一句话需求设计师给一版高保真前端再照着还原中间任何一环出现理解偏差都要再走一轮沟通。Codex这类编码智能体进入工作流之后情况才真正开始改善——它不能替你搞定需求梳理但能把从“确定方案”到“可运行Demo”之间的路程压缩到原来的三分之一。这篇文章就围绕“Codex 可视化大屏工作流”这套实践结合我做过的15个行业场景设计产出合集完整拆一遍Codex在链路里到底承担什么角色、提示词怎么组织、大屏组件怎么沉淀、现场踩过哪些坑。适合正在做数据可视化、想引入AI辅助又不希望产出变“塑料质感”的团队参考。1. 为什么把 Codex 拉进大屏工作流1.1 可视化大屏交付的真实痛点大屏项目有典型的“两头难”特征。需求端业务方经常只给一句“把核心指标放上去要好看”但什么是核心指标、哪些指标要同时出现便于对比、哪些只做趋势展示全部需要反推。实现端单个大屏通常包含地图、排名列表、环形图、趋势折线、实时刷新数据等多个模块代码量不大但杂光是把ECharts配置项里的color、grid、tooltip逐项调到视觉协调就要消耗大量时间。我接触过的很多项目卡在一个环节高保真稿漂亮但前端还原时反复改样式。传统的Figma切图 前端手写的流程在大屏这个品类上效率尤其低——因为大屏的可视化组件多数不是简单的静态图层而是带有数据绑定、轮询刷新、联动下钻的动态组件。每改一次图表类型、每调一版配色都要重新写配置沟通成本极高。于是Codex这种能直接理解自然语言并产出可运行代码的智能体就找到了用武之地。1.2 编码智能体在这个场景里的能力边界先说清楚Codex不是设计工具也不是数据分析工具。它强在“把明确的诉求转化成结构良好的代码”尤其是在前端工程领域它写React组件、ECharts配置、CSS布局的完成度相当高。你给它一段需求“一个物流大屏左侧是运输路线图中间是实时订单量右侧是异常事件列表”只要提示词里信息足够它能直接产出一个带假数据的可运行页面。但它的边界同样明显。Codex不懂业务指标背后的口径也不理解“这张屏是给董事长看的还是给调度员看的”这种使用场景差异。它默认生成的样式是通用“科技蓝”风格没有审美倾向。所以在我这套工作流里Codex不是替代者而是“第一版实现者”和“快速迭代器”——我给它结构化需求它给我一个能跑、能看的版本我再在这个版本上做业务校准和视觉精修。1.3 工作流的整体设计需求、模板、生成、校准我最终沉淀下来的流程分为四个层次。最底层是场景模板库记录每个行业大屏的信息架构、常用图表、指标组合比如零售看板倾向于“区域销售地图 品类占比 实时订单流水”制造看板则更多是“设备状态矩阵 OEE趋势 告警列表”。第二层是需求结构化把业务方的零散诉求转换成Codex能理解的任务描述。第三层是AI生成与人工调整的循环先出基础版再逐步加交互和细节。第四层是上线前的数据与性能校准。这套流程的核心思路是用模板对抗空白用结构化描述降低模型理解成本用人机循环保证产出质量。它不是把大屏开发变成“一键生成”而是把重复劳动从“写代码”转移到“定义问题和检查结果”上。对我个人来说最大的收益是同样一个零售大屏过去从零搭建需要3到5天现在压缩到6到8小时其中大部分时间花在核对指标口径和调整视觉细节上。2. 15 个行业场景是怎么拆出来的2.1 场景清单与分析维度做这套合集时我没有随机挑行业写而是按“数据特征 决策场景 展示空间”三个维度来筛选。整理出的15个行业场景覆盖了业务监控类、经营管理类、指挥调度类和公共服务类四个大方向。行业场景典型使用角色核心数据特征常用核心图表零售连锁运营经理多门店、实时订单、商品结构地图、Top10榜单、环形占比制造车间生产主管设备状态、产量、良率设备状态矩阵、趋势图、告警列表物流运输调度中心车辆位置、时效、异常事件路线图、实时指标卡、时间轴金融风控风控分析师交易量、风险事件、规则命中雷达图、热力图、漏斗图能源电力运维人员发电量、负荷、设备健康度区域分布图、Gauge仪表盘、曲线图智慧园区物业管理者人流量、能耗、安防告警3D建筑模型、人流热力图、指标卡交通枢纽运营调度客流、班次准点率、应急事件站点图、条形图、状态灯医疗资源院办管理者床位、门诊量、手术排期柱状图、饼图、实时滚动列表教育办学校务管理学生出勤、成绩分布、资源使用散点图、趋势图、统计卡农业种植基地管理者土壤墒情、气象、生长阶段地图标记、曲线图、阶段进度条文旅景区运营负责人游客量、热门项目、满意度客流趋势、词云、排行榜港口码头作业调度船舶、装卸效率、堆场状态堆场平面图、甘特图、指标卡公共应急指挥中心事件分布、资源调度、响应时长地图、时间线、联动面板资产管理财务部门资产分布、折旧、使用率树图、柱状图、状态分布舆情监测品牌公关声量、情感倾向、热点事件趋势图、情感分布、关键词列表这个清单的价值不在于“多”而在于每个场景背后都对应着一种信息架构范式。零售和文旅看上去都是“客流热区”但零售的决策点是结构占比文旅的决策点是峰值承载制造和能源都需要设备监控但制造更关注OEE和工单能源更关注负荷和告警分级。先把场景差异想清楚生成的代码才有针对性。2.2 从 15 个场景里提炼出的四种页面范式实际做下来我发现所谓行业差异落在页面结构上其实可以归纳成四种范式。第一种是“总览指挥式”大屏中央放核心地图或3D场景两侧分布指标卡和排行榜适合物流、应急、园区第二种是“指标聚焦式”上方一排KPI卡中部是主趋势图下方是明细表格适合零售、教育、资产第三种是“流程跟踪式”按业务链路从左到右排列适合制造工单、港口作业第四种是“对比分析式”强调多组数据并列展示适合舆情、金融、医疗。在向Codex描述需求时直接告诉它采用哪种范式比描述零散图表要有效得多。比如写“物流调度大屏采用总览指挥式结构中央区域为全国运输网络地图左侧展示异常事件右侧展示时效达标率”它生成出来的整体布局基本一次到位不会出现图表堆叠错乱的情况。这背后其实是在降低模型对空间关系的推测成本——你替它把版式信息架构定了它只需要在框架内填充实现。2.3 场景模板沉淀的两个关键经验经验一每个场景模板必须包含“决策动作”。大屏不是展览品它最终要支撑一个动作零售经理看了要调补货调度员看了要派单指挥中心看了要调度资源。所以在模板里我会明确写下“看到什么指标异常应该触发什么动作”的关联逻辑并在界面上预留操作入口。这个前缀信息让Codex生成的功能更有目的性也更容易说服业务方验收。经验二模板里的假数据要贴近真实分布。很多AI生成的大屏死板问题不在图表配置而在数据太“规整”——所有数值都在正常范围内曲线圆滑得像正弦波。我在模板里会给每组假数据加入毛刺、偶发跳变、阶段性波动并标注“周四晚高峰订单量陡增”“北部区域设备故障率偏高”这类业务注释。这样生成出来的大屏视觉上已经能模拟上线后的真实状态业务方看Demo时也能更早发现问题。3. 实操全流程从提示词到可运行大屏3.1 结构化提示词的写法在实践里我给Codex的提示词从来不是一句话而是三段式的结构化描述。第一段定义项目背景和设备约束“这是某零售连锁集团的门店运营监控大屏分辨率为3840x2160运行在拼接屏环境需要支持定时自动刷新请使用React ECharts实现。”第二段定义信息架构“整体采用指标聚焦式布局顶部展示今日销售额、订单量、客单价、会员新增四个核心KPI中部左侧为区域销售地图中部右侧为品类销售占比环形图底部为门店实时销售排名列表按销售额倒序排列。”第三段定义交互和视觉“地图支持省份下钻点击省份后联动更新右侧环形图和底部列表配色采用深蓝背景、青色和橙色作为主辅色避免使用红色系除非指标低于目标值80%。请生成完整工程代码包含模拟数据文件。”用这种方式写提示词Codex能在第一版就给出接近终稿的页面结构。我踩过比较多的坑是给的信息太泛比如只写“做一个门店销售大屏”它就会平均用力每个模块都做但每个模块都不够贴合业务后续返工成本反而更高。3.2 技术栈选择与大屏工程的骨架我最终固定下来的技术栈是React TypeScript ECharts Tailwind CSS外加Vite做构建。选这个组合的原因很直接——React组件的拆分方式适合把大屏的每个区块做成独立模块ECharts在图表覆盖面和配置灵活性上仍然是最稳的Tailwind CSS用来快速处理大屏的间距、定位、响应式适配效率比手写CSS高很多。Codex在这个组合下的生成质量是最稳定的因为相关开源代码和社区讨论太丰富了模型的训练数据覆盖度足够高。工程骨架我会让Codex生成后再做一次统一改造。每个大屏项目固定拆成components图表组件、layouts区块布局、data模拟数据、hooks定时刷新和联动逻辑、pages页面入口五个目录。组件全部是纯展示组件接收数据props不直接请求接口。这样做的目的是让Codex后续修改时可以精准定位文件而不是在巨型组件里反复解读上下文。3.3 布局细节、图表配置与样式调优在布局层面大屏区别于普通后台页面最核心的一点是“信息密度”和“视觉层级”。拼接屏分辨率高但观看距离也远所以字体最小不能低于28px指标卡的数字通常要做到60px以上。我会在提示词里直接写明这些约束省得生成后再逐项调。ECharts配置的部分Codex生成的内容整体可用但有几个位置需要人工修正。一个是grid边距默认配置在宽屏下经常导致图表内容偏小需要手动压缩边距让图形区域撑满容器。另一个是tooltip默认的悬浮框在拼接屏上会被系统光标遮挡我通常会改成trigger: axis并将confine: true保证提示框不出界。颜色这块我习惯让Codex先按“主色 辅色 警示色”的语义逻辑生成配置然后我再统一调整成品牌色板避免每张图各自为政。3.4 数据接入先用模拟数据跑通再换真实接口大屏项目里最影响开发节奏的事情之一就是真实接口还没好前端被卡住。我的做法是所有大屏一律先接模拟数据跑通整个交互链路后再写一个mock开关切换真实接口。Codex生成的模拟数据文件最好保持一个约定所有列表数据、趋势数据、地图数据都集中放在data/目录下并且导出函数保持一致的签名比如getSalesTrend(days: number): TrendPoint[]。这样后期接真实接口时只需要替换数据源模块图表组件完全不用动。15个场景里我有一半以上是用这种方式把联调时间压缩到半天以内的。数据刷新则统一用setInterval包一层useDashboardData的Hook所有区块共享同一个刷新时钟避免每张图各自刷新导致画面跳变不同步。3.5 大屏部署与运行环境适配部署环节容易被忽略但实际上线时问题最多。拼接屏控制主机一般配置不高浏览器打开大屏页面的同时可能还要跑其他程序所以性能需要刻意控制。我在工程里做了三件事第一关闭不必要的动画ECharts的animation: false在拼接屏上感知差异不大但CPU占用能降不少第二地图GeoJSON只加载当前需要的层级不要一次性加载全国到区县的四级边界第三定时刷新组件在页面隐藏时自动暂停避免后台标签页持续消耗资源。还有一个适配细节大屏通常运行在固定分辨率的Chromium浏览器中我用的是transform: scale()方案来适配不同尺寸的屏幕页面基准宽度设为1920根据实际屏幕分辨率等比缩放同时关闭浏览器的缩放功能。这样可以保证无论最终屏幕是1080P还是4K版面比例都不会乱。4. 常见问题与排查技巧实录4.1 生成结果“能跑但不对”的处理思路Codex产出代码后最常见的三个问题我按出现频率排一下图表不显示、布局溢出、数据不更新。图表不显示大概率是容器高度为0大屏项目里组件外层如果不给明确高度ECharts初始化时拿不到尺寸就会静默失败排查方式是打开开发者工具看canvas元素是否存在。布局溢出则主要是固定定位和百分比宽度冲突常见于地图区块和排行榜区块解决方案是把大屏主体统一用absolute定位区块内部再使用弹性布局。数据不更新集中在定时器失效排查时先看Hook是否正确清理了上一个定时器在React严格模式下双调用会叠加定时器导致页面卡顿。4.2 问题排查速查表现象常见原因快速处理方式图表区域空白容器无高度或初始化时机过早给容器固定高度或在useEffect内初始化地图散点定位偏移GeoJSON坐标系与数据经纬度不匹配统一数据为WGS84或GCJ02格式大屏字体模糊非整数倍缩放导致字体渲染模糊基准宽度设为整数分辨率关闭系统缩放刷新时图表闪烁整图重绘而非数据更新改用setOption且不传notMerge参数拼接屏侧边内容截断浏览器安全边距或缩放比例错误页面容器加overflow: hidden并居中多个组件联动失效状态提升层级不对或事件未绑定检查事件是否挂在图表实例而非容器上中文在部分主机显示乱码字体缺失或编码不一致引入Web字体包统一使用UTF-8图表颜色与设计稿不一致配置被组件默认值覆盖在setOption时传replaceMerge重置颜色系列4.3 团队协作里的关键约定Codex参与开发之后代码量生成速度变快但“生成快”也意味着代码审查压力变大。我给自己定了三条协作规则。第一AI生成的代码必须人工review后再提交重点看数据获取逻辑、定时器生命周期和安全边界而不是盯着排版和样式。第二公共组件必须由人工维护不让Codex直接修改比如所有的图表封装组件、请求Hook、通用配色变量这些是一旦改乱牵连全局的部分。第三每次需求变更先更新提示词文档再让Codex执行代码改动。这听起来多余但实际操作中提示词文档就是需求规格说明书它保证了AI生成代码的上下文一致也方便团队其他成员了解这段代码的意图。4.4 几个容易栽进去的坑再单独说几个我实际踩过、且不太容易搜到解决方案的坑。ECharts的legend在数据全为0时默认不显示这个问题在制造场景里特别容易误判看起来像是图表没渲染其实是数据值全为0导致图例过滤。解决方法是给legend.data手动指定项并设置selectedMode: false。还有大屏的自动轮播排名列表经常会遇到“新数据与旧数据id相同但内容不同”的场景如果只用key{index}会导致组件复用旧状态必须用业务唯一id作为key。拼接屏跨屏显示也是反复遇到的坑。实际项目中控制主机可能通过HDMI连接多块物理屏幕组合成一个大画面浏览器窗口如果刚好跨在屏幕拼接缝上内容会被分割。常规做法是用window.resizeTo固定浏览器窗口位置或者把页面切成多个独立窗口分别对应每块屏幕。这个在开发环境很难模拟最好提前跟现场实施同事确认具体方案。5. 一点个人体会把Codex纳入这套工作流之后我对“AI辅助开发”的理解比之前具体了很多。它最好的状态是像一个经验丰富但缺乏业务背景的协作同事——你把上下文喂得越完整它回给你的东西越靠谱你指望它完全理解业务它就会给你一个看起来完整但经不起推敲的版本。15个场景做下来我最深的感受是工作流优化的重心不应该是“如何让AI一步到位”而是“如何让自己把需求想得更清楚”。提示词写得好的前提是你对页面架构、指标关系、用户决策链路都有了明确判断这些能力在任何时代都是核心。另外我建议所有做可视化大屏的团队都从自己最熟悉的两个行业场景开始沉淀模板而不是一上来就追求覆盖多少领域。模板不在多在于每个模板真的能体现行业的数据特征和决策逻辑这样的模板配上Codex的生成能力才有可能在下一个项目里帮你节省真正的时间。
做可视化大屏开发这几年我越来越确认一件事真正拖慢进度的从来不是某个图表不会写而是从业务需求到最终成品的反复拉扯。业务方丢来一句话需求设计师给一版高保真前端再照着还原中间任何一环出现理解偏差都要再走一轮沟通。Codex这类编码智能体进入工作流之后情况才真正开始改善——它不能替你搞定需求梳理但能把从“确定方案”到“可运行Demo”之间的路程压缩到原来的三分之一。这篇文章就围绕“Codex 可视化大屏工作流”这套实践结合我做过的15个行业场景设计产出合集完整拆一遍Codex在链路里到底承担什么角色、提示词怎么组织、大屏组件怎么沉淀、现场踩过哪些坑。适合正在做数据可视化、想引入AI辅助又不希望产出变“塑料质感”的团队参考。1. 为什么把 Codex 拉进大屏工作流1.1 可视化大屏交付的真实痛点大屏项目有典型的“两头难”特征。需求端业务方经常只给一句“把核心指标放上去要好看”但什么是核心指标、哪些指标要同时出现便于对比、哪些只做趋势展示全部需要反推。实现端单个大屏通常包含地图、排名列表、环形图、趋势折线、实时刷新数据等多个模块代码量不大但杂光是把ECharts配置项里的color、grid、tooltip逐项调到视觉协调就要消耗大量时间。我接触过的很多项目卡在一个环节高保真稿漂亮但前端还原时反复改样式。传统的Figma切图 前端手写的流程在大屏这个品类上效率尤其低——因为大屏的可视化组件多数不是简单的静态图层而是带有数据绑定、轮询刷新、联动下钻的动态组件。每改一次图表类型、每调一版配色都要重新写配置沟通成本极高。于是Codex这种能直接理解自然语言并产出可运行代码的智能体就找到了用武之地。1.2 编码智能体在这个场景里的能力边界先说清楚Codex不是设计工具也不是数据分析工具。它强在“把明确的诉求转化成结构良好的代码”尤其是在前端工程领域它写React组件、ECharts配置、CSS布局的完成度相当高。你给它一段需求“一个物流大屏左侧是运输路线图中间是实时订单量右侧是异常事件列表”只要提示词里信息足够它能直接产出一个带假数据的可运行页面。但它的边界同样明显。Codex不懂业务指标背后的口径也不理解“这张屏是给董事长看的还是给调度员看的”这种使用场景差异。它默认生成的样式是通用“科技蓝”风格没有审美倾向。所以在我这套工作流里Codex不是替代者而是“第一版实现者”和“快速迭代器”——我给它结构化需求它给我一个能跑、能看的版本我再在这个版本上做业务校准和视觉精修。1.3 工作流的整体设计需求、模板、生成、校准我最终沉淀下来的流程分为四个层次。最底层是场景模板库记录每个行业大屏的信息架构、常用图表、指标组合比如零售看板倾向于“区域销售地图 品类占比 实时订单流水”制造看板则更多是“设备状态矩阵 OEE趋势 告警列表”。第二层是需求结构化把业务方的零散诉求转换成Codex能理解的任务描述。第三层是AI生成与人工调整的循环先出基础版再逐步加交互和细节。第四层是上线前的数据与性能校准。这套流程的核心思路是用模板对抗空白用结构化描述降低模型理解成本用人机循环保证产出质量。它不是把大屏开发变成“一键生成”而是把重复劳动从“写代码”转移到“定义问题和检查结果”上。对我个人来说最大的收益是同样一个零售大屏过去从零搭建需要3到5天现在压缩到6到8小时其中大部分时间花在核对指标口径和调整视觉细节上。2. 15 个行业场景是怎么拆出来的2.1 场景清单与分析维度做这套合集时我没有随机挑行业写而是按“数据特征 决策场景 展示空间”三个维度来筛选。整理出的15个行业场景覆盖了业务监控类、经营管理类、指挥调度类和公共服务类四个大方向。行业场景典型使用角色核心数据特征常用核心图表零售连锁运营经理多门店、实时订单、商品结构地图、Top10榜单、环形占比制造车间生产主管设备状态、产量、良率设备状态矩阵、趋势图、告警列表物流运输调度中心车辆位置、时效、异常事件路线图、实时指标卡、时间轴金融风控风控分析师交易量、风险事件、规则命中雷达图、热力图、漏斗图能源电力运维人员发电量、负荷、设备健康度区域分布图、Gauge仪表盘、曲线图智慧园区物业管理者人流量、能耗、安防告警3D建筑模型、人流热力图、指标卡交通枢纽运营调度客流、班次准点率、应急事件站点图、条形图、状态灯医疗资源院办管理者床位、门诊量、手术排期柱状图、饼图、实时滚动列表教育办学校务管理学生出勤、成绩分布、资源使用散点图、趋势图、统计卡农业种植基地管理者土壤墒情、气象、生长阶段地图标记、曲线图、阶段进度条文旅景区运营负责人游客量、热门项目、满意度客流趋势、词云、排行榜港口码头作业调度船舶、装卸效率、堆场状态堆场平面图、甘特图、指标卡公共应急指挥中心事件分布、资源调度、响应时长地图、时间线、联动面板资产管理财务部门资产分布、折旧、使用率树图、柱状图、状态分布舆情监测品牌公关声量、情感倾向、热点事件趋势图、情感分布、关键词列表这个清单的价值不在于“多”而在于每个场景背后都对应着一种信息架构范式。零售和文旅看上去都是“客流热区”但零售的决策点是结构占比文旅的决策点是峰值承载制造和能源都需要设备监控但制造更关注OEE和工单能源更关注负荷和告警分级。先把场景差异想清楚生成的代码才有针对性。2.2 从 15 个场景里提炼出的四种页面范式实际做下来我发现所谓行业差异落在页面结构上其实可以归纳成四种范式。第一种是“总览指挥式”大屏中央放核心地图或3D场景两侧分布指标卡和排行榜适合物流、应急、园区第二种是“指标聚焦式”上方一排KPI卡中部是主趋势图下方是明细表格适合零售、教育、资产第三种是“流程跟踪式”按业务链路从左到右排列适合制造工单、港口作业第四种是“对比分析式”强调多组数据并列展示适合舆情、金融、医疗。在向Codex描述需求时直接告诉它采用哪种范式比描述零散图表要有效得多。比如写“物流调度大屏采用总览指挥式结构中央区域为全国运输网络地图左侧展示异常事件右侧展示时效达标率”它生成出来的整体布局基本一次到位不会出现图表堆叠错乱的情况。这背后其实是在降低模型对空间关系的推测成本——你替它把版式信息架构定了它只需要在框架内填充实现。2.3 场景模板沉淀的两个关键经验经验一每个场景模板必须包含“决策动作”。大屏不是展览品它最终要支撑一个动作零售经理看了要调补货调度员看了要派单指挥中心看了要调度资源。所以在模板里我会明确写下“看到什么指标异常应该触发什么动作”的关联逻辑并在界面上预留操作入口。这个前缀信息让Codex生成的功能更有目的性也更容易说服业务方验收。经验二模板里的假数据要贴近真实分布。很多AI生成的大屏死板问题不在图表配置而在数据太“规整”——所有数值都在正常范围内曲线圆滑得像正弦波。我在模板里会给每组假数据加入毛刺、偶发跳变、阶段性波动并标注“周四晚高峰订单量陡增”“北部区域设备故障率偏高”这类业务注释。这样生成出来的大屏视觉上已经能模拟上线后的真实状态业务方看Demo时也能更早发现问题。3. 实操全流程从提示词到可运行大屏3.1 结构化提示词的写法在实践里我给Codex的提示词从来不是一句话而是三段式的结构化描述。第一段定义项目背景和设备约束“这是某零售连锁集团的门店运营监控大屏分辨率为3840x2160运行在拼接屏环境需要支持定时自动刷新请使用React ECharts实现。”第二段定义信息架构“整体采用指标聚焦式布局顶部展示今日销售额、订单量、客单价、会员新增四个核心KPI中部左侧为区域销售地图中部右侧为品类销售占比环形图底部为门店实时销售排名列表按销售额倒序排列。”第三段定义交互和视觉“地图支持省份下钻点击省份后联动更新右侧环形图和底部列表配色采用深蓝背景、青色和橙色作为主辅色避免使用红色系除非指标低于目标值80%。请生成完整工程代码包含模拟数据文件。”用这种方式写提示词Codex能在第一版就给出接近终稿的页面结构。我踩过比较多的坑是给的信息太泛比如只写“做一个门店销售大屏”它就会平均用力每个模块都做但每个模块都不够贴合业务后续返工成本反而更高。3.2 技术栈选择与大屏工程的骨架我最终固定下来的技术栈是React TypeScript ECharts Tailwind CSS外加Vite做构建。选这个组合的原因很直接——React组件的拆分方式适合把大屏的每个区块做成独立模块ECharts在图表覆盖面和配置灵活性上仍然是最稳的Tailwind CSS用来快速处理大屏的间距、定位、响应式适配效率比手写CSS高很多。Codex在这个组合下的生成质量是最稳定的因为相关开源代码和社区讨论太丰富了模型的训练数据覆盖度足够高。工程骨架我会让Codex生成后再做一次统一改造。每个大屏项目固定拆成components图表组件、layouts区块布局、data模拟数据、hooks定时刷新和联动逻辑、pages页面入口五个目录。组件全部是纯展示组件接收数据props不直接请求接口。这样做的目的是让Codex后续修改时可以精准定位文件而不是在巨型组件里反复解读上下文。3.3 布局细节、图表配置与样式调优在布局层面大屏区别于普通后台页面最核心的一点是“信息密度”和“视觉层级”。拼接屏分辨率高但观看距离也远所以字体最小不能低于28px指标卡的数字通常要做到60px以上。我会在提示词里直接写明这些约束省得生成后再逐项调。ECharts配置的部分Codex生成的内容整体可用但有几个位置需要人工修正。一个是grid边距默认配置在宽屏下经常导致图表内容偏小需要手动压缩边距让图形区域撑满容器。另一个是tooltip默认的悬浮框在拼接屏上会被系统光标遮挡我通常会改成trigger: axis并将confine: true保证提示框不出界。颜色这块我习惯让Codex先按“主色 辅色 警示色”的语义逻辑生成配置然后我再统一调整成品牌色板避免每张图各自为政。3.4 数据接入先用模拟数据跑通再换真实接口大屏项目里最影响开发节奏的事情之一就是真实接口还没好前端被卡住。我的做法是所有大屏一律先接模拟数据跑通整个交互链路后再写一个mock开关切换真实接口。Codex生成的模拟数据文件最好保持一个约定所有列表数据、趋势数据、地图数据都集中放在data/目录下并且导出函数保持一致的签名比如getSalesTrend(days: number): TrendPoint[]。这样后期接真实接口时只需要替换数据源模块图表组件完全不用动。15个场景里我有一半以上是用这种方式把联调时间压缩到半天以内的。数据刷新则统一用setInterval包一层useDashboardData的Hook所有区块共享同一个刷新时钟避免每张图各自刷新导致画面跳变不同步。3.5 大屏部署与运行环境适配部署环节容易被忽略但实际上线时问题最多。拼接屏控制主机一般配置不高浏览器打开大屏页面的同时可能还要跑其他程序所以性能需要刻意控制。我在工程里做了三件事第一关闭不必要的动画ECharts的animation: false在拼接屏上感知差异不大但CPU占用能降不少第二地图GeoJSON只加载当前需要的层级不要一次性加载全国到区县的四级边界第三定时刷新组件在页面隐藏时自动暂停避免后台标签页持续消耗资源。还有一个适配细节大屏通常运行在固定分辨率的Chromium浏览器中我用的是transform: scale()方案来适配不同尺寸的屏幕页面基准宽度设为1920根据实际屏幕分辨率等比缩放同时关闭浏览器的缩放功能。这样可以保证无论最终屏幕是1080P还是4K版面比例都不会乱。4. 常见问题与排查技巧实录4.1 生成结果“能跑但不对”的处理思路Codex产出代码后最常见的三个问题我按出现频率排一下图表不显示、布局溢出、数据不更新。图表不显示大概率是容器高度为0大屏项目里组件外层如果不给明确高度ECharts初始化时拿不到尺寸就会静默失败排查方式是打开开发者工具看canvas元素是否存在。布局溢出则主要是固定定位和百分比宽度冲突常见于地图区块和排行榜区块解决方案是把大屏主体统一用absolute定位区块内部再使用弹性布局。数据不更新集中在定时器失效排查时先看Hook是否正确清理了上一个定时器在React严格模式下双调用会叠加定时器导致页面卡顿。4.2 问题排查速查表现象常见原因快速处理方式图表区域空白容器无高度或初始化时机过早给容器固定高度或在useEffect内初始化地图散点定位偏移GeoJSON坐标系与数据经纬度不匹配统一数据为WGS84或GCJ02格式大屏字体模糊非整数倍缩放导致字体渲染模糊基准宽度设为整数分辨率关闭系统缩放刷新时图表闪烁整图重绘而非数据更新改用setOption且不传notMerge参数拼接屏侧边内容截断浏览器安全边距或缩放比例错误页面容器加overflow: hidden并居中多个组件联动失效状态提升层级不对或事件未绑定检查事件是否挂在图表实例而非容器上中文在部分主机显示乱码字体缺失或编码不一致引入Web字体包统一使用UTF-8图表颜色与设计稿不一致配置被组件默认值覆盖在setOption时传replaceMerge重置颜色系列4.3 团队协作里的关键约定Codex参与开发之后代码量生成速度变快但“生成快”也意味着代码审查压力变大。我给自己定了三条协作规则。第一AI生成的代码必须人工review后再提交重点看数据获取逻辑、定时器生命周期和安全边界而不是盯着排版和样式。第二公共组件必须由人工维护不让Codex直接修改比如所有的图表封装组件、请求Hook、通用配色变量这些是一旦改乱牵连全局的部分。第三每次需求变更先更新提示词文档再让Codex执行代码改动。这听起来多余但实际操作中提示词文档就是需求规格说明书它保证了AI生成代码的上下文一致也方便团队其他成员了解这段代码的意图。4.4 几个容易栽进去的坑再单独说几个我实际踩过、且不太容易搜到解决方案的坑。ECharts的legend在数据全为0时默认不显示这个问题在制造场景里特别容易误判看起来像是图表没渲染其实是数据值全为0导致图例过滤。解决方法是给legend.data手动指定项并设置selectedMode: false。还有大屏的自动轮播排名列表经常会遇到“新数据与旧数据id相同但内容不同”的场景如果只用key{index}会导致组件复用旧状态必须用业务唯一id作为key。拼接屏跨屏显示也是反复遇到的坑。实际项目中控制主机可能通过HDMI连接多块物理屏幕组合成一个大画面浏览器窗口如果刚好跨在屏幕拼接缝上内容会被分割。常规做法是用window.resizeTo固定浏览器窗口位置或者把页面切成多个独立窗口分别对应每块屏幕。这个在开发环境很难模拟最好提前跟现场实施同事确认具体方案。5. 一点个人体会把Codex纳入这套工作流之后我对“AI辅助开发”的理解比之前具体了很多。它最好的状态是像一个经验丰富但缺乏业务背景的协作同事——你把上下文喂得越完整它回给你的东西越靠谱你指望它完全理解业务它就会给你一个看起来完整但经不起推敲的版本。15个场景做下来我最深的感受是工作流优化的重心不应该是“如何让AI一步到位”而是“如何让自己把需求想得更清楚”。提示词写得好的前提是你对页面架构、指标关系、用户决策链路都有了明确判断这些能力在任何时代都是核心。另外我建议所有做可视化大屏的团队都从自己最熟悉的两个行业场景开始沉淀模板而不是一上来就追求覆盖多少领域。模板不在多在于每个模板真的能体现行业的数据特征和决策逻辑这样的模板配上Codex的生成能力才有可能在下一个项目里帮你节省真正的时间。
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
