zizi-al/oh-my-muse
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
oh-my-muse/design-docs/临时-新产品形态设计与文档改造说明.md
zizi ab4deeb994 提交流程四分册与引用迁移
2026-05-23 17:55:05 +08:00

42 KiB
Raw Blame History

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

  • 版本：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) 等核心要素。

外部参考链接：

项目内补充设计思路：

来源 对高质量生成有意义的设计思路 产品归类
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. 再改流程文档：流程-01A/01B、流程-02A/02B。
  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 流程文档修改要求

流程-01A-管理员操作流程(操作视角).md / 流程-01B-普通用户操作流程(操作视角).md

需要修改：

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

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

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