GPT88 / API Docs
ব্লগে ফিরে যান

Codex 从 0 到 1 全攻略：从第一次安装到完整工作流

开发工具2026-09-2322 মিনিট পড়ুনCodexOpenAIAI 编程AnnotateForkAGENTS.mdPlan ModePluginSkillAutomation

Codex 不只是一个“帮你补代码”的聊天窗口。它可以在项目上下文中读取文件、修改工作区、运行命令、查看差异、使用插件和 Skill，并把一次开发任务拆成可以继续、审查和复盘的工作流。

YouTube 视频《Codex 从 0 到 1 全攻略 - Annotate / Fork / Archive / Plan / Plugin / Skill / Automation / Mobile ......》由马克的技术工作坊发布，视频地址为原始视频，公开发布日期为 2026 年 6 月 7 日。公开视频简介给出的时间轴从安装和登录开始，依次讲到第一次做一个“马克笔记”、预览区域、Annotate、安全模式、模型配置、终端、Git、Fork、Archive、AGENTS.md、Plan Mode、多任务、Plugin、Skill、定时任务和 Mobile。

本文不是视频逐字稿。整理时可以核对到公开视频的标题、频道、发布日期和完整章节，但无法通过匿名公开接口稳定获取完整字幕。因此，本文以视频公开时间轴为骨架，并用官方 OpenAI 文档核对 Codex 的命令、权限和扩展概念；其中的选择建议、检查清单和工程化延伸属于本文编辑归纳，不代表视频作者的逐句原话。

一、先看结论：Codex 的价值在于把“写代码”变成可管理的任务

Codex 的完整使用路径可以抽象成：

安装与登录
  → 选择模型和权限
  → 让 Agent 了解项目
  → 先做一个最小任务
  → 预览、标注和修正
  → 用 Git、Fork 和 Archive 管理过程
  → 用 Plan Mode 和多任务处理复杂工作
  → 用 Plugin、Skill 和 Automation 扩展能力
  → 在 Mobile 上查看、继续或跟进任务

这条路径对应的不是功能清单，而是开发者逐步获得控制权的过程：

阶段主要问题需要留下的证据
安装登录Codex 能不能正常运行版本、账号、项目目录
第一次任务Agent 是否理解目标修改范围和验收结果
预览与 Annotate页面问题如何反馈标注位置、修改前后状态
权限设置Agent 可以做什么模式、审批和网络边界
Git 与会话修改如何隔离和恢复diff、分支、Fork、归档
Plan Mode复杂任务如何先拆解计划、依赖和检查点
Plugin 与 Skill能力如何复用插件来源、Skill 规则和权限
Automation 与 Mobile任务如何持续运行触发条件、结果和人工接管

如果只把 Codex 当成聊天框，往往会错过它最重要的能力：让任务过程变得可观察、可审查、可恢复。

二、从安装和登录开始：先确认工作面

视频的前两个章节是“下载并安装 Codex”和“Codex 登录与套餐选择”。第一次使用时，不要急着把复杂项目交给 Agent，先确认 Codex 运行在哪个环境、以什么身份运行，以及它能访问哪些文件。

1. 先确认运行形态

Codex 可能运行在不同的执行面：

  • 桌面应用：适合同时查看文件、预览、任务和会话；
  • CLI：适合终端工作流、脚本和仓库操作；
  • IDE 扩展：适合结合当前打开的文件和编辑器上下文；
  • Cloud 或远程执行环境：适合隔离任务，但与本地文件和凭证的边界不同；
  • Mobile：适合查看状态、跟进任务和处理轻量交互，具体能力取决于当前产品和账号环境。

不同形态并不意味着权限相同。开始工作前应该明确：

  1. 当前任务是在本地工作区还是隔离环境中执行；
  2. Agent 能否修改本地文件；
  3. Agent 能否访问网络；
  4. 外部插件或连接器是否会读取、写入第三方系统；
  5. 会话和任务结果保存在哪里。

2. 登录和套餐不是同一个问题

登录解决“你是谁”和“使用哪个账号”，套餐或工作区权限解决“你可以使用什么资源”。不要因为成功登录，就默认所有模型、插件、Mobile 能力或自动化入口都可用。

实际使用中要分别确认：

  • 当前登录方式；
  • 当前工作区或个人账号；
  • 可选择的模型；
  • 使用额度和速率限制；
  • Plugin、Skill、Automation 或 Computer Use 是否受工作区策略限制；
  • 本地项目是否需要显式信任。

