最近做了一次微信小程序首页改版。
最开始我只是想把原来的页面，从普通小程序风格重构成更统一、更有识别度的像素风。
但真正做完之后，我发现这件事最有价值的地方，其实不是“页面改好了”，而是我把整个过程进一步沉淀成了一个以后还能继续复用的 Skill。
也就是说，这次我产出的不只是一个改版后的首页，而是一套以后还能拿去继续改别的项目的前端重构方法。
先看前后对比
改造前
改造前的页面整体更偏默认小程序界面：
- 首页层级感偏弱
- 功能入口不够突出
- 模块之间辨识度不强
- 页面有功能感，但缺少风格记忆点
改造后
改造后我把首页统一成了纸张底像素风，整体变化主要有这些：
- 首页主卡和次卡层级更清晰
- 应用专区、音乐专区、网页专区区分明确
- 图标、描边、阴影、装饰角统一成同一套语言
- 页面第一眼识别度更强
- 首页开始承担整站风格定调的作用
我没有让这次改版只停留在“改完”
很多 UI 改版最后都会停在一个状态：
- 页面改了
- 视觉统一了一些
- 但方法没有留下
- 下次换项目又要重新总结一遍
这次我不想让它只是一次性的页面产出。
因为我发现这种前端重构，反复都在解决同一类问题：
- UI 图和真实代码不一致
- 首页改完了，内页风格跟不上
- 按钮、输入框、Toast、弹窗各写各的
- 页面改完了，但需求文档、发布说明、回归测试没有同步
所以最后我把这次过程提炼成了一个 Trae Skill：
pixel-ui-refactor
这个 Skill 主要解决什么问题
它不是一个简单的“帮我改成像素风”提示词，而是一套完整的重构流程，主要解决这些事情：
- 先确认事实源
- 再统一视觉基线
- 抽离通用组件
- 分页面推进改造
- 同步需求、发布和回归文档
- 最后做验收和发布前收口
也就是说，它做的不是单页样式输出，而是帮助我把一轮前端重构真正做完整。
我这次沉淀下来的几个关键点
1. 先确认事实源
真实项目里最容易冲突的通常是：
- UI 图
- 真实代码
- 需求文档
- 发布说明
所以我把 skill 里的事实源优先级固定成了：
- 最新补充需求文档
- 当前审核 / 发布口径
- UI 图
- 当前真实代码
这样后面的重构就不是只看“哪个好看”，而是先对齐真正的交付口径。
2. 先冻结风格基线
这次我把像素风拆成了明确规则，而不是抽象描述：
- 纸张底
- 彩色功能块
- 粗黑描边
- 硬阴影
- 像素图标
- 模块层级
同时也明确了禁止项，比如：
- 毛玻璃
- 柔和阴影
- 无边框输入框
- 只换皮、不改结构
3. 先做首页定调，再做内页
我最后沉淀出来的顺序是：
- 先冻结视觉变量
- 再抽离通用组件
- 先做首页
- 再做内页和表单页
- 最后补弹窗、Toast、状态反馈和文档收口
这个顺序能明显降低“每页都像像素风，但整站又不像一个系统”的问题。
4. 文档同步也属于重构的一部分
这次我没有让 skill 只覆盖 UI 和代码，还把这些也做进去了：
- 需求模板
- 发布模板
- 回归检查清单
- 验收基线
- 跨项目适配指南
因为我越来越觉得：
如果页面改完了，但发布说明和测试清单没同步，那这轮重构其实还没有真正结束。
我把它整理成了一个完整仓库
我最后把这个 skill 发到了 GitHub：
现在仓库里不只有 SKILL.md，还包括：
README.mdREADME.en.mdtemplates/references/examples/LICENSE
也就是说，它现在已经不是一条 prompt，而是一套可以继续复用、继续扩展、继续分享的 skill 包。
为什么我觉得这件事比“单纯做个改版”更有意义
因为页面改版本身是一次性的，但 skill 不是。
一个页面改完，价值通常只停留在当前项目里。
但如果把整个过程抽成 skill，它就会变成：
- 下一个项目还能继续用
- 团队里其他人也能直接用
- 这次经验不会随着项目结束一起消失
- 你自己的方法论资产会越来越清晰
这也是我这次最满意的地方。
不是只做出了一个像素风首页，而是把整个过程留下来了。
最后
这次我最大的收获，不是“把首页改成了像素风”，而是第一次比较完整地把一轮真实的小程序重构过程，沉淀成了一个以后还能继续使用的 Skill。
如果你也在做类似的 UI 重构，或者也在尝试把项目经验沉淀成可复用资产，欢迎交流。
仓库地址再放一次：
