Codex Full Course 2026：把 AI 编程工具当成 Agent 工作台使用

原视频链接：Codex Full Course 2026
YouTube URL：https://www.youtube.com/watch?v=KXIdYEdOPys

目录

• 一、核心结论：Codex 不只是聊天框
• 二、项目目录是工作流的中心
• 三、多聊天协作：一个聊天只负责一个产物
• 四、文件预览与自然语言迭代
• 五、Skill、Plugin 和 MCP：把能力封装起来
• 六、自动化适合做“草稿”，不要直接放飞
• 七、先搭最小闭环，再做效果
• 八、设计质量需要人类把关
• 九、一套可复用的 Codex 工作流
• 十、总结

一、核心结论：Codex 不只是聊天框

视频里最值得记住的一点是：Codex 的价值不只在“让模型回答问题”，而在于它把聊天、文件、项目、插件、技能、预览和自动化放到同一个工作流里。

传统聊天工具的中心是对话。你问一句，它答一句。结果主要停留在聊天历史里。

Codex 的中心更接近一个本地项目目录。每个聊天都可以绑定一个文件夹，Agent 可以在里面创建文档、表格、网页、App、PPT、视频工程，甚至继续读取和修改这些真实文件。

这会改变使用方式：

• 不是让 Agent “给我一个答案”，而是让它产出一个可以打开、检查、迭代的文件。
• 不是把所有需求塞进一个聊天，而是让多个聊天分别负责不同产物。
• 不是一次性提示词结束任务，而是用计划文件、预览、截图和验证结果持续纠偏。

所以，Codex 更像是一个 Agent-native 的工作台，而不是一个更强的聊天窗口。

二、项目目录是工作流的中心

视频建议先创建一个总目录，再为每个主题或产品创建独立项目。例如：

Codex Projects/
├── Codex Desktop Research/
├── My New Business/
└── Chorus/

每个项目目录下面可以有多个聊天。聊天本身不会作为文件存进目录，但 Agent 生成的文件会落在这个项目里。

这种组织方式很重要，因为它解决了三个问题。

第一，产物不会散落。Excel、Word、PPT、React 页面、Swift 工程、Remotion 视频，都可以在项目目录里找到。

第二，同一个项目里的聊天可以围绕同一批文件继续工作。比如先生成一个 codex desktop features.xlsx，再开一个新聊天，用 @文件名 引用它，让 Agent 检查是否遗漏了功能。

第三，项目目录天然适合长期迭代。即使某个聊天结束了，文件仍然在本地；即使项目从侧边栏移除，本地目录也没有消失。

我理解这里的关键不是“文件夹管理癖”，而是给 Agent 一个稳定边界。Agent 知道自己该在哪里读写，人也知道去哪里验收结果。

三、多聊天协作：一个聊天只负责一个产物

视频后半段最核心的方法论是多任务并行。

一个复杂产品不应该由一个聊天从头做到尾。更合理的方式是拆成多个相对独立的聊天：

Plan
Mobile Design
iOS App
Database / Supabase
Web Landing Page
Launch Video
Investor Deck
X Automation

每个聊天只负责一个明确产物。这样做有几个好处：

• 上下文更干净，不容易互相污染。
• 失败范围更小，一个视频任务失败不会影响数据库任务。
• 可以并行运行多个 Agent。
• 每个任务的验收标准更清楚。

视频中的 Chorus 示例就是这种模式：同一个产品，同时推进 iOS App、网页、投资人 Deck、发布视频和社交媒体自动化。人不再盯着一个 Agent 等结果，而是串行下发任务、并行回收产物。

这里有一个前提：每个任务提示词必须像一个完整任务包。它至少要包含目标、上下文、约束和验证方式。

例如，启动一个 iOS 项目时，不要一开始就要求完整 App，而是先让它创建最小可运行版本：

请创建一个名为 Chorus 的 Swift mobile app。
现在只需要在屏幕中央显示 "Hello, this is Chorus"。
不要做其他功能。完成后打开 Xcode 项目。

这类提示词的特点是范围小、验收明确、失败容易定位。

四、文件预览与自然语言迭代

Codex 的一个重要优势是文件预览。

Agent 生成 Excel、Word、PPT、网页或视频后，可以直接在右侧打开预览。然后继续用自然语言修改同一个文件。

比如表格工作流可以是：

1. 让 Codex 搜索某个主题。
2. 要求它把结果整理成 .xlsx。
3. 在预览里打开表格。
4. 发现某一列没用，再让它删除。
5. 继续要求补充来源、排序或改格式。

这和普通聊天最大的区别是：每一轮修改都落在真实文件上，而不是只停留在回答文本里。

同样的方法也适用于设计和视频。视频里经常用截图反馈问题，例如按钮重叠、动画方向错误、视频帧位置不对。对于 Remotion 这类视频工作流，反馈甚至可以精确到秒数、frame 和坐标：

在 3 秒位置，请镜头放大到 "Learning about skills" 这个组件，
然后转成全屏文档视图，展示 10 个热门技能。

鼠标点击位置错了。目标 toggle 大约在 x=1000, y=610，
而现在鼠标落在 x=1040, y=540。请修正。

这说明 Agent 交互不只靠文字。截图、坐标、帧数、草图和预览结果，都是上下文。

五、Skill、Plugin 和 MCP：把能力封装起来

