朝朝听雨

自动上架系统：为跨境电商打造的高端批量发布中枢

Thu, 09 Jul 2026 00:00:00 GMT

项目定位#

自动上架系统不是一个简单的“点按钮脚本”，而是一套面向跨境电商运营场景设计的批量发布中枢。它把 Excel 表格、产品图库、视频素材、AI 标题生成、BigSeller 页面操作、店铺状态确认和运行历史记录串成一条完整链路，让重复、易错、耗时的上架工作变成可配置、可监控、可复盘的产品化流程。

目前系统已经落地到两个核心店铺/平台方向：Shopee 和 TikTok Shop。它们分别拥有独立 Worker、独立运行状态、独立日志和发布策略，能够针对不同平台的页面结构、编辑入口、保存逻辑和成功判定做定制处理。这个基础非常重要，因为真正的电商自动化从来不是“一套流程跑天下”，而是要让每个平台的差异被系统吸收，让运营人员面对的是统一、稳定、清晰的控制台。

自动上架系统控制台

已实现能力#

系统当前以 BigSeller 为核心操作入口，通过内置 Chromium 与 Playwright 自动化完成商品编辑、素材上传、标题生成、变体校验和最终发布。运营人员只需要准备表格和素材，系统就能按照预设模板把复杂步骤拆解执行。

它已经覆盖了批量上架中最容易出错的环节：自动搜索商品、进入编辑页、删除旧图、上传主图和详情图、上传视频、绑定变体图、生成或拼接商品标题、发布前截图留档、成功后关闭页面，并把每一次运行沉淀为历史记录。

任务运行面板

模板化：把经验变成配置#

平板套是当前最成熟的应用场景。系统内置了多套产品模板，例如 360 旋转壳、3Y 折叠壳、书本式保护壳、笔槽款、通用品牌模板等，并按品牌维护图片组、主图序号、变体图序号、AI 分析图片、视频策略、标题结构和机型关键词。

这意味着系统并不是把某一次上架动作写死，而是把“运营经验”沉淀成可调整的模板。今天它可以服务平板保护套，明天也可以扩展到手机壳、配件、家居小商品、数码周边、服饰配件，甚至任何存在规律化素材和规格组合的产品线。

模板配置

AI 标题：让批量发布更像精细运营#

系统接入 AI 标题生成能力，可以根据图片内容和模板规则生成更适合平台展示的英文标题。它不仅能做固定标题拼接，也支持 AI 分析图片、随机重排品牌和机型关键词、按平台字符限制控制输出。

这部分的价值不只是“省时间”，更重要的是让批量上架保持足够的内容差异和商品表达质量。对高 SKU、高频发布的跨境店铺来说，标题质量、关键词覆盖和可读性会直接影响商品点击、搜索曝光和后续转化。

AI 与标题配置

运行可视化：自动化必须可控#

一个高端自动化产品，不能只追求“跑得快”，还要让人知道它正在做什么、做到哪里、哪里可能有风险。这个系统提供实时日志、运行状态、暂停/恢复、店铺信息确认、截图留档、历史记录和 Token 消耗监控。

当任务进入高风险步骤，例如上传素材、匹配变体、发布商品之前，系统会保留关键过程信息，让运营人员可以追踪问题，而不是等任务失败后只看到一个模糊结果。

实时运行状态

双平台基础：Shopee 与 TikTok Shop#

目前已经实现的两个店铺/平台方向是 Shopee 和 TikTok Shop。Shopee 侧更强调 BigSeller 商品列表、编辑页、素材上传和“保存并发布”的完整链路；TikTok Shop 侧则针对 TK 页面入口、表格起始行、编辑按钮、更新按钮和成功判断做了独立适配。

两条链路共用系统级能力，例如配置中心、内置浏览器、素材管理、历史记录、截图、AI 标题、SSE 日志流，同时保留平台差异化逻辑。这种设计让后续扩展更自然：新增平台不需要推倒重来，而是在统一底座上接入新的 Worker、页面策略和模板规则。

Shopee 与 TikTok Shop 工作区

周边工具：从上架延伸到运营维护#

围绕上架主流程，系统还加入了批量上传表格、批量添加新型号、批量开启折扣、清空素材中心、视频中心、截图中心、历史海报等工具。这些功能看起来像“小工具”，实际是电商运营每天都会碰到的高频维护动作。

把这些动作统一在同一个系统里，能够减少来回切换工具、手动复制路径、重复打开页面带来的损耗，也让自动化从“单点功能”升级成“运营工作台”。

批量工具

可定制方向#

这套系统最有价值的地方，是它具备继续定制的空间。平板套只是第一个成熟行业模板，未来可以沿着三个方向继续升级。

第一是产品线定制。不同品类的 SKU 结构、图片规则、标题逻辑和规格字段不同，系统可以为手机壳、耳机配件、电脑包、服饰配件、家居百货等产品建立独立模板，把每个行业的上架经验沉淀成可复用模块。

第二是平台定制。除了 Shopee 和 TikTok Shop，后续可以继续接入 Lazada、Tokopedia、Shopify、WooCommerce、Amazon Seller、Temu 或本地化 ERP 后台。平台变化并不影响系统的核心价值：统一素材、统一配置、统一状态、统一历史，再用平台适配层处理差异。

第三是运营策略定制。未来可以继续加入标题 A/B 策略、价格与库存联动、自动翻译、多语言标题、违禁词检测、图片合规检查、店铺维度权限、任务队列调度、失败重试策略和团队协作审计。

历史记录与复盘

产品愿景#

自动上架系统最终要打造的，不只是一个能替人点击页面的工具，而是一个可以交付给高强度跨境团队使用的专业产品：稳定、清晰、可扩展、可复盘，并且能跟着业务一起长大。

当平台变多、产品变多、店铺变多、素材变多，真正稀缺的不是单次操作速度，而是流程标准化能力。这个系统的方向，就是把复杂运营流程装进一个可靠的中枢里，让团队把精力放回选品、素材、定价和增长，而不是反复消耗在机械上架上。

系统总览

从母系社会到父权制度：亲缘、私有制与现代性别关系的演变(浅谈男女对立)

Thu, 20 Aug 2026 00:00:00 GMT

最近网络上的声音很大，男女对立也很严重，本期我们不站队任何一方，只从历史的角度去看待客观事实。再次叠甲，“男女对立是阶级矛盾转移”的观点认为，社会中的一些性别冲突，表面上表现为男性与女性之间的利益冲突，但深层可能与经济结构、资源分配和阶层差异有关。例如，住房、就业、生育、教育等压力，本质上可能来自社会资源分配问题，却容易被转化为男女之间的相互指责。上层或既有利益结构在这种理论中被认为可能通过强化身份矛盾，让普通群体内部产生分裂，从而弱化对更深层经济问题的关注。不过，这并不意味着所有性别问题都是阶级矛盾造成的，现实中的性别不平等也有其独立存在的原因，二者往往是相互交织的。再次声明，本站文章仅代表本站观点，若你不认可我的观点尽可离去并举报，如果你的观点能打动我，我会与你辩论，如果没有我会觉得你很无知并永久拉黑。

引言：社会制度并非天然存在#

很多人会思考一个问题：

为什么现代社会大多数文明都形成了父姓制度？

为什么子女通常随父姓，而不是随母姓？

为什么人类历史上出现了从母系亲属结构向父系社会结构的转变？

进一步来说，为什么今天女性开始获得越来越多的社会权利，而与此同时，许多普通男性也开始感受到来自传统性别结构的压力？

这些问题表面上讨论的是男女关系，实际上背后涉及的是更深层的社会逻辑：

亲缘确认、生产方式、财产继承以及社会结构的变化。

很多制度并不是某一个群体单纯设计出来的，而是在特定生产条件下，为了解决现实问题而逐渐形成的。

一、为什么父姓制度会成为许多文明的选择？#

母亲拥有天然确定的血缘关系#

从生理意义上来说，母亲对于孩子的血缘关系具有天然确定性。

女性经历：

怀孕；
分娩；
哺育。

因此，一个母亲可以百分百确认：

这个孩子属于自己的血脉。

这种确定性，使母系亲缘关系天然具有稳定基础。

父系血缘为什么需要社会制度确认？#

相比之下，父亲的血缘关系在生理层面并不存在同等程度的确定性。

男性无法通过自身身体直接确认：

这个孩子是否一定拥有自己的血缘。

这也是为什么在人类社会发展过程中，围绕父系血缘逐渐产生了一系列社会制度：

从父姓；
婚姻制度；
宗族体系；
财产继承规则。

这些制度的核心作用之一，就是加强父系血缘的社会确认。

换句话说：

生理上无法完全确认的父系关系，需要通过社会制度进行确认。

二、姓氏制度不仅是身份问题，也是亲缘识别系统#

很多人认为姓氏只是一个称呼。

但在传统社会中，姓氏承担着更加重要的功能：

第一，确认家族归属#

同一个姓氏意味着：

共同祖先；
共同宗族；
共同继承关系。

在传统农业社会中，这对于土地、财富和权力传递非常重要。

第二，帮助社会识别婚姻关系#

如果所有亲属都按照母系姓氏传承，那么一些亲缘关系可能隐藏在同姓体系中。

而父姓制度，使父系宗族更加清晰。

传统宗族中的祠堂、族谱，并不仅仅是财富继承工具，它实际上也是一种社会组织系统。

它解决的问题包括：

谁属于这个家族；
谁拥有继承资格；
哪些人之间不能通婚。

三、为什么许多母系社会中出现较弱的婚姻绑定？#

这里需要明确：

母系社会并不等于女性统治社会，也不意味着所有母系社会都采用同一种婚姻模式。

但在人类学研究中，可以发现，一些母系亲属社会中存在较弱化的婚姻绑定结构。

原因并非简单来自道德观念，而是来自亲缘确认逻辑。

当父亲身份无法被确认时，男性投入模式会发生变化#

在一些母系社会中，与孩子长期共同生活并承担抚育责任的男性，并不一定是生父，而可能是母亲一方的兄弟，也就是舅舅。

原因在于：

舅舅可以确认：

这个孩子一定属于自己母系家族的血缘。

而生父无法获得同等程度的确定。

因此，在这样的社会结构中，母系亲缘关系更加稳定。

父亲角色的社会意义与制度有关#

当社会无法建立稳定的父系确认机制时，对于父亲身份的制度需求自然较低。

而当社会进入私有财产积累阶段后，情况开始改变。

四、农业革命如何推动父系制度形成？#

人类早期社会主要依靠：

采集；
狩猎；
群体共享资源。

这一时期，私人财富积累有限。

但农业时代出现后，人类社会发生重大变化。

土地和财富改变了社会逻辑#

农业生产带来了：

土地；
牲畜；
粮食储备；
私人财产。

当财富开始积累，一个新的问题出现：

财产应该传给谁？

母亲当然可以确认自己的孩子。

但是男性如果希望自己的财富传递给自己的直系后代，就需要解决父系血缘确认问题。

于是：

1
私有财产出现
2
        ↓
3
需要确定继承人
4
        ↓
5
加强父系血缘确认
6
        ↓
7
发展姓氏、婚姻、宗族制度

五、父权制度并非单纯来自男性意志，而是生产结构的结果#

很多社会制度不能简单理解为：

“某个群体压迫另一个群体”。

更准确地说：

制度往往是生产方式和现实需求共同塑造的结果。

农业文明时期：

体力是重要生产力；
战争依赖身体力量；
土地开发依赖大量劳动力。

由于生育和哺育成本，女性平均承担更多家庭照护限制。

而男性平均具有更强的体力优势。

于是：

1
农业生产
2
+
3
体力竞争
4
+
5
私有财产继承
6
=
7
父系制度强化

六、为什么现代社会正在改变传统性别结构？#

工业革命以后，人类社会进入新的阶段。

现代社会越来越依赖：

知识；
技术；
教育；
管理；
沟通能力。

生产力的核心逐渐从体力转向脑力。

这意味着：

过去男性占优势的部分，正在减少。

女性在：

教育；
商业；
科技；
医疗；
管理；

等领域拥有越来越多的发展空间。

这并不是简单来源于思想变化，而是生产方式变化带来的结果。

七、女性解放与生产力变化#

恩格斯曾提出：

女性解放与社会生产方式变化密切相关。

这一观点的核心逻辑是：

旧社会中的性别关系，与私有制、家庭结构和社会等级体系存在联系。

当生产方式变化，旧有结构自然会受到挑战。

过去：

1
体力生产
2
        ↓
3
男性优势
4
        ↓
5
传统父权结构

现代：

1
知识生产
2
        ↓
3
性别差异降低
4
        ↓
5
新的社会关系形成

八、父权制度不仅影响女性，也影响普通男性#

讨论父权制度时，很多人首先想到女性受到限制。

但另一方面，传统父权结构也给男性塑造了大量责任要求。

尤其对于普通男性而言，父权社会给予的更多是一种责任期待，而不一定是真正的权力。

第一层压力：必须成功#

传统观念告诉男性：

要成家；
要立业；
要承担家庭责任。

成功似乎成为男性价值的重要证明。

但现实中，并不是所有男性都能获得与责任匹配的资源。

第二层压力：婚姻成为社会评价体系#

在传统观念中：

结婚不仅是一种情感选择，也被赋予了成功象征。

男性往往被期待：

买房；
提供稳定收入；
承担家庭经济责任。

婚姻因此不仅成为情感关系，也成为一种社会压力。

第三层压力：责任感被无限扩大#

责任本身并没有问题。

问题在于：

如果一个人需要承担所有责任，却缺少对应的支持和选择空间，那么责任就可能变成压力。

对于普通男性而言，传统父权结构有时意味着：

需要承担“家庭支柱”的角色，却未必拥有真正的社会资源和权力。

九、真正的问题不是男女，而是旧制度留下的压力#

父权制度并不是简单的：

“男性获益，女性受害”。

它更像是一套等级结构：

女性可能受到角色限制；
普通男性可能承担过度责任；
少数掌握资源的人获得更多优势。

因此，真正需要被反思的，并不是某一个性别，而是：

一个社会是否能够让每个人拥有更自由、更平等的发展空间。

十、从历史角度看，人类正在进入新的阶段#

回顾整个人类社会：

原始社会阶段#

生产力较低：

财富有限；
血缘以母系确认更加稳定。

农业社会阶段#

私有财产出现：

继承需求增强；
父系制度发展；
宗族结构强化。

工业与信息社会阶段#

生产方式变化：

体力不再决定全部价值；
男女能力差异进一步缩小；
传统性别结构开始调整。

结语：制度会随着生产力变化而变化#

人类历史并不是简单的男女对立史。

更多时候，它是一部：

人类不断调整社会制度，以适应新的生产方式和生活需求的历史。

从母系亲缘结构，到父系宗族体系，再到现代社会对性别关系的重新探索。

其中变化的并不仅仅是男女地位，而是整个社会组织方式。

未来社会会走向哪里，没有人可以完全预测。

但可以确定的是：

当生产力、经济结构和人的认知不断变化时，旧有制度也会不断被重新审视。

历史不会停留在过去。

它会继续寻找新的平衡。

我回望青春时，我的青春是最昂贵的；我正值青春时，我的青春是最廉价的。

Mon, 17 Aug 2026 00:00:00 GMT

后来才知道，真正舍不得的是日子#

有些年份，人在其中时并不觉得有什么特别。

天照常亮，铃照常响，黑板上的粉笔字一层叠着一层。夏天从窗外吹进来的风是热的，冬天走廊尽头总灌着冷气。我们每天抱着书，从一间教室走到另一间教室，嫌课间太短，嫌晚自习太长，嫌考试太多，也嫌日子过得太慢。

那时候谁也不会想到，许多年以后，真正舍不得的，偏偏就是这些曾经觉得漫长的日子。

我也是后来才知道——

原来青春在拥有的时候，几乎一文不值。

而一旦失去，便再也无从估价。

2020 年的秋天#

我记得2020年的秋天。

其实已经记不清那年秋天究竟冷得早不早，也记不得开学那天穿的是什么衣服，只记得教学楼的走廊很长，课间总有人聚在那里。

后来不知道是谁带来了毽子。

一群人便围成一个并不好看的圈。

毽子从这个人的脚尖飞到另一个人的肩头，踢歪了便笑，掉在地上就弯腰去捡。上课铃一响，众人作鸟兽散，踩着铃声往教室里跑。

现在想来，那实在算不得什么值得记住的事情。

可偏偏很多年以后，大考的题目忘了，名次忘了，老师说过的话也忘得七七八八，我却还能想起那只毽子在半空里打着旋。

大概记忆本来就不讲道理。

重要的事未必留下，真正留下来的，反倒总是一些无用的东西。

比如一阵风。

一句玩笑。

一个人在走廊上回过头来的样子。

又或者，是放学时天边那一点将暗未暗的光。

十六七岁的时间太多了#

刚上高中的时候，我似乎还算一个意气很盛的人。

做班长，第一次月考数学考了141，年级第一。

少年人大抵都这样。

只凭一次考得不错，便觉得前路也不过如此。

那时的我从不真正害怕时间。

一道题今天不会，还有明天；一次考试失手，还有下一次；一句话今天没说出口，也总觉得往后还有机会。

我们对“以后”有一种近乎盲目的信任。

仿佛它是一条很长很长的路，无论今天停在哪里，明天起来，总还能接着走。

所以时间在那时候很便宜。

一个课间可以拿来踢毽子。

一个晚自习可以偷偷玩五子棋。

一个周末，可以几个人抱着手机，一局接一局地打游戏。

输了便再开。

赢了便笑。

谁也不会觉得几个小时过去了有什么可惜。

因为十六七岁的时间太多了。

多得让人误以为，它永远不会见底。

屏幕背后的那些晚上#

后来有一段时间，我很喜欢露娜。

月下不停地穿来穿去，一次断大便足够让人懊恼半天。

