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