星际拓荒主题新标签页

为什么做

《星际拓荒》最打动我的并不是某一个视觉符号，而是“在宇宙中围着篝火出发”的探索感。我想把这种情绪带进一个每天都会打开的界面，让新标签页不再只是冷冰冰的效率面板。

因此，我没有把它做成一张游戏壁纸或单纯的粉丝页面，而是选择 Chrome 新标签页扩展作为产品形态：3D 篝火营地负责营造氛围，番茄钟、今日 TODO、快捷导航和稍后再看负责解决真实的浏览器日常需求。体验目标是让“专注—休息—再次出发”与篝火、音乐和烤棉花糖形成自然的场景联动。

查看 GitHub 仓库与在线演示

从参考图到浏览器场景

最初，我尝试直接让 Codex 用 Three.js 基础几何体近似复杂乐器，结果虽然能运行，但形体、材质和细节都更像示意模型，无法支撑我想要的营地氛围。这个问题让我重新拆分了 AI 与工具的职责：Blender 负责模型形体与资产，Three.js 负责实时渲染和交互，Codex 负责把两个工作流连接起来。

我先从游戏截图中整理乐器的正面、侧面和背面参考，再让 Codex 通过 Blender 工作流完成基础建模、比例与细节调整，经过多轮目视校验后导出 GLB。进入浏览器后，还需要继续处理模型的方向、尺度、原点、材质、灯光和场景位置；“模型完成”与“产品中可用”其实是两个不同的验收节点。

宇宙背景也经历了类似迭代。我把粗糙的几何符号拆成程序化星场、远方恒星、尘埃、轨道线和缓慢动画等渲染层，并以克制的辉光、色温差异和大面积暗部建立空间深度。最终目标不是复制游戏资产，而是保留手绘宇宙与篝火营地的情绪。

关键取舍

• 氛围不能盖过工具效率。 3D 场景必须与常用模块共存，新标签页打开、快捷访问和计时流程仍然要直接。
• 场景效果不能以稳定性为代价。 WebGL 场景采用独立加载与降级策略，即使 3D 模块失败，番茄钟等核心功能仍然可用。
• 扩展与在线演示共享体验，但遵循不同运行边界。 演示页使用 localStorage，扩展环境使用 chrome.storage、Service Worker 与浏览器通知。
• 资产精度要服从 Web 性能。 模型、灯光、着色器和动画需要一起控制渲染预算，而不是单独追求模型细节。

我学到的技巧

1. 把 2D 参考转化为可验证的 3D 约束

三视图并不是最终模型，而是帮助 AI 与建模工具理解比例、轮廓和结构关系的中间产物。我学会了用正面、侧面与背面的关键特征定义验收点，并通过实际场景中的相机视角反复校正，而不是期待一次生成得到正确结果。

2. 组织 AI 辅助的 Blender / GLB 资产管线

我掌握了从建模指令拆解、比例与拓扑调整，到模型原点、方向、尺度、材质和 GLB 导出的完整链路。更重要的是，我学会了判断哪些问题属于建模，哪些属于 Three.js 场景配置，避免让代码用基础几何体“假装完成”复杂资产。

3. 搭建具有产品感的 Three.js 场景

这个项目让我实践了模型加载、相机与构图、灯光和 PBR 材质、程序化星场、粒子与着色器、帧率无关动画，以及移动端和低性能设备下的渲染预算控制。视觉效果的精细度来自多个系统的配合，而不是堆叠某一个后期特效。

4. 处理 Chrome 扩展的真实工程边界

我进一步理解了 Manifest V3、内容安全策略、chrome.storage 与 localStorage 适配、Service Worker 后台计时、浏览器通知、当前标签页导航和状态恢复等细节。对用户来说只是一次点击或一次倒计时，背后却需要跨页面生命周期保持一致。

5. 把个人原型推进到可交付版本

我为项目补齐了构建检查、在线演示、扩展 ZIP 打包和 GitHub Release 流程。这个过程让我更明确：一个“好看的 Demo”只有在可安装、可恢复、可降级、可持续更新后，才真正成为产品。

它证明什么

这不是为了证明我能写多少 Three.js 代码，而是一次完整的边界扩展：我从明确的体验目标出发，主动补足 3D 建模、WebGL 渲染和浏览器扩展知识，并用 AI 工具加速陌生领域的预研与迭代，最终把个人兴趣推进成真实可用、可公开验证的产品。

口径说明：独立项目；功能与实现以公开仓库和可运行版本为准，不与工作项目混淆。