2026年Codex 超详细入门：Windows 安装配置、VS Code 开发、环境搭建与报告写作全流程

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

 
  
    
     最近我把两篇关于 Codex 的文章重新梳理了一遍，一篇偏 Windows 下的安装与排障，一篇偏 VS Code + Codex CLI 的嵌入式开发工作流。两篇内容都有价值，但也有不少重复，比如都提到了安装 @openai/codex、首次登录、常见报错和基本使用方式。

这篇文章把重复部分合并，只保留一套更顺手的流程。同时我补充了一些更实用的场景：除了写代码，Codex 其实还很适合帮你装软件、配环境、读项目、写文档、整理报告，甚至先把一篇完整博文草稿写出来，再由你自己审核后发布。

这篇文章适合谁？

想在 Windows 上把 Codex 跑起来的同学

想把 Codex 接进 VS Code 或嵌入式工作流的人

想用 Codex 帮自己配环境、写文档、写报告、整理博客的人

如果你只想先抓重点，这篇文章最值得记住的是 3 件事：

Codex 真正好用的前提，是先把本机环境、命令行链路和项目规则理顺。
它最适合处理“边界清晰、能验证结果、可以逐步推进”的任务。
它不只是写代码工具，同样适合装软件、配环境、读项目、写报告和整理文章。

如果一句话概括，ChatGPT 更像“帮你想”，Codex 更像“帮你动手做”。

它不是只会补代码的聊天工具。真正好用的地方在于，它可以结合文件、命令行、工程目录和规则文件，一步一步完成比较完整的任务，比如：

安装和配置开发环境
阅读现有项目并总结结构
新建模块、修改配置、联调构建
根据报错继续修复直到通过
审查 git diff
生成 README、实验报告、接口说明、周报
批量整理文件、生成脚本、补测试

OpenAI 在 2026 年 4 月 23 日发布的 Academy 页面也明确提到，Codex 不只是面向程序员，它也适合处理“跨多个文件和工具”的任务，例如整理资料、生成文档、制作输出物。这个定位其实很重要：别把它只当成“代码补全”，那就低估它了。

两篇原文里最值得保留的共同结论只有一个：先把基础环境理顺，再安装 Codex。

2.1 安装 Node.js

Codex CLI 依赖 Node.js。Windows 下最直接的方式就是安装 LTS 版本。

winget install -e --id OpenJS.NodeJS.LTS

安装完成后重开终端，检查：

node -v npm -v

如果 PowerShell 因执行策略限制导致 npm 运行异常，可以执行：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

2.2 先换 npm 源

这一步在国内尤其关键。很多人不是不会装，而是卡在下载阶段。

npm config set registry https://registry.npmmirror.com npm config get registry

确认输出的是镜像地址，再继续安装。

2.3 安装 Codex CLI

npm install -g @openai/codex codex --version

如果装完后提示 codex 命令不存在，通常是终端还没刷新 PATH。最简单的办法是重开 PowerShell；不想重开也可以手动刷新当前会话的 PATH。

2.4 登录方式

两篇原文里一篇更偏向通过第三方镜像和 Token 配置，另一篇提到首次运行时可以登录。

codex

首次启动后，按页面提示完成登录即可。实际使用中，建议把认证信息和密钥单独保存，不要写进公开仓库、公开截图或公开文章。

第二篇文章最有价值的部分，不是“怎么装”，而是它把 Codex 放进了一个完整开发链路里：

VS Code 看代码 -> Codex 处理任务 -> VS Code 看 diff -> 构建验证 -> 调试/烧录

这个思路比单纯“开个终端聊天”实用得多。

3.1 适合什么项目

Codex CLI 配合 VS Code，最适合这些能命令行构建的工程：

STM32CubeMX 生成的 CMake 工程
Zephyr 工程
ESP-IDF 工程
PlatformIO 工程
裸机 Makefile 工程

