- 项目模块
将项目页原来的“开源项目、科研代码与实验室折腾记录”精简为“开源项目折腾记录”，并同步修改管理端和部署端的项目页面，使两边的显示保持一致。
- 页脚技术栈徽章设置
修复了新增技术栈徽章后，页面虽然提示操作成功，但刷新后新增徽章消失、重新打开设置页也无法看到的问题。
这次没有改动“添加徽章”按钮或保存队列，而是修复了管理端读取 footerBadges 配置的逻辑。
- 灵境模块
将灵境标题下方的说明文字由“从神秘的记忆试管到深邃的星际巨舰，在这里封存所有的灵感与奇迹”精简为“在这里封存所有的灵感与奇迹”。
同时从管理端和部署端的灵境页面中移除了“帝江号舰船”的切换入口、页面状态、组件导入与渲染分支。帝江号的模型文件和资源仍然保留，只是不再由灵境页面加载。
- 归档模块
将归档页中的“研究终端”调整为“研究/学习终端”，“篇研究记录”调整为“篇研究/学习记录”，并将文章创作入口的提示语统一为“攥写新篇章”。
- 照片墙模块
将照片墙说明中的“定格时间，封存泰拉与现实的每一次心跳”修改为“定格时间，封存次元与现实的每一次心跳”。
- 杂谈模块
将杂谈说明中的“代码、学术、提瓦特与泰拉大陆的碎片记录”精简为“代码与次元的碎片记录”，并同步更新默认配置的补全逻辑，避免旧配置重新补回过时文案。
出现的问题
- 同一页面在两套目录中分别维护
当前项目由管理端和用户端两部分组成，一些页面组件和默认文案在两边各有一份。如果只修改其中一处，就可能出现管理端与线上博客显示不一致的情况。因此，项目页、灵境、归档和照片墙等页面文案都需要在对应位置同步调整。
- 技术栈徽章在刷新后被旧数据覆盖
新增徽章时，界面先更新的是 React 内存中的状态，所以能够立即显示“添加成功”。真正写入本地配置，还需要经过“保存修改 → 操作队列 → 更新本地”的流程。
这次新增的徽章其实已经成功写入 siteConfig.ts，问题出现在保存后的刷新回读阶段：原配置接口能够读取对象、字符串、布尔值和数字，却没有正确返回数组类型的 footerBadges。设置页拿不到最新数组后，又回退到了旧 standalone 生产包中的默认徽章列表，因此新增项看起来像是被删除了。
- 源码与实际运行的生产包不是同一版本
灵境、归档、照片墙和杂谈的源码已经修改完成，但启动脚本优先运行了此前生成的 .next/standalone 生产包。它只判断生产包是否存在，没有判断生产包是否比源码更新，因此实际打开的仍然是旧页面。
“同步 Blog”主要处理内容和配置同步，并不会重建已经存在的 React 生产包；已经运行的旧服务进程也不会自动加载新构建。于是便出现了源码中已经没有旧文案和帝江号入口，页面上却仍然能够看到它们的现象。
解决方案
- 同步修改管理端与部署端
对两套目录中实际参与展示的页面逐一定位并同步修改；杂谈的默认文案也同时更新到配置补全脚本中，确保新配置与已有配置使用同一版本的文字。
- 补全数组配置的读取能力
管理端配置接口现在会从 siteConfig.ts 的根级配置中正确解析并返回 footerBadges 数组，同时避免把徽章内部的 namecolorsvg 等字段误认为全站根配置。这样在保存后刷新页面时，设置页会重新读到完整的新徽章列表，不再回退到旧生产包中的默认值。
技术栈徽章的正常使用流程仍然是“添加徽章 → 保存修改 → 更新本地”；如果还需要让公开博客首页同步显示，再继续执行“同步 Blog”。
- 重建生产包并重启旧进程
重新构建了管理端的 standalone 生产包和用户端的本地生产包，随后彻底关闭仍在运行的旧管理器与命令行窗口，再通过 Start.bat 启动新版本。