夜雨聆风
AI 新手，为什么我更建议你先从 Codex 开始？
作为新手，我已经使用codex将近一个月，中间了踩了各式各样的坑，
从了解各种ai工具
到学习各种名词解释
到理解原理
到下载问题
到登录问题
到使用问题
到账号问题
到与CHATGPT的关系
到各种skill 插件 问题
到操控电脑
到远程链接
到多账号使用
到会员问题
到验证问题
到历史会话消失
到自己制作软件
到软件落地使用
到融合工作使用
到使用项目 等等，
使用之后，毫不夸张的说这就是当代的 人的春药
绝世好剑，碧血剑谱，乾坤大挪移，天龙八部，
这是行走江湖人士必须要掌握学习的工具，也是数字游民必须要学习的工具，总之只要你不想沦为时代的弃子，不想脱离世界，就必须要花时间经历学习研究！
它的威力绝对不亚于19世纪的工业革命 20世纪的互联网，就好比直接从冷兵器时代进化到核武器时代！
首先必须要跟大家讲清楚：不是只要程序员 或者 编程 IT从业者才需要学习使用，任何一个人 只要受过九年义务教育，有手 有脚 有脑子 有想法 有动手能力，愿意接受 学习新事物，那就可以开始使用Codex
普通人如何利用好这个神器 利用好这把绝世好剑 ，不要宏观视角，只从老百姓从0开始，建议直接上手 使用codex，直接放弃Qclaw work Buddy Hermers Claude等，下面是入门介绍：
摘要AI 工具越来越多，但新手最先要解决的不是“哪个最强”，而是“我能不能看懂它在做什么，并且把它控制住”。这篇文章从 Codex App、/plan、/goal、Skill、插件和日常使用习惯讲起，帮你建立一套更稳的 AI 入门路径。 |
正文
如果你刚开始用 AI ，我不太建议你一上来就追最猛的工具。
不是因为那些工具不好。
Claude Code 很强，Hermes 也有它自己的爽感。很多演示看起来也确实让人心动：一条指令下去，项目自动跑起来，代码自动改完，测试自动通过。
但对新手来说，真正的门槛往往不是“工具够不够强”，而是：
它到底在做什么？
我能不能看懂？
它改错了，我能不能把它拉回来？
它要跑命令、改文件、装依赖、联网的时候，我知道风险在哪里吗？
如果这些问题还没解决，直接追最强的 coding agent，反而容易越用越慌。
所以我的建议是：先从 Codex 开始。
不是因为 Codex 永远最强，而是因为它更适合新手建立一套可观察、可控制、可验证的 AI 编程协作习惯。
这比单纯追工具天花板更重要。
一、新手最容易被 AI 编程劝退的地方
很多人第一次接触 AI 编程工具，会以为它只是“更会写代码的 ChatGPT”。
但真正的 coding agent 不是这样。
普通聊天是你问一句，它答一句。
而 coding agent 会进入你的项目，读文件，理解结构，修改代码，运行命令，查看报错，然后继续修。
你面对的不是一个答案，而是一串真实动作。
这也是新手最容易慌的地方。
入口太多：桌面 App、IDE、CLI、Cloud，不知道从哪开始。
名词太多：Agent、Worktree、Sandbox、MCP、Plugin、Skill、Diff，看起来都重要，但不知道先学哪个。
风险感太强：担心它乱改项目、乱删文件、乱装依赖。
反馈太专业：终端日志、测试报错、代码差异，新手一眼看过去全是压力。
需求说不清：只会说“帮我优化一下”“帮我做个网站”“帮我改好看一点”，结果 AI 做出来的东西和自己想的完全不是一回事。
所以，新手真正需要的不是一个“看起来最强”的工具，而是一个能帮你建立秩序的入口。
Codex 的价值就在这里。
它把项目、线程、权限、终端、改动、验证、插件这些关键环节放到一个相对清晰的工作台里。
你可以先看懂，再动手。
二、为什么我更建议新手先用 Codex
我推荐 Codex，不是想说它在所有场景都压过其他工具。
AI 编程工具变化太快了。今天一个模型更新，明天一个产品追上，没必要一开始就陷入“到底谁最强”的争论。
对新手来说，更重要的是下面五件事。
1. 它有一个更容易入门的起点
你可以先从 Codex App 开始。
桌面 App 的好处是，你能看见项目、线程、终端、diff、权限和插件。它不像纯命令行那样信息密度很高，也不像只在 IDE 里那样容易让新手忽略“AI 到底动了哪些文件”。
先从可视化界面建立手感，再慢慢进入 IDE、CLI 和 Cloud，这个顺序对新手更友好。
2. 它的过程相对可见
用 AI 写代码，最怕的不是它不会改，而是它改了很多东西，你却不知道它为什么这么改。
Codex 的一个优势是：它读了什么、准备怎么做、改了哪些文件、跑了哪些检查，你都能追踪。
过程可见，才有控制感。
对新手来说，控制感非常重要。
你不是把项目丢给 AI，然后祈祷它做对。
你是在和它协作。
3. 它能让你更早理解权限边界
AI 编程不是没有风险。
它可能读取文件，修改文件，运行命令，联网搜索，甚至连接外部工具。
新手一开始不需要把权限全部打开。
更稳的做法是：先在小项目、小范围、小任务里试。
需要读哪些文件，就给哪些上下文。
需要改项目，就先看 diff。
需要联网或操作外部工具，再按任务授权。
一句话：权限够用就好，不要上来开满。
4. /plan 和 /goal 很适合新手
这两个能力，我觉得是新手特别应该学会的。
/plan 适合任务还没想清楚的时候。
你可以先让 Codex 读上下文、问问题、拆步骤、指出风险，而不是马上开工。
比如：
/plan我想优化登录体验，但还没想清楚要改哪里。请先阅读相关代码，问我必要问题，然后给出分阶段计划。现在不要修改文件。
/goal 适合长任务。
比如修一组测试、做一次迁移、整理一批文档、优化一个性能指标。你给它一个清晰目标，它就持续围绕这个目标推进。
你可以这样理解：
/plan 是开工前的地图。
/goal 是长任务里的方向盘。
如果一个任务你自己都说不清，先用 /plan。
如果一个任务步骤很多、需要持续推进，再用 /goal。
5. Skill 和插件可以让能力逐步打开
新手不要一上来就研究所有扩展机制。
你先把一次任务做顺。
做顺以后，再把重复出现的要求沉淀成 Skill。
比如你每次都要让 Codex 按同样方式写公众号文章、做 code review、整理表格、生成报告，那就可以把这套流程变成 Skill。
Prompt 是一次性要求。
Skill 是可复用工作流。
插件和 MCP 则是更进一步：让 Codex 连接外部系统、浏览器、文档、GitHub、数据库、自动化工具等等。
顺序应该是：
先会提需求。
再会看过程。
再会验收结果。
最后再扩展能力。
三、Codex 到底是什么？
用一句人话说：
Codex 不是只会聊天的 AI，而是一个能进入项目现场做事的 AI 助手。
它可以帮你：
解释陌生项目； 找 bug； 改代码； 补测试； 跑 lint、test、build； 看 diff； 做 code review； 写文档； 处理表格、PPT、PDF、图片等非代码产物； 通过插件连接更多外部工具。
但你不要把它理解成“自动程序员”。
它很强，但你仍然要负责三件事：
第一，目标是什么。
第二，边界在哪里。
第三，怎样算完成。
你说“帮我优化一下”，它很容易跑偏。
你说：
目标：把首页首屏加载时间优化到 1 秒以内。约束：不改 API，不大重构，优先最小改动。完成标准：指出瓶颈，完成修改，运行检查，并报告前后差异。
效果就完全不一样。
AI 不怕任务难，怕的是任务又大又空。
四、新手第一次打开 Codex，应该怎么用？
我建议你按这个顺序来：
Codex App -> IDE 插件 -> CLI -> Cloud。
Codex App 支持 macOS 和 Windows。安装后可以用 ChatGPT 账号登录，也可以用 OpenAI API key 登录。用 API key 时，部分和 ChatGPT 计划绑定的功能可能不可用。
这是桌面图标（备注：软件无法在国内正常下载，我有安装包，有需要来联系我）
这是正常使用界面：
先用 Codex App 建立手感
第一次不要拿最重要的项目练手。第一次打开 App，建议这样做：
选一个不太重要、最好有 Git 的项目；
选择 Local；
第一条 prompt 只让它解释项目，不要改文件；
打开 diff 和终端，观察它怎么工作；
熟悉后再让它做小改动。
打开以后，第一条指令只让它解释项目，不要改文件。
你可以直接这样写：
请先不要修改任何文件。帮我理解这个项目：它是做什么的？入口文件在哪里？启动、测试、构建命令是什么？如果我要改首页，应该先看哪些文件？请用新手能听懂的话解释。
这一步非常重要。
你不是急着让它干活，而是在观察它怎么理解项目。
它读了哪些文件？
它的判断有没有依据？
它有没有把“确认过的事实”和“推测”分清楚？
如果这一步都说不清，就不要急着让它改代码。
第二步：做一个很小的改动
比如改一个文案、修一个样式、调整一个按钮状态。
指令可以这样写：
目标：把首页按钮文案从“开始使用”改成“立即体验”。约束：只改必要文件，不调整布局，不引入新依赖。完成标准：修改后告诉我改了哪个文件，并说明如何验证。
小任务最适合建立信任。
你要重点看 diff，而不是只看它的总结。
总结是它说的。
diff 才是它实际做的。
第三步：让它跑一次验证
如果是前端项目，可以让它跑：
npm run lintnpm run build
如果是有测试的项目，可以让它跑相关测试。
你不需要一开始看懂所有日志。
先看三件事：
有没有 error？
命令有没有成功？
如果失败了，Codex 有没有根据错误继续定位？
验证这一步，会让你逐渐从“看 AI 表演”变成“验收 AI 工作”。
IDE 插件：适合边看代码边协作如果你常用 VS Code、Cursor、Windsurf，IDE 插件更自然。你可以把正在看的文件、选中的代码直接作为上下文，也可以用 @文件名 引用文件。适合这种任务：text文本看一下 @LoginForm.tsx 和 @auth.ts。先解释当前登录流程，再给一个最小修改方案。 CLI：适合终端用户Codex CLI 适合习惯终端的人。 什么是终端？下图所示 ，资深程序员 黑客喜欢的方式 
进入项目目录后运行：bashcodexCLI 信息密度高。新手不是不能用，但我不建议第一站就从 CLI 开始。 Cloud：适合更长、更并行的任务Cloud 适合远程运行、后台执行、并行任务。但先理解本地 Local、Worktree、diff、权限，再用 Cloud，会顺很多。
五、Codex App 里最重要的几个板块不用一开始看懂所有按钮，先抓住这几个。
Project 项目
七、真正好用的提示词公式
新手不用背一堆神奇咒语。
只记一个公式：
目标 + 上下文 + 约束 + 完成标准。
目标：你要它改变什么。
上下文：哪些文件、截图、报错、背景很重要。
约束：哪些不能改，哪些要优先，哪些要避免。
完成标准：怎样才算做完。
比如修 bug，可以这样写：
目标：修复登录后刷新页面又回到未登录状态的问题。上下文：复现步骤是打开 /login，登录成功后刷新页面，页面又回到未登录。约束：不要改 API 返回结构。优先最小改动。新增依赖前先解释原因。完成标准：找到根因。给出修复。补一个回归测试。运行最小相关测试并报告结果。
这类 prompt 不一定很长，但边界清楚。
边界清楚，AI 才更容易做对。
八、计划模式 /plan：先让 Codex 想清楚
目标模式 /goal：让 Codex 持续盯着终点
什么时候用 /plan？
遇到下面四种情况，先用 /plan：
任务复杂。
需求还模糊。
改动风险比较高。
你还不懂当前项目。
好的 plan 不应该只有“我会先分析、再修改、最后测试”这种空话。
它应该具体到：
当前状态是什么； 目标是什么； 可能涉及哪些文件； 计划分几步； 哪些地方有风险； 怎么验证； 哪些问题需要你确认。
如果 Codex 给你的计划太泛，你可以继续追问：
这个计划太泛了。请具体到文件、组件、数据流和验证方式。哪些是你已经确认过的，哪些只是推测？
/plan 的本质，是把“我想让 AI 帮忙”变成“我和 AI 一起定义任务”。
这一步对新手特别有价值。
什么时候用 /goal？
/goal 更适合长任务。 /goal：让 Codex 持续盯着终点
比如：
修一组失败测试； 做一次依赖升级； 优化一个性能指标； 整理一批文档； 迁移一个模块； 持续推进一个多步骤修复。
不好的 goal 是：
帮我把项目优化一下。好的 goal 是：
把首页首屏加载时间优化到 1 秒以内。完成标准：找到主要瓶颈。做最小必要改动。不改变 API。运行性能检查。报告优化前后的差异。
如果你写不出好的 goal，先用 /plan 让 Codex 采访你。
先 /plan，再 /goal，这是新手处理复杂任务最稳的顺序。
九、Skills：把重复工作变成可调用流程
Skill 可以理解成：
一套教 Codex 怎么做某类任务的工作说明书。
写长文有写长文的流程。
做 code review 有 review 的流程。
生成图片有图片的流程。
处理飞书、GitHub、文档、表格，也可以有各自流程。
如果你每次都手动告诉 Codex 同一套要求，就该考虑把它沉淀成 skill。
Skill 通常是一个包含 SKILL.md 的目录，可以带脚本、参考资料和资源。Codex 会先看到 skill 的名称、描述和路径；只有决定使用时，才读取完整说明。
使用 skill 有两种方式：
显式调用：在 prompt 里写
$skill-name$技能名称
；
隐式触发：任务和 skill 描述匹配时，Codex 自动选择。
一句话：Prompt 是一次性要求，skill 是可复用工作流。
十、Plugins、MCP、Apps：Codex 怎么连接外部世界
这几个词容易混，直接看表。
Prompt：这一次怎么做。
AGENTS.md：这个项目长期怎么做。
Skill：某类重复任务以后都怎么做。
Plugin：把一组能力打包起来。
MCP 或 App：连接外部工具和系统。
Automation：让某件事按时间或条件自动发生。
所以选择方式也很简单：
一次性的要求，写进 prompt。
项目长期规则，写进 AGENTS.md。
反复出现的流程，做成 Skill。
要分发一组能力，做成 Plugin。
要连接外部世界，用 MCP 或 App。
要定时重复，用 Automation。
新手不用一开始全懂。
先把“用 prompt 做一次任务”练熟。
再把重复要求沉淀成 Skill。
这样你的 AI 工作流会越用越省力。
十一、AI 编程新手最应该养成的 10 个习惯
如果你只想带走一份清单，就记住这 10 条。
一次只交给 AI 一个主要任务。 不懂项目时，先让它解释，不要马上修改。 复杂任务先 /plan。长任务再 /goal。Prompt 里一定写完成标准。 改完让它跑测试、lint 或 build。 不要只看总结，要看 diff。 权限从窄到宽，不要一上来全开。 重要任务先让它复述目标和限制。 反复出现的要求，沉淀成 AGENTS.md、Skill 或模板 prompt。
这 10 条，比任何“神级提示词”都重要。
因为 AI 编程的核心，不是让 AI 多写几行代码。
而是你能不能把目标、上下文、边界和验证方式讲清楚。
我推荐新手先用 Codex，不是因为它永远最强。
而是因为它更适合帮你建立一套正确的 AI 协作习惯。
你可以从 App 开始，看见项目、线程、diff、终端和权限。
熟悉以后，再进入 IDE、CLI、Cloud。
小任务用 Local。
大改动用 Worktree 隔离。
模糊任务先 /plan。
长任务再 /goal。
重复任务沉淀成 Skill。
需要连接外部工具时，再逐步使用插件和 MCP。
这套东西看起来多，但真正的目的不是炫技。
它是在教你设计一个可执行、可观察、可验证的 AI 工作流。
等你把这些动作跑顺，再去看 Hermes、Claude Code、Cursor 或其他 agent 框架，你的判断会完全不一样。
你不会只问：
哪个工具最强？
你会开始问：
它能不能理解上下文？
它有没有暴露过程？
它能不能控制权限？
它能不能规划复杂任务？
它能不能推进长期目标？
它能不能把重复工作沉淀下来？
这才是 AI 编程真正入门的时刻。
如果你现在还在门口犹豫，我的建议很简单：
别先追最猛的演示。
先打开一个真实项目，让 Codex 只做一件小事。
第一步，不改文件，只解释项目。
第二步，做一个小改动。
第三步，看 diff。
第四步，跑验证。
第五步，再试 /plan 和 /goal。
你会发现，AI 编程真正让人变强的地方，不是它替你写了多少代码。
而是它逼你学会更清楚地定义问题、更稳定地推进任务、更认真地验收结果。
这才是少走弯路的开始。
预告：下一篇我会把我所遇到的问题总结归纳，大家可以必坑少走弯路
