contentm_agent/docs/pm/mcn-shortvideo-agent/prd/2a-产品功能.md

2a 产品功能（新版 V4）

项目 slug：mcn-shortvideo-agent　｜　②段第 1 子步，产出 prd/2a-产品功能.md 本版在 V3 基础上把用户 2026-10-09～10 陆续下达的八条口径落进正文（归属判据换「一类事情放同一页」、资产入库不限页、选题库按分类容纳、记录与对账属复盘不拆、一条内容对应多个发布渠道、账号分内容账号与平台账号两个概念、投放页目标选择两级、F7 展开单位改平台账号 ＋ F13 补「一版一路」）。V3 本身是在 V2 基础上按用户口径同步功能归属（导航一层七项、P8 并入复盘、功能与板块一一对应）；V2 是重做，不是润色；上游决策见 GPT-规划意见与采纳决策.md（2026-10-08 23:54，采纳 24／部分采纳 3／不采纳 1）。 V4 的两份依据（口径原文）：用户口径裁决-5条回应.md（2026-10-09）、用户口径追加-账号是两个概念.md（2026-10-10）。 只读输入：①段 1a-需求文档.md（docs/pm/mcn-shortvideo-agent/research/）、1e-使用场景.md（八条用户故事）、②棒 GPT 意见与采纳决策、第①棒 产品规划/现状梳理-板块·功能·操作路线.md、V2 版 2a-产品功能-新版.md／2b-界面布局-新版.md。 判据源：stage-requirements/references/create-prd.md（功能清单）＋ references/state-machine.md（六项治理，落在功能条目内）。 本份只回答「做哪些功能、不做哪些、每条什么优先级、功能归谁」。页面骨架在 2b-界面布局-新版.md。 ⛔ 全文零视觉词 —— 配色 / 字体 / 间距 / 组件样式 / 动效，一个都没出现。 🔴 本版没加功能、没改优先级：功能清单仍是 14 条（F1–F14），编号一个没动。改的是判据、对象定义与三条功能的措辞。

---

〇、一屏结论

V4 最要紧的一句：功能没加没减，改的是判据、对象定义与三处措辞。 八条口径逐条落到 §一／§二／§三，页面侧同步落到 2b 与原型。

沿用上一版（V3）的结论（本版没推翻）：

• 功能清单还是 14 条（F1–F14），编号一个没动（沿用 1a §六，1e §四 反向核过）。
• 核心业务对象字典是 11 个对象 —— 本版仍是 11（账号只拆概念不拆对象，见 §二）。
• 两条功能口径写实：F11 标「待验证／非主链能力」；F12 标 P2／Deferred。
• 三条更结构化的建议（②段要不要并成一份九节的架构基线、六种流转类型要不要进正文、两条新增流转）没有在做/不做上自作主张 —— 先按 GPT 的方向落地，同时在 §九 单列交回用户。

V4 本轮追加（2026-10-10，用户八条口径）：

• 功能归属的判据换成「一类事情放同一个页面」（§一 第 2 条重写）。拿它复核七页：页集合不动，七页各自都是「一类事」。
• 资产入库不限页：Asset 的「产生位置」由 P3 改成「P2／P3／P4 均可」，并写清「一个对象只有一处产生」管的是唯一权威数据，⛔ 不是写入动作的地点（§二 对象字典 ＋ §一 第 3 条后新增一句 ＋ §三 F4）。
• 选题库容纳「对选题有帮助的任何信息」，靠分类区分：随手记仍落选题库，⛔ 不新增「待整理」状态、⛔ 不做多去向（§三 F2）。分类维度由本版给出方案（进度 × 类型两个正交维度），落到 2b §五 P2。
• 记录与对账属复盘：这一类事就是「发布之后看数据与看收入」，⛔ 不拆页、⛔ 不分区（§三 F12／F13 与 2b §五 P7）。
• 一条内容对应多个发布渠道：PublishTask 的定义由「含目标账号与平台」改成「含发布渠道」（渠道 ＝ 平台账号）（§二 对象字典）。
• 账号分两个概念：Account 改写成内容账号（管内容属性：账号设定），平台不属于它；平台账号 ＝ 发布渠道（带平台 ＋ 登录态 ＋ 授权状态），做成内容账号下的子项清单，不加对象（仍是 11 个）（§二 对象字典 ＋ §三 F9）。
• F7 的展开单位改成平台账号（一个内容账号下的每个平台账号各一版，守卫同步改「内容账号 ＋ 它的一个平台账号」）；F13 补「一版一路」（一个渠道只对应一个版本 ⇒ 发布记录的渠道由版本唯一确定，PublishRecord 不加渠道字段）（§三 F7／F13）。
• 定时发布挂起：用户 2026-10-10 07:56 逐字「后续具体做投放功能的时候在说」⇒ 本版不为它加任何功能条目与字段，只登记在 §九（§九 第 7 项）。

V3 追加（2026-10-09 用户令）：

• P8 记录与对账整页并入 P7 复盘台，页 ID 里不再有 P8；F12、F13 的归属页随之由 P8 改 P7（§三 F12／F13、§四 总表、§二 对象字典）。
• 导航改一层七项（首页／选题／创作／投放／复盘／账号／资产），项与页的对应见 2b §三。
• 功能与板块的对应写成可机检关系（原型 FN_HOME／FN_MAP，自检双向核），判据仍是「这个功能主要创建或改变哪个核心业务对象」。功能清单仍是 14 条，编号一个没动。

---

一、这份文档怎么组织（四条判据，全篇照这个来）

第 1 条 · 功能按使用场景组织，不按页面。 沿用 2026-10-06 的用户定案。一条场景下可以挂跨好几个页面的功能。理由不是习惯：按页面组织会把跨页场景切碎，也跟①段《使用场景》对不上。

第 2 条 · 归属看「这是哪一类事」，同类事放同一页。（🔴 2026-10-09 用户口径换的判据，取代上一版「只看核心业务对象」） 判据一句话：这个功能干的是哪一类事情，就和做同一类事情的其它功能放在同一页。 用户原话：「应该是一类事情在一个页面 比如 找选题和做选题就应该在一起 都是选题相关的事情」。

拿它复核七页，页集合一个没动：

页	这一页收的是哪一类事	复核结果
P1 矩阵总览	今天先处理哪件 —— 跨账号的待办与概览	一类（一名内容负责人一眼扫全局）
P2 选题雷达	找选题、拆解选题、把选题推进下一步 —— 选题相关的事	一类（找与做同页，正是用户举的例子）
P3 资产库	资产条目的统一管理（分类分区／检索／维护／引用）	一类（管资产）
P4 创作台	一条内容从选题走到成稿，再展开成多平台账号版本	一类（做内容）
P5 发布中心	这批内容怎么发出去：过闸、逐版确认、留痕	一类（发出去）
P6 账号画像	内容账号的设定与它的平台账号（发布渠道）	一类（管账号）
P7 复盘台	发布之后看数据与看收入 —— 复盘、发布记录、溯源、对账、商单收支	一类（用户原话：发布的目的就是看数据和看收入）

⚠️ 判据落地时仍要看核心业务对象 —— 对象是「同一类事」的落地手段，不是判据本身。 理由：一类事往往就是围着同一个对象转（选题相关的事产 Topic、发布相关的事产 PublishTask／PublishRecord、账号相关的事产 Account）。先按「哪一类事」分页，再用「它主要创建或改变哪个对象」逐条钉住归属页，两句话说的是同一件事；分页时以「哪一类事」为准 —— 用户看得见的是事，看不见的是对象。 拿对象那一层再核一遍，本版没有因为换判据而挪页：F7 仍归 P4、F14 仍归 P4、F5 仍归 P5（这三条是 V2 相对 V1 改的，本版沿用）。

