# B站插件调研 - Phase 1.3 授权方案对比与推荐 **调研时间**: 2026-02-06 **调研人**: 阿里巴巴助手 --- ## 方案对比总表 | 评估维度 | B站官方开放平台 | bili-auth 第三方方案 | |----------|----------------|---------------------| | **准入门槛** | ❌ 仅企业开发者 | ✅ 任何B站用户 | | **申请流程** | 复杂(注册→认证→审核→开发)| 简单(部署即用)| | **授权体验** | ✅ 标准OAuth页面 | ⚠️ 需发送私信 | | **功能完整性** | ✅ 全量API | ⚠️ 普通用户API | | **稳定性** | ✅ 官方保障 | ❌ 依赖非公开接口 | | **合规性** | ✅ 100%合规 | ❌ 灰色地带 | | **账号风险** | ✅ 无风险 | 🟡 有小号风险 | | **开发成本** | 高(需企业资质)| 低(Docker一键部署)| | **维护成本** | 低(官方维护)| 中(需关注接口变动)| | **扩展性** | 强 | 弱 | --- ## 决策矩阵 ### 场景分析 | 使用场景 | 推荐方案 | 理由 | |----------|----------|------| | 企业/机构项目 | **官方开放平台** | 合规、稳定、功能完整 | | 个人学习/实验 | **bili-auth** | 门槛低,快速验证想法 | | 小团队内部工具 | **bili-auth** | 成本可控,风险可接受 | | 商业产品/大规模 | **官方开放平台** | 合规要求,长期稳定 | | OpenClaw 技能 | **bili-auth** | 用户即开即用,无需企业资质 | --- ## 推荐方案(OpenClaw 技能) ### 主方案: bili-auth 私信鉴权 **推荐理由:** 1. ✅ **零门槛**:用户无需申请开发者资质 2. ✅ **快速可用**:部署后即可使用 3. ✅ **标准协议**:OAuth 2.0,与官方体验接近 4. ✅ **成本可控**:只需一个小号作为机器人 **风险控制:** 1. ⚠️ **小号策略**:明确告知用户使用小号,避免主号风险 2. ⚠️ **频率限制**:技能内建限流,避免触发风控 3. ⚠️ **降级设计**:接口失效时优雅降级,不崩溃 4. ⚠️ **免责声明**:明确说明非官方方案,用户自担风险 ### 备选方案: 手动Cookie模式 **适用场景:** - bili-auth 不可用时 - 用户不愿授权第三方服务 **实现方式:** - 用户从浏览器复制Cookie - 技能直接调用B站API - 无需机器人账号 **风险:** - Cookie泄露风险 - 有效期短,需频繁更新 - 同样存在封号风险 --- ## 技术架构建议 ### 推荐架构 ``` 用户 → OpenClaw 技能 ↓ [授权模块] ↓ ├─→ bili-auth 服务(自建或公共) │ ↓ │ B站私信鉴权 │ ↓ └─← access_token ↓ [数据获取模块] ↓ B站公开API调用 ↓ 返回数据给OpenClaw ``` ### MVP 功能范围(bili-auth 方案) **Phase 1 - 基础功能** - [ ] 用户授权(bili-auth 集成) - [ ] 获取关注列表 - [ ] 获取UP主动态 - [ ] 视频搜索 **Phase 2 - 扩展功能** - [ ] 视频详情获取 - [ ] 播放历史(如有权限) - [ ] 收藏列表(如有权限) **Phase 3 - 高级功能** - [ ] 自动追更提醒 - [ ] 数据分析 --- ## Go / No-Go 决策 ### 结论: ✅ Go **理由:** 1. bili-auth 方案技术可行 2. 风险可控(小号策略+频率限制) 3. 能满足核心需求(获取关注列表、追更) 4. 用户价值明确(解决无法官方API的问题) **前提条件:** 1. 明确告知用户风险 2. 使用小号作为机器人 3. 实现频率限制 4. 准备降级方案 --- ## 下一步行动 进入 **Phase 2 - 数据获取能力调研**,验证以下API是否可用: - 用户信息获取 - 关注列表获取 - 视频搜索 - 视频详情 同时开始 **Phase 5 - 原型开发** 的准备工作。