洗心岛1. 被“写博客”这件事折磨过的前端，都懂这几个痛点
我搭这套“AI CLI 自动写文章发布到 CSDN”的流水线，起因特别朴素：不想每个周末都花四五个小时憋一篇技术博客。作为一名干了多年的前端开发者，我太清楚那种感觉了——周一到周五在业务代码里救火，周六日还要打开编辑器，从“这篇文章到底写什么”开始消耗意志力。写技术文章对成长有帮助，这是共识，但它的时间成本确实摆在眼前。尤其是在整个行业都在聊 AI、AI Agent、AI 编程工具的节点上，如果还能自己动手做一个和 AI 相关的工具，本身就是对个人技术视野和工程能力的一次检验。
身边不少前端朋友问过我：你想写文章，直接用网页版 AI 不就行了吗？为什么要搞什么 CLI？这个问题的答案，恰恰是这个项目的起点。网页版适合“一次性聊天”，但我需要的是“可重复、可编程、可批量”的内容生成能力。比如我每个月固定输出四篇文章，每一篇都有固定的排版规范、代码块风格、标题层级要求，如果每次都在网页里复制粘贴，格式很容易乱，而且没法沉淀成一条流水线。CLI 工具天然适合藏在自动化流程里：它可以被 Node.js 脚本调用，可以接 Git，可以配定时任务，甚至可以被我自己写的发布脚本接管，这才叫“自动发布”。
所以当时我给自己定的项目目标很明确：输入一个主题关键词，脚本自动生成一篇结构完整的 Markdown 技术文章，代码块、标题层级、段落格式都提前整理好，我人工快速改一遍，然后发布到 CSDN。听起来挺美好，真正做起来之后，踩坑的地方一点都不少。下面我把整个实践过程拆开来讲，希望能给想折腾类似工具的前端同行省点时间。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. AI 写作 CLI 实战：先搭一个能“一键出稿”的环境
先说工具选型，再说我踩过的一个非常典型的坑。很多刚开始接触 AI CLI 的人会想当然地认为，直接装某个大厂出的 Codex CLI 就够了。我确实装过，也确实被它折腾得够呛。
2.1 选型：我最终没死磕 Codex CLI，而是写了 Node 脚本调 API
这里先澄清一下，我不是说 Codex CLI 不好，只是它在当时还不适合我这种需要在自动化脚本里精细控制生成流程的场景。Codex CLI 是一款很强大的智能终端工具，它更适合在代码仓库里做编程任务，能读懂项目结构、修改文件、执行命令，本质上是把 AI 变成了你的结对编程伙伴。但我这个项目要解决的是“批量生成文章并发布”，更看重的是对生成流程的精细控制：分步生成大纲、逐段扩写、统一格式化、保存草稿。
所以我最后选择了更朴素的方案：用 Node.js 脚本直连大模型 API，通过 HTTP 请求把提示词发给模型，拿到返回的 Markdown 文本后做本地处理。这个方案的优点非常明显——可控性高、依赖少、方便调试，而且不绑定某一家厂商的 CLI 工具。想换模型厂商的时候，只需要改接口地址和 key。
如果你也想自己搭一套，可以先准备这些环境，不需要太复杂：
- Node.js 18 以上，建议 20 LTS，后面跑脚本会省很多事。
- 一个支持 OpenAI 兼容接口的大模型 API key，具体选哪家看预算和生成质量要求。
- 本地安装好 Git，用来管理生成出来的文章草稿，方便回溯版本。
- 准备一个专门放脚本和文章模板的目录，比如
~/ai-cli-csdn。
2.2 一个让我排查了半小时的报错：unable to locate the codex cli binary
如果你最近在用 Codex CLI，或者用过 ChatGPT 桌面版里集成 Codex 的功能，很可能见过这条报错：`unable to locat