OpenAI CLI

原文 ↗ Hacker News 讨论 ↗

OpenAI 发布了面向其 REST API 的官方命令行接口（CLI），引发了与简单的 curl 封装以及现有 Codex agent 工具的比较。评论者讨论这种 CLI 是否真的能通过 token 跟踪、JSON/JSONL 输出和更容易的脚本化来改善开发体验，还是说在 LLM 能快速生成类似工具的世界里显得多余。此次发布也重新引发了对“vibecoded”式 AI 驱动软件的更广泛担忧：快速、低审查的开发、频繁弃用，以及 AI 辅助编码对代码质量、可维护性和关键工具信任度的影响。

OpenAI CLI 是什么（对比 Codex / curl）

  • 很多人把它看作是 OpenAI REST API 的一个薄层官方封装：“更好用的 curl”，带有 token 统计、OAuth、结构化输出，以及可通过 -h 发现的帮助信息。
  • Codex 被描述为一种“agent harness”/交互式工具，而 CLI 则用于更底层、可脚本化的访问，以及账户/工作区管理。
  • 由于功能面有重叠（例如生成图片），而且已经有一个类似 CLI 的 Codex 应用，因此仍然存在一些困惑。

被认为的用例与价值

  • 建议用途包括：脚本化调用模型、导出 API 数据（models list、files list）、快速生成图片，以及将 OpenAI 功能集成到其他工具/agent 中。
  • 有人认为它是多余的，因为任何称职的用户都可以很快自己写一个封装，或者直接使用 curl。也有人指出，便利性和标准化很重要，类似 GitHub 的 gh。

关于文档、命名和产品策略的批评

  • 一些评论者批评 README 没有清楚说明“它解决了什么问题，以及是给谁用的”。
  • 对产品命名的困惑（Chat vs Work、Codex vs CLI）被视为“vibecoded”式产品管理以及工具之间部分重复的体现。

软件质量、“vibecoding” 与 AI 生成代码

  • 讨论中有一条很强的主线是“vibecoding”：快速生成 AI 代码，轻度审查，导致 bug、不连贯的 UX，以及工具重叠。
  • 有人声称现在大多数新软件都是“vibe coded”，因为这样更快而且“够用”；也有人反驳，强调工程纪律、代码审查和对代码的人类理解。
  • OpenAI 最近的应用（例如 Mac 版 ChatGPT 客户端、Codex app）被举例为有 bug 或半成品，从而加剧了不信任。

稳定性、弃用与锁定

  • 多条评论警告 OpenAI 经常在大约 2 年内弃用工具，而且有时沟通不佳。
  • 有人认为这在一个快速变化、尚不成熟的领域里很正常；也有人认为，对于开发者依赖的工具来说，这是不可接受的。
  • 还有一种担忧是，目前仍然没有用于整理 ChatGPT 聊天记录的 API，这被视为一种新的锁定形式。

计费与配额问题

  • 大家不确定 CLI 使用的是固定订阅配额，还是按 token 的 API 计费。
  • 还提到了 Anthropic 的 CLI（claude -p），其“额外用量”在何时以及如何计费的方式令人困惑，并有报告称其行为并不一致。

替代方案与 DIY 工具

  • 有人提到至少一个社区工具（例如 llcat）被强调为更符合 Unix 风格、无状态、可组合的多 LLM 提供商替代 CLI。
  • 也有人指出，由于 LLM 可以很快生成这类 CLI，官方 CLI 的经济护城河可能很薄，不过官方支持仍然有价值。