8.3 出货检验：项目流程与实战复盘

8.3 出货检验：项目流程与实战复盘

本节摘要：把全册工序放进一场真实交付走完最后一遍：需求拆解到工位、里程碑按产线逻辑排、三类常见订单的装配差异各自讲清，最后是上线监控与售后迭代。这一节是全册的收束，也是把"教程经验"变成"接单能力"的转换器。

沙盘交付全记录

把贯穿全册的仓储沙盘按真实时间线复盘一遍，每道工序的工时占比与返工点一目了然。

背景：客户是物流设备商，需求是官网上的"智能仓储展示页"：可旋转查看、点选设备看参数、夜间模式、移动端可开。合同期三周。

操作与结果：第一周完成主体装配——工位搭建半天、三件套与货箱阵列一天、布光与阴影两天、材质纹理三天，产出静态验收版；这一周唯一返工是阴影相机的范围标定（2.3 的老坑），损失半天。第二周完成功能装配——机位手感一天、模型进场两天、动画与拾取两天，中间因设计部改模型返工一次（5.1 的格式条款没写进交接单，教训入库）。第三周精装修与质检——流光与泛光两天、性能体检一天半、移动端降级一天、上线监控半天，提前一天交付。

解读：复盘最能说明问题的是两个返工点的性质——都不是"技术不会"，而是"工序纪律没守住"：阴影范围是标定流程跳步，格式条款是沟通清单缺项。装配线方法论的价值正在于此：把技术问题前置成纪律问题，纪律问题可以写进清单，清单可以复用。三周工时的结构也符合行业惯例：主体装配约四成、功能与交互约三成、精装修加质检约三成——精装修永远比客户以为的贵，报价时就该讲清。

三类订单，三套权重

同一套工序，不同订单的装配权重差别极大，接单前先对号：

产品展示页用户会"细看"，材质与运镜的投入回报最高；数据大屏常年挂墙，按需渲染与实例化决定它一个月后还活着没有；宣传页的第一屏就是生死线——加载看板（5.2）与降级预案（8.1）不是加分项是入场券。这张表来自上一段的实战复盘，接新单时先填一行再排产。

动手：上线监控的最小配置

背景：沙盘上线三天，客服收到两条"有人那儿会卡"的反馈，信息量仅此而已。要求：用最小成本弄清"谁在卡、卡在哪"。

操作：性能采样上报加错误兜底，十几行代码回答两个问题。

// 上报采样：每 10 秒一次，只取会话内的代表值
setInterval(() => {
  const sample = {
    fps: recentFps,                          // 最近窗口帧率
    calls: stage.renderer.info.render.calls,
    dpr: window.devicePixelRatio,            // 设备像素分布
    mem: performance.memory
      ? Math.round(performance.memory.usedJSHeapSize / 1048576)
      : -1                                   // 仅 Chromium 有效，其余设备报 -1
  };
  navigator.sendBeacon('/telemetry', JSON.stringify(sample)); // 离页也不丢
}, 10000);

// 程序化错误兜底：渲染上下文丢失是 Web 端 3D 的头号恶性事故
stage.renderer.domElement.addEventListener('webglcontextlost', (e) => {
  e.preventDefault();                        // 阻止默认，保留恢复机会
  reportContextLost();                       // 上报设备与场景规模
  showReloadTip();                           // 用户侧：提示刷新
});
​

结果：一周后报表说话——"卡"的会话集中在像素比 3 的旧款高端手机上，calls 全部正常。把这类设备单独封顶像素比 1.5 并关阴影，差评消失。

解读：这段监控是 8.1 的延伸，也是"售后迭代"的起点：性能优化在上线后才有真实数据，上线前的"优化"一半是猜。两个技术点补充：sendBeacon 在页面关闭时也能把样本送出去，比普通请求可靠；webglcontextlost 是移动端发热、后台回收引发的显存吊销事件，preventDefault 加提示刷新是标准处置——别试图原地恢复，场景重建成本通常低于恢复成本。售后的另一半是内容迭代：模型换季、参数调优，都因为第 5 章的"外协件标准件化"而变成替换文件级别的小手术——装配线的收益，最终都兑现成运维成本。

变式：团队化之后，这套流程可以沉淀成三份模板：需求拆解表（需求到工位的映射）、交接清单（与设计部的格式条款）、验收仪表盘（8.1 的五项读数阈值）。三份模板齐备，下一单的启动时间通常能省三分之一——这也是"装配线"这个词在工程组织层面的意义。

需求拆解到工位的实操演示

"需求拆解到工位"值得单独走一遍，因为它是接单的第一小时里做的事。以沙盘订单为例，客户原话是"要一个能点的智能仓储展示"。拆解动作是三步：第一步把形容词翻译成工位——"能点"是拾取交互加信息卡（6.3），"智能仓储"是货箱阵列加数据驱动（1.3 的变式），"展示"是自动巡展加特写运镜（4.2）；第二步标出未覆盖项——客户没提加载体验与低配设备，但官网场景必有手机访客，把 5.2 的进场看板与 8.1 的降级预案主动写进方案；第三步给每个工位标风险等级——阴影标定、模型格式条款这类历史返工点提前列明。拆解完成的标志是报价单上每个数字都能对应到一个工位与一个工时估计，客户追问任何一项你都答得出依据。这套演示的本质是把"会写 Three.js"翻译成"会接 Three.js 的单"，翻译不过去，前七章的技术积累就只能在自娱项目里循环。

本节要点回顾

• 工时结构有惯例：主体四成、功能三成、精装修与质检三成，报价前先讲清；
• 返工源于纪律缺口：技术问题前置成清单项，清单可复用可交接；
• 订单决定权重：展示重材质运镜、大屏重调用控制、宣传重首屏与降级；
• 监控回答两个问题：谁在卡、卡在哪，sendBeacon 采样加丢上下文兜底；
• 标准件化的终局红利：换模、调参、迭代都是替换文件级的小手术。

产线到此正式出货。回望全册：一张白页起手，八个工段接力，每个案例你都亲手装过一遍——Three.js 的进阶之路（GPU 粒子、延迟渲染、WebGPU）已在前文各节的变式里埋好路标，剩下的路，你已是装配线上能独立带单的人。