第 3 条 · 跨页面只传对象 ID 加必要上下文，不传页面临时状态。 比如 P1 跳 P7，传的是 accountId，不是「刚才点的是哪个账号」这个临时变量。P7 自己拿 accountId 去查它的发布记录与表现数据。 这条治的是现状里两处硬伤（详见 2b-界面布局-新版.md §六）：P1 → P7 传了参数接收方不读（落错对象），P2 → P4 压根不带内容。

第 4 条 · 「一个对象只有一处」管的是权威数据，⛔ 不管写入动作发生在哪一页。（🔴 2026-10-10 用户口径新增，专门堵这一处误读） 一个对象只有一份权威记录、只有一处能改它的权威值；但产生它的写入动作可以在别的页发生。最直接的一例是资产：任何页（P2 的拆解线索、P3 的拆解、P4 的创作沉淀）都可以就地入库，落下来的仍是同一份资产条目，统一由资产库页管。 用户原话：「所有页面有产生资产都可以 随时入库，资产库页是统一管理的地方」。 ⚠️ 别把这条读成「归属页有多个」：归属页按「谁统一管它」定（资产仍归 P3），别的页只是入口。

---

二、核心业务对象字典（11 个）

产品里真正在流动的东西就是这些。每一行写清三件事：它是什么、在哪儿产生、被谁拿走。 🔴 对象数仍是 11 —— V4 把「账号」拆成两个概念，但只拆概念不拆对象：Account 改写成内容账号，平台账号做成它下面的子项清单（1 → N），因此不进这张表、也不算新对象。理由见本节末。

对象	是什么	产生位置	被谁消费
Account 内容账号	管内容属性的主体：账号设定（定位／风格／受众／偏好与红线／长期记忆）。🔴 平台不属于它 —— 它下面挂 1 → N 个平台账号，平台账号是子项、不是新对象	P6	P1、P4、P5、P7
Benchmark 对标号	被盯住的一个对标账号	P2（F1 录入监控名单）	P2
Topic 选题	选题库里的一条信息（⛔ 不止「一条待做选题」），含它的来源与分类（§三 F2）	P2（F1 异常值、F2 选题库、F3 评论洞察）	P4
Asset 资产条目	拆解出来的可复用写法，分角度／结构／开场白／标题四区	🔴 P2／P3／P4 均可（任何页拆出资产都可就地入库；资产库页是统一管理的地方，⛔ 不是唯一入库口）	P4
Content 内容	一条从选题长出来的内容，含它的创作环节位置	P4（F6）	P5、P7
ContentVersion 内容版本	一次改稿或一次多平台账号展开产生的一版	P4（F7、F8）	P5、P7
PublishTask 发布任务	一次「把这些版本发出去」的任务，含发布渠道（渠道 ＝ 平台账号）	P5（过 F5 闸门后）	P7
PublishRecord 发布记录	谁在什么时候确认发了哪一版	P5（F13）	P7
Performance 表现数据	一条内容发出去之后的真实读数	P7（从平台读回，读不到则手工录入）	P1、P6、P7
Review 复盘结论	系统归因加人工裁决后写下的那条结论	P7（F10）	P1、P2、P6
Campaign/Order 商单与收支	一条内容带的商单与钱的口径	P7（F12）	P1、P7

平台账号写在这里说清楚（它是子项，不进上表、不进对象计数）：

• 内容账号 ＝ 管内容属性的（主要是账号设定：内容做成什么样）。定位、风格、受众、偏好与红线、长期记忆都是内容属性；平台不是。
• 平台账号 ＝ 发布的渠道 —— 三方平台上的账号，发布具体内容用的就是它。每条带三样：平台 ＋ 登录态 ＋ 授权状态。
• 两者的关系是一对多：一个内容账号 → N 个平台账号。同一个人设在多个平台运营，靠这条表达。
• 为什么不做成独立对象：做成对象的话对象字典要 11 → 12，还要重定它与 ContentVersion／PublishTask／PublishRecord 的边界、把 20 条流转契约重过一遍；换来的只是概念上更整齐。做成子项清单，对象数不变，照样表达得出「一个人设多个平台号」。
• ⚠️ 由此**「渠道」这个词从此有确定含义 ＝ 平台账号**，⛔ 不再用「账号 × 平台」这种把两个概念拼一起的说法。

三条传递规则（全篇只要写流转就按它写）：

1. 跨页面只传 ID 加必要上下文，不传页面临时状态。
2. 一个对象只有一处权威数据。别处要用，是去消费它，不是各存一份。🔴 这一条管的是权威数据只有一个源，⛔ 不管写入动作发生在哪一页 —— 资产条目可以在 P2／P3／P4 任何一页就地入库（写入动作的地点不限），但它的权威记录只有一份，统一由资产库页管（§一 第 4 条）。
3. 目标页接到 ID 之后必须能自己把状态恢复出来 —— 恢复不出来，说明这个对象的产生位置写错了。

---

三、功能清单（14 条，按场景）

字段从上到下固定八样：功能名 / 来自哪条场景 / 优先级 / 核心业务对象 / 归属页 / 状态流转 / 验收要点 / 跨哪些页面，最后跟一条「治理」。

优先级只给 P0／P1／P2 加一句可复述的判据，⛔ 不填数字（本项目没有任何数据源）。

S1 找选题

F1 对标账号监控与爆款异常值识别

• 功能名：盯住几个对标账号，把「数据远高于它平时水平」的内容挑出来。
• 来自哪条场景：S1
• 优先级：P0 —— 判据：不做则 S1 整条办不成。
• 核心业务对象：Benchmark 对标号（连带产出 Topic 候选）
• 归属页：P2 选题雷达
• 状态流转：idle → fetching → hit / miss。事件＝刷新、恢复自动更新；守卫＝平台授权有效（🔴 依赖 A2，见 §六）；失败 ⇒ 迁 failed。
• 验收要点：录入一个对标号后，能看到它近 3 天的更新；能指出哪几条是异常值（标注了它相对该号平时水平的倍数）；刷新失败时有明确提示而不是静默空列表。
• 跨哪些页面：P2
• 治理：失败恢复＝退避重试 3 次后转「手工录入对标号」的降级路径；持久化＝监控名单与历史异常值落本地（不落全局）；并发＝同一对标号同时拉取走队列串行，不并发写；幂等＝按「对标号 ＋ 内容标识」去重；超时＝fetching 上限 90 秒（设计值，实现可调），超时转 failed；不可逆＝不涉及。

F2 选题库与灵感速记

