命令行 on KnightLi的博客

CLI-Anything：把软件变成 Agent 可用的命令行

Mon, 25 May 2026 00:24:36 +0800

CLI-Anything 是 HKUDS 开源的 Agent 工具化项目，目标是把原本面向人类 GUI 操作的软件，转成 AI Agent 更容易调用的命令行接口。它不是重新实现一个简化版软件，而是围绕现有代码库和真实后端生成 CLI harness，让 Agent 可以通过稳定命令、状态会话和结构化输出来完成任务。

这个方向解决的是 Agent 使用软件时最常见的断层：GUI 自动化依赖截图、点击和坐标，容易受界面变化影响；单个 API 又经常覆盖不完整，Agent 需要自己拼接大量上下文。CLI-Anything 选择把软件能力收敛成命令行，因为命令天然适合被模型读取、组合、验证，也便于接入脚本和自动化流程。

它怎么工作

官方仓库把 CLI-Anything 描述为一套自动生成 CLI 的流水线。给它一个本地软件源码路径或 GitHub 仓库地址后，流程会分析代码结构、识别后端和数据模型，设计命令分组，再实现 CLI、测试和文档。

生成出来的 CLI 通常包含两种使用方式：一种是面向连续工作的 REPL，会保留项目状态；另一种是子命令模式，适合脚本和流水线。命令还会提供 JSON 输出，方便 Agent 直接解析结果，同时保留人类可读的格式用于调试。

官方示例里，Claude Code 插件可以这样使用：

1
2
3

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything <software-path-or-repo>

如果已经生成某个软件的 harness，后续使用方式会更接近普通 Python CLI：

cd <software>/agent-harness
pip install -e .
cli-anything-<software> --help
cli-anything-<software>
cli-anything-<software> --json <command>

适合什么场景

CLI-Anything 更适合那些“能力在真实软件里，但 Agent 不好稳定操作”的场景。例如图像、视频、音频、办公文档、3D 建模、数据分析或 AI/ML 工具链，只要项目有可分析的代码库、可调用的后端或清晰的数据模型，就有机会被包装成 Agent 可用的命令集。

它的价值不只是在命令行里多一层封装，而是把软件的关键操作变成可发现、可组合、可测试的接口。Agent 可以先通过 --help 理解能力，再用 JSON 输出接收结果，并把多个命令串成工作流。对于需要批处理、自动验证和持续迭代的任务，这比临时让 Agent 点击界面更可控。

需要注意的边界

CLI-Anything 并不等于任何软件都能立刻无成本接入。它依赖目标软件的源码、后端能力、文件格式和可测试性；如果一个软件高度封闭、关键逻辑只存在于 GUI 层，生成高质量 CLI 的难度会明显上升。

官方方法论也强调真实后端和测试验证，这意味着生成 harness 不是只写几个命令包装脚本就结束。要让它用于严肃工作，还需要确认命令覆盖范围、输出格式、依赖安装、真实软件调用和端到端测试是否可靠。更现实的用法，是先为一个明确工作流生成 CLI，再通过 refine、test、validate 等命令逐步补齐能力。

小结

CLI-Anything 的思路很直接：不要让 Agent 去适应脆弱的人类界面，而是为现有软件补上一层稳定、结构化、可测试的命令行入口。它适合想把专业软件纳入 Agent 工作流的人，也适合研究“Agent 原生软件”形态的开发者。真正落地时，重点不在于一句命令生成了多少代码，而在于生成的 CLI 是否能调用真实能力、保持状态、输出结构化结果，并经得起测试。

Ghostty 文档速读：安装、配置与日常使用要点

Fri, 15 May 2026 14:50:11 +0800

Ghostty 是一个新的终端模拟器，但它并不只是“又一个更快的终端”。按照官方文档的说法，它想同时兼顾三个方向：速度、功能和原生桌面体验。也就是说，它既希望有 GPU 加速和较好的渲染性能，也希望在 macOS 和 Linux 上尽量像一个真正的本地应用，而不是把所有交互都塞进自绘界面里。

