7.6 KiB
用户口径追加 · 「账号」是两个概念（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 发不出去这件事没有拦路的地方。