展开可复制文字
第三篇:核心功能详解
自动化
什么是自动化
Codex 自动化 = 让 Codex 不只是“听你指挥”,而是能按规则定期帮你巡查项目、发现问题、处理问题。
就像你给项目请了一个“AI 值班工程师”:
平时它不打扰你, 有问题它来提醒你, 简单问题它先尝试修, 最后让你审核决定。
如何使用自动化
可以用“每周 Codex 会话自动复盘”举例,让 Codex 越来越好用。
你可以让 Codex 定期检查最近一段时间的会话记录、任务结果和常⻅问题,沉淀成一份可复用的工作流档
案。
示例提示词可以这样写:
请检索并复盘最近一周的 Codex 会话记录与执行日志,维护一份 “Codex 会话复盘与个人⻛格档案 ” 。
要求:
1. 优先使用可用的会话历史检索能力;如果需要读取日志,只做搜索、元数据提取和相关片段抽取,不要整文件载入大型
session 文件。
2. 不要复现原始日志、隐私内容、密钥、内部 reasoning 或⻓对话原文。
3. 总结执行经验:哪些做法导致了问题,最终正确做法是什么,适合什么场景复用。
4. 总结我的偏好: UI 设计偏好、产品理念、交互原则、内容系统偏好和工作流偏好。
5. 整理可复用规则清单:把复盘结论改写成后续 Codex 会话可以遵循的简洁规则。
6. 更新文档时去重、合并相近规则,保留日期范围或任务类型作为来源线索。
7. 如有适合⻓期复用的规则,请建议是否加入项目级或用户级 AGENTS.md 。
展开可复制文字
什么是插件
Codex 本身已经能读代码、改代码、运行命令;插件是在这个基础上,让它连接更多工具、使用固定流程,
或者获得某些专项能力。
比如:
插件类型 能让 Codex 做什么
Chrome 插件 打开网⻚、检查⻚面、配合浏览器调试
Gmail 插件 总结邮件、草拟回复
Google Drive 插件 读取文档、表格、幻灯片
Slack 插件 总结频道消息、草拟团队回复
Security 插件 检查代码安全问题
Computer U se 插件 操作电脑上的应用
插件、Skill、MCP 三者关系(先看这一张表)
插件、Skill、MCP 是本篇最容易混淆的三个概念。它们不是互相替代,而是各管一层,下面这张总表请先记
住,后面各节不再重复对比。
对比 插件 Plugin Skill MCP
一句话 能力安装包 一套固定工作方法 连接外部工具的接口
解决什么问
题
安装、打包、分发能力 同类任务「怎么做」 「连接什么工具或数据」
范围 最大,可打包 Skill、M CP
等
较小,单类任务的流程 单个外部工具或数据源的连
接
类比 工具箱 工具箱里的说明书 给工具箱接电的插座
谁来用 普通用户也能一键安装 普通用户也能用 更偏开发者和团队配置
举例 GitHub 插件、Figma 插件 READM E Skill、代码 Review
Skill
数据库 M CP、文档 M CP
一句话记住:插件可以把 Skill 和 MCP 打包成更容易安装的能力包;Skill 管「怎么做」,MCP 管「连什么
工具」。
展开可复制文字
在 Codex App 里怎么安装插件
打开 Codex App
搜索或浏览插件
也可以搜索对应的插件
展开可复制文字
点开插件详情
点击 Add to Codex 或添加按钮
展开可复制文字
安装完成后,新开一个 thread 使用
在 Codex CL I 里怎么安装插件
进入项目目录后,先启动 Codex:
codex
然后在 Codex CLI 里输入:
/plugins
打开插件列表后,可以:
操作 说明
搜索插件 找你需要的插件
查看详情 看插件能做什么、需要什么权限
Install plugin 安装插件
U ninstall plugin 卸载插件
Space 对已安装插件启用或停用
展开可复制文字
常⻅插件和能力方向
插件目录会随着 Codex 版本、工作区和账号权限变化。下面不是固定排名,而是常⻅能力方向,实际可安装
内容以你当前 Codex 插件⻚显示为准。
类型 包含插件 适合做什么
浏览器与电脑操作 Chrome、Computer U se 网⻚测试、自动点击、软件操作
代码与项目协作 GitHub 管理仓库、修 bug、创建 PR
前端与设计 Build W eb Apps、Figma 生成网⻚、设计稿转代码
办公交付 Documents、Presentations、Spreadsheets 文档、PPT、表格分析
视频生成 HyperFrames、Remotion 用代码或 HTM L 生成视频
序号 插件 / 能力 主要作用 简单来说
1 Chrome 让 Codex 直接操作浏览器 可以打开网⻚、点击按钮、检查⻚面效果、测试网⻚功能
2 GitHub 代码仓库管理与协作 让 Codex 读取仓库、处理 issue、改代码、创建 PR
3 Computer U se 让 Codex 操作电脑 像人一样看屏幕、点按钮、操作软件,权限比较高
4 Build W eb Apps 一句话生成前端网⻚应用 输入需求,生成网⻚、小工具、落地⻚、Demo
5 Figma 设计稿转代码与原型设计 把 Figma 设计稿变成前端⻚面,适合 U I 开发
6 Documents AI 帮你交付正式文档 生成 READM E、项目说明、教程文档、产品文档
7 Presentations AI 生成高质量 PPT 根据内容生成汇报、课程、产品介绍、方案型 PPT
8 Spreadsheets AI 数据分析与表格处理 帮你整理 Excel、分析数据、生成表格结论
9 HyperFrames HTM L 直接生成视频 用网⻚/HTM L 结构生成视频内容
10 Remotion 用代码生成高质量视频 用 React/代码方式生成更专业的视频
Skill
给 Codex 准备的一套「固定工作方法」。
Codex 本身会读代码、改代码、运行命令。
但如果你经常让它做同一类任务,比如写 README、做代码 Review、生成网⻚、整理文档,就可以把这套
流程做成 Skill。
什么是 Skill
概念 简单来说
Skill 一套固定工作方法
展开可复制文字
概念 简单来说
Prompt 这一次任务的提示词
W orkflow 做事流程
Template 固定模板
Instruction 给 Codex 的⻓期规则
Resource Skill 里附带的参考资料
Script Skill 里可选的自动化脚本
比如你每次都想让 Codex 写 READM E,并且 READM E 必须包含:
项目介绍
安装步骤
启动命令
文件结构
常⻅问题
那就可以做一个 READM E Skill。
以后你不用每次重新解释规则,只要调用这个 Skill,Codex 就会按这套流程写。
Skill 还是 MCP?什么时候用哪个
插件、Skill、MCP 的整体区别,⻅前面「插件、Skill、MCP 三者关系」总表。这里只解决最常⻅的纠结:
一个需求到底该用 Skill 还是 M CP。
记住一句话:「怎么做」的问题用 Skill,「连接什么工具」的问题用 MCP。
你的需求 用 Skill 还是 MCP
写 READM E、固定文档输出格式 Skill
做代码 Review、U I Review Skill
生成落地⻚、把修 bug 流程标准化 Skill
查最新开发文档、新版本 API M CP
连接数据库 M CP
读取 Figma 设计稿 M CP
读取 GitHub issue / PR M CP
连接 Notion、内部知识库、公司内部工具 M CP
展开可复制文字
Skill 和普通提示词有什么区别
只做一次的任务 = 直接写提示词 经常重复做的任务 = 适合做 Skill
对比维度 普通提示词 Skill
使用方式 每次手动输入 保存成固定能力
稳定性 容易漏要求 更稳定
适合场景 临时任务 重复任务
复用性 低 高
内容结构 一段提示词 指令、模板、资料、脚本
适合谁 所有人 经常重复做同类任务的人
Skill 适合什么时候用
情况 是否适合做 Skill
同一类任务经常重复做 适合
每次都要写一堆规则 适合
想让 Codex 输出更稳定 适合
团队里多人要用同一套流程 适合
一次性小任务 不一定需要
临时改一句文案 不需要
只是问一个概念 不需要
Skill 通常包含什么
内容 作用
instructions 告诉 Codex 怎么做
resources 放参考资料、模板、标准
scripts 可选脚本,用来自动处理任务
examples 示例输入和示例输出
checklist 检查清单,防止漏步骤
Skill 的基本结构
一个简单 Skill 可以这样写:
展开可复制文字
# Skill 名称
## 适用场景
这个 Skill 适合用来做什么。
## 工作目标
Codex 最终要交付什么结果。
## 工作流程
1. 先分析输入内容
2. 再确认任务类型
3. 然后按固定步骤处理
4. 最后输出结果和检查清单
## 输出格式
规定 Codex 最后应该怎么输出。
## 注意事项
哪些事情不能做,哪些⻛险要提醒。
比如 READM E Skill:
展开可复制文字
# README 生成 Skill
## 适用场景
用于根据当前项目生成 README 文档。
## 工作目标
输出一份结构清晰、适合新手阅读的 README 。
## 工作流程
1. 阅读项目结构
2. 查看 package.json 或主要入口文件
3. 判断项目类型
4. 生成项目介绍
5. 补充安装步骤和启动命令
6. 说明文件结构
7. 输出常⻅问题
## 输出格式
使用 Markdown 格式。
## 注意事项
不要编造不存在的功能。
不确定的地方要明确标注。
在 Codex App 里怎么添加 Skill
在 Codex App 里添加 Skill,可以分成两种情况:
1. 使用已有 Skill
2. 创建自己的 Skill
使用已有 Skill
在插件里面的技能可以看到系统推荐的一些Skill
展开可复制文字
创建自己的 Skill
如果你想自己创建一个 Skill,可以在 Codex App 的 thread 里使用:
$skill-creator
它相当于一个 Skill 创建助手,会帮你把一套重复流程整理成 Skill。
操作步骤:
步骤 操作
1 打开 Codex App
2 选择一个项目
3 新建一个 thread
4 输入 $skill-creator
5 告诉它你想创建什么 Skill
6 提供使用场景、规则、示例输出
7 让 Codex 生成 Skill 文件
8 检查生成结果
9 之后在新 thread 里使用这个 Skill
展开可复制文字
示例提示词:
$skill-creator
请帮我创建一个 README Skill 。
这个 Skill 的作用:
根据当前项目自动生成适合小白阅读的 README 。
触发场景:
当我说 “ 生成 README”“ 写项目说明 ”“ 整理项目文档 ” 时使用。
工作流程:
1. 先阅读项目结构
2. 查看 package.json 、 README 、入口文件
3. 判断项目类型
4. 生成项目简介
5. 写安装步骤
6. 写启动命令
7. 说明主要文件夹作用
8. 补充常⻅问题
9. 不确定的地方不要编造
输出格式:
使用 Markdown 。
必须包含:
- 项目简介
- 功能特点
- 安装步骤
- 启动命令
- 文件结构
- 常⻅问题
- 后续优化方向
展开可复制文字
推荐安装的 Skill
Skill / 项目 主要作用 GitHub 地址
Superpowers 给 Coding Agent 加一整套“软件开发方法论”:
先澄清需求、写规格、做实现计划,再按 TDD /
任务拆分推进开发。适合 Codex、Claude
Code、Cursor、Gemini CL I 等工程型 Agent。
https://github.com/obra/superpowers
skill-creator 创建 Skill 的辅助 Skill。Codex 内置或可用的
Skill 以你当前环境显示为准;不同来源的同名
Skill 可能实现不同。
以当前 Codex Skill 列表为准
baoyu-skills 宝玉整理的一组实用 Skills,偏内容创作和日常
效率:小红书图文、文章配图、漫画、公众号发
布、X/微博发布、网⻚转 M arkdown、YouTube
字幕、AI 生图等。仓库说明里写的是给 Claude
Code、Codex 等 AI Agents 提效用,并建议按
需安装。
https://github.com/JimL iu/baoyu-skills
Agent Reach 给 Agent 装“联网能力”:读网⻚、YouTube、
RSS、GitHub、Twitter/X、B站、Reddit、小红
书、L inkedIn 等,还带诊断和多后端路由。简单
说就是让本地 Agent 能更方便地搜网、读平台内
容。
https://github.com/Panniantong/Agent-
Reach
find-skills “找 Skill 的 Skill”。当你问“有没有某某功能的
Skill”时,它会帮你搜索、发现、安装 Agent
Skills;底层配合 npx skills find / add / check /
update 使用。
https://github.com/vercel-
labs/skills/tree/main/skills/find-skills
在 Codex CL I 里怎么添加 Skill
在 Codex CLI 里添加 Skill,主要有 3 种方式:
1. 使用已有 Skill
2. 用 $skill-creator 创建 Skill
3. 手动创建 SKILL.md 文件
添加 Skill 的 3 种方式
方式 适合谁 简单来说 推荐程度
使用已有 Skill 刚入⻔用户 直接调用现成技能 推荐
$skill-creator 创建 想把提示词变成 Skill 的人 让 Codex 帮你整理 Skill 最推荐
手动创建 SKILL.md 熟悉文件结构的人 自己写 Skill 文件 进阶
展开可复制文字
方式一:使用已有 Skill
进入项目目录后,先启动 Codex CLI:
cd 项目目录
codex
进入 Codex CLI 后,可以输入:
/skills
或者直接输入:
$
Codex 会显示当前可用的 Skill。
如果你已经知道 Skill 名称,也可以直接在任务里点名使用:
请使用 $readme-skill ,根据当前项目生成 README 。
或者:
$ui-review-skill 请检查当前首⻚的视觉问题,并给出修改建议。
已有 Skill 的使用方式
用法 示例 适合场景
/skills 打开 Skill 列表 不知道有哪些 Skill 时
输入 $ 快速选择 Skill 想快速调用时
$skill-name $readme-skill 明确知道 Skill 名称时
自然语言描述 请用 READM E Skill 写项目说明 不确定具体名称时
方式二:用 $skill-creator 创建 Skill
如果你想把一套重复流程保存成 Skill,可以用:
$skill-creator
它相当于一个 Skill 创建助手,会问你:
展开可复制文字
问题 目的
这个 Skill 是做什么的 明确用途
什么时候触发 写清楚适用场景
要不要包含脚本 判断是否只是指令型 Skill
输出格式是什么 保证结果稳定
有哪些限制 避免乱改、乱编、乱执行
$skill-creator 使用流程
步骤 操作 目的
1 进入项目目录 确保 Skill 生成在正确项目里
2 运行 codex 打开 Codex CL I
3 输入 $skill-creator 启动 Skill 创建助手
4 描述 Skill 用途 告诉它要做什么
5 补充触发场景 告诉它什么时候用
6 补充工作流程 固定 Codex 的执行步骤
7 补充输出格式 保证结果稳定
8 检查生成结果 确认 SKILL.md 是否合理
9 重新打开或继续使用 测试 Skill 是否生效
展开可复制文字
$skill-creator 示例提示词
$skill-creator
请帮我创建一个 README Skill 。
这个 Skill 的作用:
根据当前项目自动生成一份适合小白阅读的 README 。
触发场景:
当我说 “ 生成 README”“ 写项目说明 ”“ 整理项目文档 ”“ 写安装教程 ” 时使用。
工作流程:
1. 先阅读项目结构
2. 查看 package.json 、 README 、入口文件
3. 判断项目类型
4. 生成项目简介
5. 写安装步骤
6. 写启动命令
7. 说明主要文件夹作用
8. 补充常⻅问题
9. 不确定的地方不要编造
输出格式:
使用 Markdown 。
必须包含:
- 项目简介
- 功能特点
- 安装步骤
- 启动命令
- 文件结构
- 常⻅问题
- 后续优化方向
注意事项:
不要编造不存在的功能。
不要读取或输出 API Key 、密码、 token 、私钥。
展开可复制文字
方式三:手动创建 Skill 文件
Skill 本质上是一个文件夹,里面必须有一个:
SKILL.md
最简单的结构是:
.agents
└── skills
└── readme-skill
└── SKILL.md
也可以放脚本、参考资料和资源文件:
.agents
└── skills
└── readme-skill
├── SKILL.md
├── scripts
├── references
└── assets
Skill 文件结构说明
文件 / 文件夹 是否必须 作用
SKILL.md 必须 写 Skill 的名称、描述和具体指令
scripts/ 可选 放可执行脚本
references/ 可选 放参考文档、标准、说明
assets/ 可选 放模板、图片、资源文件
展开可复制文字
一个最简单的 SKILL.md 示例
---
name: readme-skill
description: 当用户需要生成 README 、项目说明、安装教程、启动步骤时使用。
---
你是一个 README 文档生成助手。
任务:
根据当前项目生成一份适合新手阅读的 README 。
工作流程:
1. 阅读项目结构
2. 查看 package.json 、 README 、入口文件
3. 判断项目类型
4. 生成项目介绍
5. 写安装步骤
6. 写启动命令
7. 说明文件结构
8. 补充常⻅问题
9. 不确定的地方不要编造
输出格式:
使用 Markdown 。
必须包含:
- 项目简介
- 功能特点
- 安装步骤
- 启动命令
- 文件结构
- 常⻅问题
- 后续优化方向
添加 Skill 后怎么使用
添加 Skill 后,有两种常⻅用法:
用法 示例
明确指定 Skill 请使用 $readme-skill 生成 READM E
展开可复制文字
用法 示例
让 Codex 自动判断 帮我写一份项目 READM E
如果 Skill 的 description 写得清楚,Codex 会更容易自动判断什么时候该用它。
比如:
description: 当用户需要生成 README 、项目说明、安装教程、启动步骤时使用。
这个描述就很清楚。
不建议写得太模糊:
description: 帮我写东⻄。
这样 Codex 不知道什么时候该调用它。
Skill 放在哪里更合适
放置位置 适合场景 简单来说
项目里的 .agents/skills 只给当前项目用 项目专属 Skill
用户级 Skill 目录 自己多个项目都想用 个人通用 Skill
团队 / 管理员配置 团队成员统一使用 团队共享 Skill
插件里 想打包分发给别人安装 正式能力包
MCP
只有进阶AI编程才需要了解,普通人可以直接跳过
让 Codex 连接外部工具的接口。
Codex 本身可以读代码、改代码、运行命令。
M CP 的作用是让 Codex 连接更多外部工具、数据源或服务。
什么是 MCP
概念 简单来说
M CP 连接外部工具的标准接口
M CP Server 提供工具能力的服务
Tool Codex 可以调用的具体功能
展开可复制文字
概念 简单来说
Config M CP 的配置文件
STDIO Server 通过本地命令启动的 M CP 服务
HTTP Server 通过网址连接的 M CP 服务
Context 外部工具提供给 Codex 的上下文信息
生活化理解:
Codex = 一个会干活的人
MCP = 给他接上不同工具的插座
MCP Server = 插在插座上的工具箱
Tool = 工具箱里的具体工具
比如一个文档 M CP,可以让 Codex 读取文档。
一个数据库 M CP,可以让 Codex 查询数据库。
一个设计工具 M CP,可以让 Codex 获取设计稿信息。
MCP 适合做什么
场景 MCP 可以怎么用
查开发文档 连接文档 M CP,让 Codex 查新版本 API
连接数据库 让 Codex 查询数据库结构或测试数据
连接设计工具 让 Codex 读取设计稿、组件信息
连接项目管理工具 读取 issue、任务、需求说明
连接内部系统 调用公司内部工具或数据源
连接知识库 让 Codex 根据团队文档工作
连接自动化工具 让 Codex 调用额外脚本或服务
小白可以这样判断:
普通写代码,不一定需要 MCP 。
需要 Codex 访问外部工具或外部数据时,才考虑 MCP 。
MCP Server 是什么
M CP Server 可以理解成:
展开可复制文字
给 Codex 提供工具能力的服务。
比如:
MCP Server 类型 能提供什么
文档 M CP 查询开发文档、API 文档
数据库 M CP 查询表结构、读取测试数据
GitHub M CP 读取 issue、PR、仓库信息
Figma M CP 读取设计稿信息
Notion M CP 读取知识库⻚面
浏览器 M CP 访问网⻚、获取⻚面信息
内部工具 M CP 连接公司自己的系统
简单来说:
MCP Server = Codex 可以调用的外部工具服务。
在 Codex App 里怎么使用 MCP
Codex App 使用 MCP 的基本流程
步骤 操作 简单来说
1 打开 Codex App 进入桌面版 Codex
2 进入 Settings 打开设置
3 找到 M CP servers 进入 M CP 工具管理区
4 查看 recommended servers 查看官方或系统推荐的 M CP
5 添加 custom server 添加自己的 M CP server
6 按提示完成授权 有些 M CP 需要登录外部账号
7 回到项目 thread 在任务里调用 M CP
8 查看结果和权限请求 确认 Codex 调用了什么工具
展开可复制文字
添加 MCP 时通常需要填什么
配置项 作用 简单来说
Name M CP 名称 给这个工具起名字
Command / U RL 启动命令或服务地址 Codex 通过它连接工具
Type M CP 类型 本地命令型或远程 HTTP 型
Env 环境变量 放 token、配置项等
Auth 授权方式 是否需要登录外部账号
Enabled tools 启用哪些工具 只打开需要的功能
展开可复制文字
添加 MCP 后怎么使用
添加完成后,回到 Codex App 的 thread,直接描述任务即可。
用法 示例
直接描述需求 请查一下 Next.js App Router 的最新用法
明确要求使用 M CP 请使用可用的 M CP 工具查询这个库的文档
指定某个 M CP 请用 context7 查询 Next.js 的最新文档
先查看可用工具 当前有哪些 M CP 工具可以用?
示例提示词:
请使用可用的 MCP 文档工具,
查询 Next.js App Router 的最新用法,
然后告诉我当前项目应该怎么修改。
或者:
请用 Figma MCP 读取这个设计稿,
分析⻚面结构,并给我生成前端实现计划。
在 Codex CL I 里怎么使用 MCP
在 Codex CLI 里使用 M CP,可以理解成:
展开可复制文字
给终端版 Codex 接入外部工具。
比如:
文档 MCP :让 Codex 查询开发文档
GitHub MCP :让 Codex 读取 issue 、 PR 、仓库信息
Figma MCP :让 Codex 读取设计稿
数据库 MCP :让 Codex 查询数据库结构
小白可以这样理解:
Codex CLI = 终端里的 AI 编程助手
MCP = 给 Codex CLI 接外部工具的接口
CLI 使用 MCP 的基本流程
步骤 操作 简单来说
1 打开终端 PowerShell / Terminal
2 进入项目目录 让 Codex 知道当前项目
3 添加 M CP server 给 Codex 接入外部工具
4 检查 M CP 是否添加成功 确认工具已经可用
5 启动 Codex CL I 进入 Codex 对话界面
6 用 /mcp 查看工具 看当前能用哪些 M CP
7 在任务里调用 M CP 让 Codex 使用外部工具
8 查看结果和权限提示 确认是否安全
常用 MCP 终端命令
命令 作用 简单来说
codex mcp --help 查看 M CP 命令帮助 不知道怎么用时先看
codex mcp list 查看已配置 M CP server 看现在接了哪些外部工具
codex mcp add 添加 M CP server 给 Codex 增加一个外部工具
codex mcp remove 删除 M CP server 不用了就移除
codex mcp get 查看某个 M CP server 详情 看具体配置
codex mcp login 登录需要授权的 M CP 给某些远程 M CP 授权
展开可复制文字
命令 作用 简单来说
codex mcp logout 退出某个 M CP 授权 取消连接状态
/mcp 在 Codex 会话里查看 M CP 看当前会话能调用哪些工具
添加 MCP 的基本格式
添加 M CP 的基本命令通常是:
codex mcp add 名称 -- 启动命令
简单来说:
名称 = 你给这个 MCP 起的名字
启动命令 = 这个 MCP 怎么启动
示例:
codex mcp add context7 -- npx -y @upstash/context7-mcp
这条命令可以理解成:
给 Codex 添加一个叫 context7 的 MCP 。
它通过 npx 启动 @upstash/context7-mcp 这个工具。
查看已经添加的 MCP
添加后可以运行:
codex mcp list
作用:
查看当前 Codex CLI 已经配置了哪些 MCP server 。
如果能看到你刚添加的名称,说明配置已经写入。
进入 Codex 后查看 MCP
先进入项目目录:
展开可复制文字
cd 项目目录
然后启动 Codex:
codex
进入 Codex CLI 后,输入:
/mcp
作用:
查看当前会话里可用的 MCP 工具。
如果 M CP 没显示,可能是:
问题 可能原因
没添加成功 codex mcp add 命令失败
M CP 启动失败 依赖没装或命令错误
名称写错 调用时写错 server 名
需要授权 还没登录外部服务
配置没刷新 需要重启 Codex CL I
在任务里调用 MCP
配置好 M CP 后,不一定要记复杂命令。
你可以直接在 Codex CLI 里说:
请使用可用的 MCP 工具,查询 Next.js App Router 的最新文档。
也可以指定某个 M CP:
请用 context7 查询 Next.js App Router 的最新用法,
然后告诉我当前项目应该怎么修改。
如果是 Figma 类 M CP,可以这样说:
展开可复制文字
请用 Figma MCP 读取这个设计稿,
分析⻚面结构,并给我生成前端实现计划。
如果是 GitHub 类 M CP,可以这样说:
请用 GitHub MCP 查看这个仓库最近的 open issue ,
帮我整理出优先级最高的 3 个问题。
MCP 配置文件在哪里
Codex 的 M CP 配置会写进配置文件里。
常⻅位置是:
~/.codex/config.toml
简单来说:
config.toml = Codex 的配置文件
里面可能会有类似这样的配置:
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
这表示:
有一个 MCP server 叫 context7 。
启动命令是 npx -y @upstash/context7-mcp 。
如果你不熟悉配置文件,前期不要手动乱改。
优先使用:
codex mcp add
codex mcp list
codex mcp remove
添加远程 MCP
有些 M CP 不是本地命令启动,而是通过网址连接。
展开可复制文字
这类一般叫远程 M CP / HTTP M CP。
可能会需要:
配置项 简单来说
U RL 远程 M CP 服务地址
Auth 是否需要登录
Token 访问凭证
O Auth 浏览器授权登录
如果需要登录,可以使用:
codex mcp login MCP 名称
不用了可以:
codex mcp logout MCP 名称
新手建议:
先用不需要复杂授权的文档类 MCP 。
后面再尝试需要登录的远程 MCP 。
删除不用的 MCP
如果某个 M CP 不用了,可以删除:
codex mcp remove 名称
比如:
codex mcp remove context7
删除后再检查:
codex mcp list
确认它已经不在列表里。
展开可复制文字
W ork
很多人第一次看到 ChatGPT W ork,会产生一个很自然的疑问:
它的界面和 Codex 很像,也可以读文件、查资料、使用工具、生成内容。
那为什么还要单独做一个 W ork?
如果只看底层能力,两者确实有很多相似之处。它们都不是只能回答问题的聊天工具,而是可以围绕目标持
续执行任务的 Agent。
但两者面对的工作环境不同,默认使用的工具不同,最终交付的结果也不同。
一句话总结:
W ork 擅⻓把资料变成可以直接使用的成果,Codex 擅⻓把需求变成经过验证的代码改动。
W ork 到底是什么?
ChatGPT W ork 是一个面向研究、分析和内容交付的工作型 Agent。
普通 ChatGPT 更像一个对话助手。你提出问题,它根据当前对话生成答案。
W ork 更像一个可以被交代完整任务的执行助手。
比如你可以告诉它:
阅读这些行业报告和会议记录,整理出核心趋势,最后制作一份给管理层汇报的 PPT。
普通聊天回答往往先停留在摘要、建议或内容草稿;Work 则会继续围绕最终交付物推进任务。
它不只是给你一段关于行业趋势的文字。
它会围绕最终交付物继续工作:
阅读你提供的文件。
搜索和补充相关资料。
整理不同来源的信息。
分析数据和重要结论。
规划文档或幻灯片结构。
生成可以继续修改和使用的成品。
根据你的反馈继续调整结果。
所以,Work 真正重要的地方,不是它“更会回答问题”,而是它开始围绕一个结果持续推进任务。
更准确地说:
ChatGPT W ork 是一个可以把分散资料整理成完整交付物的 AI 工作助手。
展开可复制文字
Codex 到底是什么?
Codex 是面向软件开发和技术任务的工程 Agent。
它默认工作的地方不是普通聊天窗口,而是代码仓库、项目目录、终端和开发工具
当你让 Codex 修复一个 bug 时,它通常需要完成一整条工程链路:
阅读项目文件和项目规则。
理解代码结构和技术栈。
查找与问题相关的模块。
分析 bug 出现的原因。
制定修改方案。
编辑一个或多个文件。
运行构建、测试或检查命令。
查看修改前后的代码差异。
整理最终改动和验证结果。
所以,Codex 交付的不是一段“你可以试试这样修改”的建议。
它更关注的是:
代码有没有真正改进项目,测试有没有通过,结果能不能被开发者检查和继续提交。
一句话理解:
Codex 是一个可以进入项目现场、执行工程任务的 AI 开发助手。
W ork 和 Codex 的核心区别
对比维度 ChatGPT W ork Codex
主要用途 研究、分析和内容交付 软件开发和技术任务
默认工作对象 文档、网⻚、邮件、表格、会议记录和业务资料 代码仓库、项目文件、终端、Git 状态和开发规
则
常用工具 搜索、浏览器、文件读取、数据分析和内容生成 Shell、文件编辑、构建、测试、Git 和代码检查
常⻅交付物 文档、报告、表格、PPT、网站和研究成果 代码修改、测试结果、Diff、Commit 和 PR
判断结果的标
准
内容是否完整、清楚、准确,能不能直接使用 修改是否正确、测试是否通过,会不会破坏现
有功能
更适合的人 职场人、研究人员、运营、产品、销售和内容创
作者
开发者、独立开发者、技术团队和需要修改项
目的人
更适合的任务 把分散信息整理成完整成果 在真实项目中完成一组工程改动
展开可复制文字
它们最本质的区别,不是模型聪明程度不同,也不是一个能使用工具、另一个不能。
真正的区别是:
W ork 默认围绕业务成果组织任务,Codex 默认围绕工程结果组织任务。
用一个生活化的例子理解
假设你正在经营一家餐厅。
你对 W ork 说:
帮我分析最近一个月的顾客评价、销售数据和竞品菜单,最后生成一份经营分析报告。
W ork 会读取资料、整理数据、总结问题,并制作一份可以拿去开会的报告。
你对 Codex 说:
餐厅的在线点餐系统无法提交订单,帮我找出原因并修复。
Codex 会打开项目、查找相关代码、复现问题、修改程序、运行测试,并告诉你具体改了什么。
它们都在帮你“做事”,但进入的工作现场不同。
W ork 进入的是你的业务资料。
Codex 进入的是你的软件项目。
W ork 最后交付经营报告。
Codex 最后交付经过检查的代码修改。
为什么两个界面看起来很像?
因为 W ork 和 Codex 都采用了 Agent 的工作方式。
一个 Agent 通常需要完成下面几个步骤:
1. 理解目标。
2. 阅读背景资料。
3. 拆解任务。
4. 调用工具。
5. 执行多个步骤。
6. 检查结果。
7. 交付最终成果。
所以,在使用过程中,你都会看到它们读取文件、调用工具、持续工作、汇报进度,并在遇到重要选择时向
你确认。
展开可复制文字
但相似的界面,并不代表它们适合完全相同的任务。
你可以把它们理解成两名使用相似办公系统的同事:
W ork 是研究和交付型同事。
Codex 是软件工程型同事。
它们都能处理复杂任务,但专业分工不同。
同一个任务应该选择 W ork 还是 Codex?
有些任务同时包含业务资料和代码,因此很容易让人纠结。
最简单的判断方法是看最终要交付什么。
最终需要文档、表格或 PPT
优先选择 W ork。
例如:
整理一份竞品研究报告。
分析会议记录并提取行动项。
根据多份资料制作演示文稿。
汇总客户反馈并整理成产品建议。
分析表格数据并生成管理层周报。
收集公开资料并制作行业研究文档。
这些任务的重点是资料是否完整、结论是否准确,以及最终成果能不能直接使用。
最终需要修改代码或验证项目
优先选择 Codex。
例如:
修复一个可以复现的 bug。
给网站增加一个新⻚面。
修改接口或数据库逻辑。
补充单元测试。
重构一个过⻓的模块。
检查项目为什么无法构建。
整理代码修改并准备 PR。
这些任务的重点是代码有没有真正修改、命令有没有成功运行,以及结果能不能通过测试和代码审查。
既要研究,又要开发
可以把任务拆成两个阶段。
展开可复制文字
例如,你准备制作一个竞品分析网站。
第一阶段使用 W ork:
调研 10 个竞品,整理功能、价格、目标用户和优缺点,生成结构化表格。
第二阶段使用 Codex:
根据这份竞品数据制作一个可以筛选和对比的网站,并检查桌面端和移动端效果。
这样做比把研究、写作、设计和开发全部塞进一个超大任务更稳定。
W ork 和 Codex 可以使用相同的插件吗?
W ork 和 Codex 都可以通过插件扩展能力,但插件是否可用,还会受到订阅计划、工作区设置、用户⻆色、
使用入口和应用权限的影响。
插件可以包含:
Skill:可重复使用的任务方法和工作流程。
App 或 M CP 工具:连接邮件、文档、云盘、聊天工具等外部数据与操作。
浏览器扩展、Hook 或定时任务模板:为特定工作流补充浏览器能力、生命周期检查或调度入口。
W ork 更常连接业务应用和内容工具,例如邮件、云盘、日历、文档和团队沟通工具。
Codex 更常使用开发工具和项目能力,例如代码仓库、终端、测试、浏览器调试和 Git 工作流。
它们并不是被工具完全隔开的。
真正应该关注的是:
当前任务需要读取什么上下文,最后又需要交付什么结果。
W ork 和 Codex 的额度是独立的吗?
不能简单地认为两者完全独立。
O penAI 当前定价说明指出,Codex 的使用额度会在相关计费生效后与部分其他智能体功能共享;具体纳入
哪些功能、如何消耗以及是否可以购买额外 credits,会因订阅计划、工作区和发布时间而变化。
因此更稳妥的做法是:
不把 W ork 和 Codex 当作两套永远互不影响的固定额度。
在 ChatGPT 的使用情况或计划⻚面查看当前账号的实际用量。
大型研究、⻓上下文和⻓时间运行任务开始前,先确认剩余额度。
W ork 和 Codex 分别在哪里使用?
ChatGPT W ork 可以在符合条件的 ChatGPT 网⻚端、移动端和桌面端使用。
展开可复制文字
不同入口的能力会有区别:
网⻚端和移动端的 W ork 主要在云端运行。
桌面端 W ork 可以在你授权后使用本地文件和桌面应用。
云端 W ork 与桌面端 W ork 的任务和本地文件不一定自动互通。
ChatGPT 桌面端提供 Codex 模式,可以使用本地文件夹、代码仓库、终端和开发工具。
除此之外,Codex 还有面向开发者的 CLI、IDE Extension 和云端任务等使用入口。
因此,不要只根据“网⻚端有没有一个 Codex 按钮”判断 Codex 是否存在。
更准确的理解是:
W ork 是 ChatGPT 中面向研究与交付的工作入口;Codex 是一套面向软件开发的 Agent 产品与工具体系。
新手应该怎么选?
如果你还是分不清,可以只问自己两个问题。
第一个问题:它需要读取什么?
如果需要读取的是:
报告
网⻚
邮件
会议记录
表格
业务文档
优先选择 W ork。
如果需要读取的是:
代码仓库
项目目录
配置文件
终端输出
Git 记录
测试结果
优先选择 Codex。
第二个问题:最后需要交付什么?
如果最后需要:
一份报告
展开可复制文字
一个表格
一套幻灯片
一篇文档
一个研究结果
优先选择 W ork。
如果最后需要:
一组代码修改
一个修复后的功能
一份测试结果
一个可以检查的 Diff
一个 Commit 或 PR
优先选择 Codex。
如果还是拿不准,就看最终验收方式:
用“内容是否能直接使用”验收的任务,更适合 W ork。
用“项目是否能正常运行”验收的任务,更适合 Codex。
本章总结
ChatGPT W ork 和 Codex 都采用 Agent 的工作方式,都可以读取上下文、调用工具并持续执行任务。
但它们的默认方向不同。
W ork 面向研究、分析和内容交付。
Codex 面向软件开发和技术任务。
W ork 主要读取业务资料,交付文档、表格、幻灯片、报告和网站。
Codex 主要读取代码仓库,交付代码修改、测试结果、Diff、Commit 和 PR。
选择它们时,不要只看界面,也不要只看它们能不能使用某个工具。
真正应该判断的是:
任务需要进入什么工作现场,最终又要用什么标准验收。
这一章最重要的一句话是:
想把资料变成成果,优先使用 W ork;想把需求变成经过验证的代码改动,优先使用 Codex。
资料说明:本章根据 O penAI 官方的 ChatGPT W ork 说明、Codex 定价说明和插件说明整理。产品入
口、订阅资格、额度和功能可能继续调整,请以账号实际界面和最新官方文档为准。
展开可复制文字
站点(sites)
让 Codex 把网站直接发布成可访问链接
以前使用 Codex 制作网站,通常只能完成开发环节。
Codex 可以帮你写⻚面、修改代码、运行项目和检查效果,但如果想让其他人通过链接访问,你还需要自己
准备部署平台、连接代码仓库、配置构建命令,再处理域名、环境变量和访问权限。
现在 Sites 补上了最后一段流程。
它可以把提示词或兼容的本地项目变成一个由 ChatGPT 托管的网站,并提供预览、版本、发布、分享和后续
修改能力。
一句话总结:
Codex 负责把网站做出来,Sites 负责把网站变成可以访问和分享的线上成果。
Sites 到底是什么?
ChatGPT Sites 是一个集网站创建、托管、修改和分享于一体的站点功能。
你可以在 ChatGPT W ork 网⻚端,或者 ChatGPT 桌面端的 W ork、Codex 模式中使用它。
使用时,你不需要先准备服务器,也不需要从零搭建一套部署流程。
只需要描述你想制作的网站,并在提示词中明确写出“网站”,或者直接提到 @Sites。
例如:
使用 @Sites 制作一个个人介绍网站。
ChatGPT 会根据任务生成站点,提供一个可以检查的预览,并允许你继续修改。
确认没有问题后,可以将它部署成一个可访问的 Site URL 。
所以,Sites 不只是“帮你生成网⻚代码”。
它真正解决的是:
从一个想法或本地项目,到一个可以访问、修改和分享的网站,中间缺失的发布流程。
Sites 可以做什么?
Sites 适合制作网站、轻量 W eb 应用和浏览器小游戏。
常⻅场景包括:
产品落地⻚
活动介绍⻚
作品集网站
展开可复制文字
项目进度看板
数据仪表盘
发布日历
内部资料⻔户
客户评审⻚面
可交互报告
轻量管理工具
简单浏览器游戏
概念验证和产品原型
Sites 最大的价值,不是让所有人都去开发复杂软件。
它更适合把原本分散在文档、表格和幻灯片里的内容,变成一个可以浏览、筛选和交互的网⻚。
例如,一份普通的竞品分析报告只能从头往后阅读。
如果把它做成 Site,就可以增加:
产品分类
条件筛选
价格对比
详情弹窗
图表展示
搜索功能
访问权限
最终交付的不再只是一份静态文件,而是一个可以通过链接访问的交互式成果。
Sites 的基本工作流程
一个完整的 Sites 任务,通常会经历四个阶段。
第一阶段:描述网站
先说明网站要给谁使用、解决什么问题,以及必须包含哪些内容和功能。
一个完整的需求至少应该包含:
目标用户
网站用途
⻚面内容
核心功能
数据来源
视觉方向
展开可复制文字
访问范围
验收标准
不要只说:
帮我做一个好看的网站。
这种描述没有明确的用户、内容和功能,Codex 只能自己猜。
更好的方式是:
使用 @Sites 制作一个面向潜在客户的 AI 咨询服务网站。 网站包含首⻚、服务介绍、案例展示和联系
表单。 整体使用暖白背景、深灰文字和少量橙色点缀,不使用大面积渐变。 桌面端和手机端都不能出
现横向滚动。 先生成预览,不要直接公开发布。
第二阶段:检查预览
Sites 生成网站后,会先提供预览。
这一步不是简单地看一眼颜色是否好看,而是要检查:
内容是否准确。
⻚面结构是否完整。
按钮能不能正常点击。
图片是否符合预期。
数据是否正确展示。
手机端是否容易阅读。
网站是否包含不应该公开的信息。
访问权限是否符合使用场景。
如果网站来自本地项目,还应该检查代码修改、依赖变化、数据库迁移和构建结果。
不要因为⻚面看起来完整,就直接发布。
好看的截图不等于可以正常使用的网站。
第三阶段:继续修改
在预览界面中,可以继续描述需要修改的地方。
例如:
把首⻚标题改得更具体,不要使用“写个好听的介绍”这类空泛表达。
手机端的首屏太高,把主视觉缩小,让用户打开⻚面后能直接看到核心介绍。
动态互动效果。
展开可复制文字
将联系表单改成姓名、邮箱和需求描述三个字段,提交后显示成功提示。
如果文字很难描述问题,也可以提供截图、参考图片或相关文件作为上下文。
这一步的重点是小步修改。
每次只处理一组相关问题,修改后重新检查,比一次要求它“全面优化所有细节”更加稳定。
第四阶段:保存版本并发布
Sites 的版本保存和网站发布是两个不同的动作。
保存版本,是生成一个可以检查的候选版本。
发布版本,才是把某个候选版本部署到线上,并生成生产环境访问地址。
这意味着你可以先让 ChatGPT:
保存当前版本,但不要部署。
确认内容、交互和权限没有问题后,再告诉它:
发布刚才确认的版本,并把访问地址发给我。
需要特别注意:
Sites 每一次部署生成的都是生产环境地址,不是临时测试地址。
如果只想检查修改,不要直接要求部署。先保存版本,完成检查后再发布。
从零创建和发布现有项目使用上有什么区别?
Sites 支持两种常⻅使用方式。
Sites 可以从零帮你搭建网站。
也可以将你已经做好的网站,将兼容项目发布到 OpenAI 托管的 Sites 环境。
从一句描述开始创建
这种方式适合没有现成代码,希望快速制作网站的人。
你只需要提供:
网站目标
用户类型
⻚面结构
内容资料
功能要求
视觉方向
展开可复制文字
ChatGPT 会帮助你创建站点、生成预览并继续修改。
这种方式适合:
落地⻚
内部工具
简单看板
活动⻚面
交互式报告
小型原型
发布已有的本地项目
如果你已经使用 Codex 做好了一个网站,也可以让 Sites 检查项目是否兼容,并准备发布。
例如:
使用 Sites 部署当前项目。 先检查项目是否兼容,列出需要修改的地方。 完成构建和⻚面检查后保存
一个版本,不要直接发布。
对于本地项目,Sites 会把源代码项目和托管项目关联起来。
相关关联信息可能记录在:
.openai/hosting.json
这个文件用于保存 Sites 项目标识和存储绑定名称,不应该用来保存密码、API Key 或其他秘密信息。
Sites 支持哪些数据能力?
有些网站只需要展示内容,不需要⻓期保存数据。
例如:
产品介绍⻚
个人作品集
活动说明⻚
静态研究报告
这类网站通常不需要额外的持久化存储。
但如果网站需要记住用户操作,就需要明确告诉 Sites。
例如:
保存项目任务
记录游戏分数
展开可复制文字
保存用户进度
存储表单记录
上传图片或文档
Sites 可以根据需求使用不同的存储能力。
网站需求 对应能力 人话解释
只展示⻚面内容 不需要持久化存储 ⻚面刷新后不需要记住新数据
保存任务、记录或分数 D1 用数据库保存结构化数据
保存图片、文档或音视频 R2 用文件存储保存上传内容
同时保存文件和文件信息 D1 + R2 数据库记录文件信息,文件存储保存文件本身
识别工作区成员 W orkspace 身份 确认访问者属于哪个工作区账号
允许外部用户登录 身份验证功能 为公开用户增加登录流程
第一次制作 Sites 时,不需要为了显得功能完整,就给所有⻚面增加数据库和登录系统。
如果只是做一个产品介绍⻚,就先把内容、布局和移动端体验做好。
只有当用户确实需要保存数据时,再增加持久化能力。
Sites 的访问权限
网站成功托管,不代表已经自动公开。
新创建的 Site 默认会受到访问控制,具体可用选项取决于订阅计划、账号类型和工作区设置。
可能包括:
只有自己和工作区管理员可以访问。
只有受邀请的用户或群组可以访问。
工作区内的所有人可以访问。
互联网中的任何人可以访问。
需要注意:
网站访问权限和网站内部的登录功能是两件事。
访问权限决定谁可以打开这个 Site。
网站内部登录功能决定用户进入网站后,是否还需要登录并识别身份。
例如,一个 Site 可以只允许公司工作区成员打开,同时在网站内部显示当前成员的姓名和权限。
也可以把一个 Site 公开到互联网,但在进入管理⻚面时要求用户登录。
发布之前,一定要使用目标访问者的身份重新测试一次,确认他们看到的内容和权限符合预期。
展开可复制文字
Sites 可以绑定自己的域名吗?
在账号支持自定义域名的情况下,Sites 可以连接你已经拥有的域名。
Sites 不会替你注册域名。
你需要先从域名服务商购买域名,并且能够修改 DNS 记录。
大致流程是:
1. 打开 Site 设置。
2. 选择添加域名。
3. 输入顶级域名或子域名。
4. 将 Sites 提供的 DNS 记录复制到域名服务商。
5. 等待解析生效。
6. 返回 Sites 检查域名状态。
自定义域名仍处于逐步开放状态,是否可用取决于账号和工作区。
在初始上线阶段,Enterprise 工作区可能不支持自定义域名。
Sites 和 Vercel、Netlify 有什么区别?
很多人会把 Sites 理解成“O penAI 版本的 Vercel”。
这个理解只对了一部分。
它们都可以把网站部署到线上,但面对的人群和工作方式不同。
对比维度 ChatGPT Sites Vercel、Netlify 等专业平台
主要目标 从提示词或兼容项目快速得到可分享网站 为开发团队提供专业部署和托管流程
操作方式 在 ChatGPT 中描述、预览、修改和发布 连接代码仓库并配置构建、域名和部署规则
上手⻔槛 较低,适合快速原型和轻量应用 需要一定开发和部署知识
修改方式 可以继续通过自然语言修改 通常修改代码后重新构建和部署
适合项目 落地⻚、看板、内部工具、报告和轻量应用 正式产品、复杂前端、⻓期维护的生产项目
基础设施控制 由 Sites 支持的运行环境决定 通常拥有更完整的框架、构建和部署控制
复杂后端 可能受运行环境限制 更适合连接复杂后端和外部基础设施
所以,不建议把 Sites 简单说成“可以完全替代 Vercel”。
更准确的理解是:
Sites 把制作和发布轻量网站的⻔槛降得更低,但专业部署平台仍然适合复杂、⻓期维护和需要完整工程控制
的项目。
展开可复制文字
如果只是想快速发布一个活动⻚、内部看板或产品原型,Sites 通常更省步骤。
如果项目依赖特殊框架、私有网络、复杂数据库、后台服务或自定义基础设施,就应该先检查兼容性,必要
时继续使用专业部署平台。
Sites 不适合做什么?
Sites 适合轻量网站和应用,但不是所有项目都应该放在 Sites 上。
下面这些场景需要谨慎:
依赖复杂后台服务的大型系统。
必须连接私有网络的企业应用。
需要特殊运行环境或框架的项目。
需要精细控制服务器和部署架构的项目。
涉及银行卡支付数据的业务。
处理受保护医疗信息的系统。
面向儿童并收集个人数据的产品。
需要执行金融交易的网站。
包含机密数据但准备公开分享的网站。
Sites 在初始阶段也不支持数据驻留和推理驻留要求。
如果企业对数据保存地区、合规和基础设施位置有严格规定,应该先让管理员和安全团队确认,而不是直接
上线。
哪些用户可以使用 Sites?
截至本章最后校验时,Sites 仍处于 Public Beta,也就是公开测试阶段。
它可以用于部分付费计划,但不向 Free 和 Go 计划开放。
初始阶段也不在以下地区提供:
欧洲经济区
瑞士
英国
不同计划的开放时间可能不同。如果没有看到 Sites,可能是以下原因:
当前计划不支持。
功能还没有推送到账号。
当前地区暂不支持。
登录了错误的工作区。
工作区管理员没有开启。
展开可复制文字
当前⻆色没有创建或发布权限。
使用的是不支持 Sites 的旧版 ChatGPT Classic。
Business 工作区通常默认开启 Sites。
Enterprise 工作区需要管理员通过⻆色权限进行配置,而且公开发布默认关闭。
具体情况应该以当前账号界面和工作区设置为准。
Sites 的额度怎么计算?
Sites 在公开测试期间包含一定的计划额度,但不同计划的上限可能不同。
当接近限制时,ChatGPT 会显示提醒。
如果达到测试额度,可能出现下面这些限制:
暂时无法创建新的 Site。
无法继续增加存储。
高使用量网站可能无法继续公开运行。
仍然可以编辑和管理已经创建的 Site。
额度会统计账号中的所有 Sites,而不是每个 Site 单独拥有一份额度。
由于 Public Beta 期间的规则可能调整,不建议在文档中写死具体数字。
最可靠的方式是查看当前 Sites 界面显示的计划限制。
使用 Sites 的标准步骤
第一步:选择一个边界清楚的小项目
第一次使用时,不要直接制作复杂的 SaaS 产品。
可以先从个人介绍⻚任务开始
第二步:写清楚网站需求
告诉 Sites:
需要哪些⻚面
需要哪些功能
使用哪些资料
希望什么⻛格
展开可复制文字
可以直接使用计划模式,先告诉 Codex 你的需求是什么
我想做个类似的互动网⻚,因为我是推特的 ai 博主,所以我需要更多的是互动感觉,不是以黑色色调来凸显科技高档⻛格,是
通过独特的创意互动,想要那种修仙玄幻⻛格的,给你参考的它是以电脑加载然后进入一个全新的电脑,我的首⻚可以是一种
能力加载,可以是电力或者其他能源加载然后进入一个全新的世界
Codex 会先给出网⻚构建计划。
Sites 输出参考图
Sites 会直接输出每一⻚的参考图
第三步:先生成预览
完成网⻚制作后,Sites 会生成一个默认受限的预览版本;具体可访问范围取决于账号和工作区设置。
这时可以进入预览,检查网站的整体效果。
展开可复制文字
如果预览链接无法打开,先检查网络、登录状态、账号计划和工作区权限,不要直接把问题归因于站点生成
失败。
展开可复制文字
第四步:逐项检查
至少检查:
桌面端
手机端
整体效果
按钮和链接
数据是否保存
空状态和错误状态
访问权限
敏感信息
第五步:确认权限并发布
确认内容和功能基本完成后,让 Codex 帮你直接发布到网上,并且设置为公开权限
第六步:使用真实访问地址验收
打开正式地址,重新检查:
网站能否正常访问。
⻚面和功能是否正常。
手机端是否出现布局问题。
本章总结
Sites 是 ChatGPT 中用于创建、托管、修改和分享网站的功能。
它可以从提示词开始制作新网站,也可以检查并发布兼容的本地项目。
它适合制作:
落地⻚
内部工具
数据看板
交互式报告
产品原型
轻量 W eb 应用
一个完整的 Sites 工作流不是“生成⻚面后立刻上线”,而是:
描述需求、生成预览、继续修改、保存版本、检查权限、正式发布、使用真实地址验收。
Sites 降低了网站发布的⻔槛,但不代表可以跳过检查。
⻚面内容、交互功能、移动端效果、访问权限、数据处理和敏感信息仍然需要人工确认。
展开可复制文字
也不要把 Sites 简单理解成可以完全替代 Vercel、Netlify 等专业部署平台。
它真正适合的是:
把一个想法、资料或轻量项目,快速变成可以访问和分享的线上成果。
这一章最重要的一句话是:
Codex 帮你把网站做出来,Sites 帮你把网站安全地变成一个可以分享的链接。
资料说明:本章根据 O penAI 官方的 Sites 文档整理。计划资格、地区、额度、运行环境、自定义域名
和工作区权限可能继续调整,请以账号实际界面和最新官方文档为准。
代码管理 (Git 与 GitHub 工作流)
用 Codex 做真实项目时,一定要懂一点 Git 和 GitHub。
小白可以先这样理解:
Git = 本地代码版本管理工具
GitHub = 把代码放到网上协作的平台
Codex = 帮你读代码、改代码、跑命令的 AI 编程助手
一句话:
Git 负责记录代码变化。
GitHub 负责远程保存和协作。
Codex 负责帮你完成具体编程任务。
Git 和 GitHub 有什么区别
对比 Git GitHub
简单来说 本地版本管理工具 代码云盘 + 协作平台
主要作用 记录代码每次改了什么 远程保存代码、团队协作
使用位置 你的电脑里 浏览器 / 云端
核心能力 commit、branch、diff、merge repository、issue、pull request
是否必须联网 不需要 需要
和 Codex 的关系 Codex 改完代码后,用 Git 检查和保存 Codex W eb / Cloud 常和 GitHub 配合
展开可复制文字
小白必须先懂的 Git 概念
概念 简单来说 作用
Repository 一个代码仓库 存放整个项目
Commit 一次代码存档 记录这次改了什么
Branch 分支 在不影响主线的情况下改代码
Diff 改动对比 看新增、删除、修改了什么
Stage 暂存区 准备把哪些改动保存进 commit
M erge 合并 把一个分支的改动合到另一个分支
Conflict 冲突 两边改了同一处代码,需要手动选择
Push 推送 把本地代码上传到 GitHub
Pull 拉取 把 GitHub 上的新代码同步到本地
Clone 克隆 从 GitHub 下载一个项目到本地
小白必须先懂的 GitHub 概念
概念 简单来说 作用
Repository GitHub 上的项目仓库 存代码
Issue 问题 / 需求记录 记录 bug、需求、任务
Pull Request / PR 代码合并申请 改完代码后申请合并
M ain Branch 主分支 项目的稳定版本
Feature Branch 功能分支 用来开发新功能
Review 代码检查 合并前检查代码
Actions 自动化流程 自动测试、构建、部署
READM E 项目说明书 告诉别人项目怎么用
.gitignore 忽略文件清单 防止上传无关或敏感文件
为什么用 Codex 更需要 Git
场景 为什么需要 Git
Codex 改了很多代码 可以查看具体改了哪里
展开可复制文字
场景 为什么需要 Git
Codex 改错了 可以回退到之前版本
Codex 删除了不该删的内容 可以用 Git 找回
多次让 Codex 修改 每次 commit 保存一个阶段
想让 Codex 大胆试方案 用 branch 或 worktree 隔离⻛险
要把项目放到 GitHub 需要 push 到远程仓库
团队协作 需要 PR、review、merge
一句话:
没有 Git , Codex 改错了你很难回退。
有了 Git , Codex 可以放心试,你可以随时检查和恢复。
如何在 Codex 中使用 Git
步骤 操作 目的
1 初始化 Git 让项目开始被 Git 管理
2 写好 .gitignore 防止上传垃圾文件和密钥
3 先 commit 一次 保存干净版本
4 新建分支 给 Codex 一个安全实验区
5 让 Codex 修改代码 完成具体任务
6 查看 diff 检查 Codex 改了什么
7 运行项目 / 构建 确认没出错
8 满意后 commit 保存这次修改
9 push 到 GitHub 上传远程仓库
10 创建 PR 合并前再检查一次
展开可复制文字
在 Codex 对话框中输入:把项目初始化成一个 Git 工程,并排除不需要的文件
Codex 会帮我们直接写好 .gitignore 文件
展开可复制文字
如何在 Codex 中使用 GitHub
使用前需要准备什么
准备项 作用 简单来说
GitHub 账号 保存远程代码 代码云盘账号
Git 本地版本管理 记录代码变化
GitHub 仓库 放项目代码 一个远程项目文件夹
本地项目 Codex 要修改的代码 电脑里的项目文件夹
GitHub 登录权限 允许 push / PR 证明这是你的仓库
.gitignore 防止上传无关文件 不上传垃圾文件和密钥
标准上传流程
步骤 操作 目的
1 在 GitHub 新建仓库 创建一个远程项目空间
2 复制仓库地址 后面要连接本地项目
3 将地址复制给 Codex 让 Codex 知道要上传到哪个仓库
4 推送到 GitHub 正式上传代码
展开可复制文字
推送到 GitHub
代码回滚
修改代码
先让 AI 修改一下代码
展开可复制文字
提交到 Git,保存好当前版本
继续修改代码
打开 IDE 查看代码并且回退代码
先打开 IDE 查看代码
展开可复制文字
复制给 Codex,让它回退代码到指定版本
Git W orktree
给同一个 Git 项目,额外开一个独立工作副本。
相当于一个草稿本,效果满意后再合并回正式项目。
为什么需要 W orktree
普通 Git 分支虽然可以切换,但每次只能在一个文件夹里操作一个分支。
W orktree 的好处是:
场景 W orktree 的作用
想让 Codex 大胆改代码 给它单独开一个副本
不想影响当前项目 主项目保持不动
想同时做多个任务 每个任务一个 worktree
想比较多个方案 方案 A / B / C 分开放
改坏了不想要 直接丢掉 worktree
做大改动 / 重构 降低污染主项目的⻛险
展开可复制文字
使用分支进行任务
合并回主干
检查效果满意后,就可以合并回主干,并把这个分支删除。
展开可复制文字
云端运行
Codex 的云端任务适合在你不方便一直开着本地电脑时继续处理工作;如果你的账号和客户端支持移动端入
口,也可以在外出时查看或推进部分任务。
把代码任务交给 Codex ,让它在云端环境里自己跑。
小白可以这样理解:
模式 运行位置 简单来说
L ocal 你的电脑本地项目 Codex 直接改你电脑里的代码
W orktree 你的电脑本地副本 Codex 在安全副本里改代码
Cloud O penAI 云端环境 Codex 在云端拉取 GitHub 仓库并处理任务
Codex 云端运行是什么
Codex 云端运行,本质上是:
内容 说明
运行环境 云端容器
代码来源 GitHub 仓库
工作方式 Codex 在云端读取、修改、运行、验证代码
最终结果 生成修改结果、diff,必要时创建 PR
适合任务 修 bug、改功能、写文档、代码 review、处理 issue
不适合任务 本地私密文件、没有上传 GitHub 的项目、高⻛险生产操作
云端运行和本地运行的区别
对比 本地运行 L ocal / W orktree 云端运行 Cloud
代码位置 你电脑里 GitHub 仓库
运行位置 你的电脑 云端容器
是否占用电脑 会占用 基本不占用
是否需要 GitHub 不一定 通常需要
是否适合后台任务 一般 很适合
是否适合并行任务 一般 很适合
展开可复制文字
对比 本地运行 L ocal / W orktree 云端运行 Cloud
权限⻛险 主要是本机文件权限 主要是仓库、环境变量、网络权限
适合新手吗 更适合先学 学会 GitHub 后再用
云端运行操作步骤
推送代码到GitHub上面
展开可复制文字
打开Codex W eb
选择我们要修改的仓库
选择好过后直接让Codex给我们工作就行了
展开可复制文字
本地修改前先同步 GitHub 仓库里的最新代码
如果云端任务已经把修改推回 GitHub,本地继续开发前要先同步最新代码,避免在旧版本上继续修改导致冲
突。具体是 Codex 自动帮你应用变更,还是你手动 git pull / codex apply,取决于当前入口和任务类
型。
展开可复制文字
记忆系统
让 Codex 记住一些⻓期有用的信息,方便以后继续工作。
项目级AGENTS.md
写给 Codex 看的项目规则说明书。
小白可以这样理解:
文件 主要读者 作用
READM E.md 人 告诉人这个项目是什么、怎么安装、怎么使用
AGENTS.md Codex / AI Agent 告诉 AI 在这个项目里应该怎么工作
.gitignore Git 告诉 Git 哪些文件不要上传
AGENTS.md 放在哪里
放置位置 作用范围 简单来说
项目根目录 AGENTS.md 整个项目 当前项目的总规则
子目录里的 AGENTS.md 当前子目录及相关任务 某个模块的专属规则
用户级 ~/.codex/AGENTS.md 你所有项目 个人通用规则
展开可复制文字
放置位置 作用范围 简单来说
项目级 AGENTS.md + 用户级 AGENTS.md 叠加生效 个人习惯 + 当前项目规则
如何写 AGENTS.md
可以直接交给AI来写,让AI总结这个项目的核心内容制作成 AGENTS.md
展开可复制文字
前端项目 AGENTS.md 模板
# AGENTS.md
## 项目说明
这是一个前端网⻚项目,用于构建产品⻚面、工具⻚面或个人作品展示⻚面。
## 技术栈
- React
- Vite
- Tailwind CSS
- JavaScript / TypeScript
## 常用命令
- 安装依赖: `npm install`
- 启动项目: `npm run dev`
- 构建项目: `npm run build`
## 项目结构
- `src/` :主要源代码
- `src/components/` :通用组件
- `src/pages/` :⻚面文件
- `src/assets/` :图片、图标等静态资源
- `public/` :公开静态文件
## 代码规范
- 优先使用 React 函数组件
- 优先使用 Tailwind CSS 写样式
- 不要引入 Bootstrap
- 不要大范围重构无关代码
- 修改时保持文件结构清晰
- 中文文案要自然、简洁、适合普通用户阅读
## UI 规则
- ⻚面要有清晰的信息层级
展开可复制文字
- 按钮、卡片、标题、留白要统一
- 移动端要基本可用
- 不要过度渐变、阴影和 AI 模板感
- 优先做真实产品感,而不是 Demo 感
## 禁止事项
- 不要修改 `.env` 、 `.env.local`
- 不要输出 API Key 、 token 、密码
- 不要删除已有核心功能
- 不要随意新增大型依赖
- 不要直接改动和当前任务无关的文件
## 完成任务后
每次修改完成后,请输出:
1. 修改了哪些文件
2. 每个文件改了什么
3. 为什么这样改
4. 是否需要运行 `npm run build`
5. 提醒我检查 diff
好的 AGENTS.md 有什么特点
特点 说明
具体 写清楚技术栈、命令、目录
简洁 不要写成⻓篇废话
可执行 Codex 看了知道怎么做
有限制 明确哪些文件不能碰
有验证 写清楚运行什么命令检查
有完成标准 让 Codex 知道交付什么
可维护 项目变化后及时更新
展开可复制文字
全局级AGENTS.md
打开Codex的设置,找到个性化
输入指令,这里的指令会作为你的个人通用偏好影响后续 Codex 会话
使用AI编程的时候最怕AI乱删东⻄,可以用以下指令
禁止批量删除文件或目录。
不要使用:
del /s
rd /s
rmdir /s
Remove-Item -Recurse
rm -rf
需要删除文件时,只能一次删除一个明确路径的文件。
正确示例:
Remove-Item "C:\path\to\file.txt"
如果需要批量删除文件,应停止操作,并向用户请求,让用户手动删除。
展开可复制文字
Codex记忆的最佳使用方法
很多人用 Codex 最大的问题,不是不会提问。
而是每次都从零开始交代:
“我的项目怎么跑测试” “我喜欢什么输出⻛格” “这个仓库有哪些坑” “这个流程上次做到哪一步” “这些
资料在哪里”
这其实是在把“记忆系统”当聊天记录用。
更好的方式,是把不同类型的信息放到不同的上下文层里,让 Codex 在合适的时候读取合适的信息。
先看一张总表:
展开可复制文字
你想让 Codex 记住什么 推荐放哪里 不建议放哪
里
原因
当前任务的临时要求 当前 prompt / 当前会话 AGENTS.md 只用一次,不要污染⻓期规
则
个人偏好、常⻅习惯 M emories / 全局
AGENTS.md
每次重新说 稳定但不一定要进项目仓库
仓库规则、测试命令、目录约定 repo 的 AGENTS.md M emories 这是硬规则,应该随项目走
可复用工作流 Skill AGENTS.md Skill 能放参考文件、脚本、
模板
定期复盘、跟进、监控 Automations 记在脑子里 需要按时间唤醒,不是静态
规则
Slack / GitHub / Docs 里的实时
资料
M CP / Connector 手动复制粘
贴
外部信息会变,应该现取现
用
当前会话 / prompt:最适合放“这次任务”的要求
当前会话就是最短期的记忆,只用于这次任务,几乎不会重复使用。
比如:
展开可复制文字
“这次网⻚背景改成蓝白色调” “在网⻚右上⻆加一个登录按钮” “这个方案只考虑 W indows” “先别提交
PR”
这类信息只对当前任务有用,不应该沉淀成⻓期规则。
如果把临时要求写进 AGENTS.md,后面每次打开项目,Codex 都可能误以为这是⻓期规则,反而会污染上
下文。
Memories:适合放“稳定偏好”和“常⻅背景”
M emories 适合保存那些跨会话、跨项目也经常有用的信息。
简单来说,Memories 是:
Codex 对你的个人工作习惯的软记忆。
比如:
你偏好中文回答。
你希望解释尽量通俗,不要堆术语。
你做项目时喜欢先看方案,再动手改代码。
你常用 W indows、PowerShell、某些固定目录或工具链。
你经常要求修改后说明 diff、验证命令和未验证项。
操作步骤:
展开可复制文字
1. 在 Codex 设置里开启 M emories。
2. 用几次真实任务让 Codex 形成稳定偏好。
3. 可以在下面这个目录里查看对应的记忆文件:
~/.codex/memories/
展开可复制文字
常⻅文件和目录大致可以这样理解:
名称 作用 简单来说
M EM O RY.md Codex 最主要的⻓期记忆文件,通常放稳定偏好、常用工作流、技术
栈、项目习惯等
正式记忆本
memory_ summary.md 对记忆内容做压缩总结,让 Codex 更快读取核心信息 记忆摘要
raw_ memories.md 更原始的记忆条目,可能包含从历史 thread 提炼出来的未压缩记录 原始记录本
rollout_ summaries/ 存放某些任务、会话或运行过程的摘要,用来支撑后续记忆生成 过去任务摘要
库
extensions/ 给扩展功能使用的记忆目录 扩展记忆区
建议定期检查 M emories:
有没有把一次性的临时要求记进去。
有没有把隐私信息、密钥、账号信息记进去。
有没有把已经过期或错误的偏好记进去。
有没有重要规则只存在 M emories 里,但没有同步到 AGENTS.md 或 Skill。
一句话总结:
M emories 是 Codex 用来记录你⻓期偏好和常⻅背景的记忆。
AGENTS.md:最适合放“必须遵守的项目规则”
AGENTS.md 是我最推荐新手先用的一层。
展开可复制文字
它的作用很像写给 Codex 的工作说明书。Codex 开始工作前会读取 AGENTS.md,并把里面的规则当成当
前项目或当前用户的工作约束。
值得注意的是,AGENTS.md 可以分为全局级和项目级。
全局级 AGENTS.md 会影响你在 Codex 中的大多数项目和会话,适合放个人⻓期规则。
文件位置通常是:
~/.codex/AGENTS.md
操作步骤:
1. 直接在 Codex 设置里的个性化区域写入规则。
2. 只写几条最重要、最稳定的规则。
3. 不要把某一次任务的临时要求写进去。
比如:
“每次文字输出都使用 M arkdown 格式。” “不确定需求时,先指出不确定点,再给推荐方案。” “不要擅
自删除文件、重命名核心目录或大范围重构。”
项目级 AGENTS.md 只影响当前项目,适合放仓库规则、测试命令、目录约定和交付标准。
文件位置通常是:
展开可复制文字
~/xxx 项目 /AGENTS.md
操作步骤:
1. 在对应项目文件夹根目录里创建 AGENTS.md。
2. 只写这个项目必须遵循的规则。
3. 如果不确定怎么写,可以让 Codex 先阅读项目,再帮你生成初版。
展开可复制文字
比如:
“使用项目现有技术栈,不要擅自更换框架。” “不要擅自删除、重命名核心目录。” “修 bug 时,优先找
到根因,不要只做表面兼容。”
最简单的模板:
展开可复制文字
# AGENTS.md
## Project overview
这是一个前端项目,主要用于构建网⻚、交互⻚面、小游戏或内容展示⻚。
## Tech stack
- 使用项目现有技术栈,不要擅自更换框架。
- 如果是 Vite / React / Vue / Next.js 项目,先确认 `package.json` 再判断运行方式。
- 不要随意引入新的生产依赖。
- 如确实需要新增依赖,先说明原因、用途和替代方案,等待确认。
## Project structure
- `src/` :主要源码目录。
- `public/` :静态资源目录。
- `components/` :组件目录,如果项目中存在则优先复用。
- `assets/` :图片、图标、样式资源。
- 不要擅自删除、重命名核心目录。
- 修改前先阅读相关文件,不要只凭文件名猜测。
## Working rules
- 开始修改前,先简单说明计划。
- 优先小步修改,不要一次性大范围重构。
- 保持原项目代码⻛格、命名⻛格和目录结构。
- 修 bug 时,优先找到根因,不要只做表面兼容。
- 改 UI 时,注意中文排版、信息层级、间距、按钮状态和移动端适配。
- 不要覆盖用户已有改动。
## Commands
请根据 `package.json` 判断实际命令。常⻅命令如下:
npm install
npm run dev
npm run build
npm run lint
展开可复制文字
Skills:适合放“可复用工作流”
如果 AGENTS.md 是项目说明书,Skill 更像一个可复用工作流包。
Skill 可以包含 SKILL.md、参考文件、脚本和资源;它适合那些反复出现、需要步骤、示例或工具辅助的任
务。
比如:
场景 应该做成 Skill 吗
每次都要写同一种 X Article 应该
每次都要按固定流程做 PR review 应该
只想提醒 Codex 用 pnpm 不用,放 AGENTS.md
只对当前任务有效的语气要求 不用,放 prompt
用来写作的 Skill,不是只记一句“帮我写推特”。
它真正应该沉淀的是:
写作⻛格。
输出结构。
M arkdown 格式。
图片占位。
教程步骤。
推荐规则。
质量检查。
操作步骤:
1. 先把反复做的任务列出来。
2. 如果一个任务出现 3 次以上,就考虑做成 Skill。
3. SKILL.md 只放核心规则。
4. ⻓模板、⻛格卡、检查表放 references/。
5. 能自动化的部分再放脚本。
最后的总结
如果前面看起来有点绕,可以这样理解:
层级 比喻 适合放什么
当前会话 / prompt 临时便签 这次任务的一次性要求
M emories 个人习惯档案 稳定偏好、常⻅背景、⻓期习惯
全局 AGENTS.md 个人工作规则 所有项目里都要尽量遵守的硬规则
展开可复制文字
层级 比喻 适合放什么
项目级 AGENTS.md 项目工作说明书 当前仓库的技术栈、命令、目录和禁区
Skill 可复用流程包 经常重复、需要步骤和模板的任务
Automations 定时提醒和监控 定期复盘、跟进、巡检、监控
M CP / Connector 实时资料入口 Slack、GitHub、Docs 等会变化的外部信息
最后补充一句:
Codex 的记忆和上下文,可以按“越临时、越具体、越靠近当前任务,优先级越高”来理解。
Chrome 插件
Chrome 插件带来的变化,不只是让 Codex 多了一个打开网⻚的入口。
它解决了过去浏览器任务中的三个问题。
第一个变化:可以使用现有登录状态
很多真实工作都发生在需要登录的网站里。
例如:
Gmail
Google Drive
LinkedIn
Salesforce
企业后台
项目管理系统
公司内部工具
展开可复制文字
使用独立浏览器时,Codex 通常无法直接使用你在 Chrome 中已经登录的账号。
Chrome 插件连接的是你当前使用的 Chrome Profile,也就是包含现有登录状态和浏览器环境的用户配置。
因此,Codex 可以在获得网站权限后,操作你已经登录的网站。
需要注意:
使用登录状态不等于把所有密码直接交给 Codex。
官方文档目前确认的是 Chrome 插件可以使用已登录的浏览器环境,并且 Chrome 会显示扩展所申请的权
限。
不要把它简单描述成“Codex 会自动导入并读取你的所有密码”。
更准确的理解是:
Chrome 扩展在用户授权的 Chrome Profile 中执行网⻚任务,网站权限和敏感操作仍然受到 ChatGPT 的确
认机制控制。
第二个变化:浏览器任务可以跨多个标签⻚
很多浏览器任务不可能只在一个⻚面内完成。
例如做竞品分析时,可能需要同时打开:
三个竞品官网
一个价格⻚面
一个产品说明⻚面
一个内部记录表
一个最终填写结果的后台
Chrome 插件可以让 ChatGPT 在任务中打开和管理多个标签⻚,并通过标签⻚组整理当前任务使用的⻚面。
这意味着 Codex 可以完成更接近真实人工操作的浏览器流程:
1. 打开多个信息来源。
2. 在⻚面之间切换。
3. 提取和比较信息。
4. 把结果填写到另一个系统。
5. 回到原⻚面复核。
6. 汇总最终结果。
多标签⻚真正重要的地方,不是“同时打开很多网⻚”。
而是让 Codex 可以在多个网站之间搬运、对照和验证信息。
展开可复制文字
第三个变化:可以处理浏览器下载和文件上传
Chrome 扩展申请的权限可能包括管理下载。
因此,在任务需要时,ChatGPT 可以操作与下载相关的浏览器流程。
例如:
下载一份网⻚报告。
获取后台导出的 CSV。
保存发票或对账文件。
下载产品图片。
获取网站提供的附件。
如果任务需要从电脑上传文件,还需要在 Chrome 扩展设置中开启:
Allow access to file URLs
也就是“允许访问文件网址”。
开启路径大致是:
1. 打开 Chrome 扩展管理⻚面。
2. 找到 ChatGPT 扩展。
3. 打开扩展详情。
4. 开启“允许访问文件网址”。
5. 重新开始浏览器任务。
这一权限只应该在确实需要上传本地文件时开启。
如果任务只是阅读网⻚或操作在线系统,就没有必要额外扩大文件访问范围。
怎么安装 Chrome 扩展
1. 打开 ChatGPT 桌面应用,在 W ork 或 Codex 中进入“插件”。
2. 添加 Chrome 插件,并按照引导安装对应的 Chrome 扩展。
3. 在 Chrome 中确认扩展显示“已连接”。
4. 新建一个 W ork 或 Codex 任务;需要调用现有 Chrome 登录状态时,可以在提示词中使用 @Chrome。
Chrome 扩展适合处理必须使用现有登录状态的网⻚。对于本地开发服务器、文件预览或不需要登录的公开
⻚面,优先使用 ChatGPT 内置浏览器,可以减少对个人 Chrome Profile 的访问范围。
导入浏览器资料是另一项可选设置
ChatGPT 内置浏览器设置中还提供 URL 打开方式、密码管理和从 Chrome 导入数据等选项。它与安装
Chrome 扩展不是同一件事,也不是使用 Chrome 插件的前置条件。
展开可复制文字
导入密码和 Cookie 会扩大 ChatGPT 内置浏览器可访问的敏感信息范围。只在确有需要、理解系统授权提示
并愿意承担相应⻛险时启用;如果只是让 ChatGPT 操作当前 Chrome 登录会话,应按上面的插件流程安装
Chrome 扩展,并逐站点授权。
展开可复制文字
资料说明:本章根据 O penAI 官方的 Chrome 扩展文档和内置浏览器文档整理。浏览器权限、数据导入
和可用范围可能随版本、计划与工作区策略变化。
