## 1. 文档目的 当前 `flash-promoter` 已经具备内容输入、平台版本生成、平台预览、模拟发布、发布日志等基础能力，但现有界面将过多功能同时展示在一个页面中，导致用户难以理解操作顺序。 本 PRD 旨在对当前界面进行重构，将主流程从“功能平铺式 Dashboard”调整为“线性发布向导”，让用户可以按照清晰步骤完成一次多平台内容适配与模拟发布。 --- ## 2. 当前问题 ### 2.1 信息过载 当前首页同时展示了： - 内容编辑区 - Markdown / 富文本 / 纯文本切换 - 平台切换按钮 - 使用引导 - 草稿列表 - 资产列表 - 发布任务列表 - 平台预览 - 发布状态 - 本地闭环测试按钮 这些信息同时出现，导致用户不知道当前应该先做什么、后做什么。 ### 2.2 流程不线性 虽然页面顶部显示了输入、生成、编辑、确认、校验、发布等步骤，但实际操作区域没有严格按照步骤展开。 用户进入页面后会同时看到多个阶段的信息，例如： - 还没完成内容输入，就看到发布任务。 - 还没确认平台版本，就看到模拟发布结果。 - 还没选择平台，就看到 Mock、公众号、B站、知乎、小红书按钮。 - 还没理解发布模式，就看到 simulate、draft、assist、publish 等技术概念。 这会造成认知负担。 ### 2.3 技术概念暴露过早 当前 UI 中出现了较多开发或底层概念，例如： - Mock - simulate - draft - assist - publish - 本地闭环 - adapter - publish job 这些概念对开发者有用，但对普通用户来说不应该出现在主流程中。 ### 2.4 右侧栏干扰主任务 右侧的内容草稿、资产、发布任务列表虽然有用，但在用户创建新内容时过早出现，会打断主线。 这些模块应该移动到： - 发布记录页 - 草稿管理页 - 设置页 - 开发调试模式 - 折叠面板 而不是默认展示在新建内容主流程中。 --- ## 3. 重构目标 ### 3.1 产品目标 将 `flash-promoter` 的主界面改造为一个清晰的线性工作流： ```text 输入内容 → 选择平台 → 生成版本 → 编辑确认 → 校验发布 → 查看结果 ``` 用户每一步只看到当前需要操作的内容。 ### 3.2 用户体验目标 重构后，用户应该能够不阅读说明文档，也能自然完成一次发布流程： 1. 输入或粘贴内容。 2. 选择要适配的平台。 3. 生成各平台版本。 4. 逐个平台编辑和确认。 5. 执行发布前校验。 6. 模拟发布。 7. 查看发布结果和日志。 ### 3.3 设计原则 1. 每一步只展示当前任务。 2. 每一步只有一个主要操作按钮。 3. 不在主流程中暴露技术概念。 4. 不把编辑、预览、草稿、资产、任务全部放在同一屏。 5. 底层能力保留，但 UI 重新组织。 6. MVP 阶段只显示模拟发布，不显示真实发布入口。 7. 发布模式说明用用户语言表达，不用开发语言表达。 8. 用户始终知道自己处在哪一步、下一步是什么。 --- ## 4. 重构范围 ### 4.1 本次需要修改 本次重构主要修改前端 UI 和流程组织： - 首页布局 - 左侧导航 - 主流程 Stepper - 内容输入页 - 平台选择页 - 平台版本生成页 - 编辑确认页 - 校验发布页 - 发布结果页 - 发布记录页 ### 4.2 本次不修改 本次不需要重写底层能力： - `CanonicalPost` - `PlatformAdapter` - `mock adapter` - 平台适配逻辑 - 发布任务模型 - 发布日志模型 - SQLite 存储 - 校验逻辑 - 平台 adapter 骨架 这些能力继续保留，只调整 UI 展示方式和用户操作路径。 --- ## 5. 信息架构调整 ### 5.1 左侧导航 左侧导航只保留三个入口： ```text 新建发布 发布记录 设置 ``` #### 新建发布 进入线性发布向导。 #### 发布记录 查看历史草稿、发布任务、模拟发布结果、发布日志。 #### 设置 管理基础配置、平台配置、开发调试选项。 ### 5.2 从主流程中移除的内容 以下内容不再默认出现在“新建发布”页面： - 内容草稿列表 - 资产列表 - 发布任务列表 - 顶部 Mock / 微信公众号 / B站 / 知乎 / 小红书筛选按钮 - 一键跑通本地闭环按钮 - 过多状态徽章 - 开发调试信息 - adapter 技术信息 这些内容可以移动到“发布记录”或“设置 / 调试模式”。 --- ## 6. 主流程设计 主流程采用 Stepper 形式。 顶部固定显示步骤条： ```text 1 输入内容 2 选择平台 3 生成版本 4 编辑确认 5 校验发布 6 发布结果 ``` 每个步骤需要满足： - 当前步骤高亮。 - 已完成步骤显示完成状态。 - 未完成步骤置灰。 - 用户可以返回上一步。 - 不允许跳过必要步骤。 --- ## 7. 页面需求 ### 7.1 第一步：输入内容 #### 页面目标 让用户输入或粘贴原始内容。 #### 页面内容 需要展示： - 标题输入框 - 摘要输入框，可选 - 标签输入框，可选 - 正文输入区 - 输入模式切换 输入模式包括： ```text 普通文本 Markdown 富文本 ``` #### 交互要求 1. 默认使用“普通文本”输入模式。 2. Markdown 只是支持格式之一，不要让用户以为必须上传 Markdown 文件。 3. 用户可以直接粘贴文章内容。 4. 用户可以填写标题、摘要和标签。 5. 用户点击“下一步：选择平台”后，系统将内容转换为 `CanonicalPost`。 #### 主按钮 ```text 下一步：选择平台 ``` #### 校验规则 进入下一步前必须校验： - 标题不能为空。 - 正文不能为空。 - 正文长度不能过短。 --- ### 7.2 第二步：选择平台 #### 页面目标 让用户选择需要生成版本的平台。 #### 页面内容 展示四个平台卡片： - 微信公众号 - 知乎 - B站 - 小红书 每个平台卡片包含： - 平台名称 - 平台说明 - 默认发布方式 - 是否启用开关 #### 默认状态 四个平台默认全部启用。 默认发布方式以用户可理解语言展示： | 平台 | 展示文案 | 内部模式 | |---|---|---| | 微信公众号 | 生成草稿 | draft | | B站 | 模拟发布 | simulate | | 知乎 | 辅助发布 | assist | | 小红书 | 辅助发布 | assist | #### 交互要求 1. 用户可以取消某个平台。 2. 至少选择一个平台。 3. 不在此页面展示 adapter、mock、publish 等技术名词。 4. 平台默认模式只作为说明，不让用户修改复杂参数。 #### 按钮 ```text 上一步 生成平台版本 ``` --- ### 7.3 第三步：生成版本 #### 页面目标 系统根据原始内容生成各平台适配版本。 #### 页面状态 该步骤包含两个状态： ##### 生成中 显示： - 当前正在生成的平台 - 总进度 - 简短说明 例如： ```text 正在生成微信公众号版本... 正在生成知乎版本... 正在生成 B站版本... 正在生成小红书版本... ``` ##### 生成完成 显示平台版本概览卡片。 每个平台一张卡片，包含： - 平台名称 - 生成状态 - 标题预览 - 摘要 / 简介预览 - 标签数量 - 是否存在警告 - 编辑按钮 #### 交互要求 1. 生成完成后不直接展示复杂编辑器。 2. 先展示概览，让用户知道系统生成了什么。 3. 用户可以重新生成单个平台版本。 4. 用户可以进入下一步编辑确认。 #### 按钮 ```text 上一步 进入编辑确认 ``` --- ### 7.4 第四步：编辑确认 #### 页面目标 让用户逐个平台检查、编辑并确认平台版本。 #### 页面结构 使用平台 Tab 展示： - 微信公众号 - 知乎 - B站 - 小红书 但只显示用户在第二步选择的平台。 每个 Tab 内部采用左右结构： ```text 左侧：可编辑内容 右侧：平台预览 ``` #### 左侧编辑内容 根据平台不同，展示不同字段。 ##### 微信公众号 - 标题 - 摘要 - 正文 - 标签 - 封面文案 ##### 知乎 - 标题 - 正文 - 话题 - 风格提示 ##### B站 - 视频标题 / 专栏标题 - 简介 - 标签 - 分区建议 - 置顶评论 ##### 小红书 - 标题 - 正文 - 话题标签 - 封面文案 - 图文卡片文案 #### 右侧预览 展示当前平台的模拟预览，不需要完全还原平台 UI，但要能看清： - 标题 - 正文结构 - 摘要 / 简介 - 标签 / 话题 - 封面文案 #### 确认机制 每个平台都有两个按钮： ```text 保存当前版本 确认当前平台 ``` 所有已选择平台都确认后，才能进入下一步。 #### 按钮 ```text 上一步 下一步：校验发布 ``` --- ### 7.5 第五步：校验发布 #### 页面目标 集中展示各平台发布前校验结果，并执行模拟发布。 #### 页面内容 每个平台一张校验卡片。 卡片内容包括： - 平台名称 - 发布方式 - 校验状态 - 错误 - 警告 - 可发布状态 #### 校验状态 状态分为： ```text 通过 有警告 有错误 ``` ##### 有错误 不能继续发布。 例如： - 标题为空。 - 正文为空。 - 标签格式异常。 - 平台版本未确认。 ##### 有警告 可以继续模拟发布，但需要提示用户。 例如： - 摘要缺失。 - 标签较少。 - 小红书封面文案为空。 - B站分区建议缺失。 #### 发布按钮 MVP 阶段只显示： ```text 模拟发布 ``` 不要显示： - 真实发布 - 一键真实发布 - 直接发布 - 发布到平台 #### 交互要求 1. 如果存在错误，禁用“模拟发布”按钮。 2. 如果只有警告，允许模拟发布。 3. 点击模拟发布后，为每个平台创建发布任务。 4. 每个平台独立执行，不因某个平台失败影响其他平台。 5. 所有结果写入发布日志。 #### 按钮 ```text 上一步 模拟发布 ``` --- ### 7.6 第六步：发布结果 #### 页面目标 展示本次模拟发布结果。 #### 页面内容 每个平台一张结果卡片。 卡片内容包括： - 平台名称 - 发布方式 - 发布状态 - 时间 - 返回信息 - 错误原因，如有 - 查看日志按钮 #### 发布状态 MVP 阶段常见状态： ```text 模拟成功 模拟失败 已记录日志 ``` #### 页面操作 提供三个按钮： ```text 查看发布日志 返回编辑 新建下一篇内容 ``` #### 交互要求 1. 用户可以查看详细日志。 2. 用户可以返回编辑确认页修改内容。 3. 用户可以开始新的发布流程。 4. 发布结果需要保存到发布记录中。 --- ## 8. 发布记录页 ### 页面目标 集中管理历史内容、发布任务和日志。 ### 页面内容 发布记录页可以包含： - 内容草稿 - 发布任务 - 发布日志 - 模拟发布结果 ### 列表字段 建议展示： - 标题 - 创建时间 - 平台 - 发布方式 - 发布状态 - 错误信息 - 操作 ### 操作 支持： - 查看详情 - 继续编辑 - 查看日志 - 删除记录 --- ## 9. 设置页 ### 页面目标 管理系统配置和开发调试能力。 ### 页面内容 设置页可以包含： - 平台配置 - 默认发布模式说明 - 本地存储位置 - 调试模式开关 - 清空数据 - 导出日志 ### 调试模式 当前界面中的以下功能可以放到调试模式中： - Mock 平台切换 - 一键跑通本地闭环 - adapter 状态 - publish job 原始数据 - raw log 默认不对普通用户显示。 --- ## 10. 视觉设计要求 ### 10.1 整体风格 界面应更像“发布向导”，而不是“后台管理系统”。 ### 10.2 页面密度 要求： - 减少同屏卡片数量。 - 每一步只突出一个主任务。 - 右侧栏默认不显示。 - 不同时展示编辑器、预览、草稿、任务和资产。 - 状态信息放在当前步骤内部。 ### 10.3 按钮文案 按钮文案必须告诉用户下一步动作。 推荐： - 下一步：选择平台 - 生成平台版本 - 进入编辑确认 - 下一步：校验发布 - 模拟发布 - 查看发布结果 - 新建下一篇内容 不推荐： - 执行 - 提交 - 跑通 - 发布 - 确认 - Mock - publish --- ## 11. 状态与权限控制 ### 11.1 步骤进入条件 | 步骤 | 进入条件 | |---|---| | 输入内容 | 默认可进入 | | 选择平台 | 标题和正文已填写 | | 生成版本 | 至少选择一个平台 | | 编辑确认 | 平台版本已生成 | | 校验发布 | 所选平台均已确认 | | 发布结果 | 已执行模拟发布 | ### 11.2 防止误操作 需要防止： - 空内容生成平台版本。 - 未选择平台生成版本。 - 未确认平台版本进入发布。 - 校验错误时模拟发布。 - MVP 阶段误触发真实发布。 - 用户误以为已经发布到真实平台。 发布结果中必须明确显示： ```text 本次为模拟发布，未调用真实平台接口。 ``` --- ## 12. 底层能力保留要求 本次重构不删除底层能力。 必须继续保留： - `CanonicalPost` - `PlatformDraft` - `PlatformAdapter` - `mock adapter` - `wechat adapter` - `bilibili adapter` - `zhihu-assist adapter` - `xhs-assist adapter` - 发布任务 - 发布日志 - SQLite 存储 - 校验逻辑 只是将它们重新组织到线性用户流程中。 --- ## 13. 验收标准 重构完成后，应满足以下标准： 1. 用户进入“新建发布”后，只看到线性 Stepper。 2. 用户可以按步骤完成一次模拟发布。 3. 首页不再默认展示草稿列表、资产列表、发布任务列表。 4. 页面不再同时展示所有平台编辑和任务信息。 5. 技术概念不再暴露给普通用户。 6. 用户不需要理解 mock、adapter、simulate、draft、assist、publish 等概念，也能完成操作。 7. 用户可以输入普通文本，而不是必须上传 Markdown 文件。 8. 用户可以选择平台。 9. 系统可以生成平台版本。 10. 用户可以逐个平台编辑并确认。 11. 系统可以进行发布前校验。 12. 用户可以执行模拟发布。 13. 系统可以展示发布结果。 14. 系统可以保存并展示发布日志。 15. MVP 阶段不会调用真实平台发布接口。 --- ## 14. 核心判断 当前版本的问题不是功能不足，而是功能组织方式不适合普通用户。 应将产品从： ```text 功能平铺式 Dashboard ``` 调整为： ```text 线性发布向导 ``` 最终用户感知到的流程应该非常简单： ```text 写内容 → 选平台 → 生成版本 → 改一改 → 检查 → 模拟发布 → 看结果 ``` 底层的 adapter、发布任务、日志、平台模式仍然存在，但不应该成为用户理解产品的前提。
1. 文档目的
当前
flash-promoter已经具备内容输入、平台版本生成、平台预览、模拟发布、发布日志等基础能力，但现有界面将过多功能同时展示在一个页面中，导致用户难以理解操作顺序。本 PRD 旨在对当前界面进行重构，将主流程从“功能平铺式 Dashboard”调整为“线性发布向导”，让用户可以按照清晰步骤完成一次多平台内容适配与模拟发布。
2. 当前问题
2.1 信息过载
当前首页同时展示了：
这些信息同时出现，导致用户不知道当前应该先做什么、后做什么。
2.2 流程不线性
虽然页面顶部显示了输入、生成、编辑、确认、校验、发布等步骤，但实际操作区域没有严格按照步骤展开。
用户进入页面后会同时看到多个阶段的信息，例如：
这会造成认知负担。
2.3 技术概念暴露过早
当前 UI 中出现了较多开发或底层概念，例如：
这些概念对开发者有用，但对普通用户来说不应该出现在主流程中。
2.4 右侧栏干扰主任务
右侧的内容草稿、资产、发布任务列表虽然有用，但在用户创建新内容时过早出现，会打断主线。
这些模块应该移动到：
而不是默认展示在新建内容主流程中。
3. 重构目标
3.1 产品目标
将
flash-promoter的主界面改造为一个清晰的线性工作流：用户每一步只看到当前需要操作的内容。
3.2 用户体验目标
重构后，用户应该能够不阅读说明文档，也能自然完成一次发布流程：
3.3 设计原则
4. 重构范围
4.1 本次需要修改
本次重构主要修改前端 UI 和流程组织：
4.2 本次不修改
本次不需要重写底层能力：
CanonicalPostPlatformAdaptermock adapter这些能力继续保留，只调整 UI 展示方式和用户操作路径。
5. 信息架构调整
5.1 左侧导航
左侧导航只保留三个入口：
新建发布
进入线性发布向导。
发布记录
查看历史草稿、发布任务、模拟发布结果、发布日志。
设置
管理基础配置、平台配置、开发调试选项。
5.2 从主流程中移除的内容
以下内容不再默认出现在“新建发布”页面：
这些内容可以移动到“发布记录”或“设置 / 调试模式”。
6. 主流程设计
主流程采用 Stepper 形式。
顶部固定显示步骤条：
每个步骤需要满足：
7. 页面需求
7.1 第一步：输入内容
页面目标
让用户输入或粘贴原始内容。
页面内容
需要展示：
输入模式包括：
交互要求
CanonicalPost。主按钮
校验规则
进入下一步前必须校验：
7.2 第二步：选择平台
页面目标
让用户选择需要生成版本的平台。
页面内容
展示四个平台卡片：
每个平台卡片包含：
默认状态
四个平台默认全部启用。
默认发布方式以用户可理解语言展示：
交互要求
按钮
7.3 第三步：生成版本
页面目标
系统根据原始内容生成各平台适配版本。
页面状态
该步骤包含两个状态：
生成中
显示：
例如：
生成完成
显示平台版本概览卡片。
每个平台一张卡片，包含：
交互要求
按钮
7.4 第四步：编辑确认
页面目标
让用户逐个平台检查、编辑并确认平台版本。
页面结构
使用平台 Tab 展示：
但只显示用户在第二步选择的平台。
每个 Tab 内部采用左右结构：
左侧编辑内容
根据平台不同，展示不同字段。
微信公众号
知乎
B站
小红书
右侧预览
展示当前平台的模拟预览，不需要完全还原平台 UI，但要能看清：
确认机制
每个平台都有两个按钮：
所有已选择平台都确认后，才能进入下一步。
按钮
7.5 第五步：校验发布
页面目标
集中展示各平台发布前校验结果，并执行模拟发布。
页面内容
每个平台一张校验卡片。
卡片内容包括：
校验状态
状态分为：
有错误
不能继续发布。
例如：
有警告
可以继续模拟发布，但需要提示用户。
例如：
发布按钮
MVP 阶段只显示：
不要显示：
交互要求
按钮
7.6 第六步：发布结果
页面目标
展示本次模拟发布结果。
页面内容
每个平台一张结果卡片。
卡片内容包括：
发布状态
MVP 阶段常见状态：
页面操作
提供三个按钮：
交互要求
8. 发布记录页
页面目标
集中管理历史内容、发布任务和日志。
页面内容
发布记录页可以包含：
列表字段
建议展示：
操作
支持：
9. 设置页
页面目标
管理系统配置和开发调试能力。
页面内容
设置页可以包含：
调试模式
当前界面中的以下功能可以放到调试模式中：
默认不对普通用户显示。
10. 视觉设计要求
10.1 整体风格
界面应更像“发布向导”，而不是“后台管理系统”。
10.2 页面密度
要求：
10.3 按钮文案
按钮文案必须告诉用户下一步动作。
推荐：
不推荐：
11. 状态与权限控制
11.1 步骤进入条件
11.2 防止误操作
需要防止：
发布结果中必须明确显示：
12. 底层能力保留要求
本次重构不删除底层能力。
必须继续保留：
CanonicalPostPlatformDraftPlatformAdaptermock adapterwechat adapterbilibili adapterzhihu-assist adapterxhs-assist adapter只是将它们重新组织到线性用户流程中。
13. 验收标准
重构完成后，应满足以下标准：
14. 核心判断
当前版本的问题不是功能不足，而是功能组织方式不适合普通用户。
应将产品从：
调整为：
最终用户感知到的流程应该非常简单：
底层的 adapter、发布任务、日志、平台模式仍然存在，但不应该成为用户理解产品的前提。