• 功能名：凡是对选题有帮助的信息都能收进来，再按分类把它理顺。
• 来自哪条场景：S1、S2
• 优先级：P0 —— 判据：不做则选题无处落地，S1 与 S2 都断在最后一步。
• 核心业务对象：Topic 选题（🔴 V4 放宽：一条 Topic ＝ 选题库里的一条信息，⛔ 不止「一条待做选题」）
• 归属页：P2 选题雷达（速记入口在全局可达的位置，见 2b-界面布局-新版.md §四）
• 容纳范围与分类（🔴 2026-10-09 用户口径新定）：
  • 容纳范围：凡是「对选题有帮助的信息」都收 —— 灵感、对标观察、数据异动、平台风向…（用户原话：「选题库里面可以是对选题有帮助的任何信息 分类区分就好」）。
  • 随手记仍落选题库：⛔ 不新增「待整理」状态、⛔ 不做多去向选择（不要求用户当场判「这是选题还是资产还是对标」）。随手记的默认落点是选题库里的**「灵感」类**。
  • 靠分类区分：分类是一条信息的属性，不是一道中途关卡。两个维度正交，都落在选题库内：
    • 进度（沿用现版）：待做／在写／已用 —— 回答「这条做到哪一步了」。
    • 类型（V4 新增）：选题／对标线索／评论洞察／数据异动／灵感 —— 回答「这条是什么、下一步去哪」，每类自带一个后续动作： ① 选题 ⇒ 转入创作； ② 对标线索 ⇒ 去资产库拆解； ③ 评论洞察 ⇒ 采纳成选题； ④ 数据异动 ⇒ 参与选题判断（做或不做同题）； ⑤ 灵感 ⇒ 续写，或升级成上面任一类型（随手记的默认落点）。
  • ⚠️ 分类的呈现方式（放在哪、怎么切）由③段定，②段只定「两个维度、五类、每类的后续动作」。细节见 2b-界面布局-新版.md §五 P2。
• 状态流转：draft → 待做 → 在写 → 已用 / 弃用。事件＝记录、转待做、转在写、标已用、弃用；守卫＝转「已用」需已关联到一条内容；弃用可恢复（可逆）。🔴 类型与进度是两个维度：改类型不改进度，改进度不改类型。
• 验收要点：连着记 5 条灵感，重启后 5 条都在；一条灵感能被标记为「已用」并追到它变成了哪条内容；一条灵感能被升级成一个「选题」类条目而不用换库、不用多选一次去向；按类型筛一遍，五类各自的后续动作都点得下去。
• 跨哪些页面：P2（入口全局可达）
• 治理：失败恢复＝本地写入失败时保留输入内容，不丢字；持久化＝落本地知识库目录，刷新与重启后仍在；并发＝同一人两个入口同时改 ⇒ 乐观重试（写临时文件 ＋ 原子替换 ＋ 回读核对），⛔ 不用文件锁（本机实测会卡死）；幂等＝同一条灵感重复提交按内容 hash 去重；超时＝无中间态；不可逆＝不涉及（删除走可恢复的「弃用」）。

F3 评论区洞察找选题

• 功能名：从一条内容的评论区里，把反复出现的问题挑成选题。
• 来自哪条场景：S1
• 优先级：P1 —— 判据：不做仍能从 F1 得选题，只是少一路输入。
• 核心业务对象：Topic 选题（原料是评论里的 Insight，它不进对象字典 —— 它只在本功能内部存在，一出候选就变成 Topic）
• 归属页：P2 选题雷达
• 状态流转：idle → 抓取中 → 已出候选 → 已采纳 / 忽略。事件＝抓取、采纳、忽略；守卫＝设定过「最多获取条数」与「样本排序」；🔴 依赖待复核第 7 条（数据来源与频率未定）。
• 验收要点：给一条视频，能按「点赞最多」取出前 N 条评论并给出至少一条可采纳的候选选题。
• 跨哪些页面：P2
• 治理：失败恢复＝抓取失败转手工粘贴评论；持久化＝候选选题落本地；并发＝同一内容同时抓取走队列；幂等＝按「评论标识」去重；超时＝抓取中上限 60 秒（设计值）；不可逆＝不涉及。

S2 选题进资产库

F4 爆款拆解与资产库

• 功能名：把一条爆款的写法拆开，存成下次能直接拿的东西。
• 来自哪条场景：S2
• 优先级：P0 —— 判据：不做则 S2 整条办不成；1a §六 F4 注明「这一条决定了『越用越准』」。
• 核心业务对象：Asset 资产条目
• 归属页：P3 资产库　🔴 V4 写清两件事：
  1. 资产库页的职责是「统一管理」 —— 分类分区、检索、单条详情、来源与引用关系、维护。⛔ 它不再是唯一的入库口。
  2. 入库动作不限页 —— P2（对标内容发起拆解）、P4（创作时沉淀写法）产生的资产都可以就地入库；不管在哪一页写进去，落下来的仍是同一份资产条目、统一由 P3 管。 ⚠️ 「入库不限页」⛔ 不等于「归属页有多个」：归属页按「谁统一管它」定，仍是 P3；别的页只是入口（对应 §一 第 4 条）。
• 状态流转：未拆 → 拆解中 → 待入库 → 已入库 / 退回。事件＝发起拆解、入库、退回；守卫＝入库前过门禁（见治理）；退回后原件保留。 🔴 资产库本身有四个分区（角度、结构、开场白、标题），各区条目独立流转，互不阻塞。
• 验收要点：拆完一条爆款，四个分区里各能看到至少一条新条目；条目的原文与出处可回溯；拿 20 条真实爆款入库，隔一周回来能找回想要的那条；在选题页就地拆解入库的一条，在资产库页照样能检索、能引用。
• 跨哪些页面：P2、P3、P4（入库动作在任一处都能发生）＋ P4（消费）
• 治理：失败恢复＝拆解失败保留原文，可重试；持久化＝入库结果落本地，带原文与出处链接；并发＝同一素材重复拆解按素材 hash 幂等；幂等＝同一条目重复入库不产生副本；超时＝拆解中上限 180 秒（设计值，长任务），超时转 待入库 并保留中间结果；不可逆＝入库前设门禁（对策 R3）：无出处的、原文缺失的一律先设 draft，draft 可删，已入库 删除需二次确认。

S3 走完创作流水线

F6 创作流水线

• 功能名：把一条选题从「聊思路」一路做到成稿，文案、标题、封面齐。
• 来自哪条场景：S3
• 优先级：P0 —— 判据：不做则 S3 整条办不成。
• 核心业务对象：Content 内容
• 归属页：P4 创作台
• 状态流转：选题态 → 思路态 → 文案态 → 标题态 → 封面态 → 检查态 → 成稿态；每一态可回退到上一态。事件＝推进、回退；守卫＝推进到「检查态」前文案与封面必须都有（封面缺 ⇒ 提示但不硬阻）；成稿态可再编辑（回 文案态）。 🔴 这条守卫是业务规则，③段原型现在的无条件推进要按它改（现状 D1）。
• 验收要点：一条选题能一路走到成稿，中途不必离开这一处；每一步的产物都存得住；用户全程不需要自己选技能。
• 跨哪些页面：P4
• 治理：失败恢复＝任一步 AI 调用失败保留已产出内容，可重试该步；持久化＝每一步的产物落本地并按内容 id 归档；并发＝同一条内容两个窗口同时改 ⇒ 写临时文件 ＋ 原子替换 ＋ 回读核对，检测到覆盖则提示；幂等＝重复点「起标题」生成新版本而不覆盖（接 F8）；超时＝任一步上限 180 秒（设计值），超时保留中间结果；不可逆＝不涉及（这一步没有对外动作）。

F8 内容与素材的版本管理