如果你正在用 iTerm2、Kitty、Alacritty、WezTerm 或系统自带终端，Ghostty 最值得关注的地方不是某一个单点功能，而是它把“开箱即用”和“深度可配置”放在了一起。默认配置已经能直接使用；想继续折腾时，文档又给了配置文件、主题、快捷键、字体、Shell 集成和终端控制序列等完整入口。

先看定位

Ghostty 的核心定位可以概括为三句话：

它是跨平台终端模拟器，目前重点覆盖 macOS 和 Linux。
它使用平台原生 UI：macOS 端使用 Swift、AppKit 和 SwiftUI，Linux 端使用 Zig 和 GTK4。
它的终端核心是 libghostty，GUI 应用围绕这个共享核心构建。

这个设计会影响日常体验。比如标签页、分屏、错误提示、窗口状态恢复、系统快捷键等能力，不是简单做成“看起来像桌面应用”的组件，而是尽量贴近所在系统的交互习惯。macOS 和 Linux 默认快捷键也会按各自平台约定区分。

安装方式：macOS 最直接，Linux 看发行版

官方预构建二进制主要面向 macOS。最普通的安装方式是下载 .dmg，打开后把 Ghostty 拖到 Applications 目录。Homebrew 用户也可以用社区维护的 cask：

`1`	`brew install --cask ghostty`

Linux 的情况更分散。Ghostty 文档把不同发行版的包管理器、社区二进制和源码构建分开说明。Arch、Alpine、Gentoo、NixOS、Snap、Solus、Void 等都有对应路径；如果发行版没有官方或可信仓库，文档更倾向于让用户从源码构建，而不是随意安装第三方二进制。

这点对服务器和工作机尤其重要：终端模拟器会处理大量输入输出、剪贴板、链接、SSH 会话和本地文件路径。安装源最好保守一点，优先选官方 macOS 包、发行版仓库或自己能审计来源的构建流程。

配置：先别急着复制一大份 dotfiles

Ghostty 的配置哲学是“零配置可用”。默认字体内置 JetBrains Mono，也带有 Nerd Font 支持；大多数用户第一次打开就能正常工作。文档甚至建议，如果你发现必须配置某个非主观选项才舒服，可以先考虑它是不是应该成为默认行为。

真正需要定制时，Ghostty 使用文本配置文件。当前配置文件名是 config.ghostty，旧版本也支持 config。常见路径包括：

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

macOS 还会读取：

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

配置语法非常直接，就是 key = value。例如：

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

一个实用建议是：不要一开始就找别人的完整配置照抄。更稳的方式是先裸跑几天，只改三类东西：字体、字号和主题。等你真的发现快捷键、分屏、窗口、Shell 集成有摩擦，再逐项加配置。

文档查询：本地也能查完整配置

Ghostty 的配置项很多，官方文档把它们集中在 Option Reference。除了网页，安装后也可以从本地查配置参考：

`1`	`ghostty +show-config --default --docs`

这个命令会把默认配置和文档输出到标准输出，适合接到分页器里慢慢搜：

`1`	`ghostty +show-config --default --docs \| less`

查看可用字体时可以用：

`1`	`ghostty +list-fonts`

查看内置和可用主题时可以用：

`1`	`ghostty +list-themes`

查看默认快捷键时可以用：

`1`	`ghostty +list-keybinds --default`

这些命令比在网上复制片段更可靠，因为它们来自你当前安装的 Ghostty 版本。

快捷键：把“动作”当成核心概念

Ghostty 的快捷键配置格式是：

`1`	`keybind = trigger=action`

trigger 是按键触发方式，action 是 Ghostty 执行的动作。比如新建标签页、关闭当前 surface、重新加载配置、跳转到提示符等，都属于 action。这个模型的好处是清晰：你不是在“改某个菜单项”，而是在把一个输入序列绑定到一个动作。

配置改完后，可以在运行时重新加载。默认快捷键是：

Linux：ctrl+shift+,
macOS：cmd+shift+,

不过并不是所有配置都能即时生效。有些选项只影响新建终端，有些需要完整重启。遇到“配置写了但没变化”时，先查对应选项说明，比反复怀疑语法更省时间。

