一扇窗，和它的无限想象

# 《一扇窗》项目文档 ## 一、项目概述 **项目名称：** 一扇窗 **项目类型：** 软硬件互动体验 / 数字艺术互动产品 **开发形式：** 个人独立完成 《一扇窗》是一件尝试重新建立人与自然连接的软硬件互动作品。 它面向那些长时间生活在办公室、宿舍、出租屋等有限室内空间中的人。当真实的窗户被遮挡、视野被压缩，或者人没有条件真正走进自然时，希望通过一块屏幕、一点灯光和一个简单的实体交互，为用户留下一个可以短暂停留、向外观看的空间。 它不是天气 App，也不是一个单纯展示传感器能力的硬件 Demo。 我更希望它像一件可以放在身边的小型互动作品： **打开一扇窗，看见自然，也看见未知、好奇和仍然存在的无限可能。** --- # 二、项目背景 这个项目来自我过去上班时非常具体的一些感受。 有一次，我坐在办公室里看到外面正在下雨，突然产生了一个很强烈的念头： **我好想当一只雨燕。** 不是因为真的想变成一只鸟，而是在那一刻，非常想离开眼前封闭的空间，到雨里、风里、天空里去。 办公室的窗户其实离我并不远，但为了避免阳光太晒或者室内升温，大家经常会把遮光帘拉下来。 即使遮光帘没有完全挡住窗户，前面也排列着大家的电脑屏幕。 于是很多时候，我只能从： **遮光帘之间、电脑屏幕之间非常狭窄而不规则的缝隙里，向外看天空。** 有时候那块天空很小。 甚至小到让我并不知道今天外面究竟是蓝天白云，还是阴天。 我看到的只是： **一小块不规则的天空。** 但就是这样的一小块天空，有时候也足以让我从工作状态里短暂地抽离出来。 这让我开始想： 如果现实里的窗户无法真正属于我们，那有没有可能人为地给自己留下一扇窗？ 于是有了《一扇窗》。 它并不是要复制一块真实的窗户，而是尝试保留“窗”最重要的意义： **它让人知道，眼前的空间并不是世界的全部。** --- # 三、目标用户 项目主要面向： **长时间处于室内、办公室、宿舍、出租屋等有限空间中，希望获得片刻自然感和情绪喘息的人。** 他们可能并不真的缺少一块显示器，也不一定需要一个新的效率工具。 他们缺少的可能只是一个很小的机会： 停下来，看一会儿树，看一会儿夜空，听几声鸟鸣，暂时不用完成任何任务。 因此《一扇窗》并不强调效率、信息密度或者功能数量，而更关注一种微小但完整的体验。 --- # 四、核心概念 项目目前包含两个世界： ### DAY / 白天 白天的主题是： **绿色、森林、生命、好奇。** 画面是一片安静的绿色自然空间。 它不是天气软件式的“蓝天白云”，也不是童话森林，而更像夏日下午从窗边看到的自然： * 绿色植物 * 树影 * 阳光穿过叶片 * 空气中的轻微变化 * 偶尔出现的流萤、光线或远处生命迹象 白天代表的是： **生命和探索。** 像是窗外还有路，还可以继续向前走。 --- ### NIGHT / 夜晚 夜晚的主题是： **蓝色、未知、空间、无限可能。** 画面进入深蓝色夜晚，灯光也转向蓝色。 夜晚不是黑暗、悲伤或者孤独。 相反，它代表一种： **因为看不清，所以不知道远处还存在什么。** 这种未知本身，也意味着可能性。 画面中有： * 深蓝色夜空 * 月亮 * 少量星点 * 夜间环境 * 柔和的蓝色光线 * 很轻的互动星光 白天和夜晚不是两个完全不同的网页，而是同一扇窗所经历的两种状态。 --- # 五、交互方式 ## 1. 实体交互 最初的方案希望通过传感器感知现实环境，再让实体灯光与网页内容一起变化。 开发过程中先后尝试了压力传感器以及光敏电阻。 压力传感器在实际调试过程中始终没有稳定跑通，因此之后改用了光敏电阻，希望通过现实环境中的光线变化控制 DAY / NIGHT。 光敏电阻曾经成功读取过环境光数据，但之后无法稳定复现。 我使用 Stack Anyway 平台进行了大量接线、参数、代码及开发板配置尝试，仍然没有恢复稳定读取。平台中的 AI 调试最终判断，当前使用的光敏元件本身可能已经损坏。 考虑到黑客松剩余时间以及作品演示的稳定性，最终 MVP 没有继续在不稳定传感器上投入时间。 **当前提交版本改为使用 ESP32-S3 开发板上的实体按钮作为 DAY / NIGHT 的物理切换入口。** 这一调整保留了作品最重要的软硬件关系： **现实中的一个实体动作 → 数字世界发生变化。** 同时避免因为单个传感器故障导致整个作品无法完成。 --- ## 2. 网页交互 网页并不是单纯的视频背景。 用户可以直接在网页中与环境发生轻微互动： ### 白天 用户的轻触、鼠标和手指移动可以带来： * 轻微视差 * 环境光变化 * 流萤粒子 * 涟漪或短暂光迹 * 非侵入式自然反馈 ### 夜晚 用户触碰夜空时，可以： * 在对应位置点亮一颗短暂的星 * 看到星光逐渐出现、消散 * 感受轻微的空间和视差变化 所有互动都刻意保持非常轻。 这个项目不希望让用户“完成任务”。 它更像是在回应： **“我知道你刚刚碰过这里。”** --- # 六、声音设计 声音是《一扇窗》体验的重要组成部分。 项目为 DAY 和 NIGHT 分别设计了环境音乐，并在两个状态之间进行平滑 crossfade。 ### DAY 白天的声音偏向： **Organic Ambient / Cinematic Ambient** 包含森林、空气、自然环境以及较轻的音乐性元素。 它并不是森林白噪音，也不是冥想音乐。 希望传达的是： **生命、绿色和对窗外世界的好奇。** ### NIGHT 夜晚逐渐进入： **Ambient Electronic / Cinematic Ambient** 声音空间变得更大、更远、更透明。 它与蓝色灯光和夜空共同表达： **未知并不意味着危险，它也意味着尚未被探索的可能性。** DAY 和 NIGHT 在音乐气质上有差异，但属于同一个世界。 --- # 七、软硬件架构 整体架构设计为： ```text 实体输入 ↓ ESP32-S3 ↓ DAY / NIGHT 状态 ├────────→ WS2812B 灯带 │ ↓ │ 实体灯光 │ └────────→ 网页 ↓ 白天 / 夜晚世界 视觉 + 动画 + 声音 ``` 当前 MVP 中，为了保证稳定演示： ```text ESP32-S3 实体按钮 ↓ DAY / NIGHT ↓ 灯光 ``` 网页端则拥有完整的 DAY / NIGHT 状态管理机制，并预留 WebSocket API 作为 ESP32 与网页之间进一步联动的接口。 因此整个架构从一开始就尽量将软硬件的耦合压缩为一个非常简单的状态： ```text DAY ``` 或： ```text NIGHT ``` 网页内部只需要根据这一状态改变整个视觉、动画和声音系统。 --- # 八、网页技术栈 整个网页采用了一套非常轻量的技术方案。 ## 核心技术栈 **纯静态 HTML + CSS + 原生 JavaScript，无框架、无构建工具、无后端。** ### HTML5 负责页面基础结构： ```text index.html ``` ### CSS3 负责绝大部分视觉表现和环境动画： ```text style.css ``` 使用的主要能力包括： * CSS Gradient * `filter: blur` * `mix-blend-mode` * `backdrop-filter` * `@keyframes` * 响应式 `@media` 其中 CSS 动画主要用于： * 树木缓慢呼吸和摆动 * 云雾漂移 * 光束明灭 * 星星闪烁 * DAY / NIGHT 环境转场 同时针对手机竖屏等不同显示环境进行了响应式处理。 --- ### Vanilla JavaScript 全部交互逻辑均由原生 JavaScript 完成： ```text script.js ``` 未引入 React、Vue 或其他前端框架。 主要使用： #### Canvas 2D API 实现流萤粒子系统，包括： * 移动 * 发光 * 拖尾 * 消散 #### Web Animations API 使用： ```javascript element.animate() ``` 处理： * 互动星星 * 点击涟漪 * 临时视觉反馈 #### Web Audio / `<audio>` 负责： * DAY / NIGHT 双音轨 * 音频播放 * 淡入淡出 * 昼夜 crossfade #### WebSocket API 项目预留 WebSocket 能力，用于之后连接 ESP32，使硬件可以向网页发送： ```text DAY ``` 和： ```text NIGHT ``` 状态。 #### Pointer / Touch Events 同时支持： * PC 鼠标 * 手机手指 * 轻触 * 上下轻扫 * 视差效果 --- # 九、音频技术 背景音频采用： **AAC 编码 `.m4a`** 原始 WAV 音频通过 macOS： ```text afconvert ``` 进行压缩。 这样能够在保持足够声音质量的情况下大幅降低网页体积。 --- # 十、为什么选择纯静态技术 网页总大小约： **1.9 MB** 一共只有约 5 个主要文件： ```text 3 个代码文件 + 2 个音频文件 ``` 项目明确没有使用： * React * Vue * 第三方前端框架 * npm * webpack * Vite * 后端 * 数据库 * API * CDN * Three.js * 外部网络请求 这个技术选择是刻意的。 因为《一扇窗》希望做到： **一份代码，两种使用方式。** ### 第一种 网页可以作为普通静态网站部署到： * Vercel * Netlify * GitHub Pages * 其他静态托管服务 用户现场扫码后，可以直接通过自己的手机进入网页独立体验。 ### 第二种 由于整个项目体积很小、没有依赖，也具备进一步塞入 ESP32 Flash、由开发板本身托管网页的可能性。 这样未来实体装置甚至可以： **自己提供网页，而不是依赖外部服务器。** 这也是整个技术架构追求低依赖的重要原因。 --- # 十一、创新点 ## 1. 从“屏幕”重新回到“窗” 现代人的生活中已经有非常多屏幕。 但《一扇窗》并不想再提供一个新的信息界面。 它尝试把屏幕重新解释为： **一扇窗。** 没有信息流，没有通知，没有任务，没有内容列表。 它只提供一个向外看的空间。 --- ## 2. 现实与数字环境形成一个连续世界 很多网页互动只发生在屏幕内部。 很多 Arduino Demo 又只展示： ```text 传感器 → 数值 → 灯 ``` 《一扇窗》尝试把两者连接起来。 现实中的动作、光线和实体灯光，与屏幕中的自然世界共同构成一套体验。 技术并不是作品本身。 技术只是让： **现实世界和窗另一边的世界发生关系。** --- ## 3. 一份网页，同时服务实体装置和扫码用户 网页既可以成为： **实体作品中的显示屏** 也可以成为： **独立存在的数字作品。** 现场用户即使没有操作实体装置，也可以扫码进入自己的“一扇窗”。 因此作品不会在黑客松结束、装置拆掉之后完全消失。 它仍然可以通过链接继续传播。 --- ## 4. 用极轻技术实现完整体验 项目没有使用 3D 引擎、复杂前端框架或后端系统。 大量视觉环境由： **CSS + Canvas 2D + 原生浏览器 API** 完成。 这种低依赖架构让网页： * 体积小 * 启动快 * 容易部署 * 容易移动端访问 * 可以离线 * 更容易未来嵌入硬件 技术选择本身也服务于作品的轻量与可持续性。 --- # 十二、开发过程 这个项目的开发过程并不是按照最初计划一路顺利完成。 反而发生了大量调整。 ### 第一阶段：构想 最初希望制作的是一个真正能够“感知人”的小型实体窗口。 因此考虑了： * 压力传感器 * 触摸 * 环境感知 * WS2812B 灯带 * ESP32 * 屏幕 由于现场无法获得合适的独立触摸屏，后来决定暂时使用手机作为显示屏。 网页同时承担： * 屏幕 * 动画 * 声音 * 数字互动 --- ### 第二阶段：压力传感器实验 尝试通过压力传感器读取人的： * 接触 * 按压力度 * 停留 但经过较长时间硬件调试后始终无法稳定运行。 考虑到黑客松时间非常有限，停止继续投入。 --- ### 第三阶段：改用环境光 之后尝试使用光敏电阻。 这一方案反而和“一扇窗”在概念上产生了更自然的联系： **现实里的光发生变化，窗里的世界也发生变化。** 曾经成功读取到环境光变化。 于是将原来的多个复杂交互收敛成： ```text DAY / NIGHT ``` 两个状态。 这样既降低硬件复杂度，也让整个体验概念更加集中。 --- ### 第四阶段：光敏元件再次失败 但在继续开发过程中，光敏电阻无法再次稳定复现之前的结果。 在 Stack Anyway 平台进行了大量： * 电路调整 * 接线测试 * 代码修改 * 参数尝试 * 开发板测试 之后仍未解决。 AI 调试最终判断，使用的元件本身可能已经损坏。 这时继续投入硬件调试的边际收益已经非常低。 --- ### 第五阶段：主动收敛 MVP 于是最终决定： **不再为了“传感器必须成功”牺牲整个作品。** 将实体输入降级为 ESP32-S3 开发板自带按钮。 按钮负责 DAY / NIGHT 的可靠切换。 同时将更多精力投入： * 网页视觉 * 自然动画 * 声音 * PC / 手机适配 * 实体灯光 * 整体体验 这也是这个项目过程中很重要的一次决策： **从“我要把某个技术做出来”，回到“我究竟希望用户体验到什么”。** --- # 十三、团队分工 本项目由我一人独立完成。 包括： * 项目概念 * 产品设计 * 用户体验设计 * 交互设计 * 视觉方向 * 硬件选型 * 硬件接线与调试 * ESP32 实验 * 网页开发 * 响应式适配 * 声音方向设计 * AI 辅助音乐生成 * 项目迭代 * 最终 Demo 整合 开发过程中大量使用 AI 辅助完成跨专业工作。 包括： * 硬件方案分析 * 接线与故障排查 * ESP32 代码生成 * 前端代码生成和修改 * 视觉探索 * 音乐 Prompt 设计 * 项目范围收敛 对于一个没有硬件开发背景的个人开发者而言，AI 很大程度上降低了进入陌生领域的门槛。 但这个项目也让我看到： **AI 能够给出方案，并不意味着现实中的硬件一定能够按照文本逻辑稳定运行。** 面对真实电路、元件损坏、供电、引脚以及无法复现的问题，仍然需要不断实验、判断和做取舍。 --- # 十四、当前版本的局限 由于黑客松开发周期较短，目前版本仍然是一个 MVP。 主要局限包括： ### 1. 环境感知尚未稳定实现 原计划使用光敏传感器让装置自动理解现实环境亮度。 当前因为元件稳定性问题，暂时使用按钮模拟 DAY / NIGHT。 ### 2. 显示设备仍然依赖手机或电脑 当前版本将普通手机 / PC 浏览器作为窗口。 它已经可以完成体验验证，但还不是最终产品形态。 ### 3. 只有 DAY / NIGHT 两个主要状态 自然本身远远不只有白天和夜晚。 当前版本为了保证稳定，主动进行了大幅收敛。 ### 4. 实体结构仍处于原型阶段 目前重点是验证： **实体交互 + 灯光 + 数字自然环境** 是否能够形成一个成立的体验。 真正的工业设计、材料和结构仍需继续探索。 --- # 十五、后续计划 我并不希望《一扇窗》最后只是一个黑客松 Demo。 它更可能继续发展成一个： **带有艺术互动体验属性的桌面产品。** 后续主要希望沿以下方向继续探索。 --- ## 1. 使用真正独立的屏幕 未来希望不再依赖： * 手机 * 电脑 而使用专门的显示模块。 这样整个产品能够真正成为一个独立存在的实体： **一块只承担“窗”的屏幕。** 它不需要展示通知，也不会被其他 App 打断。 --- ## 2. 恢复真正的环境光感知 未来会使用更加稳定、专业的： * 光照度传感器 * 数字光线传感器 * 其他环境感知模块 取代当前简单光敏电阻。 不仅判断： ```text DAY NIGHT ``` 还可以获取真实光照强度，并进行分级。 例如： ```text 清晨 白天 阴天 黄昏 蓝调时刻 夜晚 ``` 现实环境的变化会映射到窗中的世界。 --- ## 3. 增加更多自然状态 未来不仅是昼夜。 还可能出现： * 下雨 * 风 * 雾 * 春天 * 夏天 * 秋天 * 冬天 * 阴天 * 雷雨前 * 日出 * 日落 这些状态不一定完全按照真实天气复制。 它们也可以拥有一定随机性。 让用户每一次看向窗外，都保留一点： **“今天会看到什么？”** --- ## 4. 加入更多感知方式 后续可以继续尝试： * 触摸 * 压力 * 距离 * 靠近 * 环境声音 * 温湿度 * 人的停留时间 但这些传感器并不会因为“技术更多”就全部加入。 只有当某种感知能够让人与这扇窗之间的关系更加自然时，才有加入的意义。 --- ## 5. 让交互更加像自然，而不是按钮 最终希望人与它的互动不是： ```text 按按钮 → 执行功能 ``` 而更像： ```text 靠近 停留 触摸 环境改变 时间经过 ``` 装置再以非常轻的方式回应。 这种关系应该更接近人与自然相处的状态。 --- ## 6. 丰富声音世界 目前已经验证 DAY / NIGHT 双音轨。 后续希望建立更完整的自然声景系统： * 不同时间对应不同环境声 * 极低概率出现特殊声音 * 随机鸟鸣 * 风 * 夜间虫声 * 音乐片段 * 空间化声音 避免明显重复循环。 让声音也成为“窗外还有什么”的一部分。 --- ## 7. 从互动装置走向产品 长期来看，我希望探索： 《一扇窗》是否有可能成为一种真实存在于： * 办公桌 * 卧室 * 宿舍 * 工作室 * 无窗空间 里的小型产品。 它不需要帮助用户提高效率。 也不需要每天提醒人完成什么。 它存在的理由可能仅仅是： **当一个人被困在很小的空间里的时候，让他还有一个地方可以向外看。** --- # 十六、项目总结 《一扇窗》最初来自一个很小的瞬间： 坐在办公室里， 从遮光帘和电脑屏幕之间， 看见一小块不规则的天空。 那个瞬间让我意识到： 有时候我们需要的并不是更多信息。 而只是需要知道： **外面还有世界。** 因此这个项目最终想留下的，也不是 DAY、NIGHT、ESP32、Canvas 或 WebSocket。 这些都是实现方式。 真正想留下的是一种感觉： 打开一扇窗。 窗外有森林。 窗外有夜晚。 还有那些暂时不知道是什么的东西。 而未知本身， 也意味着希望、好奇和无限可能。