企业官网建设流程全解析

1. 为什么我会做 OpenShell：终端里那些“小事”最费神

每天在终端里敲命令，最烦的其实不是命令本身，而是那些“记得住大方向、记不住细节”的瞬间。OpenShell 就是我在这个背景下折腾出来的一个开源命令行 AI 助手，目标很简单：你在终端里用自然语言描述想做的事，它帮你翻译成命令、展示出来、确认后执行。

一开始我没打算写这个项目，只是想省点事。以前查端口占用，我得先lsof -i加管道grep，拿到 PID 再kill，中间还要处理 grep 自己匹配自己的问题；想批量改文件名，rename的正则在不同系统上语法还不一样；看日志统计接口访问量，awk '{print $7}' | sort | uniq -c | sort -nr这种一长串管道，每次都要重新拼一遍。后来换了思路——与其背命令，不如让大模型帮我拼。但直接问 ChatGPT 再复制粘贴回终端，来回切换窗口很割裂，而且它给的命令常常跟我的系统环境对不上。我要的是一个能直接待在终端里、能看到我当前目录和系统环境、能自己执行命令并把结果反馈回来的助手，这就是 OpenShell 的起点。

这个项目适合谁？我觉得是这三类人：一是刚转行做开发或运维，命令还没形成肌肉记忆的新人；二是要处理大量重复性终端操作的工程师，比如天天跟日志、部署、文件批处理打交道；三是喜欢折腾工具链的玩家，愿意把 AI 能力嵌进自己的工作流里。它不是一个交互式聊天网站，也不是那种只给建议不动手的小插件，它更接近一个“住进终端的外骨骼”——帮你把手部力量和精细操作放大，但方向盘始终在你手里。

OpenShell 目前是 MIT 协议，代码完全开源，本地模型和云端 API 都能接。它没有做得很花哨，但核心链路是完整的：自然语言输入、模型生成命令计划、展示候选命令、用户确认后执行、执行结果回流给模型继续分析。下面我会把这个链路一层层拆开讲，包括当时为什么要这样设计，以及实操中踩过的坑。

2. OpenShell 的工作原理：一条从自然语言到系统调用的完整链路

2.1 核心设计思路：模型先“想”，再“做”，最后“看结果”

早期我见过不少所谓的 AI 终端工具，路子很野：把用户说的话直接拼进bash -c，模型说什么就执行什么。这看起来很酷，但本质上是个自杀式设计——大模型不是操作系统，它不知道在你机器上哪些命令是安全的，也不知道rm -rf后面跟什么路径会出事。OpenShell 从第一版开始就定了一个铁律：模型不直接执行命令，它只负责生成命令和参数，真正的执行永远走独立进程，而且执行前必须经过用户确认。

所以整个执行链路分四步：

1. 意图识别：用户输入自然语言后，OpenShell 把这句话连同当前会话上下文一起发给 LLM，让它判断用户到底想要什么操作。
2. 命令生成：模型以结构化的形式返回一个“命令计划”，包含若干条候选命令、每条命令的工作目录、执行的优先级。
3. 展示确认：OpenShell 在终端里渲染这些命令，明确标出危险等级，等待用户按回车确认，或者输入n拒绝。
4. 执行回流：确认后 OpenShell 通过子进程执行命令，把 stdout、stderr、退出码全部捕获，再塞回给模型，让它基于真实输出判断下一步。

第二步里有一个关键细节：命令计划不是自由文本，而是强制 JSON 结构。比如用户说“帮我看看哪个进程占了 8080 端口”，模型返回的是：

{ "commands": [ { "cmd": "lsof -i :8080", "workdir": "/home/openshell", "description": "列出占用8080端口的进程", "risk": "low" } ] }

强制 JSON 格式的好处有三个：一是模型不容易跑偏，不会突然说一段废话；二是 OpenShell 可以对cmd字段做安全校验，比如危险命令拦截、白名单匹配，都是在结构化的字段上操作的，而不是对整段文本做模糊匹配；三是后续想接更多工具（比如操作 Git、调用 Docker）时，扩展协议很自然。

2.2 上下文注入：让模型“看得见”你的环境