现在偶尔翻到那些旧截图，已经很难再理解当时为什么会为了一个MVP高兴那么久。

但我仍然舍不得删。

倒不是怀念游戏。

我只是舍不得屏幕背后的那些晚上。

那时候有人喊一句“上号”，几个人就真的都在。

没有人要提前约时间，也没有人会在打到一半时说自己明天还有会议。

那个年纪，人的世界很小。

一间教室。

一个操场。

几个人。

一部手机。

就足够盛下整个夜晚。

一段王者荣耀的画面，放在这里，作为那些一起开黑、一起把夜晚打发掉的回声。

在哔哩哔哩打开这段视频 ↗

后来世界变大了，认识的人多了，能去的地方也多了。

反倒越来越难凑齐当年的那几个人。

于是才明白，人这一生最奇怪的地方，大概就是：

总在拥有很少的时候，觉得自己什么也没有；

等后来真的拥有了许多，才开始怀念曾经那一点点东西。

那时的我站在操场#

再后来，我去了操场。

成了体育生。

黄昏从此有了另一种样子。

放学铃响以后，别人往教室走，我往跑道走。

夏天的塑胶跑道晒过一天，热气还伏在上面。跑起来的时候风从耳边过去，汗一点点把衣服浸透。冬天则冷，呼出来的气在眼前散掉，手指僵着，连热身都觉得漫长。

那时候我并不喜欢这些。

累就是累。

疼就是疼。

训练结束时，满脑子只剩下吃饭、洗澡、回教室。

可如今再想起来，那些傍晚竟比很多后来精心安排过的旅行还要清楚。

我记得训练结束以后，天往往还剩一点光。

操场上的人没有完全散。

远处教学楼已经亮起了灯。

有人从食堂方向往回走。

风把树吹得轻轻响。

那时的我站在那里，不会觉得这一幕有什么值得留恋。

我只想着，晚自习快开始了。

可如今让我再回去一次，我大概会站得久一点。

不会急着走。

也不会急着把那天过完。

喜欢一个人，其实是很轻的事情#

青春里当然也有喜欢的人。

只是现在再回望，我已经很难把它单独从那些岁月里剥离出来。

喜欢一个人，其实是很轻的事情。

轻得像上课时回头看的一眼。

像故意调近一点的座位。

像晚自习前那十几分钟。

像训练结束以后，明明一身汗，还想先去见一面。

那时候说过那么多话。

如今却没有几句还能完整记得。

反而记得一些毫无意义的片段。

她坐在后面。

我知道她在那里。

有时回头。

有时不回头。

有时一句话也不说。

现在想来，少年人的喜欢之所以动人，或许不是因为它多么深刻。

而是因为那时候，我们还没有学会衡量。

没有值不值得。

没有以后怎么办。

没有这段关系最终会走到哪里。

甚至连所谓“永远”，也只是一个说出口时并不觉得沉重的词。

只是喜欢。

于是便靠近一些。

仅此而已。

那些没有日期的日子#

2021年5月17日，我至今还记得。

年轻的时候，总喜欢记住故事开始的日期。

后来才知道，真正值得记住的，其实不是哪一天开始。

而是开始以后，那些没有日期的日子。

一起吃过多少顿饭。

绕过多少圈操场。

等过多少次下课。

说过多少句无关紧要的话。

没有人会把这些写进纪念册。

日历也不会特意替你保存。

它们只是一天一天地发生，然后一天一天地过去。

直到有一天，你忽然发现，那些日子竟然已经全部成为过去。

这时候再去寻找，却连一个准确的日期都没有。

只剩下一种模糊的感觉。

好像那几年总是有风。

总是有人在身边。

总觉得明天还很长。

真正的告别很少有一场郑重的告别#

高三以后，很多事情开始不再像从前。

成绩掉下去。

心也乱起来。

曾经以为笔直向前的路，突然生出许多岔口。

那个考了141分以后觉得未来理所当然会很好的人，也渐渐沉默下来。

现在回头看，那大概是我第一次真正意识到：

人生并不会因为你年轻，就永远朝着自己想象的方向去。

有些人会离开。

有些事情会失控。

有些努力没有结果。

有些承诺说出口的时候是真的，后来失效的时候也是真的。

我们总是在很年轻的时候，以为遗憾来自“没有得到”。

后来才发现，遗憾更多时候来自——

曾经得到过。

只是那时不知道那就是最后一次。

最后一次并肩走过那条路。

最后一次坐在那个座位。

最后一次晚自习后一起离开。

最后一次很自然地说：

明天见。

所谓告别，很少真的有一场郑重的告别。

更多时候，它只是一个普通下午。

大家像往常一样分开。

谁也没有回头。

离开那间教室以后#

毕业以后，我很少再梦见考试。

倒是偶尔会梦见学校。

梦里的教学楼并没有什么变化。

走廊还是那样长。

教室里的灯还是白的。

有人趴在桌上睡觉，有人在后排讲话。

我走进去，也没有人觉得奇怪。

仿佛我只是出去了一会儿。

可醒来以后，要很久才能反应过来：

原来我已经离开那里很多年了。

有一次我忽然想到，人这一生会拥有很多房间。

后来住过的房子可能比那间教室宽敞得多，桌子也更好，灯也更亮。

可唯独那间教室，一旦走出去以后，就再也不能真正回去。

就算哪天重新推开门，也已经只是一个来访的人。

自己的座位坐着别人。

黑板上写着别人的课程。

窗外还是同一棵树。

可故事已经换了一批人。

那一刻大概才算真正明白了什么叫时间。

它不会毁掉什么。

它甚至让很多东西原封不动地留在那里。

只是把你从里面拿走。

时间开始有了价格#

后来，我也渐渐成了一个会计算的人。

会算得失，会想结果，会知道一件事情该不该做。

许多东西开始有了价格。

一次选择有代价。

一天时间有成本。

一件商品值多少钱，一项工作该投入多少精力，很多事情都可以慢慢算清楚。

可越是这样，我越想起十六七岁的自己。

那个时候的我，恰恰什么都不算。

会把一个下午完整地交给一场游戏。

会为了一个人多绕半圈操场。

会在晚自习前浪费十分钟，只为了说几句如今已经记不得的话。

会在走廊里踢一只毫无用处的毽子。

会望着窗外发呆。

会觉得一天太长。

会盼下课。

会盼周末。

会盼长大。

我们用最昂贵的东西，做着最没有意义的事。

而这大概就是青春。

如果现在回到从前#

我有时会想，如果现在真的给我一次机会，让我回到从前，我会不会改变些什么。

也许不会。

我甚至不想告诉那个少年未来会发生什么。

不告诉他哪次考试会失败。

不告诉他谁最后会离开。

不告诉他应该珍惜谁。

也不告诉他哪些选择以后会后悔。

因为一旦什么都提前知道，那就不再是青春了。

我只想在某个傍晚远远地看他一眼。

看他训练结束，站在操场边喘气。

看他低头看看时间，觉得晚自习快迟到了。

看他匆匆往教学楼走。

晚霞落在背后。

校服被风吹起来一点。

他不知道很多年以后，会有人如此怀念这一刻。

他只是往前跑。

甚至嫌天黑得太慢。

我不会叫住他。

只是想替很多年后的自己，多看一会儿。

青春昂贵在哪里#

现在我终于知道，青春昂贵在哪里。

不是因为年轻。

不是因为爱情。

也不是因为那几年发生过多少值得讲述的故事。

它昂贵，只因为一切都不能重来。

2020年的秋天不能。

第一次月考的141不能。

走廊里飞起来的毽子不能。

操场黄昏的风不能。

晚自习前的十几分钟不能。

那个曾经相信“以后还有很多”的自己，也不能。

而最让人无可奈何的是——

这些东西真正属于我的时候，我从没觉得它们稀有。

我嫌时间走得慢。

嫌晚自习太长。

嫌高三难熬。

一心想往前走。

后来真的走了很远，才忍不住频频回头。

原来人总是在青春里盼望远方，

又在远方里，想念青春。

在远方里想念青春#

如今再经过下雨的夜晚，我有时还是会停下来听一会儿。

雨落在窗沿，落在屋檐，也落进一些已经很远的年份里。

我不知道从前那个少年是否也曾在某个晚自习里听过同一场雨。

也许有。

也许没有。

其实都不重要了。

重要的是，他曾经在那里。

我也曾经在那里。

那几年并不完美。

有欢喜，也有狼狈；有得到，也有失去。

可它们终于还是一点一点，把今天的我送到了这里。

于是有一天，当我回过头去，我才发现——

原来我这一生最奢侈的时候，并不是后来拥有了什么。

而是十七岁那年，

我有整整一个下午可以挥霍，

有一个明天可以相信，

有一些人以为永远不会走散，

还有一个尚且不知道岁月为何物的自己。

那时候，我什么都没有。

却好像什么都有。

而如今，我终于知道它们有多贵。

只是再也买不回来了。

朝朝听雨，岁岁有风

Fri, 14 Aug 2026 00:00:00 GMT

写在故事之前#

今天是 2026 年 8 月 14 日。距离我的上一段感情，已经过去一年半了。

翻相册的时候，我看到了最近打出的高光操作——金标镜，多少有点想显摆。也就是这一点小小的得意，把我拽回了当年的那些事情。

我的博客叫“朝朝听雨”，ZZT 是我本名的缩写，Y 是她名字的最后一字，拼在一起便是“听雨”，对应着 Rain。这几年下来，不管是网名，还是做过的项目、写过的作品，落款里总藏着这几个字母。

说起来也算我痴情。倒不是刻意放不下，只是习惯了，也舍不得抹掉那些年月的痕迹。也是想提醒自己：物物而不物于物，念念而不念于念。

“朝朝听雨”现在的寓意，已经不再是我和她之间的专属暗码，而是独属于我个人的精神角落。它装得下年少的青春旧事，也盛得下如今的成熟从容；记得住被照亮的恩情，也将这份光继续延续下去。

今天不说遗憾，只讲讲我和她的故事。

故事从高一开始#

她是个很特别的姑娘，憨憨的，带着点没被磨平的傻气，和身边很多人都不一样。我总爱说她憨批，看着她的时候，总像看见初中时的自己——干净、透亮，对世界还抱着毫无保留的热忱。

故事要从 2020 年的秋天说起，那年我刚上高一。

九月入学。初三我当过半年班长，偏巧我爸认识广州大同中学的老师，而我们班主任恰好是从那所学校调过来的。我本来打定主意高中不再管事，还是被班主任直接任命成了班长。现在回头看，倒也算因祸得福。

高中的日子总过得缓慢又无聊。下课闲得发慌时，我就和几个相熟的男女同学凑在走廊踢毽子。起初只有零星几个人，后来队伍越拉越长，她也混在了里面。

你或许以为我们的故事是从毽子开始的。

其实不是。那时候认识归认识，我依旧我行我素。晚自习总爱坐到讲台上，和前排同学天南海北地聊，要么就拉着人玩飞行棋、真心话大冒险、五子棋。第一次月考我数学考了 141 分，拿了年级第一，便更没把心思放在学习上。

真正的转机是我舍友阿 B。阿 B 和他朋友小黑，加上她和她闺蜜，几个人总凑在一起开黑，连跪到小黑都嫌他们菜，嚷嚷着要找个大神带。于是他们找上了我。

就这么着，我们才算真正熟络起来。她玩法师，走中路。

从蝉鸣聒噪的盛夏，到呵气成雾的深冬。白天我们在走廊踢毽子、传纸条，课上偷偷讲小话，晚自习凑在一起写作业、玩桌游、扯些没营养的闲话；周末就抱着手机组队打王者，日子热热闹闹地往前跑。原本对她没什么特别感觉的我，不知不觉间，就动了心。

借着班长的便利，我把自己的座位调到了第一列第一个，她就坐在我身后。抬头低头总能撞见，聊天的时间越来越长，距离也越靠越近。

2021 年 5 月 17 日，我和她告白了。

我赌对了，她也喜欢我。

我们在一起了。

我喜欢她#

喜欢她干干净净的单纯。连故意逗她、看她气鼓鼓又拿我没办法的样子，心里都涨着满满的欢喜；喜欢她身上淡淡的、很好闻的香味，每次凑近都觉得莫名安心；喜欢她藏不住的可爱，一颦一笑都带着少年人独有的鲜活；更喜欢她眼睛里的光，亮闪闪的，像盛着整片星空。

我也曾有过意气风发的时候，有过属于自己的耀眼时刻。可那段日子里，我整个人都颓丧得厉害，世界灰蒙蒙的，连自己的光都快熄灭了。是她一步步走过来，把光重新递到了我手里，把我的日子照得透亮。

在一起之后的日子，像裹了层橘子味的糖衣。

上课的时候，我会趁老师转身写板书，悄悄往后递小纸条，写些无聊的废话，或者画个丑兮兮的小人；课间她会戳我的后背，递过来一颗水果糖，或者跟我吐槽刚才那道数学题有多离谱。晚自习我依旧坐讲台上，目光却总不自觉地飘向她的座位，撞见她抬头看我，就各自偷偷弯起嘴角。

周末除了打游戏，我们也会约着出去。去公园漫无目的地散步，去街边小店吃牛杂，去电影院看喜欢的动漫、电影。她走路总爱牵着我的手，而我总是觉得人多而不好意思。那时候总觉得日子很长，长到我们可以这样并肩走很久很久。

我把游戏 ID 改成了藏着她名字的字符，把日常的细碎都写进仅彼此可见的空间里，连后来做第一个小项目时，下意识就用了“听雨”的名字。那时候没想过以后会分开，只觉得这份喜欢要藏进所有我能留下的痕迹里。

高二：走进彼此的日常#

到了高二，我们的关系才算真正往彼此的生活里扎了根。

刚升学年那会儿，我们还守着各自的节奏，吃饭结伴旧友，课间各有圈子，算不上时时刻刻黏在一起。变故藏在那年的秋风里：她和相交多年的闺蜜闹了绝交，原本热热闹闹的日常忽然空了一大块。那段日子她总独来独往，连吃饭都缩在食堂角落，安安静静的。

我便顺理成章地走进了她的空档里。午饭陪她挤在食堂长桌，晚饭后绕着塑胶跑道慢慢散步，从教学楼前的香樟树下，走到田径场的铁丝网边。从前那些分给朋友的时间，渐渐都换成了彼此的陪伴。

后来我成了体育生，这份陪伴也没被训练冲散，反倒成了更笃定的日常。每天下午下课铃响，我直奔操场训练，她就安安静静地等我——有时在看台坐着翻书，有时回教室写作业，算着我结束的时间。等我带着一身汗气跑完练完，两人再慢悠悠晃去食堂吃晚饭。

饭后她先回教室自习，我回宿舍冲澡换衣，赶在晚自修开始前的十几分钟，凑到她桌边挨着说些没营养的闲话，腻歪好一阵才舍得回自己座位。

那些日子重复又细碎，却比任何告白都更让人安心。好像从那时起，我们才不只是“在一起的两个人”，而是真正走进了彼此的日常里。

高三：遗憾#

转眼到了高三，日子被高考的倒计时推着往前走，可我整个人却陷入一种浑浑噩噩的状态。明明已经迫近高考，我却没有半点奋力冲刺的劲头，成绩不进反退，越埋头学，越觉得力不从心，分数一次比一次不尽如人意。

是我的选择与失误，最后让我们没能奔赴同一所大学。

异地的距离横亘在我们之间，也埋下了往后走散的伏笔。或许这算不上分开的直接导火索，却是绕不开的间接缘由。少年人的感情，抵不住现实的落差。当两个人不能再朝夕相处，那些日常的陪伴、课间的碰面，很多矛盾与隔阂，也由此慢慢滋生。

现在回头看，这便是青春里一大桩无可奈何的遗憾。

分开之后#

后来的故事，那就不是那么开心的故事了，其实也俗套：分班、升学、磨合、争吵。少年人的感情热烈又脆弱，曾经以为能撑过所有难关，最终还是走散在了半路。

分开后的那段日子其实不好过，我花了很久才慢慢走出来。只是时至今日，再想起那些年月，最先冒出来的依旧是走廊的风、毽子落地的声响、晚自习的暖黄灯光，还有她眼睛里亮闪闪的光。

我没改掉那些带着她痕迹的名字，不是还在等什么，只是舍不得那段被照亮的岁月。毕竟是她，在我最黯淡的年纪里，认认真真地，做了我的光。

如今再翻起游戏截图，想起当年一手露娜带飞的意气，想起金标到手时迫不及待想分享的心情，想起那些藏在 ID 和名字里的少年心事，只剩一点淡淡的、温柔的怀念。

朝朝听雨，岁岁有风#

最后呢，希望大家：物物而不物于物，念念而不念于念。

而我，

朝朝听雨，岁岁有风。

Agent 赋予电商自动化：从业务规则到可控的自动上架框架

Sun, 09 Aug 2026 00:00:00 GMT

2026 年 5 月底，我第一次把 AI 真正放进跨境电商的日常工作里。不是让它帮我写一段宣传文案，也不是问它一个 API 怎么调用，而是让它参与搭建一套全自动上架系统。

这件事最初的动机很朴素：每天重复打开页面、整理表格、上传图片、匹配规格、修改标题，再盯着页面确认有没有保存成功。单次操作并不难，难的是每天重复几十次以后，人的注意力会先于代码耗尽。

后来我发现，电商自动化真正难的部分从来不是“让浏览器点一下按钮”，而是把业务规则讲清楚，再把每个容易出错的环节做成可以观察、可以重试、可以追责的流程。下面就记录这套思路，也把我在实践中踩过的坑一起写下来。

先说结论：自动化的核心不是点击，而是规则#

很多人第一次做浏览器自动化，会从录制操作开始：打开页面、点击按钮、填入文本、上传文件，然后把录制结果保存成脚本。这种方式在演示阶段很直观，但一旦页面结构、商品规格或图片顺序发生变化，脚本就会变得非常脆弱。