视频里把 Skill、Plugin 和 MCP 放在一起讲。它们名字不同，但实践上可以统一理解为：让 Agent 获得新能力的方式。

一个实用区分是：

如果不清楚某个插件能做什么，视频里的方法很直接：直接问 Codex。

@Figma 请告诉我你可以用这个插件做哪些事情。
列出所有能力，并说明适合的使用场景。

这个方法比凭感觉猜接口更可靠。因为 Agent 可以先枚举工具能力，再把任务映射到合适工具。

视频中最有代表性的 Skill 例子是 YouTube Researcher。作者经常需要分析 YouTube 频道，于是把流程封装成技能：

1. 输入频道。
2. 拉取最新视频。
3. 获取 transcript、缩略图和表现数据。
4. 总结每个视频内容。
5. 分析哪些 hook 表现好。
6. 生成 Word 报告。

抽象成通用模式就是：

重复任务 -> 搜索可用 API -> 选择服务 -> 获取 API key -> 封装 Skill -> 新 session 测试 -> 接入自动化

这个思路很适合自己的日常工作。只要某个任务每周、每月重复出现，就值得考虑封装。

六、自动化适合做“草稿”，不要直接放飞

视频里有两个很典型的自动化场景。

第一个是 Calendar + Gmail：每周五下午汇总本周日历事件，并通过邮件发给自己。

第二个是 Typefully：每天研究并生成 3 条 X / Twitter 草稿。

我觉得后者更能体现安全边界。社交媒体内容不适合一开始就自动发布，更适合先生成 draft。这样 Agent 负责收集、整理和初稿，人保留最后审核权。

比较稳妥的自动化原则是：

• 初期只生成草稿，不直接发布。
• 第一次必须用明显测试内容验证链路。
• 涉及 API key 时不要录屏展示。
• 密钥泄露后立即 rotate。
• 自动化运行后要检查真实后台，而不是只看 Codex 说完成。

自动化不是把人从流程中完全移除，而是把重复的准备工作交出去，把判断权留在人手里。

七、先搭最小闭环，再做效果

这期视频里所有复杂项目都有一个共同模式：先做最小闭环。

比如：

• App 先做 Hello World。
• 视频先做 test video。
• Web 先能提交表单。
• Deck 先生成初版。
• Skill 先测试 API。
• 数据库先确认表和数据真实存在。

这个顺序比“直接做最终效果”稳定得多。

以 Landing Page 为例，作者没有让 Codex 从零实现完整表单系统，而是使用 Tally 收集 waitlist：

1. 在 Tally 创建表单。
2. 复制 embed code。
3. 让 Codex 创建 React 页面并嵌入表单。
4. 本地打开页面。
5. 输入测试邮箱提交。
6. 到 Tally 后台确认 submission 出现。

这里最关键的是最后一步。用户路径必须真实跑通，不能只看页面长得像。

同样，Supabase 数据库也不能只看 App 里出现了内容，还要去 Table Editor 检查表、字段和写入数据是否真实存在。

Agent 可以生成很多东西，但“是否真的工作”仍然要靠验证闭环。

八、设计质量需要人类把关

视频里也有一个现实判断：Codex 很适合项目编排、文件操作、多任务推进和工程实现，但默认设计质量不一定总是最好。

常见问题包括：

• 组件重叠。
• 背景渐变过重。
• PPT 文字太多。
• Landing Page 视觉不够克制。
• 视频转场节奏不自然。

解决方式不是期待一次提示词变完美，而是给更具体的反馈。比如提供截图、圈出问题、说明坐标、要求减少文字、保持风格一致。

视频中作者还会在 Codex 项目目录里运行 Claude Code，用它处理设计-heavy 的修改：

claude --dangerously-skip-permissions

这个命令本身有风险，只适合可信工作区。它体现的思路更重要：不必把所有事情都押在一个工具上。Codex 可以负责工作台和工程编排，其他模型或工具可以负责视觉 polish，最后再由人做验收。

九、一套可复用的 Codex 工作流

把整期视频压缩后，我认为最值得复用的是下面这套流程：

重复任务或产品想法
-> 创建项目目录
-> 写计划 Markdown
-> 拆成多个聊天
-> 每个聊天负责一个产物
-> 先做最小可运行版本
-> 打开真实文件或服务后台验证
-> 用截图/预览/日志继续反馈
-> 高频流程封装成 Skill
-> 稳定流程再做自动化

对应到日常使用，可以从一个很小的任务开始，而不是直接做完整产品。

例如：

• 每周论文阅读总结。
• 每月 YouTube 或博客内容复盘。
• 自动整理某个项目的 issue 和 PR。
• 从会议记录生成行动项。
• 把实验结果同步成报告。

先让 Agent 产出一个真实文件，再围绕文件迭代；先让自动化生成草稿，再由人审核。这比直接要求它“全自动完成一切”更稳。

十、总结

这期视频真正有价值的地方，不是展示 Codex 有多少功能，而是展示了一种新的工作组织方式。

在这种方式里，项目目录是中心，聊天是任务单元，文件是可验证结果，插件和技能是能力扩展，自动化是长期杠杆。

人类的角色也随之变化：不再是逐行执行者，而是任务拆解者、上下文提供者、约束制定者和最终验收者。

Codex 能提高效率，但前提是你给它清晰边界、可检查产物和真实验证。没有这些，Agent 只是更快地产生不确定输出；有了这些，它才更像一个能长期协作的工程工作台。