这是 OpenShell 和普通 AI 聊天工具最大的区别之一。你在终端里问一个 AI 界面“帮我删掉当前目录下所有 .log 文件”，它给你的答案大概率是rm *.log；但你真正想删的可能只是那 100 个日志文件，而且你当前目录下根本没有.log文件，全是.txt。OpenShell 每次请求模型时，会携带一组系统上下文快照，包括：

• 当前操作系统类型、Shell 名称与版本（比如linux-gnu / bash 5.1）
• 当前工作目录路径和该目录下文件的简要列表（文件名按数量截断，顶层最多 50 个条目）
• 当前用户权限（uid、gid、是否是 root）
• 最近 5 条终端历史命令
• 环境变量里和路径、编辑器相关的关键值（PATH、HOME、EDITOR）

这些信息会拼进 system prompt，用特定的标记分隔开，让模型明确知道“这是环境快照，不是用户指令”。第一次用的时候你可能感受不到这个设计的分量，但用久了你会发现：模型给出的命令几乎很少出现“目录不存在”“文件找不到”这种低级错误，因为它真的知道你现在在哪个目录、能看到哪些文件。

不过上下文注入不是越多越好。最开始我试着把完整的历史记录全塞进去，结果模型被一堆旧命令带偏，而且 token 消耗暴涨。后来限定为最近 5 条历史命令和 50 个文件条目，效果最稳。

2.3 多轮执行：命令输出作为“下一轮的输入”

单条命令生成没什么稀罕的，OpenShell 真正麻烦的是多轮操作。比如用户说“把当前目录所有 .png 文件转成 .jpg，然后统计下转换后的文件总大小”，这需要两条命令：先convert或ffmpeg批量转换，再du -sh统计。OpenShell 的处理方式是：模型在 json 里返回两条有序命令，按顺序执行，但第二条命令的执行依赖第一条的输出结果来判断是否成功。

这里有一个很有意思的分支——按依赖类型区分“顺序执行”和“链式执行”：

• 顺序执行：两条命令互不依赖，按顺序跑即可，失败则中断。
• 链式执行：第二条命令需要用到第一条命令的输出内容，这时候 OpenShell 会把第一条的 stdout 作为补充上下文，再次请求模型生成第二条命令。

比如用户要求“找出最大的那个日志文件并显示它的最后 20 行”，模型第一步生成ls -S *.log | head -1，这时候 OpenShell 拿到输出，比如是access.log，并不会直接去拼tail -20 access.log，而是把ls -S *.log | head -1的输出返回给模型，让它根据真实的文件名生成第二条命令。这个过程在体验上就是：用户看到两条命令，第一条看起来只是“列文件”，第二条才是真正的tail，但两条命令之间的衔接完全由模型根据真实结果决定。

为什么要这么绕？因为文件系统状态是不确定的，你永远不知道模型猜出来的文件名是不是真的存在。与其让模型硬猜，不如让系统先探路，模型再决策，每一步都基于事实而不是想象。

3. 部署与配置：五分钟让 OpenShell 跑起来

3.1 依赖环境：比你想象的轻

OpenShell 的运行时依赖不多，核心是 Python 3.9+，然后根据你要接的模型，二选一：

我个人最推荐的方式是本地 Ollama + 中等偏小参数的模型（比如 Qwen2.5-14B 或 Llama-3.1-8B），因为命令生成任务对模型的“创造力”要求不高，但对格式遵循能力和对工具调用的理解要求比较高。14B 左右的量化模型已经能给出很稳的 JSON 输出，而且不涉及把自己的终端操作上下文发给第三方服务。想追求更聪明的意图理解和复杂多步规划，再切云端 API。

3.2 安装和初始化：一条命令，一个交互式向导

安装很简单，喜欢干净环境的用 pipx，无所谓的直接 pip：

pipx install openshell-cli

装完后跑一次openshell init，它会生成一个.openshell/config.yaml配置文件在用户目录下，然后问你几个问题：默认走本地模型还是云端 API、模型名称、危险命令要不要每次都确认、历史命令保留多少条。这套交互式初始化当时设计的原因是：装工具的人大都不会去看文档里的环境变量表，与其让他们手填，不如直接问。

生成的配置长这样：

