我最早想做这个工具是被一条命令逼急的需要把一批 Markdown 文件统一转换成正文字符数统计表又要按目录归类又要输出成 CSV还要顺带把里面的外链全部拉出来验证一遍可访问性。手写 Python 脚本到一半就放弃了因为发现下一周可能还要做类似的“一次性数据处理”。这种需求每次都不一样可每次都逃不掉“打开编辑器、写循环、处理参数、处理异常、跑一遍、再改”的流程。我当时想要的不是一个具体的转换器而是一个万能壳子把输入喂给它告诉它要什么它自己去调度底层工具。这才有了 CLI-Anything 的雏形。CLI-Anything 不是一个新鲜的大项目也不是什么框架它更像一个带插件的命令中转站。你可以把它理解成“命令行里的瑞士军刀”但又不只是简单封装十几个常用命令。它的核心思路是把所有任务抽象成“输入源 处理管道 输出目标”通过统一的命令行入口去调度外部程序和内置函数。这种设计思路放到今天其实和不少 Workflow 自动化工具是相通的但它更轻、更快而且完全跑在本地终端里。这篇文章适合谁看两类人。一类是天天跟命令行打交道手里攒了一堆零散脚本希望统一管理的开发者另一类是刚接触自动化不希望为了一个小转换就去装一套重型图形工具想用命令行搞定日常文件处理的普通用户。你不需要会写多高深的代码但最好了解基本的终端操作和几个常用命令比如ls、find、curl这种。文章里我会把整个设计思路、关键实现、踩坑过程和优化细节都讲透你可以当成一期项目复盘来读也可以照着思路自己拼一个类似的工具出来。1. 从“命令堆积”到“管道抽象”CLI-Anything 的核心模型CLI-Anything 的想法其实非常简单所有你希望在命令行里做的事都可以分解成三步——拿到原始数据、对数据做变换、把结果落到某个地方。这三步对应到程序里就是三个抽象的接口Source、Processor、Sink。我第一版写得特别粗暴就是拿一个巨大的 Bash 脚本把各种命令拼起来里面全是if [ $1 wordcount ]这种分支。结果可想而知加到一个十几个功能的时候光解析参数就写得想吐而且每加一个新功能就要改动主流程代码很容易碰坏旧功能。后来我参考了 Unix 哲学里的 “一个程序只做一件事”但又反其道而行之CLI-Anything 不自己做具体转换它只做编排具体的事全部交给外部工具。这套模型大概是这样的输入源不一定是文件也可以是一个 URL、一段剪贴板文本甚至是一个文件夹里所有满足条件的文件。处理器可以串联。比如先做文本提取再做编码转换再清洗空白字符最后做分词统计。输出目标也不一定是文件可以输出到标准输出可以追加到日志可以重命名后归档也可以直接作为下一阶段处理的输入。单一 Unix 工具只解决窄问题CLI-Anything 解决的是“怎么组合这些窄工具”的问题。就像搭积木积木本身是现成的命令而我的工具是那块底座让你可以快速改变积木的排列方式。1.1 为什么不用现成的 Makefile 或脚本框架这是我被问到最多的问题。类似功能其实可以用make、just、task甚至 GitHub Actions 的 workflow 来实现为什么非要自造一个轮子答案在“即时性”。Makefile 的语法写起来繁琐变量传递规则多处理带空格的路径天然想骂人Taskfile 稍好一些但它的定位是“任务运行器”不是数据处理管线你想把上一步的输出直接作为下一步输入就要写很多胶水代码。CLI-Anything 的定位更窄也更专注你就给我一个输入参数我在内部帮你调度然后你就可以拿着结果继续走。比如我想对比两个 CSV 文件的第二列去重情况。用传统脚本大概要写三四行 awk 再加一个sort -u。用 CLI-Anything 的管道语法一行就是一件事anything csv://a.csv | column#2 | uniq | compare csv://b.csv这里的column#2是一个内置处理器uniq直接复用系统命令compare是一个自定义比较器。框架本身不关心中间数据类型是什么它只负责把标准输出传递给下一级标准输入。这样的设计让扩展新处理器变得极其简单完全不需要改主框架。这个“标准输入标准输出”的思路是受了 Unix 管道本身的设计启发。既然系统已经帮我把进程间的数据通道做好了我为什么不用它作为所有处理器的通用接口1.2 数据在管道里长什么样CLI-Anything 的中间数据格式只有三种原始字节流、UTF-8 文本、结构化 JSON。所有内置处理器都必须声明自己接受和输出哪一种格式这样框架才能判断管道能不能串起来。这里有一个很有用的约定默认不关心数据格式所有数据先当作字节流传递。只有当某个处理器声明需要“结构化 JSON”时框架才会在它前面自动插入一层 JSON 解析。刚开始我觉得这样会拖慢性能实际测试后发现完全可接受因为现代机器上的文本序列化和反序列化速度远快于真正的磁盘 IO 或网络请求。这个设计带来一个好处你可以在管道中间随意插入grep、sed、head这类经典命令因为它们的输入输出都是字节流。也就是说CLI-Anything 不是替代你熟悉的命令而是让你在熟悉的命令之外多了一层统一调度能力。比如要统计一个超大日志文件里 ERROR 级别的记录占比我可以直接这样跑anything file://app.log | grep ERROR | countgrep是系统自带的count是框架内置的统计器file://是一种输入源协议。这比写grep -c配合wc -l要做除法方便得多而且每段都清晰可读。2. 输入源协议和输出目标的设计思路输入源协议是 CLI-Anything 和普通脚本最大的区别点。普通脚本只接受本地文件路径CLI-Anything 则定义了一组 URL scheme把不同来源的数据统一起来。这个设计是从curl的 URL 哲学里学来的——既然网络上的一切都可以用 URL 表示那本地环境里的一切也可以。目前我实现了这么几种输入源Scheme作用示例file://读取本地文件支持通配符展开file://logs/*.logdir://遍历目录下的所有文件dir://data/rawhttp(s)://抓取网页或 API 返回内容https://example.com/apiclip://读取系统剪贴板clip://textstdin://从标准输入读取cat data.txtglob://按 glob 模式匹配一组文件glob://src/**/*.md一开始我也觉得file://有点多此一举直接传路径不就行了但后来发现统一成 scheme 之后处理器不用关心数据到底从哪来。比如我想下载一个网页、把里面的 HTML 标签剥掉再统计词频命令是anything https://example.com/article | html2text | freq这里html2text是一个处理器它只关心输入是 HTML 字节流输出是纯文本完全不关心这些字节来自网络还是本地。这种解耦让整个工具链变得非常灵活本地文件、网络资源、剪贴板之间切换只改一个参数。2.1 剪贴板输入桌面场景的意外突破口我最开始觉得剪贴板输入是个鸡肋功能直到有一次我需要清洗一份从网上复制的表格数据。内容里有大量不规则的空白字符和全角符号常规做法是打开编辑器粘贴用正则替换再复制回去。但有了clip://我可以直接在终端里跑anything clip://text | clean-space | unify-quotes | clip:// # 回写剪贴板后半段那个clip://作为输出目标会把处理后的文本直接放回剪贴板。这样一个动作就完成了“清洗复制内容”的整个闭环省掉了编辑器的中间步骤。实测下来只要你的终端剪切板权限开好了这个流转路径比大多数人想象中要顺畅得多。2.2 输出目标不只是“写到文件”CLI-Anything 的输出目标支持file://、stdout://、append://、clip://以及一个比较特殊的exec://。exec://的输出目标不是文件而是执行一条命令并把数据作为参数传给它。这个设计非常实用。举个例子我想把一个 JSON 对象里所有email字段提取出来逐行发给一个内部通知脚本传统做法是写个 for 循环或者用xargs。在 CLI-Anything 里可以直接指向exec://anything file://users.json | jq -r .users[].email | any exec://notify-user.shexec://协议会把每一行输入都当作一次独立命令的参数去执行天然支持并行度控制。这个功能最初是给内部数据巡检脚本用的后来发现它可以替代很多xargs的写法而且错误处理比 xargs 细致得多。2.3 模块参数传递的一个小设计细节管道里的处理器需要一个统一的参数传递方式。我尝试过--keyvalue、位置参数、环境变量最终采用了一种混合方式全局参数用--开头处理器参数用::加在处理器名后面。看一个例子anything https://example.com --timeout 15 \ | html2text::keep-linkstrue \e | freq::top10--timeout 15是框架参数控制网络请求超时时间html2text::keep-linkstrue是该处理器自己的参数。这样设计的好处是每级管道的配置都写在它所在的那一段旁边不会混在一起。如果全部用--前缀你很难分清某个参数到底是给框架的还是给哪个处理器的。这个 “::” 分隔符一开始被吐槽有点丑但用久了觉得挺顺手因为它杜绝了参数归属歧义。相比大而全的参数解析库CLI-Anything 选择了看起来更朴素的约定换来的却是命令行的可读性和可调试性。3. 内置处理器之外如何用插件机制养活一个生态CLI-Anything 虽然内置了文本处理、CSV、JSON、图片缩放、音频格式转换等二十多个处理器但真正让它“任意”起来的是插件系统。插件系统的核心约定只有一个任何程序只要能从标准输入读数据、往标准输出写数据就可以成为 CLI-Anything 的处理器。这个约定几乎复制了 Unix 工具链的通用规则只是多了一层 JSON 元数据声明。每个插件目录下面放一个plugin.json描述处理器名称、参数、输入输出格式和底层命令。框架加载以后直接调用这些外部程序用管道把它们串起来。下面是一个简化版的插件声明{ name: pdf2text, version: 1.0.0, description: 把 PDF 提取为纯文本, input: file, output: text, command: pdftotext - -, arguments: { layout: { flag: -layout, description: 保留原始版面 } } }这个插件本质上就是包了一层pdftotext。你说它有没有技术含量确实不高。但问题在于如果每个工具都要自己重新去记pdftotext的一串参数学习成本就很高。插件机制把它变成了一个可靠的抽象还能和 CLU-Anything 的配置和错误处理机制天然整合。3.1 突破编程语言的边界插件可以用任意语言编写只要它支持标准输入输出。我自己就混合使用过 Ruby、Python、Go 和 Node 写插件这在别的框架里很少见。大多数插件系统会限定一种语言比如 Lua 插件、Python 插件但 CLI-Anything 选择了“外部进程”模型代价是每次调用都有一定进程启动开销换来的是巨大的生态兼容性。进程开销这个问题在管道数据量大的时候会影响性能。解决办法是内置了 “长驻进程模式”可以让插件进程常驻、通过标准输入持续接收数据而不是每行数据都启动一次子进程。长驻模式用起来要小心资源泄漏实际中我会给每个常驻插件设置最大空闲时间超过就自动回收。3.2 我自己写的第一个有价值插件早期测试阶段我拿一个突发需求和插件系统较劲需要把几十个 CSV 文件按第二列数值大小合并排序输出一个带总计行的大 CSV。常规命令当然可以用sort搞定但加上“统计每个产品线的合计”就麻烦了。我写了一个不到 80 行的 Python 插件接收多路输入内部按产品线汇总再分批输出。因为插件协议简单写起来完全不痛苦。这个插件后来被我不断扩展最终变成了内置处理器csvpivot。所以我的建议是如果你准备深度使用 CLI-Anything第一件事不是学它的源码而是试着为它写一个对自己有用的笨拙插件。通过这个过程你会比看一百页文档更理解“处理器”到底意味着什么也会开始用“输入、处理、输出”的视角去重构自己的日常工作。3.3 插件版本冲突问题插件多了以后版本冲突是必然的。有些插件依赖特定版本的ffmpeg有些依赖imagemagick有的又需要python3.10的新特性。CLI-Anything 提供了一个方案插件声明里的requires字段。框架在加载时会检查外部命令是否存在、版本是否满足如果发现缺失只是警告并把该插件标记为不可用而不是直接让整个工具崩掉。配置一个插件的方式特别灵活我常用的做法是在用户级配置文件里指定外部程序路径plugins: pdf2text: command: /usr/local/bin/pdftotext csvpivot: python: /usr/bin/python3 script: ~/.cli-anything/plugins/csvpivot.py这样同一套全局配置可以在不同机器上复用只要覆盖路径差异即可。常年在多台服务器之间切换的人应该懂这个需求每个环境安装的位置五花八门把所有路径管起来比什么都重要。4. 配置系统、错误处理和可观测性一个命令行工具如果只有功能没有运维设计用它做数据处理时会非常痛苦。CLI-Anything 的配置系统和错误处理花了很大力气这部分看起来不起眼却决定了工具能不能在真实生产环境里被信任。配置采用 YAML 加环境变量双重来源。环境变量优先其次才是配置文件这样方便在 Docker 或 CI 环境里覆盖配置。配置文件可以被内联到主配置里也可以分开存放支持全局配置和项目级配置。项目级配置在遇到.cli-anything.yaml文件时自动生效这一点让团队协作变得方便项目里的配置直接提交到仓库新人克隆后跑第一条命令就能得到和老同事一样的环境。4.1 管道运行时的错误传播策略管道由多个处理器串联任何一个处理器报错怎么处理默认策略是“快速失败”只要某个处理器返回非零退出码整个管道立刻停止并且把已经产生的输出缓存到临时目录。这个策略看起来简单实际实现时有个微妙的问题上游可能已经输出大量数据下游失败后管道断开会触发SIGPIPE如果不处理会让上游进程得到误导性的错误信息。最后我给每个处理器包装了一层标准信号处理逻辑检测到下游断开的SIGPIPE时向上映射成一个自定义的“下游终止”错误状态而不是简单当成本地执行失败。这样用户在调试管道时能清楚看到失败的是哪一段——是数据源不可达还是某个处理器拒绝接受不规范的数据或者只是下游主动关闭了管道。4.2 让排错不再靠猜CLI-Anything 有一个--explain模式可以在执行之前打印出整个管道的执行计划$ anything file://orders.csv | clean | csvpivot --byregion | sort | stdout:// --explain [1/4] file://orders.csv - text/data: 读取文件编码自动检测 [2/4] clean - text/data: 清理不可见字符标准化换行 [3/4] csvpivot --byregion - json/data: 按 region 汇总生成 JSON 结构 [4/4] sort - json/data: 按 region 字母序排列 [5/4] stdout:// - text/data: 将结果格式化为表格输出注意第二步的clean和第四步sort中间经过了两次结构转换--explain会显式标注这些格式变化。很多时候用户发现管道不能工作并不是因为命令写错而是数据结构在某一步悄悄变了后续处理器不接受。这个模式能把这类隐性问题提前暴露出来。4.3 日志、审计和重复性CLI-Anything 默认把所有执行记录写入一个 JSON Lines 日志文件包含时间戳、完整命令、输入源、输出目标、每个处理器耗时和最终状态。这带来两个好处一是你可以回去查“昨天跑的那个命令到底用了什么参数”二是可以在日志基础上构建审计报表弄清楚哪些数据处理任务占据了你多少时间。刚开始我甚至记录每一条从外部读到的网络响应哈希值用来判断页面是否发生变化。后来觉得这个功能偶尔有用偶尔又有一点过度设计就做成了一个可选特性。如果你想监控某个网页内容变化比如价格变动、公告更新这个功能比写完整爬虫要轻量得多。5. 真实场景实测拿 CLI-Anything 处理日常任务的结果写工具很容易自我感觉良好但如果不能在日常任务里撑住那只是自嗨。下面这三个场景都是我在过去一个月里实际执行的不是虚构演示。5.1 批量整理下载目录下载目录里堆积了各种文件PDF、图片、压缩包、临时脚本。以前我用 Finder 和脚本混合整理这次我直接用了一条管道命令anything dir://~/Downloads \ | classify::typemime \ | move --to~/Archive/{{type}}/{{yyyy-mm}}classify插件按 MIME 类型识别文件move根据分类结果和目标模板把文件移动到对应的月份子目录。实际跑了一遍处理 327 个文件耗时不到 2 秒只有少量需要人工再确认的是那些扩展名和真实格式不一致的文件。这个场景暴露出的问题是很多从网上下载的 PDF 实际是 HTML 伪装成 PDFfile命令的识别能力比扩展名可靠得多。5.2 网页内容巡检我需要定期检查一组外部文档链接是否还活着同时提取每个页面的主要标题。用 CLI-Anything 写成一个可复用的管道定义checks: - name: doc-links pipe: | file://links.txt | http::checkstatus | filter::fieldstatus_code, opne, value200 | stdout://配置里定义了这个“任务”以后任何时刻想重跑只要键入anything run doc-links。这种方式比写感性的 shell 循环清晰很多而且由于管道每一步都有日志我可以快速定位是哪一次请求超时导致整个任务变慢。实际结果发现整个文档库 80 多个链接里大概有 5 个已经返回 404自动生成了一份需要人工处理的清单。5.3 大量 CSV 文件的字段核对有一次需要对比两个供应商导出的产品价格表核对哪些产品价格有变动。两个文件的字段顺序不一样命名也不一样。CLI-Anything 的处理思路是用两个输入源分别映射字段然后在管道里做一个针对产品 ID 的连接操作anything file://supplier_a.csv | csvrename --mapID:product_id,Price:price_a \ | join --onproduct_id --withanything file://supplier_b.csv --selectprice_b \ | csvdiff --columnsprice_a,price_b \ | stdout://这里join处理器可以直接把另一个 CLI-Anything 管道作为数据源相当于在管道里嵌套管道。这种嵌套能力是我后来加上的因为很多真实数据操作都涉及多表关联。这轮核对最后定位到 12 个产品的价格存在偏差整个过程比打开 Excel 再做 VLOOKUP 要快得多还可以天然脚本化、定期自动化执行。6. 踩坑实录从设计到真实使用之间隔着一堆 bug如果说设计阶段是美好的畅想那么把 CLI-Anything 投入真实使用之后我才开始真正理解“命令行工具设计”和“命令行工具必须可用”之间的巨大鸿沟。踩过不少坑简单记录几个最有价值的。6.1 编码问题不是一切都 UTF-8我最开始把所有文本都当成 UTF-8结果在一个包含大量 GBK 编码日志文件的场景里彻底翻车。日志文件开头没有 BOM检测编码本身就是个复杂问题。后来采用的方案是框架层提供了“编码自动检测 强制指定”两个入口。自动检测基于chardet一类的统计模型但并不完全信任它因为短文本检测经常出错。最稳妥的做法是在输入源声明里直接指定编码anything file://logs/20240101.log::encodinggbk | clean | encode::fromutf-8你可能会说“怎么这么麻烦能不能全自动”能全自动但是误判率让我很不放心。文本数据处理这件事编码是个绕不开的地基与其猜来猜去不如显式声明尤其是在批量处理时。这个教训对我影响很深后来设计其他工具时我都会把类似“显式优于隐式”的原则放在首位。6.2 参数解析里的“抢参数”问题管道里的处理器多了以后出现了参数归属混乱的情况。比如要抓取一个网页然后去看 HTML 标签页面上恰好有--output字样这时候如果整个命令行只有一个--全局解析器--output可能会被框架拦截而不是传给处理器。我花了不少时间才确信必须引入::来划分边界。这不仅解决了解析歧义还带来了一个隐藏的好处管道里的每一段看起来都像独立的函数调用读起来比一长串--参数清晰得多。如果你也准备写一个带管道语义的 CLI 工具这个“每个处理器自带参数命名空间”的设计建议提前考虑别等用户来吐槽。6.3 跨平台路径分隔符之痛CLI-Anything 在 macOS 和 Linux 上都跑得很好但 Windows 适配是另一个故事。路径分隔符、换行符、命令行长度限制每个都是坑。好在项目从一开始就没打算捆绑操作系统 API而是尽量把底层逻辑交给外部命令承担所以在 WSL 或 Git Bash 环境下用起来比较顺畅不需要专门做原生 Windows 支持。想给跨平台用户一个建议在 Windows 上运行 CLI-Anything 时优先使用 WSL避免路径转换问题。如果你一定要用原生 PowerShell那至少给所有路径加引号。如果你问我为什么不适配原生 Windows我的真实想法是把维护成本压到最低把注意力放在管道模型和插件生态上比让一个工具跑遍所有平台更重要。6.4 千万不要把大文件塞进单条管道有一回我想处理一个 4GB 的日志文件直接用file://读取后做多步清洗。结果内存占用了几个 GB机器差点卡死。后来才发现框架默认为了支持--explain和错误回滚会在内存里缓存中间数据。数据量一大这个缓存就成了内存杀手。现在我的处理方式是文件超过 100MB 时自动切换成流式模式不再缓存中间结果。流式模式下每个处理器之间使用临时文件而非内存缓冲区代价是磁盘 IO 多了不少。但其实这个代价是值得的因为现代 SSD 的速度完全可以支撑如果你处理的数据量达到 TB 级别流式模式几乎是唯一合理的选择。提示如果你的任务是处理超大日志优先使用流式模式并在管道里加一个progress处理器来观察进度。不加的话你只能盯着终端发呆完全不知道管道卡住还是在进行中。6.5 插件进程的僵尸化插件系统用的是外部子进程连续处理大量小任务时偶尔会出现子进程退出了但资源没完全回收的情况。典型症状是管道跑完后终端里还能ps看到残留的插件进程。这主要是因为我早期没有正确处理子进程的waitpid状态。后来我在主进程退出前统一做一次子进程清理用一个进程表记录所有启动的子进程退出时逐个回收。这看起来是个基础工作但在早期版本里真的困扰了我很久。如果你也在写类似的外部进程调度器记得把“进程收敛”当作第一优先级处理否则你的工具跑一段时间后系统里会积累一堆僵尸进程。7. 把 CLI-Anything 推向更多场景的几个扩展思路CLI-Anything 目前的形态已经基本稳定但我自己其实很清楚距离“Anything”这个目标还有很远的距离。下面这几个方向是我测试过或者正在实践中的算是对这套架构可能性的进一步探索。7.1 和文件同步工具的联动很多人把 CLI-Anything 当作本地数据整理工具其实它也能配合云盘或同步目录使用。我目前在某个同步目录里配置了一个定时任务每次同步完成后自动统计新文件数量、类型分布和占用空间输出成一张摘要表。因为同步工具本身有命令行接口我可以用exec://协议直接调用它然后把结果再交给后续管道。这样做的好处是你不必为了监控同步目录专门打开一个图形化的信息面板所有数据都可以沉淀为文本报表方便后续生成周报周报摘要。这其实是我最喜欢的场景不重造任何一个轮子只是把已有工具像积木一样灵活拼接。7.2 通过 watch 定时调度CLI-Anything 本身没有内置 cron 调度器因为重复造一个定时任务管理工具没有任何意义。但在真实工作里我会这样搭配 cron 使用*/30 * * * * /usr/local/bin/anything run health-check --silent管道定义在配置文件里cron 定期调用run子命令输出会写入日志只在异常时才有额外的通知。这样的架构最妙的地方在于任务定义和调度是分离的。调度用系统的 cron 足够可靠任务定义交给 CLI-Anything不会出现“任务逻辑写在 crontab 里然后又带了一堆转义”的糟糕局面。7.3 把管道能力暴露成 HTTP 接口去年年底我尝试给 CLI-Anything 加了一层薄薄的 HTTP bridge让远程机器可以通过 REST 调用本地管道。比如远程上传一个 CSV返回一个处理后的 JSON。这个功能本质上就是把管道定义作为一个可复用函数客户端传入参数服务端执行管道并返回结果。其实这已经跨入“内部微服务”的领域了但我并没有把它当作一个严肃的微服务框架来维护只是给它包了一层 Flask 路由加一点鉴权。真正常态化使用要等以后再说。如果你也想在这个方向上探索建议先从本机回环地址跑起保证管道在命令行里稳定工作之后再做 HTTP 封装。8. 一些写给新手的实操建议很多刚接触 CLI-Anything 或者类似管线工具的朋友最容易犯的一个错误是什么都想用一条管道一次性完成。我自己也是这么跌跌撞撞过来的后来总结了几条经验也许对你有用。第一条从最小的任务开始。不要一开始就设计十条处理器的长管道。先单独跑一个处理器确认输出符合预期再一步一步往上加。管道的好处是每一步都独立可测所以千万不要跳步。第二条尽量保证每个阶段的数据是可观察的。在必要时用tee命令或内置的out处理器把中间结果存到一份临时文件里。这样一旦管道尾部结果不对你还能回头核查是哪个环节处理出的问题。如果所有中间数据都只在内存里流转排查问题的成本会高很多。第三条慎重使用“自动转换”。我在工具里加入了非常多的隐式启发式规则在大多数情况下都能自动处理但偶尔遇到奇怪的数据启发式规则会给出出人意料的“惊喜”。所以当你要处理重要数据时宁可多写一个显式声明也不要依赖魔法自动转换。省下的是几秒配置时间埋下的可能是几个小时的数据错误排查陷阱。第四条要接受“80% 的场景”。CLI-Anything 能够覆盖我日常工作里大约 80% 的零散数据任务剩下 20% 仍然需要手写专用脚本。我不认为这是工具的缺陷反而觉得这是自然边界。如果一个工具试图覆盖 100% 的需求它往往会变得臃肿且难用。认清边界在边界内把你的工作流打磨顺畅已经很有价值。另外还要强调一点管道的顺序会影响性能和结果。比如提前过滤掉不需要的行再去做昂贵的数据转换整体的执行时间会差出很多。这也是为什么我更倾向于让数据“先窄后宽”先缩小数据量再扩展数据信息。你在给管道排序时也可以优先考虑这个原则。实际用下来CLI-Anything 最大的收益不是单条命令跑得有多快而是它让我开始习惯用结构化的思维去做那些以前靠手工和临时脚本完成的任务。每次需要处理数据时我脑子里会自动浮现出“输入是什么、经过哪些变换、输出给谁”这样的三层结构。这种思维方式的转变带来的价值比任何功能列表都更持久。以后我可能还会继续往里面加新的处理器和协议但我越来越觉得这工具的“引擎”其实很普通真正让它与众不同的是围绕管道这套抽象建立的使用习惯和插件生态。如果你准备在自己的项目里参考类似设计我会建议你也把功夫花在这三件事上明确统一的管道抽象、极简的插件协议、可观测的日志系统。把这三块地基打牢其他功能自然会长出来。