从零搭建个人作品集网站：一次边做边改的记录
这篇文章根据最初的网站规划、域名配置对话、时间线调整过程，以及项目中保留的设计与部署记录整理。
从零搭建个人作品集网站：一次边做边改的记录
整理日期：2026 年 10 月 25 日
网站地址：aboutme.157139.xyz
这篇文章根据最初的网站规划、域名配置对话、时间线调整过程，以及项目中保留的设计与部署记录整理。
最开始，我只是想给自己的项目找个地方
最初的想法其实很简单：做一个自己的网页，放个人介绍，也放一些开源项目。以后有东西想写，能顺手发篇文章，最好还能直接在网页上编辑。
但有一点从一开始就很明确：这个网站的主角应该是作品。
我做的事情横跨机械设计、PLC 控制、嵌入式、前后端和 Android 开发。单独列一张技能清单，很难说清这些方向之间有什么联系。我更希望别人打开网站后，能通过具体项目看到：我做过什么、解决了什么问题，以及软件、电路和机械结构是怎么连到一起的。
文章可以帮助解释项目，也可以记录踩过的坑。首页的主要位置，还是应该留给作品。
技术上的预期也比较实际：能部署到 Vercel，尽量用静态页面，打开快一些，后续更新别太麻烦。毕竟搭完网站之后，我还想继续做项目，不想为了维护一个个人主页，再给自己增加一套需要长期照看的服务。
先别写代码，我想先看看它长什么样
这次没有一上来就选模板、装依赖。前面先花了一些时间讨论设计。
我对“科技风”是有偏好的，但不喜欢那种满屏蓝光、发光边框和粒子的页面。看起来很热闹，却容易让人忽略真正的内容。我想要的是深色、安静、有秩序，能让人联想到工程师的工作，而不是科幻电影里的控制台。
所以，最早的要求就是：先做设计，等设计收敛了，再统一进入开发。
文字方案先从三个角度展开：偏成果展示的工程作品档案、偏个人表达的技术工作室，以及偏长期积累的技术研究索引。这一轮主要是在想清楚网站应该给人什么感觉、先让访客看到什么。
之后又做了三套更直观的视觉方案：
| 视觉方向 | 主要画面 | 想表达的感觉 |
|---|---|---|
| A：精密机电 | 金属机构、电机、绿色控制板 | 冷静、精密，突出软硬件结合 |
| B：个人工程工作台 | 工作灯、工具、笔记与原型 | 更有个人实践和工作环境的气息 |
| C：结构与电路 | 机械拆解关系、控制板、结构层次 | 强调原理、结构和系统设计 |
最后落地采用了 A 的“精密机电”方向。石墨黑的底色、金属的质感、低饱和的绿色电路板，比较贴近我想展示的内容。强调色只放在少量链接和状态上，页面层次主要靠文字大小、细线和间距来组织。
这一阶段还明确了一件后来影响很大的事：首屏要占满一个完整的可视窗口。打开网页时，先看到背景、姓名、方向和进入项目的入口；继续往下滚，再进入内容区。它应该是一张完整的开场画面。
设计效果图和真正的网页也分开处理。背景图只负责机械与电路的视觉，姓名、导航和按钮都由页面单独排版。这样后面改名字、改介绍、调整手机布局，就不用重新生成整张图片。
把效果图变成能持续更新的网站
方向确定之后，开发才开始。
最终采用的是 Astro、Tailwind CSS 和自定义样式，文章与项目用 Markdown 管理，个人资料、时间线和荣誉证书用 JSON 保存。网站在构建时生成静态页面，不需要为访客浏览额外运行数据库或后端服务。
这套结构比较符合当时的需求：内容大多是介绍、图片和文章，没必要先做一套复杂的后台系统。与此同时，也要把内容和页面代码分开，避免以后每增加一个项目，都得重新改首页。
首页逐渐形成了现在的顺序：
- 首屏展示姓名、工作方向、头像和联系方式入口。
- 精选项目占据内容区的主要位置，桌面右侧放最新三篇文章。
- 荣誉与证书提供另一种了解经历的方式。
- 时间线串起不同阶段的经历。
- 最后是关于我和页脚。
项目和文章都有独立的列表页、详情页，首页只负责挑出重点。精选项目最多展示两项，文章按日期取最新三篇，更多内容再进入各自的页面看。这样以后内容变多，也不至于把首页无限拉长。
第一版先放了三个演示项目和四篇演示文章，用它们撑起列表、卡片和详情页，再逐步替换成真实内容。机械与电路的部分图片也是 AI 生成的概念素材，用来确定视觉效果，并不能当作实际制造或测试成果。个人照片和二维码则来自本人提供的资料。这些来源需要分清楚，否则一张看起来很像实物的图，很容易让人误解。
一些很小的细节，也是在这时慢慢补齐的。比如联系方式可以查看完整地址，微信入口能展示二维码；手机上的导航需要收起来，点击菜单项后再自动关闭；横屏时按钮也得留在可视范围内。
这些东西在效果图上不太显眼，真正开始用的时候，却会直接决定这个网站顺不顺手。
“以后能编辑”，不能只留一句承诺
一开始就提过希望网站后续能编辑，所以这部分也需要真正做出来。
最基础的方式是直接改本地文件：文章放在 src/content/articles，项目放在 src/content/projects，个人介绍和时间线放在 src/data。每篇内容都有自己的标题、日期、封面和正文，页面会读取它们生成展示内容。
为了少一些重复操作，项目里准备了文章与项目模板，也加了生成草稿的命令。新内容默认可以先作为草稿保存，确认后再发布。首页和列表只展示已发布的内容。
图片也纳入了同一套流程。文章和项目的图片进入资源目录，构建时由 Astro 生成适合网页使用的版本，省得每次上传前都手工处理多套尺寸。
不过，“可以改 Markdown”仍然有一点门槛。我还希望在浏览器里就能换图片、改文字，于是接上了 Pages CMS，并用 .pages.yml 配好中文菜单和编辑字段。
后台可以管理五类内容：文章、项目、荣誉与证书、个人时间线，以及个人资料与首页。它们编辑的仍然是仓库里的文件，因此本地维护和网页编辑可以共用一份内容。
至此，更新链路就明确了：
Pages CMS 保存内容
↓
GitHub 产生提交
↓
Vercel 自动构建
↓
线上网站显示更新这里有一个需要适应的小区别：后台点保存之后，网站还要等部署完成才会更新。编辑器里保存成功，和访客已经看到新内容，是两个不同的状态。
所以当时没有停在“后台能打开”这一步，而是临时改了一篇演示文章的标题，确认 GitHub 收到提交、Vercel 构建完成、正式网站显示了新标题，再把原标题恢复。走完这条链路，才算知道日后自己更新内容时，整个流程确实能接得上。
证书展示，也是在实际使用里改出来的
荣誉与证书没有简单地堆成一排缩略图，而是做成了可以横向浏览的书架。下方有时间轴，也能通过箭头或键盘切换。
证书有横版、有竖版，尺寸也不统一，所以展示时优先保留整张图片，用留白适配外框。描述可以不填，没有必要为了让版面看起来完整，给每张证书都硬写一段话。
这个区域后来也改过手机交互。手机 Safari 的横向拖动、页面的纵向滑动，以及鼠标的点击选择，需要分别考虑。仓库里保留了修复手机滑动和保留鼠标点击选择的提交记录。
这类问题很容易在桌面预览时被忽略。把窗口缩小，只能看出布局有没有挤坏；触摸时好不好用，还需要单独检查。
从本地页面，到一个别人能打开的网址
本地能看之后，下一步才是部署。
源码放进 GitHub 的 personal-portfolio 仓库，再把仓库连接到 Vercel。项目按 Astro 静态站配置，安装依赖后执行 npm run build，把 dist 作为输出目录，运行环境使用 Node.js 24.x。
连接完成后，main 分支有新的提交，就会触发正式部署。这样以后改文章、换项目图，或者修一个交互，都可以沿着同一条链路发布。
第一次上线先用了 Vercel 分配的地址：
personal-portfolio-seven-delta-75.vercel.app
部署记录里确认了正式环境可以公开访问，首页、项目和文章的列表及详情、微信二维码等资源都做过访问检查。源码仓库可以保持私有，正式网站则面向访客开放。
前期本地检查也没有只看构建结果。设计记录中保留了桌面、手机和横屏检查，以及草稿隐藏、发布后生成详情页、内部链接和资源引用的验证。能生成页面是一个起点，链接能点进去、图片能正常加载、手机菜单能用，才接近一个能交给别人看的网站。
再给它换上自己的域名
Vercel 的默认地址能用，但毕竟不太好记。我已经有一个托管在 Cloudflare 的域名 157139.xyz，于是又给作品集单独配了一个子域名：
这一步是在 Edge 里完成的。先到 Vercel 项目的 Production 环境添加域名，再根据它实际给出的要求，到 Cloudflare 配置 DNS。
当时新增的是这条记录：
| 项目 | 当时填写的值 |
|---|---|
| 类型 | CNAME |
| 名称 | aboutme |
| 目标 | 84513c0b96d531a4.vercel-dns-017.com |
| Cloudflare 代理状态 | 仅 DNS |
这个目标值是当时 Vercel 为该项目给出的配置，后续如果重新配置，仍应以控制台当前显示的要求为准。
刚添加域名时，Vercel 提示 DNS 配置无效。Cloudflare 保存记录之后，还经历了刷新验证和等待证书的过程。最终控制台显示 Valid Configuration，再用 Edge 打开新地址，确认加载的是自己的作品集页面。
做到这里，网站终于有了一个可以直接发给别人的入口。
最磨人的部分，反而是那条时间线
如果只看最后的页面，很难想到时间线来回改了这么多次。
最早遇到的问题是：手机显示没问题，电脑上的节点却会换行。我想让它在桌面从左到右排成一条，节点之间别空太多，放不下就横向浏览。
但我的要求还多了一层：页面滚到时间线时，要暂时停在这里。继续向下滚，推动时间线向右走，走到最后，页面再接着向下。
第一版把节点改成了单行，也让时间线固定住，再把页面向下滚动的距离映射成横向位移。方向基本对了，但下面的“关于我”和页脚仍然在往上移动。于是画面变成了：时间线停着，下方内容还在走。
接着的修改一度偏离了我的意思。它拦截滚轮，让滚轮输入只用于推动时间线。页面确实可以停住，但全局滚动条不再同步往下走。我希望整页的浏览过程仍然由全局滚动条控制，直接拖右边的滚动条，也应该能推进时间线。
所以又恢复了全局滚动驱动，再尝试给下方内容加位移补偿。这个办法在检查某几个位置时能对上，实际滚动时却仍然出现位移。另外，滚轮每次产生的距离直接映射到横向移动，也让时间线看起来一跳一跳的。
这里其实出现了两个不同的问题：横向移动需要平滑，下方内容需要稳定地固定。修好其中一个，并不意味着另一个也好了。
后面给横向移动加了短暂的平滑过渡，跳动改善了，但我继续看页面，发现下方仍然会移动。于是最后把结构重新整理了一次：把时间线、“关于我”和页脚放进同一个固定容器，让浏览器负责把这整个区域停住。
全局滚动条仍然正常向下推进。在这一段滚动距离内，整个区域保持位置，只有时间线的内容横向移动；走完整条时间线后，固定区域再一起恢复正常的页面滚动。
这种结构比对多个区块分别补偿位置更直接，也更贴近最初想要的效果。手机继续保留纵向时间线，不强行套用桌面的浏览方式。
最后一轮在四种电脑窗口尺寸下检查了时间线、“关于我”和页脚的位置，也覆盖了系统开启“减少动画”的情况。记录中的位置变化都控制在 1 像素以内，横向结束后可以恢复页面滚动；手机端和文章页的页脚也做了检查。
这段经历挺能说明网页交互的麻烦之处。同一句“滚到这里固定住”，可能被实现成好几种不同的行为。真正的验收标准，得看滚动时整张画面怎么变化，光看某一刻的截图还不够。
在线编辑接上之后，本地也得跟上
这个项目还有一个很实际的小插曲：有一次准备把时间线的修改推到 GitHub，推送被拒绝了。
原因是这段时间已经在 Pages CMS 里修改了不少内容。后台每次保存都会产生提交，远程仓库向前走了，本地还停在旧位置。取回记录后，发现远程已经多了 30 个提交。
处理时先保留本地这次代码改动，再把它整理到远程最新版本之上，最后重新推送。这样，后台编辑过的项目、证书和时间线都能留下，本地的新功能也能一起发布。
接入在线编辑以后，这件事就值得记住：GitHub 同时接收后台的内容修改和本地的代码修改。下次开始工作前，先同步远程，会省掉不少临到推送才发现版本不一致的麻烦。
到这里，它已经能承接后面的内容了
回头看，这次搭建并不是选个主题、放几张图片、部署一下就结束了。
前面花时间想清楚网站的定位和视觉，让它能表达我做项目的方向；中间把内容独立出来，再接上在线编辑和自动部署，让它能持续更新；后面用真实资料填充，再根据电脑和手机上的使用感受一点点修交互。
现在已经有了能展示项目和文章的页面、可编辑的内容、自己的域名，以及一条从保存内容到发布上线的流程。后面更值得投入的事情，是把项目背景、本人负责的部分、实现过程和实际结果慢慢写清楚，把演示内容继续换成自己的积累。
这次也让我对和 AI 一起做网页有了更具体的感受。它能帮忙出方案、写代码、配部署，也能快速完成很多重复工作；但“看起来差不多”和“就是我想要的感觉”之间，仍然需要反复指出具体差别。时间线就是最明显的一段：从能横向移动，到由全局滚动控制，再到下方真的保持原位，每一步都要在实际画面里确认。
网站已经有了一个可以慢慢添东西的地方。接下来，每做完一个项目、解决一个问题，都可以回来补上一点，让这个页面逐渐长成自己的样子。