第四章：高级实践

# 第四章：高级实践 前三章我们探讨了Crush的骨架、肌肉和皮肤——架构、渲染与视觉语言。这些是构建一个优雅TUI应用的基础。但真实世界的应用远比教科书复杂：用户会调整终端窗口大小，会同时打开多个对话框，会期望在AI助手与代码之间无缝切换。本章将深入这些高级场景，展示Crush如何将理论转化为实战能力。 ## 📐 4.1 响应式布局 想象你正在一家咖啡馆工作。你打开Crush，将终端窗口拖到屏幕左侧，与右边的代码编辑器并排。窗口变窄了，原本宽敞的侧边栏现在显得拥挤不堪，聊天区域被挤压得只剩下一条细缝。你皱起眉头，考虑是否要全屏切换。 就在这一瞬间，Crush已经感知到了变化。 在`internal/ui/model/ui.go`中，Crush定义了两个关键断点。当终端宽度小于120字符或高度小于30行时，界面会自动切换到紧凑模式。这不是简单的CSS媒体查询——终端没有CSS——而是通过Go代码精心编排的布局重构。 ```go // 基于 internal/ui/model/ui.go:61-65 const ( compactModeWidthBreakpoint = 120 compactModeHeightBreakpoint = 30 ) ``` 这两个数字并非随意选取。120字符是传统终端的标准宽度，也是代码可读性的黄金分割点——超过这个宽度，眼睛需要大幅度移动才能读完一行。30行则是一个关键的心理阈值：低于这个高度，用户开始感到"被挤压"，需要更紧凑的信息密度。 紧凑模式下，Crush会隐藏侧边栏的详细信息，将多列布局压缩为单列，减少元素之间的间距。这些变化不是简单的隐藏和显示，而是需要重新计算每个组件的位置和大小。在`View()`函数中，Crush会根据当前窗口尺寸动态生成不同的布局结构。 > **断点 (Breakpoint)**: 响应式设计中的关键阈值，当窗口尺寸跨过这个阈值时，布局会触发根本性的重构。不同于Web开发中的CSS媒体查询，终端应用的断点检测需要手动实现，并在每一帧重新计算。 响应式布局的挑战在于：终端窗口的变化是实时的。用户拖动窗口边缘的每一帧，Crush都需要重新计算布局。这意味着`View()`函数可能在一秒内被调用数十次。如果布局计算过于复杂，渲染就会卡顿；如果计算过于简单，界面就会错位。Crush通过精心设计的布局算法，在复杂度和性能之间找到了平衡点。 ## 📚 4.2 Dialog覆盖系统 终端应用的对话框管理，是一个容易被忽视但极具挑战性的问题。 想象这样一个场景：用户正在编辑一条消息，突然想查看帮助文档。他按下快捷键，帮助对话框弹出。阅读完毕后，他按下ESC关闭帮助，继续编辑消息。这个看似简单的流程，背后却隐藏着复杂的状态管理：当帮助对话框打开时，焦点应该从编辑器转移到对话框；当对话框关闭时，焦点应该回到编辑器；如果用户在帮助对话框打开时又触发了另一个对话框，应该怎么处理？ Crush的答案是栈式管理。在`internal/ui/dialog/dialog.go`中，我们看到了一个名为`Overlay`的结构体，它维护着一个对话框数组。 ```go // 基于 internal/ui/dialog/dialog.go:50-60 type Overlay struct { dialogs []Dialog } func (d *Overlay) OpenDialog(dialog Dialog) { d.dialogs = append(d.dialogs, dialog) } ``` 这个数组就像一叠透明胶片。每次打开新对话框，就在栈顶推入一张新胶片；每次关闭对话框，就从栈顶弹出一张。焦点始终在栈顶的对话框上，按键事件首先由栈顶处理，如果栈顶不处理，才传递给下一层。 > **栈式管理 (Stack Management)**: 一种处理多个重叠元素的设计模式，遵循"后进先出"原则。最新打开的对话框位于栈顶，拥有最高的优先级（焦点、按键处理）。这种设计确保了交互逻辑的清晰性和可预测性。 Dialog接口定义了三个核心方法：`ID()`返回唯一标识符，`HandleMsg()`处理消息并返回动作，`Draw()`将对话框绘制到屏幕上。这种设计遵循了Crush一贯的"Dumb组件"哲学——对话框只负责渲染和响应用户操作，不主动发起状态变更。 ```go // 基于 internal/ui/dialog/dialog.go:32-42 type Dialog interface { ID() string HandleMsg(msg tea.Msg) Action Draw(scr uv.Screen, area uv.Rectangle) *tea.Cursor } ``` 当主模型的`Update()`函数收到一条消息时，它首先检查是否有打开的对话框。如果有，消息会被传递给栈顶对话框的`HandleMsg()`方法。这个方法返回一个`Action`，告诉主模型应该执行什么操作——可能是关闭当前对话框，可能是打开另一个对话框，也可能是什么都不做。主模型根据这个动作更新状态，然后在下一帧的`View()`中重新渲染。 这套系统的精妙之处在于它的可扩展性。要添加一种新的对话框，只需要实现Dialog接口，然后调用`OpenDialog()`将其推入栈中。Crush中的确认对话框、输入对话框、帮助对话框、设置对话框，都是通过这种方式实现的。每种对话框专注于自己的职责，不需要知道其他对话框的存在，也不需要关心整体的栈管理逻辑。 ## 🔗 4.3 LSP与MCP集成 现代开发工具不再是孤岛。当你在Crush中打开一个Go文件，你期望看到语法高亮、错误提示、自动补全——这些功能背后，是LSP（Language Server Protocol）在工作。当你需要访问外部工具、查询文档、调用API——这些能力背后，是MCP（Model Context Protocol）在工作。 LSP是微软为Visual Studio Code开发的一种协议，它将代码智能功能（诊断、补全、跳转）从编辑器中分离出来，放到独立的服务器进程中。Crush通过集成LSP，获得了与VS Code同等的代码分析能力。在`internal/ui/model/lsp.go`中，我们看到了LSP状态的渲染逻辑。 ```go // 基于 internal/ui/model/lsp.go:17-21 type LSPInfo struct { app.LSPClientInfo Diagnostics map[protocol.DiagnosticSeverity]int } ``` 每个LSP服务器都有一个状态：启动中、已连接、错误、已禁用。Crush会在侧边栏显示这些状态，并实时更新诊断计数——错误有多少个、警告有多少个、提示有多少个。当用户在聊天中提及某个文件，Crush可以快速展示该文件的诊断信息，帮助用户理解当前代码的健康状况。 > **LSP (Language Server Protocol)**: 一种将代码智能功能（诊断、补全、跳转、重构）标准化的协议。编辑器作为客户端，语言服务器作为服务端，两者通过JSON-RPC通信。这种设计使得一种语言服务器可以为多种编辑器提供服务，大大降低了开发成本。 MCP则是Anthropic提出的一种新协议，用于将AI助手与外部工具连接起来。Crush通过MCP可以访问文件系统、运行命令、查询数据库、调用API——这些能力使得AI助手不再局限于"聊天"，而是能够真正地"做事"。在`internal/ui/model/mcp.go`中，我们看到了MCP状态的展示逻辑。 ```go // 基于 internal/ui/model/mcp.go:37-49 func mcpCounts(t *styles.Styles, counts mcp.Counts) string { var parts []string if counts.Tools > 0 { parts = append(parts, t.Subtle.Render(fmt.Sprintf("%d tools", counts.Tools))) } if counts.Prompts > 0 { parts = append(parts, t.Subtle.Render(fmt.Sprintf("%d prompts", counts.Prompts))) } // ... } ``` 每个MCP服务器都报告它提供的工具数量、提示模板数量、资源数量。用户可以通过侧边栏了解当前有哪些工具可用，哪些资源可以被访问。这种透明性是Crush设计哲学的一部分——用户应该知道AI助手在做什么，能够做什么。 LSP和MCP的集成展示了Crush的一个重要设计原则：延迟加载。LSP服务器不是在Crush启动时就全部启动，而是在用户打开相关文件时才按需启动。MCP服务器同样如此，只有在实际需要时才会被激活。这种设计确保了Crush的启动速度——用户不需要等待数十个服务器初始化完成才能开始使用。 这种"懒加载"的设计需要精心的状态管理。在`internal/ui/model/ui.go`中，我们看到了`lspStates`和`mcpStates`两个映射表，它们分别记录了每个LSP和MCP服务器的当前状态。当状态变化时，Crush会发送一条消息，更新这些映射表，然后触发重新渲染。整个过程遵循Bubble Tea的消息循环模式，确保了状态的一致性。 从架构角度看，LSP和MCP代表了两种不同的集成模式。LSP是"输入管道"——它将代码信息输入到Crush中，帮助AI理解用户的代码上下文。MCP是"输出管道"——它将AI的意图输出到外部世界，执行实际的工具调用。这两种管道共同构成了Crush的"智能骨架"，使得它不仅是一个聊天界面，更是一个真正的开发助手。 > 📝 **核心发现：** 第四章展示了Crush如何将前三章的理论转化为实战能力。响应式布局通过120/30断点实现终端窗口的动态适配；Dialog系统通过栈式管理解决多对话框的焦点和层级问题；LSP/MCP集成通过延迟加载和状态映射，将外部能力无缝融入TUI环境。这三项高级实践共同构成了Crush作为现代AI助手的技术基础。