我现在更愿意把一次上架拆成四层：

数据层：表格、图片、视频、规格和标题素材分别是什么。
规则层：什么图片属于哪个 SKU，什么规格允许发布，标题如何拼接。
执行层：由 Playwright、CDP 和平台适配器完成页面操作。
观察层：任务做到哪一步、为什么失败、是否进入异常队列，都要有记录。

可以把它理解成下面这条链路：

flowchart LR A[表格与素材] --> B[规则解析] B --> C[任务队列] C --> D[平台 Worker] D --> E[Playwright + CDP] E --> F[页面校验] F --> G[截图、日志、结果] G --> H{是否成功} H -->|是| I[归档] H -->|否| J[重试或异常队列]

我希望它是全自动执行，但不是无法解释的黑盒。自动化可以替我完成机械动作，每一步也必须留下可以追溯的痕迹。

为什么我更推荐从 ERP 开始#

理论上，直接操控店铺后台当然也能实现自动上架。但在实践中，我更推荐先围绕 ERP 做自动化，原因主要有三个。

1. ERP 的数据更结构化#

商品名称、规格、库存、价格、图片和视频通常都已经被整理成字段。自动化系统不必从一个复杂页面里猜测“这段文字到底是什么”，而是可以先读取结构化数据，再按照模板生成任务。

2. 风险边界更清楚#

如果所有平台都直接接入，某个平台的小改版就可能影响整条流程。ERP 作为中间层，可以把共用的数据准备、素材管理和任务记录放在一起，再把 Shopee、TikTok Shop 等平台的差异放进各自的 Worker 里。

3. 多平台差异可以被隔离#

Shopee 和 TikTok Shop 的页面入口、编辑按钮、保存逻辑和成功提示并不一样。如果强行写成一套流程，后期会出现大量条件分支。更稳定的方式是共用底座，平台只负责自己的适配。

指纹浏览器同样可以做自动化，而且对某些场景很方便。但账号风险、登录状态和长期大规模运行是否稳定，不能只凭一次成功运行就下结论。使用这类方案时，需要自行评估平台规则、账号权限和风控边界，不要把“能跑通”误认为“可以无限放大”。

站外浏览器自动化接口与支持框架

技术底座：Playwright、CDP 与固定 Chromium#

我的技术组合是 Playwright + CDP + 固定版本 Chromium。

Playwright 负责定位元素、填写表单、上传素材、等待页面状态和截取结果；CDP 负责连接已经打开的浏览器；固定版本 Chromium 则尽量减少不同浏览器版本带来的接口差异。

连接浏览器的大致代码如下：

1
import { chromium, type Browser } from "playwright";
2

3
export async function connectBrowser(cdpUrl: string): Promise<Browser> {
4
  return chromium.connectOverCDP(cdpUrl);
5
}
6

7
const browser = await connectBrowser("http://127.0.0.1:9222");
8
const context = browser.contexts()[0] ?? (await browser.newContext());
9
const page = context.pages()[0] ?? (await context.newPage());
10

11
await page.goto("https://example.com/products", {
12
  waitUntil: "domcontentloaded",
13
});

固定 Chromium 的代价是项目体积会大一些，但它解决了两个实际问题：一是不同浏览器版本的接口行为不完全一致，二是图片上传顺序、文件选择器和页面等待时机更容易出现细微差异。对于需要重复运行的任务，我更愿意牺牲一些体积，换取结果的一致性。

固定版本 Chromium 运行环境

需要注意的是，CDP 不是“绕过平台规则”的通行证。它只是让自动化程序连接到浏览器调试端口，实际仍然是在页面上进行正常的用户操作。登录状态、权限和平台规则都应该由运营者自己负责。

AI Agent 到底帮了什么忙#

我并没有让 AI 直接生成一个“万能上架机器人”，而是把它当成一个会观察、会提问、会整理的开发搭档。

它最有价值的地方，通常在下面几个环节：

观察页面：读取当前页面的按钮、表格、规格和错误提示。
拆解流程：把“上架一个商品”拆成可验证的步骤。
定位问题：当选择器失效时，根据截图和日志判断是页面未加载、入口变化还是权限问题。
整理规则：把散落在聊天记录和经验里的判断，整理成配置文件和校验函数。
生成样板代码：先快速搭出 Worker、日志、重试和页面对象，再由我检查细节。

最重要的一点是：AI 可以帮我更快地把想法变成可运行的东西，但它不知道我的业务边界。比如“这个 SKU 的第 3 张图不能上传”可能是一个临时异常，也可能是这个产品本来就没有第 3 张图。最终决定规则的人，仍然是我。

两种业务场景，不能用同一套规则#

POD 产品：规则稳定，适合批量化#

POD 产品通常有比较规整的数据和素材：款式、颜色、尺寸、主图、详情图和变体之间有明确关系。只要把模板定义清楚，就可以批量处理很多商品。

搬运或铺货：差异更大，但同样可以全自动#

搬运和铺货同样可以全自动。它们通常需要翻译、清理厂家信息、生成场景图、判断平台类目、重新组织规格，规则确实比 POD 更复杂，但复杂不等于必须人工逐条确认。只要把这些判断拆成可配置的规则和可调用的 AI 步骤，就可以让采集、清洗、翻译、配图、SKU 生成、上架和发布全部自动跑完。

真正需要保留的是异常队列，而不是人工审批链：缺少必填字段、图片不符合尺寸、类目无法判断或平台返回风险提示时，任务暂停在可定位的节点，修正规则或补齐数据后再自动继续。我的做法是共享任务队列、日志和素材中心，但为不同产品线保留独立模板和校验策略。

批量铺货与任务配置界面

图片与 SKU 的匹配：最容易被低估的难题#

图片文件名看起来很简单，真正处理起来却非常容易错位。

例如下面是一组商品素材：

1
AB001-1.jpg  # AB001 主图
2
AB001-2.jpg  # AB001 详情图
3
AB001-3.jpg
4
AB001-4.jpg
5
AB001-5.jpg
6

7
AB002-1.jpg  # AB002 另一种颜色或规格的主图
8
AB002-2.jpg

最基础的规则是：同一个前缀属于同一个图片组，-1 作为主图，其余作为详情图。但仅靠字符串切分还不够，至少要同时做三层校验：

1
type AssetGroup = {
2
  key: string;
3
  cover: string;
4
  detail: string[];
5
};
6

7
function groupAssets(files: string[]): AssetGroup[] {
8
  const groups = new Map<string, string[]>();
9

10
  for (const file of files) {
11
    const match = file.match(/^(.+)-(\d+)\.(png|jpe?g|webp)$/i);
12
    if (!match) continue;
13

14
    const [, key] = match;
15
    const list = groups.get(key) ?? [];
16
    list.push(file);
17
    groups.set(key, list);
18
  }
19

20
  return [...groups.entries()].map(([key, list]) => {
21
    const ordered = [...list].sort((a, b) => {
22
      const aNo = Number(a.match(/-(\d+)\./)?.[1] ?? 999);
23
      const bNo = Number(b.match(/-(\d+)\./)?.[1] ?? 999);
24
      return aNo - bNo;
25
    });
26

27
    return {
28
      key,
29
      cover: ordered[0],
30
      detail: ordered.slice(1),
31
    };
32
  });
33
}

展开收起

代码只能完成“文件名分组”，不能代替业务校验。真正执行上传前，还要检查：

当前 ERP 页面显示的 SKU 是否等于图片组的 key。
主图是否确实是 -1，有没有缺号或重复编号。
当前变体的颜色、尺寸与表格字段是否一致。
当前任务有没有读到下一组产品的图片。

第三点和第四点很关键。曾经遇到过流程全部显示成功，但图片被挂到了错误 SKU 上。因为系统只看到了“上传成功”，却没有验证“上传到了正确的位置”。自动化要判断的是业务结果，而不是浏览器动作有没有报错。

批量编辑中的图片分组与 SKU 关系

变体图片上传位置校验

把平台操作写成 Worker，而不是一条超长脚本#

一个平台 Worker 可以只负责一件事：接收标准化任务，完成这个平台的页面操作，并返回结构化结果。

1
type ListingTask = {
2
  productId: string;
3
  title: string;
4
  variants: Array<{ sku: string; images: string[] }>;
5
};
6

7
type ListingResult = {
8
  ok: boolean;
9
  productId: string;
10
  step: string;
11
  error?: string;
12
};
13

14
export async function publishToShopee(
15
  page: import("playwright").Page,
16
  task: ListingTask,
17
): Promise<ListingResult> {
18
  try {
19
    await page.getByPlaceholder("搜索商品").fill(task.productId);
20
    await page.getByRole("button", { name: "编辑" }).click();
21

22
    await page.getByLabel("商品标题").fill(task.title);
23
    await uploadImages(page, task.variants);
24
    await verifyVariants(page, task.variants);
25

26
    await page.getByRole("button", { name: "保存并发布" }).click();
27
    await page.getByText("发布成功").waitFor({ state: "visible" });
28

29
    return { ok: true, productId: task.productId, step: "published" };
30
  } catch (error) {
31
    return {
32
      ok: false,
33
      productId: task.productId,
34
      step: "publish",
35
      error: error instanceof Error ? error.message : String(error),
36
    };
37
  }
38
}

展开收起

Shopee 与 TikTok Shop 的平台任务工作区

这里有两个值得保留的习惯：

每完成一个高风险步骤，就记录一个明确的 step。
返回结构化结果，而不是只在控制台打印一句“失败了”。

这样做的好处是，后续可以把 Shopee、TikTok Shop 或其他平台的结果统一放进任务历史里，界面不需要知道每个平台内部的细节。

失败重试，但不要无脑重试#

网络波动、页面响应慢和临时弹窗都可能造成偶发失败，所以任务需要重试机制。但“失败就再点一次”也很危险，尤其是发布、扣库存或创建优惠券这类不可逆动作。

我会把步骤分成三类：

可安全重试：打开页面、读取列表、等待元素、获取截图。
需要幂等判断后重试：上传图片、保存草稿、更新标题。
不做盲目重试：最终发布、扣库存、创建订单等有副作用的操作，先做幂等校验，再由任务状态机自动决定是否继续。

一个简单的重试包装器可以这样写：

1
async function retry<T>(
2
  action: () => Promise<T>,
3
  options: { attempts?: number; delayMs?: number } = {},
4
): Promise<T> {
5
  const attempts = options.attempts ?? 3;
6
  const delayMs = options.delayMs ?? 800;
7
  let lastError: unknown;
8

9
  for (let i = 0; i < attempts; i += 1) {
10
    try {
11
      return await action();
12
    } catch (error) {
13
      lastError = error;
14
      if (i < attempts - 1) {
15
        await new Promise((resolve) => setTimeout(resolve, delayMs));
16
      }
17
    }
18
  }
19

20
  throw lastError;
21
}

展开收起

真正接入系统时，还要给重试加上截图、当前 URL、任务 ID 和步骤名。否则过几天回头看日志，只知道某个任务失败过，却不知道当时页面到底是什么状态。

为什么一定要做可视化界面#

自动化不是越黑盒越高级。对于电商任务，我希望界面至少能回答下面这些问题：

当前正在处理哪一个商品、哪一个 SKU？
已经完成了多少步，卡在哪一步？
失败是网络问题、页面变化，还是业务规则不匹配？
图片和规格有没有完成对应校验？
是否保存了关键截图和日志？
这个任务可以安全重试，还是应该进入异常队列？

所以我会把运行面板当成产品的一部分，而不是开发阶段的调试工具。实时日志、成功/失败统计、暂停/恢复、截图留档和历史记录，都会直接影响运营人员是否敢于使用这套系统。

最理想的状态不是“所有任务都永远成功”，而是任务失败时，系统能在几十秒内定位原因，把任务放回重试队列或异常队列，而不是让人重新从头操作。

从自动上架继续往外扩展#

自动上架只是一个入口。围绕同一套数据、素材和任务系统，后续可以继续扩展：

AI 生成商品主图、换背景和场景图；
根据平台规则自动生成多语言标题和描述；
采集供应商商品并清理厂家信息；
跑图、算价、整理利润和库存；
批量设置折扣、优惠券和活动价格；
在发布前做违禁词、图片尺寸和品牌信息检查；
用队列调度不同店铺，并保留团队操作审计。

这些功能看起来分散，其实共享的是同一条底座：结构化数据、可追踪的任务、明确的规则和可靠的执行器。底座稳定以后，新增一个工具不再是复制一份脚本，而是接入同一套任务系统。

AI Agent 串联电商自动化工作流

最后：Agent 替我完成动作，但不会替我承担判断#

这次实践让我最明显的感受是，AI 把“想法到原型”的距离压缩得非常短。以前可能要先查文档、搭环境、写一堆样板代码，才能看到第一个页面；现在可以先把业务目标、页面截图和现有规则交给 AI，让它帮助我拆分模块、定位元素、补齐日志，再由我持续校正。

但效率提高以后，真正重要的判断反而更贵了：为什么要做这个工具？哪些规则必须固定？哪些异常不能自动处理？出了问题由谁确认和负责？

Agent 可以观察页面、整理数据、调用工具，也可以陪我把一个流程逐步变成代码。它能替我完成大量机械执行，却不能替我决定什么结果才算正确。

所以我对“AI 赋予电商自动化”的理解，不是让人从系统里消失，而是让人从重复点击和逐条审批里出来，把时间留给规则设计、体验和异常处理。全自动铺货并不意味着盲目放行，而是让每个判断都有规则、有校验、有记录，只有真正无法判断的异常才会被单独拎出来。

作品展示页动画实现原理

Mon, 27 Jul 2026 00:00:00 GMT

最初做作品展示页时，我把它理解成“让五张卡片依次动起来”。后来页面经历了几轮调整，真正变化的不是多加了几个位移或淡入，而是实现的重心从“堆动画效果”转成了“维护一条可控制、可验证的滚动时间轴”。

现在的页面仍然没有引入重型动画库。Astro 负责结构和资源声明，CSS 负责固定舞台、裁切和图层关系，原生 TypeScript 只做一件事：把浏览器滚动位置转换为稳定的分镜状态。卡片、黑场快门、角色、视频和结尾文案都消费同一个进度值，但它们不再直接绑定原始滚动事件。

这篇文章记录作品展示页的实现思路。文中的区间、资源策略和代码片段以当时的实现为准，不再使用早期的 760vh / 680vh 时间轴或“滚一下就立刻改样式”的写法。

目标不是播放，而是让读者控制节奏#

作品展示区有几个约束，它们决定了这不是一组普通的 CSS 入场动画：

读者慢慢滚动时，每一张作品卡片都要有足够的停留时间；停下来时，画面也应停住。
快速滚动、触摸板惯性和不同刷新率不应让画面突然跳帧。
转场要有连续的图层关系，不能让黑场、角色和下一幕像三次互不相干的淡入。
首次进入展示区时，图片解码不能集中阻塞主线程。
动画不是作品信息的唯一载体；键盘和辅助技术用户仍应能在普通作品列表中访问每个链接。

换句话说，这一页的输入不是“经过了多少秒”，而是“读者在叙事中的位置”。页面滚动位置只是输入信号，真正被渲染的是一个受控的 0 ~ 1 进度。

1
scroll / resize
2
      |
3
      v
4
目标进度 targetShowcaseProgress
5
      |
6
      v
7
requestAnimationFrame 平滑追赶
8
      |
9
      v
10
渲染进度 renderedShowcaseProgress
11
      |
12
      v
13
phaseAt() 分镜区间 -> 卡片 / 快门 / 结尾场景

固定舞台：用滚动距离换取阅读时间#

展示区使用“长容器 + sticky 舞台”的结构。长容器提供滚动距离，舞台始终固定在视口内，所有镜头都在这个舞台上完成。

1
<section class="cinematic-showcase" id="showcase">
2
  <div class="showcase-pin" data-showcase>
3
    <div class="showcase-intro">...</div>
4
    <div class="showcase-panels">...</div>
5
    <div class="showcase-interlude">...</div>
6
    <div class="showcase-finale">...</div>
7
  </div>
8
</section>

当前 CSS 使用的是桌面端 850vh、窄屏端 760vh，而不是早期更短的数值：

1
.cinematic-showcase {
2
  position: relative;
3
  height: 850vh;
4
  margin-top: 2rem;
5
}
6

7
.showcase-pin {
8
  position: sticky;
9
  top: 0;
10
  height: 100svh;
11
  min-height: 37.2rem;
12
  overflow: hidden;
13
  isolation: isolate;
14
}
15

16
@media (max-width: 600px) {
17
  .cinematic-showcase { height: 760vh; }
18
}

展开收起

这里的 850vh 不是动画持续时间，更像是时间轴的可用长度。真正可用的滚动距离不是容器高度本身，而是容器高度减去视口高度：

1
const measureShowcase = () => {
2
  if (!showcaseSection) return;
3
  showcaseStart = window.scrollY + showcaseSection.getBoundingClientRect().top;
4
  showcaseDistance = Math.max(
5
    1,
6
    showcaseSection.offsetHeight - window.innerHeight,
7
  );
8
};
9

10
const getShowcaseProgress = () =>
11
  clamp((window.scrollY - showcaseStart) / showcaseDistance);

这样做有两个细节。

第一，showcaseStart 在测量时写成相对文档的绝对位置，而不是每一帧都重新读取 getBoundingClientRect()。滚动路径中只需计算一次减法和一次夹取，避免不必要的布局读取。

第二，舞台高度选用 100svh。手机浏览器地址栏展开和收起时，svh 比传统 vh 更稳定；同时在 resize 时重新测量，并立即同步渲染进度，避免视口变化后动画从旧位置缓慢追赶到新位置。

1
const resizeShowcase = () => {
2
  measureShowcase();
3
  targetShowcaseProgress = getShowcaseProgress();
4
  renderedShowcaseProgress = targetShowcaseProgress;
5
  lastShowcaseProgress = -1;
6
  applyShowcaseProgress(renderedShowcaseProgress);
7
};

