核心难点是上下文续接、状态管理和中断恢复；需用conversationid+workspacestate持久化消息栈，区分vscode.chatrequest与webview适用场景，确保quickpick时机正确及错误时可重试上一步。
VSCode插件中实现多轮对话式AI助手，核心难点不在“能不能聊”，而在“上下文怎么续、状态怎么管、中断怎么恢复”。直接硬塞一个聊天窗口进去，几轮之后就会出现记忆丢失、指令错乱、模型反复追问相同问题——这不是模型不行，是交互框架没设计好。
如何让vscode.window.createWebviewPanel支持多轮上下文持久化
Webview本身是无状态的，每次webview.postMessage都是新请求，不自动携带历史。必须手动管理对话ID和消息栈。
- 每次创建
webviewPanel时生成唯一conversationId（可用crypto.randomUUID()），并作为viewColumn或webview.options.enableScripts之外的元数据存入插件全局状态（vscode.workspaceState） - 所有用户输入都封装为带
conversationId的message对象，连同时间戳、角色（user/assistant）一并存入workspaceState.get('conversations', {}) - Webview加载时通过
webview.html注入初始conversationId，前端用vscode.getState()拉取对应消息列表渲染 - 切勿在
webview.html里用localStorage存上下文——跨窗口/重载后失效，且无法被插件逻辑统一清理
vscode.ChatRequest与自定义Webview的分工边界
VSCode 1.89+ 提供了原生vscode.ChatRequest API，但它只适用于简单问答场景。一旦需要文件上传、代码块高亮编辑、多步骤确认（比如“先查API文档，再生成调用示例，最后插入到当前光标”），就必须用Webview接管。
-
vscode.ChatRequest适合：单次意图明确的查询（如“解释这行正则”、“优化这个函数”），响应快、无需状态维护 - 自定义Webview适合：需保持会话状态、支持富交互（按钮、折叠代码块、拖拽上传）、要嵌入项目结构树或测试结果面板的场景
- 混用时注意：不要让两者共享同一套上下文存储——
ChatRequest走vscode.chat生命周期，Webview走workspaceState，否则切换时会丢上下文
中断恢复时vscode.window.showQuickPick触发时机错误
多轮任务常需用户中途选择（如“选一个要重构的函数”），但若在AI流式响应未结束时就调用showQuickPick，会导致UI阻塞、响应卡死，甚至quickPick选项为空。
- 必须等AI响应完成（即收到
done事件或response.text完整返回）后再触发showQuickPick - 更稳妥的做法是：把用户选择环节设计为独立的
slash command（如/refactor-function），由用户主动触发，而非AI自动弹出 - 若必须自动唤起，请用
setTimeout加防抖（至少延迟300ms），并检查quickPick.busy状态 - 别依赖
onDidAccept立刻发下一轮请求——用户可能取消或关闭面板，应监听onDidHide做兜底清理
最易被忽略的是错误恢复路径：当某轮AI响应超时或返回格式错误时，不能只弹个vscode.window.showErrorMessage就终止会话。必须把当前conversationId标记为error态，并允许用户点击“重试上一步”按钮——这个按钮背后要能精准还原前一条user消息+所有已缓存的assistant片段，而不是从头开始。