• 功能名：改稿产生新版本，旧版本还在。
• 来自哪条场景：S3、S4
• 优先级：P1 —— 判据：不做则场景办得成但要多绕（靠手工另存，容易盖掉）。
• 核心业务对象：ContentVersion 内容版本
• 归属页：P4 创作台　🔴 归属收紧：上一版写「P4、P5」，本版只归 P4。存版本这个动作产出版本对象，版本对象的产生位置在 P4；P5 只是拿到已经存在的版本去发。
• 状态流转：v1 → v2 → … → 当前版；每个版本可标「当前」。事件＝编辑保存、切换当前版；守卫＝切换当前版不影响已发布记录指向的版本；终态可再次编辑（回出新版本）。
• 验收要点：改一版再改一版，两版都在；已发布的那条记录仍指向它当时用的版本；能看出某一版是基于哪一版改的。
• 跨哪些页面：P4
• 治理：失败恢复＝保存失败保留编辑中内容；持久化＝全部版本落本地，不覆盖；并发＝同一条内容两处同时保存 ⇒ 后保存的产生新版本，同时提示「上游已变」（对应 1b 里 stale 的做法）；幂等＝同样内容重复保存不产生新版本；超时＝无中间态；不可逆＝删除某个版本需二次确认。

F14 录制卡片与画板

• 功能名：把成稿变成一张对着讲的知识卡片。
• 来自哪条场景：S3
• 优先级：P2 —— 判据：不做不影响 S3 办成，只是更好用。
• 核心业务对象：Content 草稿（产出的是这条内容的一个呈现，不是新对象）
• 归属页：P4 创作台　🔴 归属改了：上一版标 P2，本版归 P4，入口可以留在 P2。 判据用第 2 条：它动的是创作过程中的内容生产，不是选题发现能力。P2 能有的只是一颗「开始创作」的动作入口，功能本身不归 P2。 这条同时把现状 D3 的四处不一致收成一处：①段场景里在、②段功能清单里在、②段页面骨架里在（本版把它写进 P4 的板块）、③段要跟着补进创作环节。
• 状态流转：无 → 已生成 → 已同步。事件＝生成、同步到画板；守卫＝成稿态才可生成。
• 验收要点：一条成稿能生成卡片；卡片能落到画板里被打开。
• 跨哪些页面：P4（入口可在 P2）
• 治理：失败恢复＝生成失败可重试；持久化＝卡片与画板落本地；并发＝同一内容重复生成按内容版本幂等；幂等＝同版本不重复生成；超时＝上限 60 秒（设计值）；不可逆＝不涉及。

S4 一份母版变多份

F7 一份母版到多平台账号版本

• 功能名：母版改一次，按各平台账号的口径各出一版。
• 来自哪条场景：S4
• 优先级：P0 —— 判据：不做则 S4 整条办不成。
• 核心业务对象：ContentVersion 内容版本
• 归属页：P4 创作台　🔴 归属整条改了：上一版是「P4 出成稿、P5 展开并逐版确认」，两头各做一半，P4 侧连入口都没有（现状 C4／C6）。本版一句话分清：P4 决定发什么版本，P5 决定怎么把这个版本发出去。 展开这个动作发生在 P4（母版 → 版本策略 → 平台账号 → 生成各版），P5 只负责拿已经存在的版本去检查、去发。
• 展开单位（🔴 2026-10-10 用户口径改）：按平台账号展开 —— 一个内容账号下面的每个平台账号各一版。 用户原话：「一个内容账号 投放时应该有多个平台账号用于分别投放」。 ⛔ 不再写「账号 × 平台」：那是把「内容账号」与「平台」当成两个正交维拼起来，概念分开之后这个组合天然不存在（一个抖音号不可能是 B 站号）。 ⚠️ 「分别投放」是靠「分别成版」实现的，⛔ 不是靠「一个版本同时发多处」。
• 状态流转：母版 → 已展开（多版本）→ 逐版确认 → 就绪。事件＝展开、逐版编辑、确认；守卫＝每个版本必须绑一个内容账号 ＋ 它下面的一个平台账号（上一版写「一个账号 ＋ 一个平台」，V4 按两个概念分开后的口径改）；未确认的版本不许进发布闸门。 🔴 依据界线（照 1a 复核后的写法）：Easel 发布中心直证的是「多平台」（一处编辑、八端预览，源码级 ＋ 界面级）；「多账号」的依据是 Easel 的多画像支持加本产品的矩阵需求，发布中心没看到逐账号变体。
• 验收要点：母版改一次，各平台账号的版本跟着更新；一个内容账号下面挂了 3 个平台账号，展开就出 3 版；改漏了某个平台账号能被发现；超限的地方当场标出来。
• 跨哪些页面：P4（展开与逐版确认）、P5（拿这些版本去发）
• 治理：失败恢复＝展开中断保留已生成的版本；持久化＝每个版本独立落本地；并发＝两处同时展开按「母版版本 ＋ 目标平台账号」幂等；幂等＝同母版同平台账号不重复展开；超时＝展开上限 120 秒（设计值）；不可逆＝不涉及（确认可撤回，未发布的版本可删，删除需二次确认）。

S5 发之前先过闸

F5 发布前分级闸门

• 功能名：发之前，硬的拦住、软的只提醒。
• 来自哪条场景：S5
• 优先级：P0 —— 判据：不做则 S5 整条办不成。
• 核心业务对象：PublishTask 发布任务
• 归属页：P5 发布中心
• 界线（照 1a 复核后的写法，⛔ 不是旧版措辞）：硬闸管敏感信息（账号密钥、内部路径这类），不过就不许发；软闸管人设一致性（低于阈值只告警，不阻断）。⚠️ 竞品里没有「敏感词检测」，也没有「事实检测」——照旧版写会把功能带偏成一个竞品池里没人做过的「事实核查器」。
• 状态流转：未检 → 检查中 → 通过 / 有硬拦 / 有软劝。事件＝发起检查、改完复检；守卫＝有硬拦项时「去发布」不可用；软劝不阻断但要在发布确认页可见。硬拦项改完才能过。
• 验收要点：一份带敏感信息的稿子会被拦住且说得出是哪一处；一份人设偏移的稿子只提醒、不拦；改完能复检并通过。
• 跨哪些页面：P5
• 治理：失败恢复＝检查本身失败按不过处理（fail-closed，宁拦不放）；持久化＝每次检查结果留痕，随发布记录一起存；并发＝同一内容重复检查以最后一次为准；幂等＝同一版本重复检查结果一致；超时＝检查上限 60 秒（设计值），超时按不过处理；不可逆＝「去发布」这一步必须人确认（read-first / draft-first）。

F13 发布留痕与人工确认记录

• 功能名：谁在什么时候确认发的、发的是哪一版，查得到。
• 来自哪条场景：S5
• 优先级：P1 —— 判据：不做则场景办得成但要多绕（靠聊天记录回溯，且回溯成本高）。
• 核心业务对象：PublishRecord 发布记录
• 归属页：P5 发布中心（产生记录）、P7 复盘台（查记录 —— 原 P8 记录与对账整页已并入 P7，见 2b §五）
• 一版一路（🔴 2026-10-10 用户口径新定，V4 显式写出来）：一个渠道（＝一个平台账号）只对应一个版本。 因为版本是按平台账号展开的（F7），所以「渠道」由版本唯一确定 ⇒ PublishRecord 不加渠道字段，它记的「哪一版」已经说明是哪个渠道。 用户原话：「一条内容对应多个发布渠道」⇒ 主体是内容，一条内容对应多个渠道；而每个渠道各有一版、各产生一条发布记录。⛔ 不写成「一个版本同时发多处」。
• 状态流转：草稿 → 待审 → 已确认 → 已发布 → 已归档。事件＝送审、确认、登记发布、归档；守卫＝已发布 需要先有「已确认」记录；组织级急停可把任意 待审 打回 草稿。
• 验收要点：每条发布都能查到确认人与时间；能看出这条发的是哪一版；一条内容发了 3 个渠道 ⇒ 有 3 条记录，每条记录指向它自己那一版，靠版本就能分清渠道；急停能拦住所有待审项，恢复后之前的草稿还在。
• 跨哪些页面：P5、P7
• 治理：失败恢复＝登记失败保留草稿状态；持久化＝审计轨迹落本地，只追加不改写；并发＝同一内容两处送审按「内容版本」幂等；幂等＝重复确认同一版本不产生第二条记录；超时＝待审 上限 72 小时（设计值），超时提醒发起人，不自动放行；不可逆＝发布、删帖、组织级急停三件事形态不一样，别压成一句：发布是人的动作；删帖带破坏性标注，需二次确认；急停的触发与恢复都只有人能做。