这些信息可能随平台、地区、账号类型和产品 rollout 变化，文章不把某个视频页面中的套餐选择写成永久的价格或可用性承诺。

三、用一个小项目完成第一次任务

视频使用“马克笔记”作为第一版实践对象。这个选择很适合入门：它有清晰的输入和输出，又足够直观，能够让使用者看到 Codex 如何从需求进入实际产品实现。

1. 第一个任务应该足够小

第一次不要从“做一个完整 SaaS”开始。更适合的目标是：

  • 一个可以启动的页面；
  • 一个能够新增、编辑和删除的最小功能；
  • 一个只包含核心字段的表单；
  • 一个可以从输入走到结果的端到端路径。

任务描述应该包含四个字段：

目标：要完成什么
范围：允许修改哪些文件或模块
约束：不能改变什么
验收：如何确认已经完成

例如：

实现一个本地马克笔记页面。
用户可以创建标题和正文，保存后能在列表中看到，并能打开详情。
只实现本地数据，不接入账号和云端同步。
完成后运行项目并验证新增、查看和刷新三个动作。

2. 先让 Codex 解释项目，再让它修改

在已有仓库中，第一条任务可以是只读调查：

先不要修改文件。请说明项目入口、启动命令、主要页面、数据层和测试命令，并指出实现这个功能最可能涉及的文件。

这样做有两个好处：

  • 能检查 Agent 是否真的理解了项目；
  • 能在修改前发现它是否把错误目录、旧组件或生成文件当成了目标。

如果第一轮总结已经出现明显偏差，应该先修正上下文，而不是让 Agent 带着错误理解继续写代码。

四、预览区域与 Annotate：把“感觉不对”变成可执行反馈

视频接着演示预览区域和 Annotate。对网页产品来说，这两个能力的重要性在于：开发者可以直接针对页面结果反馈，而不必把视觉问题重新翻译成一长段文字。

1. 预览不是最终验收

预览区域适合快速发现：

  • 布局是否符合预期；
  • 文案是否出现在正确位置；
  • 交互入口是否可见；
  • 移动端是否出现溢出；
  • 加载、空状态和错误状态是否缺失；
  • 页面是否看起来像一个可以使用的产品。

但预览不能代替完整验证。页面看起来正常，不代表：

  • 数据保存正确；
  • 刷新后状态仍然存在；
  • 错误输入能被处理；
  • 权限边界没有被绕过；
  • 构建和测试能通过；
  • 生产环境的外部服务可以正常工作。

更完整的验证顺序是：

预览视觉结果
  → 点击核心路径
  → 检查边界和失败状态
  → 运行测试与构建
  → 查看 diff 和生成文件

2. Annotate 反馈应该指向位置和动作

不要只写“这里不好看”。更有效的标注包含三个部分：

  1. 位置：哪个组件、区域或元素；
  2. 问题：当前结果和预期差异；
  3. 动作：希望如何修改，以及不应影响什么。

例如：

这个保存按钮在窄屏上被挤到第二行。
请保持按钮文字不换行，并让输入区域在 390px 宽度下仍然可用。
不要改变桌面端的按钮顺序。

这种反馈比“把移动端优化一下”更容易让 Agent 产生局部、可审查的修改。

3. 标注后要检查改动范围

视觉反馈很容易造成 CSS 级联影响。每次 Annotate 后都应该查看：

  • 修改了哪些组件和样式文件；
  • 是否影响了其他页面；
  • 是否引入了新的固定尺寸；
  • 是否破坏了无障碍属性或键盘操作；
  • 是否需要补充移动端和桌面端的验证。

Annotate 的价值是缩短反馈回路，而不是跳过代码审查。

五、安全限制和三种安全模式：权限决定 Agent 的风险半径

视频在 08:18 讲到预览区域的安全限制，随后介绍三种安全模式。这里最重要的理解是：安全模式不是“模型聪不聪明”，而是限制 Agent 能对环境做什么。

1. 把权限拆成两个问题

Codex 的安全控制可以拆为两层：

  • Sandbox：技术上允许 Agent 读、写、联网和运行什么；
  • Approval：什么时候必须先询问人类。

一个任务即使模型能力很强，如果权限过宽，也可能扩大错误的影响范围。因此应该先按风险选择权限，再按任务选择模型。

2. 三类使用模式

不同版本的 UI 命名可能变化，但可以用三种风险等级理解：

