🔗
多源输入
抖音分享链接、纯文本均可作为输入；内容源以插件形式接入，新增来源不需要改主流程。
01
要解决的问题
信息散落在不同平台：短视频里的观点、随手记的片段、临时链接。手动整理既费时又难坚持。这个项目把「输入 → 整理 → 归档」做成一条自动化流水线。
🧠
多模型能力
文本整理、语音转写、图片理解分别绑定不同模型；供应商与能力在管理端配置，运行时可切换。
📄
落到飞书
整理结果按模板生成飞书文档，通过用户 OAuth 授权写入自己的空间，而不是共享一个机器人账号。
02
系统架构
前端 Nginx 托管 SPA 并反代 /api/；API 负责认证、套餐、任务队列与插件调度；抖音解析由独立的浏览器签名桥承担。
03
技术亮点
🧩
插件化内容源
解析器实现统一的输入契约（URL / 文本 → 结构化内容），抖音只是其中一个实现；失败可降级并记录原因。
🔀
自研模型网关
ai_providers 表登记供应商、密钥与能力绑定，运行期按「能力」而非「供应商」取模型；已退役外挂的 New API。
🔑
用户 OAuth 连接器
飞书写入优先走用户授权的 OpenAPI，凭据加密持久化；不可用时降级到 lark-cli 通道，保证任务不中断。
🕵️
真实浏览器签名桥
短视频平台的风控签名依赖真实浏览器环境。独立 bridge 容器用 Playwright 生成请求签名，通过健康检查与 API 解耦。
📋
任务队列
解析、转写、整理、写入分阶段执行，失败可重试；前端轮询任务状态，长任务不阻塞交互。
🧭
三端分离
用户端、管理端、服务端职责分离：用户只选套餐与功能，管理端管模型与用量，服务端管认证与任务。
04
关键取舍
A个人工具优先可用性
不追求多租户与高并发：SQLite、单机部署、直连供应商。把复杂度花在「解析成功率和整理质量」上。
B数据不出本机
笔记内容、OAuth 凭据、签名环境全部在本地容器内，数据库与凭据目录持久化挂载，不经过第三方中转服务。
C按能力取模型
业务只声明「需要文本整理 / 语音转写 / 图片理解」，由网关决定用哪个供应商。换模型不改业务代码。
D不公开在线 Demo
系统绑定个人飞书账号与内容库，不适合对外开放。仓库提供完整代码与部署说明，可本地运行。
05
项目规模
3运行容器
3模型能力（文本 / 语音 / 视觉）
2内容源接入方式
1条 compose 命令交付