朝朝听雨

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

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 策略、价格与库存联动、自动翻译、多语言标题、违禁词检测、图片合规检查、店铺维度权限、任务队列调度、失败重试策略和团队协作审计。

历史记录与复盘

产品愿景#

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

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

系统总览

从零搭建 Rainzt.cn：我的个人博客上线流程

Wed, 08 Jul 2026 00:00:00 GMT

为什么要搭这个博客#

我想要一个真正属于自己的内容空间。它不只是用来发文章，也用来整理项目、记录折腾过程、放一些自己喜欢的页面和小工具。

最后选择的是基于 Astro 的 Firefly 主题。它的好处很直接：静态生成速度快，页面效果完整，文章用 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。

它不是最复杂的部署方式，但对个人博客来说很舒服：本地写作足够快，线上访问足够轻，出问题时也容易定位。后面无论是加文章、加工具页、改导航、换壁纸，基本都能围绕这套流程继续迭代。