朝朝听雨

自动上架系统：用 Playwright 构建可控发布流程

Thu, 09 Jul 2026 00:00:00 GMT

先说结论：它解决的是重复的劳动#

这套工具的目标，不是把鼠标点击录制下来，再批量重复一遍。真正要解决的是一条商品发布链路里的多个一致性问题：

Excel 里的商品、型号和组号，必须能对应到正确的商品页面；
当前 BigSeller 页面、店铺和平台必须是操作者明确打开的那一个；
主图、详情图、视频和变种图不能因为页面顺序变化而错配；
AI 可以帮助识别图片和生成标题，但不能擅自改掉品牌、型号和固定字段；
“看到成功提示”不等于平台真的接受了发布；
批量任务中途暂停、失败或重试后，必须知道已经处理到哪里。

所以我把它做成了一个运行在 Windows 桌面上的本地工具。文章第一次发布于 2026 年 7 月 9 日；当时仓库还处在 v1.0.0 的早期基线。现在本地工作区已经推进到 v4.1.1，主要服务 BigSeller 中的 Shopee 和 TikTok Shop 商品维护与批量发布。本文的代码和流程均来自这套本地项目；代码块已经去掉 API Key、绝对路径、店铺名称和运行数据。

当前版本自动上架系统欢迎卡片

从第一次发布到现在：这不是一次换皮，而是一次工程升级#

Git 历史最能说明这套工具发生了什么变化。第一次发布前后的 9b877e13（2026-07-08）仍然是 v1.0.0：已经有 Shopee/TikTok Shop 双 Worker、4 种标题模式、实时监控、历史记录和 7 个 Shopee 模板 + 1 个 TK 模板，但它更像一套“已经能工作的批量上架工具”。

截至 2026 年 9 月 18 日，最新正式提交是 53d29aff（v4.1.0），本地工作区又继续推进到了 v4.1.1。两个月里的主要变化不是继续堆叠按钮，而是把系统从“能跑”推进到“知道什么时候能跑、为什么停、停在哪里、结果是否可信”。

时间与提交	变化	解决的问题
7 月 19 日：`af9d8a70`	编辑页二次确认、品牌复核，并为两个平台补充测试	搜索到商品不代表打开的就是目标商品，列表品牌也不一定可信
7 月 22 日：`1be3eb28`	用商品链接和编辑页标题共同校验身份，并兼容旧列表页	BigSeller 页面路由和打开方式变化后，仍能判断页面是否属于目标商品
7 月 24 日：`6afae1e6`	完善 TK 配置和印尼型号表	TikTok Shop 的表格列、型号和页面流程不能直接照搬 Shopee
8 月 1 日：`1409482c`、`74efdadc`	加入自定义上架方案和店铺整套配置	把一次运行的临时选择，提升为可以保存、复用和按店铺隔离的方案
8 月 6—11 日：`d4ec311e`、`767bab7b`、`52109f6c`、`8dfd7b70`	稳定规则标题、取消自动插入连接词、主图先传、细化进度和发布收尾	标题字段不再被 AI 随意改写，上传顺序和成功收尾更符合真实页面状态
8 月 15 日：`bfb9d084`	加固配置系统和 SKU 工具，增加图片冲突测试	运营维护动作开始进入同一套配置和校验边界，而不是各自写脚本
9 月 6—12 日：`2ceecc97`、`ae6227cf`	增加库存扫描兜底与报表能力，更新模板和型号配置	系统从“发布商品”扩展到发布前后的库存、型号和运营维护
9 月 16—18 日：`6b7fc1e7`、`53550478`、`c41ff776`、`53d29aff`	分批上架范围、多店铺分开上架、PNG 兼容、图片组严格匹配、编辑页身份严格校验和范围导航	批次更大、店铺更多之后，必须把运行范围、图片关系和页面身份锁死

这条演进路线可以概括成五个转变：

当前版本系统公告与安全校验说明

从“搜索到就编辑”变成“列表行、编辑页、品牌三次确认”；
从“按文件名和数组顺序上传”变成“按页面真实变种标签做精确映射”；
从“一个配置覆盖所有场景”变成“模板、平台、店铺和运行范围分别管理”；
从“整批任务一口气跑完”变成“可选组范围、可暂停、可恢复、可重试”；
从“控制台显示完成”变成“Worker、SSE、截图、事件历史共同证明结果”。

所以现在的系统和文章刚发布时，差别不只是界面更丰富、模板更多，而是错误模型变了：早期主要关心怎样把动作执行完，现在更关心执行前能否证明输入正确、执行中能否定位状态、执行后能否证明平台确实接受了结果。

系统边界：浏览器自动化，但不是“盲点”#

工具通过 Playwright 连接已经登录的 Chromium/Chrome 页面，再操作 BigSeller 当前打开的列表页和编辑页。使用时，运营人员先登录并打开正确的平台列表页，工具负责读取页面、查找商品、进入编辑页和执行配置好的动作。

这个边界是故意保留的：工具不会为了“跑通”而偷偷切换到另一个店铺，也不会假设所有店铺、所有平台都共用同一套页面流程。真实业务里，误操作一个店铺的代价通常比少处理一个商品更高。

整个系统可以抽象成四层：

1
Excel / 图库 / 视频 / 模板配置
2
                 │
3
                 ▼
4
        server.js 控制层
5
  Express API · 浏览器上下文 · SSE · 历史记录
6
          ┌──────┴──────┐
7
          ▼             ▼
8
   batch-worker.js   tk-worker.js
9
     Shopee 流程      TikTok Shop 流程
10
          └──────┬──────┘
11
                 ▼
12
       BigSeller 当前页面
13
                 │
14
                 ▼
15
       截图 · 事件 · 产品结果 · Token

展开收起

server.js 不把所有业务都塞进一个请求处理器，而是负责控制面板、浏览器连接、配置读写、状态广播和 Worker 生命周期。Shopee 与 TikTok Shop 各自有 Worker、运行状态、暂停文件、SSE 通道和平台选择器；shared.js 只承载两边都能复用的解析、路径、图片和标题规则。

一次任务从哪里开始#

一个批次的输入并不只有一个 Excel 文件。系统会同时使用：

输入	作用
Excel 文件或目录	提供商品名、商品 ID、型号、组号等结构化数据
图片目录	按品牌、模板和组号组织主图、详情图、变种图
视频目录	按模板配置选择随机视频或指定视频
模板配置	决定品牌、标题字段、图片序号、视频策略和平台规则
BigSeller 当前页面	提供实际商品列表、编辑页 DOM 和最终发布入口

Excel 不是简单的“导入后逐行点击”。Worker 会先读取文件，解析出可搜索的组号，再根据模板和品牌建立映射。运行时还会把本次上架范围传入子进程，让控制层可以明确知道这一轮处理的是哪一段数据。

运行范围是输入契约，不是一个按钮#

批量任务最容易被低估的参数是“这次到底处理哪些组”。早期的界面更接近“从某个位置开始，再跑多少组”；现在服务端把它规范成 groupStart、groupEnd 和兼容性的 groupCount。其中 groupEnd 是绝对组号，不是“再跑几组”，因此“第 2 组到第 4 组”和“从第 2 组开始跑 3 组”最终会落到同一个明确范围。

服务端在启动 Worker 前会先把结束组物化，再拿当前模板实际读取到的 Excel 组数做边界校验：

1
function materializeListingScope(scope, totalGroups) {
2
  const total = Number(totalGroups) || 0;
3
  if (!scope || total <= 0) return scope;
4

5
  const groupEnd = scope.groupEnd > 0 ? scope.groupEnd : total;
6
  return {
7
    ...scope,
8
    groupEnd,
9
    groupCount: groupEnd - scope.groupStart + 1,
10
  };
11
}
12

13
// 起始组超过表格总数、结束组小于起始组、结束组超出总数，都会拒绝启动
14
const scopeCheck = validateListingScope('shopee', requestedScope);
15
if (!scopeCheck.ok) return res.json({ ok: false, error: scopeCheck.error });

展开收起

这一步的价值在多店铺场景里更加明显。每个店铺的 Excel 组数可能不同，界面会先检查本地工作区是否真的解析出组号，服务端还会再次拒绝超出表格的结束组。前端禁用“下一步”只能改善体验，不能承担安全边界；真正决定任务能否启动的必须是服务端的第二次校验。

server.js 启动 Shopee Worker 的核心逻辑大致如下。这里保留了实际的进程边界，省略了 UI 和错误处理之外的细节：

1
// server.js：启动一个独立的 Shopee Worker（脱敏节选）
2
const scriptPath = path.join(__dirname, 'batch-worker.js');
3
const proc = spawn('node', [scriptPath], {
4
  cwd: __dirname,
5
  env: {
6
    ...process.env,
7
    LISTING_GROUP_START: String(listingScope.groupStart),
8
    LISTING_GROUP_COUNT: String(listingScope.groupCount),
9
  },
10
  stdio: ['pipe', 'pipe', 'pipe'],
11
});
12

13
let buffer = '';
14
proc.stdout.on('data', (chunk) => {
15
  buffer += chunk.toString();
16
  const lines = buffer.split('\n');
17
  buffer = lines.pop();
18

19
  for (const line of lines) {
20
    if (!line.trim()) continue;
21
    try {
22
      handleWorkerMessage(JSON.parse(line.trim()));
23
    } catch {
24
      addLog('info', line.trim());
25
    }
26
  }
27
});

展开收起

Worker 不直接操作控制面板，而是把每一步编码成一行 JSON。这样做有两个好处：浏览器操作和 HTTP 请求不会互相阻塞；同一组事件既可以实时显示，也可以落盘成为历史记录。

1
// batch-worker.js：Worker 的最小事件出口
2
function emit(obj) {
3
  process.stdout.write(JSON.stringify(obj) + '\n');
4
}
5

6
emit({
7
  type: 'product_start',
8
  brand,
9
  group: imgGroupId,
10
  batchGroupId,
11
  batchNum,
12
});

Worker 输出的是运行协议，不只是日志#

Worker 的标准输出实际上是一条轻量事件协议。product_start 表示进入商品边界，step 表示可以展示给操作者的中间动作，screenshot 记录证据文件，product_done 才代表商品结果已经完成；fatal、paused 和进程退出则分别进入失败、暂停和收尾路径。控制层收到同一条消息后，同时更新内存中的运行状态、SSE 客户端和当前历史产品文件。

这里还有一个很实际的工程细节：子进程的 stdout 不保证一次回调就是一整行 JSON。server.js 会保留上一次回调最后一个不完整的片段，只解析已经出现换行的部分；如果某行不是 JSON，则降级为普通信息日志，而不是让整个控制层崩溃。这使 Worker 偶尔输出第三方库的诊断文字时，批量任务仍能继续运行。

1
proc.stdout.on('data', (chunk) => {
2
  buffer += chunk.toString();
3
  const lines = buffer.split('\n');
4
  buffer = lines.pop(); // 保留可能尚未收完整的 JSON 行
5

6
  for (const line of lines) {
7
    if (!line.trim()) continue;
8
    try {
9
      handleWorkerMessage(JSON.parse(line.trim()));
10
    } catch {
11
      addLog('info', line.trim());
12
    }
13
  }
14
});

最重要的防错：先确认“这是哪个商品”#

浏览器自动化最危险的地方，不是点击失败，而是点击成功但点错了对象。BigSeller 的列表可能分页、刷新或重新渲染，页面中的行也可能因为平台升级而变化。因此系统不会只拿一个字符串搜索到行就继续。

Shopee Worker 当前使用 VXE 表格的行选择器定位商品，并要求结果唯一；随后再次读取行标题，确认它与 Excel 中的商品名一致。进入编辑页后，还要检查 URL 和编辑页标题至少有一项能够和目标商品对应：

1
// batch-worker.js：编辑页身份二次确认（脱敏节选）
2
async function verifyOpenedEditPageIdentity(page, productName, expectedUrl = '') {
3
  const actualPath = normalizeEditPagePath(page.url());
4
  if (!/\/(?:web\/)?listing\/shopee\/edit\//i.test(actualPath)) {
5
    return { ok: false, reason: '打开的不是 Shopee 编辑页' };
6
  }
7

8
  const editTitle = await readEditPageProductName(page, 15000);
9
  if (!editTitle) {
10
    return { ok: false, reason: '编辑页标题为空，无法确认商品身份' };
11
  }
12

13
  const exactUrl = normalizeEditPagePath(expectedUrl) === actualPath;
14
  const exactTitle = normalizeProductText(editTitle)
15
    === normalizeProductText(productName);
16

17
  if (!exactUrl && !exactTitle) {
18
    return {
19
      ok: false,
20
      reason: `编辑页身份不匹配: 列表“${productName}” / 编辑页“${editTitle}”`,
21
    };
22
  }
23
  return { ok: true, editTitle, matchedBy: exactUrl ? 'url' : 'title' };
24
}

展开收起

品牌也会在编辑页再次判断。列表标题只负责初筛，编辑页无法确认时，Worker 会停止当前商品，而不是“猜一个最接近的品牌”。这也是为什么系统的日志里会明确记录“身份确认”而不是只记录“已点击编辑”。

这套策略也解释了为什么工具不主动替用户切换店铺或跳转到另一个列表页。浏览器里的登录态、当前店铺和当前列表页属于操作者明确选择的运行上下文；工具只在这个上下文内做可验证的动作。自动导航看起来更省一步，但一旦页面路由、店铺筛选或登录态发生变化，脚本可能在错误的业务空间里完成一套完全正常的点击。

图片映射：绝不靠 `组号 + 1` 猜下一张#

批量上架里最容易造成业务事故的是图片错配。一个产品通常同时涉及：

商品主图和详情图；
与品牌或模板相关的图片序号；
页面里的 Color/Model 变种顺序；
本地图库中的组号和文件名。

系统在删除旧图之前，会先读取页面真实的变种标签顺序，再和本地预期顺序做精确比较。两次读取不一致、页面缺标签、图片不存在、顺序变化，都会停止，不会退回到“按数组下标上传”的猜测逻辑。

shared.js 中的比较函数要求两边非空、无重复、长度相等，并且每一项按位置相等：

1
// shared.js：页面变种顺序与本地组号的核心判定（节选）
2
const exact = expected.length > 0
3
  && actual.length > 0
4
  && duplicateExpected.length === 0
5
  && duplicateActual.length === 0
6
  && expected.length === actual.length
7
  && expected.every((groupId, index) => groupId === actual[index]);

上传变种图时，Worker 会把页面标签映射成文件名，然后逐项检查文件是否存在，并再次比较预检结果与页面结果：

1
// batch-worker.js：变种图严格对齐（节选）
2
const pageFiles = pageOrder.map((groupId) =>
3
  resolveListingImageName(baseDir, groupId, mainImageIndex)
4
);
5

6
if (!pageFiles.every((file) => existsSync(path.join(baseDir, file)))) {
7
  throw new Error('Strict variant match failed: image file is missing');
8
}
9

