题目重点：按 Growth onsite 的产品设计题拆用户流、实体/索引、每轮上下文拼装、超长提示上传和多窗口前端性能。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版支持创建 conversation、添加 message/prompt version、发起 run、查看结果及以只读链接分享；题目没有披露分享是否可编辑、多人实时协作或组织权限。
- 模型调用是无状态的：服务端必须按所选上下文策略组装本次输入；上下文窗口大小、tokenizer 与文件附件上限未见题目，10MB 是某次追问的文本规模而非可直接送入模型的承诺。
- 多窗口客户端显示相同 conversation 时以服务端 run/version 为真相；草稿可保存在每窗口本地，但提交需检查版本，避免静默覆盖。
解题路线
- 画关键用户流：编辑大 prompt→保存版本→选择上下文范围→提交 run→流式显示→重试/派生版本→生成分享链接。先明确分享者能看到哪些消息、结果和附件，撤销链接后缓存与搜索索引如何失效。
- 实体可拆 `Conversation(id,owner,visibility,version)`、`Message(id,conversation_id,role,content_ref,seq)`、`PromptVersion(id,parent_id,content_ref)`、`Run(id,model,params,status,context_manifest,output_ref)`、`ShareGrant(token_hash,scope,expires_at)`。按 conversation+seq 查消息，按 owner+updated_at 列会话，按 share token hash 查权限；run 保存精确上下文 manifest 便于复现。
- 每次调用按 manifest 从历史消息/模板/系统约束中选择内容并估 token；超上下文时显式拒绝、截断或摘要且记录策略，绝不假定模型自动记忆。请求幂等键避免重试生成两个 run，流式输出和最终持久化要有单调状态。
- 10MB+ prompt 用分块上传与内容寻址对象存储，浏览器只保留可视片段和编辑窗口；服务端拼装/校验内容并在生成前预估 token 与成本。多窗口用虚拟列表、懒加载、Web Worker/增量解析和跨标签广播减轻主线程压力，但关键版本冲突仍由服务端 CAS 判定。
- 分享安全先做 owner/组织权限检查、token 最小权限与到期、敏感内容确认、撤销和审计；直接把完整 prompt 放 URL 或客户端日志会泄漏。
手动走一遍
用户打开会话 C 的两个窗口，窗口 A 将 v4 改成 v5 并提交 run R1；窗口 B 仍编辑 v4，提交时服务端用 expected_version=4 与当前 v5 比较，返回冲突让用户合并或另存分支。R1 保存 `context_manifest=[m1,m2,v5]`，即使之后 C 又有新消息，重放 R1 的输入仍确定。10MB 文本先分块上传；若 token 超模型上限，UI 解释并让用户裁剪。
规模与取舍
列某会话最近 p 条消息可借 `(conversation_id,seq)` 索引做到 O(log M+p) 级查找；每轮组装输入至少 O(所选内容字节数)。10MB 文本的网络与解析成本为 Ω(10MB)，虚拟化主要减少浏览器同时渲染的 DOM 和主线程工作，不能省去真实上传字节。存储按 prompt 版本和 run 输出增长，可用内容哈希去重相同不可变大块。
易错点与追问
容易失分的边界
- 认为模型自动保存上一轮上下文，导致分享/重放时输入不一致。
- 只存 conversation 当前文本，无法复现某次 run 的模型、参数与上下文版本。
- 把 10MB prompt 直接塞进同步 JSON API 和 DOM textarea 的每个窗口，无上传进度、token 预算或主线程隔离。
- 分享 token 明文存库或放进可记录的查询日志，撤销后旧缓存仍可读。
- 把‘类似聊天产品’误当作原题要求完整群聊/实时协作；这些需另外澄清。
继续深挖
- 若共享链接可允许 fork，如何保持来源版本可追踪但不泄露后续私有消息？
- 如何评估截断/摘要策略是否改变了模型答复的意义？
- 当用户在多个窗口同时启动昂贵 run，如何限额与取消？
