企业官网建设流程全解析

• AI Agent
• 人工智能
• 大模型
• AI 应用
• 工具调用
• 本地部署
• MCP Clients
• Agent 记忆

本指南基于 Operit 仓库中「Memory Space Profile Documents」系列的设计文档 5_StandaloneUiPolish.md，讲解独立「User Preferences（用户档案）」设置界面在首版实现之后所做的界面打磨：如何还原已发布 +5 版本的 Markdown 编辑器结构、如何把档案管理与策略设置收敛到紧凑的选择栏与独立面板中，以及如何保证所有开关即时持久化。读完本文，你将掌握该界面的布局决策、每个交互单元对应的 Compose 实现位置，以及这一轮改动为何不触碰存储、迁移与运行时注入边界。

一、背景与问题：首版独立界面破坏了 +5 的视觉层次

在 4_StandaloneUserConfigurationUi.md 中，独立用户档案界面被确立为：在「设置」中恢复 User Preferences 入口，由它独占配置选择器与档案操作，并把选中的配置呈现为一个user.mdMarkdown 编辑器，附带自动更新与整文档锁定控制；记忆库则只保留浏览所需的活动空间选择器，不再承担创建、重命名、删除或编辑用户配置的职责。

然而，首版独立界面的实际布局存在明显缺陷，设计文档 5_StandaloneUiPolish.md 的 Problem 一节对此有精确描述：

首版独立界面把「档案操作、两个全宽策略行、标签页、编辑器、保存动作」堆叠进一条不间断的纵向列中，既没有保留已发布 +5 界面的视觉层次，也丢掉了其基于状态的 Markdown 编辑器。

也就是说，功能虽然齐全，但信息密度过高、主次不分：策略开关与编辑操作挤在同一视觉层级里，编辑器应有的沉浸感与可读性被破坏。打磨的目标不是新增功能，而是恢复已被用户验证过的 +5 编辑体验，同时保留 +4 档案管理器中真正有用的能力。

二、打磨方案总览：五项修订

设计文档给出的修订清单可以概括为五条：

1. 还原 +5 编辑器结构：居中内容宽度、紧凑的标签页/保存工具栏、全高编辑器、语法高亮、空占位符、字符计数与文档菜单；
2. 保留 +4 档案管理器精华：以一条紧凑的选择栏承载档案选择；
3. 操作收敛到菜单：激活、重命名、删除统一放入档案操作菜单；
4. 策略独立成面板：自动更新与整文档锁定放入专用策略面板（Policy Sheet），开关切换后立即持久化；
5. 提供紧凑跳转动作：一键把所选档案对应的记忆空间设为活动空间，并直接打开记忆库。

文档同时明确划定了本轮改动边界：存储、迁移、运行时注入、记忆绑定行为均不做任何变更——这保证了打磨纯粹是 UI 层的重构，不引入数据层面的回归风险。

三、编辑器结构还原：+5 体验的逐项落地

打磨后的编辑器结构可以直接在 UserPreferencesSettingsScreen.kt 中逐项找到对应实现。

3.1 居中内容宽度

主内容列通过Modifier.align(Alignment.TopCenter)配合.widthIn(max = 840.dp)实现居中与最大宽度约束（见UserPreferencesSettingsScreen.kt第 251-256 行）。在横屏或平板上，编辑器不会无限拉伸，保证行长可读；在竖屏手机上则自然占满可用宽度。

3.2 紧凑的标签页/保存工具栏

工具栏是一个独立的Surface（第 447-488 行），内部仅一行：两个FilterChip分别切换「编辑 / 预览」标签页（selectedTab == 0 / 1），右侧一个FilledTonalButton承担保存动作。保存按钮的可用性完全由状态驱动：

enabled = loadedProfile != null && hasUnsavedChanges && !exceedsLimit && !savingDocument

即：档案已加载、存在未保存改动、未超字符上限、且不在保存中。保存进行时按钮内的图标会被 18dp 的CircularProgressIndicator替换，形成清晰的异步反馈。这一设计与文档要求的「compact tab/save toolbar」完全一致。

3.3 全高编辑器、语法高亮、空占位符与字符计数

编辑区域占据剩余全部高度（Modifier.fillMaxWidth().weight(1f)，第 490-494 行），编辑页使用BasicTextField承载草稿（第 502-533 行）：

• 语法高亮：通过rememberMarkdownSyntaxOutputTransformation()作为outputTransformation注入BasicTextField（第 512 行），编辑时即可看到 Markdown 语法着色；
• 等宽字体：textStyle使用FontFamily.Monospace，贴合 Markdown 排版习惯；
• 空占位符：decorator中在draftMarkdown.isEmpty()时渲染user_md_editor_placeholder提示文本（第 516-528 行）；
• 字符计数：编辑区底部以"{draftMarkdown.length} / 12000"实时展示计数（第 563-571 行），超限时文字变为error色，与仓库层MAX_CONTENT_CHARS = 12_000的硬约束呼应（见 MemorySpaceProfileDocumentRepository.kt 第 20 行）；预览页在内容为空时展示user_md_preview_empty占位，否则由MarkdownTextComposable渲染。

3.4 文档菜单与状态驱动的未保存保护

「文档菜单」指编辑器基于「已保存内容」这一状态决策交互：草稿draftMarkdown != savedMarkdown时判定hasUnsavedChanges。围绕它有三类丢弃确认对话框（第 782-857 行）：

• 返回确认：BackHandler拦截返回键，未保存时弹出showBackDiscardDialog，确认丢弃才放行onNavigateBack()；
• 切换档案确认：选择器切换时若有未保存改动，弹出showSelectionDiscardDialog，确认后才把selectedProfileId切到pendingProfileId；
• 跳转记忆库确认：点击打开记忆库时若有未保存改动，弹出showMemoryDiscardDialog，确认后先把草稿回滚为savedMarkdown再执行跳转。

