文章目录
在第一章里，我写了这个空间怎样从一个念头，变成一个真正的网站。
第二章把它拆开，谈文章怎样发布，通知为什么要等待部署，数据怎样保留，以及一个个人博客为什么也需要认真面对失败和恢复。
写到那里，它已经不是只有几张页面的空架子了。
我可以写文章，读者可以阅读、评论、订阅；后台也有了管理内容和核对状态的地方。如果只按功能清单判断，似乎已经有足够多的理由，先停下来用一段时间。
但我还是会打开首页，看一会儿，然后觉得：哪里还差一点。
这次不是缺少某个按钮，也不是又想增加一种服务。
我开始在意的是，页面为什么还像一张放在那里的图；明明加了动画，为什么仍然没有什么感觉；换了一套看起来更讲究的设计，为什么反而不如原来。
这一章，记录的是网站能用以后，我怎样一点点判断，它到底应该怎样被使用、被看见，又怎样保留自己的样子。
事情主要发生在 2026 年 10 月 25 日。这不是一份全站改版教程，也不是上一轮工作的最终验收报告，而是这一阶段的体验复盘。
一、功能已经不少了，为什么还是觉得简陋
早期觉得网站简陋，解决办法很直接：加功能。
没有评论，就做评论；不方便找文章，就增加浏览、归档和标签；想知道有没有人看，就做阅读统计；不想错过更新，就做邮件订阅。
这些需求都真实，也都有自己的价值。
但功能逐渐齐了以后，“简陋”的感觉并没有自动消失。
有的入口孤零零地摆着，有的页面像是不同时间分别完成，再被放进同一个导航。单独看，每一处似乎都能说得过去；连着用，却不太像一个完整的空间。
更微妙的是，我已经很难把这种感觉转成一条准确的要求。
说“高级一点”，太空泛；说“动画再多一点”，又容易变成所有东西一起跳。指出某一个问题，还可以讨论间距和字号；如果不满意的是整页的气质，就没法只靠移动几个像素解决。
于是，我想借助一些更成体系的设计方法。
这也是两款设计 skill 进入项目的原因。
这里的 skill，可以理解为给 AI 开发过程使用的一组工作指引：怎样理解页面，怎样检查排版和交互，以及怎样避免把一个网站做成随处可见的模板。
它们不是一键换肤按钮，也不是装上以后，网站自然就会有品味。
但在当时，我确实期待，它们能帮我找到那种一直说不清的差距。
二、一次看起来更有设计感，却被我推翻的改版
我一开始给出的空间并不小。
可以主要依据这两款 skill，原来的设计也可以适当舍弃。先在本地做出来，我看完再决定，不直接上线。
第一版出来以后，我的反应很直接：
好丑啊，还不如以前呢。
现在回头看，这句话并不意味着那一版什么都没有做好。
它有更明确的版式，有重新组织过的块面，也试图让页面更像经过设计的作品。问题是，它开始离我原本想保留的东西越来越远。
我原来喜欢的居中首屏、熟悉的配色、文章封面，以及那个属于这个空间的轻松感，换成了一种更偏目录和刊物的秩序。
它可以是另一种网站，却不太像 Henry 的空间。
这让我第一次非常明确地区分了两件事：
一个设计符合某套方法，不等于它适合这个项目。
我不是没有设计过的空白页面，也不是只需要一张漂亮截图。这个网站已经有自己的内容，有用顺手的地方，也有我不想失去的辨识度。
如果所谓升级，要先让我觉得这个地方不再是我的，那么这次升级就需要重新判断。
于是，方向被改回来了：以原版为基调，不再重做整个视觉世界，把两款 skill 用在交互、动效、可读性和细节校准上。
被否定的那一版没有上线。
它也不算白做。至少，我终于把之前模糊的要求说清楚了一点：
我要的不是换一个看起来更专业的网站，而是让现在这个网站，更像它本来应该有的样子。
三、“再克制一点”，并不是这次的答案
恢复原版以后，最初一轮动效依然很轻。
轻到我打开页面，没有看出和原来有什么明显区别。
我接着问，能不能加多一点，为什么总是不敢加。
再往后，要求又变成了：还可以更大胆一点，不要只做简单的分段上升和错峰进入，我想让整个前台有活感。
这听起来，似乎和前面几章里放弃持续动态背景的决定矛盾。
其实，我想放弃的并不是动效。
我不喜欢的是：页面打开以后，背景一直在忙；色块来回走，设备持续发热，真正想读的内容却没有因此更好读。
而这次，我想要的是另一种感觉：
打开页面，内容有一个完整的出场；移动鼠标，封面会根据靠近的位置作出回应；切换分类，选中状态不是突然换一块颜色；准备订阅时，输入框能轻轻提醒一下自己的存在。
它们都和正在发生的动作有关。
所以，这轮没有继续沿用“越弱越安全”的答案。
首页的开场被放慢、放大，文字和封面有了各自展开的过程。其他页面的大标题也不再只是整块出现。精选、友链、标签和页脚，开始有一些能感知到的回应。
但页面框架不应该跟着一起收缩、晃动，正文也不应该等待一场表演结束才允许阅读。
我想要的活感，逐渐变得具体了：
不是让所有东西一直动，而是让我感觉，自己正在和这个页面发生关系。
四、动起来并不难，动得像那么回事才难
这一阶段最有意思的地方，是许多反馈都没法只用“有动画”或“没动画”回答。
同一个效果，方向、起点、速度和收尾稍微不同，感觉就会完全不一样。
标题应该长出来，而不是翻上来
除了首页，我希望其他页面的大标题，包括文章标题，都有一种从左往右，按顺序从下方长出来的感觉。
第一版看到了，但我觉得它更像从后面翻上来。
两者在描述里可能只差几个字，实际看起来却不是同一件事。
翻上来，会让人注意到字形在变形，像一片片东西转向自己；向上长出来，应该是字本身保持稳定，只是逐渐越过下方那条看不见的边界。
后来的调整，就是把这个差别真的落实到效果里。
非首页的标题不再压扁，也不再翻转，而是让文字保持直立，依次从下方升出来。英文单词、标点和换行也要正常，不能为了逐字动效，把标题本身拆得不好读。
这次修改让我意识到，我不一定需要先知道实现方式，但必须敢于指出：它和我想要的感受不是一回事。
按钮不是都往上跳一下，就算有了反馈
订阅按钮、页脚入口和标签，最初的反馈比较相似：鼠标放上去，轻轻跳一下。
单独试一个，不算有问题；整站到处都这样，就会显得单调。
我开始想要一种吸附感。
不是鼠标把按钮拖走，而是靠近不同位置时，按钮能轻微迎向指针；离开以后，再自然归位。
友链卡片则希望像首页精选封面一样，有一点随着指针变化的立体感。
投影也需要跟上。只有倾斜，没有让人相信它浮起来的层次，卡片就像是在原地扭动；投影过重，又会和原来干净的页面不协调。
这些效果不需要出现在阅读正文上。读者正在读一段文字时，我更希望文字安静地待在那里。
箭头往右上指，为什么悬停时却向下沉
“浏览全部文章”的箭头指向右上方，鼠标放上去，却出现了向下的运动。
这个错误不大，却很容易让人觉得别扭。
它提醒我的，是反馈也有自己的语义：一个表示去往其他页面的箭头，不应该沿用“向下看”的动作；真正指向下方内容的入口，才适合向下回应。
不是每个元素都需要特殊设计，但同一套反馈也不能不看含义，到处套用。
后来，404 页面返回按钮的箭头又被我发现明显偏上。
它本身已经是对称图形，真正影响观感的是图标和按钮文字没有正确居中对齐。问题不在箭头画错，而在它被放进去的方式。
这两件小事放在一起，让我觉得，所谓细节不是越做越复杂，而是不要让简单的东西互相打架。
五、订阅区域：我只想要一圈呼吸灯
订阅区域的修改，是这轮最能说明“有了”不等于“对了”的例子。
我希望“订阅新文章”能更吸引读者一点，有呼吸感，而不是一块一直安静放在页面底部的表单。
最初的提示不够明显，我没有看出来。
后来，把信封提示做得更显眼，又变成一个我不喜欢的圆形装饰。
我的反馈依然很直接：这个呼吸太丑了，不要这种，就在输入框做一圈呼吸灯。
到这里，需求终于具体起来了。
不是让整张卡片缩放，不是让标题闪动，也不是再加一个悬着的圆圈。邮箱输入框还是原来的位置和大小，只让边缘有一层缓缓明暗变化的光。
随后，我又希望它呼吸得快一点。
最终留下来的，是输入框边缘的有限提示：进入视野以后呼吸几次，开始输入、聚焦或者按下以后就停止，不在读者已经准备操作时继续争夺注意力。
这段反复，让我对“吸引注意”有了另一种理解。
它不是证明这里值得放一个更大的装饰，而是帮助读者在合适的时候，发现一个原本就有价值的动作。
表单需要让人愿意开始，不需要一直告诉别人，我正在做动画。
六、想大胆一点，也不能把风扇问题带回来
动效逐渐明显以后，之前的性能教训没有失效。
我已经经历过网站打开一会儿，电脑发热、风扇转起来的阶段，不想为了这一轮活感，再回到那个问题里。
所以，这次留下来的效果，需要有自己的边界。
开场会结束，输入框的呼吸会结束；按钮和卡片在交互时回应，离开以后归位；离开页面或者切到后台，不再继续维持已经没有意义的工作。
手机上没有鼠标，也不能假装有一个指针在那里。偏好减少动态效果的人，则应该能直接看到完整、稳定的内容。
这些要求说起来不如“再大胆一点”有画面感，却决定了大胆能不能长期留下来。
有些地方，问题甚至不只是效果强弱。
比如，源码里写了滚动联动，不代表构建后的浏览器里真的在运行；有动画名称，也不代表实际计算出来的效果就是预期。
这一轮确实遇到过这样的落差，需要回到最终页面里看，而不是仅凭“代码已经加上”就宣布完成。
对我来说，这也修正了一个容易出现的误解：
有测试和检查，不等于我就可以不看实际效果；我觉得顺眼，也不等于所有设备都已经通过验证。
模拟不同屏幕、核对浅深色、检查减少动态效果，都有意义，但不是所有手机和平板的长期使用结论。
这一章里，我愿意说这一轮终于更接近自己想要的感觉，不愿意把它写成“动效和性能从此都完美了”。
七、三万多行代码，为什么不能直接塞进一个角落
后来，我希望在开发日记页加上一个信息：这个项目一共写了多少行代码。
它有一点纪念意味。
最开始只有几页网页，后来文章、评论、订阅、后台、邮件和测试逐渐长出来。我想让日记页不只记录发生过什么，也能看见这个项目当前的体量。
按这一阶段使用的统计口径，收尾时是 33,859 行非空源码，245 个文件。
这里统计了维护中的代码与测试，非空行包含注释；文章、依赖、构建产物和重复生成的入口不算在里面。它不是我逐行手写的数量，也不是网站质量的评分。
但是，数字算对，并不意味着需求已经做好。
第一次把它加到页面上时，右侧的统计卡片把版面撑高了，左右关系变得不协调。
我的感受就是：怎么把这个信息硬塞进来了？
后来重新整理，才把标题、介绍和统计分成更自然的层次。提交、里程碑、开发日和源码行数放到同一条通栏里，统计口径则留在可以展开查看的说明中。
读者先看到的是开发日记，不是一块突然挤进来的代码仪表盘。
这个小改动对我很有提醒。
在 AI 辅助开发里，一条需求经常能很快被翻译成一个可见结果。“加上代码行数”，很快就能出现数字和卡片。
但我真正需要的，从来不只是那个数字存在。
我需要它在这里出现得合理，不打断原来的阅读顺序，也不让页面为了满足一条新要求，失去整体关系。
实现一条需求，和把它融进产品，是两件不同的工作。
八、构建成功了，为什么列表还说失败
就在这一轮收尾时，一个熟悉的问题又出现了。
第一章第一次构建失败，第二次已经成功，发布记录也能看到成功，但文章列表里仍然写着构建失败。
如果只看前台，这篇文章已经在那里了。
如果只看发布记录，这次任务也已经有了结果。
但我平时最容易看到的那个文章列表，给出的却是另一种答案。
第二章已经谈过发布链路，这里不再重复技术细节。我更想记下的是，站在使用者的位置，这种不一致会怎样影响判断。
我不知道该相信哪里，也不知道要不要再发布一次。再漂亮的进度条，在这种情况下都很难让人安心。
这次排查发现，旧的失败状态没有被重新核实；成功提示关闭后，之前保留的旧记录还可能再次把失败带回来。
修复的方向不是删除失败历史，也不是把这一篇的文字直接改成成功，而是让当前状态依据同一篇文章的实际版本和构建尝试重新对齐，不再被过时结果覆盖。
这项修复已经随这一阶段发布，但我仍然要区分两件事：隔离检查验证了哪些状态变化，作者实际登录后台以后是否已经逐条验收。
不能为了写一个圆满的结尾，把后者也默认算上。
这个问题放在一篇讨论动效与体验的文章里，并不跑题。
体验不只包括好不好看，还包括这个页面说的话，我能不能相信。
一个正确的失败提示，有时比一个漂亮的成功动画更有价值；已经成功以后，界面也应该允许这件事真正结束，而不是让旧失败一直留在那里。
九、我开始学着提出感受，而不只是追加功能
回头看，这一轮有很多反馈并不专业。
“太丑了。”
“看不出区别。”
“像翻上来，不是长出来。”
“三个东西硬放进去，左右不协调。”
这些话如果只截出来，像是在不停否定已经做好的工作。
但它们也是一个过程：我开始把自己的真实感受说出来，再一点点找出它对应的原因。
原来喜欢什么，不是只能在改坏以后才发现；觉得哪里不舒服，也不需要先掌握完整的设计术语，才有资格要求调整。
当然，感受不能自动代替判断。
我可以说想更大胆，却仍然需要看它是否挡住内容；可以说要更有吸附感，却不能让按钮为了追鼠标而难以点击；可以希望订阅更醒目，也要接受读者开始输入以后，它就应该安静下来。
这一点，也改变了我对 AI 协作的期待。
AI 能加快从描述到页面的距离，能帮我尝试原来不容易亲手做出来的东西，也能配合工具检查许多细节。
但它不会自动知道，哪一版更像我的空间。
两款 skill 可以提供方法，不能替我决定要保留什么；实现可以越来越快，选择却仍然需要我打开页面、实际使用、明确否定，再看一次。
这不是给 AI 一个更长的提示词，就能彻底省掉的部分。
十、第三章结束时，它更像一个有人在使用的地方
这一阶段结束，Henry 的空间没有更换主题，也没有因为一次改版，把过去的文章、评论和订阅关系重新来过。
原来的身份还在：Henry 的空间，熟悉的封面，浅色和深色，以及首页那句“保持好奇 無限进步”。
改变的是，页面开始更认真地回应正在发生的事情。
进入时有开场，靠近时有反馈，选择之间有衔接；该读文字的时候安静下来，已经做完的事情也能够收尾。
我不想把这些变化说成一个质的飞跃。
它们大多很小，甚至有些地方，只有改错以后才会注意到。但当这些小关系慢慢对上，网站就不再那么像一组分别完成的页面。
它开始更像一个有人使用、有人维护，也有人愿意反复回来坐一会儿的地方。
如果说第一章是把网站做出来，第二章是让它值得继续维护，那么第三章更像是在回答：
系统已经能够运转以后，我还愿不愿意亲自走进来，看看它怎样对待每一次阅读和每一个动作。
现在，我比之前更愿意。
至于后面还会改成什么样，我暂时没有一份新的大清单。
有些地方还需要真实使用来判断。有些效果看久了，也许又会想拿掉。重要的不是把这一轮当作终点，而是保留继续调整的余地，也记住哪些路已经试过，为什么最后没有走下去。
第三章，先记到这里。
让空间活起来，不是让每一处都动起来，而是让每一处的回应，都有它的理由。
保持好奇，無限进步。
开源项目与第三方组件声明
本章记录的是 Henry 的空间的实际开发与取舍。以下分别说明这一阶段涉及的设计工具、网站基础项目和第三方服务；不把上游方法、代码或工具归为本站原创。
Taste Skill
- 项目：Taste Skill，本阶段使用其中的
design-taste-frontend - 原作者与维护者：Leonxlnx 及项目贡献者
- 上游仓库：Leonxlnx/taste-skill
- 许可证：MIT License
- 本阶段用途：为页面审视、视觉一致性、交互与动效检查提供工作指引。它是开发过程中使用的工具与参考，不是本站前台额外引入的一套运行时框架。
- 说明：本章提到的改版尝试及其取舍，是本站在具体使用中的结果，不代表上游作者对本站方案作出认可或保证。
Impeccable
- 项目：Impeccable
- 原作者与维护者：Paul Bakaus 及项目贡献者
- 上游仓库：pbakaus/impeccable
- 许可证：Apache License 2.0
- 本阶段用途：辅助梳理产品与设计约束，检查交互、动效、可访问性及界面细节。
- 说明：工具反馈用于辅助判断，不等同于作者验收，也不意味着本站已经完成所有设备、长期性能或全部可访问性场景的验证。
Astro 及官方集成
- 项目：Astro、
@astrojs/rss、@astrojs/sitemap - 原作者与维护者：Fred K. Schott、Astro 团队及贡献者
- 上游仓库：withastro/astro
- 许可证：MIT License
- 用途：本站页面、文章内容、RSS 与站点地图等基础能力。本轮在既有项目上调整展示与交互，没有另行迁移前台框架。
既有组件与开发工具
本阶段沿用的站点还使用了以下项目。这里分别保留出处，不把它们合并为同一种许可证：
- Marked：Christopher Jeffrey、MarkedJS 团队及贡献者维护；markedjs/marked；MIT License 及随附声明。用于后台 Markdown 解析与预览。
- Turndown：Dom Christie 与贡献者维护；mixmark-io/turndown；MIT License。用于衔接可视化编辑内容与 Markdown。
- js-yaml：Vitaly Puzrin、Nodeca 及贡献者维护；nodeca/js-yaml；MIT License。用于构建链中的文章元信息解析。
- resvg-js：项目维护者与贡献者维护；thx/resvg-js；MPL-2.0。用于 SVG 到位图的构建工具。
- Node.js：Node.js 项目维护者与贡献者维护；nodejs/node；核心采用 MIT，第三方组件另有声明，见官方 LICENSE。用于构建与测试。
- Python：Python Software Foundation 与贡献者维护；python.org；主要采用 PSF License Version 2。用于部署保护、备份核验与恢复相关自动化。
- Git：Git 项目维护者与贡献者维护；git/git；GPL-2.0。用于版本与文章历史管理。
这份声明不是完整的软件物料清单。具体版本与授权义务，以实际使用版本、项目锁文件及各组件随附许可证为准。
Cloudflare、GitHub 与 Resend
- 服务及提供方：Cloudflare；GitHub 与 GitHub Actions；Resend。
- 官方出处：Cloudflare、GitHub Actions 文档、Resend 文档。
- 用途：分别支持网站托管与动态服务、版本和部署流程，以及邮件验证与通知。
- 说明：这些是第三方平台与服务，不是本站原创的开源组件。相关费用、配额、服务条款及各 Action 的许可证，应按各自实际规则区分，本章不作额外保证。
浏览器能力与设计参考
本轮局部动效与交互建立在浏览器原生 HTML、CSS 和 JavaScript 能力之上；使用平台能力，不意味着这些能力由本站发明，也不意味着不同浏览器的表现天然一致。
视觉仍参考 Apple 产品中的留白、层次与交互秩序。本站不是 Apple 官方产品，与 Apple 不存在官方隶属或背书关系；相关商标与权利归各自权利人所有。
项目自身与 AI 协作
Henry 的空间由 Henry 发起并持续维护，开发与本文整理过程中使用 OpenAI Codex 辅助。本章中的实际反馈、方向选择和最终取舍来自这个项目的使用过程；AI 与设计工具不改变上游作者的权利，也不代替事实核对。
截至本文整理时，本站源码仓库为私有，尚未为整个项目额外声明开源许可证。使用开源项目，不等于整站代码、文章和素材已经开放再分发。
本文不包含后台密码、访问令牌、备份密钥或访客个人数据。
项目与本文署名：Henry。记录截至 2026 年 10 月 25 日。
评论 0
留下想法或补充。评论经审核后会显示在这里。
正在读取评论…
成为第一个留下想法的人。