从脚本到应用：一个真实的 web 服务
用商业空间规划器把状态、约束与用户反馈连成一条线
学习证据 学完后，怎么核对？
把学习结果留在一个可以回看、可以复做的动作里；这一区只写学生能自己检查的证据。
如何核对
- 完成一套空间需求单与验收清单
- 在 3D/2D 双视图中验证安全区与尺寸
适用边界
本课用原生离线渲染模拟服务边界，不代表真实后端、多人协作、WebXR 权限或生产级性能。
最后复核
这是内容复核日期，不是学习截止日期。
讲
例子先把“好看”改写成可验收的服务契约
一家临时展店要在 8 m × 6 m 的场地里放置咨询台、样品墙和无障碍通道。甲方说“希望有沉浸感”，工程团队不能直接把这句话翻译成一套闪亮的 3D 模型；要先问：谁在什么设备上操作，哪些尺寸不可违反，什么反馈算通过，哪些事情本版本明确不做。
名词需求单不是愿望清单
把角色、任务、输入、约束、验收证据和非目标写成同一张表。例如“访客能从入口到咨询台”是任务；“主通道净宽 ≥ 1.2 m、转身区直径 ≥ 1.5 m”是可测约束；“自动算报价、多人实时协作”是本地演示的非目标。
定义状态是唯一事实来源
layout、material、light、view、zoom- 物件的
x/y/w/d/h与安全膨胀区 - 派生值：碰撞数、最小净宽、验收结果
定义验收之后仍有部署边界
本地演示只证明一组输入能在当前浏览器重绘并留下可读日志；测试环境还要固定构建版本、浏览器矩阵、错误恢复和性能预算；生产服务则要补上 HTTPS、身份与权限、数据保留、监控告警、回滚和真实用户／现场验收。把三层证据分开写，才不会把“能展示”冒充“已部署”。
泛化把“按钮能点”与“服务完成任务”分开：状态模型保证同一输入能得到同一结果；渲染层只是状态的一个视图；验收层用规则和日志说明结果为何通过或失败。这样做也保留了博雅教育关心的公共问题——谁被空间排除、谁能读懂反馈、哪些假设被藏起来。
| 技术 | 适合做什么 | 不要冒充什么 |
|---|---|---|
| 3D 模型／几何 | 表达物件尺寸、相对位置和空间关系；便于和客户讨论方案。 | 不是建筑施工图、结构安全证明或真实材质的测量。 |
| WebGL／Canvas | WebGL 是浏览器图形接口，Canvas 可在本地即时绘制、控制帧率和交互；Canvas 2D 投影也能清楚展示几何规则。 | 不是自动获得后端、认证、持久化、监控或跨设备性能。 |
| PBR（基于物理的渲染）材质 | 在光照参数明确时，让粗糙度、金属度等视觉线索更稳定。 | 不是“真实颜色”或无障碍证据；还要检查对比度和色觉差异。 |
| WebXR／摄像头 | 在明确设备、权限、空间追踪和安全流程后做 AR／VR 试验。 | 本课不申请权限；不能把有权限的沉浸体验当成默认生产能力。 |
核心句：从需求到应用的关键不是多一个维度，而是让状态、约束、反馈和验收证据彼此对得上；离线演示可以说明流程，却不等于已经部署的 web 服务。
例
先看两个可以复用的做法，再看一个容易把“视觉完成”误认成“服务完成”的例子。
客户在“岛台”“靠墙”“双展台”之间切换时，代码只改 state.layout，再由同一组物件数据重绘 Canvas 和平面图。验收器随后重新计算安全膨胀区。这样，平面图不会因为另写一套逻辑而落后于 3D 视图；用户也能看到“为什么通过／为什么失败”。
把主通道净宽设为 1.2 m、转身区设为 1.5 m，并在 2D 图中用虚线安全区表示。某布局即使看起来平衡，只要安全区与物件相交，就反馈“未通过：入口转身空间不足”。规则不是替代现场勘查，而是让讨论先有共同的可测语言。
演示在开发者电脑上顺畅旋转，团队便写下“服务已完成”。错在把显示当成部署：没有说明浏览器支持、加载预算、键盘路径、错误恢复、日志留存、权限与隐私，也没有真实用户验收。修法是把动画降级为可选视图，保留可读 2D／文本后路，并在验收清单里分别记录原型证据和生产待办。
静态后路 · 一眼读懂尺寸与安全区
商业空间规划器 · 状态、约束与验收
观察 → 操作 → 复盘：旋转／缩放 Canvas 3D 展台，切换布局、材质、灯光与视角；2D 平面图、安全区、尺寸读数和模拟验收日志同步更新。
互动版需要运行脚本（本地 HTTP 预览）；不运行脚本时，上面的静态例子已包含同样的内容。
做
客户要求“入口到咨询台的净宽至少 1.2 m”。哪一项最像可验收的实现？
- 需求单：写清用户角色、场地尺寸、至少三个任务、至少两个硬约束（含单位）、一个无障碍目标、非目标、设备／浏览器假设与风险。
- 状态模型：画出
layout / material / light / view / objects / constraints，标记哪些是输入，哪些是派生值；给每个字段一个有效范围。 - 验收清单：至少列 6 条可复做检查：3D 与 2D 是否同步、入口净宽、转身区、尺寸标签、键盘路径、窄屏布局、reduced-motion、脚本关闭后的文字后路。每条写“步骤—预期—证据”。
- 复盘边界：从模拟日志挑一条“未通过”，说明是状态、渲染还是需求假设导致；再写一条生产待办（性能、权限、部署、监控或真实用户测试）。
怎么算过关：同学只看需求单和验收清单，能复现一次通过与一次失败；你能指出本地演示没有覆盖的后端、权限和真实场地风险。3D 视觉效果不计作单独证据。
卡
为什么“能旋转的 3D 页面”还不能叫真实 web 服务？
真实服务还要有明确需求和非目标、可复做的状态模型、可访问的反馈、约束验收、错误恢复、性能／权限／数据与部署边界。3D、WebGL、PBR、WebXR 只是可能的呈现或交互技术，不能替代这些证据。
- 需求 → 状态 → 渲染 → 反馈 → 验收是一条可追踪链；两种视图应共享同一状态。
- 安全区、尺寸和无障碍目标要有单位、规则与失败反馈，不能只靠“看起来”。
- 原生 Canvas／WebGL 可做离线原型；生产部署还需性能预算、权限、数据保护、监控和真实用户测试。