RippleClio · 内容信用平台

Overview

项目说明

RippleClio 是 RippleClio × Wabifair 双轮生态的「精神家园」线——视频社交 + AI 创作,核心命题是「艺术创作平权」。

不是「让创作者赚钱」——是让被传统流量分配机制忽视的创作维度(摄影 / 编剧 / 音乐 / 剪辑)各自被「金票」看见。每笔关联购买的 10–20% 按共创契约自动分账,把「作品署名」从「封面挂名」升级为「账务可追溯」。

工程上 12 个 Go 服务围绕「内容信用 + 共创 + 金票投票」展开。pgvector + 本地 Ollama(qwen2.5:3b)做嵌入与推理——容器内推理意味着用户数据不出网,推荐和知识库的「主权选择」。value-tag-service 提供 TAF(Truth / Aesthetics / Future)标签语言,被 wabifair 的 catalog 反向调用,实现「内容-商品双锚点」自然联动。

Agora 信用引擎实现三个交互协议——涟漪(轻量响应)、证言(实名背书)、礼赞(可量化、可附金票),分别被 content-review / recommendation / honor 三个服务消费。同一数据通路里既有「流量信号」,也有「信用证据」,也有「账务凭据」。

启动顺序硬约束:必须先 core-platform(共享网络 + Auth + Gateway + DB)再 rippleclio-content(以 external: true 加入)。0048+ DB 迁移全幂等(IF NOT EXISTS / CREATE OR REPLACE)+ Outbox 可靠事件,远超初版 0001–0010 规划。

前端两端:观众/创作者 web (:5173,Radix UI + hls.js + tanstack/react-virtual + recharts) + 运营审核 admin-console (:5174)。

它是 RippleClio × Wabifair 双轮模型的「精神家园」一半——物质家园线由 [[wabifair]] 承担,两个平台通过 TAF 标签 + Agora 引擎 + 金票机制自然联动。

Process

制作流程

每个详情页都把真正重要的步骤拆开,不只展示结果,也展示判断是如何形成的。

01

内容域服务网格:12 个 Go 服务按职责拆

video(上传/转码/播放/Feed)、creation(团队协作/共创金库)、social(关注/二度人脉)、ticket(金票/艺术票/投票)、honor(荣誉/排行榜/称号)、agora(涟漪/证言/礼赞)、knowledge(个人 Brain)、recommendation(pgvector + Ollama)、content-review(审核)、live(直播)、value-tag(TAF 标签)、worker(异步任务)。每服务一个容器端口,前端不直连,经 API Gateway 路由。

02

pgvector + Ollama:本地 LLM 推理与向量检索

PostgreSQL 16 启 pgvector 扩展,recommendation / knowledge / value-tag 三个服务都用向量字段做「相似度匹配 + 嵌入」。LLM 推理走容器内 Ollama(qwen2.5:3b),仅供这三个服务调用,不对外暴露 11434 端口。数据不出容器边界,推理成本零外部 API 费用。

03

个人知识库(Personal Brain):用户私域 + 向量索引

knowledge-service 给每个用户一个「个人 Brain」:笔记 / 收藏 / 注释 / 视频片段索引 → 向量化 → pgvector 存储 → 召回时按相似度排序。把「个人内容资产」从「浏览历史」升级为「可检索的私域知识图」,与创作工具直接联动。

04

金票 / 艺术票 / 投票管理(ticket-service)

购买行为在 wabifair 侧触发,产出 TicketMinted.v1 事件 → ticket-service 把「金票」挂在对应内容下。荣誉体系(honor-service)按金票累计驱动排行榜与称号,创作者的「R 星等级」(三星+)解锁更多商品关联位 / 更高分成比例 / 邀请权。

05

Agora 信用引擎:涟漪 / 证言 / 礼赞 三协议

agora-service 实现三种用户表态:涟漪(轻量响应,类似「懂了/被触动」)、证言(深度证词,实名背书)、礼赞(可量化的赞许 + 可附金票)。这三个协议被 content-review、recommendation、honor 三个服务消费,构成「信用引擎」——不是点赞数,而是被治理过的可信表态。

06

TAF 价值标签:被 catalog 反向调用

value-tag-service 提供 TAF(Truth / Aesthetics / Future)标签语言定义,既给内容审核用,又给 wabifair 的 catalog-service 调用——商品和内容用同一套 tags / attributes / filters。同标签组的 AI 生成内容可缓存复用(同 embeddingKey / cacheKey),大幅降低重复推理成本。

