4.6 KiB
用户口径追加 · 「账号」是两个概念（2026-10-10 07:46）
用户原话：「这个账号说的是 内容账号 还是 三方平台的账号，这个事两个概念」。 本份只记现状核实 ＋ 两个概念的分野 ＋ 可选修法，⛔ 不动 ②段文档、⛔ 不动原型。
一、先答：现版说的是哪个？—— 两个混在一起了
现版 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 发不出去这件事没有拦路的地方。