企业官网建设流程全解析

终端快捷指令这件事，我拖了很久才动手，起因特别朴素：某天下午我统计了一下自己的命令历史，发现前二十条命令占了全部输入的六成以上，其中git status、ls -al、cd到那几个固定目录的组合反复出现。也就是说，我每天有相当一部分键盘敲击是纯粹的低水平重复。真正让我下决心整理一套自己的终端快捷指令，是某次连着处理十几个仓库的发布检查，手滑把一个路径打错，命令跑在了错误的目录里，白忙了半小时。从那天起，我开始把“敲得手酸”和“容易敲错”这两类命令，一条条改成自己维护的快捷指令，用 shell 的别名、函数和少量脚本攒成一套可复用、可备份、可分享的小工具集。这篇内容就是这套东西的完整复盘：哪些命令值得缩短、alias 什么时候会撞墙、函数怎么写才不容易翻车、配置文件为什么在有些机器上不生效、危险操作怎么加保险栓、启动变慢了怎么查。只要你在终端里干过活，哪怕目前只会cd和ls，都能从里面挑几条直接抄回去用。

1. 先算清楚哪些命令值得变成快捷指令

1.1 用频率和出错成本双维度筛选，而不是凭感觉

很多人第一次整理快捷指令，凭的是一时冲动，看到什么顺眼就加一条，结果是 alias 文件越写越长，真正高频的那几条反而不在里面。我后来固定用两个维度来筛：单位时间内的调用次数，以及打错一次的代价。前者决定省不省力，后者决定该不该防。

调用次数很好拿。如果你用的是 bash，history | awk '{print $2}' | sort | uniq -c | sort -rn | head -30就能看到前三十名；zsh 带HIST_STAMPS之类的配置也能做类似统计，或者干脆用fc -l 1拉出全量历史再管道处理。我自己的统计结果里，ls系的变体、git系的只读命令、几个固定目录的跳转、日志查看（tail -f加固定路径）稳居前列。

出错成本这一项更值得花时间想。有些命令敲错了顶多报个错，比如ls拼成lss；有些命令敲错了会真的出事，比如路径写错导致在错误目录里执行rm、分支名敲错导致推到错误分支、端口写错导致连到错误的测试环境。这类命令即使频率不算最高，也应该优先做成快捷指令，因为快捷指令的另一个价值是把易错的变量固化下来，而不是单纯图省事。

我一般的判断标准是这样：

这张表的实际用处，是防止我把时间浪费在第四行上。我见过有人给一条一年用一次的命令写了个二十行的包装函数，最后自己都忘了参数是什么，还得翻配置文件才能用，这就本末倒置了。

1.2 缩短的前提是别人和你自己都还看得懂

有一条我认为比省时间更重要的原则：快捷指令的名字必须能在一秒内被回忆起来。很多人喜欢把命令缩成一个字母，g、d、x各来一个，短期记忆里确实快，但过两周换台机器，或者换一个终端窗口，你会盯着空白的提示符想不起来x到底是干什么的。

我现在的命名习惯是“动词加对象”，长度控制在两到四个字符的英文缩写加上必要的分隔，比如gs表示 git status，gd表示 git diff，ll表示长列表，take表示建目录并进入。确实有例外，比如mkcd这种已经形成社区惯例的组合，就直接沿用，因为它是可预测的。

还有一点，加别名的时候要顺手在配置文件里写一行注释说明用途和来源。别小看这一行，我之前有一次在一台旧笔记本上看到自己两年前写的alias pl='...'，完全想不起来是干什么的，最后是靠注释里的“打印某个固定服务的日志”才回想起来。注释的成本是几秒钟，收益是半年后不用重新推理。

注意：给已有命令做同名覆盖时要格外克制。比如把ls直接 alias 成ls -alF，看起来省事，但你在脚本里调用ls时拿到的也会是带-a和-F的输出，脚本的解析逻辑很可能因此崩掉。交互和脚本是两套上下文，这一点后面还会细说。

1.3 一批可以直接抄走的初始清单

如果你是第一次系统整理，我建议从一个很小的集合开始，跑上一周，觉得顺手再扩。下面这份是我自己在多台机器上稳定保留了两年以上的基础项，几乎不涉及风险操作：

