# 临时：新产品形态设计与文档改造说明

- 版本：v1
- 更新日期：2026-05-10
- 状态：临时过渡文档
- 目标读者：产品 / 架构 / 前端 / 后端 / 文档维护者
- 删除条件：当本文件中的产品形态与文档改造要求已经落入 `产品-*`、`流程-*`、`架构-*`、`前端-*`、`后端-*`、`doc/dev/*` 等正式文档后，删除本文件。
- 边界说明：本文只定义“新产品形态”和“如何改造现有设计文档”。它不是长期 SSOT，不替代正式设计文档。

## 1. 新产品形态定义

### 1.1 产品定位修正

Muse 不应该被定义成“带 AI 能力的写作后台”，而应该定义成：

> 面向长篇小说创作的双角色 AI 创作系统：管理员管理系统能力，普通用户在低认知负担的作品工作台里完成创作、规划、生成、知识治理和使用追踪。

这个定义包含两个核心变化：

1. 产品不再只有“作者用户”一个视角，而是明确拆成 管理员(Admin) 与 普通用户(User) 两类角色。
2. 普通用户看到的是创作工作台，不是系统后台；管理员看到的是系统控制台，不是作品创作界面。

### 1.2 角色与边界

| 角色 | 主要目标 | 不能混入的内容 |
|---|---|---|
| 管理员(Admin) | 管理系统能力、模型能力、智能体能力、系统知识和用户 | 不直接参与普通用户单个作品的创作决策 |
| 普通用户(User) | 管理自己的作品、写作、规划、生成、导入解析、导出交付、查看使用情况 | 不直接看到系统 Prompt、智能体配置、底层元数据配置和系统日志 |

管理员负责“系统能做什么、怎么做、用什么做”。

普通用户负责“我的作品是什么、我要怎么写、哪些内容进入我的作品事实”。

### 1.3 管理员控制台

管理员控制台是系统能力配置后台，默认只对管理员开放。

| 模块 | 范围 |
|---|---|
| 元数据与创作模板管理 | MetaSchema / MetaField、作品模板、实体 / 关系 / 事件 / 叙事字段、继承、版本、字段是否 UI 可见、是否进入 AI 上下文 |
| 全局知识库与访问策略 | 全局资料集、写作方法、体裁规则、平台规范、默认绑定用户或用户组、是否可见、是否可检索、是否可用于生成 |
| AI Agent 配置 | 生成 Agent、提取 Agent、校验 Agent、规划 Agent、检索 Agent、启停、超时、重试、fallback |
| Prompt 与生成策略 | 系统 Prompt、任务 Prompt、体裁 Prompt、文风 Prompt、场景策略、版本管理、灰度、回滚 |
| New-API 用户与套餐同步 | 创建 Muse 用户时同步创建 New-API 用户；调用 New-API 接口修改用户分组、用户配额、用户套餐和绑定状态 |
| 上下文组装策略 | Layer 0-3、场景拼装、Token 预算、缓存策略、Watermark Overlay、上下文来源解释 |
| 检索与投影治理 | RAGFlow dataset、索引同步、projection_outbox、projection_watermarks、重建索引、Graph Query Provider / Neo4j 条件能力 |
| Pipeline 与任务治理 | 生成、提取、校验、风险路由、全书解析、任务重试、取消、重放、失败恢复 |
| 用户与权限管理 | 用户、角色、管理员权限、普通用户权限、资源访问边界、状态、封禁或删除流程 |
| 日志、审计与可观测性 | Muse 业务审计、任务失败、异常、后台作业状态、New-API 同步失败；模型消耗日志以 New-API 为准 |
| 质量评估与评测集 | 固定评测场景、固定数据集、固定评分标准、多模型评审、算法汇总评分、评测报告和回归对比 |

New-API 已经负责模型供应商、模型路由、用户分组限流、Token 成本策略和消耗日志记录，Muse 管理员控制台不重复实现这些复杂控制。Muse 只负责和系统用户生命周期相关的同步动作，以及必要的分组、配额、套餐调整入口。

质量评估与评测集不是自由表单。它应该是固定场景、固定数据集、固定评分标准的评测系统。针对一次被测输出，系统使用多个大模型按同一评分标准评审，再用算法计算最终评分、置信度和风险结论。

首批评测场景至少包括：

- 续写生成：是否承接前文、推进情节、保持角色目标。
- 改写与文风：是否保留原意、贴合作品声音、避免同质化 AI 文风。
- 角色一致性：角色声音、目标、动机、弧光是否稳定。
- 世界事实一致性：实体属性、关系、规则、时间线是否冲突。
- 场景推进：章节目标、场景节拍、冲突、结果和下一步钩子是否成立。
- 张力与悬念：张力曲线、悬念维护、信息释放是否符合章节意图。
- 知识抽取：实体、关系、事件、叙事状态提取是否准确、可追溯。
- 冲突检测：风险标记、去重、消歧、冲突摘要是否可靠。
- 全书解析：章节级汇总、批量确认边界、冲突分布是否可用。
- 长程连载：连续 5-10 章后，世界保真度和叙事质量是否稳定。

管理员侧可以使用系统术语，例如 `MetaSchema`、`Agent`、`Prompt`、`Pipeline`、`Job`、`Knowledge Base`、`Evaluation Dataset`。

### 1.4 普通用户产品结构

普通用户登录后的默认入口应该是“我的作品”，而不是系统管理页。

这里需要明确：“我的作品”和“作品工作台”不是同一个产品空间。

