我讨厌现在的软件里面动不动就加 AI
我在推广 WispTerm 的时候，经常会遇到一种反馈：
现在最讨厌的，就是终端里面也要加 AI。
说实话，我也讨厌。
我讨厌那种软件里动不动就加大模型的风气。原本好好的工具，突然多了一个 AI 按钮、一个 AI 侧边栏、一个不知道什么时候会冒出来的“智能助手”。它看起来很先进，实际用起来很别扭。它不了解你 正在做什么，也接不住复杂任务，最后只是把一个本来清爽的工具变得更重、更慢、更吵。
更糟糕的是，很多这种功能一眼看过去，就不像是从用户问题出发做的。它们像是为了赶 KPI 做出来的：这个季度必须有 AI，这个版本必须有模型能力，于是产品里硬塞一个聊天框。至于它是不是真的 好用，是不是真的嵌进了工作流，是不是真的减少了人的负担，好像都不重要。
所以一开始，我完全没想做一个“AI 终端”。
我最初的需求非常小：我想把终端里的东西，尤其是图片、截图、命令输出，更方便地交给 Claude Code 或 Codex。仅此而已。
更准确地说，我一开始想做的其实是 otty 那类工具：用户自己带着 Claude Code、Codex 或别的命令行 agent 来，我只做一个好用的终端。你要用什么模型、什么 agent、什么账号，那是你的选择；WispTerm 不需要把自己做成另一个 agent 平台。
终端本身不应该承担太重的任务。它应该像一个可靠的工作台：打开、输入、输出、复制、粘贴。不要挡路，不要自作聪明，不要把一个很简单的动作变成一套“智能工作流”。
但我很快发现，在 Windows 上，这件小事并不顺手。
我先看 Ghostty。Ghostty 很好，我也很喜欢它的设计。WispTerm 底层一直跟着 Ghostty 的方向走，终端解析用的也是 libghostty-vt。但问题是，Ghostty 当时主要是 macOS 和 Linux；我需要的是 Windows。
后来我在 awesome-libghostty 里看到了一个 Windows 项目，Phantty / ghotty。它是一个用 Zig 写的 Windows terminal emulator，基于 libghostty-vt、ConPTY、OpenGL、FreeType 和 DirectWrite。方向很对，所以我 fork 了它。
从 git history 看，我真正开始接手这个 fork 是 2026 年 4 月 30 日。5 月 1 日，我发了 v0.1：一个 Windows build，可以从 GitHub Release 下载。那时候目标非常明确，就是先把 Windows 上能用的终端体验补起来。
我当时真的只是想加一个图片粘贴功能。
现在回头看版本历史，会觉得这件事有点离谱。5 月 2 日的 v0.5.0 加了 Ctrl-click 文件预览；同一天还加了 kitty graphics 渲染和远程 imgcat/pdfcat 工具。5 月 5 日，v0.6.0 / v0.6.1 开始支持剪贴板图片粘贴，v0.7.0 处理 SSH 图片上传，v0.8.0 又加了带 SSH/SCP 远程传输能力的文件浏览器。
看起来像是在快速堆功能，但背后的动机其实很朴素：我不想为了让模型看一张图、一个文件、一段远程输出，在终端、资源管理器、浏览器、聊天窗口之间来回搬东西。
补完之后，我本来打算结束。
但 PR 没人接，原项目也已经很久没有更新。于是事情变成了：既然我要用，那只能自己继续维护。
后面的发展，基本都是被真实使用场景推着走的。
先是文件预览。v0.12.0 的 release note 里写得很直白：让 Phantty 成为一个“不离开终端也能检查文件”的地方。Markdown、文本、图片、PDF，最好不要离开终端就能看。然后是 SSH：远程文件要能 预览、下载、上传，不能每次都手写 scp。再后来是 embedded browser panel、SSH tunnel、remote console、移动端访问、端口转发、会话恢复。
到这里为止，它还不是一个 AI 产品。它只是一个越来越适合远程开发的终端工作区。
AI 是后来才变得合理的。
5 月 12 日，v0.18.0 加了 AI Chat tabs；同一天 v0.19.0 开始让 AI Chat 变成 agent，可以观察终端、执行本地命令、向已经打开的 SSH session 注入命令。5 月 15 日前后，又出现了 Agent History、Skill loading、命令中心入口。
这不是因为我突然觉得“终端必须 AI 化”。恰恰相反，是因为当你真的每天用 Claude Code、Codex 或其他 agent 写代码，会发现最大的问题不是“有没有一个聊天框”。最大的问题是上下文在哪里。
错误在终端里，文件在 SSH 服务器上，截图在剪贴板里，当前目录在某个 pane 里，历史对话在另一个工具里，Jupyter 或 Web 服务跑在远端端口上。模型看不见这些东西，你就只能手动复制、截图、 解释、再复制。
复制一次还能忍，复制十次就会烦。尤其是当你已经知道模型可以帮你做事，却还要花大量时间告诉它“我现在在哪个目录”“刚才终端输出了什么”“这个文件在远程服务器上”“你不要操作那个 pane”，这种感觉非常糟糕。
这才是 WispTerm 里 AI 功能的来源。
还有一个更现实的问题：很多人甚至还没走到“把上下文交给 Codex / Claude Code”这一步，就已经卡在配置上了。
我遇到过不少用户，不是不想用命令行，不是不想用 agent，而是卡在最前面的几步：Codex 怎么配置，Claude Code 怎么接，API key 放哪里，base URL 怎么填，模型名写什么，为什么请求失败，为什么工具不能跑。对熟悉命令行的人来说，这些只是环境问题；对刚开始想用命令行的人来说，这些就是第一道墙。
这也是我后来想加 Copilot 的初衷之一。它不是为了替代 Codex 或 Claude Code，而是给那些还没那么熟悉命令行、但确实想借助 agent 做事的人一个更顺手的入口。
我不想在终端里塞一个“万能助手”。我想要的是：当我在某个终端 pane 里工作时，右边的 Copilot 知道它绑定的是这个终端；它能看到当前目录和最近输出；它知道自己面对的是本地 shell、WSL 还是 SSH；它能按需调用工具，但危险命令必须确认；它能恢复历史、导出 Markdown、切换模型、管理技能和工具。
换句话说，它不是来替代终端的，而是尽量少打断我正在做的事。
这也是为什么 5 月 30 日的 v1.2.0 才真正出现 in-context AI Copilot sidebar。它不是启动页上的 AI 聊天入口，也不是为了显得产品“智能”的按钮。它是一个绑定当前终端的侧边栏：你在 shell 里工作，它在旁边看得到一点现场，必要时帮你问、查、执行、总结。
我最开始也只专注 Windows。
原因很简单：macOS 里面已经有太多好用的终端了。Ghostty、iTerm2、WezTerm、kitty，都已经很好。对我来说，完全没有必要再做一个 macOS 终端。Windows 才是我一开始真正想解决的问题：Ghostty 的体验很好，但 Windows 用户用不上；Phantty 方向对，但没人继续维护；那我就先把 Windows 这条路打通。
所以 WispTerm 的早期版本几乎都是围绕 Windows 走的：Windows release、Windows packaging、ConPTY、DirectWrite、SCP、PowerShell、WSL、Windows 上的文件浏览器和 UI 自动化。
但后来还是做了 macOS。
不是因为 macOS 缺终端，而是因为确实有人需要这个小小的 agent copilot 功能。不是所有人都想换一个终端；很多人只是想在现有开发习惯里，有一个能绑定当前终端、能看到上下文、能和 Claude/Codex 这类 agent 工作流接上的侧边栏。
于是 5 月 28 日，v0.35.0 才有了第一个原生 macOS app。release note 里我写得很保守：macOS support is new and may still have bugs，daily stability 可以优先用 Linux/Windows 或 Ghostty。这不是客套话。因为我很清楚，macOS 上不是没有好终端，WispTerm 在 macOS 上真正值得做的，是把这个 agent copilot 工作流带过去。
5 月 29 日，项目从 Phantty 改名 WispTerm，发了 v1.0.0。5 月 30 日，v1.1.0 加了自定义 slash commands 和 Anthropic / Claude Messages API 支持；同一天 v1.2.0 加了绑定当前终端的 Copilot sidebar。到 6 月 23 日的 v1.28.0，Copilot 侧边栏会话已经可以持久化、恢复、导出 Markdown，也能通过 history picker 重新打开。
如果只看最后的功能表，很容易得出一个结论：这不就是终端里加 AI 吗？
甚至有人会问我：那 WispTerm 跟 Codex、Claude Code 相比有什么区别？
这其实不是一个赛道。Codex 和 Claude Code 是 agent，是模型驱动的编程助手。WispTerm 是终端，是你进入命令行、连接 SSH、查看文件、运行命令、调用这些 agent 的工作台。它不是要和 Codex 或 Claude Code 抢位置，而是让你使用它们的时候少一点摩擦。
尤其对初学者来说，很多时候真正卡住的不是“大模型不会回答”，而是命令想不起来、配置找不到、路径不知道怎么写、远程文件不知道怎么拿、终端输出不知道该复制哪一段。这些问题不一定值得专门 打开网页去问，也不一定值得开一个完整的 agent session。它们只是你在命令行里走路时被绊了一下。
WispTerm 里的 Copilot 更像是处理这些小摩擦的东西：命令想不起来时问一句，当前输出看不懂时问一句，配置项不知道怎么填时问一句。它的价值不是“比 Codex 更聪明”，而是它就在终端旁边，并且知道你大概站在哪里。
但从开发顺序看，故事不是这样的。
它不是从“我要做一个 AI 终端”开始的。
它是从“我受够了在工具之间搬上下文”开始的。
这也是我对很多软件里 AI 功能不满的地方。它们看起来加了模型，但没有真的理解软件自己的工作现场。一个编辑器里的 AI 如果不知道项目结构、不知道当前文件、不知道测试怎么跑，那它只是聊天 框。一个终端里的 AI 如果不知道当前 pane、不知道 shell 状态、不知道 SSH 上下文、不知道哪些命令危险，那它也只是聊天框。
聊天框本身没有错，但把聊天框贴进任何软件里，然后说这是 AI 化，我觉得很没意思。
真正有用的 AI 功能，应该少一点存在感。
它不应该逼你进入另一个工作流，而应该待在你原来的工作流旁边。它不应该让你为了使用它而整理一堆上下文，而应该尽量从软件本身已经知道的信息里拿到上下文。它不应该假装自己无所不能，而应 该在该确认的时候确认，在该停下来的时候停下，在不知道的时候明确告诉你不知道。
这也是为什么 WispTerm 里很多 AI 相关功能听起来并不炫：绑定当前终端、自动附带最近输出、保存和恢复会话、导出 Markdown、工具权限、危险命令确认、Skill Center、agent 状态提示、Copilot 历史选择器。
这些东西没有“重新定义终端”那么好听。
但它们解决的是我每天真的会碰到的问题。
我仍然讨厌软件里面动不动就加大模型。尤其讨厌那种为了赶 KPI 做出来的 AI 功能：入口很显眼，文案很激动，用起来却没有半点工作流上的诚意。
但我不讨厌工具变得更懂自己的工作现场。
WispTerm 想避免的正是前一种东西。终端还是终端，shell 还是 shell，用户仍然掌握方向。模型只是坐在旁边，能看见一点上下文，必要时能搭把手。
如果它做不到这一点，那我宁愿不要 AI。
如果它做到了，那它最好也别太像一个“AI 功能”。