如果你的项目只能靠某个强依赖 GUI 的老 IDE 才能编译，那么 Codex 也不是不能用，但会更适合做“辅助编辑、解释代码、生成模块、查问题”，而不是全流程自动验证。

3.2 VS Code 推荐扩展

常见组合可以这样配：

C/C++
CMake Tools
Cortex-Debug
WSL（Windows 用户常用）
GitLens（可选）
GitHub Copilot / Copilot Chat（可选）
Codex IDE Extension（可选）

3.3 Windows 用户为什么还常被建议用 WSL2

第二篇原文更偏向这个思路：Windows 用户可以用 VS Code，但工程最好放到 WSL2 里的 Linux 文件系统中开发。

这个建议在嵌入式场景依然很实用，因为交叉编译工具链、openocd、调试器、路径兼容性这些问题，放在 WSL2 里通常更稳。尤其不要把核心工程长期放在 /mnt/c/... 这类跨文件系统路径里，速度和权限体验都容易打折。

不过也要补充一句新情况：OpenAI 在 2026 年 2 月 2 日发布 Codex App 时宣布 Windows 版已在 2026 年 3 月 4 日开放；另外 2025 年 12 月 18 日发布 GPT-5.2-Codex 时也提到对 Windows 环境支持更强。也就是说，今天的 Codex 生态对 Windows 已经比早期成熟不少。只是对嵌入式开发者来说，WSL2 在工具链一致性方面仍然往往更省心。

第二篇文章里我最赞同的一点，是建议在工程根目录写 AGENTS.md。

原因很简单：Codex 不是不会改代码，而是有时候“太愿意帮你改”。如果你不提前说明边界，它可能把你不想动的文件也一起碰了。

对于 STM32、RTOS、驱动类项目，可以在 AGENTS.md 里写清楚：

回答语言
优先小步修改
不要随便改 Drivers/
只在 USER CODE 区域内改 CubeMX 生成文件
修改后尽量执行构建
涉及烧录、擦写、设备状态变化时先说明再操作
注意中断、DMA、volatile、RTOS API 的风险

这类规则一写，Codex 的输出通常会稳定很多。

原文里给了一些嵌入式提示词模板，我这里把它们压缩成更通用的四类。

5.1 先理解项目，不急着改

请先阅读这个工程的目录结构、构建文件和入口文件。 不要修改代码。 请告诉我： 1. 这个工程怎么编译 2. 主流程从哪里开始 3. 哪些文件适合写业务代码 4. 哪些目录不要动

5.2 让它新增一个模块

请为这个工程新增一个 LED/按键/串口模块。 要求： 1. 新建头文件和源文件 2. 不使用动态内存 3. 保持和现有命名风格一致 4. 更新构建脚本 5. 构建并修复编译错误

5.3 让它查第一条真错误

构建失败了。 请运行构建命令，读取完整输出。 优先定位第一条真正的编译错误或链接错误。 修复后继续构建，直到没有 Error。 不要修改 Drivers 目录。

5.4 让它只做代码审查

请审查当前 Git diff。 重点关注： 1. 中断和主循环共享变量 2. DMA 缓冲区生命周期 3. 阻塞式延时 4. 生成代码区域是否被误改 5. 构建脚本是否漏加文件 只输出问题和建议，不要改代码。

这部分是我想额外补上的，因为很多人对 Codex 的理解还停在“帮我补几行代码”。实际上，它在下面这些事情上也很强。

6.1 帮你下载和安装软件

如果你的电脑里已经有包管理器或命令行安装工具，Codex 很适合把安装过程串起来。例如：

安装 Node.js、Git、Python、VS Code、CMake、OpenOCD
检查版本是否正确
根据报错补缺失组件
写出一套可重复执行的安装命令

它的价值不是“神奇下载”，而是它知道先装什么、后装什么，知道装完要不要验证，知道哪里可能出 PATH、权限或依赖问题。

6.2 帮你配置开发环境

这一类任务其实特别适合 Codex：

