哔站去水印 · 多平台一键发布桌面软件：功能规划 V1.0

我建议把这个项目做成一款真正的 自媒体内容工作台，而不是简单的“哔哩哔哩视频去水印工具”。

核心流程是：

技术路线沿用你已确定的 Tauri 2 + React。Windows 桌面端使用 React 负责界面，Tauri/Rust 负责系统能力和本地文件，独立的 Node.js + Playwright 进程负责受控的浏览器自动化。视频处理、API 调用和任务调度分别封装，避免所有功能挤在一个模块里。

一、先明确产品的核心定位

产品可以包含三个相互配合的工作区：

有一个重要区别：去水印不应该成为整个产品唯一的价值点。 更实用的方向是让用户从找到一个视频开始，经过素材整理与内容适配，最终完成自己有权使用的内容发布。

涉及他人作品时，应保留原作者、来源链接和授权信息；不能因为技术上能下载或去除水印，就默认拥有再次发布的权利。

二、内容发现模块：让素材进入软件更方便

这一部分是软件的流量入口，也是你已有“链接解析 + 关键词搜索”思路的扩展。

建议新增：相似素材查重。 同一个作品可能被多次搜索或重复导入，系统应根据作品 ID、文件哈希和素材记录识别重复项目，避免反复下载和误发。

需要注意的是，搜索和内容获取应优先通过获得授权的接口或素材来源完成。不能保证每一项作品信息都可以通过某个 API 获取，因此接口模块需要允许单项能力缺失，而不是让整个采集流程失败。

三、视频处理模块：不只提取标题

解析出作品后进入独立的处理工作区。建议分为六个子模块。

在有权使用的视频文件上，还可以提供相应的画面处理功能。建议保留原始素材，不直接覆盖原文件；处理后的文件单独保存，并关联到源作品记录。

值得增加的进阶功能

智能内容包。 处理完成后，一次性生成发布需要的全部素材：

• 原始标题、发布标题和备选标题。

• 视频简介、话题标签、关键词。

• 封面图及封面文字。

• 字幕文件和文本稿。

• 对应平台的发布参数。

• 来源链接、授权凭证和内部备注。

后续可以添加 AI 标题改写、简介润色、字幕翻译、长视频摘要、章节提取等功能。但建议让用户预览并确认 AI 修改结果，不能默认将原作者的内容改写后就视为原创。

四、多平台发布中心：软件的核心竞争力

建议把发布中心做成一个统一的工作区，而不是给每个平台分别开发一整套互不相通的页面。

1. 平台适配器

内部为每个平台设计独立适配器：

2. 一键发布和多账号发布

建议设计以下发布方式：

快捷发布： 在素材详情页选择目标平台及账号，检查标题与封面后发起发布。

多平台分发： 选择一个素材，同时创建小红书和 YouTube 两个发布任务，每个平台分别生成适配内容。

批量发布： 从素材库多选视频，统一设置目标平台，再逐条检查发布内容。

定时发布： 将任务加入计划队列，在受支持的发布方式下按预定时间执行；如果平台不支持可靠定时发布，则只创建提醒或待发布任务。

草稿模式： 先生成每个平台的待发布内容，用户可以统一修改、预览并逐条确认。

3. 平台专属参数

平台的具体字段和限制应以实际授权接口、账号权限和当时的产品规则为准，不能假设两个平台完全相同。

4. 发布前预览

这是一个很值得增加的功能。发布前显示目标平台的模拟预览，重点检查标题是否截断、封面是否合适、字幕是否遮挡主体、标签是否完整、视频格式是否符合要求，以及是否遗漏必要的授权声明。

用户确认之后才提交发布。对于涉及多个账号的批量任务，尤其不建议省略这一步。

五、账号中心与 Playwright 浏览器管理

你已经准备了 Playwright 自带的 Chromium，因此建议把它设计成独立的浏览器运行环境，而不是让前端直接操控系统浏览器。

账号中心建议包含

关于你提出的 Cookie 获取方式，需要调整一下

Playwright 确实支持读取浏览器 Cookie，并通过 storageState 保存登录状态；官方文档同时提醒，状态文件可能包含可以冒用账号的敏感令牌。Playwright+1

建议采用以下设计：

• 小红书：由用户在独立浏览器窗口中自行登录，优先使用获得授权的平台接口；没有合适的发布接口时，可提供合规的辅助发布与人工确认流程。

• YouTube：优先使用 Google OAuth 授权及 YouTube Data API 完成账号授权和上传，而不是提取、导出或复用 YouTube Cookie。官方提供了视频上传接口 videos.insert；其开发者政策也明确限制抓取 YouTube 应用内容及收集用户认证信息。Google for Developers+1

• 本地安全：会话数据按账号隔离，使用操作系统支持的加密能力保护，不在日志、前端调试输出或普通配置文件中展示 Cookie。

