60 KiB
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 条流转契约重过一遍；换来的只是概念上更整齐。做成子项清单，对象数不变，照样表达得出「一个人设多个平台号」。 - ⚠️ 由此**「渠道」这个词从此有确定含义 ＝ 平台账号**，⛔ 不再用「账号 × 平台」这种把两个概念拼一起的说法。
三条传递规则（全篇只要写流转就按它写）：
- 跨页面只传 ID 加必要上下文，不传页面临时状态。
- 一个对象只有一处权威数据。别处要用，是去消费它，不是各存一份。🔴 这一条管的是权威数据只有一个源，⛔ 不管写入动作发生在哪一页 —— 资产条目可以在 P2／P3／P4 任何一页就地入库（写入动作的地点不限），但它的权威记录只有一份，统一由资产库页管（§一 第 4 条）。
- 目标页接到 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 写清两件事：
- 资产库页的职责是「统一管理」 —— 分类分区、检索、单条详情、来源与引用关系、维护。⛔ 它不再是唯一的入库口。
- 入库动作不限页 —— 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。
附：本份自检
- 每条功能都追回①段《使用场景》（
1eS1–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。）