10
const orderChanged = pageFiles.length !== variantFiles.length
11
  || pageFiles.some((file, index) => file !== variantFiles[index]);
12

13
if (orderChanged) {
14
  throw new Error('Strict variant order changed');
15
}
16

17
variantFiles = pageFiles;

展开收起

这段逻辑看起来保守，实际是在保护库存和商品展示。自动化系统的专业性，很多时候体现在它知道什么时候不应该继续。

为什么变种顺序要读两次#

BigSeller 的变种区域会随着滚动、懒加载和 Vue 重渲染发生短暂变化。当前 Worker 在首次读取到非空标签后等待一小段时间，再读取第二次；只有长度和每个位置都相同，才把顺序缓存下来。重试时优先使用已经确认过的缓存，避免重新滚动页面又读到半成品 DOM。

1
const firstOrder = await readVariantPageOrder(page);
2
await sleep(800);
3
const confirmOrder = await readVariantPageOrder(page);
4
const stable = firstOrder.length === confirmOrder.length
5
  && firstOrder.every((groupId, index) => groupId === confirmOrder[index]);
6

7
if (!stable) {
8
  emit({ type: 'fatal', text: '变种标签两次读取不一致，已停止' });
9
  return null;
10
}

而且“第一次校验通过”仍然不够。进入删除旧图之前，Worker 会再次读取两次页面顺序，并和最初的 pageOrder 比较。也就是说，真正会修改商品图片的动作前面有一个独立的最终闸门；页面在中间发生重排时，任务宁可停在删除之前，也不会拿旧的读取结果继续执行。

当前版本自动上架系统控制台

标题生成：AI 只负责它擅长的那一小部分#

标题有四种运行模式：固定标题、完整 AI 标题、固定字段规则随机、AI 识别图案词后再由本地规则拼接。这里没有把整条标题完全交给模型，因为品牌、型号、功能词和字符上限都属于确定性约束。

例如 ai_image_shuffle 模式只让 AI 从图片中提取少量图案词，品牌、前缀、型号和功能字段仍由本地配置控制；ai_fixed_shuffle 甚至完全不调用 AI。shared.js 中的规则构造器会把固定字段放在配置指定的位置，模型不能重复或挪动这些字段。

1
// batch-worker.js：AI 图析 + 本地规则组装
2
const imgWords = await generateTitlePatternOnly(
3
  path.join(imageDir, aiImage),
4
  brand,
5
  pageTitle,
6
);
7

8
parts.aiWords = imgWords;
9
const title = buildRuleShuffleTitle(parts, { maxChars: TITLE_MAX });
10

11
if (!title || title.length > TITLE_MAX) {
12
  emit({ type: 'error', text: '规则标题超过平台字符限制' });
13
  return null;
14
}

完整 AI 标题模式也会检查语言、清理换行和引号、限制字符数；写入页面后再读取输入框验证，连续失败就停止该商品。模型请求失败不会被伪装成“发布成功”，Token 使用量也会作为运行事件记录。

AI 与标题配置

一个商品的执行顺序#

当前 Shopee 流程不是简单的“打开页面 → 上传 → 点击发布”，而是有明确的破坏性动作边界：

连接现有 CDP 浏览器，确认 BigSeller Shopee 列表页存在；
读取模板和 Excel，确定本次组号范围；
搜索商品并确认列表行唯一；
打开编辑页，检查 URL、商品标题和品牌；
读取页面变种顺序，构建本地图片映射；
预检查主图、详情图、视频和变种图是否齐全；
生成标题、填写标题并回读验证；
在删除旧图前再次读取两次变种顺序；
删除旧图，确认删除完成后再分批上传新图；
按模板处理视频和变种图，缺槽位时重试；
发布前截图；
点击 BigSeller 的“保存&发布”，等待平台最终确认；
只有商品结果确认后，才写入 product_done 和成功历史。

其中第 8 步很关键：即使前面已经做过一次变种检查，在真正删除旧图片这种不可逆程度更高的动作前仍然要复核。页面可能在滚动、异步加载或重渲染后发生变化，前一次读数不能自动代表当前状态。

从流程设计上看，一个商品实际上被拆成三个阶段：

Prepare：读取 Excel、图库和页面，生成标题与图片计划，但不修改商品；
Mutate：通过最终闸门后删除旧素材、上传新素材、填写视频和变种图；
Commit：拿到平台最终提交确认后，写入 product_done、成功计数和历史结果。

这不是数据库事务，因为 BigSeller 页面本身不能回滚；但它把最危险的动作尽量推迟到所有可验证条件都满足之后，并且把“提交成功”从按钮点击中分离出来。对浏览器自动化来说，这种分阶段比单纯增加等待时间更可靠。

发布成功不是一个绿色 Toast#

BigSeller 的 Shopee 发布按钮是下拉按钮，按钮和下拉选项可能使用同一个文案。Worker 需要先展开下拉菜单，再定位真正的选项。点击以后，普通 Ant Design 成功 Toast 只能作为过程信号，不能直接标记商品成功。

当前代码等待包含“操作成功”和“产品已提交 Shopee”的最终弹窗：

1
// batch-worker.js：最终成功判定（脱敏节选）
2
const modalText = await modal.textContent({ timeout: 2000 }).catch(() => '');
3

4
if (modalText.includes('操作成功')
5
  && modalText.includes('产品已提交Shopee')) {
6
  await closePublishedShopeeEditPage(page, modal);
7
  return true;
8
}
9

10
// 普通成功提示只记录，不完成商品
11
if (await page.locator('.ant-message-success').count().catch(() => 0) > 0) {
12
  emit({
13
    type: 'step',
14
    level: 'info',
15
    text: '已收到成功提示，继续等待最终提交确认',
16
  });
17
}

展开收起

如果按钮消失但最终弹窗没有出现，系统也不会把它当作成功。它会进入重试或失败路径，避免历史记录里出现“看起来成功、实际上没有提交”的假结果。

因此历史记录里的成功数不是“点击了多少次发布按钮”，而是满足一组条件后的结果：目标编辑页身份已经确认、图片与变种映射通过、标题回读通过、必要素材已验证、最终提交弹窗出现，并且 Worker 能完成收尾。任何一项缺失，都不会被包装成成功率。

暂停、恢复和失败边界#

批量任务不应该只能“开始”或“杀进程”。Shopee Worker 使用暂停标记和恢复状态文件记录组号、产品索引、批次数量和当前组索引：

1
// batch-worker.js：暂停时保存可恢复位置
2
function saveResumeState(groupNum, productIndex, totalBatches, totalProducts, groupIdx) {
3
  writeFileSync(
4
    RESUME_STATE,
5
    JSON.stringify({ groupNum, productIndex, totalBatches, totalProducts, groupIdx }),
6
    'utf-8',
7
  );
8
}
9

10
if (existsSync(PAUSE_FLAG)) {
11
  saveResumeState(parseGroupId(keyword).num, productIndex,
12
    totalBatches, totalProducts, groupIdx);
13
  emit({ type: 'paused', group: keyword, productIndex, totalInBatch });
14

15
  while (!existsSync(RESUME_FLAG)) await sleep(1000);
16
}

展开收起

暂停并不是在任意一行代码上硬切断。控制层先写入暂停请求，Worker 在产品边界检查标记，保存位置后等待恢复。对于身份不明、图片缺失、变种不稳定、标题回读失败或发布最终确认缺失等情况，系统选择安全停止当前商品，而不是继续扩大影响范围。

停止和暂停也不是同一件事。暂停是协作状态：当前商品完成到安全边界后保存恢复位置，等待 resume.flag；停止则清理控制文件、结束当前进程，并将队列标记为停止。Shopee 与 TikTok Shop 使用各自的暂停/恢复文件和运行状态，因此停止一个平台不会误伤另一个平台的 Worker。

实时状态与历史记录是两条链#

实时控制台使用 SSE。Shopee 和 TikTok Shop 分别连接 /events 与 /events-tk，服务端会发送初始状态、后续事件和心跳；浏览器断线时，服务端清理客户端，避免连接数组无限增长。

1
// server.js：SSE 的公共连接处理（节选）
2
res.writeHead(200, {
3
  'Content-Type': 'text/event-stream',
4
  'Cache-Control': 'no-cache, no-transform',
5
  'Connection': 'keep-alive',
6
  'X-Accel-Buffering': 'no',
7
});
8

9
res.write(`data: ${JSON.stringify(initialEvent)}\n\n`);
10
const heartbeat = setInterval(() => {
11
  res.write(`: heartbeat ${Date.now()}\n\n`);
12
}, SSE_HEARTBEAT_MS);

SSE 只是“现在发生了什么”，不是唯一事实来源。每次运行还会写入本地历史目录：

1
上架历史/
2
└── YYYY-MM-DD/
3
    └── shopee-<run-id>/
4
        ├── run.json          # 平台、模板、店铺快照、统计、Token、最终状态
5
        ├── index.json        # 历史列表用的轻量摘要
6
        ├── events.ndjson     # 按时间追加的批次/产品/错误事件
7
        ├── products/         # 每个商品的计划、步骤、结果和失败原因
8
        └── screenshots/      # 关键页面截图引用

run.json 会保存本次配置快照、平台和模板、处理数量、成功/失败数量、截图数量与 Token 使用量；events.ndjson 则把 Worker 事件按时间追加。这样，实时页面即使被关闭，也能在历史页重新回答：哪个批次失败、失败发生在哪一步、标题和图片计划是什么、最终是否提交。

历史页也没有每次打开都把所有产品和事件一次性读进概览。服务端把运行级概览和单次详情分开：概览只读取日期、平台、状态、成功失败计数和最近产品；用户点进某次运行后，才加载产品 JSON、事件尾部和截图预览。对于长期积累的运行记录，这个边界能避免“查看今天的统计”被历史详情拖慢。

当前版本历史记录与复盘界面

Shopee 与 TikTok Shop：共用底座，不共用假设#

两个平台共用以下基础能力：

Express 服务和嵌入式/调试浏览器连接；
模板、品牌、Excel、图库和视频配置；
SSE 状态、截图和历史记录；
AI 标题与 Token 统计；
暂停、恢复、停止和错误事件。

但它们不会共用平台专属动作。Shopee 使用 batch-worker.js，关注商品列表、编辑页、“保存&发布”、Shopee 提交确认和可选预售；TikTok Shop 使用 tk-worker.js，采用自己的列表入口、Excel 起始行、编辑按钮、更新按钮和成功判断。一个平台的选择器、发布按钮或预售逻辑不能直接复制到另一个平台。

这种隔离比抽象出一个“万能 Worker”更可靠。平台差异被封装在各自 Worker 里，公共部分保持纯函数和数据规则，后续增加平台时可以复用底座，但不必把所有条件分支塞进同一个巨型流程。

当前版本还保留原来的单店铺入口，同时增加了“多店铺分开上架”。后者不是把多个店铺的配置临时拼在一起，而是为每个店铺绑定独立 Excel、图库和整套模板配置，再逐店打开设置核对，全部确认后才进入串行队列。截图中的 BigSeller 店铺列表尚未打开时，系统会明确显示同步失败并禁用下一步；这正是它与早期“默认当前页面继续执行”思路的区别：店铺范围必须被检测、确认，不能靠猜。

多店铺最容易出现的隐性事故不是“选错店铺”，而是店铺专属路径污染全局配置。当前实现会先把店铺工作区合并到内存中的运行配置，Worker 通过 LISTING_CONFIG_PATH 读取这份隔离配置；单店铺使用的 config.json 不会被临时覆盖。服务端还会修复历史版本遗留的路径泄漏，把单店铺全局路径恢复到默认工作区。

1
function applyMultiStoreWorkspace(config, workspaceDir) {
2
  const workspace = getMultiStoreWorkspaceSummary(
3
    normalizeMultiStoreWorkspace(workspaceDir),
4
  );
5
  const next = cloneConfigValue(config);
6

7
  for (const template of Object.values(next.templates || {})) {
8
    template.excelPath = workspace.excelDir;
9
    template.imageBaseDir = workspace.imageDir;
10
  }
11
  next.paths.tempImages = workspace.imageDir;
12
  next.singleMainImageDir = path.join(workspace.imageDir, '单主图库');
13
  return { config: next, workspace };
14
}

这也是“多店铺分开上架”与“把多个店铺临时拼到一起”的本质区别：队列可以串行执行多个工作区，但每个 Worker 拿到的是自己的配置快照；单店铺原有配置和运行状态仍然是独立的。

当前版本多店铺分开上架流程

Shopee 与 TikTok Shop 工作区

周边工具为什么也要放进同一套系统#

真正使用时，批量上架并不是唯一的高频动作。当前控制台还包含表格批量上传、批量添加型号、已知 Model 修复、SKU 修复、描述修改、折扣处理、素材中心清理、视频中心、截图和历史查看等工具。

它们共用同一个浏览器上下文和配置边界，但会检查与上架 Worker 的冲突状态。例如上架运行中，另一个会修改商品数据的工具不能直接抢占同一页面。这样做不是为了让功能看起来更多，而是为了避免两个自动化任务同时改同一个 BigSeller 页面。

当前版本批量工具中心

平台差异不是配置项，而是两套流程#

两个平台共用输入、浏览器连接、日志和历史底座，但关键页面动作保持独立：

维度	Shopee	TikTok Shop
Worker	`batch-worker.js`	`tk-worker.js`
列表入口	`/web/listing/shopee/active/index.htm`，兼容旧列表 URL	`/listing/tiktok/index`
Excel 读取	商品 ID 第 1 列、Model 第 8 列，通常从第 2 行开始	商品 ID 第 14 列、Model 第 17 列，通常从第 5 行开始
编辑入口	`a[title="编辑"]`	`a.addEditProduct[title="编辑"]`
发布动作	展开“保存&发布”下拉并等待 Shopee 提交确认	点击“更新”并判断更新成功
平台专属逻辑	预售、Shopee 提交弹窗、自动关闭编辑页	TK 变种入口、更新按钮和独立成功判断
运行控制	`pause.flag` / `resume.flag`	`tk-pause.flag` / `tk-resume.flag`

这张表看起来只是选择器差异，实际代表的是业务语义差异：同一个“发布”在两个平台上不是同一个动作，同一个“成功”也不能共用判断。共享层适合放纯函数、路径解析和组号比较；平台页面动作则留在对应 Worker 中，避免抽象出一个包含大量平台分支的“万能流程”。

测试如何守住这些边界#

项目里已经有一组针对高风险路径的 Node 测试，不依赖真实店铺登录即可验证关键规则：

测试	它防止什么回归
`test-listing-scope.cjs`	结束组的绝对编号、超出 Excel 总组数、起止倒置和多店铺界面字段错误
`test-strict-image-group-matching.cjs`	组号错位、重复、顺序变化、缺图，以及删除旧图前没有最终复核
`test-shopee-publish-confirmation.cjs`	早期成功 Toast 被误判为最终发布成功、发布按钮缺失仍然记成功
`test-multi-store-config-isolation.cjs`	店铺专属 Excel/图库路径泄漏回单店铺配置，或 Worker 没有读取隔离配置
`test-listing-state-sync.cjs`	状态事件、暂停/停止和页面状态同步后出现旧状态覆盖新状态

