夜雨聆风Netcatty 是一个开源终端管理软件。早期它的形态很类似于 Termius，但因为 Termius 是一个付费软件且价格不菲，而我对终端软件最大的需求其实就是云同步功能。在产出代码如喝水一样简单的AI时代，我就在思考：为什么我不可以自己做一个呢？因此，在一个寻常的午后，我很随意地开动了。
一个月前，我在主机论坛发帖介绍它，当时还是 2300 多。一个月增加了 1100 个 Star。对成熟项目来说，这个数字可能不算多，但 Netcatty 是我的第一个开源项目。看到这么多人愿意点进仓库、下载软件、留下一个 Star，甚至把它当成每天都在用的主力工具，我还是挺开心的。
写这篇文章时，仓库里已经有大约 3000 次提交、150 个发布版本，还有几十位参与过贡献的人。
这些数字看上去很热闹，但很多人不知道的是。Netcatty 的第一版，我大概只用了三周。后面的半年多时间，我都在处理第一版没有碰到的问题。
做一个能够连接 SSH 主机的演示真的很容易。在AI时代，一个下午，几百行代码，就能看到终端里出现远程服务器的提示符。可要让别人愿意每天打开它，难度完全变了。
维护这个项目半年多以来，我最大的感受就是：AI 可以帮我写代码，却不会主动告诉我，某个用户正在一台什么机器上，被哪个细节绊住了。
今天的 Netcatty，是用户一次次反馈，加上我一次次返工之后才有的样子。
我为什么要再做一个终端软件
我以前是 Termius 的重度用户。
Termius 确实好用，界面成熟，多设备体验也做得很好。我最常用的是云同步，可以在不同电脑之间同步主机和配置。只是为了这个需求，每个月要付接近 15 美元，我慢慢觉得有点贵。现在越来越多的软件在做订阅制，基本上价格都在十几到 20 美元。一个两个还好，但是如果太多的话，感觉其实用不到那么多软件，而且在经济上也会造成很多不必要的浪费。
我也找过不少替代品。有些终端能力很强，有些只专注 SSH，有些支持同步，但整体使用体验没有达到我的预期。那段时间 AI 编程工具已经越来越好用，开发软件的门槛突然低了很多。我就想，既然一直没找到完全顺手的，能不能自己做一个。
2025 年 12 月，我写下了 Netcatty 的第一批代码。2026 年 1 月，肉眼能看到的 Termius 核心功能已经复刻得差不多了，v1.0.0 也随之发布。
最早的目标很简单。做一个开源、免费、支持云同步的 SSH 客户端，平时我自己用，遇到问题就顺手修一修。如果也能帮到有相同需求的人，那就更好。
当时我没有想过它会有 3400 个 Star，也没有想过半年后，自己会在终端性能、远程文件传输、不同 Linux 发行版和 AI 权限上花掉这么多时间。
第一版带来的兴奋很短。软件一旦交到别人手里，真正的工作才开始。
三周做出第一版，半年才学会怎么做产品
自己使用时，我只会走自己熟悉的路径。用户名怎么填，密钥放在哪里，主机怎么分组，遇到报错去哪里看，我都已经知道。
用户不知道，也不应该知道。
他们会从 Xshell、MobaXterm、FinalShell、Termius、Tabby 或系统终端迁移过来。有人用密码，有人用私钥，有人要经过两层跳板机。有人连接现代 Linux，也有人维护十年前的系统、网络设备和串口设备。还有人的公司电脑装着各种安全软件、代理软件和输入增强工具。
只要其中一个环节不符合预期，他们看到的结果就只有两个字，难用。
这半年里，我越来越少因为完成一个新功能而兴奋，反倒会在一个问题彻底修好后松一口气。大量日志刷出来时终端会不会卡，窗口放到后台一小时后能不能继续显示，SSH 断开后能不能恢复，SFTP 上传的大文件是否真的完整，Ctrl+C 能不能及时送到远程进程，这些都没有一个漂亮的功能名字，却直接决定软件能不能长期使用。
有一次，大文件上传时使用的数据块太大，远程文件可能已经损坏，界面却还显示上传成功。这个问题比界面上少一个按钮严重得多。后来上传过程改成了更稳妥的分块方式，并增加远程文件大小检查。
我也尝试过让隐藏的终端标签自动休眠，希望节省内存。实际用下来，它引入的恢复问题比省下来的资源更明显。标签切回来可能显示不完整，tmux 也可能停止刷新。现在这个功能默认关闭，终端会持续处理输出。
做产品经常会碰到这种情况。一个想法听上去很合理，跑进真实环境以后，结果并不好。删掉或关闭它，同样是一次进步。
AI 把制作第一版的时间压得很短，但产品成熟所需要的时间并没有一起消失。兼容性、稳定性和用户习惯，依然要靠长期积累。
我是怎么公开做这个项目的
2026 年 3 月 1 日，我第一次在开发者社区正式介绍 Netcatty。
之所以决定发帖，是因为看到有人随便 vibe 了一个几乎不能用的终端软件，都可以在上面发帖,甚至收费。当时可能稍微有点觉得幽默，所以就直接也发了个帖子。
在此之前我都有点完美主义，觉得如果软件没有做得太完善，就不好意思拿出去见人。现在来看，其实哪有完美的那一天呢？
那篇帖子没有太多故事，就是把做它的原因、已经完成的功能和当时的缺口写了出来。我也直接说明，FIDO2 和生物密钥还没有做，移动端也没有。
帖子发出去以后，我收到了很多鼓励，也收到了不少很具体的问题。有人嫌 Electron 安装包太大，有人问为什么还要再做一个 Termius 平替，也有人希望增加移动端、历史命令、更多导入格式和 SFTP 收藏。
其中有位网友问，云同步之外，能不能接入 AI。我当时的回答是，这个建议很有道理，但我还没有想好产品形态。
不到 20 天，我发了第二篇帖子。Netcatty 的终端旁边已经多了一个 AI 对话面板。你可以让它检查服务器、分析日志，也可以让它跨多台主机完成任务。后来我又接入了本地 Codex、Claude Code 和网络搜索。
这段经历基本就是我对公开开发最直接的理解。把尚未完全成熟的产品交给真实用户，听他们说哪里有用、哪里别扭，然后带着已经做出来的变化回来。
我没有把每一次提交都发到网上。零碎进度对别人没有太大价值。我更愿意在一个阶段结束后，把上次遇到的问题、这次做出的结果，以及仍然没有解决的事放在一起讲。
评论区也不只是宣传渠道。
有人反馈 Windows 10 上连接主机后闪退。我自己的机器一直无法复现，对方拉取源码时又卡在依赖安装上。继续让用户配开发环境并不现实，于是后来的版本里加了崩溃日志功能。下一位用户遇到相似问题时，可以直接把日志交给我。经过多位用户带日志的反馈和修复，目前软件本身的崩溃状况已经越来越少了。
公开开发以后，批评会来得很直接。有人看到 Electron 就决定不试，有人质疑几百 MB 的安装包，有人觉得终端根本不需要 AI。我的选择也谈不上完美。作为一个业余时间维护跨平台项目的个人开发者，Electron 让我可以把有限精力放在 macOS、Windows 和 Linux 的共同体验上，同时也带来了体积和资源占用。因此我觉得把这个取舍讲清楚，比假装缺点不存在更有用。
我从这半年里总结了几条对自己有效的做法。产品要从自己真正遇到的问题开始，第一次公开时就把适用人群和缺口说清楚。后续每次发声都要有新的交付，不能反复讲同一组卖点。遇到模糊反馈，尽量追问到系统版本、操作路径和复现步骤。暂时修不了，也说明缺少什么样本。
还有一点很重要，Star 适合记录阶段，却不能代替用户和使用数据。3400 个 Star 不等于 3400 个活跃用户，更谈不上商业成功。它只能说明，至少有一批人看到了这个项目，觉得值得继续关注。
公开开发给 Netcatty 带来了用户、反馈和贡献者，也把维护压力公开摆在了我面前。两边都是真的。
半年以后，Netcatty 已经长成了什么样
最初的 Netcatty，重点是主机管理、终端和云同步。
现在它已经更接近一个远程工作区。你可以用网格、列表或树形结构整理主机，给它们分组、搜索和排序。云同步支持 GitHub Gist、Google Drive、OneDrive、S3 和 WebDAV。终端支持多标签和分屏，SFTP 可以在本地与远程之间拖拽文件，也有内置编辑器。
我很在意操作过程里的连续感。
连接服务器以后，常驻主机侧栏可以继续打开其他机器，不用退回主机库。系统面板能直接看到 CPU、内存、磁盘、网络和高占用进程，也能管理进程、Docker 和 tmux。端口转发、命令片段、主机笔记和自动化脚本都放在同一个工作区里。
自动化脚本是我最近很喜欢的一项功能。很多公司的服务器需要经过堡垒机。登录后还要在一层层菜单里选择分组、主机和账号，有时还会遇到动态验证码。以前每天都要重复输入，网络一慢，固定延时的脚本还容易走错顺序。
Netcatty 的脚本会等待终端里出现指定内容，再继续输入下一步。它跟着实际画面往下走，堡垒机响应慢一点也不容易乱。你还可以让 AI 生成脚本，再保存到主机上长期使用。
Mosh 也经历了一次比较大的改动。早期 Windows 版本依赖 Cygwin 和一组配套文件，缺一个文件或路径不对都可能启动失败。后来我用 Rust 重新写了 MoshCatty。Windows 客户端压缩后从大约 6.4 MB 降到 0.2 MB，也已经作为独立项目开源。
说到 AI，Netcatty 里的 Catty Agent 可以读取当前服务器环境、执行命令、分析输出，也能协调多台主机。我曾经让它在两台服务器上搭建 Docker Swarm，它会处理初始化、令牌交换和节点加入。遇到不确定的问题，它还可以先搜索网络资料，再结合当前终端继续处理。
最近加入的外部 MCP，则把这些能力开放给了用户已经在使用的 AI。Codex、Claude Code、Cursor 和 Grok 可以通过 Netcatty 查看当前终端、打开主机、执行命令、操作远程文件、使用自动化脚本和端口转发。
这些操作都会出现在 Netcatty 的终端标签里。你能看到 AI 连接了哪台机器、执行了什么，也能随时停止或接管。保存在 Netcatty 里的密码、私钥和密钥口令不会交给外部 AI。写操作可以完全禁止，也可以逐次确认。
我对 AI 终端的期待很朴素。它应该减少查资料、复制日志和重复输入的时间，服务器上的决定权仍然留在用户手里。
网上怎么评价 Netcatty
这半年，我看到过不少让我很开心的评论。
有人说中文和同步解决了他的两个痛点，有人提了几个问题后评价响应很快，也有人说已经把 Netcatty 当成主力工具。还有用户在试过 Xshell、MobaXterm、Tabby 和 Windows Terminal 以后，认为 Netcatty 的主机同步、AI 对话和命令执行整合得比较顺手。
第一次在开发者社区发帖后，还有贡献者直接提交了多次改进。对一个第一次做开源项目的人来说，这种回应很难得。它说明别人愿意花时间理解项目，甚至愿意帮它变好。
当然，批评也很多。
在众多的批评声中，声音最大的就是对于 Electron 这个框架的批评，且关于 Electron 的争论似乎在网上永无休止。除此以外，更新太频繁、缺少移动端、某些导入格式不支持。早期还有连接后闪退、设置页面 CPU 占用过高、主题没有生效、自动更新失败等问题。有位用户试了三次都闪退，直接放弃了。站在他的角度，这个决定完全合理。终端里放着生产服务器，稳定性不过关，再多功能也很难建立信任。
我现在更看重这种具体的负面评价。泛泛的好用会让我开心几分钟，一条清楚的复现路径却可能改变后面很多个版本。
当然，用户需求也不能全部照单全收。机器越多、使用场景越复杂，功能请求会越来越分散。别人有的功能全部加进来，软件很快就会失去主线，维护成本也会压垮一个个人项目。
我需要听见每个需求，再决定它是否适合 Netcatty。这两件事并不冲突。
3400 个 Star 以后，我想把速度放慢一点
项目刚公开时，我在帖子里写过，后续也不会收费。
那时候我的想法很简单。自己需要，就自己做；顺便帮到别人，也是一件挺好的事。维护半年以后，我开始理解，只靠热情很难支撑一个长期项目。热情会被消耗，问题却不会自己消失。
Netcatty 的桌面客户端会继续保持开源和免费。与此同时，我也会寻找一些合理的收入方式，让维护、签名、基础服务和后续开发能够持续。目前还没有非常确定的商业化规划，主要是不希望为了追求变现，而打破了桌面端现有的平衡与纯粹。
这半年里，社区也给了我一些额外的鼓励。第二次在 V2EX 发帖后，我尝试申请了 OpenAI 的开源项目支持计划，没想到通过了。
后来我又购买了 Apple 开发者资格，给 macOS 客户端做签名和公证。对一个最初只是想省下 Termius 订阅费的个人项目来说，这些投入是我刚开始完全没有想到的。
移动端也已经在开发，会优先考虑 iOS 和 iPad。我不想简单缩小桌面界面，再做一个只能在手机上连接 SSH 的应用。移动设备上的使用时间、网络环境和操作方式都不同，具体应该做成什么样，我可能还会继续想想。
发布节奏也会调整。前一段时间几乎每天都有更新。用户需要反复下载安装，但是因为我仅仅是业余时间开发，平时也会有本职工作非常忙碌的时候，因此我自己也很难给每个版本留出足够测试时间。所以接下来我会减少功能堆叠，让版本多运行一段时间，再集中处理问题。
当然，每天都更新这种行为虽然看起来非常离谱，但在 AI 时代其实是很正常的事情，我曾经在网上看到一个梗，说 AI 时代软件的版本号应该把日期放在里面😂。每天对于我而言，也仅仅是下班以后去翻阅一下issue，然后让 AI 去处理，单元测试、验证，甚至连集成测试也是 AI 完成的。
降低更新频率这个决定听起来没有增加新功能那么兴奋，但现在的 Netcatty 更需要它。
写在结尾
从 2025 年 12 月写下第一批代码，到今天超过 3400 个 Star，时间只有半年多。
三周做出第一版，是 AI 编程带来的速度。后面的半年让我看到，软件最终会长成什么样，取决于谁在使用它、他们遇到了什么，以及维护者愿意为这些问题投入多少时间。
我很感谢每一个 Star，但更感谢那些真正下载过软件的人。有人认真写下复现步骤，有人直接提交代码，也有人毫不客气地指出哪里难用。Netcatty 能从一个满足个人需求的小工具走到今天，靠的是这些具体的反馈。
我还不知道这个项目最终会走到哪里。眼下更想做的，是让它稳定一点，更新从容一点，也让维护这件事能够持续久一点。
如果你平时需要管理服务器，做一些繁杂的运维工作，欢迎试试 Netcatty。遇到问题可以在 GitHub 提交反馈。哪怕只告诉我某个地方用起来很别扭，也可能影响它后面的样子。
项目地址 github.com/binaricat/Netcatty
官网 https://netcatty.app