- 我的作品：用户自己的作品列表和入口页。
- 作品工作台：用户进入某一个作品后的创作空间。

普通用户侧建议拆成三块，并按职责消除重叠：

| 区域 | 产品职责 | 不负责什么 |
|---|---|---|
| 我的作品 | 展示用户自己的作品列表；支持搜索、筛选、排序、最近编辑、作品状态、新建作品、打开作品、继续写作；可以提供“从文稿创建作品”的入口 | 不承载正文编辑、作品规划、知识治理、解析确认、导出配置等单作品深层流程 |
| 作品工作台 | 围绕单个作品完成写作、规划、生成、知识确认、一致性检查、导入解析、导出交付、生成记录查看 | 不承担跨作品列表管理，也不展示系统后台配置 |
| 个人中心 | 个人信息、Token 使用、生成记录总览、配额、套餐、偏好 | 不承担单个作品的创作决策 |

如果用户在“我的作品”里点击“导入”或“导出”，产品语义也只是进入某个作品的导入 / 导出流程，不应该在列表页里展开完整操作。

普通用户不应该默认看到 `Schema / Proposal / Job / Pipeline / Agent / Prompt` 这些词。

### 1.5 单个作品的工作台结构

每个作品应该成为一个完整创作空间，而不是多个后台页面的拼接。

工作台还有优化空间：它不应该把“写作、规划、知识、检查、导入、导出、记录”平铺成一排后台导航，而应该默认让用户停留在写作流里，再按需要打开规划、知识和检查能力。

建议采用“默认写作台 + 少量工作区 + 上下文面板”的结构：

| 工作区 | 作用 | 用户语言 |
|---|---|---|
| 写作台 | 正文编辑、章节导航、续写、改写、描写、候选卡、版本历史、AI 参考来源说明 | 继续写、改写、描写、插入、丢弃、查看参考 |
| 作品规划台 | 作品方向、世界设定、角色关系、章节大纲、文风检查；所有入口都支持 AI 生成、补全、整理和检查 | 规划、补全、检查、生成方案 |
| 知识与一致性 | 当前作品已确认知识、待确认知识、来源追溯、风险标记、一致性检查、问题定位 | 作品知识、待确认、冲突、定位修复 |
| 导入解析 | 上传旧文稿、导入状态、全书解析、章节确认、批量选择、一键确认全部可确认章节 | 导入、解析、确认章节 |
| 导出交付 | 导出正文、导出知识、选择范围、格式、导出记录 | 导出正文、导出设定、备份 |
| 记录与用量 | 单作品生成历史、任务历史、失败原因、Token 使用、成本 | 使用记录、生成记录、失败原因 |

默认进入“写作台”。规划台是高质量小说生成的承重入口，但不应该盖过日常写作入口。

更具体的界面组织可以采用四区结构：

- 左侧：章节、大纲、情节节拍、作品设定锚点。
- 中间：当前章节正文编辑器。
- 右侧：AI 候选、建议历史、待确认设定、任务反馈。
- 下方或抽屉：故事圣经(Story Bible)、作品知识、上下文命中、风险说明。

高频 AI 操作应贴近光标和文本块(Block)，用作者能理解的动作词，例如续写、改写、描写、头脑风暴、场景推进、换口吻、收紧、放慢。不要让用户为了写一段正文，先理解待审层(Shadow)、规范数据(Canonical)、提案(Proposal)、任务(Job)。

工作台交互原则：

1. AI 辅助能力不单独做成一级工作区，而是出现在写作、规划、知识、导入解析等具体场景里。
2. “检查”不应该变成强制审核关卡；它是用户主动查看的质量工具，问题可以定位到正文、规划或知识。
3. 作品健康状态可以作为轻量提示存在，例如世界事实风险、叙事推进风险、风格漂移风险、解析待确认数量。
4. 每次生成都应该能解释“本次参考了哪些作品知识、规划项和上下文”，但默认只展示摘要，避免增加认知负担。

### 1.6 作品规划台的高质量小说维度

高质量小说的关键维度都应该有创作规划入口，但不能做成后台表单，也不能把所有文学术语平铺成一堆导航。

本地文档和外部产品资料共同指向一个结论：长篇小说质量不是单点能力，而是“作品方向 -> 世界事实 -> 角色变化 -> 剧情结构 -> 场景推进 -> 文风表达 -> 质量检查”的分层系统。

整理依据：

- 本地 `doc/dev/01-总体路线图与阶段依赖.md` 已经把能力拆成世界状态平面(World State Plane) 与叙事状态平面(Narrative State Plane)。
- 本地 Sudowrite 逆向文档显示，故事圣经(Story Bible)至少拆成文风(Style)、梗概(Synopsis)、角色(Characters)、世界构建(Worldbuilding)、大纲(Outline)，且大纲(Outline)、叙事视角(Point of View, POV)、时态(Tense)、场景(Scenes) 会影响生成。
- Sudowrite 官方文档显示，故事圣经(Story Bible)用类型(Genre)、文风(Style)、梗概(Synopsis)、角色(Characters)、世界构建(Worldbuilding)、大纲(Outline)、场景(Scenes) 共同约束后续写作。
- Novelcrafter 的知识库(Codex) / 计划视图(Plan) 设计也把角色、地点、物品、传说设定(Lore)、章节、场景、叙事视角(Point of View, POV)、支线(Subplot) 放在同一创作空间里联动。
- 通用写作方法通常把小说拆成情节(Plot)、人物(Characters)、背景(Setting)、冲突(Conflict)、叙事视角(Point of View)、文风(Style)、主题(Theme) 等核心要素。