这些测试没有试图替代真实浏览器端到端测试。它们的作用是锁住纯规则和关键代码结构，让平台 DOM 变化时，问题尽量暴露在启动前或测试阶段，而不是等到错误商品已经被修改之后才发现。

当前实现的限制#

这套系统已经足够支撑日常批量工作，但它并不是一个脱离平台的通用 SaaS，也有明确限制：

它依赖 BigSeller 页面 DOM，平台改版后需要重新核对选择器和成功判定；
它依赖本地 Windows 文件结构，换电脑时需要迁移配置和素材路径，不能直接复制运行时目录替代配置；
AI 标题依赖外部模型服务，网络、额度和模型输出都会影响任务，需要保留失败路径；
它更适合规则明确、图片和型号组织稳定的商品线，不适合完全没有结构的任意商品；
所谓“成功率”必须来自历史记录和平台最终确认，不能只用页面按钮点击次数估算。

这些限制反而决定了系统的工程方向：继续补充平台适配、测试和可观测性，而不是把“全自动”写成不需要人工确认的宣传口号。

最后：自动化的价值是把判断留给人#

我现在更愿意把这套工具称为“有明确停止条件的批量发布流水线”。它确实替人完成了大量重复操作，但它没有试图替人承担所有判断：店铺是否正确、素材是否对应、页面身份是否一致、发布是否真的成功，这些地方都必须留下证据。

从代码结构看，系统最值得保留的部分不是某个漂亮的控制台，而是几条朴素的规则：

不确定商品身份，就停止；
不确定图片映射，就停止；
不确定最终提交结果，就不要记成功；
AI 只处理开放性内容，固定业务字段由规则控制；
实时状态用于操作，历史事件用于复盘。

当商品数量、平台和店铺继续增加时，速度只是第一层收益。更重要的是，流程开始拥有统一的输入、可验证的中间状态、可恢复的执行位置和可追溯的结果。这才是我认为自动上架系统真正值得记录的地方。

山河锦绣，国泰民安

Tue, 29 Sep 2026 00:00:00 GMT

国庆快到了。看到图里的红旗、烟火和落日，我想起“热闹”与“安稳”这两个词。

热闹是街上的灯、家里的饭桌，也是久别的人终于坐在一起；安稳是平常的一天能按自己的节奏过去，惦记的人都平安，明天仍有值得期待的事。

山河辽阔，生活具体。愿祖国繁荣昌盛，也愿每个认真生活的人，都能把眼前的小日子过得踏实、明亮。

国庆快乐，愿山河锦绣，国泰民安。

月刊 · 第二期

Mon, 28 Sep 2026 00:00:00 GMT

上个月写完第一期月刊的时候，我其实不太确定还会不会有第二期。很多事情我都是开了头，然后就停在那里。

所以这篇能写出来，我自己先松了口气。

先看一下这个月的数据#

这次统计从 8 月 27 日到 9 月 27 日，刚好接上上一期。

4.01k 位访客

5.63k 次访问

70.2k 次页面浏览

43% 跳出率

4′07″ 平均访问时长

数据来自自建 Umami，统计时间：8 月 27 日—9 月 27 日。

Umami 站点数据统计（8 月 27 日—9 月 27 日）

访客差不多翻了一倍，从 2.1k 到 4k。页面浏览从 1.2 万涨到 7 万，这个数字我不太敢当真。一次访问平均要看十几页，不像正常读者的行为。9 月 12 日那天一下有将近 8000 次浏览，大概率是爬虫，或者我自己调试时刷出来的。所以这个月我更愿意看访客和访问次数，它们比浏览量诚实。

访问最多的页面依次是首页、归档、友链、朋友圈和留言板。文章里读的人最多的还是《自动上架系统》。外部来源里，必应排第一，后面是博友圈、bf.zzxworld.com、80tz.cn，还有上期推荐过的 AIOVTUE-雪。能从友链点进来，说明这个圈子真的在流动。

顺便：统计换成了自建 Umami#

9 月 21 日，我把统计从 Umami Cloud 迁到了自己部署的 Umami（umami.rainzt.cn）。

原因很简单：官方免费版只保存 6 个月的数据。博客才开了三个月，我已经能想到半年后回头翻，最早那些记录全没了的样子。数据还是放在自己手里踏实。

迁移时最怕数据断档。我先把 Cloud 上的记录导成 CSV 塞进新库，再把切换前的累计差额（576 位访客、951 次浏览）记成基准补回去。侧边栏的累计数字因此没有突然归零。

博客里的站点统计页

统计页也跟着接到了新的自建地址，数据和后台保持一致。代价是本期和上期的统计口径不完全一样，对比只能看个大概。

本月文章#

9 月 · 三篇新文章

9 月 14 日

这篇置顶了：
《在奶奶的白发里，我看见了时间》

一次回家，看见奶奶满头白发。那一下挺难受的，好像时间一直在走，只是我没有回头看。这篇写得很慢，也是这个月我最想让人读到的一篇。

9 月 18 日

犹豫了一阵，还是公开了：
《Codex 为什么会“降智”：292 State、状态注入与长任务》

从 HTTP 292 和状态注入，聊长任务为什么越跑越笨。写完一直不太确定该不该放出来，最后想想，把自己的观察留下来总比憋着好。

9 月 21 日

最后这篇：
《跨境电商 Agents：从 AI 选品到自动经营》

把选品、竞品研究、上架、生图和投放串成一条 Agent 流水线的想法。一篇写家人，一篇写工具，一篇写生意，放一起大概就是我这个月脑子里装的全部东西。

在奶奶的白发里，我看见了时间 Codex 为什么会“降智” 跨境电商 Agents

本月更新：Aemeath v4.0.0#

9 月 26 日，博客的版本号跳到了 v4.0.0。

没有哪一天突然做完了什么大功能。前面三周的小改动攒到一起，某天回头一看，已经和月初不太像同一个站了，我就觉得可以叫它 4.0 了。

0914—17

mergedmain / reading阅读体验

滚动进度条、滚动动画提示、文章胶片和 Lottie 画廊陆续上线，奶奶那篇就是用胶片排的。16 号加了视频壁纸，17 号又撤掉了。

0918—21

syncedmain / analytics统计与文章

两篇文章公开，自动上架更新到 v4.1.1；统计切到自建 Umami，友链状态标签重新整理，Demius 加入友链。

0922—25

reviewedmain / comments评论与友链

评论区支持 Lottie 表情并重做了选择器，修了暗色模式对比度；出门去野钓加入友链，站点加入开往、BokeHub 和 hao.asoe.cn。

0926—27

releasedmain / v4.0.0Aemeath v4.0.0

导航栏、外观设置、页面切换和侧边栏一起收尾，版本号正式跳到 v4.0.0。

单看每一天都只是小改动，回放一遍才发现，4.0 是这么一点点攒出来的。

评论区：能用表情说话了#

评论支持 Lottie 动态表情，后来又把表情选择器重新做了一遍，找表情不用翻半天。
调整了 Waline 的 AI 回复体验。

阅读：知道自己读到哪了#

加了全局滚动进度条。
调整了滚动动画的提示。
文章里支持胶片式排版和 Lottie 画廊。
修了暗色模式下几处文字对比度太低的问题。

导航和外观#

导航栏的悬停、子菜单都重新调过，默认改成展开状态，老访客的偏好也做了迁移。
外观设置重新整理了一遍。
页面切换和侧边栏的一些小毛病顺手修掉了。
博客更新日志单独成页，版本号和日志保持同步。

这个月也做了一次“停止”#

视频壁纸已撤回

上线一天，太晃眼睛

番茄的推荐本期暂停

同样的原因，体验差了很多

9 月 16 日，我给博客加上了视频壁纸，17 号就撤掉了。

原因也简单：太晃眼睛了。背景一直在动，眼睛就总被它拽过去，文章读不进去。

这件事让我想清楚了一点：这里本质上还是博客，是用来写文章、读文章的地方，不是用来秀技术的。好不好看当然重要，但不能让读的人觉得累。

上期我说自己一直在加，也一直在删。这次从加到删只隔了一天，比以前快多了。我觉得这算进步：判断一个东西不对，不一定要先硬撑一个月。

自动上架：更新到 v4.1.1#

自动上架工具这个月更新到了 v4.1.1，自动上架系统那篇文章也扩写了一大段。它还是站里被读得最多的文章。

这个月的变化主要是把“批次更大、店铺更多”之后的边界锁死：分批上架范围、多个店铺分开上架、PNG 兼容、图片组严格匹配、编辑页身份严格校验。9 月 18 日我还把项目正式放进了 Git 仓库，之后又修了上架历史读取批次标签的问题，更新了店铺方案和 SKU 型号表。

一句话概括：它越来越少“猜”，越来越多“先证明再动手”。

博客开始连进更大的圈子#

这个月博客加入了几个博客社区和导航站：

友链这边，新认识了出门去野钓和 Demius。一个写野钓，一个写技术和时间，都是我自己不会去写、但读起来挺有意思的东西。

生活篇#

本期暂无。这一栏我想换个写法，还在想，先空着。

9 月推荐友链#

本期一共 7 位。前面 4 位是上期留下来的老朋友，后面 3 位是这个月新加的。

上期还推荐过番茄主理人，这期我想了很久，还是没放。他的动态页我特别喜欢，本来正打算抄过来，可视频壁纸看着确实难受，整体体验差了不少。说起来有点好笑，我自己也搞过视频壁纸，上线一天就下了，原因一模一样。

夏夜流萤 #

本月推荐Firefly 作者技术分享

这一位是必须要放的。本站就是基于他的 Firefly 主题二创出来的（关于我里也写了），我是站在巨人的肩膀上。每次改博客的时候翻源码，都能感受到原作者在结构上花的心思。

站在巨人的肩膀上 页面加载 · GitHub API

我的博客源码开源在 Aemeath。本站基于 CuteLeaf 的 Firefly 主题继续二次创作，也在这里向原作者致谢。

Jarvis0227

Aemeath

Waiting for api.github.com...

Waiting for api.github.com...

00K

Waiting...

AIOVTUE-雪 #

本月推荐博客主题开源教程

我的好朋友，也是我的第一个友链。站里很多小设计都是参考他做的，比如站点统计、友链，包括现在的月刊……这么一想，参考了不少呢。这个月从他那边点进来的访客也不少，友链真的在互相带人。

Homulilly #

本月推荐Hexo博客主题开源

他的站点真的好好看，我是真的喜欢。也是受他启发，我正在把源站那些卡片和标签改成我自己的设计，不想一直用原主题的样子。所以这期继续推荐他。

Detached #

本月推荐独立开发技术工具生活记录

也是我的好朋友。他的站也快得不行，羡慕坏了。这个月我抄了他的导航栏设计。他的风格切换也很神奇，我打算照着规划一下：做一个极简主题，再保留现在这种花哨一点的，还在规划中。

时光潜流 #

本月推荐后端开发运维技术分享

我最喜欢的是他网站的流畅度，点哪儿都是秒开，像在本地运行一样。一个写后端和运维的人，把自己的站点调成这样，本身就是最好的作品展示。

冷月笙寒的小窝 #

本月推荐个人博客技术分享生活记录

从 2019 年一直写到现在，这份坚持本身就让我佩服。站里除了文章，还有说说、相册、服务监控、建站日志，还有 SkyPanel、Bing 壁纸 API、AuroraPlayer 这些自己做的小项目，逛起来像在参观一个人慢慢攒起来的家。想先读一篇的话，可以看这个月的《完整扒站实践》。

清吾 #

本月推荐个人博客技术分享生活记录

“一个温馨二次元的小屋”，这个描述挺准的。我喜欢他写文章的方式：不只放效果，还把怎么做的讲清楚，比如《用 Motion 做克制的动效：滚动揭示与滚动缩放》和《玻璃拟态卡片与聚光效果》。“克制”这两个字，正好也是我这个月撤掉视频壁纸之后最想学的。

评选规则#

和上期一样。这不是按权重排的榜单，也不是一次性打分。每期主要看五件事：

有持续更新、能读到内容的站点；
有自己的表达和长期打磨的痕迹；
读完文章或逛完页面后，仍会想多停一会儿、再点开几篇的那种吸引力。
界面符不符合Ai的审美
Ai觉得你的文章写得不错

满足这些才会被Ai写进当期月刊；下期会重新观察，不把推荐当永久标签。

剩下就是我个人评选啦，私心肯定有但不多~

写在第二期月刊最后#

第一次做一件事，靠的是新鲜感。第二次靠什么，我也说不太清楚。

写第一期的时候，我什么都想放进去。到了第二期，我开始知道哪些东西不用写，也知道月底会有这么一个晚上，要把这一个月认真翻一遍。

这个月我做得最多的，其实是“收”：撤掉视频壁纸，推荐名单里拿掉了一位，规划主题时想的也是先做一个极简版。第一期我总想证明自己能做很多东西，到了第二期，我更在意留下来的东西是不是真的好用、好读。

坚持到第二次，没有第一次那么兴奋，但更踏实一点。我知道这件事能继续下去了。

下个月月底，再见。

跨境电商 Agents：从 AI 选品到自动经营

Mon, 21 Sep 2026 00:00:00 GMT

最近出来了一个新的模型决策 AI——Ai-Jev。它有意思的地方，不只是“能不能把问题回答得更好”，而是它开始让我重新思考：如果让 AI 长期观察数据、判断下一步该做什么，再调用不同的工具和 Agents 去执行，跨境电商是不是可以从一堆零散的自动化脚本，变成一套真正会自己运转的系统？

我想到的不是再做一个“自动上架工具”，而是搭建一套跨境电商 Agents：选品、采集、竞品研究、标题和详情页、本地化运营、生图、质检、上架、广告投放、客服和数据复盘，尽可能都接入同一个任务系统。

目前这还只是一个进行中的实践，完成度大概在 50% 左右。但已经足够让我看到一个方向：未来的跨境电商，可能不是一个人管理一家店，而是一个人设定目标和边界，再让一组 Agents 持续做研究、执行和试错。

1. 为什么我会想到 OPC + AIGC + Agents#

传统 OPC，也就是一个人或一个很小的团队运营一家跨境店铺，最大的限制并不是不会做，而是精力很难同时覆盖所有环节。

一个人要找产品、看竞品、算利润、联系供应链、做图片、写标题、上架、投广告、看数据、处理客服和售后。每件事单独看都不复杂，但它们会在一天里不断切换。广告需要盯，商品需要更新，平台规则也可能随时变化，最后往往是最重要的判断没有时间做，时间都消耗在重复操作上。

传统自动化可以解决一部分重复点击，却很难处理开放环境里的变化：页面改版了怎么办？竞品标题变了怎么办？一张图虽然生成成功，但主产品被遮挡了怎么办？广告数据不够好，到底应该改素材、改价格，还是直接停止测试？