主题和字体：先用内置，再做细调

Ghostty 自带大量主题，并支持按系统浅色、深色模式切换不同主题：

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

主题也可以来自自定义文件。文档提醒得很明确：主题文件本质上也是 Ghostty 配置文件，可以设置很多配置项，所以不要随便使用不可信来源的主题。

字体方面，font-family 可以重复多次，用来指定 fallback 字体。对多语言环境很实用，比如主字体负责英文和符号，后续字体补中文、日文或其他字符。遇到 emoji、粗体、斜体、连字等显示细节时，再去 Option Reference 里查对应选项即可。

Shell 集成：SSH 用户尤其应该看

Ghostty 支持自动注入 shell integration，覆盖 bash、elvish、fish、nushell 和 zsh。启用后，一些体验会更自然，比如：

新终端从前一个终端的工作目录打开。
复杂提示符 resize 时可以重绘，而不是被错误回流。
可以通过提示符标记在命令输出之间跳转。
在提示符处支持更符合编辑习惯的光标行为。

如果不想自动注入，可以在配置里关闭：

`1`	`shell-integration = none`

更值得注意的是 SSH。Ghostty 使用 xterm-ghostty 作为 TERM，但很多远程主机还没有对应的 terminfo。文档提供了 ssh-env 和 ssh-terminfo 两个 shell integration 功能，默认关闭，可以按需启用：

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

如果你经常连接旧服务器、容器、跳板机或严格管理的生产环境，建议先读完官方的 Terminfo 和 Shell Integration 文档，再决定是否启用这些功能。终端能力协商看起来不起眼，但一旦出问题，表现可能是颜色异常、快捷键失灵、全屏程序显示错乱。

我的上手顺序

如果只是想判断 Ghostty 是否适合自己，可以按这个顺序试：

安装后不写配置，直接用一天。
只调整 font-family、font-size 和 theme。
用 ghostty +list-keybinds --default 看默认快捷键，而不是先搬运别人的快捷键表。
如果常用 SSH，优先检查远程主机的 terminfo 兼容问题。
最后再处理分屏、窗口、透明度、标题栏、背景图等视觉和工作流偏好。

Ghostty 文档写得比较工程化，适合把它当成“配置参考手册”而不是“宣传页”阅读。对多数用户来说，真正的判断标准也很简单：默认体验是否已经舒服，日常编辑器、Shell、SSH、tmux 或 Zellij 是否稳定。如果这几件事都顺，Ghostty 就值得进入你的长期终端候选列表。

参考链接

fdupes 怎么控制删除顺序？按目录优先级保留重复文件

Wed, 06 May 2026 09:23:09 +0800

用 fdupes 删除重复文件时，如果有 a、b、c 三个目录，并且希望优先保留 a，其次保留 b，最后删除 c 中的重复文件，关键不在于写一个复杂规则，而在于目录输入顺序。

fdupes 在非交互删除模式下，会保留每组重复文件中最先出现的文件，删除后续发现的重复项。因此目录参数要按“保留优先级从高到低”排列。

也就是说，想实现“先删 c，再删 b，最后尽量保留 a”，命令应该写成：

`1`	`fdupes -rdN a b c`

扫描顺序是 a -> b -> c。当三个目录中存在相同文件时，a 里的文件会先被发现并保留，b 和 c 中重复的文件会被删除。如果只有 b 和 c 有重复文件，则保留 b，删除 c。

参数含义

常用参数如下：

-r：递归扫描子目录。
-d：删除重复文件。
-N：与 -d 配合使用，不进入交互确认，自动保留每组重复文件中的第一个，删除其余文件。

因此，自动删除重复文件的基本格式是：

`1`	`fdupes -rdN 目录A 目录B 目录C`

目录越靠前，保留优先级越高；目录越靠后，越容易被删除。

先预览再删除

直接使用 -dN 会删除文件，建议先预览重复文件分组：

`1`	`fdupes -r a b c`

输出结果会按重复文件分组展示。每组中靠前的文件，就是非交互删除时更可能被保留的文件。