S6 效果回写

F9 多账号画像、平台账号与记忆

• 功能名：每个内容账号有自己的口径和记忆，互不覆盖；它下面的平台账号（发布渠道）也在这里维护。
• 来自哪条场景：S6、S7
• 优先级：P0 —— 判据：不做则 S6 整条办不成（表现无处可回）。
• 核心业务对象：Account 内容账号（连带它的长期记忆，以及它下面的平台账号子项）
• 归属页：P6 账号画像
• 界线（🔴 2026-10-10 用户口径新定）：
  • 内容账号管的是内容属性 —— 账号设定（定位／风格／受众／偏好与红线／长期记忆）。平台不属于它。
  • 平台账号是发布的渠道 —— 每条带平台 ＋ 登录态 ＋ 授权状态。登录态归它（能不能发出去是它的事），内容账号不带登录态。
  • 一个内容账号 1 → N 个平台账号；同一个人设在多个平台运营靠这条表达。
• 状态流转：空 → 已建 → 使用中 →（复盘回写）→ 使用中。事件＝建画像、编辑、被复盘回写；守卫＝一个账号一份画像，账号标识唯一；回写只追加记忆条目，不改历史结论。 🔴 平台账号子项另有一条状态：未接入 → 已登录 / 登录失效 → 已授权 / 授权到期。守卫＝授权失效的平台账号不许进发布闸门（P5 发不出去这件事在这里拦）。
• 验收要点：两个内容账号各自的画像互不影响；一条内容复盘后，对应账号的画像里多出一条记忆；并排跑两个账号的创作，谁都不覆盖谁；一个内容账号下面挂 3 个平台账号，各自带自己的登录态与授权状态、互不串台。
• 跨哪些页面：P6
• 治理：失败恢复＝保存失败保留编辑内容；持久化＝记忆作用域收敛到画像目录，⛔ 不写全局文件（对策 R4：多账号并发写全局会互相覆盖）；并发＝多账号并行读同一份画像，写只写自己那一份；幂等＝同一条记忆重复回写按内容 id 去重；超时＝无中间态；不可逆＝删除画像需二次确认（会连带删它累积的记忆与它的平台账号接入信息）。

F10 效果复盘与归因回写

• 功能名：一条内容跑完，把它的表现读回来，写成这个账号的经验。
• 来自哪条场景：S6
• 优先级：P0 —— 判据：不做则 S6 办不成，整个闭环断在最后一步。
• 核心业务对象：Review 复盘结论（原料是 Performance 表现数据）
• 归属页：P7 复盘台
• 状态流转：待复盘 → 读数据中 → 已归因 → 已裁决 → 已回写。事件＝发起复盘、人工裁决、回写；守卫＝先有发布记录（F13）；回写前必须人确认归因结论（Review.confirmed = true 才允许回写）。 🔴 顺序写死了：表现数据 → 系统归因 → 人工裁决 → 允许回写。上一版只写了「回写前必须人确认」，但没说清裁决是回写的前置开关还是只留痕；③段原型因此按「只留痕」实现（现状 D2）。本版按业务规则定为前置开关：没有人工裁决，回写这一步不成立。 🔴 本组只有 Easel 做成了这个闭环（源码级），⛔ 不写成「多家都做了」。
• 验收要点：一条已发布内容能复盘出结论；结论能回写到对应账号的画像；回写后下一轮做这个账号时能看到这条经验。
• 跨哪些页面：P7、P6（回写的落点）
• 治理：失败恢复＝数据读不到时降级为手工录入表现；持久化＝复盘结论与回写记录落本地；并发＝同一条内容重复复盘按内容 id 幂等；幂等＝同一次复盘重复回写不重复追加记忆；超时＝读数据上限 90 秒（设计值），超时转手工录入；不可逆＝回写会改画像记忆，需人确认（不自动写）。

S7 看整个矩阵

F11 矩阵级看板

• 功能名：一屏回答每个账号今天该发什么、发了什么、效果如何。
• 来自哪条场景：S7（🔴 整条标【假设】，待复核第 5 条）
• 优先级：P1 —— 判据：不做则场景办得成但要多绕（逐账号点进去看）；若第 5 条复核为「不需要矩阵级视图」，本条可整体砍掉。
• 口径写实（本版改了）：状态标 待验证，定位标 非主链能力。它不承担主生产链上的任何一环，也不该被包装成「已经有了的完整功能」。影响页面只有 P1。
• 核心业务对象：Performance 表现数据（只读，不产生对象）
• 归属页：P1 矩阵总览
• 状态流转：无状态（只读视图）。事件＝进入、切换账号、下钻。
• 验收要点：一屏能看到矩阵下每个账号的今日状态与效果；数据不新鲜时看得出来。
• 跨哪些页面：P1
• 治理：失败恢复＝数据源不可用时显示「数据未更新」并给出时间戳，⛔ 不显示空白冒充正常；持久化＝视图本身不落库，只读上游；并发＝只读，无冲突；幂等＝只读；超时＝无；不可逆＝不涉及。

S8 商单与内容对账

F12 商单与收支记录、内容对账

• 功能名：一条内容带了商单，内容、发布记录和收支对得上。
• 来自哪条场景：S8（🔴 整条标【假设】，待复核第 6 条；另依赖 A3）
• 优先级：P2／Deferred —— 判据：不做不影响场景办成，只是更好用。本条不进第一版主链，标 Deferred，等第 6 条复核结果再定去留。
• 核心业务对象：Campaign/Order 商单与收支
• 归属页：P7 复盘台（原 P8 记录与对账整页已并入 P7，见 2b §五）
• 状态流转：未登记 → 已登记 → 待结算 → 已结算。事件＝登记、核对、标结算；守卫＝已结算 需内容与发布记录都已关联；可反结算（可逆）。
• 验收要点：一条带商单的内容能查到它的发布记录与收支；对账时不需要翻聊天记录。
• 跨哪些页面：P7
• 治理：失败恢复＝登记失败保留输入；持久化＝收支记录落本地；并发＝同一条记录两处改按记录 id 幂等；幂等＝同一内容同一口径不重复登记；超时＝无中间态；不可逆＝标「已结算」后修改需二次确认。

---

四、功能归属总表（F1–F14）

这张表是本版新加的。上一版的归属散在每条末尾的「跨哪些页面」里，没有一处能一眼看全，也就没法复核。