小红书开放平台存在开发者注册和资质审核流程，不能预设普通应用一定拥有笔记发布权限。正式实现前应核实你的开发者资质和可用接口。小红书

这样处理之后，浏览器模块的职责就更明确了：负责受控的登录和授权会话，以及平台允许的浏览器辅助操作；真正的内容发布由合适的授权接口或用户确认流程完成。

六、任务中心：批量操作必须有可靠的任务系统

建议把视频下载、视频处理、解析和发布全部纳入统一任务中心。

每个任务记录至少包括：

建议补齐的任务控制能力

• 暂停、继续和取消。

• 失败任务重试，尽可能从失败阶段恢复。

• 同一平台设置独立的并发量，避免任务相互干扰。

• 发布失败与视频处理失败分别显示，不混为一类。

• 重复发布检测：检查来源、目标账号和既有任务记录。

• 应用异常退出后恢复未完成任务。

• 每条任务都有独立日志，方便定位问题。

• 需要人工操作时暂停任务并明确提示，不无限等待。

尤其需要增加发布结果校验：不能仅仅因为浏览器点击了发布按钮，就显示“发布成功”。应当在平台返回明确结果或确认内容已创建后，再将任务标记为成功。

七、素材库与发布管理

建议增加一个完整的本地素材资产库，让用户能够管理积累下来的内容。

如果后续想将它升级成团队或工作室使用的产品，还可以扩展项目协作、任务分配、发布审批、操作审计及多用户权限。

八、还应该增加的安全与合规功能

这些功能最好在第一版就预留，而不是等发布能力完成后再补。

版权与来源记录： 保存原链接、作者、来源时间和授权说明；没有授权信息的素材可以继续整理，但在批量发布前应提示用户确认使用权。

内容审核： 检测文件缺失、标题为空、异常封面、字幕异常和重复素材；对于其他平台的内容规则，则由相应的平台校验和用户审核补充。

隐私保护： 用户能够单独清除账号会话、删除本地作品记录以及清除临时文件。不要把浏览器会话、API Key 或敏感日志打包上传。

发布确认： 支持设置默认发布策略，批量任务仍应提供明确的目标账号、内容预览和执行确认。不能因为用户点击了一次“批量处理”，就默认允许未来自动发布所有内容。

九、建议的软件页面结构

我建议最终采用下面这套导航。它既能覆盖当前业务，也为将来增加抖音、快手、视频号等平台留出了位置。

十、Tauri 2 + React 技术架构建议

建议采用以下模块化架构，避免后续某个网站页面变化就影响整个项目。

关于你本机的 Chromium 和 API Key

Chromium 可以放进项目的专用资源目录，或者在首次运行时检查并配置独立的浏览器目录。你提到的路径可以作为开发机上的默认检测路径，但不应写死为最终唯一配置，因为其他电脑上的安装位置可能不同。

推荐设置：

• 独立浏览器资源目录，例如 resources/browser/chromium-1208/。

• 运行时可配置浏览器路径，启动时检查文件是否存在。

• 浏览器可执行文件与 Playwright 版本保持兼容。

• 各平台账号使用各自的隔离配置目录。

• API Key 加密保管，不直接写入前端源码或提交到代码仓库。

• 发布正式安装包前明确 Chromium 的分发方式、安装包体积及相关许可要求。

你给出的本机 API 文档位置是 C:\Users\Administrator\WorkBuddy\哔站去水印-一键发布到视频网站去水印网站的api文档.txt。当前对话里还没有该文件的实际内容，因此暂时不能确定去水印 API 的请求方式、鉴权参数、返回结构和错误码。后续需要按这份文档建立独立的 API 适配器，而不是预先假定接口形式。

十一、开发优先级：先做什么最合适

我建议分成三个阶段，确保第一版不是功能很多但主流程不稳定。

十二、我认为最值得优先实现的三个差异化功能

第一，链接到发布的一条龙工作流。 用户不必在搜索页、下载工具、文件夹和发布页面之间来回切换，而是在一个素材工作区里完成全部步骤。

第二，跨平台内容包。 一个源素材对应多份平台专用文案、封面、标签、发布参数与审核状态，而不是简单把相同标题复制到所有平台。

第三，可恢复的自动化任务。 网络异常、浏览器关闭、接口返回失败后，软件能准确显示失败在哪一步，并在确认安全的情况下重试，而不是让用户重新操作整条流程。

最终建议把产品定义为：基于本地素材库的自媒体内容采集、加工与多平台发布工作台。哔哩哔哩作为第一阶段的内容入口，小红书和 YouTube 作为首批分发目标，之后新增其他平台时只需扩展对应适配器。

这样既保留了你最初提出的去水印和一键转发思路，也为软件后续做成成熟的 Windows 桌面产品留下了清晰的架构和升级空间。