colibri：用Go打造的轻量级项目初始化与模板渲染CLI工具

如果你跟我一样，一年里要新建十几次项目仓库，大概率会有这样的瞬间：打开终端，手指肌肉记忆般敲下 mkdir、git init、go mod init，然后开始搬运上一份几乎一模一样的 .gitignore、Dockerfile、Makefile、CI 配置和 LICENSE 模板。说实话，效率低到有点讽刺——我们自诩用工具解决重复劳动，但工程初始化的重复劳动却一直在手动完成。

有一段时间我把这些事塞进 Makefile 和 shell 脚本，脚本越长，维护成本越高，最终没人敢改。后来我干脆开发了一个小工具，当作个人内部开源项目维护，代号就叫 colibri。colibri 是法语里蜂鸟的意思，用这个名字做代号原因很简单：蜂鸟很小，飞行技术却非常精湛，还能悬停在空中精准地完成采集动作。这正是我想要的气质——一个足够小、足够快、只专注做一件事的命令行工具，替开发者把项目初始化、环境预检、模板渲染这些重复而繁琐的动作标准化。

这篇文章会从起名动机讲到核心架构，再从一次完整的实操案例讲到跨平台发布的踩坑记录。如果你经常起新项目、维护工程模板，或者正在考虑要不要自己写一个内部 CLI 工具，这篇应该能给你一点参考。

1. 被重复劳动逼出来的 colibri：起名、动机与边界

1.1 为什么叫 colibri，不叫 Hummingbird

起名这件事看似随便，实际很影响项目的调性。我最早列了 quickstart、wren、hummingbird、ruby-throat 一堆候选，最后定成 colibri。理由有三个。

第一，它短。六个字母，终端里敲起来手感好，tab 补全也不容易和其他命令撞。第二，它在项目代号里辨识度足够高。直接搜"hummingbird"，你会得到一堆同名框架、浏览器和库；搜"colibri"，竞品少得多，社区里出现这个名字时，基本不会有歧义。第三，蜂鸟的生物学特性太契合这个项目的定位了：翼展小、体重轻、代谢极快，却能悬停、倒飞，还能在花前精准停留。做开发工具也一样，体积不该是负担，能力应该来自设计精度，而不是堆积功能。

1.2 我实际遇到的痛点：三个高频场景

与其说我想做一个宏大平台，不如说是被三个具体场景反复折磨。

第一个场景是开新仓库。每次新项目落地，都要处理 .gitignore、LICENSE、README、.editorconfig、Makefile 这些"盖楼前的地基"。不同语言、不同团队规范，地基长得不一样，但每份我都要手动调整或复制粘贴。某个依赖库的 LICENSE 头写错年份的事，发生过不止一次。

第二个场景是环境一致性。团队里有人用 macOS，有人用 Windows，还有人用 Linux 容器。同一个项目，本地 go version 不一样、golangci-lint 没装、protoc 版本过旧，CI 里才爆出来。问题不难解决，但每个人的排查路径都绕远路。

第三个场景是模板漂移。我用过不少脚手架，但团队规范在变：CI 从 Jenkins 迁到 GitHub Actions，Dockerfile 从固定镜像改成多阶段构建，Makefile 的目标名换过好几轮。如果模板散落在个人目录和文档里，改了 A 忘了 B 太正常。

colibri 要解决的就是这三件事：快速生成规范工程、一键做环境预检、把模板版本化。剩下的，一概不做。

1.3 为什么不用现成脚手架

你说得对，这个领域早就有 cookiecutter、degit、yeoman，甚至企业内部有自己的一套脚手架服务。我一开始也在它们之间挑，最后还是会回到"自己写一个"这个决定，核心原因是控制权和组合性。

cookiecutter 很成熟，但它跑在 Python 环境下，很多 Java 和 Go 背景的同事本地压根没配 Python 环境。degit 只负责拉模板目录，不解决环境预检。yeoman 这类框架对一个小工具来说太重了，生成器生态的维护成本也不低。更关键的是，它们都很难在生成之前做一次完整的环境自检，也很难在生成之后自动执行构建验证。这两件事恰恰是团队日常高频需要的。

自己做的问题也现实：需要一个轻量、无依赖、单文件的二进制。不能要求每个开发者装一套运行时，也不该让curl | sh这种安装方式成为常态。所以，技术栈这里就基本锁定了。

