mcpbeat

���发 ���瓣

lornshrimp/分发-豆瓣

用于将"豆瓣/"目录内指定章节批量上传到豆瓣阅读作者后台并保存为草稿。支持按 README.md 读取账号、密码、豆瓣书籍ID、书名与卷名校验,自动执行登录、章节信息填写、正文粘贴、作者的话添加与存草稿循环。关键词:豆瓣上传、保存草稿、批量传章、豆瓣作者后台、作者的话。

8k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
148
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/lornshrimp/Lorn.NovelWriteSkills --skill 分发-豆瓣

The instruction itself

29 sections, as written by the author

<!-- ===== Layer 1: 永久缓存 ===== -->

上传指定章节小说到豆瓣阅读并保存为草稿

用于把你指定的 1 章或多章,上传到豆瓣阅读对应作品下,并全部保存为草稿。

<!-- ===== Layer 3: 场景缓存 ===== -->

工作目录路由规则(强制)

本 Skill 执行前,必须按以下规则确定工作目录:

  • 读取项目根目录 Agents.md,检查其中 主输出平台 声明
  • 若当前平台(豆瓣)匹配 主输出平台 → 工作目录为 小说正文/
  • 若当前平台不匹配 主输出平台,或 Agents.md 不存在/未声明 主输出平台 → 工作目录为 豆瓣/

后续所有章节文件路径、README.md、分发记录.md 均基于此工作目录。明确说明

  • 本平台是主输出平台时 → 章节文件、README.md分发记录.md 均在 小说正文/
  • 本平台不是主输出平台时 → 章节文件、README.md分发记录.md 均在 豆瓣/

> 路径说明:以下各节中所有 豆瓣/ 形式的路经(如 豆瓣/README.md豆瓣/分发记录.md)均为工作目录的示例写法。实际目录由上方「工作目录路由规则」确定:本平台是主输出平台时,所有这些路径对应 小说正文/;不是主输出平台时,对应 豆瓣/

何时使用

  • 你已经把待上传章节放入 豆瓣/ 目录。
  • 你已经在 豆瓣/README.md 写好账号、密码、豆瓣书籍 ID、书名、卷名信息。
  • 你希望按固定流程自动完成:登录 → 填章号与章名 → 粘贴正文 → 添加作者的话 → 存草稿。

不适用情形

  • 你只想做文本润色,不需要打开网站上传。
  • 你没有提供豆瓣账号或书籍 ID。
  • 目标不是"保存草稿",而是"立即发布"。

输入前置要求(强制)

> 建议按“章节文件 → 平台配置 → 分发记录 → 书名 / 书籍Id判定 → 缺失模板”顺序完成预检,再进入网页操作。

一、本地输入与基础来源

1) 章节文件目录
  • 待上传文件必须放在 豆瓣/ 下。
  • 你会明确指定要上传哪些章节(可单章,可多章)。
  • 章节标题不以文件名为准,必须从章节文件正文中提取。
1.1) 章节标题提取规则(强制)
  • 章节标题来源于章节文件内容,通常是第 1 行的 Markdown 标题行(以 # 开头)。
  • 该标题行有时会带章节编号,有时只有标题文本;两种都合法。
  • 若章节文件标题行为 # 1.1.3 三分钟,其中 1.1.3 表示 部号.卷号.章号;提取时必须只取最后一段 3 作为“章号”,三分钟 作为“章节标题”。
  • 豆瓣是分卷平台,上传时只使用卷内章号,不得把 1.1.32.4.17 这类三级编号原样写入标题输入框;最终只能写成 第3章 三分钟 一类格式。
  • 豆瓣要求章节号与标题合并在一个输入框,格式为 第X章 标题文本(章号与标题之间必须保留一个空格)。
2) 元数据来源
  • 必须读取 豆瓣/README.md,至少提取以下信息:
  • 豆瓣用户名
  • 豆瓣密码
  • 小说豆瓣书籍 ID(纯数字,如 11997642;按“书籍Id判定规则”选取当前章节对应值)
  • 小说名称(小说书名,用于当前上传目标)
  • 每一卷卷名
