作者用Textual写了个命令行文件选择器，把「找文件→打开编辑器→改几行→保存→切回终端」这五步压缩成一步。核心卖点不是功能多强，是拒绝上下文切换。

痛点：大项目里的编辑卡顿

打开网易新闻 查看精彩图片

作者的原话很直接：「That context switching breaks flow more than it should.」

具体场景很多人熟悉——终端里跑命令，发现要改个配置文件，切到IDE，等加载，文件树里翻半天，改三行，保存，切回终端。对大项目尤其痛苦：文件树膨胀，IDE搜索变慢，「就为了改几行字」的心理负担很重。

作者想要的流程极简：留在终端→找到文件→编辑→保存→继续。没有窗口跳转，没有加载等待。

工具怎么工作：四步闭环

安装命令是 pip install terminal-file-picker，入口命令 terminal-file-picker 后跟项目目录（. 表示当前目录）。

交互逻辑：

1. 输入文件名片段，即时显示匹配结果带完整路径
2. 按Enter聚焦结果列表，↑↓导航
3. 选中文件后直接进入行内编辑
4. 输入 :done 保存，可选覆盖或追加模式

全程不启动外部编辑器，光标没离开过终端窗口。

为什么不用现成的

作者做了明确的工具对比：

传统IDE（VS Code等）：功能强，但快速编辑太重
文件管理器：不支持行内编辑
fzf等CLI工具：选择体验好，但止步于选择，没有编辑能力

这个工具的定位很窄：终端内、快速、小修改。不跟IDE比功能，跟fzf比闭环。

技术选型：Python+Textual

技术栈就两层：Python 负责逻辑，Textual 负责终端UI。

作者特别提到 Textual 的价值：「made it possible to build a responsive keyboard-driven interface without dealing with low-level terminal handling」。换句话说，不用自己处理光标移动、屏幕刷新、键盘事件这些脏活，专注在交互设计上。

Textual 是 Python 生态里较新的终端UI框架，类似前端组件化的思路，但跑在终端里。这个选择降低了开发门槛，也让工具保持纯Python依赖，安装即跑。

路线图：模糊搜索和预览窗格

作者列出了四个改进方向：

• 模糊搜索（更好的匹配算法）
• UI响应速度优化
• 编辑体验打磨
• 可能加预览窗格

预览窗格这个点有意思——如果加上，工具就从「编辑专用」往「浏览+编辑」扩展，可能模糊掉和 fzf 的边界。但作者用了「possibly」，说明还没确定。

一个个人工具的生长路径

作者的原话：「This started as a small utility for myself, but it turned into something I now use regularly.」

典型的开发者工具诞生路径：先解决自己的问题，发现使用频率超预期，再考虑开源和迭代。没有宏大的产品规划，只有一个具体的使用场景被优化到极致。

最后作者抛了问题：「Would you use something like this, or is switching to an editor still preferable?」

如果你是重度终端用户，这个项目值得试。安装成本极低，pip install 一行，不满意 pip uninstall 秒删。GitHub 和 PyPI 链接都在原文里，搜 terminal-file-picker 能找到。