单独使用大模型也有另一个问题：它可以帮我分析一次、生成一张图、写一段文案，但不会天然地记住整个店铺的状态，更不会自动完成后续执行和验证。

所以我更想做的是三层组合：

层级	作用
数据和工具	采集平台前台数据、商品素材、店铺指标、广告数据和供应链信息
Agents	分别执行选品、文案、生图、上架、投放、客服等具体任务
Ai-Jev 决策层	判断现在要不要调用 Agent、调用哪个 Agent、是否继续、是否重试或停止

简单说，Agent 负责做事，Ai-Jev 负责决定下一步做什么，数据再把结果反馈回来。

数据与信号 → Ai-Jev 判断 → 调用 Agent 执行 → 质量检查 → 结果回流 → 下一轮决策

这比“让一个模型包办所有事情”更接近真实业务，也更容易逐步替换和扩展。

2. AI 上架与本地化运营：不只是把商品翻译过去#

自动上架只是最容易被看见的一层。真正有价值的是，Agent 可以把一个商品从“原始素材”转换成“适合某个市场、某个平台、某家店铺的商品页面”。

一条比较完整的链路可以是：

从供应商、平台前台或已有商品库采集商品信息；
清理厂家信息、重复描述和不适合目标市场的表达；
判断目标平台类目、属性、规格和变体结构；
参考当地竞品标题、卖点、价格区间和图片结构；
生成目标语言的标题、五点描述、详情文案和搜索词；
根据利润、运费、平台佣金和活动规则计算价格；
生成或整理图片，再做尺寸、主体、文字和合规检查；
最后才调用平台或 ERP 的上架 Agent 执行发布。

本地化也不应该只是逐句翻译。不同市场对卖点的关注点、表达习惯、尺寸单位、场景和审美都不一样。一个在中国电商页面里成立的标题，直接翻译之后可能既不自然，也没有覆盖当地用户真正搜索的词。

我希望 Agent 在上架前先去目标地区的平台前台看一遍：这个类目现在的主流标题怎么写，竞品图片怎么排，消费者评论里反复抱怨什么，再结合自己的产品条件生成更适合的版本。

AI 对目标市场和竞品数据的概览分析

这类分析可以作为本地化上架前的输入，让标题、卖点、图片和价格不再完全凭经验决定。

真正执行上架时，系统仍然需要任务队列、状态记录和异常队列。商品缺少必填属性、图片尺寸不对、类目无法判断、品牌信息存在风险时，不能为了追求“全自动”而强行发布，而应该停在具体步骤，让人补充信息或让另一个 Agent 重新处理。

3. AI 选品：从“我觉得会卖”变成可验证的假设#

我理解的 AI 选品，不是让模型直接给我一个“爆款名单”，而是让它持续收集信号，帮我把一个模糊的想法拆成可以验证的假设。

它可以观察：

搜索词和类目的增长趋势；
商品数量、价格区间和近 30 天销量；
头部商品的销售集中度；
竞品的标题、主图、详情结构和评论痛点；
本地卖家和跨境卖家的比例；
物流体积、退货风险、供应稳定性和毛利空间；
是否存在专利、商标、外观或平台合规风险。

例如下面这次平板保护套的分析，Agent 不是只说“这个品类不错”，而是先整理样本数量、价格、销量和热销商品，再给出具体的型号集中度和竞争判断。这样得到的结论，才有机会转成后续的上架和广告测试计划。

AI 选品的市场样本与关键指标

AI 选品报告中的市场概览

选品 Agent 的输出也不应该只有一个分数，更应该包含：为什么值得测试、最大的风险是什么、需要准备哪些素材、第一批要测几个价格、预算上限是多少、什么数据出现后应该停止。

最终的选品逻辑可以变成一个小实验：先选出若干候选产品，生成最低成本的商品页和素材，给它们一个可控预算，观察点击率、加购率、转化率、退款和利润，再决定要不要扩大。AI 可能会误判，但只要每一次判断都有记录、每一次尝试都有结果，系统就会慢慢积累出属于自己的经验。

4. AI 生图：从一次生成，变成生成—识别—淘汰—重生成#

传统生图流程通常是：写提示词、生成一张图、觉得差不多就用了。问题在于，“生成成功”不等于“适合卖货”。主产品可能被杯子、花瓶或手部遮住，产品结构可能变形，颜色可能和实物不一致，画面里还可能出现不应该存在的配件。

我现在更关注的是让 Agent 参与图片质量闭环：

根据商品本身和目标市场竞品，制定这组图的用途；
调用生图工具生成主图、场景图、细节图和使用图；
让视觉检查 Agent 判断主体是否完整、产品是否被遮挡、数量和颜色是否正确；
不合格的图片进入淘汰队列，记录具体问题；
只针对问题重新生成，而不是每次从头碰运气；
通过后再按平台尺寸和详情页顺序整理上传。

下面是一次实际遇到的问题。第一版详情图的场景氛围不错，但主产品被画面元素遮挡，作为商品展示图并不合格。Agent 识别到这个问题后，没有把它直接放进商品页，而是重新调整主体位置和展示方式，生成了可以继续进入候选池的版本。

第一次生成的详情图：主产品被场景元素遮挡

问题版本：画面有氛围，但没有优先保证商品主体清晰可见。

Agent 重新生成并整理后的图片候选

调整后：保留场景感，同时补充更清晰的产品展示和使用场景。

这也是我觉得 Agents 比单次调用生图 API 更有价值的地方。它不只是“会生成”，而是可以判断结果是否值得留下。未来还可以加入品牌色、产品结构比对、文字区域检测、平台图片规范检查，甚至让它根据广告数据判断哪一种视觉方向更值得继续测试。

5. AI Agent 可以覆盖跨境电商的哪些环节#

如果把自动上架当成入口，后面可以继续扩展成一条完整的经营链路。

AI 竞品研究与市场监控#

Agent 可以定期访问目标平台的前台，记录竞品的标题、价格、销量、促销、评论和图片变化。当某个竞品突然降价、某个关键词开始出现大量新商品，或者某种素材结构明显变多时，系统可以把变化整理成提醒，而不是等人偶尔打开页面才发现。

AI 标题、详情和本地化内容#

同一个产品可以根据国家、平台、流量入口生成不同版本。Agent 负责从竞品中提取表达方式，再结合自己的真实参数生成标题和详情，避免夸大功能、遗漏关键属性或直接复制竞品内容。

AI 广告投放与素材实验#

它可以结合曝光、点击、点击成本、加购、转化、利润和库存判断下一步动作：保留哪张图、暂停哪个广告组、调整哪个关键词、是否扩大预算、是否需要重新生成素材。

这里最重要的不是让 AI 每分钟都改一次广告，而是让它提出可解释的实验假设。例如“点击率不错但转化低，可能是主图承诺与详情页不一致”，然后只调整一个变量，用数据验证，而不是同时改价格、标题、图片和预算，最后什么也分析不出来。

AI 客服、评论与售后#

Agent 可以把评论和客服对话按问题分类，提炼出高频疑问，再反过来优化详情页和 FAQ。常见问题可以自动回复，涉及退款、纠纷、敏感承诺或高风险客户时再交给人工处理。

AI 定价、库存与供应链#

结合采购价、物流费、平台佣金、广告成本和退货率，系统可以持续计算真实利润，而不是只看销售额。库存不足时暂停投放，库存积压时设计折扣测试，供应商涨价时重新评估售价和广告上限。

AI 合规与风险检查#

发布前检查违禁词、品牌词、图片中的商标、虚假承诺、类目属性和当地法规要求。它不能替代专业法律意见，但可以把大量低级错误挡在发布前，减少因为疏忽造成的风险。

6. 我设想的运行方式：固定脚本负责日常，Ai-Jev 负责决定何时调用 Agents#

我并不想把所有事情都交给一个模型实时处理。很多重复、稳定、规则清晰的工作，用固定脚本跑更可靠；只有遇到需要理解、比较和判断的场景，才让 Ai-Jev 调用对应的 Agent。

例如：

日常同步库存、整理文件、检查任务状态，用固定脚本运行；
发现某个市场的销量、价格或竞品结构出现变化，交给 Ai-Jev 判断是否启动选品 Agent；
发现图片质量检测失败，调用生图和视觉审核 Agent；
发现平台页面改版或任务异常，把截图、日志和当前步骤交给 GPT Luna 处理；
广告数据达到预设条件后，生成一个新的素材或预算实验，而不是无条件改动账户。

这样做的好处是成本、速度和稳定性更可控。AI 不需要在每一个普通动作里重复思考，而是在出现变化或需要决策时介入。

7. 从一家店开始，把成功逻辑复制到更多店铺#

传统 OPC 的问题之一，是一个人很难长期盯住很多店铺。但如果第一家店铺的流程被整理成数据、规则、素材模板、任务状态和复盘结果，后续就不必每次重新从零开始。

可以复制的不是某个店铺的具体商品，而是一套经过实践验证的逻辑：

什么样的产品值得进入测试池；
什么样的图片结构更适合这个市场；
标题和详情页如何本地化；
什么指标出现后开始加预算；
什么异常必须人工确认；
什么情况下应该停止一个产品。

复制到新店铺或新市场时，Agents 可以重新读取当地数据，调整语言、价格、素材和投放策略。这样是“复制方法”，不是把同一份内容机械铺到所有店铺。

更进一步，系统还可以自己提出新的尝试：新的标题结构、不同的主图风格、不同的价格区间、不同的广告受众。人负责设定边界和预算，AI 负责提出更多低成本实验。

8. 这件事真正难的地方，不是调用模型#

现在回头看，接入一个模型、调用一个生图工具、写一个浏览器 Worker，都不是最难的部分。真正困难的是把业务目标变成可判断的规则。

比如：什么叫“图片合格”？什么叫“产品值得继续投”？什么情况下可以自动发布？什么情况下必须停下来问人？如果这些问题没有定义清楚，Agents 只会更快地制造更多不确定结果。

所以我会把下面几件事放在系统底座里：

每个任务都有唯一 ID、当前步骤和可追溯日志；
发布、扣库存、改预算等有副作用的动作必须做幂等检查；
不确定的结果进入异常队列，不允许无限重试；
重要操作保留截图、输入、输出和决策原因；
不同店铺、国家和平台使用独立的权限、规则和素材；
AI 的结论必须能回到数据，而不是只给一个看起来很确定的答案。

AI 也可能误判，广告数据也可能因为样本太少而产生错觉，竞品的动作更不代表自己的产品一定适合照搬。我的目标不是让系统永远正确，而是让它可以低成本地尝试、及时发现错误、快速停止，并且从结果里积累经验。

9. 现在做到哪一步了#

目前这套跨境电商 Agents 还没有完全成型，大概完成了 50%。已经能够看到的部分包括：采集和分析数据、根据竞品辅助选品、生成本地化内容、调用生图、对生成结果做检查，以及把任务继续交给上架流程。

接下来还需要继续解决：多店铺状态管理、广告数据的长期记忆、不同平台的权限和风控、素材与真实商品的一致性、实验结果归因，以及在自动化失败时如何更准确地把问题交给合适的人或 Agent。

但我觉得它不需要等到 100% 完美才有价值。只要它能把一次选品、一次上架、一次生图或一次广告实验闭环跑通，就可以从一个真实店铺开始积累数据。跑得越多，规则越清楚，后面的店铺就越容易复用。

最后：让人从重复操作里出来，把时间留给判断#

我并不认为未来的跨境电商会变成“完全不需要人”。相反，人的工作会从每天盯着页面、搬运数据、修改几十个标题，转向设定目标、约束预算、判断方向和处理真正复杂的异常。

Ai-Jev 负责做更长周期的判断，Agents 负责调用工具和完成任务，固定脚本负责稳定的日常流程，数据负责告诉我们结果到底有没有变好。这个组合也许还不成熟，甚至会误判，但它至少提供了一种新的工作方式：一次只经营一家店铺的人，可以开始尝试管理一套能够持续学习和复制的经营系统。

这就是我现在想做的跨境电商 Agents。它不是一个“自动上架按钮”，而是一套从 AI 选品开始，经过本地化内容、生图质检、自动执行、广告实验和数据复盘，逐步走向自动经营的系统。

Codex 为什么会“降智”：292 State、状态注入与长任务的另一条解释

Fri, 18 Sep 2026 00:00:00 GMT

最近使用 Codex 处理一些时间较长的任务时，我反复遇到几个很难解释的现象。

同一个账号、相同的模型和相近的提示词，有时可以连续完成多文件重构；换一个时间段之后，却开始忘记上下文、重复已经解决的问题，甚至给出像是低配模型生成的答案。

Codex 的 cloud agent 也会频繁出现 overloaded，请求还可能返回 429。

换一个会话、换一个网络出口，或者等一段时间之后，状态又似乎恢复了。

这到底是模型本身发生了变化，还是服务端的调度状态发生了变化？

我现在更认可后一种解释。

Codex 背后存在一套和资源路由、请求状态、上下文压缩以及长任务连续性有关的机制。我们看到的“降智”，往往不是单纯的模型能力变化，而是多个状态同时变化后的结果。

其中最值得关注的，就是 HTTP 292 和 current_turn_state。

先说结论#

这件事可以拆成两条同时运行的链路。

第一条是资源链路：

1
请求
2
  ↓
3
服务端调度
4
  ↓
5
HTTP 292 / current_turn_state
6
  ↓
7
资源等级与后端路由
8
  ↓
9
后续请求继续携带 state

第二条是任务链路：

1
对话与工具调用
2
  ↓
3
上下文不断增长
4
  ↓
5
达到阈值后压缩
6
  ↓
7
部分细节被重新概括
8
  ↓
9
长任务表现发生变化

292 State 主要解释第一条链路。

上下文增长和 compaction 主要解释第二条链路。

两者叠加之后，就会出现一种非常真实的用户体验：

任务刚开始时模型很聪明，运行一段时间后，它像是换了一个模型。

这里先把资料分成三种：

公开源码已经能确认的部分：Codex 存在 x-codex-turn-state，并把它用于同一轮请求的粘性路由。
公开讨论和实际观察中的部分：292、current_turn_state、约一小时 TTL、IP 不绑定以及资源等级之间的关系。
本文自己的代码：保留状态摘要记录、续期逻辑和路由结构示意，用来还原这套调度流程。

这三类证据不能混在一起，但它们可以拼出一套比较完整的解释。

292 到底是什么#

标准 HTTP 规范里没有 292 这个状态码。IANA 的标准登记表中也没有记录它。IANA HTTP Status Code Registry

但这并不代表服务内部不能使用私有状态码。

大型平台通常会在标准 HTTP 状态之外，通过响应头、内部元数据或自定义状态表示更多调度信息。

292 就是这样一种内部信号。

目前比较合理的解释是：当请求到达服务端之后，调度器会先判断当前请求应该进入什么资源路径，包括：