1.4 给 colibri 划出的能力边界

工具最容易死在自己太想证明自己有用。我在项目 README 第一版就写清楚了 colibri 不做什么。

它不做全功能的构建系统，构建交给 Makefile 和 CI；不接管部署流程，部署是发布平台的事；不碰依赖管理和包管理，那是包管理器的工作；不做图形界面，终端就是它的主战场。colibri 只做四件事：new生成新工程、init在当前目录补全工程规范文件、preflight做环境预检、tidy清理项目中的模板痕迹和临时文件。

把边界写清楚有个附带好处：后续提需求的人看到 README 里明明白白写着"这些不做"，大部分不切实际的需求在提出来之前就被自己过滤掉了。

2. 把"小而快"落进架构：colibri 的核心设计决策

2.1 一个命令分发器的自我修养

colibri 本质上是一个命令分发器加任务编排器。它的核心循环不复杂：

1. 解析根命令参数，定位子命令
2. 加载配置文件，合并默认值
3. 按子命令执行对应任务链
4. 统一收集错误，输出可操作的提示，返回退出码

这个设计刻意保持了简单。每个子命令内部就是一个任务数组，任务之间可以并行也可以串行。比如preflight里检测多个工具版本，就是并行执行的；而new里创建目录再渲染模板再到执行构建验证，则是严格的串行链路。

Go 代码结构上，每个子命令是一个入口函数，内部调用若干任务函数，任务函数彼此独立，通过上下文结构体传递配置和中间结果。没有复杂的依赖注入，没有事件总线，就是一个朴素的函数调用链。对一个千行级别的工具来说，过度设计才是最大的风险。

2.2 选型对比：Go 为什么适合这类工具

我做一个开发辅助工具，最看重六件事：分发方式、启动速度、交叉编译、并发模型、依赖管理和静态链接。把这几个维度列成一张表，选择就非常清楚了。

Go 几乎没有短板，尤其是交叉编译和静态链接这两点，让发布一个跨平台命令行工具变得极其省心。Python 在开发效率上有优势，但要给每个用户装解释器和依赖，这对内部工具劝退成本太高。Rust 性能固然好，但对这个场景属于"能力溢出"，开发周期也会拉长。Shell 在简单场景很香，一旦涉及模板渲染、参数解析、跨平台路径处理，维护成本立刻失控。

另外有一件小事促使我用了 Go：标准库里的text/template和os/exec足够可靠。模板渲染和外部命令执行是这个工具的两条腿，标准库直接覆盖，不用再引第三方依赖。

2.3 插件机制的两阶段演进

早期的 colibri 没有插件，所有的任务逻辑都写死在命令里。后来发现一个问题：公司内部不同语言团队对"标准工程"的要求不一样，Go 团队想要 Makefile，前端团队想要 eslint 配置，Java 团队想要 Maven 结构。我不能为每个团队改一次主程序。

第一阶段的方案是在配置里声明步骤，也就是用 YAML 描述"先渲染哪些模板，再执行哪些命令"，主程序只负责解释执行。这个方案很快顶不住复杂定制，比如有人想在生成后修改文件内容的一部分，而不是简单覆盖。

第二阶段我引入了基于接口的注册式插件。主程序定义了一个Task接口，插件在初始化时把自己注册进任务表。这样每个团队把自己的定制逻辑做成独立包，主程序只保留通用任务。

type Task interface { Name() string Execute(ctx *Context) error } func Register(t Task) { tasks[t.Name()] = t }

我没用 Go 官方提供的plugin动态加载，原因是它跨平台支持受限，Windows 上没法用，而且插件和主程序的编译环境必须高度一致，这对内部工具来说维护成本太高。注册式插件虽然需要重新编译主程序，但对一个小团队或者个人项目来说，简单可靠比动态扩展更重要。

2.4 幂等是底线，不是加分项

我对 colibri 有一个硬性要求：同一个目录下重复执行colibri init，第二次运行时不能产生重复内容，也不能覆盖用户已经改过的文件。

初版实现简单粗暴：先删除再写入。然后我就被自己的工具坑了一次——同事在生成的 README 里补充了大量项目资料，重建模板时这些东西被清空了。从那之后，我把执行流程改成两段式：

1. 把要生成的文件先渲染到内存临时目录
2. 与目标文件逐个对比，内容一致就跳过，目标文件不存在就写入，内容不一致且有本地修改痕迹就提示用户