移动端并没有简单地把故事压缩得更快。当前实现缩短了总行程，并隐藏卡片中的长说明文字；保留编号和标题，让每个镜头仍有可理解的停留。

不在 scroll 回调里直接渲染#

最容易写出的版本，是在每次 scroll 事件中读取进度并修改所有元素的 style。它在鼠标滚轮上似乎可行，但触摸板惯性、主线程短暂停顿和高刷新率设备会让同一段动画显得忽快忽慢。

当前实现把“用户想去哪里”和“当前画面画到哪里”分开：

1
const SCROLL_SCRUB_DURATION = 180;
2
const SHOWCASE_SETTLE_EPSILON = .00008;
3

4
let targetShowcaseProgress = 0;
5
let renderedShowcaseProgress = 0;
6
let showcaseFrame = 0;
7
let lastShowcaseTimestamp = 0;
8

9
const requestShowcaseUpdate = () => {
10
  targetShowcaseProgress = getShowcaseProgress();
11
  if (showcaseFrame) return;
12
  lastShowcaseTimestamp = 0;
13
  showcaseFrame = window.requestAnimationFrame(renderShowcase);
14
};

滚动事件只更新目标值，并且以被动监听注册：

1
window.addEventListener("scroll", requestShowcaseUpdate, { passive: true });
2
window.addEventListener("resize", resizeShowcase, { passive: true });

实际渲染发生在 requestAnimationFrame 中。这里没有使用固定比例的 progress += 0.1，而是使用基于时间差的指数平滑：

1
const renderShowcase = (timestamp: number) => {
2
  const elapsed = lastShowcaseTimestamp
3
    ? Math.min(64, Math.max(0, timestamp - lastShowcaseTimestamp))
4
    : 16.67;
5

6
  lastShowcaseTimestamp = timestamp;
7

8
  const blend = 1 - Math.exp(-elapsed / SCROLL_SCRUB_DURATION);
9
  renderedShowcaseProgress +=
10
    (targetShowcaseProgress - renderedShowcaseProgress) * blend;
11

12
  if (
13
    Math.abs(targetShowcaseProgress - renderedShowcaseProgress) <
14
    SHOWCASE_SETTLE_EPSILON
15
  ) {
16
    renderedShowcaseProgress = targetShowcaseProgress;
17
  }
18

19
  applyShowcaseProgress(renderedShowcaseProgress);
20

21
  if (
22
    Math.abs(targetShowcaseProgress - renderedShowcaseProgress) >=
23
    SHOWCASE_SETTLE_EPSILON
24
  ) {
25
    showcaseFrame = window.requestAnimationFrame(renderShowcase);
26
    return;
27
  }
28

29
  showcaseFrame = 0;
30
  lastShowcaseTimestamp = 0;
31
};

展开收起

blend = 1 - exp(-dt / duration) 的好处是刷新率无关：在 60Hz 和 120Hz 屏幕上，画面趋近目标的速度一致。elapsed 被限制到 64ms，标签页从后台恢复时也不会因一个异常大的时间差直接跳到终点。进度足够接近后停止申请下一帧，减少静止状态下的无效工作。

渲染函数内部还有一层更细的保护：当新旧进度相差小于 0.00001 时，不再重写样式。这一层在慢速滚动或停住后很有价值，因为页面的图层比普通卡片页多得多。

phaseAt：把连续进度切成可维护的分镜#

所有镜头都从同一个 progress 出发，但每个镜头只关心属于自己的时间窗口。为此实现了一个“局部阶段函数”：

1
const clamp = (value: number) => Math.min(1, Math.max(0, value));
2

3
const ease = (value: number) => {
4
  const t = clamp(value);
5
  return t * t * (3 - 2 * t);
6
};
7

8
const phaseAt = (progress: number, start: number, end: number) =>
9
  ease((progress - start) / Math.max(.001, end - start));

phaseAt(progress, start, end) 会先把任意区间归一化到 0 ~ 1，再套一层 smoothstep。它有三个稳定的状态：开始前为 0，区间内平滑变化，结束后为 1。这样每段动画不需要知道页面总高度，也不用自己处理越界。

当前时间轴大致如下：

分镜	进度区间	目的
引导文案淡出	0.00 - 约 0.21	让读者从引导进入作品卡片
五张卡片入场	第 i 张为 0.04 + 0.055i 到 0.16 + 0.055i	逐张落位，最后一张不被前几张挤压
卡片文字入场	第 i 张为 0.16 + 0.05i 到 0.25 + 0.05i	图片先建立画面，再交代标题
卡片退场	0.60 - 0.72	统一清空，不留下半透明边框
黑场与角色	0.63 - 0.97	把卡片阶段交给快门转场
上下快门合拢 / 展开	0.72 - 0.84 / 0.91 - 0.97	形成完整的一次闭合与打开
结尾场景	0.88 - 1.00	在转场遮挡下预热，再分层揭示

表格里的数字不是“魔法常量”，而是对叙事节奏的显式描述。它们集中在渲染函数里，调整某一幕时只需要移动相邻区间，不会牵连一堆独立的 @keyframes。

卡片为什么要同时算透明度和几何退场#

五张作品卡片由数据数组生成，动画代码只使用索引。入场和退场使用同一组局部进度：

1
const inProgress = phase(.04 + index * .055, .16 + index * .055);
2
const dissolve = phase(.60, .72);
3
const direction = index % 2 === 0 ? 1 : -1;
4

5
const startingY = (1 - inProgress) * direction * 150;
6
const fanX = (index - 2) * dissolve * -3.25;
7
const fanY = (index - 2) * dissolve * 1.35;
8

9
panel.style.opacity = String(inProgress * (1 - dissolve));
10
panel.style.transform =
11
  "translate3d(" + fanX + "vw, " +
12
  (startingY + fanY) + "%, 0) " +
13
  "scale(" + (1 - dissolve * .12) + ") " +
14
  "rotate(" + ((index - 2) * dissolve * 1.35) + "deg)";

入场时，奇偶卡片从相反方向进入；退场时，它们微微散开、缩小并旋转。更重要的是，透明度使用 inProgress * (1 - dissolve)，所以退场结束时一定回到 0。

这个约束是有原因的。早期版本曾保留少量半透明残影，卡片边框会在纯黑转场和窗景上变成一层浅灰横带。对于这种需要明确切镜的页面，残影不是氛围，而是上一幕没有离开干净的证据。

卡片文字单独安排了入场和退场，避免与图片一起仓促消失：

1
const copyIn = phase(.16 + index * .05, .25 + index * .05);
2
const copyOut = phase(.58, .70);
3

4
copy.style.opacity = String(copyIn * (1 - copyOut));
5
copy.style.transform =
6
  "translate3d(0, " +
7
  ((1 - copyIn) * 18 - dissolve * 26) +
8
  "px, 0)";

这让“图像抵达”和“文字可阅读”成为两个独立的节拍。设计上真正需要保证的不是卡片出现得多炫，而是最后一张卡片完全出现后，读者仍有机会理解它。

快门转场不是淡出，而是一段可交接的场景#

卡片退场后，展示区进入黑场。这里的核心不是给画面叠一层黑色，而是明确每一层的职责：

图层	作用
黑色背景	切断前一段丰富的卡片画面，给下一幕提供干净底色
上下两条横幅	从左右移动，完成快门的合拢和再次展开
前景角色	在黑场中连接卡片阶段与结尾场景
两个大字	只在快门闭合后的短暂读秒出现
结尾场景	先在黑场后方完成准备，再在遮挡结束后被看见

上下横幅不是只进不出。它们先从画面外移动到中间，在角色和文字退出时回到两侧：

1
const stripsIn = phase(.72, .84);
2
const stripsOut = phase(.91, .97);
3
const stripPosition = stripsIn * (1 - stripsOut);
4

5
shutterStripLeft.style.transform =
6
  "translate3d(" + ((1 - stripPosition) * -108) + "%, 0, 0)";
7
shutterStripRight.style.transform =
8
  "translate3d(" + ((1 - stripPosition) * 108) + "%, 0, 0)";

结尾场景则从 0.88 就开始在快门后方进入：整体场景先渐显，视频和中景在 0.90 - 0.97 进入，前景角色到 0.94 - 1.00 才落位。这个重叠不是浪费，而是为了让读者先看到“场景已在”，再感受到前、中、后景的空间关系。

视频只在进度超过一个很小的阈值后尝试播放，并忽略被浏览器自动播放策略拒绝的结果：

1
const v = phase(.90, .97);
2
finaleVideo.style.opacity = String(v);
3
setVisibility(finaleVideo, v > 0);
4

5
if (v > .02 && finaleVideo.paused) {
6
  finaleVideo.play().catch(() => undefined);
7
}

visibility 会在图层完全不可见时关闭其可见性；视频仍然带有 muted、loop、playsinline 和 preload=“auto”。即使视频不能自动播放，静态中景和前景仍会完整呈现，结尾不会变成空白。

资源预热：不要把所有图片同时 decode#

展示区一次会用到卡片、快门和结尾场景的多张图片。如果在首次进入页面时对所有图片立即调用 decode()，图片解码可能和首段滚动竞争主线程，反而让第一幕出现卡顿。

当前策略按两个图片为一组预热，每完成一组就让出一个动画帧：

1
const warmShowcaseMedia = async () => {
2
  for (const batch of showcaseImageBatches) {
3
    await Promise.all(
4
      batch.map(async (image) => {
5
        await waitForImage(image);
6
        await image.decode?.().catch(() => undefined);
7
      }),
8
    );
9

10
    await new Promise((resolve) => {
11
      window.requestAnimationFrame(() => resolve());
12
    });
13
  }
14
};

waitForImage() 同时监听 load 和 error，单张资源失败不会把整条预热链卡住。这个策略不追求“最早把所有内容解码完”，而是控制一次被调度到主线程的工作量，让首页和第一段滚动仍保持响应。

动画层不承担链接职责#

展示区不承担项目链接职责：卡片列表和快门转场容器标记为 aria-hidden，结尾场景中的图片使用空的 alt。真正可点击、带标题和描述的项目内容在下面的普通作品网格中：

1
<div class="showcase-panels" aria-hidden="true">...</div>
2

3
<section class="works-section" id="works">
4
  <article class="work-card">
5
    <a class="work-card-link" href="...">...</a>
6
  </article>
7
</section>

这避免了同一批作品被屏幕阅读器重复朗读，也让动效失效、被跳过或尚未加载时，内容仍有一条稳定的阅读路径。首屏的“向下看作品”入口指向 #showcase，保证想体验叙事的读者进入动画开头；而普通网格则负责承载可访问的项目导航。

这里还有一个应继续完善的点：当前的 prefers-reduced-motion 已经关闭了常规内容的 reveal 过渡，但还没有为整段分镜提供专门的静态展示模式。由于作品链接不依赖动画层，内容不会丢失；下一步更理想的做法是让该媒体查询直接展示首帧或静态作品列表，并跳过滚动平滑与视频播放。

验证不是“看起来能动”#

每次调整分镜后，我会从三个方向检查：

节奏：慢慢滚动时，第五张卡片和结尾文案是否都有可阅读的停留；快速滚动后画面是否平稳追上目标，而不是闪到终点。
图层：卡片退场后是否确实为 0；黑场是否干净；快门再次打开时，结尾场景是否已经准备好而没有白屏或裸露的中间状态。
环境：在展示区内改变窗口尺寸或旋转手机，进度是否保持；禁用或拒绝视频自动播放时，结尾是否仍可理解；键盘访问时，作品链接是否只在普通列表中出现一次。

内容改动完成后，仓库内使用以下命令检查：

Terminal window

1
pnpm check
2
pnpm type-check
3
pnpm build

结语#

这页最终留下的不是一套“滚动动画技巧”，而是一种更适合维护的拆分方式：

CSS 管舞台、裁切和图层；
滚动事件只更新目标；
rAF 负责在帧间平滑渲染；
分镜函数把连续进度切成可读的区间；
资源预热和可访问内容各自有独立边界。

当动画需要继续加镜头、换素材或调整节奏时，最重要的不是继续往页面里塞效果，而是先问清楚：这段变化处在哪个区间、它和前后镜头如何交接、内容是否仍有不依赖动画的路径。把这些问题写进结构之后，滚动才会真正成为叙事，而不是一串碰巧同时发生的视觉效果。

写完这一批工具后，我重新打开了自己的博客

Thu, 23 Jul 2026 00:00:00 GMT

最近一段时间，电脑终于安静了一点。

不是风扇不转了，也不是消息提示彻底消失了，而是那些排着队等我处理的定制项目，大多已经交付。剩下的一些收尾、反馈和维护，也交给合作人员继续跟进。连续很久被需求、调试和交付日期推着往前走之后，日程表上总算出现了一点没有被预先占满的空白。

我没有立刻开一个新项目，而是先整理电脑。

桌面上有周报、表格转换、上架表格制作、库存清理、批量库存处理、SKU 销量汇总；往文件夹里再翻，还有订单筛选、活动 Excel 工具、图片搜索、错误 SKU 修改、自动识别、主图优化和上架状态监控。Shopee、TikTok Shop、美客多，不同平台的规则被拆进不同脚本里；同一个工具又会因为客户流程不同，留下好几个版本。

这些文件夹没有统一命名，也谈不上整齐，但它们比周报更诚实地记录了我前段时间在做什么。

桌面上的 SKU、周报、表格与库存工具

围绕 TikTok、美客多和主图处理建立的项目文件夹

订单筛选、活动 Excel、自动上架等项目目录

上架监控、博客与各类辅助程序目录

项目名称有的直白，有的临时，有的还带着“新”“最终版”的痕迹。它们拼在一起，就是这段时间最具体的工作记录。

文件夹背后，是一个个很具体的问题#

做自动化工具久了，很容易把工作概括成几个听起来很大的词：跨境电商、批量处理、流程自动化、AI 辅助。

可真正落到手上的需求，通常没有这么抽象。

它可能只是商家每天都要从平台导出一份 Excel，再按固定规则删除、筛选和拆分；可能是几千个 SKU 的库存状态对不上，需要从多个表格里重新汇总；也可能是同一批商品要适配不同平台的上架模板，字段名称、图片顺序、变体规则都不一样。还有一些工作并不难，却要不断重复：打开页面、复制内容、上传图片、检查状态、等待结果，再把异常项目重新处理一遍。

这些动作单独看都很小，连续做几个小时却足以消耗掉一个人的耐心。

我的工作，就是先把商家原本的操作完整走一遍，弄清楚哪些步骤不能变、哪些判断藏在经验里、哪些异常以前全靠人工兜底，再把它们一点点写进程序。需求沟通、流程拆解、脚本编写、界面调整、数据校验、打包交付，最后再根据真实使用反馈继续改。

有时候最费时间的并不是写代码，而是听懂一句“这里和以前一样处理就行”。所谓“以前一样”，背后可能藏着十几条没有写进文档的规则。只有把这些规则问出来、试出来，自动化才不是机械地替人点击，而是真的能接住工作。

将多店铺 Shopee 订单集中处理的订单筛选工具

围绕图案分类、检索与导出设计的智能管理系统

一个项目处理订单数据，一个项目管理图像资产。界面和用途不同，出发点却一样：把反复发生的工作整理成清晰、稳定、可复用的流程。

这也是为什么电脑里的工具越来越多。它们并不是我事先规划好的一张产品路线图，而是现实需求一点点推出来的结果。一个客户遇到库存问题，就有了库存工具；另一个客户长期受困于上架流程，就继续往表格、图片、浏览器自动化和状态监控上延伸。

回头看，这些看似零散的文件夹，其实是一张很具体的需求地图。

初代博客，曾经更像一间线上店铺#

工具越做越多之后，我自然需要一个集中展示它们的地方。于是有了初代博客。

初代博客首页

那时搭建网站的目标非常明确：展示能力、介绍工具、承接需求。首页要让访客尽快知道我能做什么，项目页面要说明功能、参数和使用场景，文案也要回答潜在客户最关心的问题——这个程序能解决什么、适不适合自己的业务、要怎样联系开发者。

从这个目标看，初代博客并没有做错什么。它认真完成了当时的任务，也留下了我做服务器、前端和脚本开发的一段经历。

只是现在再回头看，我发现它更像一间布置过的线上店铺，而不是我真正想长期写下去的博客。

我习惯在文章里介绍“工具具备哪些功能”，却很少写“我为什么会想到这样做”；会认真展示运行效果，却不太记录调试到深夜时到底卡在了哪里；会把项目整理成一份完整、漂亮的说明，却略过了那些绕路、误判和临时改主意的瞬间。

网站里有我完成的东西，却不一定有完整的我。

这不是初代博客的问题，而是那个阶段的我确实把大部分注意力放在了业务上。那时的网站首先要服务接单，个人表达自然排在后面。

第二代博客，是一次有意的减法#

重新搭建 rainzt.cn 时，我最想做的并不是增加多少功能，而是减掉一种过强的目的性。

第二代博客仍然会写自动化工具，也不会刻意回避商业项目。跨境电商自动化依旧是我会长期深耕的方向，真实项目里积累的经验，也恰恰是最值得整理的内容。不同的是，我不再要求每篇文章都承担展示产品和转化客户的任务。

我想写下批量库存工具为什么会从一张表格变成一套流程，自动上架系统如何一点点适配 Shopee 与 TikTok Shop，主图处理为什么不能只追求“批量生成”，还要考虑平台规则、视觉一致性和异常回退。我也想记录服务器运维、前端页面打磨和 AI 辅助开发中的判断：哪些方案最后保留下来，哪些看起来聪明却不适合真实使用。

这些内容可能没有一份产品说明那么干净。它们会有失败、有犹豫，也会有“后来才发现”的补充。但对我来说，恰恰是这些不够标准的部分，才构成了真正的开发经历。