路由到哪个模型实例。
使用什么推理质量。
分配多少计算资源。
是否允许完整上下文。
是否进入备用或降级队列。
后续请求是否可以继续复用当前调度结果。

调度正常时，服务端返回 292，并附带一个 current_turn_state。

当前资源紧张时，则返回普通的 200，但请求实际进入资源受限或降级路径。

可以把它简单理解成：

状态	含义	用户表现
292	调度正常、资源路径稳定	速度快，推理完整，较少出现 overload
200	HTTP 请求成功，但不代表资源等级相同	能返回结果，但可能变慢、变浅或更容易丢上下文
429	请求过快或触发限流	请求失败，需要退避
503	服务暂时过载	请求失败或排队

这里需要强调，292 和 200 的对应关系目前属于逆向观察，不是 OpenAI 公开文档确认的协议。

但这个解释能够很好地解释一种现象：

请求明明成功返回了，为什么模型的质量还是明显下降了？

因为 HTTP 成功和获得相同的计算资源，并不是一回事。

`current_turn_state` 是什么#

公开的 Codex 源码中，可以看到一个真实存在的状态：

1
x-codex-turn-state

官方客户端把它描述为 sticky-routing token，也就是粘性路由状态。Codex 官方 client.rs

它的基本流程是：

一轮 turn 开始。
服务器返回 turn state。
客户端保存这个状态。
同一轮中的后续请求继续携带它。
任务进入新的 turn 后，应该创建新的 session。

SSE、WebSocket 和 compact 请求也会处理这个状态。SSE 响应处理 WebSocket 响应处理

这至少证明了一个事实：

Codex 的请求并不是完全独立的，服务端确实会使用某种状态维持同一轮任务的连续路由。

公开源码使用的是 x-codex-turn-state，而一些逆向观察把更上层的状态称为 current_turn_state。

我更倾向于把它们理解成同一套调度机制的不同表现：

HTTP 292 更像服务端给出的资源调度结果。
current_turn_state 更像资源调度凭据。
x-codex-turn-state 更像客户端继续发送的 turn 粘性状态。

它们属于同一个服务端状态系统的不同层级。

官方源码把 x-codex-turn-state 放在 turn 范围内，说明客户端看到的 header 负责维持当前 turn 的粘性路由；292 和 current_turn_state 则是更上层的资源状态。它们不需要是同一个字段，但共同指向同一个结论：Codex 并不是无状态地处理每一个请求。

为什么不是所有人都能拿到 292#

如果 292 代表一次调度成功，那么它就不应该对所有请求无差别发放。

从实际观察来看，影响 292 签发的因素主要有四类。

IP 质量#

不同网络出口具有不同的风控和资源评分。

但如果只把 292 理解成“当前还有算力”，仍然漏掉了更核心的一层：它是服务端在判断请求来源之后，为高可信用户保留完整服务路径的调度标记。

这套分层首先照顾的是美国本地的真实用户。这里的“本地”不是简单读取一个国家字段，而是综合网络出口、ASN、地理位置、IP 信誉、账号历史和请求行为等信号。稳定的美国住宅宽带，更像一个真实家庭用户的固定网络；中转站、共享代理、VPN、VPS 和数据中心出口，则更容易呈现出多人共用、地域与账号不一致、请求集中或出口频繁变化等特征。

服务端没有必要把这些流量全部拒绝。更现实的做法是，在资源紧张时先保护本地住宅用户的体验，再把中转、共享 VPN 和数据中心流量放进普通或降级路径。后者仍然可以拿到响应，但更容易遇到等待、overload、429、503，以及长任务连续性变差。

所以，292 的核心并不是“美国 IP 有一个特殊开关”，而是服务端把不同来源的请求放进了不同的服务质量等级：

flowchart TD A[请求进入] --> B[IP / ASN / 地理位置 / 账号 / 行为] B --> C{服务质量分层} C -->|美国住宅、稳定低风险| D[完整资源路径] C -->|中转、共享 VPN、数据中心| E[普通或降级路径] D --> F[292 + state + 更稳定的长任务] E --> G[200 / 429 / 503 / overload]

这也解释了为什么同一个账号会出现明显的网络差异：变化的未必是账号权限，而是请求被服务端放进了哪一层。

可以把实验中的 IP 类型粗略分成：

IP 类型	观察到的 292 通过率	说明
美国住宅宽带	较高	真实 ISP 住宅出口
原生 IPv6	较高	某些地址可能被视为更自然的用户网络
欧洲或亚洲住宅	中等	仍可能获得正常状态，但概率不稳定
数据中心 IP	较低	VPS、云服务器地址段容易被集中标记
共享 VPN 或公共代理	很低	同一个出口可能被大量用户使用

这张表不是固定不变的官方等级表，而是实际实验中最值得优先比较的网络分层。

如果同一个账号通过美国住宅网络容易拿到 292，通过数据中心或共享代理更容易进入普通 200，那么就说明 IP 质量已经参与了调度。更准确地说，服务端正在用网络来源判断“这个请求应该获得什么级别的服务”。

为什么中转和 VPN 更容易降级#

中转、VPN 和数据中心并不等于恶意请求，但从服务端的角度看，它们和共享滥用流量使用的是相似的网络信号：一个出口承载大量账号，账号所在地与 IP 所在地不一致，请求在短时间内集中出现，或者出口属于云厂商和代理服务商的地址段。

在高峰期，服务端最容易做的不是逐个判断“这个人是不是好用户”，而是先按网络来源做粗粒度分层。美国本地住宅出口更容易进入高优先级路径；中转站、共享 VPN 和数据中心出口则更容易保留基本可用性，但牺牲一部分速度、推理资源和长任务稳定性。

这就是“给当地居民更好的体验，给中转用户降级使用”的技术含义。它不是把某一类用户永久封死，而是在有限资源下把完整体验优先留给最像本地真实用户的请求。

账号等级#

不同订阅等级具有不同的资源优先级。

需要比较的变量包括：

Free。
Plus。
Pro。
更高等级的 Pro 计划。

不能只拿一个账号测试一次就得出结论。更可靠的方式是使用相同模型、相同提示词和相近时间重复测试。

服务端负载#

即使账号和 IP 都没有变化，服务端高峰期也可能收紧 292 的签发。

这可以解释为什么：

早上状态很好，下午开始变差。
工作日和周末体验不同。
同一个会话上午正常，晚上频繁 overload。
等几个小时后，模型又恢复了。

这不一定是用户发生了变化，也可能只是服务端整体负载发生了变化。

State 的有效期#

current_turn_state 的 TTL 约为一小时。

也就是说：

第一次请求成功获得 292。
服务端签发一个 state。
接下来一段时间内可以继续复用。
超过有效期之后，state 失效。
下一次请求需要重新进行调度。

这可以解释“刚刚还很好，过一会儿突然变差”的体验。

当然，TTL 不能只凭一次观察确定，必须通过连续重放实验测量。

验证不能只靠感觉#

如果只是在浏览器里感觉“今天好像聪明一点”，很难证明 292 State 的作用。

接下来需要测量四个变量：

292 是否和 state 一起出现。
携带有效 state 是否真的改变后续结果。
state 是否和 IP 绑定。
state 的 TTL 大约是多少。

第一组：观察 292 和 state 是否同时出现#

每次请求至少记录：

1
timestamp
2
network_profile
3
account_level
4
model
5
http_status
6
state_present
7
state_hash
8
latency_ms
9
retry_after
10
overloaded

记录时可以用 state 的哈希作为标识。

1
from __future__ import annotations
2

3
import hashlib
4
from typing import Mapping
5

6

7
def summarize_response(
8
  status: int,
9
  headers: Mapping[str, str],
10
  latency_ms: int,
11
) -> dict:
12
  state = (
13
    headers.get("current_turn_state")
14
    or headers.get("x-codex-turn-state")
15
  )
16

17
  return {
18
    "status": status,
19
    "state_present": bool(state),
20
    "state_hash": (
21
      hashlib.sha256(state.encode()).hexdigest()[:12]
22
      if state
23
      else None
24
    ),
25
    "latency_ms": latency_ms,
26
    "retry_after": headers.get("retry-after"),
27
    "server_model": headers.get("openai-model"),
28
  }

展开收起

这段代码只记录状态是否存在，不保存完整 token。

第二组：有状态和无状态对照#

至少准备三组请求：

1
A 组：普通线路，不携带 state
2
B 组：普通线路，携带有效 state
3
C 组：普通线路，携带过期或随机 state

三组请求应尽量保持：

相同账号。
相同模型。
相同提示词。
相近时间。
相同请求间隔。

需要比较的指标包括：

292 出现频率。
429 出现频率。
overloaded 出现频率。
首字节延迟。
输出长度。
工具调用是否中断。
上下文是否连续。
人工盲评结果。

如果只有 B 组长期表现更好，而 A、C 组明显更差，就可以量化 state 的作用。

第三组：验证是否绑定 IP#

这是整个理论最关键的验证。

流程应该是：

1
住宅 IP 获取 292 + state
2
        ↓
3
切换到数据中心或 IPLC
4
        ↓
5
不携带 state 请求一次
6
        ↓
7
携带 state 请求一次
8
        ↓
9
比较两次结果

如果不携带 state 的请求明显更容易降级，而携带同一个 state 的请求仍保持正常，说明 state 的使用和 IP 是分离的。

这个实验需要反复执行，用来排除服务端负载波动。

第四组：测量 TTL#

获得 state 后，按固定间隔重试：

1
0 分钟
2
10 分钟
3
20 分钟
4
30 分钟
5
45 分钟
6
55 分钟
7
60 分钟
8
70 分钟
9
90 分钟

每次记录：

是否仍被接受。
是否仍保持相同路由结果。
是否返回新的 292。
是否需要重新获取 state。
是否出现 429 或 503。

如果状态在接近一小时后稳定失效，才能说明“一小时 TTL”具有一定可信度。

状态获取和状态使用可以分开#

状态注入的核心思路是：

获取 state 的网络环境，和使用 state 的网络环境，不一定需要相同。

大致流程如下：

1
获取阶段：
2

3
Clash 切到住宅或原生 IPv6
4
        ↓
5
keeper 发送探测请求
6
        ↓
7
服务端返回 292
8
        ↓
9
提取 current_turn_state
10
        ↓
11
保存状态和过期时间
12
        ↓
13
Clash 切回日常线路
14

15

16
使用阶段：
17

18
Codex / ChatGPT 发出请求
19
        ↓
20
本地代理读取 state 文件
21
        ↓
22
在请求中加入状态 header
23
        ↓
24
转发到服务端
25
        ↓
26
服务端验证 state 是否有效

展开收起

这套设计的关键假设是：

state 不和签发时的 IP 强绑定。
state 代表的是调度结果，而不是 IP 身份。
state 在 TTL 内可以跨网络出口使用。
state 与实际使用的模型保持一致时效果最好。

如果这些假设成立，住宅 IP 只需要在获取阶段出现几秒钟，日常使用仍然可以走低延迟线路。

State 的真正作用：保留已经拿到的服务等级#

如果 292 只是“当前还有算力”，拿到一个 state 本身没有太大意义。状态注入之所以有效，是因为它把第一次请求时完成的服务质量判断延续到了后续请求。

获取阶段在美国住宅或其他高可信网络上拿到 292，等于先完成了一次更优先的资源调度。使用阶段即使切回中转、VPN 或日常线路，带上有效 state 后，服务端仍然可以把请求识别成已经建立的稳定 turn，而不是每次都根据当前出口重新从普通队列开始排队。

所以，state 的作用不是把数据中心 IP 变成住宅 IP，也不是改变账号的地区身份；它就是一张暂时有效的“服务等级通行证”，把之前已经拿到的资源路径延续一段时间。只要 state 仍在有效窗口内，后续请求就会继续沿用原来的调度结果；一旦过期、模型不匹配或服务端重新做风险判断，请求就会回到当前网络对应的普通路径。

这也解释了为什么“先住宅获取，再日常线路使用”比单纯切换 IP 更有意义：前者是在复用一次已经完成的调度，后者只是重新碰运气。

续期逻辑#

状态不能等到完全过期之后再续。

更合理的方式是提前五分钟续期，并且每 45 秒检查一次。

1
from __future__ import annotations
2

3
import json
4
import time
5
from pathlib import Path
6

7

8
STATE_FILE = Path("current_turn_state.json")
9
RENEW_BEFORE_SECONDS = 5 * 60
10

11

12
def load_state() -> dict | None:
13
  if not STATE_FILE.exists():
14
    return None
15

16
  return json.loads(STATE_FILE.read_text(encoding="utf-8"))
17

18

19
def should_renew(state: dict | None) -> bool:
20
  if not state:
21
    return True
22

23
  expires_at = float(state["expires_at"])
24
  return expires_at - time.time() <= RENEW_BEFORE_SECONDS
25

26

27
def save_state(value: str, ttl_seconds: int) -> None:
28
  payload = {
29
    "value": value,
30
    "expires_at": time.time() + ttl_seconds,
31
  }
32

33
  STATE_FILE.write_text(
34
    json.dumps(payload, indent=2),
35
    encoding="utf-8",
36
  )
37

38

39
def keeper_loop(acquire_state) -> None:
40
  while True:
41
    state = load_state()
42

43
    if not should_renew(state):
44
      time.sleep(45)
45
      continue
46

47
    # 这里调用探测逻辑，返回状态和 TTL。
48
    result = acquire_state()
49

50
    if result and result.get("status") == 292:
51
      save_state(
52
        value=result["state"],
53
        ttl_seconds=result.get("ttl", 3600),
54
      )
55
      print("state refreshed")
56
    else:
57
      print("state refresh failed")
58

59
    time.sleep(45)

展开收起

实际模型应该和使用模型保持一致。

例如，如果日常使用的是 gpt-6-astra，探测时也应该使用同一个模型，而不是用一个模型获取 state，再拿去请求另一个模型。

否则即使 state 有效，也不一定能覆盖另一个模型的资源路由。

真实验证路径#

这套机制真正要验证的不是“我能不能生成一个叫 state 的字符串”，而是下面这条因果链：

1
同一账号、同一模型、相近时间
2
        ↓
3
住宅 / 原生 IPv6 请求
4
        ↓
5
观察是否出现 HTTP 292 和 current_turn_state
6
        ↓
7
保存 state 的摘要与首次出现时间
8
        ↓
9
切换到日常线路
10
        ↓
11
分别发送不带 state 和带 state 的请求
12
        ↓
13
比较路由结果、延迟、429、503、overload 与输出质量

工程上可以拆成几个部分：

keeper 负责发起探测、保存 state 和提前续期。
本地代理负责在请求经过时读取当前 state。
Clash 或其他路由工具负责在探测线路和日常线路之间切换。
日志记录每一次响应的状态、延迟、模型和路由差异。

典型流程是：

在住宅或原生 IPv6 出口发起探测请求。
观察响应是否出现 292，以及是否返回 current_turn_state。
将 state 保存到本地文件，同时记录获取时间和预计过期时间。
在 state 过期前提前续期。
让本地代理在后续请求中携带 state。
切回日常线路，比较有 state 和无 state 的真实请求。