2.1) 平台校验(强制)

读取 豆瓣/README.md 后,必须检查其第一行一级标题是否等于 # 豆瓣阅读分发配置

  • 匹配 → 继续执行后续流程
  • 不匹配 → 立即停止上传,并向用户报错:README.md 平台标识与当前 Skill 不符:预期"豆瓣阅读分发配置",实际读取到"{实际读取到的标题}"。请检查是否将其他平台的 README.md 误放到了当前工作目录。
3) 分发记录来源(强制)
  • 必须读取 豆瓣/分发记录.md
  • 若文件不存在,先创建后再执行分发。
  • 用于查询"章节 -> 章节Id"映射,判定该章是"新建模式"还是"修改模式"。

二、书名 / 书籍Id 判定

4) 书名判定规则(强制)
  • 若小说无分部:小说书名使用该平台目录 README.md 中的“小说名称(小说书名)”。
  • 若小说有分部(多部):小说书名使用该章节所在分部的分部名,不得误用总书名。
4.1) 书籍Id判定规则(强制)
  • 若小说无分部:书籍Id使用该平台目录 README.md 中与“小说名称(小说书名)”成对维护的书籍Id。
  • 若小说有分部(多部):书籍Id使用该章节所在分部名对应成对维护的书籍Id。
  • 禁止把总书名对应书籍Id用于分部章节,或把分部书籍Id用于非对应分部章节。

三、首次缺失文件时的模板

5) 分发记录.md 模板(首次创建直接使用)

豆瓣/分发记录.md 不存在时,必须按以下模板创建:

# 豆瓣阅读分发记录

> 用途:记录"章节唯一键 -> 豆瓣章节Id"映射,供分发流程判断"新建模式/修改模式"。

## 字段说明

- `章节唯一键`:固定格式 `豆瓣书籍ID|分部名|卷号|章号|章名`(无分部时分部名填 `NA`)
- `豆瓣书籍ID`:对应 `豆瓣/README.md` 中书籍ID
- `章节Id`:豆瓣章节页 URL 中的数字段
- `最近操作`:`新建` 或 `修改`
- `更新时间`:`YYYY-MM-DD HH:mm:ss`
- `备注`:可选

## 记录表

|章节唯一键|豆瓣书籍ID|章节Id|最近操作|更新时间|备注|
|:--|--:|--:|:--|:--|:--|
6) README.md 模板(首次创建直接使用)

豆瓣/README.md 不存在时,必须按以下模板创建:

# 豆瓣阅读分发配置

> 用途:存储豆瓣账号、书籍信息与卷名映射。分发流程将读取此文件。

## 账号信息

- 用户名:`your_username`
- 密码:`your_password`

## 书籍信息

### 无分部小说

| 小说名称 | 书籍ID |
|:--|--:|
| 作品名 | 11997642 |

### 有分部小说

| 分部号 | 分部名 | 书籍ID | 卷数 |
|:--|:--|--:|--:|
| 第1部 | 分部一书名 | 11997642 | 3 |
| 第2部 | 分部二书名 | 11997643 | 2 |

## 卷名映射

### 分部一书名

| 卷号 | 卷名 |
|--:|:--|
| 1 | 第一卷 卷标题 |
| 2 | 第二卷 卷标题 |
| 3 | 第三卷 卷标题 |

### 分部二书名

| 卷号 | 卷名 |
|--:|:--|
| 1 | 第一卷 卷标题 |
| 2 | 第二卷 卷标题 |

## 字段说明

- `小说名称` / `分部名`:必须精确匹配 SKILL 中的"书名判定规则"
- `分部号`:必须使用 `第N部` 规范格式(如 `第1部`、`第2部`),并与 `分部名` 一一对应,不得错位或复用
- `书籍ID`:纯数字
- `卷名`:豆瓣平台上该卷的显示名称

## 安全提醒

- 本文件包含明文密码,请妥善保管。
- 本文件应存入 `.gitignore`,不提交到公开仓库。

执行流程(强制按序)