除此之外，我也想给生活留一点位置。

不一定每次都要讲一项新技术，也不一定非要总结出一条可复用的方法。有时只是项目结束后的松弛，一次重新整理桌面的感触，或者某个晚上突然想清楚的一件小事。它们不能直接换来效率，却能让我在几年之后回头时，知道自己当时如何生活、如何理解手里的工作。

让 AI 回到助手的位置#

忙着赶项目时，我也把写文章变成过一条自动化流水线。

把 README、功能清单、代码逻辑和截图交给 AI，它很快就能整理出标题、章节和结尾。事实基本正确，结构也比我临时组织得更完整。项目刚交付、人已经很疲惫的时候，这种方式确实替我省下了许多时间。

但这种方便用久了，我也会感觉到一种落差：文章把项目说明白了，却没有把我留下来。

AI 能从资料里提炼出“系统实现了批量上架”，却不知道某个按钮为什么改过三次；它能总结订单筛选规则，却没有经历过客户一句含糊描述背后的来回确认；它可以把功能写得很专业，却很难替我判断，哪一次失败最值得记录，哪一个看似不起眼的细节真正改变了后来做项目的方法。

所以我并不打算拒绝 AI，也不会把“全部手写”当作一种必须遵守的仪式。我仍然会用它查漏、整理资料、校对表达，甚至在没有头绪时帮我搭一个起点。

我只是想慢慢把它从“替我完整交稿”的位置，放回“陪我整理和修改”的位置。重要的经历由我回忆，真正的判断由我确认，那些只属于当时心境的句子，也尽量留给自己慢慢写。

效率可以帮助我完成更多事情，但有些内容只有在放慢以后才会浮上来。

两种创作，可以并行#

项目告一段落，不代表商业工具开发也告一段落。

以后我仍然会接触新的平台规则、新的表格格式和新的运营流程，也会继续把合适的重复劳动做成程序。商用代码解决的是客户此刻真实存在的问题，它需要稳定、准确、按时交付，也需要在变化的平台环境里不断维护。

而博客可以承担另一件事：保留那些不适合写进交付文档的东西。

这里可以有技术方案，也可以有开发感受；可以复盘一套自动上架系统，也可以只记录某次调试后的想法。商业项目追求明确结果，私人写作允许暂时没有结论。前者让我不断面对真实需求，后者让我不至于只剩下一张完成项目的清单。

它们并不冲突。

代码把复杂操作封装起来，让别人少做一些重复劳动；文字把已经过去的经历重新展开，让我看见自己是怎样走到现在。一个向外解决问题，一个向内保存思考，都是创作，只是面对的对象不同。

重新开始更新#

整理电脑时，我没有删除那些密密麻麻的项目文件夹。

有些工具以后还会继续迭代，有些可能完成使命后就停在当前版本。再过几年，其中一部分程序也许已经不适配新的平台，甚至连当时依赖的页面都不存在了。但如果把开发过程、做过的判断和那段时间的感受写下来，它们就不会只剩下一个无法运行的旧文件。

这大概就是我重新深耕第二代博客的原因。

我并不想把它重新经营成一面更精致的商品橱窗，也不急着证明自己能保持多高的更新频率。我只想在忙碌告一段落之后，重新留出一块可以慢慢写字的地方。

往后，工具还会继续做，需求还会继续变化，电脑里的文件夹大概也不会真正变少。

但这一次，我希望它们增长的同时，博客里也能留下另一条时间线：不只记录我完成了什么，也记录我为什么开始、如何走过，以及一路上究竟想过些什么。

当 AI 能替我写完项目博文，我为什么还想敲下这些字

Wed, 22 Jul 2026 00:00:00 GMT

翻了翻站点统计，博客上线差不多半个月，三篇文章里有两篇是项目作品。

说句实话，这两篇项目介绍，大半功劳不在我。

把项目的 README、核心脚本逻辑、几张运行截图丢给 AI，再告诉它一句“写成一篇博客风格的项目介绍文”，不出十分钟，一篇结构清晰、术语准确、连阅读时长都算得刚刚好的文章就出来了。改改措辞，核对几个技术细节，补一张封面图，直接就能发布上线。

省事，真的省事。

做跨境电商自动上架系统那阵子，我每天泡在 BigSeller、Shopee 店铺规则和表格批量处理里。功能跑通的那一刻，只想往椅背上一瘫，完全不想再把已经折腾过一遍的东西整理成文章。换作以前，项目背景、实现逻辑、使用说明，至少还要花一两个晚上慢慢磨；现在把文档交给 AI，一篇近两千字的初稿很快就能摆在面前。

后来做 AI 无限画布工作流也是一样。从 Firefly 节点调试到 GPT Image 接入，从画布布局到批量出图逻辑，整个过程踩了不少坑。但真要写文章的时候，我的第一反应还是打开 AI：“帮我把这套电商主图生成工作流写成博客。”

效率拉满，但总觉得哪里不太对。

隔着窗看向远处，也像是在重新看自己的表达

十分钟生成一篇“正确”的文章#

如果只从结果看，AI 写项目介绍几乎挑不出什么大问题。

它知道应该先讲痛点，再讲架构；知道把一堆零散功能整理成几个模块；也知道在结尾补上一段愿景，让一个还在迭代中的项目显得完整而有方向。它能精准地写出：“这套系统打通了 BigSeller、Shopee 与 TikTok Shop，实现了批量上架自动化。”也能清晰地拆解：“无限画布工作流包含产品图导入、提示词编排、风格参考与批量生成。”

这些话都没错，甚至比我临时组织出来的表达更准确。

更麻烦的是，它不只写得快，有时还写得比我好。标题更像标题，小节更像小节，句子长短有节奏，连那些我脑子里只有模糊轮廓的想法，它也能替我补成一段听起来很成熟的论述。

从效率的角度，我实在找不到拒绝它的理由。

但“正确”慢慢变成了一种很奇怪的东西。文章什么都有：背景、功能、流程、优势、愿景，唯独少了一点只有我知道的东西。

它写不出我最开始做自动上架工具的起因，是运营时一天要上架几十款商品，重复操作到鼠标手犯了，才咬着牙想写个脚本解放自己。它也写不出调试接口时，一个参数没对齐卡了整整一下午，最后发现不是我理解错了，而是文档真的写错了。那种想生气又忍不住觉得荒唐的心情，不在 README 里，也不在代码注释里。

它能整理无限画布的模块，却不知道我第一次跑通全流程时，看着一整张画布上的主图方案依次生成，比自己出了爆款还开心。它更不知道我为什么放着现成的 AI 绘图工具不用，非要搭一套本地画布：因为市面上的工具很方便，但永远没法完全贴合跨境电商主图那些细碎、麻烦、又不能忽略的规则。

AI 能读取项目，却没有经历项目。

AI 可以迅速铺开一整张信息画布，但经历仍然来自画布之外

真正不对劲的，不是 AI 替我写了#

今天对着站点归档发愣的时候，我突然反应过来：我好像已经很久没有“手写”过一篇完整的文章了。

不是因为没东西可写。恰恰相反，项目越做越多，能写的内容也越来越多。只是每次准备记录时，我都会自然地选择最快的路径：整理资料，交给 AI，核对事实，发布。

这个流程没有错。问题在于，当我把所有表达都外包出去，博客也很容易从“我经历过什么”变成“我完成过什么”。前者是成长记录，后者更像项目陈列柜。

想起写《从零搭建 Rainzt.cn》的时候，那是几篇文章里唯一一篇从头写到尾的。从本地 Astro 项目初始化，到宝塔面板 Nginx 配置，再到 HTTPS 证书踩的坑，每一步都是自己走过的，每一行命令也都是亲手敲过的。

写的时候没觉得它有多特别。现在回头看，文章里那些不够规整的叙述、细碎的报错和临时补上的提醒，反而比一篇标准的项目介绍更有温度。因为它不只是告诉别人“怎么搭博客”，也保留了当时的我怎么理解问题、怎么走弯路、怎么把站点一点点推上线。

真正让我不舒服的，从来不是 AI 参与写作，而是我差点只留下结果，没有留下自己。

我对 AI 的感受，是兴奋也是不安#

我其实很喜欢现在的 AI。

它把很多过去需要先学习很久才能开始的事情，变成了“先做起来，再边做边学”。不熟悉前端，也可以一边描述需求一边搭页面；不会设计完整工作流，也可以先让 AI 帮忙拆模块；面对陌生代码库，不再需要从第一行硬啃到最后一行，AI 可以先给出地图，再陪着定位问题。

这种能力很容易让人上瘾。想法和成品之间原本隔着一大片重复劳动，现在那段距离被迅速压短。以前一个念头可能只停在备忘录里，现在真的有机会在当天变成能运行的东西。

但不安也来自同一个地方。

当文字、代码、图片甚至视频都能快速生成，完成一件作品不再天然等于投入了多少时间。过去我们常常通过“他写了多少”“他做了多久”判断一件事的分量，未来这些线索会越来越不可靠。一个人可能没有写过其中的大部分代码，却真正决定了产品该解决什么问题；也可能生成了上万字内容，却没有一句是自己认真相信的。

AI 让产出变得便宜，也让判断变得昂贵。

我现在越来越在意的，不是“这个东西是不是亲手一行行做出来的”，而是另外几个问题：为什么要做？你选择保留什么、舍弃什么？遇到冲突时相信哪条原则？结果出了问题，谁愿意承担责任？

这些问题暂时还不能交给一个“生成”按钮。

人与技术真正有意思的地方，不是彼此替代，而是如何碰到一起

未来的 AI，可能不会再像一个聊天框#

现在我们习惯打开一个窗口，输入提示词，等待 AI 回答。可我觉得这种“我问一句，它答一句”的形态，只是很早期的界面。

接下来的 AI 会越来越像一层安静的工作环境。它知道我正在维护哪个项目，理解之前做过的决定，能读取文档、操作工具、检查运行结果，也能在任务持续几天甚至几周时保留上下文。它不只给建议，还会真的执行：修改代码、生成素材、整理数据、运行测试、发布版本，再把需要人判断的部分交回来。

到那时，“会不会写提示词”可能没现在想象得那么重要。真正重要的会变成：能不能把模糊的愿望说成清楚的目标，能不能给出边界和约束，能不能判断结果到底好不好，能不能在效率、成本、风险和体验之间做取舍。

这也是我做自动上架系统和无限画布时越来越明显的感受。工具真正成熟以后，人不应该一直盯着每个按钮和步骤；人更应该决定规则，处理例外，观察结果，再把新的经验沉淀回系统。AI 会吃掉大量机械执行，却不会自动替我们决定“什么值得被做”。

也许未来最稀缺的不是生产内容的能力，而是提出一个真问题的能力。

当所有人都可以快速生成一篇像样的文章、一张漂亮的图、一段能运行的代码时，真正拉开差距的会是经验、审美、取舍和长期积累。AI 可以组合已知答案，但一个人为什么在某天突然想做一个工具，为什么对某个细节执着，为什么愿意为一个看似很小的问题连续调试几天，这些东西仍然来自具体的生活。

AI 可以帮我描述今天，却不能替我活过今天。

使用 AI，不等于放弃原创#

我不太想把“亲手写”和“AI 写”分成非黑即白的两边。

原创也不一定意味着每个字都必须从键盘上纯手工长出来。摄影师不需要自己制造相机，程序员也不会因为使用开源库就失去作品署名。对我来说，更重要的是文章的经验从哪里来，观点是不是我真正认同的，最后呈现的内容由谁确认、谁负责。

如果 AI 写出了一段很漂亮的话，但我自己并不相信，只因为它听起来像正确答案就放进文章，那它很难算是我的表达。反过来，如果经历是我的，困惑是我的，判断和取舍也是我的，AI 帮我整理结构、调整节奏、删掉重复，我并不觉得这会让文章失去价值。

关键不是有没有用 AI，而是使用 AI 之后，我还在不在里面。

所以以后写项目介绍，我大概还是会继续让 AI 帮忙。技术结构、功能清单、流程说明，本来就适合交给它整理。它能让我少耗几晚时间，把精力留给真正需要解决的问题。

但我也想给自己留下一小块不追求效率的地方。写一点踩坑时的吐槽，记下功能跑通那一刻的心情，承认某些选择其实没有宏大的理由，只是我当时觉得这样更顺手。哪怕句子没那么漂亮、结构没那么标准，也至少能让我几年后再打开博客时，认得出那是自己留下的声音。

技术会继续向前，而我也想在路上保留一点自己的声音

给那剩下的 10%#

博客当然可以是一块项目展示板。它可以有 AI 生成的、规整清晰的技术说明，也可以快速记录每次上线和版本更新。工具本来就是用来解决问题的，我做自动化、搭 AI 工作流，本来就是因为我相信效率能把人从重复劳动里释放出来。

但博客也应该容得下一些没那么“有用”的文字。

可能是一次失败后的复盘，可能是做完项目的碎碎念，也可能只是像今天这样，忽然对着几篇文章产生的一点怀疑。它们不一定能带来搜索流量，也不一定能成为教程，却能组成一条更真实的时间线。

AI 能帮我完成 90% 的项目文案。剩下那 10%，可能不够专业，也很难批量生产，但它恰好记录了我为什么开始、为什么坚持、为什么在某个瞬间感到开心或疲惫。

这 10% 不需要和 AI 对抗。它只是提醒我，在享受效率的时候，别把自己的感受也一起自动化掉。

以后我大概还是会一边用 AI 快速做项目，一边偶尔慢下来写点这样的东西。因为博客说到底，不只是给别人看的作品列表，也是写给未来自己的成长记录。

其实写到一半还是觉得Ai写的方便，所以上面这些还是Ai写的（苦笑）

AI 无限画布工作流：为电商主图生成搭建一套可编排的创作中枢

Tue, 21 Jul 2026 00:00:00 GMT

电商主图的生产，往往卡在一种看似琐碎、实际高频的往返里：找产品图、写场景描述、补品牌规则、调整视觉风格、反复生成，再把满意的结果归档。单次操作并不复杂，但一旦要做批量素材、多人协作或持续迭代，素材、提示词和结果就很容易散落在不同工具与文件夹里。

这套 AI 无限画布工作流，想解决的正是这件事。它是一套面向电商主图批量生成的本地可视化工作台，把创作过程从一串零散操作，变成一张可以看见、编辑、复用和追溯的生产地图。

为什么要做这套画布#

传统图片生成通常以对话或单个表单为入口，适合快速尝试，却不擅长表达完整的创作关系。产品图从哪里来，使用了哪版场景提示词，参考了哪张风格图，哪次生成最适合上架，往往需要靠人工记忆和文件命名维持。

无限画布提供了另一种组织方式：每一个输入、规则、模型调用和结果都是一个节点；节点之间的连线，就是素材流动和决策发生的路径。画布不是装饰，它让工作流本身成为可阅读、可讨论的内容。

AI 无限画布总览

现在先把图片主图跑稳#

当前版本聚焦图片，目标不是做一个只会出图的入口，而是把电商主图生产中真正需要反复使用的部分固定下来。

从产品图开始，可以连接场景描述、参考风格、品牌文案与商品卖点，再把这些信息汇入视觉提示词节点和 GPT Image 生成节点。生成完成后，结果图会直接回到画布中，成为下一轮调整、对比或复用的输入。

这种结构很适合电商素材：同一件商品可以快速尝试不同场景和构图；同一套品牌规则也可以被多个商品项目复用。创作不再从空白提示词开始，而是从已经沉淀下来的工作流继续。

主图工坊

节点化，让规则可以复用#

画布中的节点不是单一的“输入框”。它们承载的是不同类型的生产信息：

产品图片和商品信息，定义画面的主体。
场景、风格和参考图，控制画面的氛围与视觉方向。
文案规则和品牌约束，保证素材能够被实际使用。
视觉提示词和图片生成节点，把前面的信息汇总为可执行的生成任务。
预览、结果和执行状态节点，帮助快速判断一次任务是否值得保留。

节点库把这些能力按用途整理，画布则允许它们按实际需求自由组合。对于一个成熟的主图方案，可以保存为模板；对于一次试验，也可以局部替换一个节点，而不影响整张画布的其他部分。

节点库与工作流编排

运行前校验，运行后复盘#

一套可以进入日常生产的工作流，不能只在“生成”时出现。画布会在执行前检查必要输入与节点连接，让缺少产品图、提示词或生成配置的问题尽量提前暴露。

执行过程中的状态、日志和结果也会留在项目内。这样一来，某张主图为什么有效、使用了什么组合、下一次该从哪里继续优化，都不需要重新猜测。项目切换、工作流保存和结果归档，最终服务的是一种更稳定的创作节奏。

从图片走向视频#

图片是这套系统的第一站，也是最需要先跑稳的一站。主图生成已经具备了清晰的输入、规则、模型执行和结果回收链路，而这套链路天然可以继续向视频扩展。

未来的视频画布会继续沿用同一套可编排思路：把商品资产、脚本、分镜、镜头参考、关键帧、配音与视频提示词放到同一张工作流中；生成后的片段再进入预览、筛选、拼接与复盘。最终输出不只是单张电商主图，而是一条能够适配不同平台节奏的商品短视频。

愿景：把素材生产变成可编排的系统#

AI 的价值不应该只停留在“更快生成一张图”。更值得建设的是一套能持续积累的生产系统：每次尝试都会留下可复用的节点、规则和路径；每个成功案例都能变成下一次创作的起点。

这张无限画布会先帮助图片主图生产变得更清晰、更可控，随后逐步连接到视频内容。让产品素材从静态图片到动态短片，都能在同一个工作流里被组织、生成、评估和持续优化。

访客第一次打开博客时，我想先认真说一句欢迎

Sun, 19 Jul 2026 00:00:00 GMT

很多个人博客会在访客进入时弹出提示。有的展示浏览器和操作系统，有的显示 IP、天气和访问次数，也有的连续弹出好几条通知。