provider: ollama # 可选: ollama / openai_compatible / anthropic model: qwen2.5:14b # 模型名称 base_url: http://localhost:11434/v1 # OpenAI 兼容服务的地址 temperature: 0.2 # 命令生成任务用低温，避免离谱命令 top_p: 0.9 max_tokens: 2048 # 限制模型输出长度 risk_policy: always_confirm # 可选: always_confirm / whitelist / auto history_limit: 5 # 注入上下文的历史命令条数 file_preview_limit: 50 # 注入上下文的文件条目数 sandbox: disabled # 沙箱模式，可选: disabled / docker / bubblewrap

里面有个参数值得解释：temperature: 0.2。写代码、写诗需要高温采样，让模型有创造力；但生成 shell 命令恰恰相反，你需要的是稳定、可预测、严格按格式输出。温度一高，模型就会开始“创新”，比如在关键路径上给你加个别名，或者在rm命令里自作聪明加个-f。低温不是万能的，但实测下来 0.1 到 0.3 之间是命令生成任务的甜蜜区。

3.3 三种运行模式：单人交互、单条执行、脚本集成

OpenShell 不只支持交互式对话，设计时考虑过不同场景，所以留了三种调用方式。

交互模式是你敲openshell后进入 REPL，可以连续对话，模型记得上下文：

$ openshell ▶ 列出当前目录下所有超过 100MB 的文件 $ find . -type f -size +100M -exec ls -lh {} \; 确认执行? [Y/n] Y ...输出... ▶ 把这些文件都移动到 /tmp/bigfiles 下 $ mkdir -p /tmp/bigfiles && find . -type f -size +100M -exec mv {} /tmp/bigfiles/ \;

单条执行模式适合那种“我就快速查一个命令”的场景，比如你正在写别的东西，不想切换进完整会话：

openshell -c "怎么查看当前服务器监听了哪些端口"

这个模式下 OpenShell 只输出命令，不自动执行，相当于一个“翻译器”。它的价值在于安全：你拿到命令后可以自己审一遍再跑，心理负担小很多，适合刚开始接触这类工具的人。

最后是非交互模式，给脚本用的：openshell --exec "清理系统中 3 天前的临时文件" --yes。这个模式下它会自动执行所有生成的命令，跳过确认步骤。你可能会问：这不就违背了“确认后执行”的铁律吗？确实是，所以--yes只推荐在两类场景用：一是 Docker 容器里跑一次性任务，容器本身是随时可以丢掉的；二是接了sandbox: docker后，命令实际跑在隔离容器里，宿主机不受影响。

4. 安全护栏：OpenShell 最重要的设计，也是最容易被喷的设计

4.1 双重确认：为什么“确认”要做两遍

第一次体验 OpenShell 的人，最常见的反馈是：“怎么这么啰嗦？我说个查命令你还要我按两次确认？”

第一次确认发生在命令展示阶段，终端上会渲染出完整命令、工作目录和风险等级，问你“确认执行? [Y/n]”。第二次确认发生在执行前 0.5 秒，如果检测到高危操作（比如rm -rf、mkfs、chmod -R 777），OpenShell 会在命令前面加一个独立的阻塞式提示：

⚠ 危险操作：该命令不可逆，涉及路径 /home/user/project，请输入项目名确认继续：

为什么需要第二层？因为第一层确认很容易变成“肌肉反应”——用户天天按Y，已经形成条件反射了，看到命令差不多就回车。这时候如果模型有一天生成了rm -rf /var/lib/docker，而你又没看清路径，灾难就发生了。第二层确认故意逼迫你输入几个字符（比如项目目录名），强制打断你的自动反应，给你一个重新审视的机会。

这套双重确认机制上线后，被一部分人骂“烦”，但另外一部分人（尤其是运维出身的朋友）反而觉得这是它比很多同类工具强的地方。我的态度没变过：在终端里，用户犯错的成本远高于多敲两下键盘的成本。你要嫌烦，可以去配置里把risk_policy改成whitelist，但默认永远是 confirm。

4.2 白名单机制：聪明的做法是给安全命令开绿灯

OpenShell 内置了一份默认命令分类表，把所有常见命令分成三类：

• 安全命令（白名单）：ls、pwd、cat、grep、find、diff、df、du、head、tail、env、which、curl -I（只请求头）等。这些命令在默认配置下不需要二次确认，直接进入执行倒计时。
• 常规命令：cp、mv、git、pip install、docker ps、systemctl restart xxx等。这类命令有风险但可逆，第一层确认后直接执行。
• 危险命令：rm、mkfs、dd、shutdown、reboot、> file（重定向覆盖）、chmod -R 777、任何以sudo开头且后续为危险命令的组合。这类命令必须走第二层确认。

