非聊天式生成 UI 与 Copilot 交互模式

• ghost text 的触发时机与防抖
• 接受/拒绝的交互
• 误触场景（注释、字符串内）的规避

行内 ghost text 触发时机：用户暂停输入（如 300ms 防抖）且光标在代码位置时请求补全；在注释、字符串字面量内等语义不明确处应抑制或延迟触发，避免误触。接受/拒绝交互：Tab 接受、Esc 拒绝（或 Cmd+→ 接受），幽灵文本用灰色虚线样式与真实代码区分。触发需结合 AST 上下文判断"该处是否值得补全"，避免在无意义位置频繁请求打断心流。

ghost text 的核心是"不打扰"。防抖 + 触发抑制（注释/字符串）+ 明确接受/拒绝键，既提供补全又避免误触。AST 上下文判断能显著减少无效触发。

• AI 建议值与用户确认值的视觉区分
• 交互确认机制
• 提交前的校验与确认

生成式表单中，AI 预填值用明确视觉标记（如 AI 徽章、不同底色、边框虚线）与用户自行输入/确认的值区分。交互上：AI 建议值可一键接受、拒绝或编辑；用户编辑后该字段转为"已确认"状态。提交前：AI 建议值未确认的字段需提示或要求确认，避免用户未审阅就提交错误数据；所有字段走与用户输入相同的校验（必填、格式、范围）。可用"忽略 AI 建议"或"全部接受"的批量操作。

AI 预填是"建议"而非"事实"，必须让用户明确"这是建议值还是我确认的值"。视觉区分 + 状态转换 + 提交前确认，避免 AI 建议未经确认被提交。

• 冲突合并策略的选择（OT/CRDT/锁定）
• 协同复杂度权衡
• AI 修改范围的呈现

协同编辑的合并策略选择：OT 适合文本协同、复杂度中等；CRDT 适合无需中心排序、多端并发、需自动收敛的场景，实现复杂；锁定（写锁）在 AI 改写大片区域时简单可靠，把 AI 改写区域锁住，用户不可并发编辑，避免冲突。AI 的修改范围应可视化呈现：用高亮/差异视图标出 AI 改动的起始点，用户可接受或回滚。选择依据：AI 改写常是大段替换，锁定 + 差异呈现往往比 OT/CRDT 更简单可控。

AI 改写是"大段替换"而非"逐字符编辑"，OT/CRDT 的复杂度在这里未必划算。锁定改写区域 + 清晰呈现差异，是简单可靠的选择。高并发细粒度协同才需 OT/CRDT。

• 语音交互的状态机（收听/说话/思考/打断）
• VAD 事件驱动
• 字幕同步与打断处理

语音交互用显式状态机：listening（收听）、processing（思考/模型处理）、speaking（说话/播报）、barge-in（打断）。VAD（语音活动检测）事件（speech-start/speech-end）驱动 listening 与 speaking 之间的转换；检测到用户说话（barge-in）时立即停止播报并进入 listening。字幕同步：识别文本与播报逐句同步渲染，打断后字幕与状态同步更新。状态机用事件驱动、防抖（避免 VAD 抖动）处理，保证收听/说话/思考状态不混乱。

语音交互状态交错（用户边听边想说话），必须用状态机 + VAD 事件精确驱动。barge-in 是核心：用户打断时立即停止播报。状态机 + 防抖保证状态稳定。

• 上下文共享的范围控制
• 权限与数据最小化
• 防止无关敏感内容进入模型

Copilot 侧边面板与主应用共享上下文，但必须划权限与最小化：明确"当前选区""当前文件""操作历史"哪些可共享，用户可控制（如只共享选区、不共享整文件）；敏感内容（密钥、其他文件）默认不进入模型，需用户显式授权。数据最小化：只发送任务所需的上下文，不发送无关内容，减少泄露面与 token 成本。可提供"共享上下文预览"让用户看到将发送什么。

上下文共享是 Copilot 的核心价值，也是泄露风险。权限控制 + 最小化 + 用户显式授权，防止敏感内容无意进入模型。这是 AI 助手产品必须设计的边界。

• 差异预览
• 逐条接受/拒绝
• 用户控制与回滚

