Textual 终端应用构建指南
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @kunlungrowth/textual-tui-framework,用于构建基于 Textual 的 Python 终端 TUI 应用。
技能介绍
当终端工具复杂到脚本撑不住的时候
一个 Python 工程师最常见的困境:用 print 拼出来的 CLI,功能越多越像一坨命令行碎片。想做带表格、表单、多面板的内部运维工具,立刻撞上三道墙——刷新控制、样式管理、事件响应全靠手写,代码越写越脆。
Textual 的思路是把 Web 的成熟范式搬进终端:组件、布局、类 CSS 样式、事件驱动,但保持 TUI 应有的简约。本技能就是这套方法的工程化提炼。
四步把 TUI 搭出来
- 组件与布局:用
Widget和容器(Vertical/Horizontal/Grid)拼出界面结构,外观交给类 CSS 样式表声明,而不是在代码里到处调refresh()。 - 事件驱动交互:用
on_*方法响应按键、点击和消息,业务逻辑从渲染逻辑里拆出来,状态可测、可回放。 - 数据绑定:声明
reactive属性,状态变化时自动重渲染——这是替代手动刷屏的关键。 - 双端运行:同一套代码既能在终端跑,也能
serve到浏览器里访问,一次编写两端复用。
常见陷阱与适用边界
手动刷屏是性能杀手:反复 refresh() 只会造成闪烁和卡顿,正确做法是声明式状态。CSS 并非全支持:终端渲染引擎不认所有 CSS 属性,写法必须对照支持列表验证。重计算阻塞事件循环:耗时任务要丢进 worker 或异步协程,否则界面假死。别把 Web 应用整套搬进终端:终端的优势是简约,堆砌组件反而毁掉体验。
最后提醒:本技能是开发方法论而非官方文档替代品,复杂场景请以 Textual 官方文档为准,并保证退出清理和代码可维护性。
使用场景
- 运维团队要做一个多面板内部工具:左侧服务列表,右侧日志预览,还要能一键重启服务
- 开发者要把原来纯 print 输出的 CLI 升级成带表单和交互按钮的内部工具
- 数据工程师想用表格组件展示 Redis 实例的内存分布,支持排序和按节点过滤
- 团队要把一套 Python 内部工具同时部署到终端和浏览器,不想维护两套代码
适合人员
- 后台或平台工程师,想把零散的运维脚本整合成多面板、可交互的终端面板
- SRE 或运维开发者,需要用表格、表单等组件替换纯 print 的一次性命令行脚本
- 数据工具开发者,希望用 reactive 属性自动刷新表格状态,避免手动刷屏的繁琐
- 终端应用爱好者,想把 Web 后端能力以事件驱动的方式跑在 TUI 里,同时支持浏览器访问