分类规则放在配置里，用户可以自己改：

whitelist_commands: - "ls" - "pwd" risk_commands: - "rm" - "dd" - "mkfs*"

白名单的匹配不是简单字符串包含，而是先做 shell 命令解析，提取命令名和参数，再做规则匹配。这个细节很重要：你设了rm为危险命令，但如果用户输入的是rm -i（每次删除都询问的交互式删除），OpenShell 能判断出它带了-i参数，危险等级会降低；反过来，如果用户输入的是alias rm='rm -rf'然后执行rm somewhere，解析器会识别出这是走了扩展后的alias定义，按真实展开结果来分级，而不是只看表面的rm。

4.3 沙箱模式：把命令关进箱子里跑

白名单和确认机制能做到“拦住危险”，但拦不住“用户自己都没意识到有风险”的操作。比如模型生成了一条find . -exec chmod 644 {} \;，它把项目里所有文件的权限都改成了 644，包括原本是 600 的密钥文件。这种操作其实算不上“危险命令”，对单个文件改权限也没问题，但作用在find的递归结果上，就不是你想要的结果了。这就是为什么 OpenShell 额外提供了沙箱模式。

目前沙箱有两种实现方式：

• Docker 沙箱：把生成的命令放进一个临时的 Docker 容器里执行，容器挂载当前工作目录为只读，需要写入时再单独指定挂载路径。好处是隔离彻底，坏处是 Docker 本身有性能开销，每次执行都要起一个容器，慢了不是一点半点。
• bubblewrap 沙箱：Linux 下的轻量级用户命名空间隔离方案，没有 Docker 那么重，但它依赖内核支持user namespaces，不是所有环境都开着的。

我用 Docker 沙箱跑过一段时间，命令执行速度明显下降，VC 上叠甲，每次ls都要等一两秒。但它的安全意义在于：即便模型疯了、用户也手滑确认了，宿主机也不会坏，最坏情况就是容器被打烂。如果你是用 OpenShell 帮自己批量处理不熟悉的文件，或者跑定时任务没人守着的夜间脚本，强烈建议开启沙箱。注意可视化性能损失，我建议非特殊场景还是用默认的确认机制，沙箱作为第二道保险备着就行。

4.4 一个被 OpenShell 拦下来的真实案例

有一次我在调配置脚本，输入了“清理一下那个临时测试目录，把里面的东西都删了”，模型在低温参数的约束下生成了：

rm -rf /tmp/openshell_test_temp

看起来没问题，路径也确实是名字很明显的临时目录。但 OpenShell 的路径保护规则发现这个目录的实际路径被解析为了/var/tmp/openshell_test_temp——因为/tmp和/var/tmp在部分 Linux 系统上是符号链接关系。而/var/tmp不在默认受保护路径白名单里，这个操作直接触发了一级警报，要求额外输入确认短语。

我当时的心理活动是：“这也太小题大做了。”但仔细想想，这个拦截完全正确。你永远不知道模型什么时候会把一个看起来无害的路径拼到一个有危害的位置上。后来我把PATH_PROTECTED_DIRS加上了/var/tmp，配置支持按正则匹配：

protected_paths: - "/var/tmp" - "/etc" - "/usr" - "/bin"

这套规则不复杂，但实用性很高。我建议每一个重度使用 OpenShell 的人，都花 5 分钟把这个列表按自己机器的情况过一遍。

5. 实际任务演练：从命令查询到组合操作

5.1 案例一：找到占用 8080 端口的进程并处理

这是终端里最高频的问题之一。传统做法是先lsof -i :8080看输出，记住 PID，再kill -9 PID，如果权限不足还要加sudo。用 OpenShell 直接说：

▶ 8080 端口被哪个进程占了？ $ lsof -i :8080 确认执行? [Y/n] Y COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME node 12345 me 22u IPv6 12345 0t0 TCP *:8080 (LISTEN) ▶ 帮我把它杀掉 $ kill 12345

