夜雨聆风
2026年5月8日，OpenAI 工程师 Jason Liu 在推特上宣布了一个新工具：openai-cli，OpenAI 官方推出的命令行工具。项目已经在 GitHub 开源，Apache 2.0 协议，Go 语言编写。
如果你平时用 Python 或 Node.js 调 OpenAI 的 API，可能觉得这东西跟自己关系不大——谁还没写过几行 SDK 代码呢？但等我装完试了一圈之后，发现它解决的其实不是"能不能调 API"的问题，而是"能不能快一点"的问题。而"快"这件事，对开发者的日常来说太重要了。
装好之后，第一个命令的体验
安装不复杂。装好 Go 1.25+，一行命令搞定：
go install github.com/openai/openai-cli@latest
export PATH="$PATH:$(go env GOPATH)/bin"
配好 API Key 之后，我敲了第一条命令：
openai responses create --input "用一句话解释量子计算" --model gpt-4o
结果直接出现在终端里。没有 import openai，没有 client.chat.completions.create，没有从 response 对象里一层层取 message.content。就是一个命令、一行输出。
这种体验的差异，比看起来大。当你只是想快速验证一个 prompt 的想法，或者临时查一个技术问题时，打开 IDE 写 SDK 代码的过程本身就是一种打断。命令行的优势在于它是即时响应的——你想到什么，敲进去，下一秒就看到结果。这种节奏感是 SDK 给不了的。
三个真正实用的功能
GitHub README 上列了完整的功能列表，这里不逐一翻译。挑三个我在试用中觉得最影响实际效率的来说。
第一个是管道输出。 命令行工具的灵魂在于能跟其他命令组合。openai-cli 支持 --format json、--format yaml 等输出格式，可以直接 pipe 给 jq 或其他工具：
openai responses create --input "列出 5 种常用的设计模式" --format json \
| jq '.output[].content[].text'
这行命令的意思是：让 GPT 生成内容，然后立刻交给 jq 提取出纯文本。AI 的输出变成了 Unix 管道中的一个环节，可以像 grep、awk 一样被编排进 Shell 脚本。这意味着我们可以在自动化流程里嵌入 AI 能力，而不需要专门写一个 Python 脚本来调 SDK 再处理结果。
第二个是文件传参。 语法跟 curl 一致，用 @ 符号引用本地文件：
openai responses create --input @code_review.txt \
--system "找出这段代码里所有潜在的 bug" --format pretty
工具会自动检测文件类型——纯文本直接传内容，图片自动做 base64 编码。不需要手动读文件、判断类型、选择编码方式。这个设计很 Unix：做一件事，把它做好，不制造额外的认知负担。
第三个是内置 Agent 工具的调用。 openai-cli 直接支持 OpenAI 的 Cloud Tools，web_search 和 code_interpreter 都能用：
openai responses create \
--input "查一下 React 19 有哪些破坏性变更，整理成表格" \
--tools web_search --format pretty
以前要做这类事情——“让 AI 自己上网查资料然后整理”——通常需要搭一个 LangChain 或者类似框架的项目，写 Agent 调度逻辑。现在一行命令就够了。对于快速调研、原型验证这种场景，效率提升非常明显。
跟 curl 实际对比
openai-cli 最直接的竞品其实是 curl——大多数开发者都有过手写 curl 调 API 的经历。我们把两种方式放在一起看一下。
用 curl 调一次 GPT：
curl https://api.openai.com/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{"model":"gpt-4o","input":"用一句话解释量子计算"}'
用 openai-cli 做同样的事：
openai responses create --input "用一句话解释量子计算" --model gpt-4o
curl 的问题不是它不能用，而是每一次都要手动处理三件事：记住 API 端点的完整 URL、记住 header 里需要哪些字段、记住 JSON body 里的字段名到底是 input 还是 prompt 还是 messages。任何一个写错就是 400。openai-cli 把这些都封装好了，同时保持了命令行的简洁性。
但 openai-cli 也有它的边界。如果你的场景里有多轮对话的状态管理、自定义重试策略、流式响应的逐 token 处理这类复杂需求，那还是用 SDK 更合适。CLI 工具的优势是"快"，不是"灵活"。它不是来替代 SDK 的，是来替代"为了一件小事写一个脚本"这种场景的。
适合放在哪几个场景里用
梳理下来，openai-cli 最适合这么几种场景：
Shell 脚本自动化。 比如每天定时生成日志摘要：
#!/bin/bash
report=$(openai responses create \
--input "总结今天的错误日志: $(cat /var/log/error.log)" \
--format raw)
echo"$report" | mail -s "每日日志报告" team@company.com
CI/CD 流程集成。 在 GitHub Actions 里做代码审查：
git diff > changes.txt
openai responses create --input @changes.txt \
--system "你是一个代码审查专家，指出潜在问题并给出修改建议" \
--format json > review.json
Prompt 快速测试。 不需要写脚本，直接批量试：
for prompt in prompt_a.txt prompt_b.txt prompt_c.txt; do
echo"=== Testing $prompt ==="
openai responses create --input @$prompt --model gpt-4o
done
这些场景的共同特点是：调一次 API，拿一个结果，不需要复杂的状态管理。这恰好是 CLI 工具最擅长的。
装两个别名，日常效率更高
我在 .bashrc 里加了两个 alias：
alias ai='openai responses create --model gpt-4o --format raw --input'
alias aiimg='openai images generate --size 1024x1024 --prompt'
之后在终端里可以直接用：
ai "这段代码有什么问题" @main.go
aiimg "一只在太空站里喝咖啡的猫"
这种随时能调 AI 的感觉，跟打开网页版 ChatGPT 是不同的体验。网页版是"去一个地方用 AI"，命令行是"AI 就在当前环境里，想到了就直接用"。对于每天大半时间都在终端里的人来说，这个切换成本的变化，带来的效率提升是不小的。
总结
openai-cli 不是那种"颠覆行业"的产品。它就是一个做了一件小事但做得干净的工具：让你在终端里用一行命令调 OpenAI API。它不会取代 SDK，不会取代 ChatGPT 网页版，但在"我只想快速问一下"的瞬间，它比打开任何东西都快。
项目是 Apache 2.0 协议开源，Jason Liu 自己把它叫 “small ship / passion project”——一个工程师利用业余时间做的、因为自己需要所以顺手分享出来的工具。这种气质其实比任何产品发布会都更像开发者社区该有的样子。
参考资料
OpenAI CLI 官方 GitHub 仓库
Jason Liu 发布推文（2026-05-08）
