个人主页杨利杰YJlio❄️个人专栏《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《IOS插件分析测试》《超简单用Python让Excel飞起来》让复杂的事情更简单让重复的工作自动化Codex 完整实战教程从 APP、CLI 到 AGENTS.md、Skills 和 MCP一、为什么要重新理解Codex二、先看完整教程结构不要只盯着单个功能三、进入Codex APP后先完成初始化四、创建项目文件夹先确定代码工作区五、在项目内创建新对话区分项目和任务六、理解Codex和Claude Code的差异七、Seatbelt Sandbox决定默认权限边界八、进入实战前先管理好上下文九、用Pet Spa项目开始真实页面修改十、用Steer人工引导任务方向十一、在pet_care项目中发起任务十二、检查页面生成结果而不是只看回答十三、进入GitHub前先确认代码变更十四、用Git WorkTree隔离不同任务十五、确认无问题后再合并改动十六、把项目规则写进AGENTS.md十七、全局记忆和偏好要和项目规则分开十八、用Skills封装重复流程十九、安装Skills有多种方式二十、通过MCP接入外部服务二十一、部署后要回到页面验证结果二十二、用Netlify做静态网站托管二十三、安装Computer Use扩展浏览器能力二十四、完整使用流程建议二十五、总结Codex应该按项目工作流来用一、为什么要重新理解Codex很多人第一次接触Codex时会把它当成一个更适合写代码的ChatGPT。这个理解只对了一半。Codex确实可以回答代码问题但它更适合围绕真实项目完成任务读取项目文件、修改代码、生成页面、隔离分支、执行命令、连接外部服务、复用流程规则。教程开头把Codex分成四种形态Codex APP、Codex CLI、Codex 网页端和Codex 插件。这四个入口不是互相替代的关系而是分别适合桌面端项目操作、命令行流程、网页端任务管理和扩展能力调用。如果只是临时问一段代码怎么写用普通聊天也可以。但如果要让Codex修改真实项目就必须先处理好工作区、权限、项目规则和验证流程。否则短时间看起来能跑后面很难判断它到底改了什么、为什么这么改。二、先看完整教程结构不要只盯着单个功能这套教程不是单独讲某一个按钮而是把Codex的完整使用流程串起来。课程目录中可以看到Codex实战教程的多个章节覆盖项目管理、任务、沙箱、MCP、Skills等内容。这类教程适合按模块学习。先理解APP如何初始化再看项目文件夹怎么建先理解沙箱限制再看什么时候需要提权先学会让Codex修改页面再看怎么通过GitHub合并最后再处理AGENTS.md、Skills和MCP。学习顺序很重要。不要一上来就研究MCP或复杂自动化先把最基础的项目边界和任务边界弄清楚。项目边界没分清后面写再多规则文件也会出现上下文混乱。三、进入Codex APP后先完成初始化进入Codex APP后首先会看到桌面端的初始界面。视频里提到Windows和Mac版本功能基本一致所以使用路径可以统一理解先安装并打开Codex APP再按初始化向导设置使用偏好。初始界面更适合作为“工具入口”的说明。它说明Codex不只是浏览器中的一个页面而是有独立桌面端入口可以直接围绕本地项目工作。初始化阶段不要随便跳过。因为这一步会影响后续默认工作方式例如是否偏向开发任务、是否启用某些技能、是否需要让Codex先计划再执行。后续界面会询问“Codex可以帮你做什么”并提供内置插件和Skills相关选项。这些选项决定Codex在默认情况下更像“代码助手”“项目执行助手”还是“自动化流程助手”。建议第一次配置时不要追求一次性选满。先选择和当前工作最相关的能力例如代码修改、项目管理、自动化任务。等熟悉项目流程后再补充Skills或外部工具接入。四、创建项目文件夹先确定代码工作区Codex的项目文件夹不是普通聊天分类它对应的是一个真实代码工作区。视频里先创建两个项目文件夹再进入项目对话这个顺序很关键。项目文件夹负责承载代码、文件结构、任务上下文和执行结果。如果不先建立项目边界直接让Codex改文件很容易出现两个问题一个是上下文不清楚另一个是修改范围不受控。尤其是多个项目同时存在时必须先确认当前任务在哪个项目里执行。创建项目时左侧项目区和中间任务输入区是重点。这里要明确项目名称、项目路径和当前任务目标。比如一个Pet Spa网页项目就不要和脚本工具、数据分析项目混在同一个工作区里。选择项目时会进入Select Project Root文件夹选择器。这里要选择项目根目录而不是随便选择某个子目录。不要把多个无关项目放进同一个Codex项目里。项目越混后续AGENTS.md、记忆、技能和自动化越容易互相干扰。五、在项目内创建新对话区分项目和任务项目创建好之后下一步是在项目内部创建新对话。这里要理解一个层级关系Projects管项目范围单次对话或任务管具体操作。一个项目可以有多个任务但每个任务都应该有明确目标。视频中出现“在项目里面开启新的对话”的画面适合解释项目和任务之间的关系。项目是代码工作区对话是某一次具体操作。实际使用时建议把任务拆小。例如“调整首页导航”“新增预约表单”“修复地图显示”“补充测试用例”分别开任务。不要把它们都塞进同一轮对话里。如果已经存在多个对话就要回到正确上下文继续。视频里展示了选择某个对话、双击进入、重命名对话的操作场景这一步适合处理“上次做到一半现在继续”的任务。继续已有任务前要先看清楚当前对话对应的目标和历史操作。不要在错误对话里继续发新需求。这类错误最隐蔽后面会表现成文件被改到不相关位置或者任务结果和预期完全不一致。六、理解Codex和Claude Code的差异视频中专门用了一个对比画面解释Codex和Claude Code的不同。这里的重点不是评价哪个工具更好而是理解Codex的运行方式它不是在本机上无边界地直接操作而是有沙箱、安全边界和权限确认。这个对比适合放在沙箱机制前面因为它能先告诉读者为什么Codex有些操作不能直接做为什么联网、外部文件和高风险命令需要额外确认。Codex的关键不是“能不能直接控制电脑”而是“能不能在可控边界内完成项目任务”。理解这一点后后面再看沙箱、提权和风险等级就不会觉得它是在故意限制用户。七、Seatbelt Sandbox决定默认权限边界Seatbelt Sandbox是视频里很关键的一段。沙箱内的项目文件夹可以被Codex操作但默认不能随便修改沙箱外文件也默认禁止联网。这样做是为了避免AI在用户不确认的情况下改动本机文件或访问外部服务。画面里能看到沙箱内项目文件夹、禁止联网、禁止修改沙箱外文件等限制元素这正好对应Codex的默认安全设计。对日常开发来说这种限制反而是好事。因为真实项目里经常会有配置文件、密钥文件、构建产物、缓存目录和系统文件如果没有沙箱边界自动化工具一旦执行错误影响范围会变大。当任务需要更高权限时就会涉及Escalate。视频用低风险、高风险和人工审查说明了不同操作的处理方式。凡是涉及删除文件、批量修改、联网请求、提交代码、安装依赖、执行脚本的操作都应该谨慎处理。看到提权提示时不要只看是否方便要先判断这次操作是否真的需要这个权限。八、进入实战前先管理好上下文在真实项目里Codex的上下文管理很重要。项目中积累多个对话后必须知道每个对话对应什么任务。否则继续使用时容易接错上下文。建议给任务起清楚的名字。例如“首页样式调整”“预约表单字段修改”“地图组件修复”“部署到Netlify”。这样后续回到项目时能快速知道哪个任务做了什么。九、用Pet Spa项目开始真实页面修改视频中段进入Pet Spa宠物店网页项目。画面中出现门店信息、地图、地址、营业时间等内容说明这是一个接近真实业务页面的示例而不是单纯生成一个空白网页。这种实战项目适合用来验证Codex的综合能力它需要理解页面结构、保留已有内容、修改业务信息、处理表单和地图展示还要保证页面能正常运行。门店信息页适合作为实战数据来源。这里能看到地图和门店卡片所以后续修改时要注意不要只改页面样式还要确认地址、营业时间、预约入口等业务信息是否一致。十、用Steer人工引导任务方向视频专门解释了Steer字幕里将它理解为“控制、引导”。这说明使用Codex做复杂项目时不能只把需求丢过去等结果。人仍然需要告诉它目标、边界和优先级。比如做一个宠物店页面需求不能只写“帮我优化一下”。更好的写法是保留门店信息调整首页结构补充预约表单修复地图显示不要改动已有品牌色和导航结构。人工引导的作用是让Codex不偏离任务边界。它可以执行很多操作但执行前需要人把目标拆清楚。任务越复杂越需要先说明不要改什么。十一、在pet_care项目中发起任务进入pet_care项目后视频中通过提问开始任务例如“我们该在pet_care中做什么”这一类问题适合让Codex先观察项目再给出下一步建议。这个界面显示的是项目级任务入口。输入框里的问题不应该太泛也不应该直接要求它大改。更稳妥的是先让它分析项目结构再列出可操作的改动建议。如果项目里已经有页面、组件和样式文件建议先让Codex回答三个问题当前页面入口在哪里主要组件有哪些修改某个功能可能影响哪些文件。确认后再让它动手。十二、检查页面生成结果而不是只看回答经过任务执行后画面中出现泡泡爪 Pet Spa页面包含导航、品牌信息、门店区域和预约表单。这一步属于结果验证重点是看网页是否真的被生成或修改成功。页面结果比文字回答更重要。Codex可能说自己已经完成修改但最终还是要看页面能否打开、内容是否正确、布局是否异常、表单是否存在。验证网页时至少看四点页面标题是否正确导航是否保留门店信息是否准确预约区域是否能正常展示。涉及表单时还要检查字段名称和提交逻辑是否符合预期。十三、进入GitHub前先确认代码变更页面生成后视频进入Git与GitHub操作界面。这里对应代码变更提交和协作流程。对真实项目来说网页能跑只是第一步还需要把改动提交到版本控制系统里。进入GitHub前应该先确认本地改动文件、提交说明和分支目标。不要把未经验证的代码直接合并到主分支。这类界面适合讲代码协作流程先生成改动再检查差异然后提交或创建合并请求。如果项目多人协作必须看清目标分支避免把实验性修改直接推到主线。十四、用Git WorkTree隔离不同任务视频通过Git WorkTree解释main主文件夹和branch分支文件夹互不干扰。这个概念很适合搭配Codex使用因为Codex经常会同时处理多个任务如果都在同一个工作区里改冲突概率会明显增加。main主文件夹可以保持稳定branch分支文件夹用于试验某个功能。这样即使分支任务改坏了也不会直接影响主目录。建议高风险任务优先放到独立分支或独立工作树里执行。比如登录、支付、数据库结构、权限校验、批量重构都不适合直接在主工作区里让Codex大范围修改。十五、确认无问题后再合并改动后续画面进入GitHub PR合并页面。这里能看到No conflicts和Merge pull request说明当前分支没有冲突可以进入合并阶段。合并前至少要检查三件事代码差异是否符合任务范围页面或功能是否通过验证是否存在不该提交的文件。如果项目接入了测试流程合并前还应该跑测试命令。没有测试时也要至少进行页面手动验证。不要只因为Codex显示任务完成就直接合并。十六、把项目规则写进AGENTS.md视频进入VS Code后展示了项目根目录下的AGENTS.md。这个文件可以理解为给Codex看的项目说明书。后续所有和项目相关的任务都可能受到这个文件内容影响。AGENTS.md适合写项目结构、编码规范、运行命令、测试要求、禁止修改的文件、提交规则和特殊约束。它应该放在项目根目录不要随便放进某个子目录。如果项目里没有AGENTS.md每次都需要重复告诉Codex项目规则。把稳定规则写成文件后后续任务会更容易保持一致。建议AGENTS.md至少包含目录说明、开发命令、测试命令、代码风格、禁止修改范围。尤其是配置文件、密钥文件、构建产物目录要明确告诉Codex不要乱改。十七、全局记忆和偏好要和项目规则分开视频后段进入Personalization和自定义指令配置界面。这里适合放跨项目都通用的偏好比如回答语言、默认步骤、是否先给计划、是否输出验证方式。它和AGENTS.md的区别在于AGENTS.md是项目规则全局记忆是个人习惯。项目专属内容不要写到全局里否则换项目后容易误导Codex。界面中的配置区域适合管理长期偏好。比如你可以要求Codex默认先分析项目再列改动计划最后输出验证步骤。这种规则跨项目有效适合写到全局设置里。不要把某个项目的目录结构、依赖版本、业务背景写进全局记忆。这些内容应该放在对应项目的AGENTS.md或项目说明文件里。十八、用Skills封装重复流程Skills是视频后段的重要内容。它适合处理重复任务例如网页修改、代码整理、文档生成、项目检查、测试辅助。与其每次都把流程重新说一遍不如把稳定流程封装成Skill。Skills页面强调“让Codex按你的方式工作”。这里适合挑选和当前任务相关的能力而不是盲目安装一堆。选择Skill后最好先用低风险任务测试。例如让它生成文档草稿、整理项目结构、输出检查清单而不是一开始就让它批量修改代码。十九、安装Skills有多种方式视频中出现“三种方法”的章节画面用来说明安装或接入Skills不止一种路径。虽然部分细节小字无法确认但可以确定后续围绕网页端、本地项目和工具配置展开。这类章节分隔图适合提醒读者不要只记一个入口。不同场景下Skills可以通过网页端、桌面端项目、配置文件或其他工具链接入。建议先从最简单的方式开始。如果只是个人使用优先用界面提供的安装入口如果要和项目规则结合再考虑放入本地项目或配置文件中。本地路径选择的画面和第四节Select Project Root属于同一张图本版不重复插入。这里直接说明原则选择本地项目时必须确认选中的是项目根目录而不是某个子目录。二十、通过MCP接入外部服务视频后段进入MCP服务器设置页面。MCP的作用是让Codex可以连接外部工具或服务比如数据库、浏览器、部署平台、内部接口等。画面中出现MCP服务器设置页后续还涉及复制URL和外部服务连接。由于配置字段较小具体参数需要以实际界面为准。配置MCP时要特别注意权限和数据范围。如果连接数据库、生产系统或外部服务不要直接给高权限账号。建议先使用测试环境、只读权限或临时凭据。二十一、部署后要回到页面验证结果视频中将Pet Spa项目部署到网页后回到页面进行验证。能看到泡泡爪 Pet Spa页面、预约表单和右下角弹出提示。这一步说明项目已经从本地修改进入部署验证阶段。部署后的验证不能只看平台提示成功还要打开页面确认内容是否符合预期。尤其是表单、地图、门店信息、图片资源和按钮跳转都要实际查看。如果是静态网站常见问题包括路径错误、资源丢失、表单不可用、地图不显示、路由刷新后 404。验证时要按用户路径操作一遍不要只停在首页。二十二、用Netlify做静态网站托管部署环节后视频进入Netlify相关页面。Netlify适合快速部署静态网页常用于前端项目预览、演示站点和轻量业务页面。对Codex生成的网页项目来说Netlify可以作为快速验证出口。页面部署成功后能通过线上地址检查真实效果。建议把部署验证写进项目流程。例如让Codex修改页面后先本地运行再推送分支最后部署预览。每一步都要有对应验证结果。二十三、安装Computer Use扩展浏览器能力视频后段进入Computer Use插件安装页面。它的作用更接近扩展Codex或自动化工具对浏览器、页面和系统界面的操作能力。画面显示安装入口字幕提到安装computer use插件并让它完成某些浏览器相关任务。具体输出内容因为画面小字较多无法完整确认。这类扩展工具要谨慎授权。如果它可以读取网页、操作浏览器或发送内容就要确认权限范围避免把账号、公司系统、客户信息或隐私数据暴露给不受控流程。二十四、完整使用流程建议把这段教程整理成一套实际使用流程可以按下面顺序执行。先用Codex APP建立项目再通过任务对话完成修改中间用沙箱和权限控制风险完成后通过GitHub和部署平台验证结果最后把稳定经验写入AGENTS.md和Skills。认识 Codex 四种形态初始化 Codex APP创建项目文件夹选择项目根目录在项目中创建任务对话确认沙箱与权限边界用 Steer 人工引导任务方向让 Codex 修改真实项目页面结果验证使用 Git WorkTree 隔离分支通过 GitHub 检查并合并编写 AGENTS.md配置全局偏好安装 Skills按需接入 MCP部署并验证线上结果这套流程的重点不是把每一步都做复杂而是避免跳步。没有项目边界就不要急着改代码没有沙箱意识就不要提权没有本地验证就不要合并没有规则文件就不要期待长期稳定。二十五、总结Codex应该按项目工作流来用这段视频真正要讲的不是某个按钮在哪里而是Codex的使用方式要从“问答式”切换到“工作流式”。Codex APP负责桌面项目操作Codex CLI适合命令行流程网页端适合任务管理插件和MCP负责扩展外部能力。如果只是临时写一个函数普通对话就够了。但如果要修改真实项目就应该按项目、任务、权限、规则、技能、部署这条线来管理。这样做的好处是出问题时能追溯改动范围能控制重复流程能复用。下一次使用Codex时建议先问自己四个问题这个任务属于哪个项目是否需要沙箱外权限项目规则有没有写进AGENTS.md这类操作以后是否应该做成Skill能回答这四个问题Codex就不会只是一个聊天窗口而会变成一个更可控的项目工作流工具。点击回到顶部