注意第二轮的kill 12345，模型没有自作主张加-9。为这个细节我调过很多次 prompt：默认让它先用TERM信号（即kill 不加参数），如果用户表示“杀不掉”再升级到KILL。原因很简单：kill -9是最后的兜底手段，直接走到这一步会跳过进程的清理逻辑（比如释放文件锁、删除 socket 文件），容易留一堆脏数据。

这里想额外说一句：模型如果通过lsof输出看到了node, 通常它会先手动kill，但很多初版工具会把两个步骤合成一条命令lsof -t -i :8080 | xargs kill -9。这种写法看起来高效，但隐藏的问题是：lsof输出为空（端口根本没被占）时，xargs kill -9会因为没有输入而报错。OpenShell 的链式执行机制天然避免了这个问题——第二步的命令建立在第一步真实输出的基础上，而不是纯靠模型猜。

5.2 案例二：批量重命名文件

假设你的下载目录里有一堆没有规律的抓图文件：

photo1.png photo2.png photo3.png

想让它们按拍摄日期组织，比如20240312_photo1.png。这个需求用rename实现很繁琐，而且不同发行版的rename（Perl 版 vs util-linux 版）语法不一样。OpenShell 的做法是先用系统命令看一下真实情况：

▶ 把当前目录下所有 png 文件按 年月日_原文件名 的方式重命名，日期用今天的 $ ls *.png photo1.png photo2.png photo3.png $ for f in *.png; do mv "$f" "$(date +%Y%m%d)_$f"; done

模型这里選擇了for循环而不是调用rename，因为环境上下文告诉它当前系统是 Ubuntu 24.04，util-linux 版的rename是不支持 Perl 正则替换的。这个选择如果能单独提示，你还能看到它给出的理由：“当前系统使用 util-linux rename，语法与 Perl 版不同，使用 Shell 循环更通用。”

这个例子看起来简单，但背后体现的是：模型读到了上下文快照里的系统类型，从而避开了跨平台差异的大坑。如果你直接拿着同样的问题去 ChatGPT 网页版问，它大概率给你rename 's/^/20240312_/' *.png，你复制到自己的 Linux 机器上就报错。

5.3 案例三：日志分析里最常用的统计套路

再来一个稍微复杂一点的。线上 Nginx 日志access.log格式是常见的 combined 格式，想知道今天访问量最高的前 10 个 IP。

▶ 分析 access.log，按访问次数统计前 10 个 IP $ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10 确认执行? [Y/n] Y

这条管道命令很长，但执行起来就是一瞬间的事。后处理阶段 OpenShell 会给结果加一个解读层：取到排名后，你可以继续问“这个列表里哪个 IP 的请求量超过了 1000 次，单独列出来”，模型会再生成一条awk管道，把阈值过滤的逻辑写进去。

在日志场景下我发现一个很实用的小技巧：用 OpenShell 拼接管道命令，不如用 OpenShell 生成 SQL。如果你本地装的是 SQLite，日志已经导成结构化表，那么把awk全链换成SELECT ip, COUNT(*) FROM access_log GROUP BY ip ORDER BY 2 DESC LIMIT 10，可读性高一个层级。OpenShell 支持在对话里指定“用 sqlite 完成这次分析”，它会自动切换策略。坦白说管道命令对不熟awk的人是负担，但对熟的人来说是肌肉记忆，所以这个切换的设计完全看你自己的习惯，没有绝对的对错。

6. 我踩过的坑和调优经验

6.1 上下文爆炸：多轮对话后模型“失忆”和变笨

用着用着你会发现，OpenShell 在多轮复杂操作后开始犯低级错误：明明前面已经确定了文件路径，后面却生成了对不上号的命令。原因很简单——上下文窗口被历史命令输出塞满了。OpenShell 每一轮都会把上一条命令的 stdout 塞回给模型，几十条命令之后，这些输出占了大量的 token，模型的注意力被稀释，反而忽略了用户最新的指令。

我调过几轮之后，最终用的是“滑动窗口 + 摘要压缩”的组合：

• 只保留最近 3 轮的完整命令和输出；
• 更早的对话不直接丢弃，而是每隔 5 轮生成一段摘要文本（比如“用户已完成对日志文件的清理，当前目录为 /var/log/nginx”）注入到上下文中；
• 用户可以随时输入/clear清空对话历史，但保留环境快照信息。

这个策略上线之后，多轮操作的准确率提升非常明显。如果你用 OpenShell 也遇到了模型“越来越傻”的情况，先检查是不是上下文太长了，而不是急着换更大的模型。