行内编辑的 AI 建议应提供差异预览（diff 视图，高亮改动部分），并支持逐条接受/拒绝：每条建议独立呈现，用户可逐条接受、拒绝或编辑，而非一次性全部应用。接受后保留回滚能力（undo）。这样用户能精细控制哪些改动被采纳，避免副作用。逐条操作也便于统计采纳率。

一次性全部应用会抹掉用户对细节的控制。差异预览 + 逐条接受/拒绝 + 回滚，让用户主导改动，减少误采纳。这也是衡量建议质量的基础。

• 命令面板的生成式交互
• 流式输出就地呈现
• 取消与重做

命令面板（Cmd+K）触发的生成式交互：在面板内就地展示流式输出（不切换页面），输出逐 token 渲染；提供就地取消（Esc/按钮）中止生成并清理；支持重做（重新生成或撤销应用）。命令面板保持轻量，输出可一键应用或复制到主界面。取消后可通过 Cmd+Z 重做或重新触发。状态机管理面板的 idle/generating/done/error。

命令面板的生成式交互要"轻量就地"：不打断当前工作流，流式输出就地呈现，取消/重做即点即用。保持面板不阻塞主应用。

• 采纳度量指标（接受率、留存率、编辑距离）
• 防扭曲的统计口径
• 归因与真实采纳

行内建议采纳度量：接受率（接受/提出）、留存率（接受后一段时间仍保留）、编辑距离（接受后用户修改多少）。防止"接受后即删除"扭曲：统计时跟踪建议的"留存"——接受后若在短时间内撤销/删除，应计为未真正采纳或单独计为"接受后回退"。用编辑距离衡量接受后的改动量，若改动过大则视为"修改后采纳"。归因需绑定建议 id 与最终内容，反映真实采纳价值。

单纯"接受率"可被"接受后马上删除"刷高。需用留存率与编辑距离校正，识别"真实采纳"。归因统计要跟踪建议的建议 id 与最终状态，才反映真实质量。

• AI 建议值是否走相同校验
• 校验时机（预填/提交）
• 建议值与校验的交互

AI 建议值必须走与用户输入相同的校验规则（必填、格式、范围、业务约束），因为 AI 可能生成不合规的值。校验时机：预填时做即时校验（高亮不合规字段），用户未确认前只提示不强拦；提交时强校验，未通过则阻止提交并定位问题。AI 建议值存在的校验错误应明确标注"该值不符合规则"，并给出修正建议。校验规则由服务端业务定义，前端执行。

AI 建议不等于合法值，必须过同样校验。预填时温和提示、提交时严格拦截，把握"提示 vs 拦截"的时机。这样既允许 AI 预填的便利，又不放行非法数据。

• 结构化增量的局部更新
• 组件 tree 的划分
• 避免整页重渲染

结构化输出增量（如 JSON 的字段级更新）应驱动组件树局部更新：把界面拆成独立组件，每个结构化字段映射到组件，增量到达时只更新对应字段的组件，其他组件不重渲染。用 memo/selector 隔离更新范围，流式数据用 rAF 批量合并。渲染层根据结构化 schema 递进渲染已完成的字段，未完成字段显示占位。避免整页重渲染，保持滚动与交互稳定。

结构化输出天然是"字段级"的，可做局部更新。把结构化 schema 映射到组件树 + 只更新变化的叶子节点，是生成式 UI 高效渲染的关键。整页重渲染会破坏交互与滚动。

• AI 插入与用户编辑的冲突
• 防跳动（debounce、合并边界、光标锚定）
• 冲突处理

AI 逐字插入与用户同时编辑并发时：用 debounce 缓和 AI 插入频率，避免每 token 都影响文本；划定合并边界（AI 只在建议区域插入，不触及用户编辑区）；光标锚定——AI 插入不改变用户当前光标位置，用偏移补偿或独立插入区域。冲突时：AI 插入与用户编辑重叠区域的改动以用户为准，AI 建议在用户编辑后重新生成或标记待确认。采用"AI 写入独立层 + 用户层优先"的合并策略。

防跳动核心是"AI 插入不影响用户定位与既有操作"。debounce 降频、合并边界隔离、光标锚定保定位，冲突时用户优先。这避免 AI 流式插入打断用户编辑。

• 屏幕阅读器播报建议采纳
• 键盘操作
• ghost text 对辅助技术的可见性