外部参考链接：

- [Sudowrite: 什么是故事圣经(Story Bible)](https://docs.sudowrite.com/using-sudowrite/1ow1qkGqof9rtcyGnrWUBS/what-is-story-bible/jmWepHcQdJetNrE991fjJC)
- [Novelcrafter](https://www.novelcrafter.com/)

项目内补充设计思路：

| 来源 | 对高质量生成有意义的设计思路 | 产品归类 |
|---|---|---|
| `doc/dev/04-S2-上下文组装引擎.md` | 上下文组装引擎(Context Assembly Engine)已经把作品、实体、章节、目标文本拆成四层上下文，并要求按场景注入叙事弧线、悬念、角色目标、章节意图和张力 | 用户侧需要看到“作品规划台”入口；具体组装、令牌预算(Token Budget)、缓存和截断属于系统支撑能力 |
| `doc/dev/04-S2-上下文组装引擎.md` | 元结构定义(MetaSchema)按领域(Domain)、范围(Scope)、目标类型(Target Type)拆分，包含世界(World)和叙事(Narrative)两类领域 | 用户侧应形成“世界设定 / 角色关系 / 章节大纲”的规划入口；字段继承和运行态载体属于后台能力 |
| `doc/dev/06-S4-统一Pipeline.md` | 生成流水线(Generation Pipeline)和文本块提取流水线(BlockExtraction Pipeline)要求从正文和 AI 建议里持续提取世界要素与叙事要素，并通过风险标记(Risk Markers)提示问题 | 用户侧需要“知识与一致性”和“检查”入口；流水线步骤、重试、风险路由属于系统支撑能力 |
| `doc/dev/07-S5-全链路闭环验证.md` | 质量评估明确拆成世界保真度(World Fidelity)与叙事质量(Narrative Quality)，叙事质量包含弧线推进、悬念管理、张力曲线、角色声音、情节推进和段落节奏 | 这些维度应反向约束作品规划台和检查项；具体评分、长程评测(Long-horizon Evaluation)、消融评测(Ablation Evaluation)属于管理员和系统评测能力 |
| `doc/design-docs/后端-04-统一数据库Schema-v1.md` | 叙事状态(Narrative State)有真实运行态载体，保存弧线进度、章节意图、角色目标和动机 | 用户侧不直接操作底层载体，但需要能在规划台看到可理解的角色弧光、章节目标和剧情推进状态 |
| `doc/design-docs/架构-02-核心数据结构与双轨模型.md`、`doc/design-docs/后端-04-统一数据库Schema-v1.md` | 当前稳定内容骨架是作品(Work)、章节(Chapter)、文本块(Block)，叙事状态只按作品、章节、实体三个范围保存 | 作品规划台需要作品结构、章节计划和情节节拍；不应先把小说场景(Scene)贸然升成独立一级数据模型 |
| `doc/design-docs/产品-02-核心功能与交互边界.md` | 一致性检查(Consistency Check)被定义为主动查看工具，不是强制审核关卡 | 用户侧应把检查做成轻量工具，不应把每次写作都变成审批流程 |

因此，项目内文档还能补充的高质量生成维度不是“再加更多表单”，而是把已有底层设计翻译成用户可理解的规划和检查入口：

- 上下文命中与可解释性：生成前后说明参考了哪些作品知识、规划项和上下文；这是系统透明度，不是用户手填维度。
- 作品结构与进度：章节顺序、章节摘要、当前字数、完成状态和近期目标要能被规划和检查；这是用户规划维度。
- 章节意图与场景节拍：每章每场要有目标、冲突、结果和下一步钩子；这是用户规划维度。
- 长程记忆与演变轨迹：角色、关系、事件和世界规则要能按章节演变；这是世界设定与角色关系的一部分。
- 事件时间线与因果链：重大事件需要绑定章节、参与角色、因果效果和后续影响；这是世界状态与剧情结构之间的桥。
- 用户编辑后的再提取：用户改正文后，系统要重新提取并让旧草稿失效；这是质量闭环，不是用户一级入口。
- 风险标记与质量闸门：实体冲突、叙事停滞、悬念遗忘、风格漂移要被提示；这是检查入口。
- 评测闭环：长程评测、消融评测和多模型评审用于系统改进；普通用户侧只看到必要的质量提示。

维度是否应该进入 Muse，要满足至少一个条件：

1. 会影响后续生成上下文。
2. 能从正文或规划中提取、保存、追踪或校验。
3. 用户确实需要在创作时做选择，而不是只给系统内部评分。
4. 能帮助判断“故事是否更好看”，而不只是“设定是否不打架”。

每个规划入口都必须同时支持：

- 用户手写
- AI 生成
- AI 补全
- AI 整理
- AI 检查
- AI 给多组选项
- 从正文提取
- 和后续生成上下文绑定

建议采用下面的分层结构：

| 层级 | 普通用户看到的入口 | 子维度 | 意义 | AI 辅助方式 |
|---|---|---|---|---|
| 作品方向 | 作品设定 | 题材、类型、主题、读者承诺、基调、禁区、结局方向 | 给全书生成一个稳定北极星，避免 AI 只会局部续写 | 生成故事前提、整理梗概、检查偏题、给多版方向 |
| 作品结构 | 章节与进度 | 章节顺序、章节摘要、当前字数、完成状态、近期目标、断点位置 | 给长期创作一个可管理骨架，避免写作流和规划流脱节 | 生成章节摘要、整理进度、提示断点、建议下一章目标 |
| 世界与实体 | 角色 / 地点 / 物品 / 组织 / 规则 | 实体属性、关系、时间线、世界规则、能力体系、重要物品 | 解决“世界是什么样的”，保证长篇一致性 | 从正文提取、补全属性、发现冲突、生成关系图 |
| 角色与关系 | 角色弧光 | 目标、动机、弱点、秘密、变化阶段、关系变化、对白特征 | 解决“人物为什么行动、如何变化”，避免人物工具化 | 生成角色弧线、检查章节推进、提示关系停滞 |
| 事件与时间线 | 时间线 / 因果链 | 重大事件、发生章节、参与角色、前因后果、长期影响 | 把世界状态和剧情推进连起来，避免事件只发生一次就被遗忘 | 从正文提取事件、整理时间线、检查因果断裂、提示后续影响 |
| 剧情结构 | 大纲 / 主线 / 支线 | 卷、幕、章节、转折点、支线、伏笔与回收 | 解决“故事往哪里走”，避免中段散掉 | 生成大纲、补齐缺口、检查主线偏移、追踪伏笔兑现 |
| 章节叙事规划 | 章节目标 / 情节节拍 | 章节意图、叙事视角、时态、地点、出场人物、冲突、结果、下一步钩子 | 这是生成正文前最关键的近程控制面，避免原地打转 | 生成情节节拍、检查目标是否完成、建议推进动作 |
| 张力与节奏 | 冲突 / 悬念 / 节奏 | 利害关系、阻力、反转、悬念问题、信息释放、高潮密度 | 解决“读者为什么继续看”，但不应做成独立大表单 | 评估张力不足、建议升级冲突、检查章节节奏 |
| 叙事策略 | 叙事视角 | 叙事视角、时态、叙事距离、多视角切换、信息遮蔽 | 保证讲述方式一致，避免 AI 生成时口吻和视角漂移 | 设置章节策略、检查视角偏移、提示信息泄露 |
| 文风与文本质量 | 文风 | 作者声音、句式、节奏、描写密度、对白密度、禁用风格 | 解决“写出来像不像这本书”，承接文风(Style) / 匹配我的文风(Match My Style)类能力 | 分析样本、生成风格说明、检查风格偏移、给改写建议 |
| 质量检查 | 一致性检查 | 实体一致性、大纲一致性、细纲一致性、进度推进、风格漂移、伏笔遗漏 | 这是检查层，不是用户手填层；把上面各层合成可操作问题 | 自动扫描、列出风险、定位正文、给修复方案 |

产品上不建议把每一行都做成一级导航。普通用户侧可以收敛为 5 个一级入口：

1. 作品设定：作品方向、主题、题材、读者承诺。
2. 章节大纲：作品结构、章节进度、主线、支线、伏笔。
3. 世界设定：实体、关系、规则、事件、时间线。
4. 角色关系：角色档案、角色弧光、关系变化。
5. 文风检查：文风、叙事策略、张力节奏、质量诊断。

原来的“文笔 / 文风”应合并为“文风与文本质量”；“大纲一致性 / 细纲一致性 / 进度推进”应分别落到剧情结构、章节叙事规划和质量检查；“张力”保留，但作为跨大纲和章节的检查维度，不单独做成重表单。

当前正式模型更稳定的结构是作品、章节、文本块和叙事状态，不建议在这个阶段把小说场景(Scene)做成独立一级模型。产品上可以使用“情节节拍 / 场景推进”这样的作者语言，但落文档时应先归入章节叙事规划，后续确认需要独立模型时再扩展。

这些入口共同组成 Muse 的“作品规划台”，不是独立的系统管理模块。

### 1.7 知识库分层

知识库必须按归属拆成两大类，避免普通用户误操作系统级知识，也避免把单个作品的知识和全局资料混在一起。

| 类型 | 归属 | 创建与维护 | 普通用户可见 / 可用策略 | 用途 |
|---|---|---|---|---|
| 全局知识库(Global Knowledge Base) | 管理员 | 管理员导入、维护、授权、停用 | 管理员控制谁默认绑定、谁可见、谁可检索、谁可用于生成、用户是否可解绑 | 写作方法、体裁规则、平台规范、公共资料、可授权资料集 |
| 局域知识库(Local Knowledge Base) | 单个作品 | 系统根据用户作品自动创建、自动维护；来自正文、导入解析、规划、用户确认 | 用户只看到元数据允许展示的实体、关系、字段和摘要；系统内部可保留更多生成上下文 | 当前作品的正式事实、叙事状态、实体关系、来源追溯、生成上下文 |

全局知识库是管理员能力，不是用户作品内容。管理员需要能配置：

- 默认绑定用户或用户组。
- 用户是否能在 UI 里看见该知识库。
- 用户是否能主动检索该知识库。
- 用户是否能在生成时使用该知识库。
- 用户是否能绑定、解绑或只读使用。
- 是否参与默认上下文、仅按需检索，还是完全不可用。

局域知识库是作品能力，系统按作品自动创建，不要求用户手动建库。用户可见的是“作品知识 / 角色设定 / 世界设定 / 引用来源”，不是数据库或索引后台。

局域知识库需要有“内部完整知识”和“用户可见投影”两个层面：

- 系统内部完整知识：用于生成、检查、检索、审计，包含 AI 提取到但不适合直接展示给用户的中间事实。
- 用户可见投影：只展示元数据允许展示的实体类型、字段、关系和摘要。

元数据对象需要补充可见性字段。建议至少区分：

| 字段 | 含义 |
|---|---|
| `uiVisible` | 是否在普通用户 UI 展示 |
| `aiContext` | 是否进入 AI 上下文 |
| `userEditable` | 普通用户是否可编辑 |
| `userSearchable` | 普通用户是否可检索 |
| `exportable` | 是否允许随作品导出 |

抽取出的实体、关系和字段根据所属元数据的 `uiVisible` 决定是否出现在普通用户 UI。`uiVisible=false` 不代表不能参与 AI 生成；是否进入 AI 上下文由 `aiContext` 单独控制。

### 1.8 普通用户侧术语替换

底层技术术语可以保留在架构和后端文档，但普通用户产品文案必须换成创作语言。

| 系统术语 | 普通用户语言 |
|---|---|
| MetaSchema | 创作规则 / 作品模板 / 字段模板 |
| Agent | AI 助手 / AI 能力 |
| Prompt | 指令模板 / 生成规则 |
| Proposal | 待确认知识 / 知识变更 |
| Shadow | AI 候选 / 待确认内容 |
| Canonical | 已确认内容 / 正式设定 |
| Job | 生成记录 / 处理记录 |
| Narrative State | 叙事状态 / 剧情推进状态 |
| Pipeline | 处理流程 / 生成流程 |

### 1.9 必须继续守住的底层边界

新产品形态不能牺牲现有设计里已经定下的硬边界：

- AI 输出必须先进待审层(Shadow)，不能绕过用户直接写正文或知识库。
- 用户确认后才进入规范数据(Canonical)。
- 作品知识必须可追溯来源。
- 修改后合并必须让旧知识草稿失效，并重新提取。
- 全书解析必须保留章节确认边界；可以提供“一键确认全部可确认章节”，但落库、校验、失败回滚必须按 `parse_job_id + chapter_id` 逐章隔离，不能变成一个不可解释的全局写入。
- 未确认草稿不得进入正式检索。
- 普通用户低认知负担不等于系统黑盒；需要在必要时解释“本次 AI 参考了什么”。

## 2. 现有文档修改方式

### 2.1 修改总原则

这次不是给现有文档补几段说明，而是要把产品形态重新落进正式文档。

修改时遵守：

1. `产品-*` 负责用户视角与产品边界。
2. `流程-*` 负责用户步骤和系统处理链路。
3. `架构-*` 负责角色边界、数据边界、上下文边界和不变式。
4. `前端-*` 负责信息架构、交互结构和前端状态拥有。
5. `后端-*` 负责权限、接口、数据结构、后台能力和系统管理能力。
6. `doc/dev/*` 负责实现路线图和阶段验收。
7. 单一归属不能被打破：表结构以 `后端-04` 为准，接口以 `后端-05` 为准，状态机以 `架构-04` 为准，ADR 以 `架构-03` 为准，模块职责以 `后端-02` 为准。
8. 本临时文档只做改造依据，改完删除。

修改时禁止：

- 把同一个字段、状态、接口、表结构在多个正式文档里重复定义。
- 因为产品入口增加，就为每个 UI 面板新增一张表。
- 把 IA 阶段写成必须先完成的工程实现大阶段；IA 只代表产品形态与文档对齐 gate。
- 把管理员配置能力塞进普通用户工作台，或把普通用户创作流程写成后台管理流程。

### 2.2 推荐修改顺序

1. 先改产品文档：`产品-01`、`产品-02`、`产品-03`。
2. 再改流程文档：`流程-01`、`流程-02`。
3. 再改架构文档：`架构-01`、`架构-02`、`架构-03`、`架构-04`。
4. 再改前端文档：`前端-01`、`前端-02`、`前端-03`。
5. 再改后端与 API 文档：`后端-01`、`后端-02`、`后端-03`、`后端-04`、`后端-05`；如果 `后端-04` 的目标表结构变化，再同步检查 `后端-04a-完整建表SQL.sql` 是否需要更新。
6. 再改 dev 路线图：`doc/dev/00` 到 `doc/dev/09`，只把新产品形态作为阶段影响面和验收 gate 纳入，不重排已有 S0-S5 的技术依赖。
7. 最后改入口与映射：`00-文档大纲.md`、`内容映射表.md`。
8. 全部正式文档对齐后，删除本文件。

### 2.3 产品文档修改要求

#### `产品-01-产品定位与核心价值.md`

需要修改：

- 一句话定义改成“双角色 AI 创作系统”。
- 目标用户拆成 管理员(Admin) 与 普通用户(User)。
- 核心价值新增：
  - 管理员可控的系统能力
  - 普通用户低认知负担的创作工作台
  - 高质量小说规划入口
- 非目标新增：
  - 普通用户直接操作系统后台
  - 把作品规划台做成知识管理后台
  - 只做 prose 生成而不管叙事质量

#### `产品-02-核心功能与交互边界.md`

需要修改：

- 功能清单按角色拆分：
  - 管理员控制台
  - 普通用户作品工作台
  - 普通用户个人中心
- 普通用户功能改为用户语言：
  - 我的作品（作品列表）
  - 写作台
  - 作品规划台
  - 知识与一致性
  - 导入解析
  - 导出交付
  - 记录与用量
- 增加“普通用户不可见系统概念”边界。
- 明确“我的作品”只负责作品列表和入口，不负责单作品深层创作流程。
- 增加“作品规划台分层维度”，避免把高质量小说能力做成平铺表单。
- 增加“全局知识库 / 局域知识库”产品边界。
- 保留 Shadow / Canonical / Source Snapshot 等底层边界，但表达为用户可理解反馈。

#### `产品-03-用户旅程与操作流程.md`

需要修改：

- 拆成两类旅程：
  - 管理员配置系统能力
  - 普通用户创作作品
- 普通用户默认旅程改为：
  1. 登录进入我的作品
  2. 新建或导入作品
  3. 进入写作台
  4. 在需要时进入作品规划台
  5. 用 AI 生成 / 改写 / 描写 / 检查
  6. 确认候选与知识
  7. 检索作品知识或被授权的全局知识库
  8. 导出或继续创作
- 管理员旅程不进入单个作品写作，只配置系统能力。

### 2.4 流程文档修改要求

#### `流程-01-产品操作流程(用户视角).md`

需要修改：

- 只写普通用户视角，不承载管理员后台配置流程。
- 普通用户流程第一屏必须是“我的作品”，不是系统后台。
- 单个作品流程要体现：
  - 写作台
  - 作品规划台
  - 知识与一致性
  - 导入解析
  - 导出交付
  - 记录与用量
- 作品规划台每个规划入口都要支持 AI 辅助。
- 全书解析要支持逐章确认、批量选择和一键确认全部可确认章节；系统处理边界仍按章节隔离。
- 保留候选卡、确认、修改后合并、丢弃当前建议等已有生命周期语义。

#### `流程-02-系统处理流程(系统视角).md`

需要修改：

- 增加管理员配置链路：
  - 元数据配置
  - 智能体配置
  - Prompt 配置
  - 全局知识库配置
  - 全局知识库访问策略配置
  - New-API 用户 / 分组 / 配额 / 套餐同步配置
  - 上下文组装策略配置
  - Pipeline 与任务治理配置
  - 质量评估与评测集配置
- 增加普通用户作品链路：
  - 作品写作链路
  - 作品规划链路
  - 作品知识确认链路
  - 全局知识库授权使用链路
  - 局域知识库自动维护链路
  - 使用记录链路
- 明确管理员配置影响普通用户生成链路，但普通用户不能直接修改系统配置。
- 管理员链路在这里写系统处理关系，不写成普通用户操作流程。

### 2.5 架构文档修改要求

#### `架构-01-系统全貌与边界上下文.md`

需要修改：

- 系统边界改为双角色边界。
- 增加 Admin Console 与 User Workspace 两个上层入口。
- BC 划分需要覆盖：
  - Admin BC：系统模板、Prompt、Agent、用户、New-API 同步、全局知识库、访问策略、评测集
  - Content BC：作品、章节、文本块
  - Knowledge BC：全局知识库、局域知识库、用户可见投影
  - AI BC：生成、提取、校验、任务、候选
  - Usage / Audit BC：Token 使用、生成记录、系统日志
- 明确全局知识库、局域知识库、用户可见投影的边界。

#### `架构-02-核心数据结构与双轨模型.md`

需要修改：

- 在模型层区分：
  - 系统级模板与配置
  - 用户级作品数据
  - 作品级知识数据
  - 全局知识库与访问策略
  - 局域知识库与用户可见投影
- 普通用户侧“创作规则 / 作品模板”映射到底层 MetaSchema。
- 作品规划台中的作品方向、作品结构、世界实体、事件时间线、角色弧光、剧情结构、章节叙事规划、张力节奏、叙事策略、文风与质量检查，需要分别落到 World State / Narrative State / MetaSchema 或相关模型边界。
- 当前阶段不要把小说场景(Scene)升成独立一级模型；产品语言可以写“情节节拍 / 场景推进”，模型归入章节叙事规划。
- 元数据对象需要支持 `uiVisible`、`aiContext`、`userEditable`、`userSearchable`、`exportable` 等控制字段。
- 保留 Shadow / Canonical / Archive 三层模型。

#### `架构-03-关键决策与原则(ADR).md`

需要修改：

- 如果新增或改变下面任一架构决策，必须补 ADR，而不是只在产品或后端文档里散写：
  - 管理员控制台成为独立系统入口。
  - New-API 职责边界：New-API 管模型供应商、路由、分组、限流、成本和消耗日志；Muse 只同步用户、分组、配额和套餐。
  - 全局知识库 / 局域知识库分层。
  - 作品规划台只映射到已有 MetaSchema / Narrative State / Knowledge 模型，不为每个 UI 面板新增孤立模型。
  - 小说场景(Scene)暂不作为独立一级模型。

#### `架构-04-状态机与约束清单.md`

需要修改：

- 增加系统配置类对象的状态或版本约束：
  - Prompt 版本
  - Agent 配置版本
  - 全局知识库版本
  - 全局知识库访问策略版本
  - New-API 用户同步配置版本
  - 评测集版本
- 增加全局知识库的启用 / 停用 / 授权边界。
- 增加局域知识库自动维护、用户可见投影和元数据可见性变更的约束。
- 普通用户作品知识确认仍沿用现有 Shadow -> Canonical 生命周期。

### 2.6 前端文档修改要求

#### `前端-01-工程结构与核心依赖.md`

需要修改：

- 前端信息架构拆成：
  - Admin Console
  - User Workspace
  - Personal Center
- 路由和目录建议按角色边界组织，避免管理员页面和作品工作台混在一起。

#### `前端-02-编辑器与影子层交互.md`

需要修改：

- 编辑器不再只是正文 + Shadow Panel，而是作品写作台。
- 引入右侧候选卡流和生成历史。
- 引入作品规划台与写作台的互相跳转。
- 普通用户看到“AI 候选 / 待确认知识 / 已确认设定”，不直接看到 Shadow / Proposal / Canonical。
- 仍然保持 revision、冲突恢复、修改后合并、来源快照拦截。

#### `前端-03-元引擎与动态表单.md`

需要修改：

- 区分管理员配置 MetaSchema 与普通用户填写作品规划。
- 管理员侧显示 `domain + scope + targetType` 等结构。
- 普通用户侧显示为作品设定、章节大纲、世界设定、角色关系、文风检查等创作语言。
- 所有规划入口都应该支持 AI 生成、补全、整理、检查。
- 前端需要按元数据的 `uiVisible` 决定普通用户能看到哪些实体、字段和关系。

### 2.7 后端与 API 文档修改要求

#### `后端-01-领域模型与聚合设计.md`

需要修改：

- 增加或确认管理员配置相关聚合。这里先定义领域职责，不等于每一项都必须新增独立表：
  - SystemPrompt / PromptVersion
  - AgentConfig
  - NewApiUserBinding
  - NewApiPlanMapping
  - GlobalKnowledgeBase
  - GlobalKnowledgeAccessPolicy
  - LocalKnowledgeBase
  - KnowledgeVisibilityPolicy
  - EvaluationDataset
  - EvaluationRun
  - UsageLog
- 区分系统级配置、用户级数据、作品级数据、全局知识库和局域知识库。

#### `后端-02-工程结构与模块职责.md`

需要修改：

- 重新检查模块职责是否覆盖新产品形态：
  - `muse-admin`：管理员控制台、元数据、Prompt / Agent 配置、全局知识库授权、用户与 New-API 同步、评测集管理。
  - `muse-content`：作品、章节、文本块、导入导出、作品工作台所需内容能力。
  - `muse-knowledge`：全局知识库、局域知识库、作品知识、用户可见投影、知识检索边界。
  - `muse-ai`：上下文组装、生成 / 提取 / 校验编排、风险标记、任务状态，不承载模型供应商和成本路由。
  - `muse-shared`：跨模块基础类型、错误、领域事件、权限上下文。
- 明确 New-API 的模型供应商、路由、成本、消耗日志不迁入 Muse 模块。
- 明确跨模块调用仍走公开接口 / Facade，不因为管理员控制台增加就允许直接穿透 Repository。

#### `后端-03-关键流程实现与接口契约.md`

需要修改：

- 增加管理员配置变更如何影响生成链路。
- 增加用户作品工作台所需后台能力：
  - 作品规划数据保存
  - AI 辅助规划生成
  - 全局知识库授权检索
  - 局域知识库自动维护
  - 用户可见投影生成
  - 用户使用日志
- 保持外部 AI 调用不进入正文合并主事务。

#### `后端-04-统一数据库Schema-v1.md`

需要修改：

- 按“复用 / 扩展 / 新增 / 待确认”四类整理表结构，避免过度建模：

| 分类 | 对象 | 处理原则 |
|---|---|---|
| 优先复用 | `meta_schemas`、`narrative_states`、`knowledge_entities`、`knowledge_relations`、`generation_jobs`、`extraction_jobs`、`audit_logs` | 作品规划台、叙事状态、知识确认和任务记录优先复用这些目标模型 |
| 扩展字段 | 元数据可见性字段、知识库访问策略字段、任务来源和审计字段 | 只在已有模型确实承载不了时新增字段 |
| 倾向新增 | `prompt_versions`、`agent_configs`、`newapi_user_bindings`、`newapi_plan_mappings`、`global_knowledge_bases`、`global_knowledge_access_policies`、`evaluation_datasets`、`evaluation_runs` | 这些属于系统级配置或评测能力，适合独立建模，但仍需在 `后端-01` 先确认聚合边界 |
| 待确认 | `local_knowledge_bases`、`usage_logs` | 局域知识库可能由 `work_id` + 现有知识表隐式表达；Token 消耗日志以 New-API 为准，Muse 是否落本地汇总表需要再确认 |

- 增加元数据可见性控制字段，例如 `ui_visible`、`ai_context`、`user_editable`、`user_searchable`、`exportable`。
- 增加作品规划台需要的结构，优先复用 MetaSchema / narrative_states / knowledge_entities，不要为每个 UI 面板硬建孤立表。
- 如果 `后端-04` 目标表结构更新，`后端-04a-完整建表SQL.sql` 必须同步检查；但不要先改 SQL 再反推设计文档。

#### `后端-05-统一API契约-v1.md`

需要修改：

- API 分组拆成：
  - Admin APIs
  - User Workspace APIs
  - Personal Center APIs
- Admin APIs 包含元数据、Prompt、Agent、全局知识库、访问策略、New-API 用户同步、评测集、用户、系统日志。
- User Workspace APIs 包含作品、写作、规划、局域知识库、全局知识库授权检索、导入解析、导出交付、生成候选。
- Personal Center APIs 包含个人信息、Token 使用、生成记录。
- 权限模型必须明确普通用户不能访问管理员接口。

### 2.8 dev 路线图修改要求

#### `doc/dev/00-项目真实现状与目标差距.md`

需要修改：

- 增加产品形态差距：
  - 当前更像系统后台
  - 缺管理员控制台明确边界
  - 缺普通用户作品工作台信息架构
  - 缺作品规划台作为高质量小说生成入口
  - 缺全局知识库 / 局域知识库边界

#### `doc/dev/01-总体路线图与阶段依赖.md`

需要修改：

- 阶段路线里加入产品形态与文档对齐 gate。
- 建议新增前置 gate：
  - IA-0：角色边界与信息架构重构
  - IA-1：普通用户作品工作台
  - IA-2：管理员控制台
  - IA-3：作品规划台和高质量小说维度
- IA-0 到 IA-3 是产品形态 / 信息架构 / 文档对齐 gate，不是要求在 S1 前完成全部工程实现。
- 不要直接把所有管理员能力和作品规划能力塞进 S4/S5；S0-S5 仍保持 AI core 技术依赖链，只补角色影响面和验收口径。

#### `doc/dev/02` 到 `doc/dev/09`

需要修改：

- 每个阶段增加“管理员侧 / 普通用户侧 / 个人中心”影响面。
- 验收口径要区分：
  - 系统能力是否可配置
  - 普通用户是否低认知负担
  - 作品规划维度是否能被 AI 辅助
  - 高质量小说维度是否进入生成上下文或检查链路
  - 全局知识库授权和局域知识库自动维护是否按边界生效

### 2.9 入口与映射文档修改要求

#### `00-文档大纲.md`

需要修改：

- 增加“角色视角导航”：
  - 管理员控制台
  - 普通用户工作台
  - 个人中心
- 明确本临时文档删除后，正式归属由 `产品-* / 架构-* / 流程-* / 前后端文档` 承担。

#### `内容映射表.md`

需要修改：

- 增加新产品形态内容归属：
  - 管理员控制台 -> 产品-02 / 架构-01 / 后端-05 / 前端-01
  - 我的作品 -> 产品-02 / 产品-03 / 流程-01 / 前端-01
  - 作品工作台 -> 产品-03 / 流程-01 / 前端-02
  - 作品规划台 -> 产品-02 / 产品-03 / 架构-02 / 前端-03
  - 知识与一致性 -> 产品-02 / 流程-01 / 架构-02 / 前端-02 / 后端-05
  - 全局知识库 / 局域知识库 -> 架构-01 / 架构-02 / 后端-04 / 后端-05
  - 使用日志 -> 产品-02 / 后端-05 / 前端-01

### 2.10 Sudowrite 对标文档修改要求

#### `专题-02-Sudowrite对标与Muse产品取舍.md`

需要修改：

- 保留“Sudowrite 强在作者前台体验，Muse 强在长期可控”的判断。
- 增加新结论：
  - Muse 借鉴 Sudowrite 的不是外观，而是作品工作台、候选卡流、故事圣经(Story Bible)、章节大纲 / 情节节拍(Outline / Beats)、风格入口。
  - Muse 要把这些能力放进普通用户作品工作台和作品规划台。
  - 管理员控制台是 Muse 区别于 Sudowrite 的系统可控能力。
- 不要把插件市场列为当前 P0；插件和自定义工作流应放到系统成熟后的扩展能力。

### 2.11 横切风险与验收要求

正式文档改造时，下面这些风险不能只散落在单个文档里，必须在相关产品、架构、后端和前端文档中形成闭环：

| 风险 | 必须写清的内容 |
|---|---|
| 权限边界 | 普通用户不能访问管理员接口；管理员不直接进入普通用户单个作品创作决策 |
| 配置版本 | Prompt、Agent、全局知识库、访问策略、评测集必须有版本、启停、回滚或至少变更记录 |
| New-API 同步 | Muse 创建用户时同步 New-API 用户；修改分组、配额、套餐必须幂等；失败要可重试和可审计 |
| 知识库授权 | 全局知识库默认不可越权使用；局域知识库只归属单个作品；用户可见投影由元数据控制 |
| 低认知负担 | 普通用户界面使用创作语言，不把 Schema / Pipeline / Agent / Prompt 暴露成默认导航 |
| 高质量生成 | 作品规划维度必须能进入上下文、提取、校验或检查链路；不能只做静态表单 |
| 数据一致性 | Shadow -> Canonical、Source Snapshot、章节级确认、修改后重新提取等既有硬边界不能被产品改造冲掉 |

### 2.12 完成判定

只有满足下面条件，才能删除本文件：

1. `产品-01` 已写清 Muse 是双角色 AI 创作系统。
2. `产品-02` 已写清管理员控制台、普通用户作品工作台、个人中心的功能边界。
3. `产品-03` 已写清管理员旅程与普通用户作品创作旅程。
4. `流程-01` 已写清普通用户从“我的作品”进入单个作品工作台的流程。
5. `流程-02` 已写清管理员配置如何影响普通用户生成链路。
6. `架构-01` 已写清 Admin Console / User Workspace / Personal Center 的系统边界。
7. `架构-02` 已写清系统级配置、全局知识库、局域知识库、用户可见投影和作品规划数据的模型边界。
8. `架构-03` 已补充必要 ADR，或明确本次没有新增 ADR。
9. `前端-*` 已写清角色分区与普通用户低认知负担的信息架构。
10. `后端-*` 已写清权限、接口、表结构、模块职责和配置链路。
11. `doc/dev/*` 已把新产品形态作为路线图影响面与验收 gate 纳入，而不是误写成全新工程大阶段。
12. `00-文档大纲.md` 和 `内容映射表.md` 已更新正式归属。

删除前必须再做一次全文检索，确认没有正式文档仍只描述单一作者视角，或把管理员配置能力混在普通用户作品工作台里。