功能	来自	核心业务对象	归属页	与上一版的差异
F1 对标账号监控与爆款异常值识别	S1	Benchmark	P2	无
F2 选题库与灵感速记	S1 S2	Topic	P2（入口全局可达）	🔴 V4 改了口径：容纳范围放宽成「对选题有帮助的任何信息」，靠进度 × 类型两个维度分类（⛔ 不新增「待整理」状态）
F3 评论区洞察找选题	S1	Topic	P2	无
F4 爆款拆解与资产库	S2	Asset	P3	🔴 V4 改了：Asset 产生位置由 P3 改成 P2／P3／P4 均可；P3 的职责由「入库口」改成「统一管理」
F5 发布前分级闸门	S5	PublishTask	P5	无（对象定义随 §二 更新）
F6 创作流水线	S3	Content	P4	无
F7 一份母版到多平台账号版本	S4	ContentVersion	P4	🔴 V4 改了：展开单位由「账号 × 平台」改成按平台账号展开；守卫改成「内容账号 ＋ 它的一个平台账号」
F8 内容与素材的版本管理	S3 S4	ContentVersion	P4	无
F9 多账号画像、平台账号与记忆	S6 S7	Account	P6	🔴 V4 改了：功能扩到「平台账号（发布渠道）也在这里维护」；Account 改写成内容账号，平台账号做成它下面的子项
F10 效果复盘与归因回写	S6	Review	P7	无
F11 矩阵级看板	S7【假设】	Performance	P1	无
F12 商单与收支记录、内容对账	S8【假设】	Campaign/Order	P7	无（V4 起归属理由由「同类事」给出：发布之后看收入）
F13 发布留痕与人工确认记录	S5	PublishRecord	P5（产生）／P7（查）	🔴 V4 改了：补「一版一路」—— 渠道由版本唯一确定，PublishRecord 不加渠道字段
F14 录制卡片与画板	S3	Content／草稿	P4（入口可在 P2）	无

七页各自「核心对象」与「不应该负责」两栏在 2b-界面布局-新版.md §五，本份不重复。

---

五、与上一版的实质差别（逐条）

这一版不是同一批句子换了个说法。下面逐条写改在哪，能对照原文核。

V4 本轮（相对 V3 · 八条口径）

1、归属判据换了一条（§一 第 2 条）：由「看它动的是哪个对象」改成「这是哪一类事，同类事放同一页」。对象那层保留，但降为落地手段。拿新判据复核七页 ⇒ 页集合一个没动（七页各自都是「一类事」）。 2、新增 §一 第 4 条：「一个对象只有一处」管的是权威数据，⛔ 不管写入动作发生在哪一页。这条是新增的，上一版没有（它正是「资产入库不限页」与「一处产生」看似打架的根因）。 3、Asset 的产生位置由 P3 改成「P2／P3／P4 均可」，并写明资产库页的职责是统一管理、不再是唯一入库口（§二 ＋ §三 F4）。 4、Account 整行重写（§二）：由「矩阵里的一个账号，带它的画像与长期记忆」改成「内容账号：管内容属性的主体，平台不属于它」；平台账号做成它下面的子项清单（带平台 ＋ 登录态 ＋ 授权状态），不加对象（仍是 11 个）。新增一段专门说明两个概念的分野与「为什么不做成独立对象」。 5、PublishTask 的定义改了（§二）：由「含目标账号与平台」改成「含发布渠道」（渠道 ＝ 平台账号）。 6、Topic 的定义放宽（§二）：由「一条待做／在写／已用的选题」改成「选题库里的一条信息」，并带上分类。对应 §三 F2 重写成一个「容纳范围 ＋ 两个正交分类维度（进度 × 类型，五类各带后续动作）」的条目。 7、F4 的归属页段落重写：写清「资产库页＝统一管理」与「入库动作不限页」，并明说**「入库不限页」不等于「归属页有多个」。验收要点与「跨哪些页面」同步。 8、F7 改名并改展开单位：「一份母版到多账号多平台版本」→「一份母版到多平台账号版本」；守卫由「一个账号 ＋ 一个平台」改成「一个内容账号 ＋ 它下面的一个平台账号」；幂等键同步改成「母版版本 ＋ 目标平台账号」。⛔ 全文不再出现「账号 × 平台」。 9、F9 改名并扩范围：「多账号画像与记忆」→「多账号画像、平台账号与记忆」；新增界线段（内容账号管内容属性、平台账号是渠道、登录态归它）；新增平台账号子项的状态流转（未接入 → 已登录 / 登录失效 → 已授权 / 授权到期）与守卫（授权失效不许进发布闸门）。 10、F13 补「一版一路」：一个渠道只对应一个版本 ⇒ 渠道由版本唯一确定 ⇒ PublishRecord 不加渠道字段。验收要点补「一条内容发 3 个渠道 ⇒ 3 条记录，靠版本分清渠道」。 11、§四 总表的「与上一版的差异」栏重写，把 V2 那批差异折叠进历史（避免一张表里混着三个版本的说法）。 12、§九 更新**：上一轮遗留的三条待拍板（账号带不带平台 / PublishRecord 带不带渠道字段 / 要不要做定时）前两条已随本次口径落定；第三条（定时发布）按用户 2026-10-10 07:56 逐字「后续具体做投放功能的时候在说」挂起，并带上回收三字段。 13、功能清单仍是 14 条、编号一个没动，优先级判据一个没改；治理六项覆盖不变。本轮动的是判据、对象定义与三处措辞。

V3 本轮（相对 V2）

1、P8 记录与对账整页并入 P7 复盘台，页 ID 里不再有 P8。F12、F13 的归属页随之改：F12 由 P8 改 P7；F13 的「查记录」那一头由 P8 改 P7（「产生记录」仍在 P5）。 2、对象字典的「被谁消费」栏把 P8 全部并入 P7：Account、ContentVersion、PublishTask、PublishRecord、Performance、Campaign/Order 六行里凡出现 P8 的，一律改 P7（§二）。对象本身一个没增没减，仍是 11 个。 3、导航改一层七项（首页／选题／创作／投放／复盘／账号／资产），页集合由八页收成七页。本份只承接它对功能归属的影响；导航表见 2b §三。 4、功能与板块的对应写成可机检关系。判据没变（仍看核心业务对象），变的是「每页每个板块承担哪条功能」被逐块写下来并由自检双向核（原型 FN_HOME／FN_MAP，2b 附自检 5b-3）。 5、功能清单仍是 14 条、编号一个没动，优先级判据一个没改。本轮动的是归属页与页集合，不是功能本身。

V2（相对 V1）

6、新增「核心业务对象字典」（§二，11 个对象）。V1 完全没有这一层，1a 与 1e 里也没有。它是本版所有归属判断和流转契约的地基。 7、新增「功能归属总表」（§四）。V1 没有任何一处能一眼看全 14 条功能的归属。 8、新增三条判据（§一）。V1 只说了「按场景组织、不按页面」，没说归属怎么判、跨页传什么。第 2、3 条是 V2 第一次写下来。 9、每条功能从六字段扩到八字段，新增「核心业务对象」与「归属页」两栏。原来的「跨哪些页面」保留，但它现在只描述落点，不再承担归属判据。 10、F7 归属改了：从两头各半改成 P4 单一归属，并写死分工「P4 决定发什么版本、P5 决定怎么发」。V1 2b:283 那句「在 P4 出成稿，在 P5 展开并逐版确认」按此作废。 11、F14 归属改了：从 P2 改成 P4，入口可留 P2。 12、F8 跨页收窄：从「P4 创作台、P5 发布中心」改成 P4。 13、F11 口径写实：从一条 P1 的 P1 级功能，改标「待验证／非主链能力」。 14、F12 口径写实：标 P2／Deferred，明确不进第一版主链。 15、F10 状态流转从三态扩到五态（加了「已裁决」「已回写」分开），并把「裁决是回写的前置开关」写死。V1 只写「回写前必须人确认」，没写清是开关还是留痕 —— ③段就是照「留痕」实现的（现状 D2）。 16、F6 的守卫在条目里写实：明确标出这条守卫要③段改（现状 D1 是无条件推进）。