> 建议按“读取本地输入与模式判定 → 登录后台 → 新建 / 修改分流 → 填标题 / 正文 / 作者的话 → 保存并回写 → 多章循环”的顺序执行。

零、执行前自检(强制,每次分发对话必做)

> 以下自检用于防止"凭印象执行"导致偏离已有 SOP。任何页面异常、工具选择、流程分叉,先查本文对应小节再动手。

  • 工具选择:涉及数据通道(批量传正文/作者的话)时,先查阅 六.1.F 数据通道提效,确认已有 scripts/content_parts_server.mjs 是否覆盖当前需求;禁止在已有工具可覆盖的情况下新建临时脚本
  • 弹窗判定:编辑页出现浮层/弹窗时,先对照 实操经验沉淀一:工具栏教学浮层 vs 真实安全验证 做判断,再决定是否暂停;禁止不查文档直接判定为安全验证
  • 限流/失败判定:遇到"你发得太快"或保存异常时,先查 实操经验沉淀二 和 实操经验沉淀三 对应小节,按已有策略处理。
  • 登录异常:出现验证码/滑块/风控提示时,必须立即暂停并等待用户手动完成;在收到"登录完成"反馈前不得继续。

一、读取本地输入与模式判定

  • 读取并解析 豆瓣/README.md
  • 确认已获得:账号、密码、目标书籍Id(按“书籍Id判定规则”选取)、目标小说名、目标卷名。
  • 读取 豆瓣/分发记录.md,建立"章节唯一键 -> 章节Id"映射(建议唯一键:豆瓣书籍ID|分部名|卷号|章号|章名;无分部时分部名固定为NA)。
  • 读取你指定的章节文件,提取每章:卷号、卷名、章节号(阿拉伯数字)、章节标题、正文、作者的话。
  • 其中章节标题必须按"章节标题提取规则(强制)"从文件内容提取,不得用文件名替代。

二、登录并进入作者后台

  • 必须新开一个浏览器标签页,并在该新标签页访问:
  • https://read.douban.com/submit/agent
  • 该新标签页仅用于本次豆瓣上传流程,不复用你当前正在进行其他任务的标签页。
  • 若出现未登录状态:
  • 页面默认显示"手机号验证码登录"界面
  • 必须点击"豆瓣登录"链接
  • 页面跳转后,在右上角找到并点击"短信登录/注册"
  • 然后切换到"密码登录"选项卡
  • 使用 README.md 中的用户名和密码进行登录
  • 若密码登录后页面提示"为保证账号安全,请使用验证码"或同类提示:
  • 必须立即暂停流程,等待用户手动完成验证并明确反馈“登录完成”
  • 在收到“登录完成”反馈前,不得继续任何后续步骤、不得伪造成功态

三、进入目标书籍章节页(新建 / 修改分流)

  • 在访问前,先查询 豆瓣/分发记录.md 中该章节是否已有 章节Id
  • 若该章节 没有 章节Id(新建模式),访问:
  • https://read.douban.com/article_v2/chapter/create?column_id={豆瓣书籍ID}
  • 页面加载后,URL 会自动重定向到 https://read.douban.com/article_v2/chapter/{章节Id}/
  • 从重定向后的 URL 提取 {章节Id} 部分(两个斜杠之间的纯数字)
  • 若该章节 已有 章节Id(修改模式),访问:
  • https://read.douban.com/article_v2/chapter/{章节Id}
  • {豆瓣书籍ID} 必须来自 README.md,且是数字串。
  • 豆瓣编辑界面不显示书籍信息与卷名,无法在页面做书籍校验;书籍ID的正确性仅通过 URL 中的 column_id 或 URL 路径本身来确认,请在步骤 2 前确认 README.md 中书籍ID无误。

四、编辑章节内容

4) 填写章节标题区

豆瓣要求在单一输入框中输入"章节编号 + 空格 + 章节标题"。

  • 获取该章的阿拉伯数字章节号(如 1)。
  • 获取该章的章节标题(来源于文件内容,通常为第1行 # 标题行),不得使用文件名。
  • 按格式 第X章 标题文本 组合填入标题输入框:
  • 示例:第1章 天降奇缘
  • 章号与标题之间必须保留一个空格
  • 确保格式正确后提交。
5) 填写正文
  • 在正文文本框输入该章节正文。
  • 必须确保正文来自你指定的章节文件,不得错章串章。
