浮光 · 壁纸为主角的新标签页

01. 项目概述

项目简介

浮光是一款以壁纸为主角的新标签页扩展，让用户在保留个性化视觉体验的同时，自由管理快捷链接与页面布局。

与功能丰富、信息密集的新标签页不同，浮光更注重页面的视觉留白和使用者的自主控制。它不预置推荐内容，也不主动向用户展示热搜、资讯或其他附加信息，而是将页面的主要空间留给用户选择的壁纸。

项目从个人使用需求出发，由我独立完成产品构思、需求分析、竞品体验、产品规划、界面与交互设计，并借助 AI 完成开发。在开发过程中持续进行测试、调整和验收，最终成功上架 Microsoft Edge 扩展商店。

项目基本信息

• 项目名称： 浮光
• 产品类型： 浏览器新标签页扩展
• 发布平台： Microsoft Edge 扩展商店
• 项目性质： 个人独立产品项目
• 项目角色： 产品规划、需求分析、竞品体验、UI/UX 设计、AI 协作开发、测试验收、产品发布与推广
• 开发方式： AI 辅助开发
• 项目状态： 已正式上架，核心功能已完成

02. 项目缘起：从个人使用痛点出发

原生新标签页无法满足我的使用需求

最初，我希望浏览器新标签页能够以自己喜欢的壁纸作为主要视觉内容，同时保留少量常用网站入口。 但在使用浏览器原生新标签页时，我发现它存在一些不符合自己使用习惯的限制：

• 搜索框无法隐藏，也不能自由移动。
• 快捷图标无法按照自己的需求进行分组管理。
• 页面元素的布局调整空间有限。

这些限制影响了我对新标签页的个性化控制。尤其是当我使用包含人物主体的壁纸时，希望快捷图标能够放在页面边缘，而不是遮挡壁纸主体。

体验同类扩展，发现新的问题

为了解决这些问题，我尝试体验了其他新标签页扩展。 在体验过程中，我发现不同产品虽然各有优势，但都存在一些让我无法满意的地方。

一类产品支持类似手机桌面文件夹的图标分组，但页面中包含较多其他内容，快捷图标区域也占据了画面中央，容易遮挡壁纸主体。 另一类产品界面相对简洁，壁纸展示空间较大，但快捷图标不支持分组，也不能自由调整位置。 此外，其设置页面的组织方式也不符合我的使用习惯。

这让我意识到，自己需要的并不是单纯增加几个功能，而是让壁纸展示、快捷链接管理和页面布局之间形成更合理的关系。

明确产品需求

结合实际使用体验，我整理出了以下需求：

需求方向	具体需求
壁纸展示	尽可能保留壁纸主体，减少页面元素的遮挡
快捷链接	支持添加、编辑、分组和管理常用网站
分组管理	快捷链接可以按照不同用途进行分组
布局调整	快捷链接区域可以调整位置
搜索框	支持隐藏和移动
设置界面	功能分类清晰，避免不必要的信息干扰

但是当时体验过的扩展，都无法同时满足这些需求。于是，我决定自己设计一款新标签页扩展。

03. 产品定位：让壁纸成为页面的主角

核心定位

浮光的核心定位是：一款以壁纸展示为主，提供必要快捷链接管理能力的新标签页扩展。

在设计过程中，我始终将壁纸作为页面的主要视觉内容。快捷图标、搜索框等功能元素应当服务于使用，而不是占据页面的视觉中心。

因此，我没有将浮光设计成一个集成大量信息和功能的综合型新标签页，而是主动控制功能范围。

产品设计原则

壁纸优先

壁纸是页面最重要的视觉内容。快捷图标区域应尽量避开壁纸主体，避免使用影响壁纸清晰度的视觉效果。例如，我不希望通过玻璃模糊等效果来处理页面元素，因为这会影响壁纸本身的展示效果。

功能简洁

只保留与壁纸展示、快捷链接管理和页面个性化调整直接相关的功能，不额外堆砌资讯、热搜、推荐内容等模块。

用户自主控制

不预置快捷链接，也不替用户决定应该访问哪些网站。快捷链接由用户自己添加和管理，页面布局也尽可能交由用户调整。

明确不做什么

产品定位不仅包括需要实现的功能，也包括主动排除的功能。浮光不以内容推荐为目标，不提供资讯流、热搜和各种信息小组件，也不通过预置快捷入口来占据用户的页面空间。

我希望用户打开新标签页时，看到的是自己选择的壁纸，以及仅有自己添加的快捷链接。

04. 产品规划：从需求拆解到功能架构

明确产品定位后，我开始将需求拆解为具体功能，并规划各模块之间的关系。

核心功能架构

浮光的主要功能可以分为以下几个部分：