07

内容审核 + 启动顺序约束

content-review-service 同时承载内容审核(TAF Filter + AI 预检)和管理面 API,管理后台统一走 `/api/v1/admin/*`。启动顺序硬约束:必须先 core-platform(创建共享网络 + Auth + Gateway),再 rippleclio-content(以 external: true 加入网络),否则跨服务发现失败。

Thinking

设计思路

这里说明为什么这样做,而不是只列出做了哪些动作。

「艺术创作平权」是产品命题,不是修辞

不是「让创作者赚钱」——是「让被传统流量分配机制忽视的创作维度(摄影/编剧/音乐/剪辑)各自被金票看见」。共创金库 + 共创分账 10–20% 按契约自动分,把「作品署名」从「封面挂名」升级为「账务可追溯」。这条命题驱动了 creation-service / ticket-service / revenue-share 三个服务的存在。

推理就近、不出网:Ollama 容器内是「主权」选择

完全可以接 OpenAI / Anthropic API,但那让所有用户数据(笔记 / 视频元信息 / 知识库)通过外部 LLM。这里选择 Ollama(qwen2.5:3b)在容器内推理:延迟更高、能力更弱,但数据不出网——这对「个人知识库 + 内容信用」是结构性选择,不是性能选择。

pgvector 是「嵌入数据库」的最便宜方案

不上 Pinecone / Weaviate / Milvus 这类专门向量库,因为 PostgreSQL 已经在那里(主库 / 业务库)。pgvector 让「向量」和「业务表」在同一事务里读写,recommendation / knowledge / value-tag 三个场景的查询都走 SQL,运维成本几乎为零。专门向量库的「高性能」在 MVP 阶段未必体现价值,但运维负担是确定的。

金票 ≠ 点赞:付费成本筛选真实支持

传统点赞 / 投币机制的根本问题是「零成本表态」——水军刷量在零成本下不可控。金票把「投票」和「付费购买」绑定,刷一个赞要先掉出真金白银买关联商品。这不是营收手段,是「信号筛选」——数字小但每一个都真实,可量化也可用于分账。

Agora 三协议:不是互动,是被治理的可信表态

涟漪 / 证言 / 礼赞 看起来像点赞 / 评论 / 打赏,但底层数据模型不同:涟漪要求轻量、不署名;证言要求实名背书、可追溯;礼赞要求附金票、可量化。三层各自被 content-review / recommendation / honor 不同服务消费——同一个数据通路里,既有「流量信号」,也有「信用证据」,还有「账务凭据」。

启动顺序硬约束 = 服务边界硬约束

规则:必须先 core-platform 再 rippleclio-content。这条规则被写进 README 和 scripts/dev_up.sh。这种「顺序硬约束」本身是种治理:它强迫所有人承认 core-platform 是「基础设施层」,rippleclio-content 是「业务层」。模块化的「基础设施 vs 业务」边界在启动顺序里就被划清楚。

Result

交付与结果

交付内容
  • 12 个 Go 服务(video / creation / social / ticket / honor / agora / knowledge / recommendation / content-review / live / value-tag / worker)+ 0048+ DB 迁移
  • 容器内 Ollama(qwen2.5:3b)本地 LLM 推理 + pgvector 向量检索(嵌入式推荐 + 个人知识库 + value-tag 邀供调)
  • 共创金库 + 金票 / 艺术票 / 投票管理 + 荣誉体系 / 排行榜 / 称号(R 星三星+)
  • Agora 信用引擎:涟漪 / 证言 / 礼赞 三个交互协议 + TAF 价值标签服务(被 catalog 反向调用)
  • 前端两端:观众/创作者 web(:5173,Radix UI + hls.js + tanstack/react-virtual + recharts)+ 运营审核 admin-console(:5174)
项目结果
  • 推荐/标签全走容器内 Ollama,不依赖任何外部 LLM API,用户数据不出容器边界
  • 金票机制把「购买」和「投票」绑定,付费成本筛选 + 杜绝水军 + 真实支持度可量化
  • TAF 价值标签让「内容」和「商品」用同一套标签语言匹配,自然联动不是强插入
  • 0048+ 个 DB 迁移全部幂等(IF NOT EXISTS / CREATE OR REPLACE)+ outbox 可靠事件,远超初版 0001–0010 规划