rogee/creator-hub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
fa7b78797dfae93e00a44d25b2e586dbd8fdef14
creator-hub/docs/research/xhs-all-in-one.md
T

390 lines
28 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# `XHS_ALL_IN_ONE` 小红书能力吸收与落地研究
> 研究日期：2026-09-14
> 上游仓库：<https://github.com/cv-cat/XHS_ALL_IN_ONE>
> 研究快照：`e86f82b`（`master`）
> 研究方式：只读检查源码、提交历史与公开 Issues；未向小红书真实账号发起请求，以下不等同于平台能力验收。
> 当前结论：本文形成小红书实现约束；main 已接入受限只读适配器，但未复制上游代码、签名脚本、Cookie 或指纹数据。
## 1. 结论先行
这个仓库最值得 CreatorHub 吸收的不是它的逆向接口代码，而是它暴露出来的**平台适配边界、请求状态分类、数据标准化和失败场景**。
| 判断 | 结论 |
| --- | --- |
| 能否直接作为 CreatorHub 的小红书 SDK | **不能**。它依赖 Web 私有接口、动态签名、设备/浏览器状态和服务端下发程序，且公开 Issues 持续出现 406、461、登录失败和账号封禁反馈。 |
| 能否吸收工程做法 | **可以**。重点吸收适配器分层、原始响应保留、`xsec_token/xsec_source` 端到端保留、评论父子关系、媒体处理分步状态和登录态健康检查。 |
| 能否直接复制签名/指纹/`curl_cffi` 方案 | **暂不可以**。这属于高维护、强平台耦合和潜在合规风险路径；先取得真实平台能力证据，再决定是否需要平台专用实现。 |
| 能否证明小红书已经支持 CreatorHub 要求的事件监听 | **不能**。上游主要是主动请求式读取和发布，没有解决“自有账号互动/私信事件监听、断连恢复、稳定事件 ID”的问题。 |
| 能否直接复制上游代码 | **当前不能确认**。README 声称 MIT，但 GitHub API 的 `license` 为 `null`，研究快照中也没有可读的 `LICENSE` 文件；在许可证和逆向产物来源确认前不复制代码。 |
**推荐落地顺序：**先做小红书只读能力和证据链，再做素材处理；写操作和事件监听分别独立验收，不能因为上游有发布接口就宣称 CreatorHub 已具备发布或自动响应能力。
## 1.1 当前实现边界
- CreatorHub 当前已接入小红书只读 collector、详情/搜索/作品/一级评论读取、分享链接解析、原始 payload 保存、受限 gateway 路由和控制面平台分派；写操作与事件监听仍未接入。
- 小红书竞品主页输入会校验稳定账号标识并保留主页中的 `xsec_token/xsec_source`；作品详情可通过受限浏览器解析官方分享短链。
- `internal/creator/collection.go` 的分页、窗口、checkpoint 和 lease 模型可作为后续适配的复用边界，但不能证明小红书平台能力。
**未完成的真实能力验收：**私有接口签名是否能由浏览器当前会话完成、真实 UID/作品/评论分页、媒体下载、写操作和事件监听仍需真实小红书环境分别验证。HTTP 200、离线 fixture 和本地单元测试不能替代这些证据。
## 2. 上游实际做了什么
### 2.1 已能从源码确认的能力
| 能力 | 上游实现 | 对 CreatorHub 的价值 | 证据 |
| --- | --- | --- | --- |
| PC 端搜索笔记 | 组装搜索请求、分页参数、排序和筛选，使用 `/api/sns/web/v2/search/notes` | 可作为小红书只读采集字段和分页适配的参考 | `apis/xhs_pc_apis.py`：`search_note`、`search_some_note` |
| 笔记详情 | 从链接提取 note ID、`xsec_token`、`xsec_source`，调用 feed 详情接口 | 提醒我们不能只保存 note ID；分享链接中的访问上下文也可能是请求材料 | `apis/xhs_pc_apis.py`：`get_note_info`；`backend/app/api/platforms/xhs/pc.py`：`_note_url`、`_normalize_detail_payload` |
| 用户作品读取 | `user_posted` 分页读取用户作品 | 可作为竞品账号“按主页读取作品”的候选平台能力 | `apis/xhs_pc_apis.py`：`get_user_note_info`、`get_user_all_notes` |
| 一级/二级评论 | 分别调用 comment page 和 sub-comment page，后端递归扁平化并保留父评论 ID | 可吸收评论层级模型；CreatorHub 当前需求首先要求一级评论，但应保留父子关系扩展位 | `apis/xhs_pc_apis.py`：`get_note_out_comment`、`get_note_inner_comment`；`backend/app/api/platforms/xhs/pc.py`：`_flatten_comments` |
| 图文/视频媒体上传 | 先申请上传许可，再向 `/spectrum/{file_id}` 上传；视频返回 `X-Ros-Video-Id` | 上传许可、token、过期时间和实际上传结果应分步记录 | `apis/xhs_creator_apis.py`：`get_fileIds`、`upload_media` |
| Creator 发布 | 话题/地点查询、媒体上传、图文发布；视频还涉及封面和转码查询 | 说明写操作不是一个 HTTP 请求，需要独立状态和结果证据 | `apis/xhs_creator_apis.py`：`get_topic`、`get_location_info`、`post_note` |
| 登录 | 支持 Cookie、二维码和手机号路径，维护多域 Cookie 和安全初始化 | 可借鉴登录态与业务账号状态分离，以及登录后再次调用 user-info 验收 | `xhs_utils/xhs_pc/auth.py`、`apis/xhs_pc_login_apis.py`、`apis/xhs_creator_login_apis.py` |
| 监控/定时/草稿 | 有关键词、账号、品牌、笔记 URL 监控、快照、定时发布和 AI 草稿 | 可作为产品功能的反例和字段参考；不能当作已验证生产能力 | `backend/app/api/platforms/xhs/monitoring.py`、`backend/app/services/scheduler_service.py` |
| 原始响应与标准字段并存 | 标准化标题、正文、作者、媒体、指标，同时保留 `raw`/`raw_json` | 适应平台字段变化时可重新解析历史数据，不必再次请求 | `backend/app/api/platforms/xhs/pc.py`、`backend/app/api/platforms/xhs/crawl.py` |
### 2.2 README 宣称但不能直接视为已实现
上游 README 的完整功能清单很大，包含数据采集、内容管理、AI 改写、图片处理、发布、定时和多账号健康检查。但代码中存在明显的 demo/placeholder：
- `backend/app/api/platforms/xhs/pc.py` 的 `search_users()` 返回固定 `demo-user`。
- 同文件的 `user_notes()` 返回 `sample_notes()`，不是用户作品真实读取。
- `homefeed_channels()` 和 `homefeed_recommend()` 返回固定示例。
- 监控、定时、AI 等业务接口存在，但不等于真实平台链路已成功，也不等于数据持续更新正确。
因此本研究把“README 功能清单”标为**文档宣称**，把上表源码路径标为**源码存在**；只有真实账号、真实响应和失败恢复证据才能升级为 CreatorHub 的“已支持”。
## 3. 上游已经暴露的关键坑
### 3.1 请求签名是动态协议，不是一个固定函数
源码同时维护：
- 本地生成的 `a1`、`b1`、`X-s`、`X-t`、`X-S-Common`、trace ID、`xy-direction`、搜索 ID；
- 服务端下发或依赖会话的 `_dsl`、`websectiga`、`sec_poison_id`、`gid`、登录 Cookie；
- PC 与 Creator 分开的 RAP 指纹模板；
- MNS 分档、会话计数、设备状态、Cookie 域和请求头顺序；
- `curl_cffi` Chrome impersonation、HTTP/2 和关闭默认 headers 的传输行为。
对应源码：
- `xhs_utils/xhs_pc/auth.py`
- `xhs_utils/xhs_pc/state.py`
- `xhs_utils/xhs_pc/params.py`
- `xhs_utils/xhs_core/http.py`
- `xhs_utils/xhs_creator/auth.py`
- `xhs_utils/xhs_creator/params.py`
**可吸收的原则：**把每个请求材料标注为“本地可计算、服务端签发、用户交互、会话状态”四类；服务端签发材料不能当静态配置，登录 Cookie 不能当作永久登录证明。
**不应吸收的做法：**把逆向签名、指纹模板或固定 Chrome 版本包装成长期稳定 SDK。它们应被视为平台专用、可替换、需要真实证据的适配层。
### 3.2 PC 和 Creator 是两套不同链路
上游同时维护 `xhs_pc_*` 与 `xhs_creator_*` 两套认证、请求参数、Cookie 域、RAP 模板和业务 API。Creator 发布请求使用独立指纹模板；PC homefeed 使用的模板不能直接拿去发布，否则会被服务端以参数错误拒绝。
**对 CreatorHub 的约束：**
- `platform=xhs` 不足以决定适配方式，还要区分读取/登录上下文和 Creator 写入上下文。
- 不复用“PC 读取成功”作为 Creator 发布成功依据。
- 账号登录状态、业务账号状态和浏览器环境状态必须分别保存。
### 3.3 `_dsl`、安全 Cookie 和设备状态有时序要求
Creator 登录实现明确分为匿名会话、honeypot、DS 程序、安全 Cookie、`websectiga`、`gid`、CAS 二维码/手机号登录和最终 user-info 验收。部分 `_dsl` 由服务端拉取并短时缓存；代码还记录不同 CDN 节点可能导致时间锚点不同。
这说明以下做法不可靠：
- 用本机时间简单替代服务端时间锚点；
- 只保存 `a1` 或网页 `document.cookie`；
- 只判断二维码接口 HTTP 200 就认为登录完成；
- 把一个匿名设备会话的安全材料复制给另一个账号。
### 3.4 406 不是普通网络失败，重试边界取决于会话
上游源码区分了两类 406：
- 某些 customer 域请求被记录为按请求概率拒绝，可以在同一会话内有限重发；
- Creator 登录/发布场景的另一些拒绝会标记整个匿名设备会话，需要重建 `a1/webId`、Cookie store 和连接，而不是重复发送原请求。
公开 Issue 也说明该判断会随服务端变化：
- [Issue #27：发布接口 HTTP 406](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/27)：同一会话重新生成参数仍连续失败，作者怀疑 Creator 指纹模板过期；
- [Issue #24：Creator 二维码/验证码 406](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/24)：登录入口持续 406。
**CreatorHub 做法：**只对已证明是安全的、幂等的读取请求使用有限重试；写操作遇到 406 不得用重试掩盖不确定结果。已发送但缺乏确认时标为 `uncertain`，不自动补发。
### 3.5 461 可能来自流程变化，不一定是账号失效
[Issue #25](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/25) 记录：PC 二维码登录的 `/api/sns/web/v1/login/activate` 稳定返回 HTTP 461；前置安全接口均为 200。同一机器在旧提交 `2819d74` 中通过 `webprofile` 获取 `gid` 的流程可以继续生成二维码，算法更新后反而失败。
**可吸收的排查方式：**保留“最后成功提交/算法版本、请求阶段、HTTP 状态、响应 code、Cookie key、是否已拿到 gid”的结构化诊断，不把 461 直接归类为 Cookie 过期或账号封禁。
### 3.6 发布 payload 的微小差异会造成业务错误
`apis/xhs_creator_apis.py` 记录了几个具体失败点：
- 没有地点时必须省略 `common.post_loc`，发送空对象 `{}` 可能返回 `-9059`；
- 话题需要先查到平台对象，不能只把用户输入字符串塞进 payload；
- Creator 发布需要 Creator 专用 `x-rap-param` 指纹；
- 视频上传成功后还涉及封面、异步转码和发布时机。
这类坑值得吸收为**契约测试和失败证据**，不值得吸收为“万能兼容字段清洗”。平台响应字段变化时应让适配器明确失败并记录原始响应。
### 3.7 视频转码失败不应被当作成功前置条件
上游视频发布分支在转码查询不可用时会 warning，然后直接继续发布；这是该仓库的取舍，不适合 CreatorHub 当前的结果模型。CreatorHub 已要求区分成功、失败和结果不明，不能把“转码状态无法确认”转换成“可以继续发布”。
### 3.8 上游的分页循环缺少 CreatorHub 所需的完整边界
上游的 `get_user_all_notes()`、评论聚合等循环主要依赖 `has_more` 和返回 cursor，源码没有统一的重复 cursor 检测、最大页数和 checkpoint/lease 机制。
CreatorHub 已有更严格的 `internal/creator/collection.go`：
- cursor 缺失、重复、不前进会失败；
- 最大 100 页硬边界；
- 采集窗口固定，不因分页时间变化而滑动；
- 有 checkpoint、lease 和中断后续采基础。
**结论：**分页保护直接复用 CreatorHub 现有模型，不复制上游的简单 `while True`。
### 3.9 媒体下载实现过于宽松
`backend/app/services/asset_downloader.py`：
- 仅检查 URL 前缀、HTTP 状态和内容长度；
- 使用空 `Referer`；
- 不验证响应 MIME 与实际文件类型；
- 不限制文件大小、不做断点、不保留明确失败状态；
- 异常统一 warning 后返回 `None`，上层仍可能把笔记保存成“成功”。
**CreatorHub 不采用：**下载失败静默变成空路径。使用现有 `internal/creator/creator_material.go` 的分步状态、原子文件、大小限制、HTML 拒绝和失败步骤记录。
### 3.10 账号风控风险是真实运营风险
公开 [Issue #13](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/13) 及评论中，多名用户反馈使用工具发布后出现脚本操作警告、封禁；反馈包括视频发布后封号和“贵重账号慎用”。这些是用户报告，不是平台官方因果证明，但足以作为高风险信号。
CreatorHub 不应承诺“稳定”“不封号”或“无法识别”，也不应通过更换指纹、随机重试或隐藏错误来规避风控。真实写操作必须：
1. 使用者明确授权；
2. 登录环境和账号身份再次核对；
3. 目标、文案、媒体和平台返回证据可追溯；
4. 失败/不确定停止，不自动换账号、换代理或补发。
### 3.11 前端 refresh 递归和部署依赖也值得记录
- [Issue #23](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/23)：前端 401 拦截器把 `/auth/refresh` 自身再次送入 refresh，导致登录页无限 checking。通用经验是 refresh 请求必须有明确标记，失败只清理一次并回到登录页。
- [Issue #22](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/22)：Debian Trixie 移除了 `libgl1-mesa-glx`，Docker 构建失败。不要固定过时系统包名，镜像构建要在当前基础镜像上实际验证。
这两项不是 CreatorHub 当前小红书业务核心，但可作为前端会话恢复和 Compose 构建检查的回归用例。
## 4. 对 CreatorHub 的吸收清单
### 4.1 现在就吸收：不增加平台耦合
| 吸收项 | CreatorHub 落点 | 具体要求 |
| --- | --- | --- |
| 平台适配器与业务逻辑分离 | 新增小红书适配时沿用 `internal/platform/douyin` 的边界，业务层不直接拼平台请求 | 读取、登录、媒体、动作、事件各自有清晰接口；不把上游 Python SDK 直接嵌进控制面 |
| 原始响应 + 标准字段 | `internal/creator` 的 Work/Comment/Material 数据 | 保存原始平台 payload、来源链接、采集时间和标准化结果；字段变化先保原文再调整解析 |
| `xsec_token`/`xsec_source` 端到端保留 | 作品来源/平台适配输入模型 | 详情链接、搜索结果和后续详情请求不得丢失访问上下文；没有 token 时不得猜测或拼造 |
| 评论父子关系 | Comment 入库字段扩展时保留 `parent_comment_id` | 当前业务先采一级评论，平台返回子评论时不丢弃层级；不要把昵称当用户 ID |
| 指标三态 | Work 指标和采集报告 | `0` 只表示平台明确返回 0；缺失使用“不可获取/待采集”，不把缺失填成 0 |
| 分页安全 | 直接复用 `internal/creator/collection.go` | 统一做 cursor 缺失、重复、不前进、页数上限和 checkpoint/lease，不复制上游无限循环 |
| 媒体分步处理 | `internal/creator/creator_material.go` | 下载、提音、转写、仿写分别记录状态、产物、失败步骤；不把整条任务压成一个 boolean |
| 登录态健康检查 | 账号登录状态与动作前身份核对 | Cookie 存在不等于登录有效；每次写操作前核对实际 UID、环境和目标 |
| 证据分级 | `ActionResult`、Task、E2E evidence | 区分源码存在、接口返回、业务确认、失败、结果不明；HTTP 200 不自动算成功 |
| 领域错误可观测 | 网关/控制面边界 | 记录平台、账号、环境、请求阶段、外部状态、业务 code、响应摘要和 trace；不在底层静默吞异常 |
### 4.2 只能带着改造吸收
| 上游做法 | 改造后才可用 | 原因 |
| --- | --- | --- |
| `curl_cffi` Chrome impersonation | 仅在真实平台证据证明普通浏览器网关无法满足时评审引入 | 新增依赖和维护面大，不能先把私有签名客户端当默认架构 |
| `_dsl`/`websectiga` 缓存 | 设计为有来源、TTL、版本和失效原因的短生命周期运行时材料 | 服务端程序可能轮换，不能写死或永久缓存 |
| 406 有限重试 | 只用于已证明幂等且不会产生写副作用的阶段 | 写操作重试会造成重复发布或掩盖不确定结果 |
| Creator 上传许可 | 建立上传许可、过期时间、上传结果、媒体校验的状态机 | token 过期和上传成功不是同一状态 |
| 视频封面/转码查询 | 转码未确认时状态为 `pending/uncertain`，禁止自动跳过门禁发布 | 上游“warning 后继续”不符合 CreatorHub 结果约束 |
| 监控/定时服务 | 使用 CreatorHub 既有计划、lease、任务和证据模型 | 上游 scheduler 在应用进程内运行，容易重复执行和丢失任务边界 |
### 4.3 明确不吸收
- 复制或改造上游逆向签名 JavaScript、RAP 指纹模板、设备指纹模板、`websectiga` 执行器。
- 固定 Chrome/Web build、固定 MNS 环境值，并把它们当作永久配置。
- 通过重试 406/461 规避平台拒绝。
- 把 Cookie 导入当作 CreatorHub 的生产登录方案；当前需求是用户在可见环境人工登录，系统核对身份。
- 用普通翻页 cursor、昵称、头像、时间或内容哈希猜事件唯一 ID。
- 用上游主动读取接口代替自有账号互动/私信事件监听。
- 采用空 Referer 下载、内容长度阈值代替媒体真实性校验。
- 采用上游固定 demo 返回或 README 清单作为功能回退。
- 直接采用 Ant Design、`lucide-react` 等前端体系；CreatorHub 保持 shadcn/ui、Tailwind 和 RemixIcon。
- 直接把上游 AI 自动改写、随机选笔记和定时发布流程当作本期业务。
## 5. 与当前 CreatorHub 的对照
### 5.1 已有基础，应直接复用
- `internal/creator/models.go`：已有平台、作品、评论、素材、事件、策略和动作结果模型。
- `internal/creator/collection.go`：已有分页边界、固定 UTC 窗口、checkpoint、lease 和续采。
- `internal/creator/content.go`：已有竞品导入、启停、作品 upsert 和来源关联。
- `internal/creator/actions.go`：已有事件永久去重、策略顺序、同 UID 冷却，以及 AI 失败/结果不明不补发。
- `cmd/control-plane/creator.go`：已有写操作前身份核对、目标映射和结果证据保存。
- `cmd/control-plane/creator_material.go`：已有人工选取、原子媒体文件、大小/HTML 校验、ffprobe/ffmpeg 和显式转写失败步骤。
- `cmd/control-plane/creator_events.go` 与 `browser_gateway/platform/douyin.py`：已有监听代际、baseline、gap、断连恢复、delivery ACK/retry 的抖音实现；小红书不能直接沿用为已验证能力。
- `docs/plan01.md`：已明确先抖音后小红书、逐平台真实验收，以及读取/写入/事件的成功、失败、不明边界。
### 5.2 当前小红书缺口
当前已有小红书只读代码适配器和 gateway 路由，但尚未完成真实账号验收。不能因为 `platform=xhs` 可登记、代码测试通过或页面可打开，就宣称以下能力已经在生产环境可用：
- 人工登录后的实际 UID 核对；
- 主页/分享链接解析和稳定账号标识；
- 作品和一级评论完整分页；
- 30 天窗口、checkpoint 续采和指标计划；
- 媒体下载、提音、转写；
- 评论、点赞、关注、转发、私信写操作；
- 自有账号互动和私信事件监听；
- 断连恢复、稳定事件 ID、baseline 和缺口证据。
### 5.3 上游没有解决、CreatorHub 仍必须独立验收
1. **事件监听**：上游的搜索/评论/主页接口是主动读取，不证明平台会推送稳定事件，也没有跨重启事件身份闭环。
2. **目标身份**：读取到评论不等于能拿到可用于私信/关注的稳定互动者 UID。
3. **公开数据完整性**：第一页或当前接口返回不等于最近 30 天完整作品/评论。
4. **媒体地址寿命**：返回视频/图片 URL 不等于可下载、可长期复用或可提取音轨。
5. **写操作结果**：上传成功、发布请求返回和平台实际可见是不同证据层级。
6. **账号风险**：开源实现能跑不等于账号可安全长期运营。
## 6. 建议的落地阶段
### XHS-G0：冻结能力矩阵和证据格式
先按平台能力单独建立小红书矩阵，不复制抖音结论。每一项记录：
- 账号/环境/代理/登录方式；
- 平台稳定 UID、作品 ID、评论 ID、互动者 UID 是否存在；
- 请求阶段、平台时间、系统接收时间、原始响应摘要；
- 成功、失败、结果不明或数据缺失；
- 是否可跨重连/重启恢复；
- 是否允许进入自动响应。
小红书事件如果无法证明稳定事件 ID、互动者 UID、目标作品/评论和恢复边界，自动响应保持阻塞。
### XHS-G1：只读连接器
只实现最小纵向切片：
1. 人工登录并核对账号 UID；
2. 输入主页链接或作品分享链接，解析并要求用户确认；
3. 读取一页作品和详情；
4. 读取超过一页的作品和一级评论；
5. 保存原始 payload、原始链接、`xsec_token/xsec_source`（若平台提供）和标准字段；
6. 证明固定 30 天窗口、分页不重复、cursor 不前进会失败、重启可续采。
这一阶段不做签名引擎复制、不做自动登录、不做事件监听、不做自动动作。
### XHS-G2：素材处理
在 G1 取得真实可用媒体地址后，接入现有人工选取链路：
- 下载原始媒体并做大小/MIME/文件真实性校验；
- 无视频、无音轨、无语音、下载失败分别记录；
- 提取音轨、转写、仿写分别产生状态和产物；
- AI 失败和转写失败不得用原文或空文本冒充成功。
### XHS-G3：人工写操作
仅在每个动作分别取得真实证据后实现平台专用 adapter：
- 回复评论；
- 点赞评论/作品；
- 关注互动用户；
- 转发作品；
- 人工发送私信。
每次写入前再次核对登记账号 UID、当前浏览器身份、目标 UID/评论/作品；平台返回不完整或连接中断时保存 `uncertain`，不自动重试或换小号。
### XHS-G4：事件监听
上游仓库不能提供现成方案。需要单独研究小红书已登录页面/平台可观察事件：
- 事件是否能由真实页面监听取得；
- 是否存在稳定事件 ID 或可证明的新旧边界；
- 互动者 UID、评论 ID、作品 ID 是否齐全；
- 断连和进程重启后能否恢复；
- 是否满足 5 秒开始处理、30 秒页面可见的时限。
未通过这些证据前，不启用小红书自动响应。
### XHS-G5：双平台回归
小红书独立通过 G0-G4 后，再做双平台共存回归：账号、Profile、代理、Cookie/登录态、事件、冷却、任务和证据不能串号；不能用上游 README 或离线 fixture 替代真实证据。
## 7. 第一批推荐实现项
| 优先级 | 项目 | 原因 | 验收门槛 |
| --- | --- | --- | --- |
| P0 | 小红书只读适配器 + 原始响应归档 | 价值最大、风险最低，能验证平台真实读取边界 | 真实账号 UID、详情、分页作品、一级评论、失败证据 |
| P0 | 作品/评论字段三态和 `xsec_*` 上下文保留 | 直接解决字段缺失、链接失效和后续重解析 | 缺字段不变 0；上下文可回放/诊断 |
| P1 | 竞品账号固定窗口采集 | 对应当前 C1/C2/W1 需求 | 最近 30 天、超过一页、重启续采、重复 cursor 失败 |
| P1 | 人工选取后的媒体处理 | 对应当前 C4，且不依赖自动写操作 | 下载/提音/转写逐步成功、失败、无内容证据 |
| P2 | 人工评论/私信写操作 | 先满足工作台最小闭环 | UID/目标/身份核对，成功/失败/不明三态 |
| P2 | 互动/私信事件监听 | 依赖平台真实事件身份和恢复能力 | 稳定事件 ID、baseline、重连/gap、时限证据 |
| P3 | 自动响应策略 | 只有事件、动作和账号隔离都通过后才有意义 | 永久去重、UID 冷却、AI 失败不补发、全量真实证据 |
## 8. 研究后形成的明确决策
1. **把上游当作坑位和协议观察资料，不作为 CreatorHub 运行时依赖。**
2. **先复用 CreatorHub 自有分页、任务、素材和结果证据模型。**上游简单循环、静默下载失败和 warning 后继续发布不符合当前验收标准。
3. **小红书读取、Creator 发布和事件监听分别建立适配器和证据门。**不把一个能力的成功外推到另一个能力。
4. **许可证未确认前不复制上游代码或静态逆向产物。**即使后续确认 MIT，也要单独核对签名脚本、指纹模板和其上游来源的版权/授权。
5. **不建设“反检测/不封号”承诺。**风控拒绝和账号处罚是外部平台结果，必须如实暴露并保留人工处理入口。
6. **当前不新增 `curl_cffi`、APScheduler 或另一套前端组件体系。**只有真实平台证据证明现有浏览器 gateway/标准库不足时，才提交针对性技术评审。
## 9. 来源与证据索引
### 上游仓库与提交
- 仓库：<https://github.com/cv-cat/XHS_ALL_IN_ONE>
- 研究快照：<https://github.com/cv-cat/XHS_ALL_IN_ONE/tree/e86f82bb>
- 算法大改提交：<https://github.com/cv-cat/XHS_ALL_IN_ONE/commit/17d42a67d7ed8d12d615de5439863485d7102acf>
- README：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/README.md>
- PC API：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/apis/xhs_pc_apis.py>
- Creator API：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/apis/xhs_creator_apis.py>
- Creator 登录：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/apis/xhs_creator_login_apis.py>
- PC 登录：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/apis/xhs_pc_login_apis.py>
- PC 鉴权/参数：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/xhs_utils/xhs_pc/auth.py>、<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/xhs_utils/xhs_pc/params.py>
- Creator 鉴权：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/xhs_utils/xhs_creator/auth.py>
- HTTP 传输：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/xhs_utils/xhs_core/http.py>
- PC 后端标准化：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/backend/app/api/platforms/xhs/pc.py>
- 媒体下载：<https://github.com/cv-cat/XHS_ALL_IN_ONE/blob/e86f82bb/backend/app/services/asset_downloader.py>
### 公开 Issues
- [#5 长期稳定性、签名、补环境和 TLS/HTTP 指纹](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/5)
- [#13 使用脚本操作警告与封禁反馈](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/13)
- [#22 Debian Trixie 中 `libgl1-mesa-glx` 构建失败](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/22)
- [#23 前端 refresh 401 死循环](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/23)
- [#24 Creator 登录二维码/验证码 406](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/24)
- [#25 PC 二维码登录 `/login/activate` 返回 461](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/25)
- [#27 Creator 发布 `/web_api/sns/v2/note` 返回 406](https://github.com/cv-cat/XHS_ALL_IN_ONE/issues/27)
### CreatorHub 当前依据
- [业务需求与验收基线](../plan01.md)
- `internal/creator/models.go`
- `internal/creator/collection.go`
- `internal/creator/content.go`
- `internal/creator/actions.go`
- `cmd/control-plane/creator.go`
- `cmd/control-plane/creator_events.go`
- `cmd/control-plane/creator_material.go`
- [容器与 gateway 架构](../architecture/container-control.md)
## 10. 研究范围限制
- 未使用真实小红书账号验证登录、搜索、详情、评论、下载、发布或事件监听。
- 上游 README 的功能清单、用户 Issue 的账号封禁反馈和平台风控判断不能当作官方因果证明。
- `LICENSE` 文本当前未能确认，不能据此进行代码复制或商业化授权判断。
- 上游实现可能继续随 Web 版本变化；后续若要实现小红书能力，必须重新锁定源码提交、真实环境和证据时间。
Reference in New Issue View Git Blame Copy Permalink