也可以查看统计信息：

`1`	`fdupes -rm a b c`

如果数据重要，建议先把结果保存下来人工检查：

`1`	`fdupes -r a b c > duplicates.txt`

确认每组重复文件的排列顺序符合预期后，再执行：

`1`	`fdupes -rdN a b c`

子目录怎么处理

只要开启 -r，fdupes 会递归扫描传入目录下的所有文件。决定保留优先级的，仍然是命令中路径出现的先后顺序。

例如：

`1`	`fdupes -rdN dir_a dir_b dir_c`

这表示：

dir_a 的优先级最高。
dir_b 次之。
dir_c 最低。

如果 dir_a/sub1/file.txt 和 dir_c/sub1/file.txt 内容相同，会保留 dir_a 下的文件。如果 dir_a/x/y/file.txt 和 dir_c/file.txt 内容相同，也会优先保留 dir_a 下的文件。fdupes 比较的是文件内容，不要求文件名或目录层级完全一致。

精确控制子目录优先级

如果只传父目录，子目录内部的扫描顺序由 fdupes 的遍历逻辑决定。多数情况下，这已经够用。但如果你想让某个子目录拥有更高优先级，就要把它显式写在前面。

例如，希望优先保留 dir_a，然后保留 dir_b/special，再处理 dir_b 的其他内容，最后处理 dir_c：

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

这样 dir_b/special 会先于 dir_b 被扫描。之后扫描 dir_b 时，special 里的文件已经被记录，整体优先级就会高于 dir_b 的其他部分。

这个写法适合下面这种需求：

a 是最重要的基准目录。
b 中某个子目录比 b 的其他内容更重要。
c 主要作为低优先级备份目录。

路径顺序可以继续扩展：

`1`	`fdupes -rdN a b/important b c/keep-first c`

规则仍然只有一个：越靠前，越优先保留。

目录很多时使用列表

如果有很多目录和子目录，手动写一长串命令容易出错。可以把路径按优先级写入一个文本文件，比如 folders.txt：

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

然后用 xargs 传给 fdupes：

`1`	`cat folders.txt \| xargs fdupes -rdN`

如果路径中可能包含空格，更稳妥的方式是使用空字符分隔：

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

需要注意的边界

第一，fdupes 比较的是文件内容，而不是文件名。如果两个文件名完全不同，但内容一致，也会被识别为重复文件。

第二，如果 a 目录内部本身就有重复文件，使用 fdupes -rdN a b c 时，a 内部靠后的重复项也可能被删除。这个命令表达的是“按整体扫描顺序保留最先出现的文件”，不是“绝对不删除 a 中任何文件”。

第三，默认情况下，fdupes 不会跟随符号链接。如果需要处理软链接相关文件，要先确认是否需要加 -s，以及这样做是否符合你的数据安全预期。

第四，fdupes 只删除重复文件，不负责清理空目录。删除完成后，如果 b、c 中留下了空文件夹，可以再运行：

`1`	`find b c -type d -empty -delete`

更安全的操作习惯

如果目录里是重要数据，不建议一上来就执行 -rdN。更稳的流程是：

先运行 fdupes -r a b c 查看重复分组。
确认每组中排在前面的文件确实应该保留。
再执行 fdupes -rdN a b c 自动删除。
删除后检查是否需要清理空目录。

如果你非常担心误删 a 中的文件，可以先只对低优先级目录做更小范围的清理，或者把结果导出后人工筛选。fdupes 的目录顺序很好用，但它不是权限隔离规则；只要路径被纳入扫描，路径内部的重复文件就可能参与删除判断。

小结

用 fdupes 按优先级删除重复文件，核心就是把“想保留的目录”放在前面，把“优先删除的目录”放在后面。

想保留 a，再保留 b，优先删除 c：

`1`	`fdupes -rdN a b c`

想让某个子目录优先级更高，就把它单独写在父目录前面：

`1`	`fdupes -rdN a b/important b c`

记住一句话就够了：fdupes -dN 会保留先出现的重复文件，删除后出现的重复文件。目录顺序，就是你的保留优先级。

