docs: 产品共识 CONTEXT 与四篇 ADR
This commit is contained in:
@@ -0,0 +1,38 @@
|
||||
# 0001 合规定位:申报为社交 App,不走游戏版号
|
||||
|
||||
**Status**: accepted (2026-10-03)
|
||||
|
||||
## 背景
|
||||
|
||||
本产品是一个陌生人交友匹配 app,但其前端体验和冷启动载体是一个互动叙事产品
|
||||
(内部称"影游":漫画级静态美术 + 关键节点预生成视频 + 对话框选项 + 语音讲述)。
|
||||
它看起来、玩起来都像游戏,因此在中国大陆上架时存在一个根本性的分类分叉:
|
||||
申报为**游戏**还是**社交 app**。这个分叉决定监管路径、变现方式和内容口径,
|
||||
且上线后几乎不可逆。
|
||||
|
||||
## 决定
|
||||
|
||||
申报为**社交/交友 app**。影游在产品内和所有宣传口径中称为"互动剧情测评",不使用
|
||||
"游戏"字样。变现从第一天起按会员订阅/增值服务设计(对标探探/Soul),
|
||||
不做任何游戏内购(卖道具、卖体力、抽卡等)。
|
||||
|
||||
## 备选方案
|
||||
|
||||
- **申报为游戏**:需要游戏版号。版号审批排队以年计,基本不对小团队开放,
|
||||
恋爱/相亲题材过审难度极高。此路对本产品不通,被否决。
|
||||
|
||||
## 理由
|
||||
|
||||
1. 版号路线时间成本和不确定性是小团队无法承受的;
|
||||
2. 社交 app 路径的合规义务(实名认证——交友类强制、ICP 备案/许可、内容审核机制、
|
||||
未成年人隔离)虽然繁重,但都是可执行的工程问题;
|
||||
3. 变现若走游戏内购,会被监管认定为游戏行为,摧毁社交 app 的申报口径,
|
||||
因此变现设计必须与身份一致。
|
||||
|
||||
## 后果
|
||||
|
||||
- 应用商店上架类目为社交,需准备实名认证和内容审核能力;
|
||||
- 影游内容(考古探险题材)在合规口径上主角是考古/文物保护方,不是盗墓;
|
||||
- 剧本和运营文案需持续遵守"互动剧情测评"口径,避免任何"游戏化付费"表述;
|
||||
- 该定位同时构成对竞品(青藤之恋等"学历认证+自填资料"产品)的差异叙事:
|
||||
**实测 vs 自报**——本产品的人格数据来自互动剧情中的行为实测。
|
||||
@@ -0,0 +1,40 @@
|
||||
# 0002 匹配建模:心动度有向、契合度无向、匹配 = 双向心动过阈值
|
||||
|
||||
**Status**: accepted (2026-10-03)
|
||||
|
||||
## 背景
|
||||
|
||||
产品的核心动作是给用户两两评估"这两个人该不该互相推荐"。评估由 Jev
|
||||
(TypeSafe AI 的 System One 模型,见 ADR-0003)完成:输入两个用户的资料与行为数据
|
||||
作为"状态",输出类型化分数。建模时必须回答一个问题:A 对 B 的合适程度和 B 对 A 的
|
||||
合适程度是不是同一个分数——这张关系图是有向的还是无向的?
|
||||
|
||||
## 决定
|
||||
|
||||
拆成两个概念,分别建模:
|
||||
|
||||
- **心动度 (Attraction)**:**单向、有向**。A 看到 B 的资料后产生兴趣的程度。
|
||||
吸引天然不对称(A 觉得 B 有魅力不代表 B 看得上 A),A→B 与 B→A 是两个独立分数。
|
||||
- **契合度 (Compatibility)**:**双向、无向**。两人长期相处的关系质量预期,
|
||||
本质上对称(性格互补还是冲突不取决于谁先看到谁)。用途是向用户解释推荐理由
|
||||
("你们都是安全型依恋,冲突风格互补"),不是匹配的门槛。
|
||||
|
||||
**匹配 (Match) 的成立条件:双向心动度都超过阈值。**
|
||||
|
||||
实现要点:Jev 一次请求可以携带多个问题并行回答、输出免费,因此一次调用即可
|
||||
同时问"A 对 B 的心动度"和"B 对 A 的心动度"(可加契合度),有向建模不增加调用成本。
|
||||
|
||||
## 备选方案
|
||||
|
||||
- **单一对称分数**("这两人配不配,一个数"):被否决。它会掩盖单向吸引
|
||||
(A 痴迷 B、B 无感的组合会得到一个中间分而被错误推荐),而线下交友的真相
|
||||
恰恰是吸引不对称;Tinder 的双向右滑机制本质就是求两条有向边同时存在。
|
||||
- **只建模心动度**:被否决。缺少长期关系质量信号,无法向用户给出有说服力的
|
||||
推荐理由,而"解释力"是本产品对竞品的核心差异之一。
|
||||
|
||||
## 后果
|
||||
|
||||
- 数据模型需按**有序对**存储心动度(或存一次调用返回的双向结果);
|
||||
- 用户可见的人格勋章(Badge)只是营销包装,**不是匹配输入**——匹配输入是
|
||||
底层行为数据与维度画像,二者必须隔离,防止用户"装修人设"污染匹配信号
|
||||
(见 ADR-0004)。
|
||||
@@ -0,0 +1,57 @@
|
||||
# 0003 AI 分工:SQL 硬过滤 + Jev 两两打分 + LLM 只做剧情
|
||||
|
||||
**Status**: accepted (2026-10-03)
|
||||
|
||||
## 背景
|
||||
|
||||
产品可用的 AI 能力有三类,成本和能力画像完全不同:
|
||||
|
||||
- **Jev**(TypeSafe AI 的 System One 模型):不生成文本;输入非结构化状态 +
|
||||
类型化问题(choice/score/概率),一次前向传播并行回答全部问题,返回带校准
|
||||
置信度的结构化答案。中位延迟约 100ms,输出 token 免费,输入极廉价。
|
||||
- **前沿 LLM**(System Two):能生成文本(剧情、追问、画像报告),但慢且贵。
|
||||
- **传统手段**:SQL 过滤、embedding 向量相似度,成本近乎为零。
|
||||
|
||||
产品的 AI 负载有三处:注册/叙事(生成剧情与个性化内容)、人格实测(从行为数据
|
||||
产出维度画像)、匹配(海量两两评估)。分工错误会让成本或延迟爆炸。
|
||||
|
||||
## 决定
|
||||
|
||||
**三层分工,各就各位:**
|
||||
|
||||
1. **SQL 硬过滤(免费,先行)**:城市、年龄、性别、性取向等硬约束用数据库
|
||||
谓词过滤,砍掉 90%+ 候选对。这些字段在"穿越者身份登记"的开局流程中
|
||||
自然采集。绝不用 AI 判断硬约束——那是把最贵的资源花在最不需要智能的地方。
|
||||
2. **Jev 两两打分(核心阵地)**:对过滤后的候选池,状态 = 双方资料 + 行为轨迹,
|
||||
一次调用并行问"A→B 心动度 / B→A 心动度 / 契合度"(见 ADR-0002)。
|
||||
候选池较大时分批调用(如每批 200 个候选,数千人分多批)。
|
||||
Jev 同时承担人格实测:对用户行为轨迹按 7 个维度(依恋类型、冲突处理风格、
|
||||
价值观与人生优先级、情绪稳定性、风险偏好、文化底蕴、择偶偏好)打分,
|
||||
其**置信度用于自适应补测**——证据不足的维度在后续章节动态插入对应支线剧情。
|
||||
3. **LLM 只做叙事,且受三通道边界约束**:
|
||||
- 通道 1·情绪配色:LLM/Jev 只做预写场景变体的**选择**,不生成主线内容;
|
||||
- 通道 2·幻境机制:LLM 可生成内容(用户记忆意象的幻境呈现、NPC 追问),
|
||||
这是生成被允许的唯一通道;
|
||||
- 通道 3·档案馆:用户讲述内容的沉淀与展示。
|
||||
所有个性化内容在**章节之间预生成**,绝不在游玩过程中实时生成;
|
||||
生成失败回退到通用版本。
|
||||
|
||||
## 备选方案
|
||||
|
||||
- **embedding 粗筛 + Jev 精排**:被产品负责人否决,倾向"尽量全用 Jev"。
|
||||
折中结果:硬过滤层(SQL)不可省略,但语义层全部交给 Jev,接受分批调用的
|
||||
工程复杂度。
|
||||
- **Jev 直接对全量用户两两打分**:被否决。N 个用户每人刷新一次是 O(N²) 调用,
|
||||
1 万用户一轮全量打分即上亿次调用,即使单价极低也不可持续;且绝大多数配对
|
||||
被硬约束排除,根本不需要判断。
|
||||
- **LLM 实时生成剧情**:被否决。延迟、成本、角色一致性和内容安全均不可控。
|
||||
主线骨架(转折、选择点、结局树)必须全部预写——这既保质量,也保不同用户
|
||||
行为数据的可比性(实测框架的底线)。
|
||||
|
||||
## 后果
|
||||
|
||||
- 匹配成本随**过滤后池子大小**增长,而非用户量的平方;
|
||||
- 剧本生产流程必须交付"完整故事框架"(整体弧线、选择点地图、维度覆盖表、
|
||||
每选择点的预写变体),然后才逐章写作;
|
||||
- 人格画像、匹配打分、自适应支线路由都依赖 Jev 的结构化输出与置信度,
|
||||
Jev 是不可替换的单点依赖,需在架构上接受这一点。
|
||||
@@ -0,0 +1,61 @@
|
||||
# 0004 数据规则:一次告知、历史不可涂改、可重玩时间衰减
|
||||
|
||||
**Status**: accepted (2026-10-03)
|
||||
|
||||
## 背景
|
||||
|
||||
产品的匹配质量完全依赖用户数据的真实性:剧情中的选择行为、语音讲述的个人经历
|
||||
与记忆。两类风险威胁数据质量与合规:
|
||||
|
||||
1. **表演污染**:用户一旦知道"这会影响匹配",就有动机按理想人设作答
|
||||
(社会赞许性偏差),把行为数据退化为自填问卷;
|
||||
2. **合规**:人格画像数据用于伴侣推荐,属于《个人信息保护法》下需明确告知并
|
||||
取得同意的处理行为;语音包含声纹(生物识别信息),个人经历属敏感个人信息。
|
||||
|
||||
## 决定
|
||||
|
||||
**告知规则**
|
||||
- 注册时告知一次:"剧情选择将用于为你推荐伴侣",开场提示一次"按本心选,
|
||||
没有对错",之后绝不在任何选择点/讲述点反复提醒。
|
||||
- 理由:告知是合规义务也是卖点("每个选择都让 AI 更懂你"是留存钩子);
|
||||
但反复提醒会激活表演欲。防表演的底线靠设计承担——选项无社会赞许方向、
|
||||
行为数据(是否读完描述/对话)、一致性检验(表演人格与行为人格的撕裂即信号)、
|
||||
游戏机制直接奖励"具体"(真实记忆自带细节,编造必然空泛)。
|
||||
|
||||
**不可涂改规则**
|
||||
- 不允许单独编辑任何历史选择或讲述。一旦允许编辑,用户看到自己的画像/勋章后
|
||||
回头修改,行为数据即降级为"装修人设"的自报数据,一致性检验同时失效。
|
||||
|
||||
**重玩与时间衰减**
|
||||
- 章节可重玩。重玩产生**新的行为轨迹**而非修改历史;Jev 始终看到完整历史,
|
||||
按时间衰减加权,最近轨迹权重最高(人会变,画像应当漂移)。
|
||||
- 初刷与重玩区别对待:初刷视为本能,重刷视为经营,权重与解读不同。
|
||||
- "我变了/选错了"的正当需求由重玩满足,不由编辑满足。
|
||||
|
||||
**敏感数据处理**
|
||||
- 语音管线为"**特征提取后即焚**":音频只存在于处理窗口内,删除前提取两类产物——
|
||||
(a) ASR 转写文本;(b) **韵律/声学特征**:语速、停顿分布、音高变化范围、能量、
|
||||
填充词频率、情绪唤醒度、笑/叹息等副语言信号。这类特征与人格相关
|
||||
(如外向性与语速/能量、神经质与音高波动在语音心理学文献中有对应关系),
|
||||
且以不可逆的统计向量形式存储,**不含声纹**(不可用于身份识别、不可还原声音)。
|
||||
- 韵律特征与转写文本一起作为状态输入 Jev;文本内容与语气特征的一致性本身也是信号
|
||||
(嘴上说释然、声音在抖)。韵律特征同时服务于幻境的情绪配色(ADR-0003 通道 1)。
|
||||
- 原始音频的唯一例外:用户主动 opt-in 保留某段做"声音名片"。
|
||||
- 注册时的告知(见上)须覆盖"提取语音特征用于性格分析"。
|
||||
- 用户的记忆与经历内容**仅作模型输入**,永不原样展示给匹配对象;
|
||||
档案馆"记忆展厅"向匹配对象开放需用户逐次明确授权。
|
||||
- 每次语音讲述点的追问至多 1-2 句(防审讯感);"记不清了"是合法回答。
|
||||
|
||||
## 备选方案
|
||||
|
||||
- **允许编辑选择**:被否决,理由见上(数据真实性是本产品的命脉,
|
||||
"实测 vs 自报"是对竞品的全部差异)。
|
||||
- **全程反复提示"请诚实"**:被否决。效力低(提示值 10 分,选项设计值 90 分),
|
||||
且持续打断沉浸感。
|
||||
|
||||
## 后果
|
||||
|
||||
- 选择与讲述事件存储必须是 append-only,禁止 update 路径;
|
||||
- 注册流程需包含告知与同意的 UX 与存证;
|
||||
- 章节重玩是正式功能而非边缘 case,匹配与画像管线必须支持多轨迹加权;
|
||||
- 语音管线默认"特征提取后即焚",原始音频存储是显式 opt-in。
|
||||
Reference in New Issue
Block a user