功能模块	核心功能
背景	上传背景、恢复默认、使用原分辨率
背景调整	调整背景亮度、模糊等效果
图标布局	调整图标间距、位置、行数及显示样式
搜索框	控制搜索框显示及位置
书签	导入浏览器书签，辅助添加快捷链接
数据	导入导出备份、清空扩展数据

设置模块的分类设计

设置界面采用按功能分类的方式组织内容，并通过展开模块显示具体选项。这样既能让用户快速找到对应功能，也不需要在页面中同时展示所有设置项。

设置浮窗采用纵向滚动结构，壁纸仍然能够从浮窗周围透出，避免设置界面完全覆盖新标签页的视觉内容。

为什么将背景和背景调整分开？

在实际使用中，我发现上传背景和调整背景是两种不同的操作。上传背景是比较常用的功能，而亮度、模糊等调整选项并不是每次更换壁纸都需要使用。

如果将这些选项全部放在一起，用户每次上传背景时都需要面对一组当前并不需要的调整选项。因此，我将两者拆分为独立模块，让背景上传和背景效果调整分别对应不同的操作目的。

书签模块：减少添加快捷链接的操作成本

书签模块的主要作用是复用用户已有的浏览器书签数据。用户导入浏览器书签后，浮光会提取其中的网站名称和网址。

在添加快捷链接时，用户可以通过下拉列表选择已有书签，而不必逐个手动输入网址。这样既保留了用户原有的书签资源，也减少了添加快捷链接时的重复输入操作。

数据管理：考虑同步、备份与清空需求

在数据管理方面，我考虑了不同使用场景下的数据保存需求。

浏览器同步

在浏览器开启同步功能的情况下，分组、链接和界面设置可以通过浏览器账号进行同步。

JSON 备份

为了方便用户更换电脑或浏览器，我设计了独立的数据导出与导入功能。

备份文件采用 JSON 格式，包含分组、链接和自定义图标图案。壁纸、界面设置和书签识别结果不包含在备份文件中。其中，壁纸由于文件体积较大，没有纳入备份；书签识别结果则可以在需要时重新导入。

导入备份时，会整体替换当前已有的分组和链接，而不是与现有数据合并。壁纸和界面设置不受影响。

清空扩展数据

我还考虑了用户删除扩展后的数据残留问题。

如果用户开启了浏览器账号同步，删除扩展后，浏览器可能仍会在一段时间内保留扩展相关数据。因此，我加入了清空扩展数据的功能，让用户可以主动清除数据，使扩展恢复到刚安装时的状态。

05. 交互与视觉设计：围绕壁纸展示进行布局取舍

在具体设计页面布局时，我需要同时考虑壁纸主体、快捷图标区域、分组切换控件和设置浮窗之间的位置关系。

快捷图标区域的位置设计

最初规划页面布局时，我就决定将快捷图标区域放在页面顶部或底部。因为这两个位置更容易避开壁纸主体，减少对壁纸内容的遮挡。

我也考虑过将快捷图标放在页面左右两侧，但最终没有采用。因为右侧已经被设置浮窗占据；左侧则会与右下角的胶囊式分组切换控件形成割裂，而且左侧布局与胶囊控件左右切换的交互方向也不协调。

综合考虑这些因素，我最终决定让快捷图标区域只支持 Y 轴方向的位置调整，也就是在页面上方和下方之间移动。

这一设计在满足布局调整需求的同时，也避免了页面元素之间的位置冲突。

搜索框设计

最初设计时，我没有将搜索框列为必要功能。因为我个人习惯直接使用浏览器地址栏进行搜索，并不需要在新标签页中额外放置搜索框。

但在其他功能基本完成、准备上架时，我考虑到其他用户可能有使用页面内搜索框的需求，因此在后期加入了搜索框功能。

同时保留了隐藏和移动搜索框的能力，让用户可以根据自己的使用习惯决定是否展示。

浮窗视觉效果调整

在 AI 最初生成的界面中，所有浮窗都采用了玻璃模糊效果。但这种效果会影响壁纸的清晰度，与我希望壁纸成为页面主角的设计方向不符，因此我要求移除所有浮窗的玻璃模糊效果。

随后，我尝试过根据背景明暗分别调整浮窗颜色，但在实际效果中发现，浅色背景下使用降低不透明度的黑色浮窗并不理想。经过比较，我最终决定统一使用白色作为浮窗底色，并降低其不透明度。

这样无论背景偏亮还是偏暗，浮窗都能保持相对统一的视觉表现，同时让壁纸透出。

胶囊式分组切换控件

右下角的胶囊控件用于切换不同的快捷链接分组。

AI 最初实现的效果并不符合我的设计预期，因此我进行了多轮调整，并直接修改代码中的参数，包括胶囊内部颜色的浓度和外框线的不透明度。

除了胶囊控件，其他界面设计模块也有一些细节是我根据实际呈现效果，直接在代码中微调数值完成的。

