上个月我在一块ESP32开发板上调一个外设驱动电脑放在工位上人蹲在测试台旁边一遍改menuconfig一遍烧录。旁边没有 IDE只有一个开了三个标签页的终端一个跑着串口监视器一个是ssh到服务器看日志还有一个就是我想写代码却不知道从哪儿下手的地方。当时我就想如果有一个 AI 编程助手能直接活在终端里不用切窗口、不用鼠标点按钮就蹲在命令行里听我说话那该多好。后来我试到 Super Code这个想法成了现实而且它解决的不止是在终端里能用 AI这一件事。Super Code 是一款原生跑在终端里的 AI 编程助手支持自然语言生成命令、代码解释、仓库级问答、自动修复报错。它特别适合三种人第一种是常年在 SSH 远程机器上干活、没有图形界面的运维和后端第二种是搞嵌入式、单片机天天跟串口终端和交叉编译链打交道的人第三种是已经用惯了tmux终端复用不想要再开一个重型 IDE 占内存的开发者。这篇文章我不打算写成官方的 README 复述而是从我实际折腾了两周的经验出发讲讲 Super Code 到底解决了哪些真实痛点、怎么把它接入自己的工作流以及它跟 Cursor、Copilot 这些主流助手比谁更适合什么场景。1. 为什么一个终端里的 AI 助手是刚需而不是锦上添花1.1 GUI 助手在三个场景里真的会让人抓狂我最早用的也是 VSCode 加 Copilot或者 Cursor说实话在纯前端、后端 Web 开发里它们体验确实好有上下文能跳转能直接在代码里给你补全。但一旦离开图形界面它们的短板就暴露得非常干脆。第一个场景是远程开发。你ssh进一台云服务器或者公司的堡垒机上面没有桌面环境只有一堆命令行工具。你总不能为了用 AI 再装一个 X Server 转发图形界面。这时候你需要的不是在 IDE 里帮你补全的 Copilot而是在终端里能读懂你正在敲什么命令、能看穿你当前工作目录和 git 状态的助手。Super Code 的设计原点就在这儿它就是为纯命令行环境生的。第二个场景是嵌入式开发。ESP32、STM32这些项目经常要跟idf.py menuconfig、openocd、arm-none-eabi-gcc打交道。这些工具的交互全在终端里完成。你在写CMakeLists.txt时想让 AI 解释一下某个target_compile_definitions的写法或者想让它帮你生成一段初始化 I2C 的代码如果每次都要复制到网页聊天框里来回切换的效率实在太低了。第三个场景是终端的惯性使用者。我身边有些老程序员工作流就是tmuxvimgit他们已经习惯了鼠标只用来复制粘贴。对他们来说为了一个 AI 功能被迫去打开带有 AI 插件的 IDE是很别扭的一件事。他们需要的不是一个有终端的 IDE而是一个长在终端里、可以随时召唤的 AI 同事。1.2 终端形态带来的不可替代的上下文优势Super Code 和网页版 ChatGPT 最大的区别就是它天然把你的终端上下文作为对话的参考书。官方虽然没有吹得太玄乎但我实际用下来它会自动读取这么几样东西当前 shell 的历史记录和当前输入的未提交命令当前工作目录下的.git状态包括分支、改动文件、最近 commit 信息系统的环境变量和 shell 类型bash/zsh你最近执行的几条命令及其输出特别是报错信息。这意味着什么举个例子你在终端里跑pytest有一堆测试挂了终端里飘着红色的 traceback。你只需要在 Super Code 的对话行里输入帮我看看这个报错怎么回事它不需要你手动贴报错信息因为它已经从上一条命令的输出里拿到了。它会直接告诉你问题出在哪个模块的哪一行大概率原因是什么甚至已经帮你写好了修复命令。这就是活在你的终端里最实在的价值——它不用问你要上下文因为它自己看得见。我在用 Cursor 的时候经常需要自己 CmdC / CmdV 把报错贴给 AI但是在 Super Code 里这个动作被削掉了。别小看这一个动作一天下来省下来的时间至少二十分钟更重要的是你不会因为懒得复制而放弃求助 AI。2. Super Code 的核心能力拆解先把底牌看清楚2.1 自然语言到命令的中转站解决命令记不全的问题这年头没人能记住所有命令的拼写尤其是那些很长又低频的。比如ffmpeg的滤镜参数、openssl的证书转换语法我每次都要翻文档。Super Code 的第一个基础能力就是把自然语言翻译成命令。我实测了一个非常典型的场景我需要把当前目录下所有.wav文件转成 16kHz 单声道的.mp3还要保持文件名不变。我直接输入把当前目录下所有 wav 文件转成 16kHz 单声道的 mp3文件名保持不变Super Code 在消息区域回显了一条命令for f in *.wav; do ffmpeg -i $f -ar 16000 -ac 1 ${f%.wav}.mp3; done它不仅仅是把这句话翻译成了命令还考虑了三个细节-ar 16000音频采样率、-ac 1声道数、${f%.wav}文件名后缀替换。这些细节恰恰是新手最容易漏掉的。如果你直接去问搜索引擎大概率会得到一个非常朴素的ffmpeg -i input.wav output.mp3然后你发现码率、声道全都不对。但这有一个前提它会先把命令回显给你看而不是直接执行。你需要按回车确认或者直接拒绝。这种设计很关键——AI 的命令理解能力再强也不能跳过人工确认。尤其是那些会rm -rf、会覆盖文件的命令我建议你养成先看再跑的习惯。2.2 仓库级代码问答它认识你的整个项目Super Code 不只是一个命令翻译器它能读取你当前项目目录里的代码结构。这就意味着你可以问它一些很上下文相关的问题比如这个项目里是怎么处理用户登录鉴权的把相关的文件和函数列出来。它不会给你一个空泛的常见的 JWT 鉴权流程是……的废话而是会基于当前仓库的实际代码告诉你src/auth/login.go里用了gin的 middlewareutils/token.go里有个GenerateToken函数config/config.yaml里有jwt_secret的配置项。并且它会在回答里标注引用的文件路径方便你直接查看。这种能力的原理类似于代码库索引Super Code 会为当前 git 仓库构建一个轻量索引把文件结构、函数签名、关键注释提取出来。它不需要把整个仓库塞进模型上下文而是按需读取相关文件片段。所以它的响应速度很快就算仓库里有几万个文件也不会卡到没法用。我跟它做了一次比较有意思的对话我在一个用platformio管理的 ESP32 项目里问它现在的分区表是怎么配的Flash 够不够用。它读了partitions.csv和platformio.ini之后告诉我当前配置中有 4MB Flashapp0 分区 1.5MBspiffs 分区 0.5MB并且提示我如果启用了CONFIG_ESP32_SPIRAM项目实际占用的内存会更大建议调整。这个回答不是背知识点是真真切切地基于我的项目现状做的判断。这比那种什么都懂但不了解你项目的通用 AI 有价值太多。2.3 自动修复报错把复制报错-问 AI-拿答案压缩成一条指令这里我要重点讲一下它的报错自动抓取机制。Super Code 启动后会在后台监听当前 shell 进程的输出注意它只监听你当前的那个终端会话不是系统全局的。当你运行一条命令并失败时它可以自动将最后一段错误输出提取出来作为上下文附加到你下一次提问中。比如我在 WSL2 里编译一个 Linux 内核模块make报了一个头文件找不到的错误。这个报错信息非常长路径嵌套了三层。我直接在 Super Code 里输入这个头文件路径问题咋解决它在回答里先复述了我刚才报错的关键片段再给出解决方案。我觉得这个复述动作很关键说明它确实读到了这段报错而不是在猜。然后它给出的建议是在Makefile里加一句ccflags-y -I$(src)/include还解释了为什么$(src)比$(PWD)更可靠。这句话正好点到了内核模块编译的一个经典坑直接用PWD会被 make 的-C参数影响导致路径指向错误。这些细节说明它不是只做报错文本匹配而是真的理解了这个错误在特定构建系统里的成因。2.4 可以当作 Shell 脚本生成器批量任务的好帮手除了上述三个被官方列为卖点的能力我用得最频繁的其实是它帮我写一次性脚本。比如我下载了一批数据集有train/和test/两个目录我想统计每个类别的样本数量还想把类别不均匀的文件列出来。这种需求如果想自己写会花几分钟查 API 文档但是用 Super Code 直接描述需求它生成的 Python 脚本能在大部分情况下直接跑通。更让我好感的是它生成的脚本里会包含异常处理和注释。有一次我让它写一段批量重命名文件的脚本它自动加了pathlib的.exists()检查和try/except还会对重命名前后做一个预检查防止from和to指向同一个文件。这种防御性编程的自觉源于它对常见失败模式的了解而不是简单地堆代码。当然我依然会一行一行读它生成的脚本AI 写的代码没有人兜底是不负责任的但至少在初稿层面它帮我把大量脚手架工作做完了。3. 安装与配置从零到跑通的完整细节3.1 支持的平台与安装方式Super Code 官方支持 macOSIntel 和 Apple Silicon、Linuxx86_64 和 aarch64、Windows 10/11原生终端和 WSL2 均可用。这点我拉满好感因为多数终端 AI 工具对 Windows 原生环境的支持都像后妈养的Super Code 至少做到了开箱可用。安装方式非常简单两条路可选方式一用包管理器安装。macOS 上用 Homebrewbrew install super-codeDebian/Ubuntu 上建议直接下载.deb包或者用官方脚本curl -fsSL https://get.supercode.dev | bash方式二用原生二进制安装。官方在 GitHub Releases 里提供各平台编译好的二进制下载解压后把可执行文件放到PATH里就行。如果你对安全要求高也可以自己从源码编译但那不是一般用户需要的。我在一台最老旧的 Ubuntu 18.04 服务器上也试过直接拷贝静态编译的二进制进去就能跑不需要额外动态库这点对远程服务器相当友好。3.2 配置文件第一次启动该填什么启动 Super Code 之后它会自动生成配置文件~/.supercode/config.json。打开看一下核心配置项并不多配置项作用我的建议model指定底层模型标识官方默认是deepseek-v3但我个人更常用claude-sonnet-4因为代码感更好api_base设置兼容接口的模型服务地址如果你想接本地部署的模型或第三方中转改这里api_key模型服务的密钥建议用环境变量SUPERCODE_API_KEY注入不要硬写进配置文件context_mode控制自动读取上下文的层级full/repo/shell三档默认repo我觉得这是性价比最高的档位confirm_before_run是否需要确认后执行命令默认true强烈建议保持history_limit读取 shell 历史的最大条数默认 50如果想让它更懂你的习惯可以调高到 200我第一次配置时踩了个小坑因为是在远程服务器上安装我习惯性把api_key直接写进了配置文件结果这个文件是644权限同事都能读。后来我改成用环境变量注入权限这块就安心了。如果你用的是 zsh可以在~/.zshrc里加一行export SUPERCODE_API_KEY你的密钥然后在 Super Code 的配置里把api_key字段留空它启动时会优先读取环境变量。这样密钥不会落到磁盘上的明文字段里至少多一层保险。3.3 启动方式与快捷键怎么把它召唤出来Super Code 通常有两种启动形态独立对话模式在终端里输入supercode它会进入一个全屏的交互式 TUI 界面风格类似htop左侧是对话历史右侧是当前回答的 Markdown 渲染区。这个模式适合长对话、需要浏览大量代码的场景。内联助手模式在任意 shell 会话里你可以通过快捷键唤醒一个浮层窗口。例如我在 zsh 里设置CtrlSpace呼出输入框直接在浮层里输入问题回答会以内联的方式插入到当前终端缓存区不需要打断正在运行的前台任务。这么设计的好处是你正在跑一个长任务时不想中断它但又想顺手问个问题。你可以完全并行地进行任务继续在后台跑Super Code 的浮层浮在终端上面两不打扰。第二种形态是我日常使用率最高的。我用tmux开多个窗口在一个窗口里跑开发服务器另一个窗口开 Super Code 浮层查问题查资料完全不影响第一个窗口的输出。如果你也习惯终端复用这个形态会很顺手。3.4 对接本地模型零成本方案和离线兜底前面提到api_base是可配置的这意味着 Super Code 不仅能连接官方托管的模型也可以对接本地大模型服务。我在一台有 24GB 显存的机器上跑过Qwen2.5-Coder-14B用vllm起一个 OpenAI 兼容的服务vllm serve Qwen/Qwen2.5-Coder-14B-Instruct --port 8000然后修改配置{ api_base: http://localhost:8000/v1, model: Qwen/Qwen2.5-Coder-14B-Instruct }实测下来14B 的模型对终端命令的理解能力稍弱复杂一点的仓库级问答会答得比较模糊但简单的命令翻译、报错小结是没问题的。如果你只是在没有外网的环境里用一用本地模型兜底绝对够。这也让 Super Code 多了一层可离线化的价值对数据敏感的团队来说这个自由度很重要。4. 真实场景实测从 ESP32 调试到 WSL2 排障4.1 嵌入式场景ESP32 终端开发的外挂我前面提到过在 ESP32 项目里测试 Super Code 的仓库问答。这里讲一个更具体的操作链路。我需要在 ESP32 项目里实现一个简单的 NTP 时间同步但是记不住esp_netif_sntp这套 API 在 IDF 5.x 之后的改名规则。我没有切到浏览器直接在项目目录下问这个项目里如果要用 SNTP 获取时间该调用哪些 API注意 IDF 版本是 v5.2。它给出的回答直接引用了当前项目managed_components里某个依赖的头文件路径指出在 v5.2 中esp_netif_sntp.h替代了旧的esp_sntp.h并给出了初始化代码片段esp_netif_sntp_init(sntp_config); esp_netif_sntp_start();这个答案如果让没有 AI 的人去翻文档可能要花上十几分钟去搜索 IDF 的版本迁移指南。而 Super Code 因为能同时看到项目依赖版本 头文件路径 编译环境它给出的代码天然契合当前项目。更重要的是它还能帮你生成针对这个项目的sdkconfig.defaults修改建议比如启用CONFIG_SNTP_TIME_SYNC_METHOD什么的。这些配置项在不同 IDF 版本里叫法不一样容易踩坑它帮你省去了试错的成本。4.2 WSL2 里的中文乱码问题一个顺手解决的意外另一个让我印象深刻的例子是在 WSL2 环境下。我因为工作需要装了 Ubuntu 发行版进入终端后跑ls中文文件名显示成乱码的一大片。这种问题通常跟 locale 环境有关但我一直懒得深入排查。某次我在 WSL2 终端里运行locale时看到大大小小的POSIX设置就顺手在 Super Code 里问了一句为什么 WSL2 终端里中文文件名乱码它先是解释了原理WSL2 的环境变量LANG没有设置为 UTF-8然后直接给出了修复命令sudo sed -i /^LANG/d /etc/default/locale echo LANGen_US.UTF-8 | sudo tee -a /etc/default/locale sudo locale-gen关键是它没有把那句LANGzh_CN.UTF-8塞给我而是用了en_US.UTF-8因为它知道这是大多数 Linux 服务器的默认选择且能覆盖中文显示。我执行之后重新打开的终端里中文文件名就正常了。这不算什么高深的功能但这种推己及人的细节真的很加好感。很多终端工具只会机械回答你输入的问题不会主动考虑到你的真实环境配置和最佳实践。这一点让我觉得 Super Code 真的有在揣摩用户意图。4.3 远程服务器上排查 Python 依赖冲突我在ssh到一台服务器部署一个 Flask 应用时启动后总是报错ImportError: cannot import name Flask from flask我知道这是依赖环境混乱导致的但是不知道具体是哪一个包路径出了问题。Super Code 根据我这边的输入自动把报错信息带进对话然后它给了一条诊断命令python3 -c import flask; print(flask.__file__)我执行后发现路径指向了/usr/local/lib/python3.8/dist-packages而不是当前虚拟环境的路径。它接着建议我删除当前的虚拟环境重建并激活后再安装依赖。整个排查过程是引导式的不需要我自己像搜索引擎那样来回试探。这其实是终端 AI 助手比 IDE 插件更强的地方IDE 插件通常只关注代码编辑很少帮你指挥终端命令而 Super Code 把命令执行、结果读取、下一步建议串成了一个闭环。5. 和主流 AI 编程助手横向对比选谁不只看性能5.1 竞品功能对比表现在市面上的 AI 编程助手大致分三类IDE 内置型、终端命令型和浏览器型。Super Code 属于终端命令型但它在功能覆盖上已经触到了 IDE 型的一部分界限。我拉了一张表做个直接对比工具核心形态代码补全终端命令执行仓库级问答自动读取报错适合场景Cursor独立 IDE极强内置终端但 AI 不直接操作很强需要手动粘贴前端/全栈开发重度重构VSCode CopilotIDE 插件极强不涉及强需要手动粘贴日常编码补全为主Windsurf独立 IDE强内置终端可执行命令强部分自动团队协作多文件修改Trae独立 IDE强内置终端强需要手动习惯国内生态的开发者ClineVSCode 插件中可以执行终端命令需授权中部分自动需要插件式 Agent 工作流Super Code原生终端中等原生支持确认后执行强自动读取远程/嵌入式/终端重度用户需要说明的是我没有贬低 IDE 型助手的意思。Cursor 的代码补全和联想能力依然是我见过的天花板尤其当你同时编辑多个文件、跨文件重构时它的上下文窗口和大模型调度机制确实高效。但 Cursor 是一个完整的 IDE意味着你必须在它的环境里写代码你没法在vim里享受它的能力。5.2 Super Code 的优势与明显短板先聊优势。终端形态带来的最大优势就是它可以覆盖 IDE 触及不到的系统级任务。比如你可以让它帮你修改 crontab 计划任务它可以先运行crontab -l看当前已有任务再给出新增任务的具体命令然后等你确认后执行。这种查看-分析-操作的循环在 IDE 型助手里是很难实现的因为它们和系统 shell 是隔离的。另一个优势是资源占用。我用 Cursor 开一个中型项目内存占用经常超过 2GB而 Super Code 就是一个 TUI 程序加上后端的语言模型服务本地资源占用可以忽略不计。在一台只有 4GB 内存的云服务器上这个差距是决定性的。再说短板。第一Super Code 的代码补全能力很弱。它本质上不是一个按一下 Tab 就续写的工具它更擅长的是你描述需求它给你整段代码或命令。所以如果你指望它像 Copilot 一样在你敲代码过程中实时补全那你会失望。第二它的多文件同时编辑能力目前还比较有限当你需要跨五个文件同步修改某个接口时它还做不到像 Cursor 那样生成一个多文件 patch 然后让你一键接受。第三TUI 界面对纯鼠标用户不太友好你得习惯键盘操作。5.3 我的选择逻辑工具是环境的仆人这里我想给一个自己的判断标准不是 AI 助手越强越好而是越贴合你的工作环境越好。如果你每天大部分时间都在 VSCode 或者 JetBrains 里写业务代码Copilot 或者 Cursor 插件仍然是最合适的。你的工作流里代码编辑是核心终端只是配角。如果你像我一样一半时间在远程服务器上操作一半时间在本地终端里编译调试那 Super Code 这种原生终端助手的收益会远大于 IDE 插件。因为它不需要你打开 IDE不需要你上传项目到某个云服务也没有离开 IDE 就没法用的尴尬。如果你是运维工程师日常工作主要就是 SSH 到各种服务器上改配置、看日志、执行脚本那你只需要 Super Code甚至不需要 Cursor。因为你的代码不是主程序而是命令和脚本。我自己现在的搭配是本地写需要重构的复杂功能时用 Cursor日常服务器维护、嵌入式编译、快速查命令时用 Super Code两个工具井水不犯河水。它们不冲突因为各自守住了自己的阵地。6. 实战中积累的配置技巧与避坑经验6.1 上下文模式怎么选我前面说过context_mode有三种分档这里展开讲一下怎么选。shell模式只读取当前命令和最近的输出。内存占用低私密性好适合你在服务器上处理一些与代码仓库无关的系统管理任务。在这个模式下Super Code 不会扫描你的代码仓库也就不会回答这个仓库里 xxx 函数在哪里这类问题。repo模式默认模式会扫描当前 git 仓库的文件索引和关键片段但不读取垃圾文件。回答代码问题时用的就是这种模式。它的优点是能回答仓库级问题缺点是如果你操作的是一个大仓库初始索引需要几秒钟且会占用一点 CPU。full模式会把当前工作目录下所有文件的内容包括二进制文件的文本化信息塞进上下文。理论上回答最准但基本只适合小型项目。我在一个有 3000 多个文件的 monorepo 里开过一次直接导致响应变慢。最后我还是老老实实用repo模式。我的经验是日常开发用repo远程服务器上临时处理文件用shell只有明确知道仓库很小才用full。不建议一开始就开full否则你会被它的迟钝劝退。6.2 模型选择的玄学不是越贵越好Super Code 支持多种模型后端官方配置里默认给了一个性价比不错的模型但我自己测过的几个模型有很明显的性格差异claude-sonnet-4代码逻辑最稳解释问题最通透复杂问答首选但生成速度中等。deepseek-v3速度飞快命令翻译和脚本生成都很准仓库级问答稍弱日常轻量任务很合适。qwen2.5-coder-14b本地离线可用隐私性好但只建议用来做简单的命令翻译和报错概括别指望它做深刻的重构建议。gpt-4o如果通过兼容接口接入综合能力平衡但在终端场景下没有明显优势反而因为响应偏慢让我不愿意用。我的建议是默认用deepseek-v3跑日常遇到复杂的代码逻辑问题再/model切换成claude-sonnet-4。Super Code 支持在会话中动态切换模型不需要重启。这个功能非常实用相当于你在一个工具里同时雇了两个不同性格的助手。6.3 常见坑权限确认与危险命令前面强调的确认后执行机制我实际使用中也踩过一次坑。有次我让它帮我清理一些临时文件它给出的命令是rm -rf /tmp/supercode_cache_*我瞄了一眼路径发现以/tmp开头觉得应该安全就按了确认。结果它执行的时候因为 shell 的通配符展开方式和我预想不一致把/tmp/supercode_cache_old目录里的一个正在被占用的日志文件也删了。还好只是日志但如果那是一个正在运行的进程的数据库文件后果就严重了。因此我给自己定下几条纪律也建议所有使用终端 AI 助手的朋友遵守涉及rm、mv、覆盖写入的命令一定要逐字检查尤其是通配符部分的路径。让 AI 先输出命令你复制到另外的终端窗口里执行而不是直接在 Super Code 里按确认。虽然这样麻烦一点但多一层隔离就多一层安全。不要在配置里写明文密钥不要在开放目录下存放包含个人信息的对话记录。另外Super Code 的对话历史默认存在~/.supercode/history/下如果你在共享服务器上使用记得定期清理或者把权限设为700。这些细节虽然琐碎但对一个长期使用的终端工具来说关系到你的账号安全和隐私边界值得花十分钟处理。6.4 和 tmux 搭配的高效工作流最后分享一下我现在最稳定的工作流。我打开终端后会先启动一个名为dev的 tmux 会话然后在这个会话里开三个窗口窗口一跑开发服务器或实时编译输出大量日志。窗口二普通 shell用来执行 git 操作、运行测试脚本。窗口三运行 Super Code 的 TUI 模式专门用来进行对话式问答。当窗口二的命令报错时我不用切到窗口三手动输入问题上下文因为 Super Code 已经监听到同一个 shell 环境的输出。我只需要在窗口三说出看一下刚才的报错它就知道指的是窗口二里的那一次失败。这个跨窗口的上下文关联靠的是它监听当前 tmux 会话内的 shell 输出而不是简单的剪贴板共享。实际用下来这个配合让我的排错速度提升了一大截。如果你用的是screen而不是tmuxSuper Code 也支持但官方文档里明确建议优先使用tmux因为它的 pane ID 更稳定上下文关联更可靠。这是个真实的兼容性差异建议直接用 tmux。7. 它还需要补足的短板我对 Super Code 的保留意见虽然我在前面给了不少好评但它的不成熟之处也很明显。第一是多文件编辑能力。你让它给一个跨模块的重构思路它能说得头头是道但你要它一次性生成一个涉及五个文件的 diff 补丁它就露怯了。它会逐个文件给你代码块但你得手动打开每个文件去粘贴。相比之下Cursor 的Apply按钮可以直接把改动应用到指定文件。这块体验差了不止一个身位。第二是上下文窗口的调度策略。当仓库比较大的时候它虽然不会把所有文件都加载进来但在回答某个函数在哪里被调用这类问题时它偶尔会漏掉部分文件给出的答案不够全面。这应该是索引精度的问题希望后续版本能修复。第三是TUI 的易用性。虽然 TUI 本身就是键盘党的福音但如果你是一个习惯用鼠标选中、滚动、点击的普通人Super Code 的学习成本会有点高。特别是它的长文本 Markdown 渲染在大段输出时快速跳转不是特别顺滑。我遇到过一次回答特别长的情况想从上往下找某个关键词没有类似/搜索的功能只能慢慢翻页。好在开发者的迭代速度很快我关注到的几个 Issue 都已经在路上了。比如支持多文件 patch 预览和TUI 内搜索这两个功能官方的项目看板里都已经标了 In Progress。作为用户我选择相信这个方向是对的。8. 写在最后从能用到好用的一段脚程如果你问我 Super Code 值不值得梭哈我的回答是先分清你的主场在不在终端。如果你是那种电脑前永远挂着 Cursor 或者 VSCode 的人那你可能用不到它。但如果你和我一样住在终端里每天有大量时间在服务器、嵌入式工具链、tmux 之间腾挪Super Code 很可能是今年让你生产力提升最明显的工具。我给它加进日常工具链之后最直观的感受不是省了百分之多少的时间而是我几乎不再因为记不住命令而切到浏览器搜索了。那种沉浸式地在终端里完成所有事的体验会让人上瘾。它像一个从来不嫌你烦、随时在线、并且对你的 shell 世界一清二楚的助手坐在旁边你说一句它动一下错了再改改了再试。当然工具终归是工具。它帮你写命令但最终要不要执行、代码能不能上生产责任还是在你。这也是我为什么一直强调确认后执行和人工审查生成代码这两件事。用 AI 的前提是你比 AI 更清楚自己在做什么而不是把决策权整个让渡出去。如果你也在用 Super Code或者准备尝试欢迎在评论区交流你的工作流。尤其是那些在嵌入式、运维、数据分析场景里玩出新花样的朋友我很想听听你的故事。毕竟终端的世界那么深一个人踩的路不如一群人踩得明白。