两个版本都没改的

17、14 条功能的编号、来自哪条场景、优先级判据，一个都没动。1e §四 的「场景 → 功能」反向核对依然成立。 18、清单主体仍按使用场景组织（沿用 2026-10-06 用户定案），⛔ 没有改成按页面。GPT 的「按业务对象重新解耦」落在归属判据上，没落在清单组织方式上 —— 这两件事不同，没把它们混成一件事。 19、六项治理全覆盖照旧，落点仍在功能条目内（§七 给了落点清单）。 20、§六 的假设依赖、§八 的不做清单对照，条目数照旧（9 条假设、8 条不做对 13 条已拍板项）。

---

六、依赖假设的条目（逐条标出）

⭐ 1a 的 9 条待复核与 A1–A4 全部未经用户确认，⛔ 不当事实用。本份凡依赖它们的条目列在下面，写清「依赖哪条、不成立会怎样」。

本版比上一版多说一层：这些假设不成立时，受影响的核心业务对象也跟着变，所以影响面不止那一页。

功能	依赖	假设内容	不成立会怎样
F1	A2 ＋ 待复核第 2 条	平台数据靠官方接口或授权方式拿	自动拉取这条路断，退化成手工录入对标号；Benchmark 与 Topic 的来源少一路，S1 的「不用刷榜」打折
F10	A2 ＋ 待复核第 2 条	同上	效果数据读不回来，Performance 只能手工录入，Review 的归因依据变弱，S6 降级
F11	A1 ＋ 待复核第 5 条	账号数 10–50；矩阵级视图确实需要	账号数超出 ⇒ P1 的组织方式要重设计；视图不需要 ⇒ F11 可整体砍掉，P1 页重画
F9	A1	账号数 10–50	同 F11；且 Account 的数量与存储组织要跟着变
F12	A3 ＋ 待复核第 3、6 条	收支口径是「内容级」；商单对账进不进第一版	口径若是月级 ⇒ Campaign/Order 的对象粒度要重定，本条整条重做；不进第一版 ⇒ 保持 Deferred
F5	A4 ＋ 待复核第 4 条	团队 5–20 人、审批不超过三层	审批层数超三层 ⇒ PublishTask 的审批模型要重做
F13	A4 ＋ 待复核第 4 条	同上	同上
F3	待复核第 7 条	评论洞察的数据来源与频率未定	数据来源定不下来 ⇒ F3 退成手工粘贴评论
（无功能）	待复核第 8 条	「整合营销」含不含投放	若含投放 ⇒ 需要新增一条场景（1e §六），本份没有对应功能，⛔ 不编
（策略层）	待复核第 9 条	只服务一个机构自用 vs 可交付产品	影响 1d-产品策略.md §7、§9 与权限体系是否进第一版，不影响本份功能骨架

假设三归宿（方法论要求，⛔ 不许长期悬空）：上表 9 条全部落在「② 待实现且已排定确认时机」这一档 —— 确认时机统一为「②段收口时由主会话转用户一次性过；未过之前，③段不得把这些条目当硬约束用」。落「① 已确认」的：无。落「③ 已按假设落地」的：无。

---

七、六项治理覆盖核对

判据源 state-machine.md 的必答清单。⛔ 不留空，不适用写「不适用」。

治理项	落点（哪些功能显式写了）	最要紧的一条
失败恢复路径	F1 F2 F3 F4 F6 F7 F8 F9 F10 F11 F12 F13 F14	F5 走 fail-closed（检查失败按不过处理），本组唯一一条「宁拦不放」
持久化范围	全部 14 条	F9 的记忆作用域收敛到画像目录、不写全局（对策 R4）；F13 的审计轨迹只追加不改写
并发冲突	F1 F2 F3 F6 F7 F8 F9 F12	统一做法：写临时文件 ＋ 原子替换 ＋ 回读核对，⛔ 不用文件锁（本机实测会卡死）
幂等	F1 F2 F3 F4 F6 F7 F8 F9 F10 F12 F14	F4 与 F8 的重复入库／重复保存不产生副本、也不覆盖旧版
超时迁移目标	F1 F3 F4 F5 F6 F7 F10 F13 F14	F13 的 待审 超时只提醒、不自动放行 —— 不可逆动作不许靠超时自动过
不可逆操作二次确认	F4 F5 F8 F9 F10 F12 F13	F5 ＋ F13：发布、删帖、组织级急停三件形态不同，分别按「人的动作 / 二次确认 / 只有人能触发与恢复」处理

补一条方法论要求的分工说明：发布这个动作本身留在人手里（read-first / draft-first，源码级）；删帖带破坏性标注、属需二次确认的一类；组织级急停的触发与恢复都只有人能做。⚠️ 三件事的「人来做」形态不一样，⛔ 不压成一句话。

---

八、「不做」清单与①段已拍板项的逐条对照

对照方法：本份列出的「不做／移出／暂缓」共 8 条，逐条对 1a-需求文档.md 的已拍板项 13 条（来源：§一 不做什么 4 条 ＋ §八 第一版不做 5 条 ＋ §八 三个入口 1 条 ＋ §三 三条差位的取舍结论 1 条 ＋ §六 治理段「人来做」的三件事分开记 3 条 —— 去重后按条计）。

#	本份的「不做／移出／暂缓」	1a 原条目与口径	拟改口径	理由	差异
1	不做平台自动化代发	§一 不做什么；§八 第一版不做	不变	走 F5 ＋ F13 的人确认路径	无
2	不做矩阵级自动投放优化	§八 第一版不做	不变	1b 里五家都没这一段证据	无
3	不做跨机构协作与权限体系	§八 第一版不做	不变	A4 假设团队不超过三层审批	无
4	不做移动端 App	§八 第一版不做	不变	—	无
5	不把平台数据抓回来做数仓	§八 第一版不做	不变	只对接与留痕	无
6	不自建投放系统	§一 不做什么	不变	只对接与留痕	无
7	不做个人版单账号工具	§一 不做什么	不变	面向一个账号矩阵	无
8	第一版不铺「三个入口」之外的界面	§八「这一版只留的三个入口」	不变	找选题 / 走创作流水线 / 看矩阵复盘	无

结论：8 条对照完，差异行 0。没有一条涉及已拍板项的口径改动，因此没有「与已定决策的差异」表要交用户确认。

一条待确认项（不是「不做」，是「暂缓」，必须带回收三字段）： 本份把 F12 标为 P2／Deferred。这是一条暂缓。

• 复核人 ＝ 主会话转用户
• 复核时机 ＝ ②段收口时一次性过
• 结论落点 ＝ 本文件 §三 F12 条目与 §六 依赖表

---

九、待与用户确认项

派活单要求：涉及改②段结构的三条「部分采纳」先按 GPT 的方向落地，但必须在文末单列。以下是本份范围内的全部待确认项，逐条给「为什么它没被自己拍板」和回收三字段。

🔴 V4 先把上一轮遗留的三条待拍板交代清楚（它们原本堆在这里没结论）：