我喜欢“有人来时说一句欢迎”这个想法，却不希望它变成开门后的第一道障碍。于是这次做的欢迎提示很轻：只在同一浏览会话第一次打开网站时出现，从右下角进入，停留几秒后自己离开。

首次访问时出现的欢迎提示

欢迎应该出现一次，而不是每页一次#

Firefly 在站内跳转时会替换页面内容。如果每次切换路由都重新执行欢迎逻辑，访客从首页打开文章、再去工具页，会连续看到同一条提示。

我使用 sessionStorage 保存一个会话标记：

1
const key = "rain_welcome_seen_v1"
2

3
if (sessionStorage.getItem(key)) return
4
sessionStorage.setItem(key, "true")

只要当前标签页没有关闭，它就不会再次出现。重新打开一个新会话时，欢迎提示才会回来。

我没有使用长期的 localStorage，因为那会让看过一次的访客以后永远见不到；也没有使用 Cookie，因为这个状态只和页面体验有关，不需要发给服务器。

先显示，再尝试获取所在地#

提示出现时，会先根据本地时间生成一句问候：

早晨显示“早上好”；
下午显示“下午好”；
深夜则把语气放轻。

随后才在后台请求所在地。如果接口顺利返回，文案会补充为“来自某地的朋友，很高兴遇见你”；如果请求超时、被浏览器拦截或接口暂时不可用，就保留普通欢迎语。

这一步的顺序很重要。第三方接口不应该决定组件能不能出现，更不能拖慢博客正文。请求设置了较短超时，并且使用 AbortController 主动终止。定位只是锦上添花，失败不是页面错误。

动画要让人看见，也要允许离开#

弹窗使用位移、缩放和透明度完成进入动画，时间控制得比较短。右上角保留关闭按钮，不要求访客一定等自动计时结束。

在手机上，它会避开底部悬浮导航；如果系统开启“减少动态效果”，位移动画会被取消，只做轻微淡入淡出。

这些处理看起来比“显示一段文字”复杂，但它们共同决定了提示会不会打扰人：

不遮挡主要按钮；
不抢占页面焦点；
可以手动关闭；
几秒后自动消失；
同一会话不重复；
接口失败不报错。

建立欢迎提示组件#

组件放在：

1
src/components/features/WelcomeToast.astro

它不是侧栏内容，而是覆盖在页面右下角，所以直接写成全局功能组件：

1
<welcome-toast
2
  class="welcome-toast"
3
  aria-live="polite"
4
  aria-atomic="true"
5
  data-state="idle"
6
>
7
  <div class="welcome-toast-icon">✦</div>
8
  <div>
9
    <span class="welcome-toast-kicker">WELCOME</span>
10
    <strong class="welcome-toast-title">欢迎来到朝朝听雨</strong>
11
    <p class="welcome-toast-message">很高兴在这里遇见你。</p>
12
  </div>
13
  <button class="welcome-toast-close" aria-label="关闭欢迎提示">×</button>
14
</welcome-toast>

aria-live="polite" 会让辅助技术在合适的时机读出提示，又不会强行打断正在阅读的内容。

显示与关闭只依赖 data-state：

1
.welcome-toast {
2
  opacity: 0;
3
  pointer-events: none;
4
  transform: translateY(calc(100% + 2rem)) scale(0.96);
5
  transition:
6
    opacity 320ms ease,
7
    transform 420ms cubic-bezier(0.22, 1, 0.36, 1);
8
}
9

10
.welcome-toast[data-state="visible"] {
11
  opacity: 1;
12
  pointer-events: auto;
13
  transform: translateY(0) scale(1);
14
}

在窄屏下要给底部导航留出空间：

1
@media (max-width: 640px) {
2
  .welcome-toast {
3
    right: 1rem;
4
    bottom: calc(5rem + env(safe-area-inset-bottom));
5
    left: 1rem;
6
    width: auto;
7
  }
8
}

会话判断与定位回退#

初始化时先读 sessionStorage，没有标记才延迟显示：

1
connectedCallback() {
2
  if (sessionStorage.getItem("rain_welcome_seen_v1")) return
3

4
  this.querySelector(".welcome-toast-close")
5
    ?.addEventListener("click", () => this.close(), { once: true })
6

7
  this.showTimer = window.setTimeout(() => this.show(), 850)
8
}

show() 中先写入会话标记并显示普通欢迎语，再发起定位请求：

1
sessionStorage.setItem("rain_welcome_seen_v1", "true")
2
this.dataset.state = "visible"
3

4
const response = await fetch("https://v2.xxapi.cn/api/ip", {
5
  signal: this.abortController.signal,
6
})

接口返回结构可能变化，因此不要直接假设地址一定在某个字段。我的处理会依次尝试 data.address、data.location、data.city 等候选值。任何异常都会进入 catch，保留“很高兴在这里遇见你”的默认文本。

为了防止请求长时间占用，设置 3.5 秒超时：

1
this.abortController = new AbortController()
2
const timeout = window.setTimeout(
3
  () => this.abortController?.abort(),
4
  3500,
5
)

关闭组件或离开页面时，也要终止请求并清理计时器。

挂载到全局布局#

在 src/layouts/Layout.astro 顶部导入：

1
import WelcomeToast from "@components/features/WelcomeToast.astro"

然后在 body 末尾、其他全局效果附近挂载：

1
<SakuraEffect />
2
<WelcomeToast />
3
<FancyboxManager />

测试“只出现一次”时，普通刷新不会再次显示，因为当前标签页的 sessionStorage 仍然存在。可以新开一个标签页，或者在开发者工具的 Application 面板中删除 rain_welcome_seen_v1 后再刷新。

还需要主动测试断网或接口失败的情况。一个合格的欢迎提示应该在没有定位数据时照常出现和关闭，而不是在控制台抛出未处理异常。

个性化不等于收集更多信息#

位置欢迎很容易继续扩展：显示 IP、网络运营商、浏览器、系统版本，甚至根据天气改变文案。

我没有继续加。访客来到博客，是为了看内容，不是为了被告知网站识别出了多少信息。现在只使用接口返回的概略地区来组织一句话，获取不到就立刻退回普通欢迎，并且不保存这些数据。

这也符合我对第二代博客的想法：可以有技术细节，也可以有一点个人气息，但不需要把每一种能力都展示出来。

欢迎提示最终只停留几秒。它不会成为网站里最重要的功能，却能在第一次见面时替我说一句：你好，欢迎来到朝朝听雨。

把一年、一个月和一周放进三条进度条

Fri, 17 Jul 2026 00:00:00 GMT

做定制项目的时候，时间通常以交付日期存在：还有几天要上线，今天必须完成哪一部分，下一轮反馈什么时候回来。

项目告一段落以后，我想在博客里放一种没那么紧张的时间提醒。它不催我完成任务，只把一年、一个月和一周走到哪里，用三条进度条安静地显示出来。

时间进度与倒计时组件

三条进度，代表三种尺度#

组件放在右侧栏，依次显示：

本年已经过去的比例，以及还剩多少天；
本月已经过去的比例，以及还剩多少天；
本周已经走到哪一天，以及周末前还剩多少天。

下方再单独留一块区域，显示距离下一个节日还有多久。最初这里只保留元旦、劳动节和国庆节，结果到了 2026 年 7 月，组件直接把“下一站”指向了国庆节，漏掉了 9 月 25 日的中秋节。

现在的节日表分成三类：

国内节日与纪念日，例如春节、清明、劳动节、国庆节；
农历传统节日，例如元宵、端午、七夕、中秋、重阳和除夕；
常见国际节日，例如情人节、复活节、母亲节、父亲节、万圣夜、感恩节和圣诞节。

这样做以后，“全面”不再等于堆一串当年日期。公历固定节日、按星期计算的节日和农历节日分别使用不同算法，第二年仍然能够继续工作。

日期计算最怕看起来差不多#

本月进度最简单：获取今天是几号，再除以当月总天数。

本年进度需要考虑闰年：

1
const daysInYear =
2
  (year % 4 === 0 && year % 100 !== 0) || year % 400 === 0
3
    ? 366
4
    : 365

周进度则要处理 JavaScript 中星期日等于 0 的情况。我把星期一到星期日统一映射成 1 到 7，这样进度条和“还剩几天”的文案更直观。

另一个容易忽略的问题是夏令时。直接用两个本地时间相减，在采用夏令时的地区可能遇到一天不是完整 24 小时的情况。计算天数时，我先把年月日转换到 UTC 的零点，再用毫秒差换算，避免时区偏移让倒计时多一天或少一天。

不需要每秒重新计算#

这块组件展示的最小单位是“天”，没有必要像时钟一样每秒甚至每分钟更新。

页面加载时计算一次，然后只安排一个定时任务，等到下一个本地零点重新刷新。组件被移除时，定时器也会清理：

1
connectedCallback() {
2
  this.update()
3
  this.scheduleMidnightUpdate()
4
}
5

6
disconnectedCallback() {
7
  clearTimeout(this.midnightTimer)
8
}

这种写法对 Firefly 的无刷新页面切换更友好。它不会因为在首页和文章页之间来回跳转，就留下越来越多的后台任务。

组件结构与进度条样式#

组件文件为：

1
src/components/widget/ScheduleProgress.astro

每一行由百分比、说明文字和进度轨道组成：

1
<div class="progress-row" data-kind="year">
2
  <span class="progress-percent">--%</span>
3
  <div class="progress-detail">
4
    <span class="progress-copy">本年还剩 -- 天</span>
5
    <div class="progress-track">
6
      <i></i>
7
    </div>
8
  </div>
9
</div>

我没有直接使用原生 <progress>，而是用普通元素控制宽度。这样渐变、发光和过渡动画更容易统一：

1
.progress-track {
2
  height: 0.42rem;
3
  overflow: hidden;
4
  border-radius: 999px;
5
  background: var(--btn-regular-bg);
6
}
7