6.2 中文路径与编码问题：一个最容易摔的跟头

我平时的工作环境里有一半机器是双系统或 Windows 下用 WSL，目录名经常是中文。有一次我让 OpenShell 把 “下载文件夹” 里的文件都压缩打包，它生成：

zip -r archive.zip /home/me/下载

看起来没毛病，但执行时直接报了编码错误，因为zip默认使用的系统编码（POSIX 环境下通常是 UTF-8）和 Windows 下的 GBK 不是一回事。而这个报错还不是发生在命令生成阶段，是发生在命令执行阶段，所以模型下一次轮询时才会看到错误信息。

后来我在 OpenShell 的配置里加了一个“execution encoding”的全局设置项，默认优先探测locale，如果检测到 GBK 相关的环境变量，会强制在命令前加export LC_ALL=en_US.UTF-8或者给涉及文件名的命令加参数（比如zip的--unicode）。效果立竿见影，但这类问题最烦人的是它因发行版而异，没有一个放之四海而皆准的解法，只能靠采集真实环境信息来动态适配。

6.3 Windows PowerShell 与 Linux Bash 的命令语义差异

OpenShell 之前主要面向 POSIX 环境，后来有用户在 Windows 终端上用，反馈了一堆奇怪的问题：ls能跑，但ls -lh的输出格式不对；grep不存在；路径分隔符是反斜杠。这些问题在领先工具那儿也常见，根源是 Windows 上命令行的兼容层设计思路完全不同于 Unix。

我的处理方案是给 OpenShell 加了一个“shell 类型探测”：

• 检测到powershell.exe时，模型生成的命令会优先用 PowerShell 原生 cmdlet（Get-Process、Select-String），而不是硬套 Bash 命令。
• 检测到 Windows 下的 Git Bash 时，则按 Linux 命令习惯生成，但路径转换交给cygpath处理。

然后 prompt 里会有一条明确的约束：“当前环境为 PowerShell，所有命令须符合 PowerShell 语法，不要使用参考 Linux 手册生成的命令。”加了这个约束后，PowerShell 下的错误率低了非常多。模型不是不会 PowerShell，而是你没有告诉它当前环境，它默认按最熟悉的方式回答，这不怪模型，怪我们上下文中没说清楚。

6.4 模型选择对比：本地小模型 vs 云端大模型

OpenShell 初期，我在不同模型之间横跳了很久，最后形成了一个经验表格：

实测下来，本地 14B 模型对于 80% 的终端场景已经足够，复杂推理（比如“同时满足 A、B、C 三个条件，还要注意 D 目录不能动”）就得上云端大模型。而延迟的影响比大多数人想象的大：命令行交互的节奏很快，延迟超过 2 秒就会让人想关掉它。

6.5 输出过长的处理：一屏装不下怎么办

有一个很常见但在设计初期没考虑到的场景：命令输出一长串，比如find / -name "*.conf" 2>/dev/null的结果动辄几百上千行。如果整段输出塞给模型，token 被刷爆，而且终端用户一下子看到 500 行文件列表也会不耐烦。

我给 OpenShell 加了一个输出截断规则：stdout 超过 300 行或 8KB 时，只保留前 50 行和后 20 行，中间加一行提示“输出省略 X 行”。这样既保住了模型决策需要的关键信息（错误通常发生在开头或结尾），又不会吞掉整个上下文窗口。如果你要完整的输出，交互命令!cat可以直接把结果导入分页器，完全不经过模型。

7. 把 OpenShell 变成自己的：技能函数与自定义工作流

7.1 技能函数：把常用套路固化下来

用了几个月后你会发现，自己反复让 OpenShell 做的事其实就那么几十件：查端口、看磁盘、清理临时文件、启动服务、看日志、部署前后端……与其每次都用自然语言描述，不如把它们固化成“技能函数”。OpenShell 的技能函数机制很简单：在~/.openshell/skills/下放一个 YAML 文件，声明技能的触发词和命令模板。

比如我写了一个部署检查技能，平时只需要说“deploy check”就能触发：