判断"本地是否有修改"我用了最朴素的方式：在生成的文件头部写入一行注释标记，例如# generated by colibri do not edit。对比时先看标记，有标记的内容差异可以直接覆盖并提醒；没标记说明文件被改过，就必须停下询问。

这个策略不是万能的，但它覆盖了绝大多数使用场景，也让 colibri 在团队里放心地进入了"可重复执行"的工作流。

3. 核心实现拆解：命令、配置、模板与错误处理

3.1 命令树的组织方式

colibri 的命令树设计得很传统，所有命令都挂在根命令下。colibri自身不带任何操作，直接执行会打印帮助信息。

主要的叶子命令有五个，它们的职责划分是反复调整过的：

doctor是后来加的。最早模板加载报错时用户完全不知道发生了什么，输出一堆堆栈吓跑了不少人。加了doctor之后，它能主动检查模板目录结构、配置文件语法、版本兼容性，把排查路径变成了自动化流程。

3.2 配置解析与字段校验

配置是 colibri 的核心，它决定了一个 profile 长什么样。我选 YAML 作为配置格式，因为它可读性好，对中文用户也友好，不需要像 JSON 那样纠结逗号。一个最小化的 profile 配置长这样：

name: golang-http version: 1.0.0 description: "Go HTTP 服务标准工程模板" output: dir: "." variables: projectName: "{{.ProjectName}}" moduleName: "{{.ModuleName}}" copyrightYear: "{{.Year}}" require: - command: go version: ">= 1.21" - command: git version: ">= 2.30" templates: - source: "templates/go-service/**" target: "{{.ProjectName}}/" - source: "templates/gitignore" target: "{{.ProjectName}}/.gitignore" hooks: afterGenerate: - run: "go mod tidy" cwd: "{{.ProjectName}}" - run: "go build ./..." cwd: "{{.ProjectName}}"

配置加载时我会做两件事：一是把字段结构体用默认值填充，比如output.dir没写就默认当前目录；二是做严格类型校验，不允许出现未知字段。未知字段往往是拼写错误，容忍它会在后面的任务链中产生莫名其妙的错误。校验失败时，配置解析器会指出具体是哪一行字段出了问题，而不是笼统地报一个"配置无法解析"。

3.3 模板渲染与占位符处理

模板层面我用了 Go 标准库的text/template，而不是引入更重的模板引擎。原因很简单：它支持{{.Variable}}的占位符写法，也支持if分支和range循环，对工程模板来说能力完全够用。特别实用的一个特性是自定义函数，我注册了一组内置函数，比如upper、lower、kebabCase、camelCase，用来转换项目名。

还有个很容易踩的坑要提醒你：如果你的模板里要生成 Go 代码，而 Go 代码里恰好有结构体嵌套或者 map 的定义，你会碰到{{ }}的冲突。比如模板里某个文件要包含map[string]string{{...}}，这段内容会被 text/template 误认为是模板指令。解决方式是给模板引擎设置自定义分隔符，或者用{{ "{{" }}来转义。我的建议是后者，因为它只影响局部文件，不用全局改配置。

t, err := template.New(name). Delims("{{", "}}"). Funcs(funcMap). ParseFiles(path)

3.4 多语言工程的结构差异怎么办

我不会为每种语言写死一套逻辑，而是用 profile 机制解决。一个 profile 就是一份描述目录结构、模板来源和环境要求的配置。Go 服务有golang-http这个 profile，前端项目有web-react，纯 Python 库有python-lib。

一个 Python 库的 profile 大致长这样：

name: python-lib version: 1.0.0 require: - command: python args: ["--version"] minVersion: "3.11" templates: - source: "templates/python/lib/**" target: "{{.ProjectName}}/" - source: "templates/python/pyproject.toml" target: "{{.ProjectName}}/pyproject.toml" hooks: afterGenerate: - run: "python -m venv .venv" - run: "pip install -e .[dev]"

profile 之间不共享模板目录，避免了不同语言模板交叉污染。这一层抽象让 colibri 的主程序完全不需要知道"Go 项目的结构应该是什么样"，它只负责按照配置去拉模板、生成文件、执行钩子命令。新增语言支持，就是加一个 profile 目录的事。

3.5 错误提示与日志：让用户一眼看懂

