并不是 AI 替代人,而是会用 AI 的人替代不会用 AI 的人。

我的大模型使用历程
从2023年秋季,我开始使用对话型的大模型,提升工作和学习的效率,以及回答一些生活上的常识问题。最开始是 ChatGPT 的免费版本,随着使用频率提高,慢慢会遇到问答超过上限的情况。随后便开通了Plus订阅直至今日。期间也曾使用过 Deepseek、Gemini、Minimax 等等,不过最主要的仍然是 ChatGPT,个人感觉它在回答的质量、速度、上下文方面体验最好。
在这段历程里,网页对话型 的 AI 工具是我使用的主流。优点是使用门槛低,点击即用,不需要额外安装软件,是搜索引擎的上位替代,很大程度上节约了人工筛选和信息加工的成本。与此同时,缺点也很明显:上下文容量有限、回答质量与 Prompt 质量密切相关、会话管理机制非常简陋等等。其中最麻烦的在于写代码,我不得不在浏览器窗口和 IDE 之间反复切换------将代码从浏览器粘贴到 IDE,并且将运行失败的错误日志从IDE粘贴到浏览器,然后让 AI 分析作答。很多时间都耗费在了信息传递上,而不是真正有价值的问题推演。
2025年,Agent 逐渐进入大众视野,开始真正解决上述痛点。作为开发者,我们可以将指定目录的读写权限赋予 Agent,并允许它执行 Python、Shell 等脚本。这样一来,很多原本需要人肉转述的信息流转,就可以直接在终端内闭环完成。

经过调研与交流,我了解到目前市面上评价较高的 Coding Agent 主要有两个:Anthropic 的 Claude Code,以及 OpenAI 的 Codex。由于 ChatGPT Plus 订阅包含了 Codex 的使用权限,我就先从其开始上手。
Codex 的环境搭建
接下来将在本文中记录,Windows11 笔记本上搭建 Codex 开发环境的步骤。
在 Windows 环境有两种安装 Codex 方法,对比如下:
| 方案 | 推荐度 | 原因 |
|---|---|---|
| PowerShell + npm | ⭐⭐ | 能用,但兼容性一般 |
| WSL + npm | ⭐⭐⭐⭐⭐ | Linux环境稳定、工具链完整 |
由于 Linux 是 AI coding agent 的主战场,在 Shell 兼容、文件系统操作、sandbox 执行、package manager 等方面,都天然更适配 Linux。因此,Codex、Claude Code、Aider 等 AI coding 工具几乎都更推荐通过 WSL 接入 Windows 开发环境。
安装流程如下
1、安装 Ubuntu
使用管理员权限启动 PowerShell 后,执行:
bash
wsl --install -d Ubuntu

安装完成后,重启电脑。
2、安装 Node
启动 PowerShell(非管理员):
bash
wsl
这会启动 Ubuntu 系统,在正式进入系统前,你需要设定用户名 & 密码。
进入后,先更新依赖仓库:
bash
sudo apt update
sudo apt upgrade -y
安装 Node:
bash
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
检查安装结果,注意 Codex 需要 Node版本 >= 18:
bash
node -v
npm -v

3、安装 Codex
安装 Codex CLI
bash
npm install -g @openai/codex
验证安装结果:
bash
codex --version

到此为止,就已经完成了Codex的环境搭建,可以通过codex命令进入到CLI界面,愉快地开始工作吧。
bash
codex

我对于 AI coding 的一些想法
用了一段时间 Codex 之后,我最大的感受是:AI coding 的价值并不只是"自动写代码",而是 把开发过程里大量机械、重复而且耗神的工作接管过去。
站在软件工程师的角度,开发工作主要有3个部分:
- 搭建环境,解决编译问题
- 设计软件架构,拆分模块,设计接口
- 编码实现(业务代码+单元测试)
AI coding 擅长实现1和3,从而让我们的精力集中在2上。在现阶段 AI 还不能充分理解需求和策划文稿,更不用说与产品经理、设计师进行细节确认,这些任务应当由软件工程师主导完成。
此外,在真实工作里,还有大量隐性成本:梳理文件结构、分析调用链、比对日志、调整格式和命名、解决 gradle 依赖、处理构建错误、写 API 文档 ------ 这些事情单次看都不重,可一天下来非常消耗注意力。Agent 的意义,恰恰是把这些碎片劳动接过去一部分,让人类把更多精力放在判断、取舍和架构层面。
当然,AI coding 也绝不是"把工程师变成监工"这么简单。恰恰相反,它对工程师提出了更高要求。因为当写代码本身变得更便宜之后,真正稀缺的能力会变成另外几件事:
- 能不能把问题定义准确。
- 能不能划定清晰边界。
- 能不能识别一个方案是否可行。
- 能不能用工程化手段验证结果。
不会这些能力的人,就算手里有最强的 Agent,也很容易陷入另一种低效:不停地下指令、不停地返工、不停地修补 AI 自己制造的问题。表面看像是在"高频使用 AI",实际上只是把原来的体力劳动,换成了新形式的沟通内耗。
所以我越来越倾向于认为,AI 所能达到的上限,不会超过使用者的上限。它不会自动替你建立判断力,但会把你的判断力放大到更大的执行半径上。
从这个角度看,未来团队里的差距,很可能不只是"会不会写代码"、"会不会用 AI",而是 会不会组织 AI 一起写代码 。谁能更好地 描述任务、拆解问题、设定约束、校验结果,谁就更容易在同样时间里交付更多有效成果。
这也是为什么我觉得现在值得认真学习 Codex、Claude Code 这类工具。它们不只是新玩具,而是在改变软件开发的人机协作方式。也许再过几年,我们回头看今天,就像回头看当年从手写 Makefile 过渡到现代 IDE、从纯命令行调试过渡到图形化调试器一样。工具变了,工作方式也会跟着变;而真正长期受益的人,往往是那些不固步自封,去积极拥抱新技术的人。