模式适合场景典型边界
只读 / 规划阅读仓库、分析问题、写方案不修改文件，不执行高风险写入
工作区自动修改常规开发和测试允许修改当前工作区，外部副作用仍需确认
更高权限执行明确授权的复杂任务需要更严格的范围、日志和人工监督

新项目建议从只读或工作区范围开始。只有当任务明确需要更高权限时，才逐步放开，并且每次都记录原因。

3. 预览区域也有安全边界

浏览器预览或 Computer Use 类能力可能触及真实网站、登录状态、文件上传、网络请求和本地应用。不要因为一个动作看起来只是“点击按钮”，就忽略它可能带来的外部副作用。

以下操作应该默认进入人工确认：

  • 发送消息或提交表单；
  • 删除数据；
  • 修改生产配置；
  • 发布内容或部署应用；
  • 上传含有隐私或密钥的文件；
  • 购买、支付或改变订阅；
  • 修改权限和账号设置。

六、模型配置、内置终端和消息编辑

视频在 12:17 开始讲模型配置，随后介绍内置终端和编辑消息。这几个功能共同解决的是“如何让 Codex 在合适的地方工作”。

1. 模型选择应该跟任务匹配

选择模型时，至少考虑：

  • 任务是否需要长上下文；
  • 是否需要复杂推理或多步规划；
  • 是否只是快速修改文案、样式或小函数；
  • 延迟和成本是否重要；
  • 是否需要视觉、工具或插件能力；
  • 失败一次的代价有多大。

可以用一个简单的分层：

探索与定位：快速模型
局部实现：均衡模型
架构设计、复杂调试和最终审查：更强推理模型

不要把“更强模型”当作所有任务的默认答案。任务边界、上下文质量和验证方式，往往比模型名称本身更影响结果。

2. 内置终端是验证闭环的一部分

终端不只是让 Agent 运行命令的地方，也是开发者确认事实的入口。建议让 Codex 在每个阶段留下：

  • 实际执行的命令；
  • 命令返回结果；
  • 通过或失败的测试；
  • 生成的文件和路径；
  • 未解决的问题。

尤其不要只根据 Agent 的自然语言说“已经完成”来判断结果。真正的完成证据应该来自运行结果、diff、构建产物或可复现的页面操作。

3. 编辑消息比不断追加解释更可靠

需求发生变化时，可以编辑原任务中的约束和验收条件，而不是在几十条消息后继续叠加互相冲突的指令。

适合编辑消息的场景：

  • 需求范围已经变化；
  • 发现原来的验收条件不完整；
  • 之前的假设被代码事实推翻；
  • 不希望 Agent 继续执行上一版计划。

编辑后应该明确告诉 Codex：哪些旧要求仍然有效，哪些要求已经废弃。这样可以减少模型同时遵循多个版本需求的风险。

七、Git、Fork 和 Archive：把会话变成可恢复的工程资产

视频从 16:48 开始介绍 Codex 的 Git 功能，之后讲到 Fork 和会话归档。这一组能力非常适合用来管理探索性开发。

1. Git 是 Agent 工作的安全网

交给 Codex 之前，先确认工作区状态：

git status --short --branch
git diff --stat
git diff

如果工作区已经有用户修改，不要让 Agent 默认把它们当成自己的工作。任务提示中应明确：

  • 哪些修改是既有内容；
  • 哪些文件允许修改；
  • 是否可以创建新分支或 worktree；
  • 是否允许运行会修改生成文件的命令；
  • 交付时需要提供什么 diff 和验证结果。

2. Fork 适合并行探索，不代表自动合并

Fork 可以把当前会话分成不同方向，例如：

  • 一条路线探索产品方案；
  • 一条路线实现最小版本；
  • 一条路线审查安全和测试；
  • 一条路线比较不同技术选型。

但 Fork 只解决会话分支，不自动解决文件冲突、数据库状态、端口、外部账号和生产资源冲突。如果多个分支都要写同一个工作区，仍然需要 Git 分支或 worktree，并且由人类决定哪条结果合并。

3. Archive 和 Delete 不是一回事

归档的意义是从当前工作列表中移除会话，同时保留后续恢复和查看的可能。删除则是更强的清理动作，可能移除转录和后代会话。对重要任务，应该先归档，不要在没有确认的情况下删除。

推荐的会话命名方式：

项目名 / 目标 / 当前阶段

例如：

notes-app / mobile layout / verification

会话名称、分支名称、提交信息和最终报告统一后，后续查找会轻松很多。