FFmpeg 的 `-map` 参数详解：精准选择视频、音频与字幕流

Thu, 02 Apr 2026 23:14:03 +0800

在多音轨、多字幕的视频处理中，-map 是 FFmpeg 最关键也最容易用错的参数之一。

如果你不显式指定 -map，FFmpeg 会按默认规则自动挑选流，结果常常不是你想要的。比如：

导出后丢了字幕
选错了音轨语言
混入了不需要的数据流

这篇文章用最常见的场景，讲清楚 -map 怎么用。

先理解什么是“流”

一个容器文件（例如 mp4、mkv）里通常不止一个内容流（stream），常见包括：

视频流（v）
音频流（a）
字幕流（s）
附件/数据流（如字体、封面、章节等）

你可以先用 ffprobe 看清文件里有什么流：

`1`	`ffprobe -hide_banner input.mkv`

`-map` 的基本语法

最常见写法：

`1`	`-map input_index[:stream_type][:stream_index]`

例如：

0:v：第 1 个输入文件的所有视频流
0:a:0：第 1 个输入文件的第 1 条音频流
1:s:1：第 2 个输入文件的第 2 条字幕流

说明：

input_index 从 0 开始，对应 -i 的顺序
stream_index 也从 0 开始

实战示例

1) 视频来自 A，音频来自 B

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0:v:0 -map 1:a:0 \
  -c:v copy -c:a aac \
  french.mp4

含义：

取 english.mp4 的第 1 条视频流
取 french.mp3 的第 1 条音频流
合并输出为 french.mp4

2) 保留第一个输入的全部流，再额外加一条音轨

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0 -map 1:a:0 \
  -c copy \
  english-french.mp4

含义：

-map 0 先把第一个输入文件中的所有流都带上
再追加第二个输入的第 1 条音频流

两个很实用的进阶技巧

1) 负映射：排除不想要的流

例如保留第一个输入的全部流，但去掉第 2 条音频流：

`1`	`ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv`

2) 可选映射：流不存在也不中断

某些文件可能没有字幕，这时可以用 ?：

`1`	`ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4`

0:s? 表示“有字幕就映射，没有就跳过，不报错”。

常见坑位

-map 一旦使用，FFmpeg 就不再按默认自动选流，必须把你要的都写出来。
-c copy 只是封装复制，不做转码；若目标容器不支持某编码，仍会失败。
多输入时最容易错的是输入序号，记住序号只看 -i 的先后顺序。
想做稳定脚本时，先 ffprobe 再生成 -map，比手写更稳。

总结

-map 的核心就是一句话：明确告诉 FFmpeg，“从哪个输入，拿哪类流，拿第几条”。

掌握它之后，你就能稳定处理多音轨、多字幕、跨文件拼接等复杂场景，避免“导出结果不对但又不知道为什么”的问题。

命令行 on KnightLi的博客

CLI-Anything：把软件变成 Agent 可用的命令行

它怎么工作

适合什么场景

需要注意的边界

小结

Ghostty 文档速读：安装、配置与日常使用要点

先看定位

安装方式：macOS 最直接，Linux 看发行版

配置：先别急着复制一大份 dotfiles

文档查询：本地也能查完整配置

快捷键：把“动作”当成核心概念

主题和字体：先用内置，再做细调

Shell 集成：SSH 用户尤其应该看

我的上手顺序

参考链接

fdupes 怎么控制删除顺序？按目录优先级保留重复文件

参数含义

先预览再删除

子目录怎么处理

精确控制子目录优先级

目录很多时使用列表

需要注意的边界

更安全的操作习惯

小结

FFmpeg 的 `-map` 参数详解：精准选择视频、音频与字幕流

先理解什么是“流”

-map 的基本语法

实战示例

1) 视频来自 A，音频来自 B

2) 保留第一个输入的全部流，再额外加一条音轨

两个很实用的进阶技巧

1) 负映射：排除不想要的流

2) 可选映射：流不存在也不中断

常见坑位

总结

`-map` 的基本语法