name: deploy_check description: 检查部署环境是否健康 trigger: ["deploy check", "部署检查", "发布前检查"] commands: - cmd: "df -h" description: "检查磁盘空间" - cmd: "free -m" description: "检查内存" - cmd: "systemctl status nginx --no-pager" description: "检查 Nginx 服务状态" - cmd: "tail -20 /var/log/nginx/error.log" description: "查看最近错误日志" run_mode: sequence

这里有一个设计细节：技能里的命令不是死的，支持的变量可以动态替换。比如你定义了一个技能“查看特定服务日志”，把服务名留成参数，OpenShell 会把用户说的“看看 MySQL 日志”自动匹配到这个技能，并把{{service}}替换成mysql。这样你就不用每次都重新描述一遍“我要看什么服务的日志、日志路径在哪、最近多少行”。

7.2 自定义开放指令：让可信命令免确认

在配置里，你可以把常用的自写脚本加入免确认白名单。比如我自己写了一个genpass脚本（生成随机密码），跑了几百次没出过问题，于是在配置里加了一条：

skip_confirm: - "genpass*"

这样以后 OpenShell 生成genpass -l 24时就直接执行了，不再弹出确认框。但从安全角度，我强烈建议：你自己写的脚本可以加，官方工具不要加。你能力范围之外的命令（比如docker全家桶）很容易因为版本差异、参数误用产生意外，多按一次回车不丢人。

7.3 当前功能边界和下一步扩展方向

OpenShell 目前还不能做的事情，我觉得值得说清楚，避免你把期待拉满：

• 它不能做 GUI 自动化，终端外的事情（比如用鼠标操作某个软件界面）它管不了。
• 它对桌面型命令的覆盖有限，ssh到远程服务器后，它生成的命令是在本地跑还是在远程跑，目前只靠 ssh 命令本身来传，不会自动维护远程会话状态。
• 它不擅长解释“为什么命令是这样写的”，虽然你问它它会说，但它的核心价值是执行效率，不是教学。真要学命令，还是去看文档更系统。

下一步我计划做的方向有三个：一是支持更多工具接入，比如让模型直接操作 Docker API，而不是生成 Docker CLI 命令；二是增加“工作流编排”，把多个技能串成一个流水线，类似 CI 的那套理念，但跑在终端里；三是做更好的远程服务器会话管理，让 OpenShell 能维护 SSH 多台机器的会话状态，操作哪台机器由用户指定，而不是靠模型猜。

8. 从一个功能到一类工具：OpenShell 在终端生态里的位置

做 OpenShell 这几个月，我最大的收获不是写了多少行代码，而是想明白了一个问题：终端里最缺的不是“能听懂自然语言的命令翻译器”，而是“能在既有工具链之上叠加智能决策的协处理器”。

传统的 shell 是确定性的：你输入什么它就执行什么，好处是可预测，坏处是任何复杂操作都要靠人脑拼装命令。大模型补上的恰恰是“从意图到命令”的这层拼装能力。而把 LLM 接进终端，不只是换了个交互方式，它其实改变了终端工具的信任模型——以前你信任命令，现在你既要信任命令，又要信任生成命令的模型。

所以 OpenShell 的定位始终不是一个“自动执行器”，而是一个“建议+执行+验证”的决策回路。它建议命令，你来决定；它执行命令，然后把自己的输出带回来给你看；它验证结果，如果有异常还会主动问你要不要回滚。这跟自动驾驶的层级划分有点像：我们不追求 L5 全自动，我们做的是 L2+ 的辅助驾驶，方向盘在用户手里，油门刹车在系统脚下，但系统随时准备接管一部分繁琐的操作。

如果你也想在终端里获得这种体验，我的建议很直接：先从单条执行模式（openshell -c）开始用，让 OpenShell 只当翻译官，不当执行者；习惯了它的命令风格之后，再切换成交互模式，让它真的帮你跑命令。这个上手路径比一上来就全面接管要稳得多，也能少几个“rm -rf”级别的惊吓。

最后说一句掏心窝的话：工具做得再顺手，也比不上你自己对操作系统本身的理解。OpenShell 能帮你把“怎么实现”的细节省掉，但“实现什么、为什么要实现、实现之后如何验证”这些问题，还是得靠你自己的判断力。我在实际使用中逐渐发现，OpenShell 最打动我的场景恰恰不是“省了多少次键盘敲击”，而是它让我把原本花在拼命令上的时间，挪给了真正需要思考的事情上。这才是这套东西对我而言最大的价值。