八、AGENTS.md：把项目规则交给每一次任务复用

视频在 25:37 开始介绍 AGENTS.md。它的核心作用不是替代产品文档，而是给 Codex 提供与当前目录和代码工作直接相关的长期规则。

1. AGENTS.md 应该写什么

一份实用的项目规则文件通常包含：

  • 项目如何安装、启动、测试和构建；
  • 目录结构和重要入口；
  • 哪些文件允许修改；
  • 哪些文件由脚本生成；
  • 代码风格和命名约束；
  • 数据库、密钥和外部服务边界；
  • 提交前必须运行的检查；
  • 遇到不确定情况时应该停止并询问什么。

2. 规则应该短、近、可执行

不要把所有产品背景都塞进 AGENTS.md。更有效的结构是：

仓库根目录/AGENTS.md
  → 全局工程规则

子目录/AGENTS.md
  → 当前模块的局部规则

README / docs/
  → 产品背景、架构说明和完整使用文档

规则文件越接近当前任务，越应该具体。例如前端目录可以写组件约束，脚本目录可以写不可直接手改，数据库目录可以写迁移和回滚要求。

3. AGENTS.md 不等于安全策略

即使规则文件写着“不要执行生产操作”，也不能把它当成真正的权限控制。权限必须由沙箱、审批、账号权限和外部系统本身共同约束。

AGENTS.md 解决的是“Agent 应该如何工作”，不是“系统技术上绝对不允许什么”。

九、Plan Mode：先冻结路线，再开始写代码

视频在 29:32 进入 Plan Mode。复杂任务最容易失败的原因之一，是实现开始得太早：Agent 还没有读完项目，就已经开始改文件。

1. Plan Mode 适合什么任务

  • 跨多个模块的功能；
  • 需要数据库迁移的改动；
  • 需要多个外部服务的集成；
  • 可能影响现有用户流程的重构；
  • 用户需求还比较模糊的产品工作；
  • 需要并行拆分的长任务。

2. 一份可执行计划应该包含什么

目标
现状
方案
涉及文件
依赖和风险
验证命令
交付结果

计划不是越长越好。它应该帮助人类回答：

  • Agent 是否理解了真正的问题；
  • 是否遗漏了关键模块；
  • 是否要先做调查或原型；
  • 哪些步骤有外部副作用；
  • 哪些任务可以安全并行。

3. 计划通过后再执行

一个稳定的交互方式是：

  1. 先让 Codex 只读分析并提出计划；
  2. 人类修正目标、范围和风险；
  3. 明确批准实现；
  4. 按计划逐步修改和验证；
  5. 如果事实发生变化，回到计划阶段更新路线。

Plan Mode 的价值不是让 Agent 写一份漂亮的文档，而是把不可见假设提前暴露出来。

十、同时运行多个任务：并行的是独立工作，不是共享冲突

视频在 35:27 讲到同时运行多个任务。并行可以提高效率，但前提是任务之间的写入边界清晰。

1. 适合并行的任务

  • 一个 Agent 阅读后端，另一个阅读前端；
  • 一个 Agent 设计测试，另一个实现功能；
  • 一个 Agent 做只读调研，另一个处理独立文档；
  • 多个页面或互不相关的模块分别实现；
  • 一个 Agent 做审查，另一个等待审查结论后再修改。

2. 不适合直接并行的任务

  • 多个 Agent 同时修改同一个核心组件；
  • 多个 Agent 同时编辑同一份数据库迁移；
  • 多个 Agent 同时操作同一个线上账号；
  • 一个 Agent 依赖另一个 Agent 尚未确定的接口；
  • 多个 Agent 共用同一个会产生副作用的外部资源。

3. 为并行任务冻结接口

并行前至少确定：

  • 每个任务的文件所有权；
  • 输入和输出格式；
  • 不能触碰的目录；
  • 共享接口谁负责定义；
  • 哪个 Agent 或人类负责最终合并；
  • 出现冲突时停止还是继续。

并行的目标是减少等待，而不是把一个冲突任务复制成多个冲突任务。

十一、Plugin 与 Skill：扩展能力，但不要跳过审查

视频从 40:14 开始介绍 Plugin，之后演示 Presentations Plugin、Chrome Plugin、Computer Use Plugin、Image Gen Skill，以及自己编写 Skill。

1. Plugin 和 Skill 的区别

可以这样理解：