# 文件与目录 alias ll='ls -alFh' alias la='ls -A' alias ..='cd ..' alias ...='cd ../..' alias path='echo -e "${PATH//:/\\n}"' # git 只读类 alias gs='git status -sb' alias gd='git diff' alias gds='git diff --stat' alias gl='git log --oneline --graph --decorate -n 20' alias gb='git branch -vv' # 日常查看 alias ports='netstat -tunlp 2>/dev/null | grep LISTEN' alias now='date "+%Y-%m-%d %H:%M:%S"'

这里有几个细节值得说。ls -alFh里的h是让文件大小以人类可读的方式显示，处理日志和构建产物时比看字节数直观得多；git status -sb里的-s是短格式、-b是显示分支信息，输出只有两三行，比默认的长篇提示舒服很多；path那条用了 bash 的参数替换${PATH//:/\\n}，把冒号分隔的路径拆成一行一条，排查“为什么这个命令找不到”时非常有用。

我没有把cd本身做任何覆盖，因为cd是 shell 内建命令，行为极其稳定，覆盖它带来的收益远小于风险。目录跳转我是用另一套方案解决的，后面会讲。

2. alias 撞墙之后，函数才是真正的主力

2.1 三种必须从 alias 升级成函数的场景

alias 的本质是文本替换，它在解析阶段就把你输的字符串换成了另一串字符，所以它天然做不了三件事：接收和转发参数、做条件判断、串联多步操作。我用一条经验来判断：只要你的需求里出现了“如果”“然后”“把上一个的结果传给下一个”这类词，就说明该写函数了。

具体来说，下面三种情况我遇到过很多次，每次都是 alias 无能为力：

第一，需要带参数。比如我想让日志查看命令支持指定行数，tail -n 50 -f /var/log/xxx.log里的 50 是变量。alias 做不到，函数一行就能搞定。

第二，需要组合多步。典型的是“建目录并进入”，mkdir和cd是两条命令，中间还得判断建目录有没有成功，失败就不该切过去。

第三，需要前置校验。比如某个命令必须在 git 仓库根目录执行，函数里可以先判断当前目录是不是仓库，不是就直接给出人话提示并退出，而不是让用户看到一大段 git 的报错。

顺带说一个容易忽略的点：alias 在非交互式 shell 里默认是关闭的（bash 的expand_aliases选项），所以脚本里用不了 alias。函数在这方面的限制少很多，只要定义被 source 进来就能调用，这也是我把主力迁到函数的原因之一。

2.2 从两个最小可用函数开始改造

先看最经典的那个：

mkcd() { if [ -z "$1" ]; then echo "用法: mkcd <目录路径>" >&2 return 1 fi mkdir -p -- "$1" && cd -- "$1" || return 1 }

这个函数有四个地方是我特意加的。-z "$1"判断参数为空，避免用户什么都不传时mkdir -p报一个莫名其妙的错误；>&2把提示打到标准错误，这样在管道里调用时不会污染正常输出；--是为了处理以短横线开头的目录名，虽然少见，但加上没有成本；最后的|| return 1让函数在失败时返回非零状态码，这样它才能被&&正确串起来。

再看一个处理 git 日志的：

glog() { local count="${1:-20}" case "$count" in ''|*[!0-9]*) echo "参数必须是数字" >&2; return 1 ;; esac git log --oneline --graph --decorate -n "$count" }

这里的${1:-20}是“有参数用参数、没参数用默认值”的写法，local保证变量不会泄漏到当前 shell 里污染其他函数。那个case分支是参数校验，防止用户敲了glog abc之后看到 git 报错说-n后面不是数字。这类校验写起来只多三行，但能省掉很多“为什么报错”的困惑。

写函数的时候还有一个通用建议：尽量用local声明所有中间变量。我早期写函数不声明局部变量，结果一个叫dir的临时变量把外面正在用的同名变量覆盖了，排查了快二十分钟才定位到。shell 没有块级作用域，函数的变量默认是全局的，这个坑值得每个人都踩一次然后记住。

2.3 把函数写稳的几个固定套路

写得多了会发现，能稳定用几年的函数，结构上高度相似，基本都是这四段：参数校验、变量准备、主逻辑、结果反馈。我把它当成一个模板来套，出错率明显下降。

参数校验那段，除了判空和判类型，还要考虑“参数是个不存在的路径”这种情况。比如一个批量压缩的脚本，如果路径不存在，直接报No such file or directory也能用，但不如自己给一句“目录 xxx 不存在，检查一下拼写”来得清楚。

