107 lines
7.6 KiB
Markdown
107 lines
7.6 KiB
Markdown
# 用户口径追加 · 「账号」是两个概念（2026-10-10 07:46）
|
||
|
||
> 用户原话：「这个账号说的是 内容账号 还是 三方平台的账号，这个事两个概念」。
|
||
> 本份只记**现状核实 ＋ 两个概念的分野 ＋ 可选修法**，⛔ 不动 ②段文档、⛔ 不动原型。
|
||
|
||
---
|
||
|
||
## 〇、用户已给的定义（2026-10-10 07:47，逐字）
|
||
|
||
**用户原话**：「内容账号管的是内容属性（主要是账号设定 内容做成什么样），平台账号应该是 发布的渠道三方平台账号 用户发布具体内容」。
|
||
|
||
拆开是两条定义：
|
||
|
||
- **内容账号** ＝ 管**内容属性**的 —— 主要是**账号设定**（内容做成什么样）。⇒ 定位、风格、受众、偏好与红线、长期记忆都属于"内容属性"；**平台不属于它**。
|
||
- **平台账号** ＝ **发布的渠道** —— 三方平台上的账号，**发布具体内容用的就是它**。⇒ 登录态、授权属于它。
|
||
|
||
⇒ **「渠道」这个词从此有确定含义 ＝ 平台账号**（不再用"账号 × 平台"这种组合说法）。
|
||
|
||
**由此定下三件**：
|
||
|
||
1、`2b-界面布局-新版.md` 行 278 画像六维里那一维「**平台**」**从内容账号身上拿掉**（它不属于内容属性）。
|
||
2、**登录态归平台账号**（能不能发出去是它的事），内容账号不带它。
|
||
3、`2a-产品功能-新版.md` 行 180 的 F7 守卫那句「每个版本必须绑一个账号 ＋ 一个平台」，"一个平台"改成"**一个平台账号**"；发布记录里说的"渠道"同样指平台账号。
|
||
|
||
**建模方式（我已定，可推翻）**：**不加对象** —— 平台账号做成**内容账号下的子项清单**（一个内容账号 1 → N 个平台账号，每个带「平台 ＋ 登录态 ＋ 授权状态」）。
|
||
|
||
理由：对象数不变（仍是 11 个），不用重定与版本／发布任务／发布记录的边界，也不用重过 20 条流转；而"一个人设多个平台号"照样表达得出来。若改成两个独立对象，字典要 11 → 12、20 条流转要重过一遍，换来的只是概念上更整齐。
|
||
|
||
---
|
||
|
||
## 〇之二、投放时怎么落（用户 2026-10-10 07:48 推论）
|
||
|
||
**用户原话**：「所以一个内容账号 投放时应该有多个平台账号用于分别投放」。
|
||
|
||
**确认**：一个内容账号在**投放时**对应**多个平台账号**，每个平台账号**分别投放**。
|
||
|
||
**这句落地要拆成两步**（现版 F7 已有前半，后半要按新口径改）：
|
||
|
||
1、**展开**：一条内容（母版）按目标**平台账号**各自出一版 —— 现版 F7 就是这么设计的（流转是 `母版 → 已展开（多版本）→ 逐版确认 → 就绪`），只是它写的是"账号 × 平台"，按新口径要改成"**按平台账号展开**"。
|
||
2、**分别投放**：每个平台账号发它自己那一版 ⇒ 每个平台账号各产生一条发布记录。
|
||
|
||
⇒ **"分别投放"是靠"分别成版"实现的**，不是靠"一个版本同时发多处"。由此顺出三件：
|
||
|
||
- F7 的展开单位改成**平台账号**（一个内容账号下的每个平台账号各一版）。
|
||
- "一版一路"因此天然成立 ⇒ 发布记录的"渠道"由版本唯一确定。
|
||
- 于是「`PublishRecord` 要不要加渠道字段」这条**按不加处理**：保持现状，只在 `2a-产品功能-新版.md` 的 F13 补一句「一版一路」把它显式写出来。
|
||
|
||
---
|
||
|
||
## 一、先答：现版说的是哪个？—— 两个混在一起了
|
||
|
||
现版 `Account` 的三处写法互相打架：
|
||
|
||
1、**对象字典**（`2a-产品功能-新版.md` 行 50）：`Account` 账号 ＝「**矩阵里的一个账号**，带它的画像与长期记忆」，产生于 P6 —— 这句读起来是**内容账号**（我们运营的主体）。
|
||
2、**画像六维**（`2b-界面布局-新版.md` 行 278）：定位、**风格**、受众、**平台**、偏好与红线、长期记忆 —— **「平台」是六维之一**，也就是把"平台"当成了**账号的一个属性**。
|
||
3、**F7 的守卫**（`2a` 行 180）：「每个版本必须绑**一个账号 ＋ 一个平台**」—— 账号与平台写成**两栏独立**，读起来平台不是账号的属性，而是另一个正交维。
|
||
|
||
另外，全篇 grep「平台号／平台账号／登录」**零命中** —— 现版**根本没有"平台侧的号"这个概念**，也**没有"登录态"**（只有 F5 里一句"账号密钥"）。
|
||
|
||
⇒ 结论：现版的 `Account` **既不是纯内容账号**（它带"平台"这一维），**也不是平台账号**（它带人设画像与长期记忆，却又没有登录态）。两个概念被压进了一个对象。
|
||
|
||
---
|
||
|
||
## 二、两个概念到底差在哪
|
||
|
||
**一、内容账号**（我们运营的主体，例："某某说职场"这个人设）
|
||
- 带的是：定位、风格、受众、偏好与红线、长期记忆；
|
||
- **本质跨平台** —— 同一个人设在多个平台运营是常态；
|
||
- **不含登录态**（登录态不属于人设）。
|
||
|
||
**二、三方平台账号**（平台侧的号，例：抖音上的某个号、B 站上的某个号）
|
||
- 带的是：**登录态／授权**（能不能发出去，第一个拦路虎）；
|
||
- **天然绑一个平台** —— 一个抖音号不可能是 B 站号；
|
||
- 是一个人设在某个平台上的落地。
|
||
|
||
**两者是一对多**：一个人设 → N 个平台账号。
|
||
|
||
⇒ 这也**正是"账号带不带平台"那个矛盾的根因**：两个概念不分，怎么写都别扭。所以上一轮那条待拍板（"`Account` 带不带平台"）**问错了层面** —— 它不是"带不带一个字段"的问题，是"一个对象装了两件事"的问题。
|
||
|
||
---
|
||
|
||
## 三、可选修法（三条，取向不同）
|
||
|
||
**候选 A：把两个概念分成两个对象。**
|
||
`Account` 只做内容账号（人设），另立一个对象表示平台账号（带平台 ＋ 登录态 ＋ 授权）。
|
||
- 优点：概念最干净，一个人设挂多个平台号天然表达；发布记录说的"渠道"正好指平台账号。
|
||
- 缺点：对象字典 11 → 12，要重定与 `ContentVersion`／`PublishTask`／`PublishRecord` 的边界，20 条流转契约要重过。
|
||
|
||
**候选 B：不加对象，平台号做成账号下的子项清单。**
|
||
`Account` 仍是内容账号（画像六维里**去掉「平台」这一维**），它下面挂一串平台号，每个平台号带「平台 ＋ 登录态 ＋ 授权状态」。
|
||
- 优点：对象数不变，仍能表达"一个人设多平台号"；版本绑的"账号 ＋ 平台"自然落成"账号 ＋ 它的某个平台号"。
|
||
- 缺点：`Account` 的内部结构变复杂（从平面属性变成带子清单），画像的"一个账号一份"要重新措辞成"一份账号画像 ＋ N 份平台接入状态"。
|
||
|
||
**候选 C：维持现状（画像里保留「平台」这一维）。**
|
||
- 优点：零改动。
|
||
- 缺点：等于规定"一个账号只能有一个平台" ⇒ 一个人设做多平台就得建多个账号，画像与长期记忆**不共享**；而 F7 又写着账号与平台两栏独立，两处继续互相打架。
|
||
|
||
---
|
||
|
||
## 四、这件事牵动谁
|
||
|
||
- **P6 账号页**：画像六维要不要变成"人设五维 ＋ 平台接入清单"。
|
||
- **P5 投放页**：「目标选择」是先平台后账号（A／B 都能做到），还是照现状平铺。
|
||
- **F7 母版展开**：「账号 × 平台」这个组合到底是不是合法输入 —— 概念分开之后，它变成"账号 × 该账号下的平台号"，非法组合天然不存在。
|
||
- **`PublishRecord`**：它说的"渠道"到底指平台账号还是平台 —— 概念定了一并清楚。
|
||
- **登录态**：现版全篇没有这个概念；平台账号（或平台号子项）必须带它，否则 P5 发不出去这件事没有拦路的地方。
|