ARTICLE · 1252274
从技术文档到全模块大屏:我做演示件的三步工作法
这套城市生命线大屏，我前后做了三版，现在还在往上加东西。
先看它现在长什么样。
城市生命线安全监测预警平台：AI 实景城市底图打底，楼群、河道、监测点位全代码叠加，单文件 HTML
第一版照技术文档做，做完自己看着都觉得平；第二版靠一轮轮返工，把问题磨掉一半；第三步找来 6 个真实项目的视频对标，才敢说"拿得出手"。
如果你也遇到过这种场面——领导看了别家的智慧平台眼热，回头跟你说"咱也整一个"；或者乙方演示时满屏炫酷，你问一句"这数是哪来的"，场面就冷了——这篇就是给你写的。
看完你能带走三样东西：怎么判断一个演示平台是不是糊弄的；自己要做的话，钱和时间该花在哪；下次乙方汇报，你该问哪几个问题。
三步的产出各不相同：骨架、问题清单、标准（示意图）
第一步：技术文档能给你什么
第一版是照技术文档写的：功能清单、接口定义、指标口径，全在纸上。Three.js + ECharts，单文件 HTML，写完 5800 多行。
跑起来第一眼就发现问题：功能是齐的，但页面是平的。
后来想明白了，技术文档只回答"有什么"，不回答三个更值钱的问题：
演示给谁看，他第一眼看哪里？ 十几个模块，哪几个是记忆点，哪些是陪衬？ 每个模块的数据，做到什么精度才立得住？
文档能给你骨架，给不了你节奏。
这条你记下就行：乙方拿着一纸功能清单说"都做完了"，先别急着验收——清单齐，不等于演得出。
第二步：迭代长出来的问题清单
接下来是常规操作：跑一轮，改一轮。修数据、调布局、砍模块，活不体面。
但真正值钱的是把每轮发现的问题记成清单。几类典型的：
数据打架。顶部指标一个数，点进明细页另一个数；告警弹窗弹了 5 条，列表里只有 4 条。观众未必去核对数据库，但两个页面的数字对不上，一眼就能看出来。
模块有壳没芯。管线超期服役分析，最初就是一张静态表格。后来改成按管材、年限真实核算，超期的红色高亮——同样的模块，业务逻辑立住了，别人才会当真。
演示没有主线。十几个模块平均用力，领导扫一眼没记忆点。后来定死规矩：一场演示只要 3 个记忆点，其余全部降级成陪衬。
迭代到这里能解决"对不对"，解决不了"好不好"——标准不在我的经验里，在别人的成熟产品里。
第三步：拿真实项目视频对标
第三步，我找来 6 个做成了的真实项目视频——都是同行交付上线、正在跑的平台。哪家的不说，这篇只讲东西。
对标不是抄界面。每个视频我回答同样三个问题：这个模块为什么放在这个位置？它在演示里起了什么作用？换成我的，数据从哪来？
6 个视频拆完，提炼出 13 个可复用模块，按演示价值分三档：
拆完有个结论：这些平台 80% 的骨架是共用的——顶部指标、专题面板、地图布点、预警流、处置闭环。区别只是每个行业往骨架里填的肉不一样。
3D 城市加载 3 秒就消失：一个很阴的坑
有天彩排演示，我发现一个怪事：3D 城市总在加载 3 秒后自己降级成 2D 地图，好端端的三维画面说没就没。
排查发现是个很阴的逻辑：页面里有个"黑屏检测"，加载 3 秒后去读画面中央那个像素，接近全黑就认定"3D 没渲染出来"，自动降级。
问题是这套大屏本来就是深夜色调——它渲染得越好，中心那个像素越黑，越容易被自己误杀。
修法也就几行：
// 原来：读画面中心像素，太黑就降级 —— 深夜色调大屏被自己误杀// 现在：容器里真有 WebGL 画布就是活的，连画布都没有才降级const alive = [...el.querySelectorAll('canvas')] .some(c => { try { return !!c.getContext('webgl'); } catch(e) { returnfalse; } });if (!alive) fallback2D(); // 只有渲染压根没启动，才走这条第一行还是老老实实找画布，第二行换个判断标准：不看颜色，看"渲染器活没活"。
这事我记进了问题清单，也变成一条验收经验：乙方给你演示 3D，让他当场刷新三次。有"自动降级"逻辑的平台，最容易把最好看的东西悄悄降没掉。
全部装进母版
13 个模块挨个装进大屏，说几个值得看的：
AI 问数：点一个问题，它用"数据 + 研判 + 建议"的结构回答。演示时这是全场最容易让人点头的地方。
AI 问数：点预置问题，结构化分析带打字机效果
管线孪生：地下综合管廊剖开看，燃气、供水、电力、通信分色排布，点构件出详情。
三维态势：管线孪生模式，地下管廊分色呈现
救援路线推演：红圈脉冲扩散、绿色路线流动、救援车沿线动。视频素材首选，太抓眼。
完整操作实录，从点位详情到管线孪生：
实录：AI 实景底图 → 点位实时读数 → 管线孪生（加速）
数据是模拟的，但"编"得有规矩
说个容易被问的事：这套大屏的数据全是前端模拟的，没有接真系统。这不心虚吗？
我的做法是：数据可以编，编要有规矩。所有数据内部自洽——管材按真实年限标准核算、告警弹窗数和列表条数一致、顶部指标和明细页对得上。
观众不会去验证你的数据库，但任何人扫一眼都能看出"这数字打不打架"。演示件被打脸，从来不是因为数据是假的，是因为两个页面的数字对不上。
这也是你验收时最省事的检查法：让乙方当场把汇总页的数和明细页对一遍。对不上的，其他地方大概率也糊弄。
想自己整一个？照这三步抄
前三步是我的路子，你要动手，其实可以更省——把需求直接讲给 AI 工具（Cursor、Claude、通义都行），照着这个骨架说：
帮我做一个城市生命线安全监测大屏演示件。单文件 HTML，Three.js + ECharts，暗色指挥大屏风格，数据前端模拟。模块：顶部核心指标、分行业风险列表、地图布点告警流、处置闭环时间线、专题面板（燃气 / 供水 / 管线各一个）。数据要内部自洽：告警弹窗条数 = 列表条数，汇总页数字 = 明细页合计。每轮改完我截图验收。三步走：
1. 用上面的骨架把需求一次说清。模块清单、数据自洽的规矩，全部写进第一句话——说清一次，省三轮返工。
2. 每轮只盯一件事验收。跑起来截图，先查"数字打不打架"，再查"点哪哪响"，最后才看好看不好看。
3. 拿成熟产品对标补标准。你拆不动 6 个项目视频，拆 1 个也行：问它"这个模块为什么放这、数据从哪来"。
演示件到这一步就够了。但演示件和能用的系统是两回事——接真数据、通真设备、常年有人维护，那是另一个价位的活。跟乙方谈之前先把这两件事分开，"便宜做个大屏"的话术就套不住你。
技术底细顺一下
单文件 HTML，没有框架，Three.js + ECharts，6100 行左右，数据纯前端模拟。
有人会问为什么不用 React/Vue。我的答案很实际：这是演示件，不是交付件。演示件的生死是"打开就动、点哪哪响、拷到谁电脑上都能跑"——单文件双击就能开，客户现场断网都不怕。
你不用懂代码。下次乙方给你演示，问三个问题就够了：数据是接了真系统还是模拟的？两个页面的数字能对上吗？拷到我电脑上、断了网，还能跑吗？三个都过硬，这活儿就是认真的。
复盘：这种事我的做法
三版走下来，能沉淀成方法的就是四条：
1. 文档定骨架，对标定标准。两样都齐了再动手，比闷头返工快得多。
2. 每轮迭代必须有产出物。不是"改好了"三个字，是问题清单加一条。
3. 模块为复用而写。第一版按功能堆代码，第三版按"下次能不能直接搬"来划——这个意识变化比任何技术选型都重要。
4. 演示件和交付件分开评判。拿交付件的标准苛求演示件是浪费时间，反过来是事故。
别人的项目是案例，拆完才是你的能力。
下一篇写我怎么把这套母版改成污水厂大屏的——里面有个非常阴的坑：页面一半空白，控制台还不报错，排查过程挺有意思。