非聊天生成式 UI 无障碍：建议采纳时用 ARIA live region 播报（如"已应用建议"）；键盘操作覆盖所有交互（接受/拒绝、导航建议）；ghost text 不能只靠样式隐藏——需用 aria-label 或 role 让辅助技术可感知，或提供非视觉替代（如"按下 Tab 接受建议"的提示）。对比度、焦点管理、可缩放字体也要达标。避免 ghost text 对 screen reader 不可见而让视觉缺陷用户无法感知建议。

无障碍是生成式 UI 常被忽略的。ghost text 是视觉提示，辅助技术用户需要文字/播报替代。ARIA live region + 键盘全覆盖 + ghost text 的可感知替代，是核心。

• 遥测数据最小化
• 聚合指标与采纳事件
• 隐私保护

Copilot 遥测遵循最小化：只上报聚合指标（建议触发次数、采纳率、延迟、错误率）与采纳事件（建议 id、采纳/拒绝、编辑距离），不采集用户完整输入与文件内容。对需要诊断的，用哈希或脱敏标识符（如文件类型而非内容）。上报前过滤敏感字段，设置采样率。遥测策略满足合规与隐私要求。

用户输入与文件内容是敏感数据，遥测只能采聚合与事件。用建议 id 归因、脱敏标识符替代内容，既保可观测性又守隐私。

• 三种上下文策略（全文、向量检索、结构化摘要）
• 质量与 Token 代价的权衡
• 选择依据

三种上下文策略各有取舍：全文注入质量最高（模型看全貌）但 Token 代价巨大，仅适合小内容；向量检索命中片段（RAG）用相似度检索相关片段，质量高且 Token 少，适合大知识库，但需索引与召回调优；结构化摘要把内容压缩为结构化摘要，Token 最小但可能丢失细节。评估：用下游任务指标（问答准确率、采纳率）衡量质量，用 token 数/成本衡量代价，在质量 ↑ 与代价 ↓ 间权衡。通常用 RAG + 摘要混合，按场景选择。

上下文管理是"质量 vs 成本"的权衡。全文贵但全，检索省但需召回，摘要省但丢细节。评估必须用真实任务指标 + Token 成本，找到最优组合。

• 可编辑与撤销/重做
• 状态可控与可审计
• 操作历史记录

AI 生成结果应可编辑、可撤销/重做：每次 AI 应用或用户编辑都记录为操作（op），支持 undo/redo 栈；AI 应用与用户修改都可回滚。最终状态可控可审计：操作历史记录（谁、何时、应用了什么 AI 建议、改了什么），可用于审计与指标归因。AI 应用与用户编辑在同一 undo 栈中，用户可逐步回退并查看差异。

生成结果不能是"一次性黑盒"，必须可编辑、可回滚、可审计。操作历史（undo/redo + 审计日志）保证用户对最终状态有完全控制，同时满足合规与归因。

• 各模式的交互设计要点
• 结构化输出的工程要点
• 模式差异

非聊天式生成 UI 典型模式：表单预填——AI 建议值需区分与确认、走相同校验、就地编辑；图表生成——AI 输出结构化数据（图表配置/数据数组），前端渲染为图表，支持预览与参数调整；报告生成——按章节流式输出，提供 TOC、折叠、导出，数据可视化。工程要点：都用结构化输出（JSON schema）驱动，增量渲染，支持反馈与回滚，输出与用户输入融合编辑。三者共用"结构化输出 + 局部渲染 + 可编辑回滚"底座。

三种模式都非对话式，交互目标是"就地生成可用成果"。结构化输出是共同底座，配合局部渲染、可编辑回滚与反馈，形成统一的生成式 UI 工程范式。

• 反馈闭环的数据采集
• 归因统计驱动模型迭代
• 驱动交互迭代

生成式 UI 的反馈闭环：采集建议采纳/拒绝/编辑距离等归因数据，按建议 id、场景、模型版本归因。分析哪些建议被采纳、哪些被拒、编辑距离多大，指导模型迭代（调优、重训、换策略）与交互迭代（改触发时机、减少误触、优化建议质量）。闭环让数据驱动"建议质量"与"交互体验"双迭代。用 A/B 测试验证改动。

反馈闭环是生成式 UI 持续改进的引擎。归因统计（采纳率、存活率、编辑距离）把用户行为转化为模型与交互的改进信号，形成数据驱动迭代。