06. AI 协作开发：从需求表达走向方案判断

浮光采用 AI 辅助开发的方式完成。

在这一过程中，我主要负责产品需求、交互与视觉设计、方案判断和最终效果验收，AI 负责协助实现代码。

我没有将需求一次性提交给 AI 然后等待最终结果，我是在开发过程中持续观察实现效果，根据实际情况调整需求、修改方案，并参与具体实现细节的优化。

设计效果把控

AI 最初生成的界面并不完全符合我的设计预期。例如，浮窗玻璃模糊效果与壁纸优先的定位不符；浮窗颜色方案在不同明暗背景下的表现也存在问题。

面对这些情况，我会根据实际效果判断与预期之间的差异，再提出具体修改方向。

当我知道通过什么方式可以达到目标效果时，就会直接告诉 AI 应该如何修改。对于部分界面细节，我也会直接进入代码调整数值，而不是完全依赖 AI 自行判断。

解决裸图标被裁剪的问题

在开发快捷链接图标时，我遇到了一个比较典型的问题：部分网站使用没有背景底色的裸图标，经过圆形遮罩处理后，图标内容会被裁剪。

为了解决这个问题，我没有只要求 AI 修改显示效果，而是自己分析了图标的显示规则，并提出了一套新的处理思路。

我的想法是：先为裸图标添加圆形底层，再利用圆形内部的内切圆角矩形作为图标的缩放范围。对于尺寸较大的图标，将其缩小到能够完整显示在这个范围内；对于尺寸较小的图标，则放大到能够充分利用显示区域，同时不超出范围。 这样，圆形底层负责最终的圆形外观，图标本身只需要按照内部范围缩放，不必直接裁剪。

在进一步讨论时，我还提出了更直接的图标类型判断方法：裸图标与自带底色图标的主要区别在于是否存在透明区域，因此可以检查图标显示范围内的透明区域，以判断图标类型。

AI 最终认可了这一思路，并将判断方式进一步简化为检查图标四角是否存在透明区域。

控制实现方案的复杂度

在另一次方案讨论中，AI 对裸图标的处理引入了过多判断条件。 我重新解释了不同图标类型之间的区别，并指出当前方案中不必要的复杂处理。 最终，通过重新梳理问题和判断条件，AI 调整了原先的实现思路。

这类协作并不只是让 AI 按照要求编写代码，也包括对 AI 提出的方案进行审视、纠正和优化。

持续测试与迭代

浮光的测试并不是在开发完成后才集中进行的。 从开发开始，我就一直通过浏览器开发者模式安装扩展，在实际的新标签页环境中观察每一轮实现结果。

测试内容包括：

• 页面界面的实际呈现效果。
• 各项功能是否按照预期实现。
• 动画效果是否符合设计预期。
• AI 修改后的结果是否真正解决了当前问题。

当发现问题时，我会先分析当前效果与目标之间的差异，再根据自己对问题的判断提出修改方向。 对于界面问题，如果已经明确解决方式，就直接告诉 AI 如何修改；对于功能实现问题，则会描述希望达到的效果，并指出当前实现还缺少哪些部分。

因此，浮光的开发过程实际上是一个持续循环的过程： 提出需求 → AI 实现 → 实际运行测试 → 发现问题 → 分析差异 → 调整方案 → 再次验证。

07. 上架与发布：从开发完成到正式上线

核心功能完成后，我开始准备将浮光发布到 Microsoft Edge 扩展商店。

上架材料准备

首先，我登录了微软合作伙伴中心账号，开始准备扩展上架所需的材料。

主要工作包括：

• 编写扩展商店描述。
• 在 GitHub 创建仓库，并存放隐私说明文件。
• 准备扩展压缩包。
• 编写扩展简介。
• 填写隐私相关信息及其他上架资料。

提交审核

完成材料准备后，我将扩展压缩包及相关信息提交至 Microsoft Edge 扩展商店审核。 提交后等待了几个小时，扩展便顺利通过审核，没有遇到明显阻碍。

至此，浮光正式完成上架。

产品演示视频制作与推广

上架后，我录制并剪辑了一段产品演示视频，用于展示浮光的整体界面和主要功能。 视频采用录屏展示的方式，配合背景音乐和字幕，没有使用旁白讲解。 展示内容包括产品理念、快捷链接分组与管理、添加链接、图标编辑、布局调整、搜索框设置、背景及图标颜色调整，以及不同壁纸下的实际展示效果。

视频发布在 B 站，并在视频简介和评论区附上 Microsoft Edge 扩展商店链接，方便感兴趣的用户获取产品。

08. 项目展示

产品名称： 浮光

发布平台： Microsoft Edge 扩展商店

• Microsoft Edge 扩展商店
• GitHub 隐私说明仓库