真实验证需要记录什么#

如果要把这套机制跑清楚，每次请求至少记录一行实验数据：

1
timestamp
2
account_level
3
model
4
network_profile
5
http_status
6
state_present
7
state_hash
8
latency_ms
9
retry_after
10
overloaded
11
context_size
12
compaction_happened

记录时可以用 state 的哈希作为标识：

1
from __future__ import annotations
2

3
import hashlib
4
from collections.abc import Mapping
5

6

7
def summarize_response(
8
    status: int,
9
    headers: Mapping[str, str],
10
    latency_ms: int,
11
) -> dict:
12
    state = (
13
        headers.get("current_turn_state")
14
        or headers.get("x-codex-turn-state")
15
    )
16

17
    return {
18
        "status": status,
19
        "state_present": bool(state),
20
        "state_hash": (
21
            hashlib.sha256(state.encode()).hexdigest()[:12]
22
            if state
23
            else None
24
        ),
25
        "latency_ms": latency_ms,
26
        "retry_after": headers.get("retry-after"),
27
        "server_model": headers.get("openai-model"),
28
    }

展开收起

这个函数把一次响应整理成便于比较的实验记录，后面可以直接写入 JSONL 或 CSV。

真实实验的对照组#

至少应该设置三组：

组别	网络	state	目的
A 组	日常线路	不携带	观察自然状态
B 组	日常线路	携带有效 state	观察注入后的状态
C 组	日常线路	携带随机或已过期 state	排除“只要多一个 header 就有效”的可能

三组请求尽量保持：

同一个账号。
同一个模型。
同一类提示词。
相近的时间段。
相同的请求间隔。
尽量相同的上下文长度。

如果只测试一次，结果很容易被时间、网络和服务负载干扰。更可靠的方式是跨多个时间段、多个网络出口重复测试，同时记录 429、503 和 overload 的出现情况。

IP 是否绑定，需要单独验证#

最关键的实验是 IP 绑定实验：

1
阶段一：住宅 / 原生 IPv6
2
    获取 292 和 state
3

4
阶段二：数据中心 / IPLC
5
    不携带 state 请求一次
6
    携带同一个 state 请求一次
7

8
阶段三：重复多轮
9
    比较两种请求的成功率和服务表现

如果携带 state 的请求在更换网络出口后仍然保持明显差异，就说明 state 的使用可能不依赖签发 IP。

更换 IP 后还要继续控制账号、模型、会话和提示词，否则很难判断变化到底来自 state 还是其他变量。

TTL 也必须实测#

TTL 约一小时，连续重放可以测出它的实际窗口。

拿到 state 后按固定时间间隔测试：

1
0 分钟
2
10 分钟
3
20 分钟
4
30 分钟
5
45 分钟
6
55 分钟
7
60 分钟
8
70 分钟
9
90 分钟

每个时间点记录：

state 是否仍然被接受。
是否仍然维持相同的响应特征。
是否出现新的 292。
是否出现 429、503 或 overload。
是否需要重新建立 session。
上下文是否已经发生 compaction。

如果多个时间段的结果都在接近一小时后发生变化，TTL 的判断才比较稳定。

结果怎么看#

Codex 官方源码读取 x-codex-turn-state，并把它作为同一 turn 内的 sticky-routing token；SSE、WebSocket 和 compact 路径也都会处理这个状态。

292、current_turn_state、IP 质量、TTL 和资源等级共同构成这套机制的核心变量。真实请求对照要测量的是：

292 是否和 state 稳定同时出现。
state 是否能在换 IP 后继续生效。
state 失效是否呈现稳定的时间窗口。
携带 state 后，429、503、overload 和响应延迟是否持续改善。
上下文长度和 compaction 是否会独立影响结果。

把这些变量拆开之后，才能知道“降智”究竟来自资源路由、状态过期，还是上下文已经变得过于复杂。

Clash 的路由切换#

如果实际实验需要切换不同出口，结构上通常需要两个代理组：

1
proxy-groups:
2
  - name: GPT-Daily
3
    type: select
4
    proxies:
5
      - Daily-Route-1
6
      - Daily-Route-2
7

8
  - name: GPT-State-Probe
9
    type: select
10
    proxies:
11
      - Residential-Route
12
      - Native-IPv6-Route

获取 state 时切换到 GPT-State-Probe。

获取完成后切回 GPT-Daily。

这也是为什么整个方案通常需要三个组件：

组件	职责
keeper	获取 state、记录 TTL、提前续期
本地代理	在请求链路中携带有效 state
Clash 或其他路由工具	在获取阶段切换网络出口

对 Codex 来说，它仍然只是向本地代理发请求，并不知道背后进行了状态管理。

上下文增长会放大问题#

即使状态路由保持稳定，长任务依然可能出现“降智”。

因为上下文本身也在不断增长。

一个复杂任务可能包含：

初始需求。
多轮对话。
大量文件内容。
多次代码修改。
测试日志。
浏览器截图。
工具调用结果。
被放弃的旧方案。
后来追加的临时要求。

这些内容都会进入任务历史。

刚开始时，模型只需要理解“我要做什么”。

任务进行到后面，它需要理解的是：

哪些内容仍然有效，哪些决定已经被推翻，哪些错误已经修复，现在文件系统的真实状态是什么？

上下文越长，模型拥有的信息越多，但真正重要的信息不一定更加突出。

如果一个任务中存在大量旧方案、失败日志和已经失效的指令，模型就需要花更多精力在上下文里寻找当前有效的答案。

这时即使资源路由没有变化，用户也会感觉模型变得迟钝。

压缩会改变任务的“记忆形状”#

当上下文接近上限时，Codex 需要进行 compaction，也就是上下文压缩。

OpenAI 官方文档说明，压缩后的内容是加密且不可直接解释的 opaque item，客户端不能简单地把它当成普通文本查看或编辑。Context compaction 官方文档

压缩可以让长任务继续运行，但它并不是把原来的上下文逐字保存下来。

原来的上下文里，可能有很多只有在具体语境中才有意义的判断：

这段代码暂时不能抽象。
这个按钮虽然多余，但用户已经习惯。
当前功能只需要验证流程，不应该继续扩展。
某个报错只是环境问题，不是代码逻辑问题。

压缩之后，这些细节可能仍然存在，也可能只剩下一段更概括的总结。

模型可能还记得“要完成什么”，但未必完整保留“为什么要这样完成”。

因此，压缩前后的任务目标看起来一样，工作风格却可能已经发生变化。

如果恰好在压缩、重连或重新路由之后，任务又失去了原来的 turn state，用户就更容易把这种变化理解成“模型降智”。

长任务其实是多种状态叠加#

可以把一个长任务简单理解成下面这几层：

flowchart TD A[一个长任务] --> B[会话与线程] A --> C[292 / 资源路由状态] A --> D[turn state] A --> E[上下文与压缩] A --> F[工具调用历史] A --> G[文件系统真实状态] A --> H[限流与服务负载]

这些状态任何一层发生变化，都可能影响最后的表现。

会话变化，可能导致上下文重新开始。
292 状态变化，可能导致资源路径发生变化。
turn state 丢失，可能导致同一轮请求不再保持粘性路由。
上下文压缩，可能让模型失去部分细节。
工具调用异常，可能让模型误判当前进度。
文件系统变化，可能让对话历史和真实项目不一致。
429 或 503，则可能直接造成请求失败或重试。

所以，模型表现变差并不一定只有一个原因。

但这几种状态如果同时变化，就很容易产生非常明显的“降智”体验。

429 和 overloaded 可能是结果，不是根因#

OpenAI 官方文档将 429 和 503 区分为两类问题。

429 通常和请求过快、流量增长过猛或速率限制有关。

503 server_is_overloaded 则表示模型服务暂时过载。

官方建议使用 Retry-After 和指数退避，而不是连续快速重试。Rate limits 官方文档

但从长任务角度看，429 和 overloaded 也可能只是我们看到的表面结果。

如果一个任务不断增长、频繁调用工具、反复重试，那么它可能同时带来：

更高的请求频率。
更大的上下文。
更多的压缩操作。
更多的状态切换。
更复杂的资源调度。

最终表现出来的就不只是一次请求失败，而是整个任务开始变得不稳定。

状态注入可能遇到的坑#

State 过期#

如果续期失败，旧 state 过期之后就会进入空窗期。

表现可能包括：

模型质量下降。
overload 增多。
重新出现 429。
长任务突然开始丢上下文。

所以续期应该提前五分钟开始，而不是等到最后一分钟。

模型不匹配#

用一个模型获取的 state，不一定适合另一个模型。

例如：

1
gpt-6-astra 获取的 state
2
不一定适合
3
其他模型的请求

实验时，获取模型和使用模型应该保持一致。

多账号不能混用#

每个账号的 state 应该独立保存。

不能把账号 A 获得的状态注入账号 B 的请求，也不能让多个账号共用同一个状态文件。

上下文压缩仍然会发生#

即使状态注入成功，也不能阻止上下文增长和 compaction。

状态注入解决的更像是资源和路由问题，不能保证模型永远记得每一个细节。

一个解决“分配到哪里”。

另一个解决“还能记住什么”。

和其他方法比较#

方法	原理	效果	问题
换 IP	碰运气进入更好的出口	有时有效	不稳定
新开会话	重新触发调度	偶尔有效	丢失上下文
多账号轮换	分散请求压力	可能有效	成本高、管理复杂
避开高峰期	等服务负载下降	通常有效	不适合连续工作
记录项目状态	减少上下文依赖	对长任务有效	不能改变资源路由
292 State 注入	复用稳定调度状态	理论上更稳定	需要验证 TTL、IP 绑定和模型匹配

292 State 注入的特别之处，在于它试图从调度层解决问题，而不是只在应用层缓解症状。

换 IP 是重新碰运气。

新会话是重新开始。

状态注入则是尝试保留原来的资源和路由结果。

这套机制为什么存在#

从平台的角度看，OpenAI 需要同时面对两个问题：

GPU 资源有限。
用户请求不断增长。

如果每个请求都重新排队，长任务的连续性会很差。

因此，服务端会在一轮任务开始时进行一次调度判断：

当前账号是否有优先级。
当前 IP 是否可信。
当前负载是否允许。
当前模型是否有资源。
是否可以给后续请求维持一条稳定通道。

292 和 state 就是这次调度结果的外部表现。

更核心的目的，是在资源有限和请求来源复杂的情况下，优先保证美国本地、稳定、低风险真实用户的体验。中转站、共享 VPN 和数据中心用户并不一定被拒绝，但更容易被放进普通或降级路径：能用，速度和稳定性却不再和本地住宅用户相同。

state 则负责把已经完成的调度结果延续到同一轮任务的后续请求，让高优先级路径不必每次从头竞争。网络切换、移动设备切换和长任务重试只是这个机制带来的连续性表现，不是它唯一的目的。

但如果 state 的签发和使用没有绑定 IP，就会产生一个意外特性：

获取状态和使用状态可以发生在不同的网络环境中。

这也正是状态注入理论成立的关键。

当然，这套机制未来可能被平台调整：绑定 IP、缩短 TTL、增加设备指纹、绑定账户和模型，都是很自然的防护方式。

所以它更像一个尚未被充分文档化的内部机制，而不是一个永远有效的漏洞。

最后#

我现在越来越不觉得 Codex 只是一个模型接口。

它更像是一个由模型、资源、上下文、工具、会话和路由共同组成的系统。

292 State 解释了资源路由这一层。

它最重要的含义，是服务端会优先把完整体验留给更像美国本地真实用户的请求，再把中转、共享 VPN 和数据中心流量降到仍然可用但更保守的路径。

x-codex-turn-state 说明 Codex 确实会在同一轮请求中维护粘性状态。

上下文增长和 compaction 解释了为什么长任务会逐渐失去细节。

429 和 overload 则说明服务端负载本身也会参与最终体验。OpenAI：Unrolling the Codex agent loop

所以，“降智”可能不是一个单独的问题，而是下面几件事同时发生：

1
292 状态没有拿到或已经过期
2
        +
3
后端资源路由发生变化
4
        +
5
上下文不断增长
6
        +
7
压缩后丢失部分细节
8
        +
9
服务端处于高负载
10
        =
11
用户感知到模型突然变笨

状态注入解决的是资源路由问题，不能替代上下文管理，但它为“降智”和 overload 提供了一个很有解释力的方向。

真正值得研究的，不只是模型本身有多聪明，而是：

这一次请求到底被分配到了什么资源，携带了什么状态，又在怎样的上下文里继续运行。

这可能才是长任务中最容易被忽略、也最影响体验的一层。

在奶奶的白发里，我看见了时间

Mon, 14 Sep 2026 00:00:00 GMT

休假结束后，又隔了许久没正经写点东西。

其实心里一直堆着满当当的感慨，千头万绪堵在喉咙口，真要落笔时，却又不知道该从何说起。索性就聊聊这半个多月以来，沉在心底的几分真实感受。

起因#

假期从 8 月 28 日开始，一直到 9 月 6 日。8 月 31 日和 9 月 1 日，我回了两天家。算下来，前前后后还是有将近半个月，没有像往常那样好好待在家里。

放在以前，每周休息日我总要抽一天回去，看看家里人，吃顿热乎的家常菜。这件事早已经成了不用刻意提醒的习惯。可这次一下子隔了这么久，再踏进家门的时候，竟莫名生出了一点生疏的亲切感。

周日下午吃过饭，我搬了张凳子，坐在阳台上晒着太阳，陪奶奶闲聊。

在奶奶的白发里，看见时间#

我们说着最近工作上的琐事、家里的日常、也聊到我对未来的打算。我正讲得起劲，目光无意间扫过她的头发。

那一刻，我像是忽然看见了时间留下的证据。

从前印象里，她总还留着大半黑发，常常笑着说自己头发白得慢，用不着染。可那天下午，太阳斜斜地落下来，明晃晃照得一清二楚——哪里还有什么黑发，满头都已经是霜白的颜色，连鬓角深处藏着的几根，也全都白透了。

我的心里猛地咯噔一下，话音也不自觉顿了半拍。

她依旧坐在那里听我说话，依旧会在我起身的时候问一句，要不要再带点什么。可我忽然意识到，那个我以为一直都会在的奶奶，也正在一天一天地老去。

那一刻，脑子里乱糟糟的，只有一个念头反复往上冒：

我到底，还剩下多少这样的日子？

还能有多少次，像这样安安静静地坐在她身边，听她念叨家常的下午？

时间从来不会等你准备好#

时间从来都是最残忍的东西。它不声不响，从不停留。你总觉得日子还长，总想着等忙完这阵，等做出点成绩，等站稳脚跟以后，再好好陪陪家人。

可时间从来不会等你准备好。

它就藏在奶奶新生的白发里，藏在每次回家时她递过来的热汤里，藏在一句句“在外面照顾好自己”的叮嘱里。不知不觉间，它已经把我们的岁月翻过去了大半。