主逻辑那段，我有个习惯是把危险动作放在最后一步。比如“切到某目录然后执行清理”，顺序一定是先cd并确认成功，再执行清理；绝不能两个动作并行写在一行里用;连接，否则cd失败了后面照样会跑。

结果反馈那段不用做得多漂亮，但至少要让成功和失败可区分。我的约定是：正常输出走 stdout，错误和警告走 stderr，返回码 0 表示成功、非 0 表示失败。有了这个约定，函数就能被其他脚本安全调用。

# 综合示例：安全地在仓库根部执行命令 atroot() { local root root="$(git rev-parse --show-toplevel 2>/dev/null)" || { echo "当前目录不在 git 仓库内" >&2 return 1 } ( cd "$root" && "$@" ) }

这个atroot是我用得最多的函数之一。它先问 git 要仓库根目录，拿不到就直接退出；拿到之后在子 shell里切换目录再执行传入的命令，子 shell 的意义是不影响调用者的当前目录，执行完回到原位。这个技巧在处理“需要临时切目录”的场景时特别有用，比手动cd再cd回来安全得多。

3. 配置写对了，快捷指令才会在每个窗口都生效

3.1 登录 shell 与非登录 shell：不生效的头号原因

我见过最多的求助是“我明明写进.bashrc了，为什么新开窗口还是提示命令不存在”。九成情况下这不是写法问题，是配置文件放错了位置。shell 启动时读哪个文件，取决于它是登录 shell 还是非登录 shell，是交互式还是非交互式，这套规则在不同 shell 之间还不一样。

bash 的大致规则是：登录 shell 读/etc/profile和~/.bash_profile（或~/.bash_login、~/.profile中第一个存在的），非登录的交互式 shell 读~/.bashrc。而很多桌面环境下的终端模拟器，默认启动的是非登录的交互式 shell，所以它读.bashrc；但有些环境（尤其是某些桌面发行版的默认终端，以及远程登录场景）启动的是登录 shell，那就只读.bash_profile，.bashrc被跳过了。

zsh 的规则简单一些，交互式 shell 主要读~/.zshrc，登录 shell 还会额外读~/.zprofile和~/.zlogin。

解决办法很固定，就是让.bash_profile显式去加载.bashrc：

# ~/.bash_profile 里加这几行 if [ -f "$HOME/.bashrc" ]; then . "$HOME/.bashrc" fi

这样两种启动方式都会走到同一份配置，维护的时候只需要改一个文件。我早期的机器上就是因为没加这三行，导致在本地终端里一切正常、一换成远程会话就全部失效，白白怀疑了半天自己的函数写错了。

3.2 判断当前到底是什么 shell 在读配置

排查这类问题的时候，先别急着改文件，先确认现场。几个命令我几乎每天都用：

echo "$0" # 当前 shell 的可执行文件名 echo "$SHELL" # 登录 shell 的默认值 echo "$-" # 当前 shell 的选项，含 i 表示交互式 ps -p $$ -o comm= # 当前进程实际是什么

echo "$-"的输出里如果有i，说明是交互式 shell；ps -p $$看的是当前 shell 进程的真实名字，比$SHELL更可靠，因为$SHELL只是记录你的默认登录 shell，你完全可能在里面手动起了另一个 shell。

还有一个小技巧：在配置文件里临时加一行echo "loaded: $0"，然后开一个新窗口看它有没有打印出来。这招很土，但定位“到底读没读这个文件”特别快，比翻文档快得多。确认之后再把这行删掉。

注意：配置文件是会被反复执行的，所以里面不要放有副作用的命令。我见过有人在.bashrc里写了一行创建目录，结果每开一个窗口就执行一次；也见过在里面写cd到某个目录，导致所有新窗口都从那个目录开始。配置只应该做定义（变量、别名、函数、PATH），不该做事。

3.3 拆成模块文件，让快捷指令可以按领域维护

当快捷指令超过三十条，单文件就开始难找了。我现在的做法是按领域拆成多个小文件，放在一个统一目录下，主配置里用一个循环批量加载：

