1. 项目概述1.1 OpenShell 是什么OpenShell 是一个面向日常开发与运维场景的开源终端增强工具本质上是一个轻量级的跨平台 Shell 环境启动器。它不试图取代你现有的 Bash、PowerShell 或 Zsh而是在这些已有的 Shell 之上做一层强化外挂把高频操作、常用路径、指令模板、批量任务全部收敛到一个交互式界面里。这个想法源自一个很朴素的痛点——每天打开终端后真正花在敲命令上的时间其实没多少大量时间消耗在重复切换目录、拼写参数、回查历史命令这些琐碎动作上。OpenShell 想把这一层杂物清掉。我最初接触这个项目时并没有期待它能有多少新东西毕竟终端工具这个赛道已经挤满了各种全家桶。但实操下来发现它和其他工具的原则分得很清楚不做新的语言解释器不接管系统权限就是一个配置驱动的快捷键中枢和命令仓库。你写好一次的命令组合之后按几个键就能复用。对刚入行的开发者来说它降低了记忆成本不用背一堆冷门参数就能把活干完对老手来说它省掉的是肌肉记忆之外的反复确认。1.2 这个项目解决了什么问题OpenShell 解决的核心问题是命令使用的信息过载。普通终端用户通常只掌握自己最常用的那二三十条命令而系统里可用的命令和参数组合数以千计。每当遇到稍微复杂一点的操作比如批量改文件名、压缩特定目录下的日志、按时间范围清理缓存大多数人第一反应是去搜索引擎现查语法再回终端里手敲验证。OpenShell 把这类高频场景预置成模块化的命令块用户只需要选定目标路径和参数值剩下的交给配置好的模板执行。它另外一个很实际的价值在于环境一致性。很多人在本地 Mac 上写命令跑得欢到了远程 Linux 服务器上就抓瞎因为 Shell 类型不一样、路径不兼容、工具链缺失。OpenShell 的配置文件可以跟着项目走一份配置在 zsh、bash、PowerShell 下都能加载。团队协作时把配置文件扔进仓库里新人拉下来就能获得和团队一致的命令环境不需要单独花时间搭工具链、整理别名列表。这也是我认为它最值得推荐的一点——它把个人习惯变成了团队约定。2. 核心功能拆解与配置体系2.1 功能模块布局OpenShell 的功能架构可以理解为三个层级入口层、调度层、执行层。入口层是你在终端里启动 OpenShell 后看到的交互界面它提供候选命令列表、参数联想和快捷键绑定调度层负责解析你选中的命令块把模板中的占位符替换成你输入或选择的实际值然后根据预设策略决定是直接执行还是进入确认步骤执行层则直接调用底层的系统 Shell 完成真实操作并把输出结果格式化呈现。这三个层级各自承担的任务非常清晰但有一个容易被忽视的设计细节执行层不会把命令直接交给系统 Shell。OpenShell 会把展开后的命令先拆成 token做一次安全性检查再放行执行。这个检查包括敏感路径比如/、~下的危险操作、破坏性参数比如rm -rf搭配变量为空的情况以及命令模板中未替换干净的占位符。第一次使用时我觉得这个步骤有点多余但后来确实遇到过变量没填入就差点执行误删的情况那一瞬间觉得这个守护机制很有价值。功能模块方面OpenShell 内置了几大块文件操作、系统信息、网络诊断、日志管理、服务进程、Git 辅助。每一块下面有若干预置命令块同时也支持用户自定义。它不会像某些工具那样把几百个命令平铺在菜单里而是按照场景来分组。比如你要处理日志进入日志模块后看到的是按时间区间抽取日志、统计日志关键字出现次数、轮转压缩、清理过期日志每一个命令块都有清晰的中文描述和参数提示而不是一堆让人望而生畏的 flag。2.2 配置文件结构与语法解析OpenShell 的配置采用 YAML 格式这个选择很务实——比 JSON 易读、比 INI 更结构化注释也很友好。一个典型的配置文件由三部分构成全局设置、命令块定义、快捷键映射。全局设置里可以指定默认 Shell 类型、超时时间、日志等级、是否开启确认模式等。命令块定义是核心每个命令块包含五个字段名称、描述、命令模板、参数定义、执行模式。名称是你在交互界面看到的条目描述是它的功能说明命令模板是真正会执行的 Shell 指令参数定义则声明了模板中哪些位置需要用户填值。执行模式分为三种直接执行、确认后执行、只生成命令不执行。第三种模式很实用适合当你只是想让 OpenShell 帮你拼好一条复杂命令然后拿它去做教学演示或二次加工。参数定义部分支持四种类型普通字符串、路径选择器、枚举值、数字。路径选择器会自动联动文件系统做补全和存在性校验枚举值则从一个预置列表中选一。这层抽象的价值在于用户不需要记得某个参数的取值范围或文件路径的具体位置系统会在交互界面里一步步引导。我在配置自己的一套日志清理命令时把时间范围参数定义成枚举值比如近 1 小时、近 6 小时、近 24 小时、近 7 天用起来非常顺滑不需要手动换算时间戳。2.3 跨 Shell 适配原理很多终端增强工具都死在换一台机器就失效这个问题上OpenShell 的跨 Shell 策略算是比较成熟的。它没有尝试统一不同 Shell 的语法差异而是采取协议翻译的思路。假设你的命令模板里写了ls -lah在 Windows 的 PowerShell 下OpenShell 会翻译成Get-ChildItem -Force | Format-List在 Linux 的 bash 下则原样执行在 macOS 的 zsh 下会保留原样但调整输出编码。这个翻译过程依赖一个内置的命令等价表表格维护了两百多条常用命令在不同 Shell 下的对应关系。当然这个表不可能覆盖所有命令对于未收录的命令OpenShell 的策略是优先执行原命令如果报错则给出候选建议。这个设计避免了一个常见问题——翻译过度带来的混乱。与其把所有命令都硬转换成目标平台的版本不如只在已知有差异的范围内做翻译其余交给原始 Shell 去处理反而更加可靠。对于用户自定义的命令块OpenShell 允许你在配置里为不同平台分别编写命令文本也可以只写一份通用命令然后依赖等价表自动翻译。实操中我的建议是涉及文件路径、权限操作等和系统耦合较高的指令分别写各平台的版本而像 Git 操作、文本处理这类通用性强的可以依赖自动翻译。这样既保证了正确性又减少了配置冗余。3. 实操流程与核心场景3.1 安装与初始化OpenShell 的安装方式根据平台有所区别。在 macOS 上最简单的是通过 Homebrew 直接安装一条命令搞定Linux 环境下可以下载预编译的二进制包解压后把可执行文件软链到/usr/local/binWindows 上则推荐用 Scoop 或直接下载 Zip 包解压。安装完成后不要急着用先用openshell init生成初始配置文件。这个初始化命令会做几件事检测当前系统的 Shell 类型、探测常用的工具路径Git、Python、Node.js 等、生成一份基础配置模板、创建命令绑定脚本。整个过程是交互式的会问你几个问题比如默认确认模式是否开启、是否启用网络诊断模块、终端 UI 风格偏好等。大概两分钟内可以完成。这里有个容易踩的坑初始化时 OpenShell 会把当前终端的环境变量快照写入配置包括PATH。如果你之后用brew或apt安装了新工具可能会因为 PATH 快照过期导致 OpenShell 检测不到新命令。解决方法是偶尔跑一次openshell refresh让它重新扫描环境或者手动在配置里追加路径。注意初始化工具会在~/.openshell/目录下生成配置文件和运行日志。这个目录不要随意删除里面包含了你所有的命令块定义和会话记录删了等于一切重来。3.2 配置第一个命令块快速收集系统状态为了让你有直观的感受我完整演示一个命令块的配置过程一键收集系统状态信息。这个命令执行后会把操作系统版本、CPU 负载、内存占用、磁盘空间、网络连接数、最近 10 条系统日志打包输出到一个文件里。在配置文件里新增如下命令块command: name: sys_info_collect description: 收集系统整体状态到指定文件 template: uname -a {output_file}; uptime {output_file}; free -h {output_file}; df -h {output_file}; ss -tuln | head -20 {output_file}; tail -10 /var/log/syslog {output_file} 2/dev/null || true; echo 系统状态收集完成: {output_file} args: - name: output_file type: path default: ~/system_report.txt description: 保存状态数据的文件路径 exec_mode: confirm注意到这个配置里做了两个细节处理。一是tail -10 /var/log/syslog后面加了2/dev/null || true这是为了防止在 macOS 或其他没有 syslog 文件路径的系统上报错导致整条命令链中断。二是exec_mode设置为confirm因为收集过程中会写入文件属于有一定副作用的操作执行前确认一次比较稳妥。保存配置后在 OpenShell 交互界面输入sys_info_collect系统会提示你填写输出文件路径回车确认后展开命令再次回车后执行。整个过程从调用到拿到报告不会超过五秒钟而手动敲这些命令怎么也要一分钟还容易漏行。3.3 高级用法条件分支与串联任务OpenShell 的命令模板支持一种轻量的条件语法。它不要求你写完整的 Shell 条件语句而是用if:和unless:前缀在模板行内声明条件。这个设计很聪明它把复杂的 Shell 逻辑收敛成模板的局部属性核心执行流程不会被条件语句的嵌套搞乱。举个例子我想实现一个智能备份命令如果目标目录存在就复制到备份路径不存在则先创建再复制并且统一加上时间戳后缀。在 OpenShell 里可以这么写command: name: smart_backup description: 带条件判断的目录备份 template: mkdir -p {backup_root}; cp -r {target_dir} {backup_root}/{target_name}_{timestamp}; echo 已备份至: {backup_root}/{target_name}_{timestamp} args: - name: target_dir type: path description: 要备份的目录 - name: backup_root type: path default: ~/backups description: 备份存放的根目录 - name: target_name type: string default: {basename(target_dir)} description: 备份目录的命名前缀 - name: timestamp type: string default: {date:YYYYMMDD_HHMMSS} description: 时间戳标记 conditions: - pre: test -d {target_dir} message: 源目录不存在任务终止 action: abort这个示例里有两个值得关注的地方。一个是参数默认值可以引用其他参数并调用内置函数比如{basename(target_dir)}会从目标路径里提取目录名{date:YYYYMMDD_HHMMSS}会生成格式化时间戳。这叫做参数值计算它避免了用户手动输入带有规律性的内容减少出错机会。另一个是conditions段定义了前置校验。在执行命令之前OpenShell 先运行test -d {target_dir}检查源目录是否存在如果没有则显示信息并终止任务。这种防御式编程的思路建议每个人在配置高频命令块时都采用——先校验再执行永远比事后补救来得舒心。除了条件分支OpenShell 还支持任务串联。你可以在一个命令块里引用另一个命令块的完成状态。例如先执行日志抽取再执行格式转换最后发起上传。每个环节的失败都会阻断后续任务并弹出明确的错误定位。对于运维场景里的多步骤操作这个能力可以省下大量人工盯盘的时间。3.4 团队共享的配置同步OpenShell 的配置文件是纯文本的 YAML这意味着天然适合放进 Git 仓库。我们的做法是在项目根目录建一个openshell/文件夹里面放config.yaml和templates/目录团队成员各自本地拉取后执行openshell import引入项目级配置。有一个关键点项目级配置和个人级配置同时存在时OpenShell 会做合并而不是覆盖。合并逻辑是项目配置优先加载然后加载个人配置个人配置会覆盖项目配置的同名命令块。这种约定带来的好处是团队统一规范和个人使用自由并不冲突。你可以保留自己的快捷键习惯同时也能使用团队预置的命令模块。在配置同步过程中最常见的麻烦是路径差异。比如团队里有人用 macOS有人用 Windows配置里的路径写法完全不一样。OpenShell 的做法是支持路径占位符{home}指当前用户的 home 目录、{os}指当前系统类型、{desktop}指桌面目录。你在配置里写{home}/logs在 Windows 上它会自动解析成C:\Users\当前用户\logs在 macOS 上解析成/Users/当前用户/logs。这个细节极大减少了团队协作时的路径冲突问题。4. 排查技巧与重要避坑4.1 高频故障命令块执行后无输出我自己在实际使用中遇到最多的异常是命令块触发后系统既不报错也没有任何输出就像石沉大海。排查这个问题第一步是看执行模式如果配置里exec_mode是直接执行而命令模板里又没有echo之类的输出语句那你当然看不到反馈。这属于配置习惯问题不算程序故障但会让人误以为没执行成功。通常我的处理方式是把执行模式改成confirm确认界面里 OpenShell 会展示完全展开后的命令文本这样我能看到占位符被替换成了什么值。如果确认界面显示的命令文本没问题执行后仍无输出那就要检查命令本身是否被内置安全检查拦截了。打开日志文件查看运行记录搜索Blocked或Warning关键字确认是否命中了敏感操作黑名单。提示如果某些命令你确实需要执行但 OpenShell 的安全机制总是拦截可以在命令块配置里加入allow_override: true跳过检测。但这相当于把安全防线人为拆除只推荐在完全信任命令来源、且确认参数值和执行路径没有问题的情况下使用。4.2 环境变量失效与 PATH 不完整另一个高频问题是我在终端里明明能用的命令通过 OpenShell 调用却说找不着。例如直接在终端里敲python3正常通过 OpenShell 跑却提示command not found。这往往是因为 OpenShell 的会话环境和你的普通终端会话环境存在差异——它启动时加载的 PATH 不包含 Python 的安装目录。我建议在此处做两步修复。第一步是用命令openshell doctor查看环境检测结果它会列出 OpenShell 当前会话里所有环境变量的路径集合对比你正常终端里echo $PATH的输出找出缺失项。第二步是在配置文件的全局设置里手动添加缺失的路径global: env: PATH: - append: /opt/homebrew/bin - append: ~/.local/bin - append: /usr/local/bin值得留意的是这个配置追加的是路径值而不是覆盖整个 PATH所以不会影响系统原本的路径顺序。修改完成后需要重启 OpenShell 会话才能生效。4.3 常见问题速查表我在使用过程中整理了一张问题对照表基本覆盖了容易被卡住的点。你可以把它打印出来贴显示器旁边遇到问题先查一遍现象可能原因解决方案命令块找不到或不在列表中配置文件语法错误导致加载中断执行openshell validate定位语法错误行参数补全不出现参数类型定义缺失或类型名拼错检查args下每个参数的type字段确认界面显示乱码中文编码在 Windows 终端不兼容执行chcp 65001切到 UTF-8 编码某条命令在 Windows 上报错等价表未收录该命令的 Windows 翻译手动为 Windows 平台添加win_command字段导入团队配置后个人快捷键失效合并顺序优先了项目配置在个人配置里重新声明同名命令块命令执行超时模板内含有类似交互式vi这类命令将对应命令块超时时间调大或改用只生成模式日志文件无限增长日志等级设置为debug且未清理将log_level改回info部署定时清理任务这张表里我想特别强调第三行中文乱码的问题。Windows 控制台的默认代码页通常不是 UTF-8导致 OpenShell 的中文界面文字在个别终端软件里显示成乱码。解决方案不只有chcp 65001如果你用的是新版 Windows Terminal也可以直接在配置文件里指定codepage: utf-8效果更加持久。4.4 定制高风险命令块的防御准则OpenShell 允许你定义任何命令包括删除、格式化、覆盖等高风险操作。我有几条防御准则首先所有涉及删除或覆盖的命令块必须设置exec_mode: confirm强制二次确认其次对于涉及路径通配符的命令在conditions段里校验路径拼接后的长度防止空路径或根路径误入最后凡是会调用rm、mkfs、dd等危险工具的命令在模板注释里写清楚用途和适用场景方便挂起的同事理解。这里有一个我亲身遇到过的事故我第一次配置批量清理测试文件时模板里写了rm -rf {target_dir}/*当时target_dir用了默认值~/test看起来没问题。但后来顺手改了一次配置把默认值改成了~/根目录。第二天再执行的时候安全机制检查弹出拦截提示我才注意到路径变化避免了把整个家目录清空的惨剧。所以配置文件里路径默认值这块我建议反复审查加绝对路径写明不给模糊空间留机会。5. 效率提升与进阶实战5.1 日常提效的十个配置建议我基于个人经验筛选了十个高频场景做了配置优化分享几个值得优先设置的。第一个是 Git 工作流命令集包括提交并推送、合并前检查、回滚上一次提交等这些操作在 OpenShell 里配置好参数引导后可以避免手动敲错 hash 值。第二个是 Docker 容器管理如查看活跃容器、清理悬空镜像、进入容器调试通过枚举参数选择容器 ID比在终端里反复查容器名加过滤命令要顺手得多。第三个是文本处理命令集覆盖批量替换文件内容、统计代码行数、提取日志中的 IP 信息。这类命令的模板写一次能用到各种项目里长期收益高。第四个是系统巡检脚本可以安排成定时任务执行OpenShell 负责生成命令和记录输出系统的 crontab 或计划任务负责定时触发。这个组合算是最省心的巡检方案不用额外装监控软件也能应付日常检查需求。为了给你一个更具体的参考我贴一个 Git 快速提交命令块的配置片段command: name: git_commit_push description: 快速提交并推送当前分支 template: git add -A; git commit -m {commit_message}; git push origin {current_branch} args: - name: commit_message type: string description: 本次提交的说明 - name: current_branch type: string default: {exec:git branch --show-current} description: 当前所在分支自动检测 exec_mode: confirm注意current_branch的默认值用到了内置的{exec:}前缀它会把一段命令的执行结果作为默认值。这里执行git branch --show-current自动获取当前分支你连手动输入分支名都省了。这个语法很高频我配置了十几个命令块都在用。5.2 与系统定时任务的联动OpenShell 的命令生成能力可以和系统任务计划配合实现无人值守的自动化。思路是用一个只生成命令不执行的命令块把完整的 Shell 命令输出到文件然后再用系统级的定时任务去执行这个文件。这么做的好处是定时任务本身只管执行而命令内容由 OpenShell 负责生成和更新命令变更时不需要改定时任务配置。举一个实际例子每天晚上整理下载目录过期三十天的临时文件自动清理。在 OpenShell 里定义清理命令块输出生成命令到~/scripts/clean_downloads.sh再通过 crontab 设定每天凌晨三点执行该脚本。日常需要调整保留天数或目录路径时只需改 OpenShell 配置下次生成时脚本就会更新crontab 无需任何改动。我在实践中总结到这个用法尤其在多人维护的环境里价值高。每个人都能通过 OpenShell 查看当前清理策略和配置历史不用再 ssh 上服务器猜那段 crontab 命令是谁写的。配置即文档命令块描述里写上维护人名字管理透明度会好很多。5.3 把重复性运维操作沉淀成模块OpenShell 真正提升效率的长期路径是沉淀。每次你手动执行了一连串多个步骤才完成的操作都应该思考能不能把它定义成命令块如果能就把步骤拆解、参数找出来、写成模板。刚开始可能会觉得写配置比手动敲命令还麻烦但积累到五十个命令块之后你会发现日常终端操作里百分之八十的场景都可以直接调用现成模块不再需要开搜索引擎查语法。我们的实践是每月最后一个周五做一次配置评审大家把过去一个月里重复做过三次以上的操作提交出来统一讨论沉淀成命令块。这个机制让团队的知识资产一点点积累新人来了之后也不需要问老同事这步怎么操作直接浏览 OpenShell 的命令列表就能找到方***验以命令块的形式流动起来。5.4 进阶实践个人命令库的模块化管理当命令块数量逐步增多之后把它们全部堆在一个配置文件里会变得很臃肿、难以维护。OpenShell 支持用import指令把多个 YAML 文件拼接成一个逻辑配置。比如我可以把文件操作、Git 操作、Docker 操作、日志处理分别拆分到四个文件里再在入口配置里统一导入global: imports: - openshell/modules/file_ops.yaml - openshell/modules/git_ops.yaml - openshell/modules/docker_ops.yaml - openshell/modules/log_ops.yaml拆分的好处不仅仅是目录清晰还能让每个子模块单独做版本管理。比如 Git 操作命令块的调整频率很高而日志处理模块可能半年都不动一次拆开之后提交历史互不干扰review 代码时也不会看到无关的改动。这个习惯是我在项目规模变大之后总结出来的早一点建立模块化意识后期维护成本会低很多。另外当你的命令块数量超过八十个之后建议在命名上建立统一的规范。我们的做法是采用领域前缀功能名称的格式例如git:push、git:reset-soft、docker:logs、log:extract、file:rename-batch。这样在交互界面里输入前缀就能快速过滤出相关命令不会出现几十个命令让你翻页找半天的尴尬。规范命名这个习惯越早养成越受益等命令库大了之后再统一改名是一件很痛苦的事。6. 安全架构与高级保障6.1 命令执行的安全沙箱机制OpenShell 在命令执行前会过一道三层检查。第一层是变量展开检查确认所有占位符都被成功替换没有残留的{...}结构防止半成品命令被执行第二层是路径合法性检查当命令中出现文件路径时系统会确认路径存在于允许的范围内并检测是否包含通配符加敏感目录的组合第三层是风险词匹配把命令文本分割成 token 后与风险规则库做匹配比如rm配合-f参数就会触发告警。有人可能会担心这套机制拖慢执行速度实际测试下来三层检查的总耗时在毫秒级别感知不到延迟。我自己的感受是它带来的安全感远超这点性能损耗尤其是在深夜处理批量任务时多一次防御检查真的能避免不少低级错误。很多终端工具追求极致的顺手和直接我反而觉得 OpenShell 这种多管闲事的特性是加分项——工具应该帮你兜底而不是把所有风险都留给使用者的肌肉记忆。在一个多云多环境的团队里这一步的价值会被放大。开发、测试、生产环境之间常有细微差异命令在某一个环境运行良好、在另一个环境却可能产生意料之外的连锁反应。有了统一的安全性检查你至少能在执行前获得一次自动化的风险提示从而有机会重新审视命令本身是否真的满足当前环境的要求。6.2 日志审计与操作追溯OpenShell 默认把所有执行的命令和结果写入运行日志包括触发时间、执行者、命令内容、参数值、执行结果码。这对运维场景尤其重要——出了问题之后可以准确回溯到当时执行了什么操作参数值是什么终止码是多少。我经历过一次线上事故排查靠的就是 OpenShell 日志里记录的精确命令内容省去了从终端历史记录里大海捞针找命令的环节。日志的保留策略也值得根据团队情况调整。默认是滚动保留最近三十天也可以配置指定文件保存路径和保留时长。对于有合规要求的业务环境建议把日志输出到独立的日志收集系统做长期归档这样配合审计需求时可以随时调取历史操作记录。从安全角度看操作可追溯是对团队所有成员的保护也是规范操作流程的基础支撑。6.3 敏感信息的脱敏策略在很多命令块里可能会涉及用户名、密码、令牌之类的敏感信息。OpenShell 提供了一套简单的脱敏机制配置里声明的敏感字段会在日志中自动以***替代不会记录真实值。同时敏感字段的值尽量不直接写在配置文件中而是通过环境变量或专用的密钥文件引用。在执行过程中展开的值会用${SECRET_PASSWORD}这类变量占位日志记录时自然就变成掩码。我觉得比较实用的一点是OpenShell 支持对敏感参数增加执行前确认强制选项。即使命令块本身设定为直接执行模式涉及敏感参数的项也会弹出确认提示提醒你检查即将使用的密钥或令牌是否正确。这个机制避免了一些因为环境变量配置错误而把测试环境密钥当生产环境密钥用出去的低级事故。安全的核心不是堆砌功能而是在每个可能出错的环节设置一层缓冲提示。6.4 最小权限原则的践行最后想聊一下权限控制的整体思路。OpenShell 本身不强制要求sudo权限大多数日常操作都以当前用户的权限完成。只有当你明确在命令模板里写了sudo它才会提升到管理权限执行。我建议遵循最小权限原则大多数命令块基于普通权限设计确需提升权限的命令单独标注并限制使用场景。你可以通过配置来管理哪些用户组允许使用哪些高危命令块把它当作简单的访问控制层。这个思路在一定程度上弥补了终端工具在权限管理层面的空缺可控性和安全性都会更上一个台阶。7. 实操经验总结7.1 关于习惯养成与配置积累使用 OpenShell 这段时间我最大的体会是它改变的不仅是效率更是工作方式。过去打开终端脑子里想的是下一步敲什么命令现在打开终端想的是哪个场景要处理然后在命令列表里找到对应模块。这种从记忆具体命令到维护场景能力的转变让操作更稳定、更可复用。建议不要把配置工作当成一次性的负担而是在日常使用中自然生长每处理完一个陌生操作花一点时间沉淀进配置里下次再遇到时就会轻松很多。7.2 最后的实用小技巧分享一个我一直在用的小技巧在 OpenShell 里创建一个名为help的命令块内容是一页你自己书写的高频命令速查表。当你想不起来某个命令块叫什么名字时直接输入help就能看到分类清单和说明。这个小技巧的好处是用自己的语言维护了一套个人速查系统不用依赖记忆力去背诵命令列表。OpenShell 的文本配置方式也便于随时增减项目配置多了之后不怕忘直接看一眼速查表就能快速找到要用的命令日常使用会顺畅很多。