• 「账号带不带平台」 ⇒ 已随 2026-10-10 用户口径落定：账号分内容账号与平台账号两个概念，平台账号做成内容账号下的子项。本条不再是待确认项（§二 ＋ §三 F9）。
• 「PublishRecord 带不带渠道字段」 ⇒ 已落定为「不加」：靠「一版一路」让渠道由版本唯一确定（§三 F13）。
• 「要不要做定时发布」 ⇒ 挂起，见下面第 7 项。

1、②段要不要并成一份九节的「产品架构基线 V2」 GPT 建议把②段合成一份，九节：导航结构／页面框架／功能清单／核心数据对象／状态机／页面流转契约／业务规则／异常与降级／待决事项。 本版的处置：内容照收，形态不收。九节要的东西本版全部落下去了，只是分布还是两份 —— 导航、页面框架、流转契约进 2b；功能清单、数据对象、业务规则、异常降级、待决事项进 2a；状态机落在每条功能条目里。合成一份等于把「产品功能」与「界面布局」重新塞回去，而这两份是 2026-10-07 的用户定案。 为什么不自决：合成会新增文档层，属于扩大可见面，得单独拍。

2、六种流转类型（T1–T6）要不要进正文 GPT 给了 Create／Open／Continue／Publish／Review／Trace 六型。本版只采纳了三分类（对象传递／上下文定位／状态完成），六型没进正文。 为什么不自决：GPT 没把六型和②段那 20 条流转逐条对齐，直接搬进来就会在同一件事上造出第二份定义。要进就得先把 20 条逐条归型。

3、两条新增流转要不要进②段 GPT 的 P0 清单里有 P7 → P1（复盘结论 → 矩阵待办／异常／最佳内容）与 P7 → P2（复盘发现 → 下一轮选题）两条。第①棒逐条盘过的 18 条里没有这两条 —— 它们是 GPT 新加的。 本版的处置：写进 2b §六 的流转契约，但逐条标了「新增·待确认」。理由：不写进去，GPT 主张的那个「复盘反哺」闭环在文档上就是断的，第④步做界面对不上；写进去但不标，等于偷偷扩范围。 为什么不自决：新增流转是扩范围，得用户点头。

4、1a 的 9 条待复核 ＋ A1–A4 仍未确认 沿用上一版遗留（现状 E2）。本版按假设标注，没有把它当事实用。P1 的形态挂在第 5 条上，P7 第 10 板块（商单与收支）挂在第 6 条与 A3 上。

5、「投放」这一段要不要补一条场景 1e §六 明写的未闭环处：1a §一 的链路里有「投放」，§四 有「剪辑与投放」这个角色，但 §五 的场景里没有一条是投放岗的。本版不为它出功能（无依据就是编）。 ⚠️ 与第 7 项不是同一件事：本条问的是「有没有一条投放场景」（场景层），第 7 项问的是「要不要做定时发布这个具体能力」（功能层）。

6（沿用上一版，未清）：什么算「板块」的判据 2b:7 原来那句「骨架冻结、③段不许新增板块」没有定义「什么算板块」，③段因此能在各页各长一层页壳而机检看不见（现状 A1／A3）。本版在 2b §四 把公共框架显式定义掉了，但**「公共框架 vs 业务板块」这条线本身，最终还要用户认一次**。

7、定时发布：挂起（🔴 V4 新增的登记项） 用户 2026-10-10 07:56 逐字：「后续具体做投放功能的时候在说」。 ⇒ 本版不为它加任何功能条目、字段或状态（⛔ 不编一条 F15，⛔ 不在 PublishTask 里塞排期字段）。 ⇒ 它是挂起，不是「不做」：等真做投放功能时再议。挂起期间谁都不许拿它当已定内容用。

• 复核人 ＝ 主会话转用户
• 复核时机 ＝ 立项做投放功能时（⛔ 不是②段收口时）
• 结论落点 ＝ 本文件 §三 F5／F7 附近 ＋ 2b §五 P5

回收三字段（本份第 1–6 项共用）：

• 复核人 ＝ 主会话转用户
• 复核时机 ＝ ②段收口时一次性过；第 3 条、第 5 条要赶在第④步动界面之前定
• 结论落点 ＝ 本文件 §九 与 2b-界面布局-新版.md §十

---

十、页面清单（跨页引用用的 ID）

本份只写「跨哪些页面」，页面骨架在 2b-界面布局-新版.md。为免引用悬空，页 ID 列在这里：

P1 矩阵总览｜P2 选题雷达｜P3 资产库｜P4 创作台｜P5 发布中心｜P6 账号画像｜P7 复盘台

导航是一层七项（首页／选题／创作／投放／复盘／账号／资产），项与页的对应见 2b §三。P8 记录与对账已整页并入 P7 复盘台，页 ID 里不再有 P8。

---

附：本份自检

• 每条功能都追回①段《使用场景》（1e S1–S8），14 条全覆盖；1e §四 的反向核对（场景 → 功能）依然成立
• 每条功能八字段齐全（功能名 / 来自哪条场景 / 优先级 / 核心业务对象 / 归属页 / 状态流转 / 验收要点 / 跨哪些页面）
• 功能归属有可复核的判据（🔴 V4 换成「一类事情放同一页」，对象降为落地手段），不是「哪页有按钮」
• 拿新判据复核过七页：七页各自都是「一类事」，页集合没动（§一 第 2 条的复核表）
• 八条口径逐条落到正文：① 判据（§一 第 2 条）② 资产入库不限页（§一 第 4 条 ＋ §二 Asset ＋ §三 F4）③ 选题库分类（§二 Topic ＋ §三 F2）④ 记录与对账属复盘不拆（§三 F12／F13，页面侧落 2b §五 P7）⑤ 渠道定义（§二 PublishTask）⑥ 账号两个概念（§二 ＋ §三 F9）⑦ 目标选择两级（页面侧落 2b §五 P5）⑧ F7 展开单位 ＋ F13 一版一路（§三）
• 对象数仍是 11：平台账号做成 Account 下的子项，没有新增对象
• 优先级只用 P0／P1／P2 加一句判据，零数字
• 「不做」清单逐条对照①段已拍板项，给出对照条目数（8 对 13），差异行 0
• 六项治理全覆盖，且落在功能条目内（§七 给了落点清单）
• 依赖假设的条目逐条标出（§六 9 条），每条带假设状态标注与「不成立会怎样」
• 待确认项逐条带齐 复核人 / 复核时机 / 结论落点；定时发布单列为「挂起」并写明挂牌条件（§九 第 7 项）
• 上一轮遗留的三条待拍板（账号带不带平台 / PublishRecord 渠道字段 / 定时发布）逐条交代了去向，不留悬空
• 功能归属页里不再有 P8：F12 → P7，F13 的查记录那侧 → P7（产生侧仍 P5）；对象字典的消费栏同步
• 每页每个板块承担哪条功能写清，并与 2b 的板块清单双向对得上（可机检 FN_HOME／FN_MAP）
• 全文零视觉词（配色 / 字体 / 间距 / 组件样式 / 动效，一个未出现）
• 未重开需求（grill 在①段）、未写页面结构（那是 2b）、未新增本段白名单外的文档
• 只读输入全部是只读使用，没改任何上游文件

（说人话自评：46/50　直接性 10 ／ 节奏 8 ／ 信任度 10 ／ 真实性 9 ／ 精炼度 9 —— 判据源 E:/ProgramData/.workbuddy/skills/humanizer-zh，门槛 45。）