32 lines
3.7 KiB
Markdown
32 lines
3.7 KiB
Markdown
# 2026-10-10 工作日志
|
||
|
||
## 07:36 · 核实 social-auto-upload 分析目标完成情况
|
||
|
||
- 目标「分析 social-auto-upload 项目，用于投放页与发布对象的判断」**已完成**（检查会话第 42 棒判：三条判据全过）。
|
||
- 产物：`执行会话/目标-分析social-auto-upload项目，用于投放页与发布对象的判断-0ec0a7/social-auto-upload 分析与对照.md`（30 045 B，10-09 23:02），六项各有代码出处（平台清单／发布抽象／账号与登录态／定时／失败重试／技术栈）。
|
||
- **核心结论**：① 它的数据层**只有两张表**（账号、素材文件），**没有发布记录表** ② 它**没有「渠道」对象**（两个正交输入：平台单选 ＋ 账号多选，账号本身内含平台）③ **「不加发布事件」站得住** —— 我们"一个目标一版 ＋ 记录绑版本"已是渠道级，它连发布记录都没有、拿它验这件事样本量为零 ④ 但照出一处**精度问题**：若一个版本发多渠道，"一版一记录"分不清渠道 ⇒ 真要补是**给记录加字段**或**把"一版一路"写死**，⛔ 不是加对象。
|
||
- **三条待拍板**（已给用户）：账号带不带平台（倾向 A 自带）／要不要做定时（倾向 A 不做、B 记 `Deferred`）／`PublishRecord` 要不要渠道字段（倾向 B 写死"一版一路"）。
|
||
|
||
## 07:46 · 用户指出：「账号」是两个概念（内容账号 vs 三方平台账号）
|
||
|
||
**用户原话**：「这个账号说的是 内容账号 还是 三方平台的账号，这个事两个概念」。
|
||
|
||
**核实结论：现版把两个概念混在一起了** ——
|
||
- 对象字典写 `Account` ＝「**矩阵里的一个账号**」（读起来像内容账号）；
|
||
- 但**画像六维里含「平台」**（`2b` 行 278：定位／风格／受众／**平台**／偏好与红线／长期记忆）⇒ 把平台当成账号的一个属性；
|
||
- F7 守卫又写「一个账号 ＋ 一个平台」两栏独立（`2a` 行 180）⇒ 把平台当另一个正交维；
|
||
- 全篇 grep「平台号／平台账号／登录」**零命中** ⇒ 现版**既没有"平台侧的号"这个概念，也没有"登录态"**（只有 F5 里一句"账号密钥"）。
|
||
|
||
⇒ **两个概念**：**内容账号**（我们运营的主体/人设，带画像与长期记忆，**本质跨平台**，不含登录态）vs **三方平台账号**（平台侧的号，带**登录态/授权**，**天然绑一个平台**）。两者**一对多**（一个人设 → N 个平台号）。
|
||
|
||
🔴 **这推翻了上一轮那条待拍板的层面**：「`Account` 带不带平台」问错了 —— 根子不是"带不带一个字段"，而是"**一个对象装了两件事**"。
|
||
|
||
**三条修法（已写进文档，待用户定）**：
|
||
- A **分成两个对象**（`Account` 只做内容账号，另立平台账号对象带平台＋登录态）—— 概念最干净，代价是对象 11→12、20 条流转契约重过；
|
||
- B **不加对象**，平台号做成 `Account` 下的**子项清单**（画像六维去掉"平台"这一维）—— 对象数不变、仍能表达一人设多号，代价是 `Account` 内部结构变复杂；
|
||
- C **维持现状** —— 等于规定"一个账号只能有一个平台"，多平台人设要建多个账号、画像与记忆不共享，且与 F7 继续互相打架。
|
||
|
||
**牵动面**：P6 账号页（画像六维要不要拆成人设五维＋平台接入清单）／P5 投放页「目标选择」／F7 母版展开（「账号 × 平台」是不是合法输入）／`PublishRecord` 说的"渠道"指谁／登录态（现版全篇没有这个概念）。
|
||
|
||
**产物**：`执行会话/目标-分析social-auto-upload项目，用于投放页与发布对象的判断-0ec0a7/用户口径追加-账号是两个概念.md`。
|