AI-CLI 实战：让本地 LLM 帮你写 Shell 命令，但把执行权留在终端里
在终端里向模型问“把这个目录的日志按日期归档”“找出最近两小时失败的任务”，通常比记住一串 find、awk、xargs 更快。但把自然语言直接变成可执行 Shell，又恰好踩在自动化最危险的边缘：模型可能误解范围、拼错路径，甚至给出具有破坏性的命令。
AI-CLI 是一个很小的 C 工具：它把请求发送到兼容 OpenAI Chat Completions 的本地服务端点，再把模型回复放进一个可编辑的终端交互界面。它不是“替你静默执行”的代理；README 明确描述的交互是：先看见回复，按 Enter 才接受执行，按 Ctrl+C 则放弃。这个顺序决定了它更适合作为 Shell 命令草稿器，而不是无人值守的生产自动化组件。
项目以 MIT 许可证发布，GitHub 仓库的核心实现是单个 ai.c 源文件。对需要在 Linux、macOS 或类 Unix 环境中临时使用本地模型的人，这种无额外运行时依赖的形态很有吸引力；但“单文件”不等于“低风险”，下面的重点正是如何把人工审阅放进工作流。
它解决的不是模型选择，而是最后一公里
许多本地模型服务已经能提供 HTTP API，例如 llama.cpp server、vLLM、Ollama 或 LM Studio。AI-CLI 的定位是把其中一个服务接到当前终端：你输入一句自然语言，它请求固定的 /v1/chat/completions 路径，然后把答案作为候选 Shell 动作交给你确认。
这带来三个很实用的边界：
- 模型在本机或可信网络中运行。 请求地址由
AI_URL指定；工具本身不替你选择或托管模型。 - 命令不是黑盒。 返回内容会先进入编辑状态，能改参数、删掉管道，或者完全取消。
- 上下文有限且显式。 工具可根据环境、当前目录和可用系统信息帮助模型生成命令，但敏感目录、凭据文件和生产主机依然不应因为“方便”而交给模型处理。
因此，最合适的首批任务是只读查询、生成报告、解释已有命令和在临时目录里做转换。涉及 rm、权限变更、包安装、服务重启、数据库写入或网络上传时，至少要把候选命令逐段审完，再决定是否执行。
从源码构建，并指向本地服务
项目 README 给出的构建方式很直接：编译 ai.c，再运行仓库提供的安装脚本；也可以自行把二进制和 man page 放进用户目录。先克隆仓库并在隔离的测试环境中完成构建：
git clone https://github.com/vkataev/ai-cli.git cd ai-cli gcc ai.c -o ai sh run.install_ai.sh
接着设置模型服务地址。README 只要求一个 AI_URL，并说明服务需要支持 OpenAI 风格的 Chat Completions 接口。下面使用本机端口作为示例；实际端口、鉴权和模型启动参数应以你所用推理服务的文档为准：
export AI_URL="http://127.0.0.1:8001" ai "列出当前目录中最大的十个普通文件；只生成只读命令"
不要把上面的请求当作安全策略。它只是提示模型偏向只读操作，真正的保护来自随后的人工检查。模型返回命令后，先确认四件事：路径是不是预期目录、通配符是否会扩张到意外文件、是否包含重定向或管道、是否出现了网络请求或提权命令。任何一项存疑都应 Ctrl+C 取消，而不是“先跑一次看看”。
用“可撤销任务”建立信任
一个好的试运行任务应当可复核、可撤销且不会修改系统。比如让工具生成日志统计，而不是直接清理日志：
ai "统计当前目录下 .log 文件的数量和总大小，不修改任何文件"
这里不应假定模型一定会给出哪一条具体命令；不同模型、系统工具和当前目录会产生不同答案。你要审阅的是命令意图是否被正确表达：是否限定为当前目录，是否仅匹配 .log，是否没有删除、覆盖或写入操作。若结果合理，再按 Enter 执行。
当任务开始需要多轮对话时，可以使用 --memory。README 说明该选项会把此前请求和动作记录在当前目录的 AI_MEMORY.md 中：
ai --memory "继续基于刚才的日志统计，给出按日期分组的只读汇总方案"
这也意味着它不是临时缓存。项目目录如果会提交到 Git，AI_MEMORY.md 可能记录请求文本、候选动作以及被拒绝的回复；其中若包含内部路径、主机名或业务信息，就应将其加入 .gitignore，或在敏感目录中不要启用该选项。
交互审阅应当覆盖什么
把 AI-CLI 当成“自动补全加强版”会比把它当成自治 Agent 更准确。建议给团队约定一个简单的审阅清单：
| 检查项 | 为什么重要 | 建议动作 |
| — | — | — |
| 目标路径 | .、~、挂载目录和符号链接可能不是你以为的位置 | 先用 pwd、realpath 或缩小到测试目录 |
| 写入动作 | >、mv、chmod、包管理器和服务管理都会改变状态 | 拆成预览与执行两步 |
| 删除范围 | 通配符、递归选项和变量为空都可能扩大影响面 | 先改为 find ... -print 预览 |
| 网络边界 | curl、scp、git push 可能把内容送出本机 | 明确目标域名、分支和上传内容 |
| 权限边界 | sudo 与权限修改的后果难以由模型上下文判断 | 默认拒绝，改为手工逐条执行 |
这种流程看似慢，却避免了“模型生成正确语法”被误当成“命令符合当前业务意图”。尤其是模型回答含有复合管道时，先把每一段拆开理解，通常比一次性接受更省时间。
还有一个容易忽略的边界是模型端点本身。AI_URL 可以指向本机回环地址，也可能被设置为局域网或远端服务；前者只是在网络路径上更收敛，并不自动保证请求内容无敏感信息。不要把私钥、访问令牌、客户数据片段或完整生产日志写进自然语言提示。若模型服务启用了访问日志，提示词同样可能留存在服务端。对需要排障的真实数据，先做脱敏、缩小字段范围，再让工具帮助生成查询思路。
建议把确认动作设计成分级的：只读命令可在审阅后直接执行；可逆写入先针对临时副本运行；不可逆写入必须改成显式、带备份和带范围限制的人工步骤。这样做并非否定自然语言接口，而是把模型擅长的“提出命令候选”与人类擅长的“理解业务后果”分开。
何时不该使用它
AI-CLI 的 README 对风险说得很直白：它会执行模型返回的动作，作者不为由此造成的损失负责。因而以下场景不适合直接把它接入执行链：CI/CD 的无人值守步骤、拥有生产凭据的跳板机、涉及客户数据的目录、会触发付费云资源的命令，以及需要可审计批准记录的运维流程。
这些场景可以把它限制为“生成建议”，把命令复制到受控变更单或脚本评审中，而不是按 Enter。若确实要自动化，应使用固定脚本、参数白名单、最小权限账户和独立审计日志；不要把自然语言模型的输出当作权限系统。
结语
AI-CLI 的价值在于把本地模型接进熟悉的终端工作流，并保留一个关键的人类确认点。用它减少查询命令、数据筛选和一次性转换的记忆负担是合理的；让它替你在不透明环境中做写入决策则不是。先从只读、可撤销的小任务开始，把编辑、取消和上下文清理变成习惯，才能让这种极简工具真正提高效率，而不是扩大 Shell 的风险面。
相关链接