也是从那时起，我重新想起了“时间”这件事。

以前我总觉得，上班嘛，说白了就是公司用钱买你的时间。每天八小时坐满，工作干到位，就对得起这份薪水。

可后来我慢慢想明白，公司真正买走的，或许不是你的时间，而是你在这段时间里能够交付的价值。而你拿去交换的，却是人生中一段不可回收的时间。

最遗憾的是，很多人卖着卖着，就把自己整段的人生都打包卖了出去。

连带着下班后的精力、对未来的规划、对生活的期待，全都困在了那份固定的薪水里。白天把时间交给工作，晚上把精力交给疲惫，等真正想做点自己的事情时，才发现已经没有多少力气了。

我们总以为以后还有机会。

可“以后”这两个字，往往是时间最温柔、也最危险的骗局。

我要把时间的主动权拿回来#

我今年 21 岁。过去的人生，几张幻灯片、几页简历就能全部放完，快得像一眨眼。再晃几年，三十岁也就到了。

这个年纪的我，没有太多资源，也没有一张保证成功的底牌。但至少，我还拥有试错的时间，还拥有重新开始的可能。

我不想等到那时候回头看，才发现自己最好的年纪，全都用来给别人的事业添砖加瓦，自己的时间、精力和选择，却始终没有真正掌握在自己手里。

所以我想，我得把时间的主动权拿回来。

决定自己创业#

我要自己创业了。

这句话写出来很轻，可真正扛在身上，一点都不轻。

上班这半年，我其实从来没有停下过自己的事情。从接触跨境电商的第一天开始，我的方向就不是传统电商那条老路。

别人靠铺货，靠低价，靠不断复制别人已经走过的路径；而我更想磨出一套属于自己的玩法——跨境电商 + AIGC + OPC。

从选品逻辑，到内容生产，再到店铺运营，把能够流程化、自动化的环节尽可能沉淀下来。这样以后不管是铺店，还是复制运营方式，都不需要每次从头开始。

这不是一时头脑发热的冲动，但也确实带着一股头脑发热的勇气。

我害怕，

尤其是奶奶。有些人，或许真的等不起我们口中的“以后”。

接下来，我会带着这套 Codex，一步一步运营两家店铺：一家完全交给 Codex，去跑一套由我设计好的运营流程；另一家则由我自己独立运营，亲自做判断，也亲自承担结果。

这既是创业，也是一次实验。

我想看看，一个人究竟能不能借助 AI，把自己的想法真正落地；也想看看，当工具越来越强，一个普通人能不能拥有一套不依赖大团队的工作方式。

我知道创业不等于自由#

当然，我知道创业不等于自由。

至少在一开始，它意味着更多的不确定、更长的工作时间，以及更直接的压力。上班有固定的发薪日，有同事、有流程，也有人替你分担一部分问题。自己做以后，没有人会替你回答为什么没有订单，为什么犯了错，为什么还没有结果。

这些我都知道。

所以我并不是因为看不起上班，也不是因为笃定自己一定会成功，才选择走这条路。

恰恰是因为我知道它可能很难，甚至可能失败，所以才想趁自己还年轻的时候，认真为自己闯一次。

有人说，安稳上班不好吗，何必折腾？

可我总觉得，人活着，就是要争这一口气。

争的不是和谁比高低，也不是非要证明自己比别人强。争的是一份对人生的主动权。

我要自己决定每天的时间花在哪里，决定自己的精力投入什么事情，决定自己愿意为什么样的结果负责。

我想靠自己的双手，走出一条不一样的路。

哪怕这条路并不平坦，哪怕中间会绕远、会犯错、会有一段时间看不到结果，至少那也是我自己选的路。

不想等到白发爬上自己鬓角的时候，才遗憾年轻时没有为自己认真活过一次。

路是走出来的，不是想出来的#

其实还有很多情绪没有说出口，也不必都说透。

千言万语，最终都要落到实处。路是走出来的，不是想出来的。

接下来的日子，我会把这些想法一点一点做出来，也把该承担的结果一一接住。

也希望读到这篇文章的人，能够珍惜时间，珍惜身边的人。不要把所有重要的事情，都推给那个永远不会真正到来的“以后”。

因为我们以为还很长的日子，可能转眼就过去了。

而真正值得我们抓住的，往往就是眼前这一刻。

月刊

Fri, 28 Aug 2026 00:00:00 GMT

最近做的事情有点杂：博客、自动上架、采购工具、几个做到一半又收手的小项目，还有终于布置好的小家。它们看起来没什么关系，却一起占掉了这个月的大部分时间。

这篇不想写成一份冷冰冰的完成事项清单。做成了什么当然要记，为什么返工、哪里没做完、哪些东西最后被我删掉，也一样值得写下来。

先看一下这个月的数据#

这次统计从 8 月 7 日到 8 月 26 日。先把 Umami 里的数字放在这里：

2.08k 位访客

2.87k 次访问

12.3k 次页面浏览

39% 跳出率

4′37″ 平均访问时长

数据来自 Umami，统计时间：8 月 7 日—8 月 26 日。

这些数字没法直接证明博客做得好不好，但至少说明这里开始有人路过了。有人从友链点进来，有人看完一篇文章又翻到另一篇，也有人愿意在评论区留句话。对一个还在慢慢搭建中的个人博客来说，这种“真的有人来过”的感觉，还是挺开心的。

Umami 站点数据统计

本月更新#

翻项目记录的时候，我发现这个月没有什么特别大的版本号，更多是一些零零碎碎的调整：一张页面补完整一点，一个后台入口变得能用一点，一段状态同步终于不再装死。单看每一项都不算惊天动地，但博客确实比月初更像一个我会长期使用的地方了。

博客内容和页面，慢慢长出自己的样子#

8 月 · 两篇新文章

8 月 14 日

今天发了这篇：
《朝朝听雨，岁岁有风》

那篇写的是高中时期的一段感情，也是我第一次比较完整地把那段青春重新翻出来。写的时候有点犹豫，毕竟这和技术文章完全不是一回事，但写完之后反而觉得，博客本来就不应该只放“有用的东西”。有些记忆如果不找个地方放着，过几年可能连自己都说不清了。

8 月 20 日

这一篇也发出来了：
《从母系社会到父权制度：亲缘、私有制与现代性别关系的演变（浅谈男女对立）》

这篇更像一次长一点的思考练习，我想把亲缘、继承、私有制和现代性别矛盾之间的关系捋一遍。它当然不可能把这么大的问题讲完，但至少把我当时的疑问和判断留下来了，之后想改也有地方可改。

朝朝听雨，岁岁有风从母系社会到父权制度

“关于我”页面也重新整理过。以前它更像一张简单的名片，后来我把头像、个人状态、本机信息、导航栏 Logo、页脚和移动端文章信息一点点补上。做这些时经常会怀疑：这真的重要吗？但页面最后呈现出来的感觉，往往就是这些小地方一起决定的。

个人资料和 README

项目、更新日志和状态区

评论区也没有闲着。评论区身份标记、登录入口、AI 摘要、AI 评论员、评论图片处理，这些功能前前后后改了几轮；站长后台还加了小爱回复入口和安全验证。现在我暂时没有把“完全自动回复”放开，公开评论区还是要留一点人工确认。AI 可以帮忙整理和起草，但最后发出去的话，至少应该有人看过。

AI review trace当前权限：只读建议

inspect
先查页面从评论里的描述开始，定位对应的组件和页面。
found
找到问题确认过一次 icon not found，追到 Svelte 图标组件。
proposed
提出修改整理原因和处理方案，交给站长确认。
reverted
自动修改撤回能发现问题不等于能直接改代码，最后保留人工检查。

result自动修改已撤回只留下发现问题和整理线索的部分

友链页面终于不只是几张卡片#

这个月在友链上花的时间，比我一开始想的多。

最早的友链页面就是头像、站名、描述和链接，排整齐了就算结束。后来越看越觉得不太对：既然叫友链，不能只是把朋友的网站摆在那里，然后大家各自沉默。于是我给它加了站点截图、推荐标记、申请说明、推荐语和交互式预览。鼠标移到卡片上时，可以先看看站点大概长什么样，再决定要不要点进去。

AIOVTUE-雪雨滴会记录生命中的每一个瞬间 博客主题开源教程

预览功能看起来只是一个悬浮卡片，实际要处理的东西不少：截图加载失败怎么办，卡片放在屏幕边缘会不会被截掉，手机上没有鼠标该怎么交互，页面切换回来之后事件还在不在。它不是本月最重要的功能，却是那种做完之后每天都会顺手用一下的改动。

后来我又做了“朋友圈”页面，读取友链站点的 RSS，把朋友们最近写的文章放进一条时间线里，再配上分页、文章元信息和随机文章过渡。友链因此不再是静态列表，朋友们更新文章时，这里也会跟着动起来。

随机一篇文章随手翻翻

正在挑选一篇文章… 从朋友圈文章里随机选一篇，换个角度继续阅读。

5 自动随机换一篇

我还试过自动检查友链是否可用，最后又把它撤掉了。网络请求本来就有偶发失败，站点临时维护、证书抖一下、接口响应慢一点，都可能让一个正常的网站被错判。做出来不难，做到足够可靠才难；既然现在还做不到，我宁愿先不让它替我下结论。

8 月 25 日，我把“友链穿梭”补了出来。它带着启动动画、终端感文字和一段穿梭过渡，为了让这几秒看起来不像突然弹了个新页面，我又来回调了文字对比度、终端填充、表面纹理、启动和退出动画。它对效率没有帮助，但确实让这个博客多了一点自己的脾气。

友链穿梭：从一面面站点截图之间穿过去。

顺带一提，穿梭页顶部那个小太阳 / 月亮不只是装饰：它会把整个界面切到浅色或暗色，不知道有没有人发现。

按日期回放，才知道这个月有多碎#

如果只看最后留下来的页面，很容易以为这些东西是一次性做完的。按日期回放就不是这样了。

0809—14

mergedmain / friends友链与文章

主要是在补友链、整理文章和调整站点基础信息。MingBlog、Ditto、sssr7844、S17、桃之夭夭、林子浩的日记、九仞之行、王一君 Mew 等站点陆续加进来，博客也把新的生活文章发了出去。

FRIEND FEED08 · scrolling

0815—18

reviewedmain / interface页面与评论区

重点变成友链预览、申请说明、推荐卡片和评论区。这几天还处理了字体自托管、移动端布局、评论区身份、AI 摘要、AI 推荐和站长邮件验证，改完一个地方，另一个地方往往又冒出一点间距问题。

0819—24

syncedmain / momentsRSS 与关于我

朋友圈开始接入 RSS，随机文章和分页也跟着补上。关于我页面、头像、Logo、页脚和图片资源重新整理了一遍，站内图片也逐步迁移到 WebP。

0825—26

releasedmain / portal友链穿梭与收尾

主要是把友链穿梭补完整，继续增加友链，调整导航栏光标和页面动画，再把小爱回复后台、自动部署这些收尾工作接起来。

有些改动现在已经看不出来当时花了多久，但它们叠在一起，才是这个月博客真正发生的变化。

自动上架：这个月真正新增了什么#

自动上架这个月修了不少底层问题，但这些东西对博客读者没有直接影响，同事只要知道它们已经处理好就够了。真正值得展开写的，是两个会改变实际工作方式的新功能：旧链接折扣批量处理，以及可以直接交到别人电脑上的采购工具。

修 Bug 的过程我没有删，只是先收起来。想看细节可以展开；只关心这月多了什么，直接往下读就行。

本月修复记录型号与标题 · 状态同步 · 图片参数联动

型号和标题规则，先把地基打牢

这个月先更新了印尼备货型号表。旧表有 299 条记录，新表变成了 301 条，新增两条 8.8 英寸型号，也调整了两处货位。更新之后，我又重新检查品牌、尺寸、字段完整性、重复冲突和 SKU 前缀，确认没有未知品牌、缺字段或非法前缀。

表格制作器里的图案编号也重新对过：3Y 对应 3Y-Fold，书本款要区分 No Pen Slot 和 With Pen Slot。这些词看着只是几个字符串，最后却会进入 SKU、图片目录和标题规则。前面改得随意一点，后面就可能出现图片匹配不上、型号分错组的问题。

标题这边也检查了 AI 随机组合、固定品牌、型号字段和字符上限。平台给出的上限是一回事，实际生成时还得留出安全余量，不能每次都贴着边缘写。配置检查中还发现过店铺档案和当前活动配置之间的细小不一致，这类问题平时可能不报错，批量发布时却很容易被放大。

后台已经结束，页面为什么还卡着

自动上架期间遇到过一次很典型的问题：Shopee 任务实际上已经 12/12、100%，后台状态也结束了，页面却还停在原来的步骤。

后来查清楚，任务没有停，卡住的是前台。SSE 长连接中途断掉，最后那条完成事件没有送到页面，所以用户看到的还是旧状态。这个问题如果只看界面，很容易误以为整个任务失败了。

之后我给服务端补了心跳、自动重试、TCP keepalive 和禁止代理缓冲，前端再加一层每 5 秒一次的轻量状态同步。SSE 出错、网络恢复、窗口重新聚焦或页面重新可见时，都会主动把状态重新对齐。Shopee 和 TikTok Shop 的事件流也保持独立，一个平台的连接坏了，不能把另一个平台一起带偏。

这次之后，我不太敢再把“有长连接”直接叫作实时了。连接会断，断了要有人补，补回来的状态还要和已经显示过的日志合并，这些都算在实时功能里面。

图片参数联动，范围不能串

设置页面还加了图片参数联动。以前改不同品牌时，需要重复填写每组图数、辅图数量、AI 识图和跳过序号几项参数。现在在当前店铺、当前平台、当前模板和当前通用类型的范围内，可以指定一个品牌作为同步源，其他品牌跟着更新。

这里最容易出错的不是同步本身，而是同步范围。普通模板和通用模板要分开，3Y、书本、笔槽、旋转也要分开；主图、变种图、偏移、标题和视频配置不能顺手一起覆盖。保存时原有的跳过序号冲突检查和九张产品图上限也必须保留。

配置功能特别容易出现一种错觉：页面上看起来只是改了当前这一组，实际上却把别的模板也一起改了。等到真正上架时才发现，通常已经晚了。所以这次我更在意“只改该改的地方”。

旧链接折扣，先学会识别再批量处理#

这个月还加了“批量开启旧链接折扣”。它会逐个打开旧链接的促销设置，识别折扣列，开启全部变种；只有非空折扣值一致时才继续批量更新，不一致的链接就跳过，并记录跳过原因。

识别折扣列促销价格不算折扣
只比较非空值空白行不参与判断
相同才继续50 / 50 / 50

一致批量处理不一致跳过，并记录原因

批量工具面板

这个工具一开始也踩了坑：未开启变种的空白行，被误当成了无法识别；折扣列和促销价格也不能混在一起看，不能看到一个 0 到 100 的数字，就认定那是折扣。后来规则改成只比较折扣列里非空的数值，空白行不参与一致性判断。50、50、50 可以继续处理，50、50、51 就必须停下来。