6) 添加作者的话
  • 在页面右上方找到"工具"按钮或菜单。
  • 点击其中的"作者的话"选项。
  • 点击后会在页面右上角弹出一个浮层输入框。
  • 在弹出的输入框中先全选清空旧内容,再输入该章"作者的话"内容,避免与历史文本拼接。
  • 输入后必须检查计数器(若页面显示字数限制):
  • 若超限,按"保钩子优先"压缩到平台限制内再保存。
  • 若未超限,保持原文语义。
  • 点击弹出浮层中的"确定"按钮,确认作者的话已落盘。

五、保存章节并回写记录

  • 点击页面上的"保存"按钮。
  • 等待页面反馈已保存成功(或等价成功提示)。
  • 保存成功后,从当前 URL 提取 章节Id(若为新建模式,这时 URL 应为 https://read.douban.com/article_v2/chapter/{章节Id}/)。
  • 将"章节唯一键 + 章节Id + 更新时间"写回 豆瓣/分发记录.md
  • 若记录不存在:新增一条。
  • 若记录已存在:仅更新 章节Id(如变化)和更新时间。
  • 注意 Markdown 表格转义章节唯一键内部包含 | 时,写入表格必须转义为 \|,否则会破坏表格列数并导致记录不可解析。

> 章节唯一键生成规则(强制):

> - 使用字段顺序:豆瓣书籍ID|分部名|卷号|章号|章名

> - 其中:

> - 豆瓣书籍ID 来自 README.md

> - 分部名 使用当前分部书名;无分部填 NA

> - 卷号章号 必须是阿拉伯数字

> - 该规则用于彻底避免多部小说下"同卷同章号"冲突。

六、多章循环

  • 对每个指定章节,严格重复步骤 3~7,直到全部章节完成。
  • 每章开始前都必须先查一次 分发记录.md 决定新建/修改模式,不得沿用上一章模式。

六.1 连续多章提效模式(推荐)

> 目标:在不放松现有强制规则的前提下,减少重复点击、重复粘贴与重复判定成本。

A. 先批量预处理,再进入浏览器连续执行
  • 在打开网页前,一次性完成以下预处理:
  • 章节号 / 章节标题提取;
  • 正文与作者的话拆分;
  • 作者的话超限预检(>300 先压缩);
  • 新建 / 修改模式预判(来自 分发记录.md)。
  • 产物建议统一放入临时队列(如内存对象或 豆瓣/.cache/content_parts/no_part/v{卷号}/*.txt豆瓣/.cache/content_parts/p{分部号}/v{卷号}/*.txt + 映射表),浏览器阶段只做“取数据→填写→保存”。
B. 浏览器阶段采用“固定入口 + 重复节拍”
  • 对于每一章,保持统一节拍:

1) 打开目标地址(新建 create?column_id= 或修改 chapter/{id});

2) 填标题(第X章 标题);

3) 填正文;

4) 填作者的话;

5) 保存;

6) 提取章节Id;

7) 回写记录。

  • 除“目标地址”和“填入文本”外,其余动作应尽量保持同一套定位器与顺序,避免每章临时切换策略。
C. 用“小批次提交”替代“整批一次性提交”
  • 推荐按 5–10 章为一个小批次执行:
  • 每个小批次完成后立刻回写 分发记录.md
  • 再进入下一个小批次。
  • 这样即使遇到限流、登录态波动或页面改版,也只影响当前小批次,不会让整批进度回滚。

> D / E / F 三节统一执行口径:优先保证批次连续性与可回滚性;安全验证类提示一律按阻断处理;数据通道异常必须可降级。

D. 对“高频弹窗”做一次性消噪
  • 保存阶段若出现字数提醒:
  • 首次勾选“不再提醒”并点击“我知道了”;
  • 后续章节通常可减少同类干扰。
  • 编辑页若出现“切换工具栏模式”教学浮层:按非阻塞元素处理,不中断主流程。
E. 失败分层:快跳过、可续跑
  • 对单章失败采用“记录原因并继续下一章”的策略(除非用户要求遇错即停)。
  • 失败章需记录最小必要信息:
  • 章节唯一键;
  • 失败步骤(打开页 / 标题 / 正文 / 作者话 / 保存 / 回写);
  • 页面关键提示。
  • 批量结束后按失败清单单独补传,避免在主循环里反复卡住。
F. 数据通道提效(可选)
  • 长批量自动化场景可选用 scripts/content_parts_server.mjs(通用 content parts 服务):
  • 让浏览器通过 scoped 接口读取标题/正文/作者话:
  • 无分部:/parts/v/{卷号}/{章号}
  • 有分部:/parts/p/{分部号}/v/{卷号}/{章号}
  • 平铺 /parts/{章号} 仅限单批次临时使用;
  • 减少在聊天或脚本中反复搬运长正文。
  • 该方式是提效手段,不替代本 Skill 的书籍Id判定、章节唯一键、回写规则与失败处理要求。
G. 批量执行防误用补丁(建议默认开启)
  • “新建 / 修改模式预判”仅用于提效,不得替代每章执行前对 分发记录.md 的实时查询。
  • “高频弹窗消噪”仅限非安全类提示;涉及登录风控、验证码、实名校验、账号安全提示时,一律按阻断处理并暂停。
  • 失败分层需加入“致命错误即停”:书名/卷名(或作品)不匹配、书籍ID错误、登录态异常未解除时,不得继续下一章。
  • 使用数据通道(如 content_parts_server)时必须提供降级路径:服务不可用时自动回退到本地文件读取,不中断批次执行。
  • 每个小批次结束必须执行对账复核:计划章数 = 成功章数 + 失败章数,且成功章均完成 章节Id 回写。

关键边界与硬规则

> 下面这些是执行时不能放松的护栏;若与页面临时表现冲突,以这里的规则和下方“实操经验沉淀”为准复核。

一、范围与分流规则

  • 必须只上传用户明确指定的章节,不得擅自扩展范围。
  • 每章进入步骤 3 前,必须先查询 豆瓣/分发记录.md
  • 每章进入步骤 3 前,必须确认 README.md 中的豆瓣书籍 ID 正确无误(豆瓣编辑界面无法在页面校验书籍信息)。
  • create?column_id={书籍ID}chapter/{章节Id} 两种地址必须按记录自动分流,禁止混用。

二、登录与页面使用

  • 步骤 2 必须使用新标签页进入作者后台,禁止占用用户正在使用的原标签页。
  • 登录流程必须按"手机号验证码 → 豆瓣登录 → 短信登录/注册 → 密码登录"的顺序执行。
  • 账号密码仅用于当次登录,不写入产物文件、不外泄。

三、标题、正文与作者的话

  • 章节标题必须来自章节文件内容(通常第1行 # 标题行),不得以文件名充当标题。
  • 章节标题输入格式必须为 第X章 标题文本(章号与标题之间必须保留一个空格),不得遗漏空格。
  • 章节号必须是阿拉伯数字,不得写中文数字。
  • 豆瓣是分卷平台,章节号必须使用所在卷内的相对章节号,不做跨卷累加。
  • "作者的话"必须通过"工具 → 作者的话 → 在弹出浮层中输入 → 确定"路径录入。
  • 作者的话录入前必须先清空编辑框,再粘贴本章文本。
  • 作者的话必须满足平台字数限制后再确定。

四、保存与记录

  • 每章"保存"成功后,必须把最新 章节Id 回写到 豆瓣/分发记录.md
  • 最终动作是"保存",保存后即为草稿状态。

失败与回退处理

  • 登录失败:提示账号/密码错误并停止,不继续后续章节。
  • 密码登录被拦截为验证码登录:必须立即暂停流程,等待用户手动完成验证并明确反馈“登录完成”;在收到该反馈前不得继续任何后续步骤。
  • 编辑页出现二次安全验证(拼图/滑块):必须立即暂停流程,等待用户手动完成验证并明确反馈“登录完成”;在收到该反馈前不得继续任何后续步骤。
  • 页面元素缺失(如按钮改版):记录当前失败步骤并停止本章,继续尝试下一章前需先确认页面可操作。
  • 保存失败:本章标记失败,重试后仍失败则保留失败记录并继续下一章(除非用户要求遇错即停)。
  • 作者的话保存失败:本章先不保存,重试"编辑作者的话 → 确定 → 保存"链路;仍失败则记录原因并继续下一章(除非用户要求遇错即停)。
  • 分发记录.md 写入失败:本章虽然可能已保存,但流程状态必须标记为"部分失败(记录未落盘)",并立即提示人工补录,禁止静默成功。

实操经验沉淀(基于真实上传)

> 建议按“编辑页识别 → 页面反馈 → 长批量策略 → 自动化辅助件”的顺序阅读:前两类偏单章操作稳定性,后两类偏长批量连续分发。

一、编辑页识别与误判排除

【重点】如何精准识别标题与正文输入框
  • 【2026-05-20 用户明确补充(最高优先级)】
  • 标题输入位置:textarea(位于 h1.title 下),placeholder 为“标题”。
  • 正文输入位置:div.public-DraftStyleDefault-block.public-DraftStyleDefault-ltr(Draft 编辑区块,位于 DraftEditor-root 下)。
  • 执行时必须先写 textarea(标题),再写 Draft div(正文);禁止反向填写。
  • 豆瓣编辑器主编辑区分为上下两部分,以 placeholder 为唯一锚点
  • 上半部分输入框用于填写标题,placeholder 明确为“标题”。
  • 下半部分输入框用于填写正文,placeholder 明确为“写点什么吧”。
  • 标题输入框为单行,正文输入框为多行,且支持格式化工具栏。
  • 自动化/人工操作时,务必以 placeholder 为准,优先定位“标题”输入框填写章节标题,再定位“写点什么吧”输入框填写正文。
  • 任何页面变动时,优先核查 placeholder 内容,必要时更新自动化脚本的定位逻辑。
  • 常见误区:
  • 不要将正文内容误填到标题输入框(会导致整章内容只显示标题,正文为空)。
  • 不要将标题内容误填到正文输入框(会导致章节无标题,影响目录与展示)。
  • 自动化/人工操作时,务必先定位标题输入框(页面顶部、单行),再定位正文输入框(大块编辑区),每次粘贴前都要确认焦点位置
  • 建议:
  • 自动化脚本应通过 placeholder、input 标签顺序或 class/id 精确定位。
  • 人工操作时,先点击标题输入框,输入标题,回车或 Tab 切换到正文输入框,再粘贴正文。
  • 粘贴后可用“撤销/重做”功能确认内容落在正确区域。

如遇页面结构调整,优先人工核查输入框顺序和 placeholder,必要时更新自动化定位逻辑。

【2026-05-20 实跑修正】如何区分工具栏教学浮层与真实安全验证
  • 编辑页底部可能出现“切换工具栏模式”的全宽教学浮层;这不是拼图/滑块验证,不会阻塞正文输入、右上角菜单或保存操作。
  • 识别要点:
  • 浮层位于页面底部,标题明确为“切换工具栏模式”。
  • 浮层内会出现工具栏模式说明、左右翻页箭头与右下角关闭 X
  • 页面顶部“保存 / 发表 / 菜单”与正文区仍可正常点击、输入与保存。
  • 处理方式:
  • 可直接忽略该浮层,继续填写正文、作者的话并保存。
  • 若担心遮挡,可先点击右下角 X 关闭,再继续流程。
  • 只有当页面实际出现不可绕过的验证码交互,且阻断正文区、菜单或保存按钮操作时,才按“二次安全验证”暂停;不要把教学浮层误判为安全验证。
  • 若辅助快照里出现“安全验证 / 拖动下方拼图完成验证”等字样,但可视页面实际显示的是工具栏教学浮层,应以可视界面与实际可交互性为准复核,再决定是否暂停。

二、创建与保存阶段的页面反馈

【2026-05-20 实跑修正】创建页出现“你发得太快”如何处理
  • 若访问 https://read.douban.com/article_v2/chapter/create?column_id={书籍ID} 后,页面正文区域没有出现编辑器,而是显示“你发得太快,读者看不过来啦,请明天再继续”,应判定为平台当日发稿限流。
  • 这不是登录失效、验证码,也不是输入框定位错误;继续刷新或反复重试通常无效。
  • 识别要点:
  • 页面标题通常仍是“创建文章 | 豆瓣阅读”;
  • 页面正文会直接出现“你发得太快,读者看不过来啦,请明天再继续”和“返回作者中心”;
  • 原本应出现的标题输入框 textarea[placeholder="标题"] 不会渲染出来。
  • 正确处理方式:
  • 立即停止后续“新建章节”尝试;
  • 先把当日已经保存成功的章节Id回写到 豆瓣/分发记录.md
  • 将剩余未上传章节标记为“因平台限流延期”,待次日继续。
  • 若需要继续补传,次日应从 分发记录.md 中未写入 章节Id 的第一章继续,而不是从头重跑整批。
  • 本轮实跑中,已连续完成到第21章后,在尝试新建第22章时命中该限流;说明长批量任务不要默认可以在单日无限连续新建。
【2026-05-20 实跑修正】保存时出现字数提醒如何处理
  • 点击“保存”时,页面可能弹出字数提醒;这不是保存失败,也不是安全验证。
  • 正确处理顺序:
  • 先勾选“不再提醒”;
  • 再点击“我知道了”。
  • 这样可关闭后续重复弹出的同类提醒,减少每章保存时的额外交互,提高批量上传效率。
  • 若本次未勾选“不再提醒”,后续章节保存时仍可能反复弹出同类提示,影响连续分发节奏。

三、长批量分发策略

【2026-05-20 实跑修正】长批量分发前先做“作者的话”超限预检
  • 长批量上传时,不要等到打开“作者的话”弹层后才发现字数超限;那会打断节奏,也容易在连续操作里改乱文案。
  • 推荐做法:
  • 在正式上传前,先对目标章范围的“作者的话”批量统计长度;
  • >300 的章节集中压缩,再进入浏览器批量填写。
  • 本轮 第3–40章 预检中,超限章为:第12章第24章第26章第28章
  • 若当前流程使用 豆瓣/.cache/content_parts/no_part/v{卷号}/*.txt豆瓣/.cache/content_parts/p{分部号}/v{卷号}/*.txt 作为自动化输入缓存,可优先批量检查 *_author.txt;若未使用缓存,则仍以原章节文件中的“作者的话”为准。
【2026-05-20 实跑修正】长批量上传必须分段回写 分发记录.md
  • 不要等整批全部完成后再一次性回写 豆瓣/分发记录.md
  • 推荐策略:每成功完成 5–10 章,就立刻把这一小批的 章节唯一键 -> 章节Id 映射写回记录表。
  • 这样做的好处:
  • 若中途遇到平台限流、浏览器状态异常、页面改版或人工打断,已完成章节不会丢失 章节Id
  • 次日续跑时,可直接从 分发记录.md 中尚未写入 章节Id 的第一章继续;
  • 可避免“网页已保存成功,但本地记录未落盘”的隐性断档。
  • 本轮实跑中,正是因为先分段回写了 第3–7章、再回写 第8–21章,才在第22章触发限流后仍能保持本地状态完整。

四、自动化辅助件(可选)

【2026-05-20 实跑修正】scripts/content_parts_server.mjs(通用 content parts 服务)的定位与用法
  • scripts/content_parts_server.mjs 是一个自动化辅助脚本,用于把平台目录下 .cache/content_parts/ 中按章拆分好的标题、正文、作者的话,暴露为本地 JSON 接口,供浏览器自动化流程读取。
  • 它的定位是:辅助批量自动化上传,不是人工上传的必需步骤。
  • 适用场景:
  • 需要连续批量上传多章;
  • 不希望在聊天或自动化脚本里反复搬运整章正文;
  • 已经确认 豆瓣/.cache/content_parts/ 中的内容与当前待上传章节保持同步。
  • 不适用场景:
  • 纯人工上传;
  • 豆瓣/.cache/content_parts/ 还是旧缓存、尚未反映最新章节改动;
  • 无法确认拆分文本是否与 豆瓣/ 下目标章节文件一致。
  • 使用边界:
  • 该脚本只负责提供正文数据通道,不替代本 Skill 的强制规则;
  • 章节标题、章号、书籍ID、卷号、回写记录等判断,仍必须按 README.md分发记录.md 与目标章节文件的正式规则执行;
  • 若源章节刚修改过,应先重新同步 豆瓣/.cache/content_parts/,否则应直接读取章节文件,不要盲信缓存。
  • 接口约定:
  • 健康检查:/health
  • 章节数据(推荐,无分部小说):/parts/v/{卷号}/{章号}
  • 章节数据(推荐,有分部小说):/parts/p/{分部号}/v/{卷号}/{章号}
  • 章节数据(可选平铺,仅单批次):/parts/{章号}
  • 返回字段:chapterNotitlebodyauthor
  • 端口说明:
  • 默认使用 8765
  • 若端口被占用,可通过环境变量 CONTENT_PARTS_PORT 切换到其他端口。
  • 缓存子路径 .cache/content_parts 在脚本中已写死,默认读取 小说正文/.cache/content_parts
  • 豆瓣分发场景请显式设置:DISTRIBUTION_PLATFORM_DIR=豆瓣(脚本会自动拼接到 豆瓣/.cache/content_parts)。
  • 若要复用于其他平台,可通过环境变量 DISTRIBUTION_PLATFORM_DIR 切换平台目录(如 番茄小说),脚本会自动拼接到 {平台目录}/.cache/content_parts
  • 实跑结论:
  • 在本轮 21 章批量分发中,该脚本显著降低了浏览器自动化反复搬运长正文的成本;
  • 因此建议把它作为“长批量自动化上传”的可选辅助件写入本 Skill,但明确标注为可选而非强依赖
【目录职责约定】scripts/ 与数据缓存目录的边界
  • scripts/ 目录只用于存放可复用脚本本体(如 content_parts_server.mjs),不建议放置每轮分发生成的临时章节数据。
  • 分发过程中的章节拆分缓存、临时映射与中间产物,建议统一放在 豆瓣/ 目录下的专用临时子目录(如 豆瓣/.cache/content_parts/)。
  • content parts 服务固定使用 .cache/content_parts 作为缓存子路径;仅在跨平台复用时通过 DISTRIBUTION_PLATFORM_DIR 切换平台目录。
  • 为避免“不同分部/不同卷同章号”冲突,优先使用带分部/卷号的 scoped 接口路径,不建议长期依赖平铺 /parts/{章号}

本次实跑教训(2026-05-10)

  • 豆瓣/分发记录.md 首次不存在时必须先创建模板再执行,否则新建/修改分流失效。
  • 章节唯一键写入 Markdown 表格时必须使用转义竖线(\|);不转义会触发表格列错位(典型报错:Expected 6 columns, Actual 10)。
  • 编辑页可能出现二次安全验证弹层(即使已登录);这是硬阻塞点,需用户协助完成后再继续自动化。
  • 本次第1章新建后实际章节链接为:https://read.douban.com/article_v2/chapter/732782163/,验证了"create -> 重定向 -> 提取章节Id -> 回写记录"链路可用。

完成检查清单

  • 已读取 豆瓣/README.md 并提取必需字段。
  • 已按指定章节列表逐章执行上传。
  • 已在每章执行前查询 豆瓣/分发记录.md 并正确选择新建/修改 URL。
  • 每章均完成:章号+章名、正文、作者的话、保存。
  • 每章均已记录或更新到 豆瓣/分发记录.md(含章节与章节Id映射)。
  • 已输出每章结果(成功/失败及原因)。

How to use it

Copy the folder

Take lornshrimp/分发-豆瓣 from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.