能力主要作用
Plugin打包可安装的工具、连接器、Skill、Hooks 或其他扩展能力
Skill针对特定任务的可复用指令、参考资料、脚本和模板
MCP / Connector让 Agent 访问外部系统或调用结构化工具
Hook在 Codex 生命周期特定节点执行的命令或检查

Skill 更像“怎么做这类任务”，Plugin 更像“把一组能力分发出去”。一个 Plugin 可以包含 Skill，但两者不是同一个概念。

2. Presentations、Chrome 和 Computer Use 要按副作用分类

视频里的几个插件示例说明了 Codex 可以从代码工作扩展到文件、浏览器、演示文稿和本地电脑操作。但能力范围越大，副作用也越大：

  • 生成 PPT 可能产生文件和外部媒体引用；
  • Chrome 操作可能使用登录态、填写表单或发送请求；
  • Computer Use 可能影响本地应用、文件和系统设置；
  • Image Gen 可能产生图片资产、费用和版权判断；
  • 外部连接器可能读取或修改第三方数据。

因此，安装扩展前至少审查：

  • 它来自哪里；
  • 它需要哪些工具和权限；
  • 是否包含可执行脚本或 Hooks；
  • 是否会联网；
  • 哪些动作会写入外部系统；
  • 是否支持撤销、dry-run 或人工审批。

3. 自己写 Skill 的最小结构

一个 Skill 不需要一开始就做得很复杂。可以从以下结构开始：

my-skill/
├── SKILL.md       # 名称、触发描述和工作步骤
├── scripts/       # 可选：可复现脚本
├── references/    # 可选：长文档和规则
└── assets/        # 可选：模板、图片或样例

SKILL.md 应该写清楚：

  • 什么时候使用这个 Skill；
  • 开始前需要检查什么；
  • 具体步骤是什么；
  • 哪些情况必须停止；
  • 如何验证结果；
  • 最终报告需要包含什么。

Skill 的触发描述要具体。与其写“帮助处理文件”，不如写“当用户要把一组 CSV 转换为带公式和格式的 Excel 报表时使用”。

十二、定时任务和 Automation：重复工作必须有边界

视频在 53:47 介绍定时任务。自动化适合重复、低风险、结果可检查的工作，例如定期生成报告、检查文档链接、汇总公开信息或运行健康检查。

1. 自动化提示词应该包含五个部分

触发时间
任务目标
允许读取的范围
禁止执行的动作
成功与失败的通知条件

不要只写“每天帮我处理一下”。更好的表达是：

每周一上午检查文档站的失效内部链接。
只读取仓库和构建产物，不修改生产文件，不提交或推送。
输出失效 URL、引用页面和建议修复位置；只有发现问题时通知我。

2. 自动化不应默认拥有生产写权限

定时任务最容易被忽略的风险是：它会在用户不在场时运行。默认应该：

  • 先只读；
  • 输出报告而不是直接修改；
  • 对外部写入使用人工审批；
  • 对每次运行保留日志；
  • 对重复执行设计幂等性；
  • 对失败设置明确的通知条件。

视频中的定时任务入口是产品能力演示，不代表所有账号、平台和工作区都具有完全相同的可用性。实际使用前应核对当前产品设置和工作区策略。

十三、Codex Mobile：移动端适合跟进，不等于替代完整开发环境

视频最后在 56:03 介绍 Codex Mobile。移动端的价值主要在于：

  • 查看任务状态；
  • 阅读 Agent 的结果和待处理问题；
  • 继续对话或补充要求；
  • 处理轻量的决策和反馈；
  • 在不方便打开电脑时跟进长任务。

但复杂代码实现、视觉调试、终端排错、权限确认和最终发布，通常仍然更适合在完整桌面或终端环境中完成。

建议把 Mobile 当成任务控制面：

桌面 / CLI：实现、测试、审查
Mobile：查看状态、补充上下文、批准下一步、处理通知

在移动端继续任务时，应优先读取当前状态、最近 diff、失败命令和待确认事项，不要在缺乏工作区上下文时直接要求 Agent 做大范围修改。

十四、一套可直接复用的 Codex 工作流

第一步：初始化项目上下文

请先只读检查这个项目。
告诉我启动、测试和构建命令，列出核心目录和当前 Git 状态。
不要修改文件，也不要执行外部写入。

第二步：冻结任务范围

目标：实现一个最小可用的笔记创建和查看流程。
允许修改：src/notes/ 和对应测试文件。
禁止修改：依赖、部署配置和其他业务模块。
验收：创建、列表查看、详情查看和刷新后状态都可验证。