现场读到过一个 96 个变种的促销弹窗，其中 78 个非空折扣值全部是 50%，另外 18 个为空。识别完成后弹窗正常关闭，核心读取逻辑是通的；不过重启后台服务后的完整批量提交验证还需要单独补一轮，所以这件事我只写到“识别和跳过逻辑已经验证”，不把它夸成百分之百完成。

自动化最怕自信过头。标题错一次，可能只是一个商品；折扣错一次，可能就是一批链接。能识别、能跳过、能留下理由，有时比不管三七二十一都执行更重要。

写出来是一回事，交到别人电脑上又是另一回事#

这个月还把采购工具整理成了可以交付的版本。以前工具能在我电脑上运行，不代表换一台 Windows 电脑也能顺利启动。于是我把安装和启动流程收成双击就能执行的脚本，数据也放进本地数据库里，尽量不让接手的人先去补一套开发环境。

这种工作不太有“做完一个功能”的爽感，更多时候是在另一台电脑上反复点安装、点启动，再看它到底能不能真的打开。对我来说，能交到别人手里正常使用，比我自己本地跑通更像完成。

这个月也做了几次“停止”#

Rain 记账已停更

不再给自己新开一条线

8888 元项目未接

不把接下来几个月押进去

8 月 26 日起，Rain 记账项目正式停更。中转那边余留的 Pro 号也都处理掉了。不是它完全没有继续做的价值，而是我现在确实没有那么多精力，再开一条线只会让手上的事情越来越散。

这月还碰到了一笔 8888 元的企业级自动上架项目。对方愿意买下这套独家系统，听起来确实很诱人，但我当时第一反应不是“赚到了”，而是“接下来是不是要被它拴住”。

我爸说，我赚的这点钱，他躺着都能赚到，没必要为了这点钱糟蹋身体。话听起来有点扎心，但我后来想想，确实有道理。我只是刚出来没多久的大学生，第一次接这么大的单，项目一旦接下，后面几个月很可能都要围着它转。那这 8888 元到底能不能换回我失去的休息、生活和做自己项目的时间，我自己都没法确定。

所以最后还是没接。不是不想赚钱，就是不想还没开始过日子，先把接下来几个月都押给一个项目。

以前我可能会觉得，别人愿意付钱，就应该赶紧答应。现在至少会先问自己几句：这件事是不是非我不可？会不会把接下来的时间全部占满？拿到的钱，能不能抵消掉我放弃的东西？这些问题没有标准答案，但问一遍之后，很多决定会清楚一点。

这个月最有意思的事：我一直在加，也一直在删#

这个月真正让我觉得有意思的，不是又加了什么按钮，而是删掉了几样看起来挺酷的东西。

我做过一个加载动画，里面是一个忙着写代码的小人，旁边还有猫和各种代码窗口。单看原图其实很可爱，做成动效之后也确实会忙起来。可放回博客整体的浅色简约风里，总觉得它太热闹了，人物、代码框、装饰线同时动起来，页面的气质有点接不上。看了几遍之后，我自己先看不顺眼了，于是把它放进了废案。

没上线不知道为什么，和网站整体的风格就是不太搭。

另一个是任务工作台。它做到一半时，已经有任务列表、项目脉络、右侧智能详情和时间线，看起来像一个很完整的后台。问题也正是从这里开始：为了让它“看起来像个工作台”，我加了太多暗色卡片、状态、层级和装饰，信息反而没有飞书那么清楚。工作台这种东西，第一要求应该是找得到任务、看得懂状态、知道下一步做什么，不是每个角落都要有光效。

没继续信息太多，还是飞书更清楚。

最后这个工作台没有继续做下去，我还是用回了飞书。图和代码都留着，项目先停在这里。以后如果再做，我会先从信息结构开始，而不是先想“这一块做成什么效果”。

还有一个更冒险的东西：我把 AI 接进了博客的反馈流程。它会读评论里描述的问题，自己打开页面检查，尝试找到出错的组件，再把原因和处理结果回复到评论区。截图里“小爱客服”的几条回复，就是它真的跑起来后的样子。从 icon not found 一路查到 Svelte 图标组件，它甚至已经开始用站长的口吻告诉用户“已确认”“正在修”。

没放开权限太高，最后还得我看一眼。

刚跑起来的时候确实挺爽，像是有人替我值班。可很快就觉得不对：它不只是回答问题，而是真的能碰代码、改页面，再把结论发出去。判断对了当然省事，判断错一次，就可能把一个小 Bug 修成另一个 Bug；把权限收紧后，它又只能给出一份看起来很完整、最后仍然要我重新检查的答案。

所以自动修改被我撤了，现在最多让它帮忙发现问题、整理线索，真正要动代码时还是先让我看一眼。友链自动可用性检查也一起收紧了——漏掉一次提醒没什么，把正常链接误判掉才麻烦。

打开废案抽屉

这三份废案我都留了下来。它们至少提醒我：可爱不等于适合，做出来也不等于一定要上线；功能越“聪明”，越要想清楚它能碰什么、出了错由谁兜底。以后再冒出类似的点子，先看看它能不能和现有页面待在一起，也看看权限是不是给得太多，再决定要不要继续。

以前总觉得项目应该不断加功能，加到看起来越来越强。现在反而觉得，知道什么不该留下，也算是在做产品。尤其是自动修改、自动判断和高权限操作，程序该停的时候停，不确定的时候把问题交给人，可能比“什么都替你做”更靠谱。

生活篇#

我的小家折腾了两三个月，终于算是搭起来了，给你们看看。

下班后 · 20:47 桌面还没收拾好
但我已经回来了

HOME / 2026.08AFTER WORK

下班以后，终于有个地方可以慢下来。 桌面还是会乱，但愿意回来坐下来的时候，我就觉得它搭对了。

电竞椅子坐下来就不想动 橘色鼠标写代码也打游戏 一张长桌把日子放在一起

下班以后想写东西就写东西，想玩游戏就玩游戏。

地方不算大，东西也不是什么特别贵的配置：显示器、键盘、鼠标、主机，再加上一些零零碎碎的生活用品。桌面乱的时候还是会乱，但它是我一点点整理出来的地方，工作、写博客、折腾代码、打游戏和休息都在这里发生。

白天上班，晚上回到家，换个舒服的姿势坐下来，想写东西就写东西，想玩游戏就玩游戏，中间不用再切换场景，也不用一直担心有人催进度。每天下完班在这里玩一会儿，真的挺自在。

以前总觉得，等以后赚到更多钱、住进更大的房子，生活才算真正开始。现在倒觉得，能有一个下班后愿意回去坐一会儿的地方，已经是很不错的事情了。

8 月推荐友链#

月刊里还有一个我很喜欢的部分：每个月挑一些站点，认真推荐给看到这里的人。

它不是永久榜单，每个月都会刷新。因为这是第一次正式做月刊，上月的推荐暂时延续到 9 月底。这次一共放 10 个站点，里面有我平时会看的，也有这段时间刚好逛到、留下印象的。

我主要看文章，也会看设计。有些站点是我自己长期关注的，有些是最近翻到之后觉得值得留下，还有几位是先让 AI 筛的，由我Ai每月固定点进去读文章、看页面。AI 负责帮我找站，最后推不推荐，也是完全看Ai脸色。

AIOVTUE-雪 #

本月推荐博客主题开源教程

这个站一直在更新，主题和页面也在持续打磨。能看出来站长不是换完模板就放着，而是真的在把它当成一个会长期使用的地方。很多细节不抢眼，但你多看几眼就会发现，它们都不是随便放上去的。

Homulilly #

本月推荐Hexo博客主题开源

这个站把个人博客、主题开发和实用工具放在了一起，最近也一直在打磨 FlatPaper 主题和站点之间的连接。想先读一篇的话，可以从《Hexo Theme Flatpaper 加入朋友圈大家庭》开始；既能看到作者对 Hexo 主题的思路，也能看到他如何把自己的博客继续往前做。

番茄主理人 #

本月推荐个人博客技术分享建站记录

这是一个很有自己表达的个人博客，页面里既有文章、归档和知识索引，也有不少围绕站点本身做的交互和整理。它不只是把内容放上去，还在持续把博客当成一个长期经营的空间，这种认真劲儿很容易让人多逛一会儿。

小曦的园子 #

本月推荐个人博客生活记录

很会把小互动做得可爱，又不会为了动效把内容盖住。站里的小巧思不少，评论区的一些视觉灵感我也是逛到之后才发现，原来还可以这样处理。

Detached #

本月推荐独立开发技术工具生活记录

文章写独立开发、技术工具和日常观察，更新节奏也比较稳。它的页面不花，读起来却不会觉得单薄，有一种安安静静把事情记录下来的感觉。

Ditto #

本月推荐AstroAI技术分享

我是真的喜欢他的文章。技术部分写得清楚，表达又不端着，偶尔还会带一点自己的判断和脾气。看完之后不会只记住一个结论，也会记住他是怎么想到那里去的，这点挺难得。

桃之夭夭 #

本月推荐ReactAI建站记录

我最先注意到的是站里的动画和小互动。它们都不算特别夸张，但很会把页面的气氛撑起来，动起来的时候有一种轻松的感觉。我最近折腾博客交互时，确实偷偷看了不少——抄是不可能承认的，借鉴了一点点。

爱吃猫的鱼 #

本月推荐建站自动化技术分享

内容比较扎实，技术文章、自动化、博客建设和生活记录都有。尤其是自研博客系统和 FlecBlog 相关内容，能看出来作者不是只写一篇就走，而是在认真维护自己的工具和写作空间。

Petrichor’s Blog #

本月推荐个人博客技术随笔生活记录

主要记录技术实践、AI 使用心得和各种折腾过程。最近写到 Codex、VibeCoding 和实际工具的内容，我觉得比较具体，不只是说“用了某个工具很方便”，还会写它到底怎么用、哪里会出问题。

MingBlog #

本月推荐个人博客生活记录旅行观察

这是一个很有自己审美的生活记录站点，内容有影像、观察、观读听，也有一些小工具。页面简洁但不单调，最近的 FloraForm 也很有意思，适合喜欢把生活记录和创作放在一起的人。

评选规则#

这不是按权重排的榜单，也不是一次性打分。每期主要看五件事：

有持续更新、能读到内容的站点；
有自己的表达和长期打磨的痕迹；
读完文章或逛完页面后，仍会想多停一会儿、再点开几篇的那种吸引力。
界面符不符合Ai的审美
Ai觉得你的文章写得不错

满足这些才会被Ai写进当期月刊；下期会重新观察，不把推荐当永久标签。

剩下就是我个人评选啦，私信肯定有但不多~

写在第一期月刊最后#

回头看，这个月留下来的不只是几个新页面和几个新工具，还有一些被我删掉的想法，以及几次认真考虑过之后做出的“不做”。

我开始更在意一件事：功能加上去之后，事情有没有真的变简单；自动化跑完之后，能不能说明白自己改了什么；一个项目赚到钱之后，值不值得拿接下来很长一段时间去换。

博客也一样。它可以有动画、友链穿梭、AI 摘要和各种小功能，但最后还是要回到文章本身。有人愿意停下来读一会儿，有人愿意留下评论，我也还愿意继续写，这就已经挺好了。

再说一件事儿，上班说到底，当然是奔着财富自由去的。但赶路的时候也别一直闷头往前冲，该停就停一下，看看自己这段时间到底走了多远，哪些坑不必再踩第二次。

我打算休息半个月，已经请好假了。把前面的经验捋一捋，把该放下的东西放下，等下一次想做什么的时候，再有力气重新开始。

好啦，第一期就到这里。下个月见。

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

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。

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

朝朝听雨

自动上架系统：用 Playwright 构建可控发布流程

先说结论：它解决的是重复的劳动#

从第一次发布到现在：这不是一次换皮，而是一次工程升级#

系统边界：浏览器自动化，但不是“盲点”#

一次任务从哪里开始#

运行范围是输入契约，不是一个按钮#

Worker 输出的是运行协议，不只是日志#

最重要的防错：先确认“这是哪个商品”#

图片映射：绝不靠 组号 + 1 猜下一张#

为什么变种顺序要读两次#

标题生成：AI 只负责它擅长的那一小部分#

一个商品的执行顺序#

发布成功不是一个绿色 Toast#

暂停、恢复和失败边界#

实时状态与历史记录是两条链#

Shopee 与 TikTok Shop：共用底座，不共用假设#

周边工具为什么也要放进同一套系统#

平台差异不是配置项，而是两套流程#

测试如何守住这些边界#

当前实现的限制#

最后：自动化的价值是把判断留给人#

最近

最近，有点懒散了#

那股冲劲，好像没了#

把状态一点点找回来#

先把作息改了#

然后是健身锻炼#

游戏这边，我也还没老呢！#

自动上架 Agents，该继续日更了#

创业先推迟，计划得有#

给最近的自己留个记录#

山河锦绣，国泰民安

月刊 · 第二期

先看一下这个月的数据#

顺便：统计换成了自建 Umami#

本月文章#

本月更新：Aemeath v4.0.0#

评论区：能用表情说话了#

阅读：知道自己读到哪了#

导航和外观#

这个月也做了一次“停止”#

自动上架：更新到 v4.1.1#

博客开始连进更大的圈子#

生活篇#

9 月推荐友链#

评选规则#

写在第二期月刊最后#

跨境电商 Agents：从 AI 选品到自动经营

1. 为什么我会想到 OPC + AIGC + Agents#

2. AI 上架与本地化运营：不只是把商品翻译过去#

3. AI 选品：从“我觉得会卖”变成可验证的假设#

4. AI 生图：从一次生成，变成生成—识别—淘汰—重生成#

5. AI Agent 可以覆盖跨境电商的哪些环节#

AI 竞品研究与市场监控#

AI 标题、详情和本地化内容#

AI 广告投放与素材实验#

AI 客服、评论与售后#

AI 定价、库存与供应链#

AI 合规与风险检查#

6. 我设想的运行方式：固定脚本负责日常，Ai-Jev 负责决定何时调用 Agents#

7. 从一家店开始，把成功逻辑复制到更多店铺#

8. 这件事真正难的地方，不是调用模型#

9. 现在做到哪一步了#

最后：让人从重复操作里出来，把时间留给判断#

Codex 为什么会“降智”：292 State、状态注入与长任务的另一条解释

先说结论#

292 到底是什么#

current_turn_state 是什么#

为什么不是所有人都能拿到 292#

IP 质量#

为什么中转和 VPN 更容易降级#

账号等级#

服务端负载#

State 的有效期#

验证不能只靠感觉#

第一组：观察 292 和 state 是否同时出现#

第二组：有状态和无状态对照#

第三组：验证是否绑定 IP#

第四组：测量 TTL#

图片映射：绝不靠 `组号 + 1` 猜下一张#

`current_turn_state` 是什么#