命令行工具最被忽视的就是错误提示。很多工具出错时输出一个堆栈，或者一句含糊的failed to create dir，用户根本不知道该改哪里。colibri 的每个任务函数都遵循一条规则：错误信息必须包含发生的位置、可能的原因、以及建议的修复动作。

例如预检阶段找不到go命令，我不是直接报"exec: go: executable file not found in $PATH"，而是输出下面这段：

[ERROR] 未检测到 Go 工具链 位置: preflight -> require.go 原因: 系统中没有找到 go 可执行文件 修复: 请先安装 Go 1.21 及以上版本，访问 https://go.dev/dl/

这里的输出还会带上退出码。colibri preflight失败时退出码是 1，方便 CI 脚本直接判断。成功的阶段用绿色对勾，警告用黄色三角，错误用红色方块。颜色在非 TTY 环境下会自动关闭，避免日志文件里出现一堆转义字符。

4. 动手跑通一个案例：一条命令生成 Go 服务标准工程

4.1 案例背景与目标结构

理论讲再多，不如实际跑一遍。这里我用 colibri 生成一个 Go HTTP 服务作为演示，目标结构是团队内部沉淀下来的一套比较标准的目录：

• cmd/api/main.go：程序入口
• internal/config/：配置加载逻辑
• internal/handler/：HTTP 处理器
• pkg/：对外可复用包
• Dockerfile
• Makefile
• .github/workflows/ci.yml
• README.md、.gitignore、LICENSE

这套结构不是 colibri 发明的，而是团队经过几个项目迭代出来的约定。colibri 的价值在于把这个约定从文档转成了可落地的模板。

4.2 定义 profile 配置

先把 profile 写好，放在 colibri 的模板目录下。配置文件里最值得注意的是hooks.afterGenerate，它会在文件生成完毕后自动执行go mod tidy、go build ./...和go vet ./...。这三个钩子保证了生成出来的工程不是一堆死文件，而是真能编译通过的。

name: golang-http version: 1.2.0 variables: projectName: "{{.ProjectName}}" moduleName: "{{.ModuleName}}" require: - command: go version: ">= 1.21" - command: git version: ">= 2.30" templates: - source: "templates/go-http/**" target: "{{.ProjectName}}/" hooks: afterGenerate: - run: "go mod tidy" cwd: "{{.ProjectName}}" - run: "go build ./..." cwd: "{{.ProjectName}}" - run: "go vet ./..." cwd: "{{.ProjectName}}"

4.3 执行与输出

执行一条命令，把整个工程建起来：

colibri new go-service \ --profile golang-http \ --name my-api \ --module github.com/example/my-api

正常情况下终端会输出下面这样的过程信息：

[OK] 环境预检通过: go v1.22.2, git v2.39.3 [OK] 渲染模板: cmd/api/main.go [OK] 渲染模板: internal/config/config.go [OK] 渲染模板: internal/handler/health.go [OK] 渲染模板: Dockerfile [OK] 渲染模板: Makefile [OK] 渲染模板: .github/workflows/ci.yml [OK] 运行钩子: go mod tidy [OK] 运行钩子: go build ./... [OK] 运行钩子: go vet ./... [INFO] 工程生成完成: ./my-api

每一步都有明确反馈，如果哪一步失败，它能精确告诉你是文件渲染失败还是构建命令失败。以前手动搭建这套东西至少要十分钟，现在一条命令加一次目光扫过，确认输出没有红色块就结束。

4.4 生成结果验证

生成完后，我通常还会手动检查两件事。第一是看目录结构是否完整，尤其是.github/workflows/ci.yml这种容易在复制粘贴中漏掉的文件：

my-api/ ├── cmd/ │ └── api/ │ └── main.go ├── internal/ │ ├── config/ │ │ └── config.go │ └── handler/ │ └── health.go ├── pkg/ ├── .github/ │ └── workflows/ │ └── ci.yml ├── Dockerfile ├── Makefile ├── README.md ├── .gitignore └── LICENSE

第二是重新执行一遍构建验证，跑go build ./...、go test ./...和golangci-lint run。这看起来和 profile 里的钩子重复了，但手跑一遍的意义在于验证"离开 colibri 之后，这个工程依然可以被标准工具链正常构建"。工具生成的东西不该对工具有依赖，这是底线。

4.5 这套流程对团队的意义