配 PATH
配 npm、pip、Git 镜像
生成 .vscode/tasks.json
生成 .vscode/launch.json
配 c_cpp_properties.json
检查 CMake/Ninja/GCC/调试器是否能跑通

很多“环境配不好”的本质，不是不会点按钮，而是缺少一条完整链路。Codex 可以边检查边补。

6.3 帮你读陌生项目

这是我认为最被低估的功能之一。

你完全可以把它当成一个“项目导览员”，直接让它：

总结目录结构
找入口函数
梳理模块依赖
说明构建链路
标出自动生成代码和业务代码边界
告诉你“改哪个文件最合适”

对于接手老项目、做毕业设计、或者刚进实验室的人，这个价值非常高。

6.4 帮你写文档、说明书和实验报告

这不是顺带功能，而是很实用的主力功能。

比如你可以直接让 Codex：

根据源码写 README
根据调试过程写实验记录
根据目录结构写模块说明
根据结果截图整理测试报告
根据你的大纲扩写课程设计报告
把零散笔记整理成可发博客的文章

如果你本来就要写 CSDN、课程报告、项目总结，那 Codex 非常适合先给你一版结构完整的草稿，再由你自己修正措辞、补图片、加个人经验。

6.5 帮你做代码审查和风险排查

相比“从零写一大段代码”，我其实更推荐新手先拿它做这件事：

审查当前改动有没有明显 bug
检查实时性风险
看变量是否该加 volatile
看中断里有没有不合适的阻塞操作
看 DMA/缓存/生命周期是否安全
看构建脚本是不是漏了新文件

这个用途很稳，因为它的任务边界很清晰。

6.6 帮你写博客初稿

这正是你这次这个需求本身。

比较高效的做法不是让它“直接替你发”，而是让它先完成下面几步：

汇总资料
去重重组
补充官方信息
调整为适合发布的口语化结构
输出 Markdown 成稿

最后你只需要自己检查事实、改一下个人表达、插入图片，再决定是否发布。

这一点两篇原文都在提醒，只是侧重点不同。我这里统一成一句话：越靠近底层、启动、时序、安全、烧录链路，越要谨慎。

尤其是下面这些内容，建议先让它解释，再决定要不要改：

启动文件
链接脚本
中断向量表
时钟树初始化
Bootloader 跳转
Flash 擦写
DMA + Cache
安全校验、密钥、升级相关代码

嵌入式里很多 bug 不是“写错一个 if”，而是改错了系统边界。

如果你想把 Codex 真正用顺，我建议按这个节奏来：

先让它读项目，不改代码
再让它做一个很小的修改
看 diff
运行构建
修复问题
再做下一步

不要一上来就说“把整个工程重构一下”。Codex 很强，但工程任务越大，越需要你把目标拆清楚。

把两篇文章合并后，我觉得最核心的结论其实不是“Codex 怎么安装”，而是下面这三点：

Codex 真正好用的前提，是你的环境、构建链路和项目规则先清楚
它最适合接手“有边界、可验证、能逐步推进”的任务
它不只适合写代码，同样适合装软件、配环境、读项目、写文档、写报告和整理博客

如果你只是把 Codex 当成“高级补全”，那它的价值只发挥了一小部分。更高效的用法，是把它当成一个能读文件、能执行步骤、能生成结果、但仍需要你审核的数字搭档。

原文 1：Codex CLI 完美配置指南（Windows 篇）
https://blog.csdn.net/2402_/article/details/
原文 2：使用 Codex CLI 和 VS Code 开发嵌入式
https://blog.csdn.net/2301_/article/details/
OpenAI Help Center: OpenAI Codex CLI – Getting Started
https://help.openai.com/en/articles/
OpenAI Academy: What is Codex?
https://openai.com/academy/what-is-codex/
OpenAI: Introducing the Codex app
https://openai.com/index/introducing-the-codex-app/
OpenAI: Introducing GPT-5.2-Codex
https://openai.com/index/introducing-gpt-5-2-codex/