这组对话框保证了「编辑 → 切换 → 保存」的状态闭环，任何离开路径都不会悄悄丢弃用户输入。

四、紧凑选择栏：+4 档案管理器的精华保留

首版界面把整套档案管理器平铺在页面里；打磨后只保留一条紧凑的选择栏（第 259-445 行），它承载了 +4 中真正高频的能力：

• 选择器：左侧OutlinedButton展示当前档案名，激活中的档案名旁显示对勾Check图标，点击展开DropdownMenu列出全部档案，活动档案带Check前导图标；
• 创建：Add图标按钮弹出命名对话框，创建成功后调用createMemorySpace(name)并立即设为活动空间、选中该档案（第 694-697 行）；
• 打开记忆：Folder图标按钮执行跳转动作（详见第六节）；
• 档案操作菜单：MoreVert图标按钮展开档案操作DropdownMenu（详见第五节）。

选择栏整体以surfaceContainer圆角Surface呈现，视觉上收敛为单行工具条，与下方编辑器形成清晰的「工具条 → 内容区」主次结构。

五、档案操作菜单：激活、重命名与删除

档案级操作统一收敛到MoreVert展开的DropdownMenu（第 366-443 行），共四类条目：

删除项刻意对default空间隐藏，避免用户删除默认档案；同时所有破坏性操作（删除、丢弃改动）都要求二次确认对话框，符合 Android 设置类界面的安全惯例。

六、策略面板：自动更新与整文档锁定，切换即持久化

这是本轮打磨中信息架构变化最大的一处：策略开关不再以两个全宽行常驻页面，而是收纳进ModalBottomSheet策略面板（第 580-662 行），仅当用户从档案菜单点击「策略」时弹出。面板内是两行带图标的开关：

• 自动更新（Auto update）：Sync图标 +profileAutoUpdateEnabled开关；
• 整文档锁定（Lock）：Lock图标 +profileAutoUpdateLocked开关。

「切换即持久化」由persistPolicy函数保证（第 204-224 行）：每次开关变化立即构造policyProfile.copy(...)，乐观更新loadedProfile与profiles列表，随后preferencesManager.updateMemorySpace(updatedProfile)写回；失败时回滚到previousProfile并弹出 Snackbar。面板标题栏右侧的savingPolicy进度圈在写入期间禁用所有开关，避免并发覆盖。

这两个开关在运行时层的语义由 MemorySpaceProfileDocumentRepository.kt 的saveAutomatic（第 94-100 行）体现：仅当profileAutoUpdateEnabled为真且profileAutoUpdateLocked为假时，记忆自动保存管线才会把抽取出的档案内容写回对应空间的user.md——策略面板正是在这一仓库边界上做用户可见的开关控制。

七、跳转动作：激活记忆空间并直达记忆库

选择栏的Folder按钮实现文档要求的「紧凑跳转动作」——openSelectedMemory()（第 230-240 行）：

1. 先preferencesManager.setActiveMemorySpace(profileId)把所选档案对应的记忆空间设为活动空间；
2. 再通过onNavigateToMemory()回调直接打开记忆库。

一条点击同时完成「激活」与「跳转」，让用户可以在档案与记忆数据之间快速来回，而不必在设置页与记忆库之间手动切换活动空间。

八、边界与兼容性：本轮不动数据层

设计文档在 Revision 末尾明确声明：「No storage, migration, runtime injection, or memory binding behavior changes in this step」。结合系列文档可确认其边界含义：

• 存储与迁移（见 1_StorageAndMigration.md）：memory-space-profiles/<memory-space-id>/user.md的存储布局、原子写入、12,000 字符上限、schema 标记与 +4/+5 一次性迁移逻辑全部保持原样；
• 运行时与自动更新（见 2_RuntimeAndAutoUpdate.md）：活动记忆空间 ID 加载档案文档、update_user_profile/update_user_preferences工具名解析活动空间文档等行为不变；
• 快照恢复兼容（见 6_RawSnapshotRestoreCompatibility.md）：+4 原始快照的profile_list分类、目录整体恢复与原子导入逻辑同样不受本轮影响。

因此，从 +4、+5 或当前 worktree 升级而来的用户，其既有档案文档、ObjectBox 数据库与固定角色卡绑定均保持兼容——这一轮打磨的收益完全来自界面信息架构的重构，而非数据契约的变更。

九、源码验证路径

若要在当前仓库中核对本文描述的每一项打磨，可按以下路径直接查阅：

• 界面实现：UserPreferencesSettingsScreen.kt——居中宽度（L253-256）、工具栏（L447-488）、编辑器与字符计数（L490-575）、策略面板（L580-662）、跳转动作（L230-240）；
• 仓库与写入边界：MemorySpaceProfileDocumentRepository.kt——MAX_CONTENT_CHARS = 12_000（L20）、saveAutomatic锁定检查（L94-100）、AtomicFile原子写入（L299-311）；
• 配置与运行时契约：文档 4_StandaloneUserConfigurationUi.md、2_RuntimeAndAutoUpdate.md 与系列索引 index.md。

总体而言，5_StandaloneUiPolish.md所定义的这轮打磨，是在「独立用户档案界面」这一新能力上的一次信息架构收敛：编辑器回归 +5 的沉浸式 Markdown 体验，档案操作与策略控制各自归位，所有交互状态（草稿、保存中、策略写入中）都有明确反馈与防丢失保护，而数据层完全不动——为后续基于该界面的任何功能演进保留了干净的边界。

• AI Agent
• 人工智能
• 大模型
• AI 应用
• 工具调用
• 本地部署
• MCP Clients
• Agent 记忆