对团队来说，colibri 最大的价值不是省那十分钟，而是把规范变成了默认选项。新成员加入，不用再去翻一篇几十页的 Wiki 来了解"项目应该长什么样"，一条命令就得到一个符合规范的起点。更重要的是一次次迭代模板时，改动只用集中到模板仓库，团队里每个人生成的工程都是同步更新的，不会出现 A 的 Dockerfile 是旧版、B 的 CI 配置是另一版的情况。

我特别建议不要一上来就把完整的团队规范全部塞进模板。第一次使用只放你最在意的基础部分，比如构建流程、Lint 规则和 .gitignore。跑顺之后再逐步加，不然一个 profile 里几十个模板文件，排查问题会很痛苦。

5. 跨平台发布踩坑记录：我在四个平台上的实测笔记

5.1 交叉编译基础配置

colibri 的发布流程依赖 Go 的交叉编译能力，一条命令生成一个平台的二进制，不用在每个系统上单独搭构建机。

CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags "-s -w" -o dist/colibri-linux-amd64 CGO_ENABLED=0 GOOS=darwin go build -trimpath -ldflags "-s -w" -o dist/colibri-darwin-amd64 CGO_ENABLED=0 GOOS=darwin GOARCH=arm64 go build -trimpath -ldflags "-s -w" -o dist/colibri-darwin-arm64 CGO_ENABLED=0 GOOS=windows go build -trimpath -ldflags "-s -w" -o dist/colibri-windows-amd64.exe

CGO_ENABLED=0是我建议的默认值，它强制生成纯静态二进制，避免目标机器缺少 glibc 导致运行失败。-trimpath能去掉构建机上本地目录的路径信息，方便复现构建。-ldflags "-s -w"去掉调试信息，体积能缩小 30% 左右，对一个命令行工具来说压缩到十几 MB 是完全可接受的。

5.2 踩坑一：Windows 路径分隔符引发的连锁问题

第一个大坑出现在模板路径上。我的模板内部约定统一使用/作为路径分隔符，比如templates/go-http/cmd/api/main.go。这个写法在主流的 macOS 和 Linux 上没有任何问题，但到了 Windows 上，text/template 和文件写入库对路径的处理方式会和系统 API 产生冲突。

我第一次做 Windows 适配时，生成出来的目录嵌套全乱了，main.go被写到了一个名字里带反斜杠的文件夹里。排查到最后，问题出在两个地方：一是渲染模板时读取模板文件路径用的是filepath.Join，它会把/转换成\；二是目标路径在替换变量后没有做统一的规范化处理。

解决方案也不复杂：读取模板阶段统一用正斜杠，写入目标文件时才交给filepath.FromSlash转换。这样既保证了模板仓库在不同系统下看起来一致，又能在落盘时符合当前系统的路径规范。

5.3 踩坑二：模板里的 shell 脚本换行符

第二个坑更隐蔽。我的模板里有一份scripts/build.sh，在 macOS 和 Linux 上都跑得好好的，放到 Windows 上通过 Git Bash 执行时却报了一堆奇怪的错误，说什么$'\r': command not found。

这是典型的 CRLF 和 LF 换行符不一致问题。Windows 上编辑器默认以 CRLF 保存文本，当 colibri 以默认方式读取文本模板并原样写回时，生成的.sh文件就带着\r\n，Linux 风格的 shell 解释器不认这个回车符号。修复方法是在写文件时对特定扩展名强制执行 LF 换行：

func writeContent(path string, content []byte) error { if strings.HasSuffix(path, ".sh") || strings.HasSuffix(path, ".env") || strings.HasSuffix(path, ".Makefile") { content = bytes.ReplaceAll(content, []byte("\r\n"), []byte("\n")) } return os.WriteFile(path, content, 0o644) }

这让我意识到一件事：模板文件在入库前就应该统一用 LF 换行，并且.gitattributes里要加上*.sh text eol=lf，防止 Git 在 Windows 上检出时再把它改回 CRLF。

5.4 踩坑三：信号取消与子进程清理

colibri 的preflight和hooks.afterGenerate会执行很多外部命令，比如go build、pip install。这些命令动辄跑几十秒甚至几分钟。如果用户执行到一半按下 Ctrl+C，主程序会收到 SIGINT，但正在执行的子进程不一定能被正确终止，留下一个僵死的 go build 进程继续占用 CPU 和文件锁。