第三步：先计划，再执行

让 Codex 列出涉及文件、数据流、失败状态和验证命令。人类确认后再开始写入。

第四步：分阶段实现

先完成页面骨架
  → 验证启动和空状态
  → 接入本地数据
  → 验证新增和详情
  → 补充错误处理
  → 运行测试和构建

第五步：用预览和 Annotate 修正体验

针对具体位置反馈，不用大范围描述；每次反馈后查看 diff，并重新验证桌面和移动宽度。

第六步：交付前回读证据

最终报告至少包含：

  • 修改文件；
  • 运行过的命令；
  • 通过或失败的结果；
  • 未完成事项；
  • 需要人工确认的风险；
  • 是否可以提交或推送。

十五、Codex 入门检查清单

安装和第一次运行

  • 已确认当前登录账号和工作区；
  • 已确认模型、额度和插件可用性；
  • 已确认项目目录和当前 Git 状态；
  • 已知道如何启动、测试和构建项目；
  • 第一个任务范围足够小。

权限和安全

  • 已区分 Sandbox 和 Approval；
  • 默认只开放当前工作区；
  • 网络、外部写入和敏感文件有明确边界；
  • Browser、Computer Use 和 Connector 动作需要人工确认；
  • 没有把 AGENTS.md 当作真正的权限控制。

开发和会话管理

  • 复杂任务先使用 Plan Mode；
  • 并行任务有清晰文件所有权；
  • 每轮完成后查看 diff 和测试结果；
  • 重要任务使用有意义的会话名称；
  • 使用 Fork 探索不同方向，使用 Archive 保存历史，不随意删除。

扩展和自动化

  • 安装 Plugin 前审查来源、权限和 Hooks；
  • Skill 写清触发条件、步骤和验证；
  • Automation 默认只读并支持人工接管；
  • 移动端主要用于跟进和决策，不直接承担复杂发布。

最后：Codex 的学习曲线是从功能熟悉走向边界设计

这个视频的章节很多，但可以收敛成三层能力：

  1. 会用功能：安装、预览、Annotate、Git、Fork、Archive、Plan、Plugin、Skill 和 Mobile；
  2. 会组织任务：知道什么时候先调查、什么时候计划、什么时候并行、什么时候回滚；
  3. 会设计边界：明确权限、外部副作用、自动化范围和最终验收。

第一层让你开始使用 Codex，第二层让你提高效率，第三层才决定你能不能把 Codex 用在真实项目里而不失控。

Codex 最好的工作方式不是让 Agent 无限自主，而是把目标、上下文、权限、反馈和验证组织成一个可重复闭环。

来源与边界

原始视频：Codex 从 0 到 1 全攻略 - Annotate / Fork / Archive / Plan / Plugin / Skill / Automation / Mobile ......，频道为马克的技术工作坊，公开发布日期为 2026 年 6 月 7 日。

公开视频简介公开列出以下时间轴：00:00 视频内容介绍、01:01 下载并安装 Codex、01:25 Codex 登录与套餐选择、03:27 实现第一版马克笔记、06:05 预览区域的使用、06:39 Annotate、08:18 预览区域的安全限制、10:06 三种安全模式、12:17 模型配置、13:50 使用内置终端、14:54 编辑消息、16:48 使用 Codex 的 Git 功能、18:22 Fork、24:43 会话归档、25:37 AGENTS.md、29:32 Plan Mode、35:27 同时运行多个任务、40:14 Plugin 简介、42:37 使用 Presentations Plugin 做 PPT、44:30 使用 Chrome Plugin 操作浏览器、46:52 使用 Computer Use Plugin 操作电脑、49:37 使用 Image Gen Skill 生成图片、52:42 自己写一个 Skill、53:47 定时任务、56:03 Codex Mobile。

官方边界参考：Codex 内置命令。本文关于 /plan、/fork、/archive、/init、/skills、/plugins 和 /permissions 的说明，按官方命令文档核对；产品界面、套餐、模型和功能可用性仍可能因账号、平台、地区、工作区和 rollout 不同而变化。

本文是基于公开视频页可见标题、频道、发布日期和时间轴的结构化整理，不是视频逐字稿。由于完整字幕在整理时无法通过匿名公开接口稳定取得，文中的工作流、检查清单和工程化建议属于编辑归纳；视频中的具体演示、原话和实际操作请以原视频为准。

সম্পর্কিত গাইড

我的 AI 编程全流程：从 Agent 选择到高质量产品交付