8
.progress-track i {
9
  display: block;
10
  width: 0;
11
  height: 100%;
12
  border-radius: inherit;
13
  background: linear-gradient(90deg, #8de6d1, var(--primary));
14
  transition: width 650ms cubic-bezier(0.22, 1, 0.36, 1);
15
}

展开收起

脚本更新时只需要修改文字与 width：

1
private setProgress(kind: string, percent: number, copy: string) {
2
  const row = this.querySelector(
3
    `.progress-row[data-kind="${kind}"]`,
4
  )
5

6
  row.querySelector(".progress-percent").textContent =
7
    `${percent.toFixed(1)}%`
8
  row.querySelector(".progress-copy").textContent = copy
9
  row.querySelector(".progress-track i").style.width =
10
    `${Math.min(percent, 100)}%`
11
}

计算年、月、周进度#

核心更新函数可以按下面的顺序组织：

1
const now = new Date()
2
const year = now.getFullYear()
3
const month = now.getMonth()
4
const today = now.getDate()
5

6
const daysInMonth = new Date(year, month + 1, 0).getDate()
7
const weekday = now.getDay() || 7
8

9
const startOfYear = new Date(year, 0, 1)
10
const startOfToday = new Date(year, month, today)
11
const dayOfYear =
12
  Math.floor((startOfToday.getTime() - startOfYear.getTime()) / 86400000) + 1

再分别传给 setProgress：

1
this.setProgress(
2
  "month",
3
  (today / daysInMonth) * 100,
4
  `本月还剩 ${daysInMonth - today} 天`,
5
)
6

7
this.setProgress(
8
  "week",
9
  (weekday / 7) * 100,
10
  `本周还剩 ${7 - weekday} 天`,
11
)

三类节日要用三种算法#

固定公历日期最直接，月份仍然从 0 开始：

1
const fixedFestivals = [
2
  { name: "元旦", month: 0, day: 1, kind: "国内" },
3
  { name: "情人节", month: 1, day: 14, kind: "国际" },
4
  { name: "国庆节", month: 9, day: 1, kind: "国内" },
5
  { name: "圣诞节", month: 11, day: 25, kind: "国际" },
6
]

母亲节、父亲节和感恩节不是固定几号，而是“某月第几个星期几”。我写了一个通用函数：

1
function nthWeekdayOfMonth(
2
  year: number,
3
  month: number,
4
  weekday: number,
5
  nth: number,
6
) {
7
  const first = new Date(year, month, 1)
8
  const offset = (weekday - first.getDay() + 7) % 7
9
  return new Date(year, month, 1 + offset + (nth - 1) * 7)
10
}
11

12
const mothersDay = nthWeekdayOfMonth(year, 4, 0, 2)
13
const thanksgiving = nthWeekdayOfMonth(year, 10, 4, 4)

上面的 0 代表星期日，4 代表星期四。复活节的规则更特殊，组件使用 Gregorian computus 算法单独计算。

农历节日没有硬编码成 2026 年的公历日期，而是借助浏览器自带的中文农历日历：

1
const lunarFormatter = new Intl.DateTimeFormat(
2
  "zh-CN-u-ca-chinese",
3
  { month: "numeric", day: "numeric" },
4
)
5

6
function getLunarMonthDay(date: Date) {
7
  const parts = lunarFormatter.formatToParts(date)
8
  return {
9
    month: Number(parts.find(part => part.type === "month")?.value),
10
    day: Number(parts.find(part => part.type === "day")?.value),
11
  }
12
}

脚本从今天开始向后扫描 400 天，将每天转换成农历月日，再和节日表匹配。这样中秋始终匹配农历八月十五，端午始终匹配五月初五，不需要每年手动改日期。除夕不能写死为腊月三十，因为有些年份腊月只有二十九天；我的判断方式是检查“明天是否为正月初一”，如果是，今天就是除夕。

最后把三类候选日期合并、去重并排序，取第一个不早于今天的日期：

1
return [...unique.values()]
2
  .filter(festival => festival.date >= startOfToday)
3
  .sort((a, b) => a.date.getTime() - b.date.getTime())[0]

2026 年 7 月 24 日之后，完整列表会先显示 8 月 19 日的七夕节，随后是 9 月 25 日的中秋节，不会再直接跳到国庆节。

注册并放到右侧最下面#

与其他侧栏组件一样，需要完成三步：

在 WidgetComponentType 中加入 "scheduleProgress"；
在 SideBar.astro 导入组件并写入 componentMap；
在 rightComponents 最后加入配置。

1
{
2
  type: "scheduleProgress",
3
  enable: true,
4
  position: "sticky",
5
  showOnPostPage: false,
6
}

它被放在右侧配置最后，因此会出现在日历与其他启用组件之后。position: "sticky" 让它属于跟随滚动区域；如果改成 top，它会和时钟、统计等固定顶部组件排在一起。

测试时重点看月末、年末、星期日和闰年二月。日期组件最容易在边界条件出错，普通工作日显示正确并不能说明算法已经完整。

进度条不是为了制造焦虑#

把时间做成百分比，很容易让人产生“今年怎么已经过去这么多”的紧迫感。所以我没有使用警告色，也没有加入“剩余生命”一类过重的文案。

三条进度都沿用博客主题色，数字保持小尺寸，下方倒计时只写“距离下一站”。它更像一个路标，而不是考核表。

有时我会觉得时间很快，电脑里的项目文件夹一批接一批，回过头才发现一个月已经接近尾声。把这些尺度放在侧边栏，至少能让我在打开博客时短暂地意识到：今天属于这一周，也属于这个月和这一年。

工具提醒我把工作做完，进度条则提醒我，时间本身也值得被看见。

每天留一句话：我在侧边栏做了一个本地每日一言

Tue, 14 Jul 2026 00:00:00 GMT

重新开始写博客以后，我越来越在意“文字是不是自己的”。

以前赶项目时，我习惯把资料交给 AI，让它快速整理出完整文章。效率很高，可当博客真正准备长期更新时，我又希望页面里能多留一点与文字有关的气息。每日一言正好给了我一个很小的位置：它不需要展开成一篇文章，也不负责讲清某项技术，只是在访客打开首页时，留下一句值得慢慢读的话。

每日一言侧边栏效果

为什么没有直接接语录 API#

网上有很多现成的一言接口，请求一次就能得到一句随机内容。接入确实方便，但我最终没有用。

原因有三个。

第一，第三方接口的速度和稳定性不受我控制。侧边栏本来是静态页面的一部分，不值得为了十几个字增加一次网络依赖。

第二，接口返回什么内容无法预先检查，偶尔可能出现过长、重复或不符合博客气质的句子。自己维护内容，排版和语气都更可控。

第三，也是最重要的一点：我想让它逐渐变成自己筛选过的句子库，而不是另一个站点内容的转发器。

所以组件内放的是十条经过核对的经典名句，例如：

千里之行，始于足下。

学而不思则罔，思而不学则殆。

纸上得来终觉浅，绝知此事要躬行。

十条内容来自《道德经》《论语》《荀子》以及陆游、屈原的诗文。它们都保存在本地数组中，页面不需要为了十几个字再等待一次网络请求。

今天固定，明天再换#

“今日一言”不应该像轮播图一样十几秒换一次。我的规则很简单：语录库里共有十条，同一天无论刷新多少次都显示同一句，日期变化后再显示下一句。

实现时先把访客本地日期换算成一个稳定的天数，再对语录总数取余：

1
const now = new Date()
2
const dayNumber = Math.floor(
3
  Date.UTC(now.getFullYear(), now.getMonth(), now.getDate()) / 86_400_000,
4
)
5
const quoteIndex = dayNumber % quotes.length

这里使用年、月、日，而不是当前的小时和分钟，所以刷新页面不会改变结果。天数每天只增加一，索引也会依次向后移动；十条全部出现一遍后，再从第一条重新开始。

让它看起来像一句旁白#

视觉上我没有给它加复杂背景，只沿用侧边栏卡片：

标题是“今日一言”；
正文使用略微倾斜的字形；
两侧引号用主题色降低透明度；
作者放在右下角；
鼠标经过时，正文才轻轻变成主题色。

它的存在感比时间卡片低，也比统计组件更松。页面滚动到这里时，像在一组数字和工具之间短暂停了一下。

把每日一言做成可注册的侧栏组件#

组件文件放在：

1
src/components/widget/QuoteOfTheDay.astro

外层继续使用主题自带的 WidgetLayout，这样圆角、标题、内边距和暗色模式不用重新造一套：

1
---
2
import WidgetLayout from "@/components/common/WidgetLayout.astro"
3
const { class: className, style } = Astro.props
4
---
5

6
<WidgetLayout
7
  id="quote-of-the-day"
8
  name="今日一言"
9
  class={className}
10
  style={style}
11
>
12
  <daily-quote>
13
    <blockquote>
14
      <span class="quote-mark">“</span>
15
      <span class="quote-text">慢一点，也是在向前走。</span>
16
      <span class="quote-mark">”</span>
17
    </blockquote>
18
    <cite class="quote-author">—— Rain</cite>
19
  </daily-quote>
20
</WidgetLayout>

展开收起

文字数组和日期选择逻辑放在组件脚本中。每一项都保存正文与署名，后续也可以把署名换成书名、项目名或记录日期：

1
const quotes = [
2
  ["千里之行，始于足下。", "《道德经》"],
3
  ["学而不思则罔，思而不学则殆。", "《论语》"],
4
  ["纸上得来终觉浅，绝知此事要躬行。", "陆游"],
5
] as const
6

7
class DailyQuote extends HTMLElement {
8
  private midnightTimer?: number
9

10
  connectedCallback() {
11
    this.showTodayQuote()
12
    this.scheduleMidnightRefresh()
13
  }
14

15
  disconnectedCallback() {
16
    if (this.midnightTimer) clearTimeout(this.midnightTimer)
17
  }
18

19
  private showTodayQuote() {
20
    const now = new Date()
21
    const dayNumber = Math.floor(
22
      Date.UTC(now.getFullYear(), now.getMonth(), now.getDate()) / 86_400_000,
23
    )
24
    const index = dayNumber % quotes.length
25
    const [text, author] = quotes[index]
26
    this.querySelector(".quote-text")!.textContent = text
27
    this.querySelector(".quote-author")!.textContent = `—— ${author}`
28
  }
29

30
  private scheduleMidnightRefresh() {
31
    const now = new Date()
32
    const nextMidnight = new Date(
33
      now.getFullYear(),
34
      now.getMonth(),
35
      now.getDate() + 1,
36
    )
37

38
    this.midnightTimer = window.setTimeout(() => {
39
      this.showTodayQuote()
40
      this.scheduleMidnightRefresh()
41
    }, nextMidnight.getTime() - now.getTime() + 100)
42
  }
43
}
44

45
customElements.define("daily-quote", DailyQuote)

展开收起

如果项目启用了无刷新切页，注册前需要先判断元素是否已经存在，避免重复定义报错：

1
if (!customElements.get("daily-quote")) {
2
  customElements.define("daily-quote", DailyQuote)
3
}

注册到左侧栏#

先在 src/types/sidebarConfig.ts 中加入类型：

1
export type WidgetComponentType =
2
  | "profile"
3
  | "announcement"
4
  | "quoteOfTheDay"
5
  // ...

再在 SideBar.astro 中导入并注册映射：

1
import QuoteOfTheDay from "@/components/widget/QuoteOfTheDay.astro"
2

3
const componentMap = {
4
  // ...
5
  quoteOfTheDay: QuoteOfTheDay,
6
}

我把它放在左侧资料与公告之后、音乐播放器之前：

1
{
2
  type: "quoteOfTheDay",
3
  enable: true,
4
  position: "top",
5
  showOnPostPage: false,
6
}

这里的顺序就是实际渲染顺序。想把它移到右边，不需要改组件，只要把这段配置从 leftComponents 移到 rightComponents。

修改内容时要注意什么#

如果句子里包含英文引号、反斜杠或换行，记得按照 TypeScript 字符串规则转义。句子过长时，侧栏会明显变高，因此我会尽量控制在一到两行。

日期索引会严格按顺序走完十条。想确认逻辑是否正确，可以在浏览器控制台中临时把日期改成连续几天，检查索引是否依次变化；同时反复刷新当天页面，确认正文始终一致。

我还额外设置了一个指向本地午夜的定时器。这样即使页面从晚上一直开到第二天，它也会在零点后主动更新，而不必依赖访客手动刷新。组件被移除时要清理这个定时器，避免无刷新切页后留下多余任务。

文字库会跟着博客一起长大#

这个组件现在保留十句话，不算很多，但每条都经过选择。

有些内容适合写成长文，有些只值得记成一行。以后做完新的自动化项目、踩过新的坑，或者某天只是突然想明白一件小事，我都可以把它补进去。几年之后再看，这个数组也许会变成一份非常简短的时间线。

每日一言真正吸引我的地方，不只是它会自动变化，而是它给零散文字留了一个固定入口。博客不只有完整、正式、可以被搜索到的文章，也可以有这些短暂停留，却仍然值得被记住的句子。

连鼠标指针也换掉：给第二代博客补上一点自己的细节

Sun, 12 Jul 2026 00:00:00 GMT

做网站时，我通常会先处理最显眼的部分：横幅、文章卡片、侧边栏、配色和字体。鼠标指针几乎总被留到最后，因为它不影响内容，也不会决定页面能不能使用。

可博客真正打开以后，鼠标又是桌面端最频繁出现的元素。它一直在页面上移动，经过导航、文章链接、播放器按钮和工具入口。默认箭头没有问题，只是和我已经重新整理过的第二代博客相比，显得过于“系统自带”。

于是这次我给它换了两枚本地光标。

自定义光标在页面中的效果

只做两种状态就够了#

我没有做跟随鼠标的粒子、拖尾或点击烟花。博客页面已经有壁纸轮播、水波纹和樱花效果，再叠一层持续运行的鼠标动画，只会增加干扰。

最终只保留两种状态：

普通浏览时使用默认光标；
遇到链接、按钮和可点击控件时切换为指针光标。

两枚 .cur 文件放在 public/mouse/，CSS 用变量统一管理：

1
:root {
2
  --cursor-default: url("/mouse/default.cur"), default;
3
  --cursor-pointer: url("/mouse/pointer.cur"), pointer;
4
}

这里的第二个值不是多余的。如果自定义文件加载失败，浏览器仍然能回退到系统的 default 或 pointer，页面不会因此失去正确的交互提示。

默认与可点击状态使用不同的光标文件

可点击，不等于所有元素都用手型#

最开始很容易写成：

1
* {
2
  cursor: url("/mouse/default.cur"), default;
3
}

这样虽然省事，却会把输入框和文本区域也覆盖掉。用户准备选中文字或输入内容时，光标仍然是一枚普通箭头，反而削弱了浏览器原本清楚的提示。

所以我只给明确的交互元素使用指针光标，包括链接、按钮、下拉框、role="button" 和站内已有的 .cursor-pointer。输入框、文本域与可编辑区域继续使用系统文本光标。

这类细节很小，但它决定了自定义样式是在增强界面，还是只是在覆盖默认行为。

只在真正有鼠标的设备上启用#

手机和平板没有悬停指针，没必要加载或应用桌面光标样式。我把规则放进了媒体查询：

1
@media (hover: hover) and (pointer: fine) {
2
  /* cursor rules */
3
}

只有同时支持悬停、并且具有精确指针的设备才会启用。触屏端保持原样，也不会为了一个用不到的效果增加额外逻辑。

完整接入步骤#

首先准备两枚 .cur 文件，并按下面的结构放进 public：

1
public/
2
└─ mouse/
3
   ├─ default.cur
4
   └─ pointer.cur

public 中的文件会原样复制到构建结果，因此页面访问路径分别是 /mouse/default.cur 和 /mouse/pointer.cur。如果文件名使用中文或空格，虽然也可能访问成功，但更容易在 CSS 转义和服务器迁移时出问题。

接着新建 src/styles/mouse.css。下面是站内实际使用的完整规则：

1
@media (hover: hover) and (pointer: fine) {
2
  :root {
3
    --cursor-default: url("/mouse/default.cur"), default;
4
    --cursor-pointer: url("/mouse/pointer.cur"), pointer;
5
  }
6

7
  html,
8
  body {
9
    cursor: var(--cursor-default);
10
  }
11

12
  a,
13
  button,
14
  select,
15
  label,
16
  summary,
17
  [role="button"],
18
  [role="link"],
19
  .cursor-pointer,
20
  input[type="button"],
21
  input[type="submit"],
22
  input[type="reset"] {
23
    cursor: var(--cursor-pointer);
24
  }
25

26
  input,
27
  textarea,
28
  [contenteditable="true"] {
29
    cursor: text;
30
  }
31
}

展开收起

最后在全局布局 src/layouts/Layout.astro 的 frontmatter 中导入：

1
import "@/styles/main.css"
2
import "@/styles/variables.styl"
3
import "@/styles/markdown-extend.styl"
4
import "@/styles/mouse.css"

这一步必须放在全局布局，而不是某个单独页面。否则首页可能已经换了光标，进入文章页后又恢复系统样式。

怎样确认文件真的生效#

构建成功只代表 CSS 语法没错，不代表 .cur 一定可以读取。可以直接在浏览器打开：

1
http://127.0.0.1:4321/mouse/default.cur
2
http://127.0.0.1:4321/mouse/pointer.cur

再打开开发者工具，检查 body 的计算样式中是否出现自定义 URL。鼠标移到链接上时，计算结果应切换到 pointer.cur；移到正文段落时回到 default.cur；进入输入框时仍然是文本光标。

如果浏览器完全没有变化，优先排查：

文件实际下载成了 HTML 错误页，而不是 CUR 二进制文件；
CSS 写的是相对路径，进入二级路由后找不到文件；
光标尺寸或格式不被当前浏览器支持；
设备被媒体查询识别为触屏设备。

我最终使用绝对路径，并给每条规则都保留系统回退值。这样就算某个浏览器不支持自定义文件，交互语义也不会丢失。

越小的改动，越应该克制#

自定义光标的代码量很少，真正需要判断的是它应该影响哪些地方。

如果把它做得太抢眼，鼠标每移动一次都在提醒访客“这里换过皮肤”，阅读就会被打断。现在这版更像一个不主动解释的彩蛋：不仔细看可能不会立刻发现，可一旦注意到，会知道这个网站连最小的交互状态也经过了选择。

第二代博客对我来说不是一个急着堆满功能的展示站。它可以有个性，但个性不一定都要大声出现。有些只需要跟着鼠标，安静地待在每一次点击之前。

让博客在不同时间说不同的话：侧边栏实时时钟改造记录

Sat, 11 Jul 2026 00:00:00 GMT

最近重新打磨第二代博客时，我开始留意一些并不影响功能，却会影响“这个网站像不像自己”的小地方。

侧边栏原本放着站点统计、日历和音乐播放器，它们各自都很实用，但少了一点会随时间发生变化的东西。于是我加了一块实时时钟：早晨说早上好，中午提醒吃饭和休息，到了晚上则让页面的语气慢下来。

时段问候组件的版式参考

这项改动看上去只是多了几行时间和一句问候，真正做起来却经历了一次很明显的返工。

第一版，做得太像一张海报#

最初我把整张卡片都铺成鸣潮壁纸，在图片上叠暗色渐变，再放一个很大的时间。单独看并不难看，甚至有一点游戏界面的感觉。

可它放进右侧栏以后，问题立刻出现了：信息层级太重，和旁边干净的白色卡片不在同一个体系里。用户第一眼看到的是背景图，而不是时间；卡片像一个缩小的横幅，而不是侧栏部件。

这次偏差也提醒了我，参考一个效果时不能只识别“它有哪些元素”，还要识别这些元素之间的关系。原版真正舒服的地方，是上半部分把问候、时间、星期和日期排得很克制，下半部分才留给图片。它不是在图片上写字，而是把信息和装饰分成了两个区域。

所以第二版我把结构彻底拆开：

上半部分使用博客卡片原有的浅色背景；
时间保持最大字号，问候语放在它上方；
星期和日期缩小后靠在时间右侧；
右上角只留一个跟随时段变化的小图标；
底部固定为横向图片区域。

这样放回右侧栏后，它终于像这个博客原本就有的一部分。

图片必须是我的鸣潮图库#

版式稳定后，我又改了两次图片逻辑。

第一次为了加载速度，直接用了壁纸目录里的缩略图。卡片只有 280 像素宽，看起来似乎够用，但缩略图经过压缩后再裁切，人物细节明显发糊。最后还是换回同一批鸣潮壁纸的原图，让浏览器按卡片尺寸裁切显示。

图片池只读取站内已经整理好的鸣潮壁纸：

1
const images = [
2
  "wallpaper-01.webp",
3
  "wallpaper-25.webp",
4
  // ...
5
  "wallpaper-47.webp",
6
]

每次刷新会重新随机选择一张。这样它不会请求第三方随机图接口，也不会突然出现和站点风格无关的风景照。页面横幅、相册和时钟卡片使用的是同一套视觉素材，整个网站的气质更统一。

时间更新不能留下重复计时器#

Firefly 有无刷新页面切换。如果直接在脚本里写一个全局 setInterval，组件被替换后计时器可能仍然活着，来回切几次页面就会出现多个任务同时更新。

我把它做成了自定义元素，在组件挂载时启动，在移除时清理：

1
connectedCallback() {
2
  this.updateGreeting()
3
  this.alignToNextMinute()
4
}
5

6
disconnectedCallback() {
7
  clearInterval(this.minuteTimer)
8
  clearTimeout(this.alignmentTimer)
9
}

第一次更新会对齐到下一分钟的边界，之后每分钟刷新一次。这样时间不会因为页面打开的秒数不同而慢慢偏移，也能适应站内的页面切换。

问候语按六个时段划分：

深夜：提醒早点休息；
早晨：迎接新的一天；
上午：保持活力；
中午：记得午休；
下午：继续加油；
晚上：适当放松。

从零接入这个组件#

如果要在同一套 Firefly 项目里复现，主要改动四个文件：

1
src/components/widget/TimeGreeting.astro
2
src/components/layout/SideBar.astro
3
src/types/sidebarConfig.ts
4
src/config/sidebarConfig.ts

先建立 TimeGreeting.astro。组件上半部分负责信息，下半部分负责图片：

1
<time-greeting-widget class:list={["time-greeting-card card-base", className]}>
2
  <div class="time-greeting-info">
3
    <div>
4
      <p class="time-greeting-message">正在获取时间...</p>
5
      <div class="time-greeting-meta">
6
        <time class="time-greeting-clock">--:--</time>
7
        <div class="time-greeting-date">
8
          <span class="time-greeting-week">---</span>
9
          <div>
10
            <span class="time-greeting-day">--</span>
11
            <span class="time-greeting-month">/--</span>
12
          </div>
13
        </div>
14
      </div>
15
    </div>
16
  </div>
17
  <div class="time-greeting-image"></div>
18
</time-greeting-widget>

展开收起

时段判断独立成函数，后续改文案时不需要碰 DOM 更新逻辑：

1
function getGreetingPeriod(hour: number) {
2
  if (hour < 6) return { id: "late-night", message: "夜深了，早点休息！" }
3
  if (hour < 9) return { id: "morning", message: "早上好，新的一天！" }
4
  if (hour < 12) return { id: "forenoon", message: "上午好，充满活力！" }
5
  if (hour < 14) return { id: "noon", message: "中午好，记得午休！" }
6
  if (hour < 18) return { id: "afternoon", message: "下午好，继续加油！" }
7
  return { id: "evening", message: "晚上好，放松一下！" }
8
}

鸣潮图片池不必手写二十多个完整路径，可以用编号生成：

1
const images = [
2
  "01",
3
  ...Array.from({ length: 23 }, (_, index) =>
4
    String(index + 25).padStart(2, "0"),
5
  ),
6
].map(index => `/assets/images/wallpaper/wallpaper-${index}.webp`)
7

8
const imageUrl = images[Math.floor(Math.random() * images.length)]

先用 new Image() 预加载，成功后再设置 CSS 变量，可以避免图片下载过程中卡片突然闪白：

1
const image = new Image()
2
image.onload = () => {
3
  this.style.setProperty("--time-greeting-image", `url("${imageUrl}")`)
4
  this.dataset.imageReady = "true"
5
}
6
image.src = imageUrl

CSS 中让图片区读取这个变量：

1
.time-greeting-image {
2
  height: 9rem;
3
  background-image: var(--time-greeting-image);
4
  background-position: center;
5
  background-size: cover;
6
  opacity: 0;
7
  transition: opacity 650ms ease;
8
}
9

10
time-greeting-widget[data-image-ready="true"] .time-greeting-image {
11
  opacity: 1;
12
}

组件完成后，在 SideBar.astro 导入并加入映射：

1
import TimeGreeting from "@/components/widget/TimeGreeting.astro"
2

3
const componentMap = {
4
  // 其他组件
5
  timeGreeting: TimeGreeting,
6
}

然后在 sidebarConfig.ts 的右侧栏中启用：

1
{
2
  type: "timeGreeting",
3
  enable: true,
4
  position: "top",
5
  showOnPostPage: false,
6
}

最后别忘了把 "timeGreeting" 加进 WidgetComponentType 联合类型，否则 TypeScript 会在构建时提示配置值不合法。

本地执行 npm run build 后，至少检查三种情况：刷新页面时图片是否变化；停留到下一分钟时数字是否更新；从首页进入文章页后组件是否按配置隐藏。只看静态截图并不能证明定时器与无刷新切页都正常。

小组件也需要服从整体#

这次改造最有价值的部分，并不是写出了一个时钟，而是把一版“看起来挺酷”的方案主动推倒。

个人博客很容易不断往里加效果。可每一个效果都在争夺注意力，如果只追求单独截图好看，最后页面反而会越来越吵。现在这块时钟保留了鸣潮图片、分时图标和实时变化，也仍然愿意退回到侧栏应有的位置。

它每天会说不同的话，每次刷新会换一张图，但不会压过文章本身。对我来说，这才是这类小组件最合适的状态。

博客页脚定制方案

Fri, 10 Jul 2026 00:00:00 GMT

以前我很少认真看页脚。

搭建第一代博客时，我把它当成页面最后的一行版权文字：写上年份、站点名称，再放一个 RSS 链接，任务就算结束。后来文章越来越多，导航、侧栏、播放器和各种小组件陆续长出来，我才发现页脚其实是读者离开一篇文章之前，最后一次和站点发生关系的地方。

它不适合塞满所有信息，却应该把最需要被记住的内容交代清楚：这个站点用了什么、作者还维护哪些入口、网站运行了多久、版权和备案信息应该去哪里确认。于是这次我没有继续往原来的 FooterConfig.html 里堆标签，而是把页脚重新拆成几个有明确职责的区域。

先确定页脚的内容顺序#

我最后采用了下面这条从“氛围”到“信息”的顺序：

一条轻量的装饰带，让正文和页脚之间有一个缓冲。
技术徽章，说明站点由哪些工具组成。
社交链接，只保留博客、GitHub、Bilibili 三个入口。
运行时间，把“这个站点还活着”变成一个持续变化的数字。
备案提示和版权信息，放在页面最底部，方便查找但不抢视线。

这个顺序有一个很实际的好处：访客先看到站点气质，再看到可继续访问的入口，最后才是法律和版权信息。每一层都很短，手机上也不会变成一堵文字墙。

Astro 组件应该负责什么#

我把页脚放在 src/components/layout/Footer.astro，让它只处理三类事情：

在服务端输出稳定的静态内容，例如徽章、链接和版权年份；
计算站点运行时间的初始值，避免页面加载时出现空白；
在浏览器端每秒更新一次运行时间，其余内容不依赖 JavaScript。

这种拆分比把全部 HTML 放到配置文件里更容易维护。以后要调整颜色和间距，只改组件的样式；要换社交链接，只改 socials 数组；要修改起始日期，则改站点配置，不需要在多个文件里搜索日期字符串。

用数据数组控制技术徽章#

徽章不是为了炫技，所以我没有给每个徽章引入一套很重的图标。当前只显示技术名称，并用不同的低饱和色做区分：

1
const techStack = [
2
  { label: "Astro", tone: "violet" },
3
  { label: "Tailwind CSS", tone: "cyan" },
4
  { label: "Twikoo", tone: "orange" },
5
  { label: "EdgeOne", tone: "blue" },
6
  { label: "Umami", tone: "green" },
7
];

渲染时只需要遍历数组：

1
<div class="stack-row">
2
  {techStack.map((item) => (
3
    <span class={`stack-badge ${item.tone}`}>{item.label}</span>
4
  ))}
5
</div>

这样做有两个好处。第一，增删技术栈不会复制粘贴一大段 HTML；第二，颜色属于 tone，内容和视觉样式彼此独立。将来如果我把评论系统换掉，只需要替换一项数据。

社交链接要设置“允许列表”#

之前的个人资料里还保留了微信和邮箱入口，但这次页脚只放三个链接：博客、GitHub、Bilibili。这里我用了一个明确的数组，而不是把所有 profile links 原样输出：

1
const socials = [
2
  { name: "博客", icon: "material-symbols:home-outline", url: "https://rainzt.cn/" },
3
  { name: "GitHub", icon: "simple-icons:github", url: "https://github.com/Jarvis0227" },
4
  { name: "Bilibili", icon: "simple-icons:bilibili", url: "https://space.bilibili.com/473321504" },
5
];

这相当于给页脚加了一层“允许列表”。个人资料以后可以继续保存私密或备用联系方式，但它们不会因为配置被复用，就意外出现在公开页脚。外链统一加上 target="_blank" 和 rel="noreferrer"，避免读者离开博客后无法快速回来，也减少不必要的来源信息暴露。

运行时间不是一张静态图片#

站点运行时间的起点写在 siteConfig.siteStartDate：

1
siteStartDate: "2026-07-08",

组件先在构建时计算天、小时、分钟和秒，首屏直接得到完整文字；页面加载后再用一个很小的定时器更新数字：

1
const seconds = Math.max(0, Math.floor((Date.now() - startAt) / 1000));
2
const days = Math.floor(seconds / 86400);
3
const hours = Math.floor((seconds % 86400) / 3600);
4
const minutes = Math.floor((seconds % 3600) / 60);
5
const secs = seconds % 60;

这里特意保留了 Math.max(0, ...)。如果服务器时间比起始日期还早，页面不会显示负数；如果以后修改起始日期，也不会让运行时间脚本直接失效。数字使用等宽数字，秒数跳动时文本宽度不会来回抖动。

“萌备案”要和真实备案区分开#

我在页脚里放了两条萌系占位文字：

1
萌ICP备2026070801号
2
萌公网安备2026070801号

它们只是页面气氛的一部分，不是真实备案号。实际备案完成后，应该把文字和链接替换成工信部、公安备案平台提供的正式信息，不能把占位文字当作真实备案展示。这个区分也写进了我的维护笔记，避免未来换服务器或提交备案时忘记修改。

CSS 重点是“收住”#

页脚最容易出现的问题不是不好看，而是太用力。我的处理方式有三点：

用 max-width 限制内容宽度，让信息集中在正文附近；
用 gap 和 flex-wrap 排列徽章与链接，不写死每一行的长度；
颜色使用 color-mix 混合当前文字色，让浅色和深色主题自动保持一致。

徽章采用圆角胶囊，但边框和背景都非常淡；鼠标悬停时只向上移动一像素，不再叠加发光、缩放或大面积渐变。页脚应该像一本书的版权页，能被看见，但不应该抢走文章结尾的注意力。

响应式部分只做必要的调整：小屏幕缩短两侧装饰线、缩小徽章字号、让所有行自动换行。没有给移动端单独复制一套模板，所以桌面和手机看到的是同一份信息，维护成本也更低。

如何验证它真的工作#

完成代码后，我会按下面顺序检查：

执行 npm.cmd run build，确认 Astro 内容图片、图标和页面路由都能通过构建。
打开文章页面滚动到底部，检查页脚是否完整出现。
等待十秒，确认运行时间的秒数持续变化。
逐个点击博客、GitHub、Bilibili，确认没有多余的微信或邮箱入口。
调整浏览器宽度，检查徽章和备案行是否自然换行。
切换深色模式，检查文字对比度和边框是否仍然清楚。

实际页面中的完整页脚效果

最后这张图不是参考站点的截图，而是这次修改后我自己的页面截图。把它放进文章里，一方面是给以后回顾留下一个版本快照，另一方面也能在页脚样式再次调整后，快速对比哪些细节发生了变化。

留给下一次改版的空间#

这次我没有把页脚做成一个“功能展示区”，也没有加入访问量、天气或一长串友情链接。它现在只承担站点身份、联系入口和基础信息三件事。以后如果博客真的需要新增内容，我会优先考虑两种方式：

把内容加进现有的数据数组，让它继续保持可维护的结构；
新增一个独立的、可关闭的区域，而不是把所有东西挤进同一行。

对我来说，第二代博客最重要的变化，就是不再把每个角落都当成产品橱窗。页脚也是如此：它可以有一点可爱、有一点技术感，但最后还是要安静地把一段路送到终点。

从零搭建 Rainzt.cn：我的个人博客上线流程

Wed, 08 Jul 2026 00:00:00 GMT

为什么要搭这个博客#

我想要一个真正属于自己的内容空间。它不只是用来发文章，也用来整理项目、记录折腾过程、放一些自己喜欢的页面和小工具。

最后，我把这套基于 Astro 与 Firefly 深度改造的站点命名为 Aemeath 主题。它保留了静态生成速度快、页面效果完整、文章用 Markdown 管理这些优点，部署后只需要一份 dist 静态文件就能跑起来。对个人博客来说，这种结构足够轻，也足够自由，同时也终于有了更贴近自己审美的名字。

这个站点最终部署在 rainzt.cn，服务器侧使用宝塔面板和 Nginx，HTTPS 证书也已经配置好。

项目准备#

开始之前，先确认本地已经准备好 Node.js 和 pnpm。这个博客使用的是 Astro 项目结构，内容、配置和静态资源都放在源码目录中维护，生产环境只需要部署构建后的静态文件。

项目主要结构大概是这样：

1
src/content/posts/     文章目录
2
src/content/spec/      关于、友链、留言等特殊页面
3
src/config/            站点配置
4
public/                静态资源
5
dist/                  构建后的生产文件
6
package.json           项目脚本
7
wrangler.jsonc         Cloudflare Workers 静态资源配置
8
vercel.json            Vercel 输出目录配置

其中最常用的是 src/content/posts/。以后新文章基本都放在这里。

本地运行#

项目使用 pnpm 管理依赖。进入项目根目录后，先安装依赖：

Terminal window

1
pnpm install

开发环境启动：

Terminal window

1
pnpm dev

本地开发服务会跑在类似下面的地址：

1
http://127.0.0.1:4333/

开发环境和生产环境有一个重要区别：开发环境会显示草稿文章，方便预览和调试；生产构建会自动过滤 draft: true 的文章。所以本地看到的文章数量可能比线上多，这是正常现象。

这个逻辑在 src/utils/content-utils.ts 里：

1
return import.meta.env.PROD ? data.draft !== true : true;

也就是说，生产环境只展示非草稿文章。

配置站点信息#

站点的大部分基础信息都在 src/config/siteConfig.ts 里配置，例如：

站点标题
副标题
站点地址
导航栏标题和 Logo
页面开关
分页数量
壁纸、字体、主题色等显示配置

导航菜单在 src/config/navBarConfig.ts 里维护。比如首页、文章、工具、更新日志、友链、留言、我的、关于等菜单，都是从这里生成的。

如果某个菜单带有子菜单，它会渲染成下拉框。比如“文章”下面有归档、分类、标签；“我的”下面有相册、追番、番组计划。

写文章#

文章使用 Markdown 或 MDX。最简单的一篇文章格式如下：

1
---
2
title: 文章标题
3
published: 2026-07-08
4
description: 文章简介
5
image: /assets/images/wallpaper/wallpaper-20.webp
6
tags: [博客搭建, Astro]
7
category: 博客指南
8
draft: false
9
---
10

11
这里开始写正文。

published 是发布时间。
draft: false 表示会在生产环境发布。
draft: true 表示只在本地开发时显示。

如果文章需要配图，可以像现在这样创建一个文章目录：

1
src/content/posts/build-rainzt-blog/index.md
2
src/content/posts/build-rainzt-blog/cover.png
3
src/content/posts/build-rainzt-blog/step-1.png

正文里可以直接引用同目录图片：

1
![部署截图](./step-1.png)

生产构建#

确认文章和配置没问题后，执行生产构建：

Terminal window

1
pnpm build

这个命令不是只跑 Astro，它会连续做几件事：

Terminal window

1
node scripts/generate-icons.js
2
npx tsx scripts/generate-lqips.ts
3
astro build
4
npx tsx scripts/subset-fonts.ts
5
pagefind --site dist

分别对应：

生成项目用到的图标常量
为图片生成低质量占位图数据
生成 Astro 静态站点
处理字体子集
生成 Pagefind 搜索索引

构建完成后，生产文件会出现在：

1
dist/

部署到服务器的就是这个目录里的内容。

本地预览生产版本#

开发环境正常不代表生产构建一定正常，所以部署前最好跑一次预览：

Terminal window

1
pnpm preview

也可以指定端口：

Terminal window

1
pnpm preview --host 127.0.0.1 --port 4334

这个预览服务读取的是 dist，更接近线上效果。如果这里正常，线上不正常，问题通常就在部署目录、静态资源缓存或服务器配置上。

服务器环境#

线上使用的是宝塔面板加 Nginx。当前站点配置里，rainzt.cn 和 www.rainzt.cn 都指向同一个网站根目录。

Nginx 配置里核心部分是：

1
root /path/to/site;
2
index index.html;
3

4
location / {
5
    try_files $uri $uri/ $uri.html =404;
6
}

HTTPS 证书由宝塔管理。部署静态文件时，只需要操作网站根目录，不要动证书配置。

部署流程#

部署时的思路很简单：

本地执行 pnpm build
把 dist 打包上传到服务器
备份旧站点目录
清空网站根目录里的旧静态文件
解压新的 dist 到网站根目录
检查 Nginx 配置并 reload

清空旧文件很重要。Astro 生成的 _astro 资源带 hash，如果只覆盖不删除，旧 CSS、旧 JS 可能残留。浏览器或 Nginx 又会长期缓存这些带 hash 的资源，最后就容易出现“本地正常，线上某些交互异常”的情况。

部署前最好保留一份旧版本备份。这样就算新版本有问题，也可以快速回滚。

线上验证#

部署完成后，需要检查几个点：

1
https://rainzt.cn/
2
https://rainzt.cn/api/allPostMeta.json
3
https://rainzt.cn/_astro/

首页能打开，说明 Nginx root 和静态文件没问题。
api/allPostMeta.json 正常，说明文章元数据构建出来了。
_astro 里的 CSS 和 JS 能访问，说明资源路径没问题。

如果刚部署完页面样式或下拉框还是旧状态，可以先强制刷新：

1
Ctrl + F5

如果仍然不对，就要检查线上 HTML 引用的资源文件名是不是最新构建生成的文件。

Git 管理#

项目已经初始化 Git。常用流程：

Terminal window

1
git status
2
git add .
3
git commit -m "Add new post"

注意 dist/、node_modules/、日志文件等不需要提交。源码、配置、文章、静态资源才是应该进入 Git 的内容。

后续更新文章#

以后发新文章可以按这个流程：

在 src/content/posts/ 新建文章
设置好 published、tags、category、draft
本地 pnpm dev 预览
确认无误后 pnpm build
上传新的 dist
访问线上确认

如果只是草稿，就保持：

1
draft: true

等要发布时再改成：

1
draft: false

小结#

这个博客的核心链路可以概括成一句话：

用 Markdown 写内容，用 Astro 生成静态站点，用宝塔 Nginx 托管 dist，用 HTTPS 把它稳定地挂到 rainzt.cn。

它不是最复杂的部署方式，但对个人博客来说很舒服：本地写作足够快，线上访问足够轻，出问题时也容易定位。后面无论是加文章、加工具页、改导航、换壁纸，基本都能围绕这套流程继续迭代。

朝朝听雨

自动上架系统：为跨境电商打造的高端批量发布中枢

项目定位#

已实现能力#

模板化：把经验变成配置#

AI 标题：让批量发布更像精细运营#

运行可视化：自动化必须可控#

双平台基础：Shopee 与 TikTok Shop#

周边工具：从上架延伸到运营维护#

可定制方向#

产品愿景#

从母系社会到父权制度：亲缘、私有制与现代性别关系的演变(浅谈男女对立)

引言：社会制度并非天然存在#

一、为什么父姓制度会成为许多文明的选择？#

母亲拥有天然确定的血缘关系#

父系血缘为什么需要社会制度确认？#

二、姓氏制度不仅是身份问题，也是亲缘识别系统#

第一，确认家族归属#

第二，帮助社会识别婚姻关系#

三、为什么许多母系社会中出现较弱的婚姻绑定？#

当父亲身份无法被确认时，男性投入模式会发生变化#

父亲角色的社会意义与制度有关#

四、农业革命如何推动父系制度形成？#

土地和财富改变了社会逻辑#

五、父权制度并非单纯来自男性意志，而是生产结构的结果#

六、为什么现代社会正在改变传统性别结构？#

七、女性解放与生产力变化#

八、父权制度不仅影响女性，也影响普通男性#

第一层压力：必须成功#

第二层压力：婚姻成为社会评价体系#

第三层压力：责任感被无限扩大#

九、真正的问题不是男女，而是旧制度留下的压力#

十、从历史角度看，人类正在进入新的阶段#

原始社会阶段#

农业社会阶段#

工业与信息社会阶段#

结语：制度会随着生产力变化而变化#

我回望青春时，我的青春是最昂贵的； 我正值青春时，我的青春是最廉价的。

后来才知道，真正舍不得的是日子#

2020 年的秋天#

十六七岁的时间太多了#

屏幕背后的那些晚上#

那时的我站在操场#

喜欢一个人，其实是很轻的事情#

那些没有日期的日子#

真正的告别很少有一场郑重的告别#

离开那间教室以后#

时间开始有了价格#

如果现在回到从前#

青春昂贵在哪里#

在远方里想念青春#

朝朝听雨，岁岁有风

写在故事之前#

故事从高一开始#

我喜欢她#

高二：走进彼此的日常#

高三：遗憾#

分开之后#

朝朝听雨，岁岁有风#

Agent 赋予电商自动化：从业务规则到可控的自动上架框架

先说结论：自动化的核心不是点击，而是规则#

为什么我更推荐从 ERP 开始#

1. ERP 的数据更结构化#

2. 风险边界更清楚#

3. 多平台差异可以被隔离#

技术底座：Playwright、CDP 与固定 Chromium#

AI Agent 到底帮了什么忙#

两种业务场景，不能用同一套规则#

POD 产品：规则稳定，适合批量化#

搬运或铺货：差异更大，但同样可以全自动#

图片与 SKU 的匹配：最容易被低估的难题#

把平台操作写成 Worker，而不是一条超长脚本#

失败重试，但不要无脑重试#

为什么一定要做可视化界面#

从自动上架继续往外扩展#

最后：Agent 替我完成动作，但不会替我承担判断#

作品展示页动画实现原理

目标不是播放，而是让读者控制节奏#

固定舞台：用滚动距离换取阅读时间#

不在 scroll 回调里直接渲染#

我回望青春时，我的青春是最昂贵的；我正值青春时，我的青春是最廉价的。