feat: integrate creator hub douyin workflows

2026-09-14 19:22:07 +08:00
parent 025fe62c37
commit 44a28954cf
42 changed files with 2850 additions and 880 deletions
@@ -0,0 +1,388 @@
+# `XHS_ALL_IN_ONE` 小红书能力吸收与落地研究
+
+> 研究日期：2026-09-14
+> 上游仓库：<https://github.com/cv-cat/XHS_ALL_IN_ONE>
+> 研究快照：`e86f82b`（`master`）
+> 研究方式：只读检查源码、提交历史与公开 Issues；未向小红书真实账号发起请求，以下不等同于平台能力验收。
+> 当前结论：本文仅形成小红书后续实现的研究约束，尚未接入运行代码；未复制上游代码、签名脚本、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 当前只保留平台枚举和通用 Creator 数据模型；小红书专用 collector、gateway 路由和动作适配器未接入。
+- `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/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` 与 `cmd/docker_gateway/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 版本变化；后续若要实现小红书能力，必须重新锁定源码提交、真实环境和证据时间。