3.7 KiB
3.7 KiB
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。