AI生成智慧交通驾驶舱代码实战：从搭建到源码私有化

1. 先想明白驾驶舱到底要做什么AI在这里面能扛多少活1.1 智慧交通驾驶舱的核心模块与数据关系智慧交通驾驶舱说白了就是把城市交通的“家底”用一块大屏讲清楚。它不是一个普通的后台管理页面而是一个面向管理者、大屏展示、实时监控一体的可视化系统。我接触过的交通类项目无论是一线城市的分指挥中心还是区县级别的交通运行监测平台核心模块基本逃不出这几块综合态势总览展示整个区域的交通运行指数、拥堵路段排行、在途车辆数、重点路口流量。实时路况图层在地图上渲染道路拥堵状态红黄绿三色铺满路网这是驾驶舱最直观的视觉重心。车辆监控与轨迹回放对公交车、出租车、两客一危车辆进行实时定位支持查询历史轨迹。信号灯与路口监测重点路口信号周期、排队长度、通行效率的可视化。告警中心与工单联动拥堵事件、违法事件、设备离线告警从发现到派单处置的业务闭环。模块之间不是孤立的。数据流向一般是“采集层 → 接入层 → 处理层 → 展示层”路侧设备、GPS终端把数据推到接入网关经过清洗计算之后落到数据库或消息队列里前端通过接口订阅这些数据再映射到地图和大屏组件上。AI生成代码的时候最难的部分不是某个组件怎么写而是这套数据流转关系能不能被它理解。1.2 哪些活适合交给AI哪些必须自己写这是所有想用AI提效的团队先要回答的问题。我的判断标准很简单界面和交互的代码可以交出去逻辑和架构的决策必须自己把控。适合交给AI的部分大屏页面的布局代码包括栅格布局、Flex布局、CSS样式适配。常用可视化组件的初始化代码比如ECharts的折线图、柱状图、散点图配置。地图底图的初始化包括地图实例创建、图层叠加、标记点绑定。表格、表单、筛选器、搜索框这类CRUD界面的结构代码。各类Sass/Less样式片段主题色变量通用工具函数。必须自己写的部分数据接入层的封装尤其是涉及多源数据聚合、冲突处理、断线重连的逻辑。告警规则引擎。AI生成的规则判断往往是if-else堆出来的真实场景里一条拥堵告警可能需要综合车速、排队长度、持续时间多个条件规则写不好就全是误报。权限控制体系。一个驾驶舱有总览大屏、处长驾驶舱、值班员操作台数据可见范围、操作权限完全不同这部分代码AI帮不上什么实质性的忙。与既有业务系统的对接协议。大多数交通项目不是从零开始的周边已经有一套信号控制系统或者交通管理平台驾驶舱要跟它们做数据交换AI不知道你内部系统的接口长什么样。1.3 为什么“源码私有化”这件事从第一天就要定死“AI生成的代码算谁的”这个问题很多团队是项目做到一半才想起来然后开始扯皮。我强烈建议在项目启动前就把口径定清楚驾驶舱的最终交付物必须是完整、可编译、可部署的私有源码包而不是只能在某个在线平台上运行的工程。原因很实际。第一政务和交通类项目普遍要过等保测评和第三方审计系统里的数据、代码、部署架构都要能自查代码如果只有AI平台里的一份云端副本审计的人来了连代码目录都看不见这一关过不去。第二项目验收之后还要持续运维今天改一个路网图层明天加一个指标卡片每次都回平台重新生成、再导出流程太脆弱平台一旦调整了模型或收费策略你的项目就被动了。第三真正的业务系统永远是定制化的AI平台帮你写的是百分之七八十的通用部分剩下百分之二三十的个性改造需要直接在本地源码上做。所以在选AI代码生成工具的时候我优先验证的不是它生成的页面有多炫而是导出的工程能不能不依赖平台独立运行。这里有一个很关键的判断手段把导出的代码拿下来关掉所有网络请求试试如果页面还能打开、假数据还能渲染说明工程是纯前端的私有化的成本低如果连登录、渲染都要回调平台端的接口这个坑就大了。2. 实操第一步用AI把驾驶舱的骨架搭出来2.1 需求描述怎么写AI才能懂很多人在AI生成代码这一环节就翻车不是工具不行而是需求描述得太笼统。你说“帮我做一个智慧交通驾驶舱”AI肯定给你一个泛泛的模板里面放几个饼图柱状图地图上标几个点看起来像那么回事但离可用还有十万八千里。我建议用“拆解描述法”把需求拆成四个维度喂给AI页面结构、数据指标、交互方式、视觉风格。页面结构要说清楚顶部是什么、左侧是什么、中间是什么、右侧是什么大屏整体是几比几的分辨率。数据指标要说清楚每个区域展示哪些指标指标的口径是什么刷新频率是多少。交互方式要说清楚点击地图上的车辆弹什么面板点击拥堵路段做什么联动图表之间有没有钻取关系。视觉风格要说清楚深色还是浅色主色调是什么参考哪个大屏的感觉。举个例子我在做某个城市交通运行监测平台时给AI的提示词是这样写的生成一个适用于LED大屏的智慧交通驾驶舱前端页面分辨率为1920x1080深色科技风主色调为蓝色#00B4FF和青色#00E5FF。页面结构如下顶部为标题栏显示“XX市交通运行监测平台”右侧显示当前时间和天气中间区域为地图使用高德地图展示路网与实时路况地图上叠加重点车辆位置标记地图左侧为交通运行指数面板包含拥堵指数、平均车速、在途车辆数三个核心指标每个指标配一个趋势小图地图右侧为事件告警面板按时间倒序展示告警事件列表每条事件包含时间、位置、类型、状态四个字段底部为通行效率分析区域展示四个重点路口的排队长度和信号周期对比柱状图。交互要求点击地图车辆标记弹出车辆信息气泡点击告警列表事件地图自动定位到事件位置并高亮。这段描述不算长但已经把页面结构、数据指标、交互方式和视觉风格都说清楚了。AI生成的初版代码基本不用改布局直接能跑出80分的效果。2.2 选型前端框架、可视化库、地图组件的取舍AI生成代码之前框架和组件库的选型要先把基调定下来不然导出的代码五花八门维护成本极高。交通驾驶舱场景里我的默认组合是这样的前端框架首选Vue 3 TypeScript。Vue在国内的项目生态里非常成熟团队容易招人组件库丰富TypeScript在数据模型复杂的场景下能少踩很多运行时错误。React当然也行但如果你跟AI描述需求的时候没有指定AI默认给Vue的概率很大反而省事。可视化库以ECharts为主。地图上用高德地图或者Mapbox GL。ECharts的迁徙图、散点图、关系图在交通场景里覆盖率高资料多AI训练语料里关于ECharts配置的样本非常充足生成的代码准确率高。Mapbox GL在3D航拍和路网叠加的效果上更好但涉及底图风格定制的复杂度更高。UI组件库选Element Plus或者Naive UI。Element Plus在后台管理系统和驾驶舱里都很普遍AI对它的掌握程度高Naive UI的TypeScript体验好但语料相对少一些。如果是给政府客户做项目Element Plus的成熟案例多客户不容易挑毛病。这个选型组合还有一个额外的优势AI生成代码的准确率高度依赖训练语料的数据规模。Vue3、ECharts、Element Plus是全国开发者用量最大的组合之一AI在这些框架上见过的代码模式远远多于一些小众组合。选大众组合不是保守而是在为AI的人效买单。2.3 提示词模板 生成结果拆解这里给一份可以直接套用的提示词模板涵盖页面骨架、图表组件、地图场景三大类。页面骨架模板使用Vue 3 TypeScript Element Plus生成一个驾驶舱页面分辨率1920x1080使用flex布局左侧面板宽度380px中间地图区域自适应右侧面板宽度420px底部区域高度180px。使用深色主题背景色为#0A1628面板背景半透明使用深蓝色渐变边框。请分别生成App.vue、布局组件、样式文件并给出package.json中需要的依赖列表。图表组件模板使用ECharts生成一个[图表类型]数据通过props传入类型为[数据类型]包含[具体维度和指标]需要支持[交互行为如tooltip、legend切换、dataZoom]图表配色使用[#00B4FF, #00E5FF, #FFB400, #FF5B6E]当数据量超过[阈值]时自动显示滚动条。地图场景模板基于高德地图JS API 2.0生成一个实时路况图层组件地图中心点为经度[xxx]纬度[xxx]初始化缩放级别[xx]加载路况图层并在地图上添加车辆标记标记使用自定义DivIcon样式颜色根据车辆状态切换正常绿色、告警红色、离线灰色点击标记弹出包含车辆编号、速度、状态、所属企业的信息窗体。用这些模板生成出来的代码结构上一般都比较规整。但我要提醒一句AI生成代码最大的风险不是“它写不出来”而是“它写得很自信但细节有错”。比如ECharts的配置项里有几个特性更新之后废弃了AI可能还在用旧写法地图组件的key过期了它不会告诉你事件监听的解绑有时候会漏掉导致组件销毁之后还在重复请求。生成代码之后第一件事不是看效果而是先审查入口文件、数据模型定义、接口请求封装三个地方的健壮性。这三个地方出问题后面越改越乱。3. 核心难点驾驶舱里最值钱的几个功能怎么实现3.1 地图与车辆轨迹实时位置不是画点那么简单地图是交通驾驶舱的灵魂也是AI生成代码时最需要人工介入的部分。AI能帮你把地图实例创建好、标记点铺上去但真实项目里有几个关键细节AI的初版代码几乎处理不好。第一个细节是轨迹点的时间插值。GPS设备的上报频率通常是10到30秒一条两个点之间车辆的实际路径是一条弧线而不是直线。如果直接把相邻两个点连起来轨迹回放会显得非常机械转弯处甚至会出现“切路”的违和感。合理做法是在两个上报点之间做插值基于道路网络匹配的算法把轨迹点“吸附”到路网上。这个逻辑一般需要调用地图服务的道路匹配接口AI不会主动帮你做。第二个细节是聚合展示。当大屏上同时展示几千辆车的时候逐个渲染标记点肯定卡死。需要做空间聚合当地图缩放级别较低时把临近的车辆聚合成一个带数字的圆点放大地图之后才分散渲染。高德地图和Mapbox都有聚合图层的能力但需要你自己在代码里配置聚合半径和样式。第三个细节是车辆状态的主动推送。真实项目里车辆的实时位置不能用前端定时轮询来做一是接口压力大二是数据延迟高。正确方式是用WebSocket或者Meteor的DDP协议建立一个长连接服务端把GPS数据推送到前端前端做增量更新。AI生成的默认情况往往是setInterval轮询这在演示环境里没问题一上生产就露馅。3.2 数据大屏与指标联动布局、刷新、钻取大屏页面的指标卡片看起来简单但在真实业务里有三个容易翻车的细节。刷新机制。不同指标的更新频率不一样交通运行指数可能5分钟刷新一次实时路况2分钟刷新一次告警事件实时推送。如果全部用同一个定时器管理要么数据时效性不够要么接口被频繁请求。推荐做法是给每个指标组件独立的刷新策略用组合式API封装一个useRefresh hook组件挂载时启动定时器卸载时清理避免内存泄漏。钻取路径。驾驶舱不是只看宏观数据管理者点击某个区域之后要能下钻到区级、路段的明细。比如“XX区拥堵指数”这个卡片点击之后地图视野移动到该区域周边弹出该区排名前三的拥堵路段再点击路段弹出路段的流速、流量、排队长度。这条钻取链路的数据接口、弹窗层级需要在设计阶段就定义清楚AI生成单个弹窗容易生成一整套钻取逻辑经常会出现路径断裂需要我们手动补齐。自适应布局。LED大屏和电脑显示器的分辨率效果完全不同。有的项目用16:9的标准分辨率部署有的项目用的是异形屏甚至拼接屏。写大屏代码时不能写死像素尺寸要基于vw/vh单位做适配关键字体大小和卡片尺寸用rem或vmin做缩放。这块最好在AI生成的初始代码里就把它调整好后面再改布局成本很高。3.3 告警与工单联动从“看到”到“处置”驾驶舱如果只做信息展示价值会大打折扣。真正让甲方掏钱的是“看到问题之后能处置问题”。所以交通驾驶舱一般会带上告警和工单的联动功能这也是AI生成代码时最薄弱的环节之一。这个模块的数据流是前端收到告警事件大屏弹出提醒值班员点击确认系统自动创建工单工单推送到处置人员手机端处置完成后回传结果大屏上的告警状态从“待处置”变为“已完成”。用AI生成这部分代码我建议把重点放在工单状态机的定义上。先定义枚举类型待确认、待派发、处置中、已办结、已关闭。再定义状态流转事件确认、派发、接单、上传结果、归档。AI可以帮你生成状态流转的基础逻辑但各种边界情况需要人工把控比如超时未确认的自动提醒、同一位置重复告警的合并、处置超时后的升级策略。这些业务规则不写清楚告警工单就是摆设上线的第一天就会被一线人员骂翻。4. 源码私有化导出把代码从平台里完整拿回家4.1 导出前要检查的五件事源码私有化导出是整个流程里最容易被低估的一步。很多人以为在AI平台点一个“导出项目”按钮下载一个压缩包就完事了。实际上导出之后还需要在本地完整跑起来这时候问题才会集中爆发。我在导出之前会逐项检查五件事第一依赖清单是否完整。解压工程之后先看package.json里的依赖项。有的AI平台会把依赖写成一个超大集合什么包都往里塞导致项目体积虚胖、安装极慢也有平台漏写依赖导致本地安装直接报错。建议对照代码里的import语句逐一核对。第二环境变量和配置文件是否抽离。真实的驾驶舱项目接口地址、地图token、密钥这些肯定不能硬编码在源码里。导出之前就要要求AI把配置项抽到.env文件或者config目录里。第三有没有平台私有SDK的依赖。这是最危险的检查项。如果导出的代码里有类似于xxx-platform/sdk的依赖而且这个SDK只能在平台上跑那你的私有化就名存实亡了。检查方法是全局搜一下依赖名有没有平台相关的字样。第四构建脚本是否可用。导出之后要在本地执行npm run build看生产构建能否通过。有些AI平台导出的是预览版代码只保证npm run dev能跑build阶段各种类型错误、样式引用缺失就全暴露出来了。第五Mock数据和真实数据的切换路径是否清晰。开发阶段用Mock数据没问题但私有化之后要能快速切到真实接口。检查代码里是否对API BaseURL做了统一管理不要有散落各处的axios.create。4.2 导出的工程结构与依赖清单一次相对理想的AI导出工程结构应该长这样traffic-command-center/ ├── public/ │ ├── favicon.ico │ └── mock/ │ ├── traffic-index.json │ ├── vehicle-list.json │ └── alarm-events.json ├── src/ │ ├── api/ │ │ ├── http.ts │ │ ├── traffic.ts │ │ └── alarm.ts │ ├── assets/ │ │ ├── styles/ │ │ │ ├── theme.scss │ │ │ └── reset.scss │ │ └── images/ │ ├── components/ │ │ ├── dashboard/ │ │ ├── map/ │ │ └── charts/ │ ├── composables/ │ │ ├── useRefresh.ts │ │ └── useWebSocket.ts │ ├── layouts/ │ │ └── DashboardLayout.vue │ ├── router/ │ │ └── index.ts │ ├── stores/ │ │ ├── traffic.ts │ │ ├── vehicle.ts │ │ └── alarm.ts │ ├── types/ │ │ ├── traffic.ts │ │ └── vehicle.ts │ ├── utils/ │ │ ├── format.ts │ │ └── map.ts │ ├── App.vue │ └── main.ts ├── .env.development ├── .env.production ├── package.json ├── tsconfig.json └── vite.config.ts依赖清单关注这几个核心包就行vue、vue-router、pinia、echarts、amap/amap-jsapi-loader或mapbox-gl、axios、dayjs、lodash-es、sass。其他的像element-plus按需引入的插件、vite的插件按项目需要加。选Vite做构建工具是必然选择Webpack配置繁琐编译速度慢AI对Vite的配置模式掌握得也足够好。如果AI导出的是Webpack工程我一般会直接改成Vite省下来的时间会在后面持续回报。4.3 私有化的关键动作配置外部化、接口代理、构建产物拿到源码在本地跑通只是第一步真正的私有化要解决三个问题环境切换、接口对接、部署交付。配置外部化的意思是所有环境相关的配置都要放到.env文件里。开发环境、测试环境、生产环境各一套编译时按环境变量注入。特别是地图的token和Key一定不要提交到代码仓库或者打到前端包里面。比较好的做法是通过后端的配置中心下发给前端或者放在部署平台的nginx配置里做注入。接口代理要做两层。开发环境用Vite的proxy把/api前缀的请求代理到后端服务解决本地开发时的跨域问题。生产环境由nginx做反向代理前端只请求同源的/api路径nginx再把请求转发到真实的数据服务地址。这样前端的代码里不会出现任何内网IP或者域名安全性和可迁移性都有保障。构建产物要经过处理再交付。执行npm run build之后dist目录里就是纯静态文件可以部署在任何Web服务器上。但直接扔dist文件夹给客户太业余了需要把部署说明文档写清楚nginx配置模板、环境变量说明、系统端口要求、浏览器的兼容性要求。这个部署说明可以要求AI帮写初稿但最终要人工核对AI经常想当然地写一些不存在的配置项。5. 本地复现与真实改造从“演示稿”变成“生产项目”5.1 在本地把项目跑起来的完整步骤拿到导出源码之后第一次在本地跑起来大概率不会一帆风顺下面是我每次都会走的流程第一步解压工程删除无关文件。很多AI平台会生成一些模板说明文件、占位图片、示例组件先用不上删掉能减少干扰。第二步安装依赖。推荐用npm ci而不是npm install前者按照package-lock.json精确安装版本避免依赖漂移。如果安装过程中报node-sass这类的兼容性错误先不用急着折腾版本先试着换用sass的dart-sass版本一般能解决。第三步检查工具链。确认本地的Node版本不低于项目要求的版本。Vite 5要求的Node版本是18如果本地是16或者更老直接升级Node环境再回来。第四步启动配置检查。复制.env.development.example为.env.development把地图Key和接口地址填进去。很多AI平台导出代码里不知道为什么没有env文件只有env.example不复制的话项目启动会报“缺少环境变量”的错误。第五步启动开发服务器。npm run dev起来之后用浏览器打开页面先打开控制台看有没有红色报错。常见的有地图加载失败Key问题、接口404代理没配好、变量未定义代码里有坑。第六步验证核心功能。页面出来之后按顺序过一遍核心链路地图加载是否正常、图表是否渲染、点击交互是否有响应、Mock数据是否展示、刷新定时器是否工作。这里不要走马观花要认认真真把每个按钮点一遍。第七步跑生产构建。npm run build构建通过之后用本地静态服务器预览dist产物确认生产包能正常出图。5.2 把Mock数据换成真实交通数据源这一步是整个流程里最关键的一个坎也是AI帮不上太多忙的地方。Mock数据和真实数据之间差的不是接口地址而是数据形态的不确定性。先说一个最常见的坑。Mock数据里面字段类型是写死的比如speed字段是number类型真实接口在异常情况下可能返回null或者字符串“--”AI生成的图表组件遇到这种情况会直接渲染错乱。所以换真实数据源的时候第一步是写数据清洗和兜底逻辑保证每个字段拿到的一定是正确的类型拿不到就给默认值。第二个坑是鉴权。真实接口通常不是裸奔的需要带token。有的用JWT放在请求头里有的用cookie做会话维持。在前端的request封装里统一处理鉴权另外要考虑token过期之后的刷新机制。AI生成的代码往往直接写死一个假token这一步必须人工改。第三个坑是分页和全量数据的差异。Mock数据的车辆列表可能只有几十条真实数据可能是上万条。之前提过的聚合图层、虚拟滚动、按区域预加载这些优化就要在这里上了。第四个坑是接口的实时推送。如果驾驶舱里的车速、路况、告警采用WebSocket推送这里还需要额外处理断线重连、数据去重、消息积压的情况。真实项目里网络环境复杂弱网场景下Wi-Fi切换、SignalR连接中断很常见前端必须有自动重连机制否则大屏会越看越假。5.3 性能优化和浏览器兼容排查驾驶舱的性能问题集中在三块首屏加载、地图渲染、大屏长时间运行的稳定性。首屏加载的优化手段有几个路由组件改成懒加载ECharts和地图这类体积大的库拆成独立chunk静态资源上CDN。驾驶舱首屏如果5秒还没出来甲方体验会非常差。我一般用构建工具的代码分割能力把地图SDK和ECharts单独拆包首页优先加载布局框架和关键指标次要组件放到用户交互时再加载。地图渲染的性能主要靠聚合、图层隔离、标记点密度控制。之前提到的聚合图层要加上不同类型的数据用不同的图层管理方便开关显隐同一个位置的多个信息窗口要合并避免页面卡顿。长时间运行的稳定性是驾驶舱项目最容易忽略的。大屏设备可能一周7天、一天24小时挂在那里运行三天之后的内存泄漏、WebSocket断线不重连、定时器越积越多都是真真实实会发生的问题。排查方式很简单打开DevTools的Performance Monitor看内存变化曲线是否持续上升、GPU占用是否异常、网络请求是否有堆积。把这些检查项在项目交付前做一遍能避免上线之后的无数个深夜告警电话。6. 实测复盘AI生成代码的效率、风险与边界6.1 效率账省了多少时间多花了多少时间我用一个实际的驾驶舱项目来算一笔账。假设需求已经确定了页面结构、数据指标、交互链路都有了原型图按传统的开发方式搭建项目骨架、配置路由状态管理、封装请求库大约1到1.5天写大屏布局和样式大约1天地图组件和车辆标记大约1.5天图表组件与数据联动大约1到1.5天告警面板和工单流程大约2天联调真实接口、性能优化、Bug修复大约3天总计大概需要10到11个工作日。用AI生成代码的方式我的实际时间花费是写详细的提示词、反复调优半天审查AI生成的代码、修正明显错误半天数据源替换、接口联调2天性能优化和兼容性修复2天私有化部署配置、文档半天总计大概5到6天。效率提升是肉眼可见的尤其是前端样式和布局这部分AI在几分钟之内就能输出人工需要画一上午的代码而且布局的美观程度相当在线。但省下来的时间并不是白送的代价是你要有足够的能力去做代码审查和架构把控。AI生成的代码就像一份写得很好的草稿它的思路清晰、风格统一但你不能指望它替你思考业务边界。6.2 AI代码常见问题清单与解决策略实测下来AI生成代码的问题集中在几个固定类型上我把它们整理成一份速查表问题类型具体表现解决策略依赖冗余package.json里塞了很多无关包裁剪依赖保留实际用到的包减小体积类型定义缺失TypeScript任何地方都用了any建立types目录逐模块补充类型定义硬编码配置接口地址、token写死在业务代码里全局搜索字符串常量统一迁移到env配置内存泄漏定时器、事件监听器没清理逐组件检查onUnmounted钩子清理副作用组件设计过重一个组件塞了几百行难维护按功能拆成子组件用props和emit通信样式全局污染写了一大堆全局样式互相覆盖组件内使用scoped样式公共样式抽到统一目录Mock数据和真实数据混用组件里既调接口又有静态数组兜底统一走API层Mock只在纯开发环境生效解决这些问题的核心策略是把AI当成“初稿工程师”来管理。初稿可以快但review必须认真。我在团队里定的规矩是AI生成的每一行代码都必须经过人工review才能合入主干分支除非是docs目录下的说明文档。6.3 什么时候该用AI什么时候别硬用我自己有一个很清晰的边界交互链路越短、技术栈越主流、业务逻辑越通用越适合用AI生成反之链路越深、定制化越强、越是核心业务逻辑越要人自己动手。适合用AI的场景包括做原型给客户看、内部工具的开发、通用管理后台的前端页面、大屏可视化初版。这些场景的共同特点是需求变化快、返工概率高、代码价值密度低用AI把初版生成出来人做调整效率是最高的。不适合用AI的场景包括涉及核心算法的模块、资金交易类系统、需要高度定制化交互的复杂驾驶舱、对代码质量有严格审计要求的重点工程。不是说AI在这些场景里一定不行而是它出错之后的代价太大不值得用效率去赌。还有一点很关键AI会放大需求理解的偏差。如果你的需求描述本身就模糊AI生成的代码也会模糊而且它的“模糊”会以一种看起来很像样的方式呈现反而容易掩盖问题。所以需求分析这个环节永远是主力AI只是把已经想明白的需求快速落成界面它不能帮你想明白怎么定义“拥堵”、怎么界定“事件等级”。最后分享一个小经验这阵子跑完整个流程我最深的感受是AI生成代码最大的价值不是让程序员失业而是把“从空白页开始写代码”这件事变成了“在AI给你的初稿上做架构评审和改造”。智慧交通驾驶舱这类项目界面和交互部分高度标准化AI输出这些内容非常擅长。但代码拿到手之后能不能变成真正可靠的生产系统还是取决于你自己对架构、数据流、业务规则的理解。如果你正准备用AI做驾驶舱或类似的可视化大屏项目我的建议是先花一个下午把需求彻底想清楚把页面结构、数据指标、交互方式写成文档再打开AI工具让代码帮你把界面搭出来。同时拿到源码之后第一时间在本地完整跑通把能不能私有化部署这件事放在选型阶段就验证掉。项目做到一半再想换工具、换方案那才是真正的折腾。代码谁写的不是最要紧的要紧的是它得能在你的服务器上稳稳当当地跑起来。