个人主页实现｜Build in Public

原来的作品集首先展示一张暗色人像海报，项目列表被推到首屏之外。更具体的问题出现在宽屏：文案容器有固定最大宽度，同时左右内边距会随视口增加，最终正文可用宽度接近零，标题和说明都变成一字一行。

这一轮没有继续给旧海报补装饰，而是重新确定作品集的职责。首页的 3D 桌面负责让人愿意探索，作品集负责把真实项目说清楚。因此页面改成短介绍、重点项目和项目索引三段，打开后可以直接看到项目截图、状态、阶段、结果和详情入口。

项目数据也不再来自单独的静态数组。作品集现在读取与“最近在做”和项目档案相同的公开项目 collection，草稿不会出现，推荐项目优先，其余按更新时间排列。以后增加一个公开项目，只需要补项目内容与档案，不需要再改作品集页面。

重点项目封面来自当前真实 3D 首页，压缩后为 56,326 字节。图片的自然尺寸与渲染比例一致，没有拉伸。作品集在常见横屏下完成截图和溢出检查，详情入口可以进入现有 Build in Public 档案；首页则继续使用原来的桌面实现。

这一轮没有继续猜键盘、机箱或台灯应该长什么样，也没有把新的模型直接塞进默认桌面。真正缺少的是尔玉实际物件的照片，因此先把“照片来了以后怎么做”变成一条不会破坏现有页面的流程。

原始照片默认只作为建模输入，不进入公开仓库。照片先检查屏幕内容、二维码、序列号、快递单、他人面孔和镜面倒影；公开仓库只保留确认后的 GLB、脱敏来源说明和必要参考。

模型目录现在有了机器可检查的清单。每个 GLB 都必须说明来源、生成工具、输入素材权利、授权、坐标、原点、缩放、体积预算、预览参数和默认状态。候选没有明确验收记录时，Gate 不允许把它设成默认。

下一次收到一组真实物件照片后，可以只为该物件建立候选，在独立地址比较默认版和模型版。候选失败、加载失败或最终不采用，都不会影响当前桌面。

这一步没有再往桌面上增加物件，而是先把“可以发布”变成一组能重复执行的条件。现在一条命令会依次完成单元测试、Astro 诊断、静态构建、资源预算和构建产物审计，并检查必需页面、站内资源、本机路径、常见凭据形态和新窗口外链安全。

检查器先由失败测试驱动，再拿真实构建结果校准。它确实发现了一个静态分享页的新窗口链接缺少安全属性；修复后，又为相对 HTML 与 CSS 资源、无引号属性、Astro 的 404.html 输出以及压缩脚本误报补了回归测试。

依赖更新也经过单独审计。核查时，Astro 7.1.0 的信息存在冲突：官方发布带有已验证签名，一条 OSV 恶意包记录后来被标记为撤回，而 GitHub 安全公告仍保留相关记录。这里采取的是当时的谨慎措施，不对该版本下恶意结论：没有运行它的 CLI，直接改用官方签名发布的 7.1.6；Sharp 更新到 0.35.3。全量与生产依赖审计均为 0。

默认桌面没有借这次收口顺便改样式。两个基准分辨率与 V0.7 保持零像素差，另外四个常见横屏尺寸也完成了非空渲染、溢出和核心交互检查。公网仍未更新，下一步先做本地验收。

这一步没有把每天的聊天或终端输出搬到网页上，而是把内容拆成稳定概览和独立更新。项目概览回答“为什么做、现在在哪”，每条更新只记录一次判断或变化。

桌面副屏仍然只有三个入口。访客点开“最近在做”后，先在主屏看简短预览，再决定是否进入完整项目页。这样 3D 场景保持简洁，真实过程也不需要依赖飞书接口才能阅读。

第一次模型实验没有直接替换整套桌面，而是选择体积小、交互边界清楚的鼠标。GLB 只替换视觉层，拖动容器、点击代理和主屏光标同步继续沿用稳定逻辑。

加载器采用按需动态导入，并处理并发缓存、失败重试、取消和幂等释放。这个候选是否成为默认视觉仍要单独验收，但以后新增模型已经不需要重新发明加载和回退流程。

秒哒路线的目的不是复制当前站点，而是验证：不用完整 Three.js 工程时，卡通化真实桌面是否仍然能成为一个有趣、可读的个人主页入口。

这条路线和主站共享构图判断与个人视觉资产，但实现和验收独立。这样既不会把已有代码伪装成平台原生作品，也不会为了参赛尝试破坏当前已经可运行的主页。

图片转模型会自然带来新的资源，因此不能先加模型、最后再猜页面为什么变慢。这里先把人物图和 Q 版摆件改成适合实际显示尺寸的 WebP，并把大尺寸降级图改成失败后才请求。

这一步同时加入自动预算。以后任何模型或脚本让默认入口超过约定体积，构建检查会直接失败，而不是等到发布后才靠体感发现。

一次诊断发现，线上运行代码和原先记录的“唯一代码基线”已经分叉。继续加功能之前，必须先回答一个很朴素的问题：修改到底应该落在哪一条历史上。

处理方式不是删除旧版本，而是保留当前生产文件树、把两段历史合入同一主线，并为合并前状态建立保护点。之后功能分支都从统一主线出发，GitHub 合并和公网发布仍然是两件事。

原来的场景能运行，但增加一个物件要同时碰建模、坐标、点击、状态和销毁逻辑。真正的成本不是写几十行 Three.js，而是所有东西都挤在同一个函数里，改动很难单独验证。

这轮重构只改变代码边界，不改变画面。所有物件统一返回可交互目标和可选的更新、释放函数；scene.ts 只负责装配。这样后续替换鼠标或键盘时，不需要重新理解整张桌子。

这一步没有追求“看起来更高级”，而是先解决可逆性。桌面已经经过多轮构图修改，如果直接在同一份代码上继续拆分，一旦画面发生变化，很难判断是有意优化还是重构回归。

因此先保存受保护标签，再把结构调整放到独立分支。后续每一轮都能回到这个版本比较，而不是靠聊天记录回忆“原来大概是什么样”。