# 目录结构 # ~/.config/shell/aliases.fs.sh # ~/.config/shell/aliases.git.sh # ~/.config/shell/functions.fs.sh # ~/.config/shell/functions.git.sh # ~/.config/shell/env.sh # ~/.bashrc 里加载 for f in "$HOME"/.config/shell/*.sh; do [ -r "$f" ] && . "$f" done

这个循环里有三个细节。[ -r "$f" ]判断可读，避免某个文件权限不对时整段报错；路径里的*.sh加了引号以外的部分是有意为之，"$HOME"/.config/shell/*.sh这种写法让$HOME被引号保护但 glob 仍能展开；用.（等价于 POSIX 的source）而不是直接执行，因为执行会开子进程，定义就丢了。

拆文件之后，好处立刻显现：改 git 相关的快捷指令只动functions.git.sh，出问题的时候回滚范围也小。而且这套目录可以直接放进版本管理，换机器的时候 clone 下来再建立软链接就行，后面会讲具体做法。

4. 给危险操作加保险栓：删除与批量操作怎么写

4.1 别把rm覆盖成rm -i，换个名字更好

给rm加交互确认是个流传很广的建议，但我实测下来效果很差，原因有两个。一是习惯会被训练坏：你连续按了几百次y之后，确认提示就变成了无意识的回车，等真正危险的那一次出现时，手指比大脑快。二是破坏可移植性：你在别人的机器上、在容器里、在 CI 脚本里敲rm，期望的行为和实际行为不一致，出问题的时候非常难查。

我后来采用的是“新名字 + 显式意图”的方案：保留原生的rm不做任何改动，另外提供一个叫trash的函数，把文件挪到一个固定目录而不是真删除。想用保险的时候就敲trash，这个动作本身就是一次显式确认。

trash() { local base="$HOME/.local/share/trashbox" mkdir -p "$base" || return 1 [ "$#" -eq 0 ] && { echo "用法: trash <路径>..." >&2; return 1; } local target dest for target in "$@"; do if [ ! -e "$target" ]; then echo "跳过（不存在）: $target" >&2 continue fi dest="$base/$(date +%Y%m%d-%H%M%S)-$$-$(basename -- "$target")" mv -- "$target" "$dest" && echo "已移入回收区: $dest" done }

这个实现里有几个考虑。时间戳带上进程号$$，是为了防止同一秒内多次调用产生重名覆盖；continue而不是return，是因为批量场景下某一个路径不存在不该中断整批；--依然是防短横线开头；每次移动都打印目标路径，方便事后反悔时找回来。

回收区需要定期清理，我的做法是再写一个小小的辅助函数，列出超过 N 天的条目并让用户确认后删除。这一步没有必要做得很智能，因为它本身就是低频操作。

4.2 批量操作先“干跑”，把结果打印出来再执行

批量重命名、批量替换、批量转换格式，这类操作出事之后的恢复成本极高，我的固定做法是所有批量函数都必须先支持干跑。实现方式很简单，加一个环境变量或者一个-n参数，为真时只打印将要执行的动作，不实际执行。

batch_rename() { local dry=0 if [ "$1" = "-n" ]; then dry=1; shift; fi local f new for f in *; do case "$f" in *.txt) ;; *) continue ;; esac new="${f%.txt}.md" if [ "$dry" -eq 1 ]; then echo "[dry-run] $f -> $new" else [ -e "$new" ] && { echo "目标已存在，跳过: $new" >&2; continue; } mv -- "$f" "$new" fi done }

这个函数的关键在于干跑分支和执行分支共用同一套计算逻辑，只有最后一步动作不同。如果干跑和执行是两段独立代码，那干跑就失去意义了。还有那个“目标已存在就跳过”的判断，批量重命名最容易出的问题就是两个源文件映射到同一个目标名，后一个把前一个覆盖掉，加上这行判断就能避免。

我自己的操作流程固定是三步：先-n跑一遍看输出，确认映射关系没问题；再挑一个子目录小范围实跑；最后才全量执行。这三步看起来慢，但比起误覆盖一批文件之后再想办法恢复，快太多了。

4.3 危险动作前先打印上下文，让人有机会停下来

还有一个便宜但极其有效的技巧：在执行不可逆操作前，把当前环境和目标打印出来。比如一个清理构建产物的函数，在执行删除之前先打印“当前目录、将要删除的路径列表、总大小”。这个输出不但能让人在按回车前多看一眼，还能在事后复盘时提供线索。

clean_build() { local dir="${1:-.}/dist" [ -d "$dir" ] || { echo "目录不存在: $dir" >&2; return 1; } echo "当前目录: $(pwd)" echo "将清理: $dir" echo "占用空间: $(du -sh "$dir" 2>/dev/null | cut -f1)" printf "确认清理？输入 yes 继续: " local answer read -r answer [ "$answer" = "yes" ] || { echo "已取消"; return 1; } rm -rf -- "$dir" }

要求输入完整的yes而不是按y，是有意的：它强迫你读一下屏幕上的内容，而单个字母太容易被肌肉记忆带过去。这个设计在社区里被反复验证有效，值得抄。

5. 快捷指令一多，启动变慢怎么查

5.1 先量一下打开一个终端到底花了多久

配置越堆越多，最典型的症状是新开窗口明显变卡。这时候别猜，先测：

time bash -i -c exit time zsh -i -c exit

这两个命令模拟一次交互式启动然后立刻退出，输出的 real 时间就是启动开销。我一般的判断是：超过 300 毫秒就该看看了，超过 1 秒肯定有问题。注意要在同样的环境里多测几次取稳定值，第一次跑可能受缓存影响偏慢。

5.2 逐行定位是哪一行拖慢的

定位方法很简单粗暴但有效：在配置文件的每一段开头加分段的计时输出，或者更省事的做法是注释掉后半部分再测，二分法定位。文件不长的话，两三轮就能锁定到具体某几行。

常见的罪魁祸首有这么几个：

网络请求这一条我踩过，某次在配置里加了个“检查新版本”的脚本，结果在没有网络的环境下每次开窗口都要等超时，整整两秒。这种在配置里做网络动作的行为，我认为在任何情况下都不该有。

5.3 懒加载：把重的东西挂起来，用到再初始化

版本管理工具、补全框架这类东西，初始化动辄消耗几百毫秒，但它们并不是每次开终端都一定用得上。懒加载的思路是：先定义一个同名函数占位，等第一次真正调用这个命令时，才去加载真正的实现，加载完把自己替换掉。

# 以某个版本管理工具为例的懒加载骨架 mytool() { unset -f mytool # 这里放真正的初始化逻辑，比如 source 初始化脚本 . "$HOME/.mytool/init.sh" mytool "$@" }

第一次敲mytool时，执行的是这个占位函数，它把自己删掉、加载真正的实现、然后把参数转发过去；第二次敲的时候，走的就已经是真正的命令了。代价是第一次调用稍微慢一点，换来的是每次开终端都省下几百毫秒，这笔账我认为很划算。

补全框架也可以用类似思路。不过要提醒一句，懒加载会让“命令存在性检查”出现误判，比如command -v mytool在未初始化时会返回成功（因为函数存在），但实际功能还没加载。如果你的脚本里有依赖存在性检查的逻辑，这一点要留意。

6. 快捷指令不生效时的完整排查链路

6.1 从“命令能不能被解析到”开始往外查

遇到“命令找不到”或者“行为不对”，我按固定顺序往下走，基本五分钟内能定位：

第一步，type 命令名。这个命令会告诉你是别名、函数、内建命令还是外部文件，以及具体的定义。比如输出ll is aliased to 'ls -alFh'，说明别名生效了；输出ll is a function说明是函数；如果直接报not found，说明根本没定义。

第二步，command -v 命令名。这个比which可靠，因为它能正确处理别名和函数。很多人习惯用which，但which是外部程序，它并不知道当前 shell 里的别名和函数，经常给出误导性的结果。

第三步，确认配置文件是否被加载。回到第 3 节的办法，在配置里临时加打印，或者用echo $0加$-判断当前 shell 类型。

第四步，检查是不是被后面的定义覆盖了。比如你在两个文件里都定义了ll，后加载的那个会赢。用alias ll或者declare -f ll看最终生效的版本。

第五步，如果是函数，检查语法。bash -n 文件名可以做语法检查但不执行，shellcheck能发现更多问题，比如未加引号的变量、无用的local等。

我用一张对照表把常见现象和原因记下来，省得每次都重新推理：

6.2 bash 和 zsh 的语法差异导致的“玄学问题”

跨 shell 的兼容问题很隐蔽，因为错误往往不是报错，而是行为不一致。我遇到过的几个典型：

数组下标。bash 的数组下标从 0 开始，zsh 默认从 1 开始。一段在 zsh 里写得飞起的取参数代码，搬到 bash 里就全错位了。如果函数里要用数组，我现在的做法是能用"$@"就别用索引。

local在 zsh 和 bash 里都支持，但某些衍生 shell（比如某些精简过的环境）不一定有，写可移植脚本的时候要小心。

单词拆分。zsh 默认不对未加引号的变量做单词拆分，bash 会。这意味着同一行for f in $list，在两个 shell 里循环的次数可能不一样。结论只有一个：变量永远加引号，这样两边行为一致。

set -e的行为也有差异，在函数里、在条件判断里表现都不太相同。我个人的选择是不在交互配置里用set -e，因为它会让一些本可以继续的错误直接终止整个 shell，交互体验很差；需要严格模式的，放在独立脚本里。

验证兼容性最笨也最有效的办法，是在两个 shell 里各跑一遍：

bash -c 'source ~/.config/shell/functions.fs.sh; mkcd /tmp/testdir' zsh -c 'source ~/.config/shell/functions.fs.sh; mkcd /tmp/testdir'

跑通两遍，心里就有底了。

7. 把这套东西管起来：备份、迁移与分享

7.1 用版本管理托管配置，用软链接安装

快捷指令攒到一定规模，它就已经是资产了，必须进版本管理。我的做法是把整个~/.config/shell/目录放进一个仓库，然后在目标机器上用软链接接上去：

# 建立软链接（先备份原文件） mv ~/.bashrc ~/.bashrc.bak 2>/dev/null ln -sfn "$HOME/repos/shell-config/bashrc" "$HOME/.bashrc"

ln -sfn里的-f是强制覆盖已有链接、-n是防止把链接当成目录进去创建。这两个参数一起用很有必要，否则在目标位置已经有链接的情况下，可能生成一个嵌套的怪东西。

用软链接而不是复制，好处是改一处立刻全局生效，不用记得“改完要同步”。坏处也有，就是万一仓库目录被挪走，配置就断了。所以我一般会在.bashrc开头加一个小小的自检：

if [ ! -f "$HOME/repos/shell-config/bashrc" ]; then echo "警告: 配置文件路径异常，请检查 shell-config 仓库位置" >&2 fi

这种自检不解决根本问题，但能在出问题时给出一句人话提示，省得对着诡异的报错发呆。

7.2 分享给别人时的命名冲突与安装脚本

把自己的配置分享出去，最大的风险是命名冲突。你定义的gd、gl、gs，对方可能已经有同名的东西，直接覆盖会让对方困惑甚至出事。我的处理方式是给所有自定义命令加统一前缀，比如都用x开头，这样冲突概率极低，也一眼能看出这是来自哪套配置。

另外，安装脚本要做得保守一点：不直接覆盖已有文件，先备份；加载配置时不要无条件 source，让用户自己选择启用哪些模块。下面是一个我常用的最小安装骨架：

#!/usr/bin/env bash set -u target="$HOME/.config/shell" mkdir -p "$target" for f in aliases.fs.sh aliases.git.sh functions.fs.sh functions.git.sh; do if [ -e "$target/$f" ]; then echo "已存在，跳过: $target/$f" else cp "modules/$f" "$target/$f" echo "已安装: $target/$f" fi done echo "下一步：在 ~/.bashrc 中加入加载循环"

注意这里用的是set -u而没有用set -e，因为安装过程里某些“失败”是可接受的（比如文件已存在），用-e会让脚本提前退出。

提示：分享配置时，记得检查里面有没有硬编码的本地路径、内部服务地址、个人目录名。我之前分享过一次，忘了删一条写了内部路径的别名，对方用了之后一直报错，还以为是脚本有 bug。现在我的做法是把这类信息统一提取到env.sh，主仓库里只保留一个示例文件。

这套东西我从最初的十几条别名，慢慢演进到现在按领域分的四五个模块文件，中间删掉的比留下的多。有些当时觉得很聪明的写法，用了一个月发现反而增加了认知负担，就果断去掉了。快捷指令的价值不在于多，而在于你敲下去的时候不用想，也不会担心它出错。如果你现在还没开始，我建议就从今天统计出来的前五条高频命令开始，先做 alias，遇到带参数或者需要判断的再升级成函数，一步一步来，不用一开始就追求完整。