我最初的写法只监听了信号然后直接os.Exit(1)，后来发现这个做法会留下孤儿进程。正确的做法是用 Go 的signal.NotifyContext创建一个上下文，把它透传给所有exec.CommandContext调用。这样信号到达后，Go 会主动向子进程发送终止信号，完成清理后再退出。

ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM) defer stop() cmd := exec.CommandContext(ctx, "go", "build", "./...")

这个改动很小，但解决了一个很容易被忽视的问题。内部工具面向的是开发者，如果他们频繁遇到"Ctrl+C 之后进程还在跑"，对工具的信任感会直线下降。

5.5 踩坑四：配置文件缓存目录的跨平台约定

colibri 会把模板缓存和用户自定义的 profile 存到用户配置目录，最早我图省事直接写死在当前目录下的.colibri/文件夹里。问题很快暴露：用户在不同的项目目录执行colibri new时要重复下载模板缓存，而且权限受限的 CI 环境里根本没法定点写文件。

后来我切换到标准的用户配置目录，不同平台上的具体路径如下：

Go 标准库里的os.UserConfigDir()已经把这层跨平台逻辑封装好了，直接用就行。唯一要注意的是 macOS 的路径带空格，在日志输出里要记得给路径加引号，避免拼字符串时出错。

6. 在团队中推广后，我总结的三条经验与一条边界

6.1 使用者不读文档，默认值就是文档

工具做完后我写了一份很详细的 README，然后发现团队里真正完整读过的人不超过三个。大多数人的使用路径是colibri --help、试错、成功、记住这个命令。所以我把--help输出当成了最重要的文档阵地。

每个子命令的帮助信息里都强制带一个 Example 段，直接展示最常用的调用方式：

Examples: colibri new my-service --profile golang-http --module github.com/example/my-service colibri preflight --profile golang-http colibri init --profile golang-http .

所有交互式参数都提供默认值。用户不传--name时，默认用当前目录名作为项目名；不传--profile时，默认读取当前目录下的colibri.yaml。与其说这是设计上的懒，不如说是我意识到：一个命令在"零参数可运行"的情况下才真正降低了他的使用门槛。

6.2 工具受欢迎的原因往往是"快速看见产出"

团队引入 colibri 三个月后，我私下统计了一下使用频率，最受欢迎的不是生成器new，而是预检命令preflight。原因很有意思：new只有在新项目启动那一瞬间有价值，而preflight在每个人换机器、配 CI、升级工具链的时候都会被用到。它几秒钟内输出的那份环境诊断清单，让使用者立刻知道自己缺什么、该装什么版本，这种"当场能看到结果"的反馈比任何文档都有说服力。

这个观察改变了我后续的迭代优先级。我花了很多精力去优化 preflight 的输出排版和检测项，而不是急着给new增加更多模板。

6.3 边界意识：请不要变成全家桶

项目跑起来之后，需求会像雪片一样飞来。有人说要加定时任务调度，有人说要支持远程模板仓库，还有人说要做可视化面板。我几乎全部拒绝了。

拒绝的依据很简单：如果这个功能不加，用户会损失什么？如果损失可以靠现有命令的组合弥补，就坚决不加。定时任务调度已经有了 cron 和 CI 调度器，远程模板仓库已经有了 Git 子模块，可视化面板和终端工具的理念相悖。colibri 的立身之本是轻，一旦开始往里面堆东西，蜂鸟就会变成鸵鸟。

6.4 下一步：模板市场与编辑器插件

我个人其实很想做一个公共模板仓库，让不同团队把沉淀好的 profile 发布出来，其他人通过colibri new直接引用。这个事容易做过头，所以我会要求发布的模板必须附带验证脚本，至少保证生成后的工程是可构建的。

编辑器插件的思路也在规划中，VSCode 插件可以做得非常简单：右键目录，弹出"使用 colibri 初始化"，然后展现 preflight 的输出面板。但这件事优先级不高，因为 colibri 本身在终端里的体验已经足够顺畅，插件带来的增益有限。

在我自己维护这个小工具的这段时间里，最大的体会是：工具的价值不在于它有多大，而在于它能在多大程度上让人愿意反复使用。colibri 这个名字提醒我保持轻盈，也提醒我悬停精准——不做什么，比做什么更重要。