知识工作者的 Codex 使用指南

一份面向高阶用户的实战指南：把 OpenAI 的编码智能体转变为知识工作的“操作系统”，涵盖环境搭建、工作流与七天入门计划。

目录

• 第一部分：理解 Codex
• 第二部分：搭建环境
• 第三部分：Codex 的五个使用层级
• 第四部分：工作流库
• 第五部分：高质量地使用 Codex
• 第六部分：开始行动

Codex 很容易被低估。乍看之下，它像是又一个 AI 编程工具；如果你不是工程师，很自然会觉得它和自己无关。

但这种理解忽略了 Codex 能够实现的巨大可能性。

设想一个周一早晨：你的收件箱里收到了一项“制定产品发布计划”的请求。你打开对应的 Codex 项目，把任务简报交给它，然后合上笔记本，让 Codex 在云端继续工作。通勤路上，你在手机上收到通知：Codex 已经读完相关 Slack 讨论，从 Google Drive 提取了客户笔记，检查了 PostHog 里的上季度数据，并开始在共享 Notion 文档中撰写市场进入计划。它只需要你确认一个时间安排细节；你点个赞完成确认。等你到工位时，一份等待审阅的草稿已经准备好了。

这就是智能体原生（agent-native）的知识工作。整套流程由 Codex 桌面应用中的 OpenAI 智能体驱动。本指南中提到“Codex”时，均指该应用。

Codex 是一个让你与 AI 智能体共同工作的工作空间。你为它授予完成任务所需的文件、应用和工具访问权限；它会收集需要的上下文，调用已连接的工具，并推进任务。使它适合写代码的同一套能力，也能应用于非常广泛的知识工作。

在 Codex 中与智能体协作，主要有两种方式：委派（delegate）与协作（collaborate）。

• 委派：适用于可预测、可重复、低风险的任务。只要给出清晰且具体的指令，智能体就可以自主执行，完成后将成果交给你审阅。
• 协作：适用于需要判断、探索或多轮迭代的任务。你与模型共同推进，直到结果符合你的设想。

AI 现在已经能够完成许多过去需要专业技能的工作，这既创造了更多机会，也带来了更多噪声。最会使用 AI 的人，懂得哪些事情该委派，哪些决定必须由自己做。他们不是被模型淹没，而是在“驾驭模型”。

熟练的 Codex 用户，就是这种工作方式的鲜明例子。

本指南讲的就是如何成为这样的人：如何搭建工作空间，如何运行高杠杆的知识工作任务，以及如何把重复劳动沉淀为能够随着时间持续变好的系统。假如你已准备好不再把工作看成一次次孤立任务，而是看成不断循环、不断改进的过程，那么这份指南就是为你准备的。

你不需要一次性掌握 Codex 的每一项能力。先了解有哪些能力可用，再按照自己的舒适度、信任程度和审阅结果的能力，选择适当的委派、定制和自动化层级。层级更高不等于一定更好；正如 Every 的《AI 采用的八个层级》所指出的，成熟用户会依据任务本身，在不同层级之间灵活切换。

第一部分：理解 Codex

Codex 是什么

Codex 是一个智能体式工作空间：你给它一个目标，它会规划工作、调用可用工具与上下文，并产出供你审阅的结果。它可以读取和写入你打开的项目文件夹中的文件；可以通过插件与应用连接外部服务；可以运行多步骤工作流；可以在任务需要时生成代码和脚本；也可以创建文档、电子表格、演示文稿、PDF 和网站。

Codex 可以：

说明

• 与你并行处理多项任务
• 从你连接的应用和文件中提取上下文
• 当任务需要屏幕操作时，使用受支持的浏览器与桌面工作流
• 在具备所需上下文、工具和权限时，自检并向既定目标迭代
• 在长时间运行的会话中保持一个持续目标，而不是把每条消息都当成一次孤立请求
• 把可重复任务转为定期运行的工作流
• 把可复用指令封装成 skills 与可安装插件
• 将计划、报告和工作材料制作成可托管的 Sites
• 当 Codex 在已连接电脑上运行时，让你用手机发起、引导和审阅工作

这些能力使 Codex 既适合委派边界明确的任务，也适合作为人机协同的共享工作空间。最关键的判断，是为每项任务决定采用哪种模式。

需要了解的核心功能

本指南中的组织能力主要由五项 Codex 功能承担。它们很容易被混淆，但分别解决不同问题：**项目（Projects）**保存共享上下文，**线程（Threads）**隔离单项任务，**目标（Goals）**持续追踪长期目标，**插件（Plugins）**添加可复用能力，**站点（Sites）**把工作转化为共享界面。

项目（Projects）

一个项目会把某个特定文件夹及其中的指令，作为一个或多个线程的工作上下文。对于每个持续开展的工作领域，例如一次产品发布、每周报告、招聘流程，都应建立一个项目，这样其中的线程就可以使用同一批源材料和规则。

请把长期有效的决定、当前状态、来源链接等信息存入项目文件，而不要依赖某一段对话“记住”它们。

线程（Threads）

线程是在项目内围绕某项任务或一条思路展开的一段对话。当任务发生变化，或者对话已经难以浏览时，应新开线程。长线程会积累噪声，Codex 可能通过总结关键信息来压缩它们；项目文件则负责在不同对话之间保存重要信息。

不同线程不会自动共享对话历史，也不会自动向彼此汇报。它们仍可通过多种方式协同：

说明

• 直接消息：当线程管理工具可用时，可以让 Codex 找到指定名称的线程并向其发送后续提示。应在消息中说明决策、来源链接、预期答复，以及接收线程应该把结果保存到哪里。接收线程只会获得这条消息及自身项目上下文中包含的信息。
• 共享项目文件：一个线程把简报、状态更新或来源地图写入项目，另一个线程读取该文件。这是在线程间传递信息最可靠的方式，因为你可以准确检查共享了什么。
• 分叉（Forking）：当一条新工作线需要继承此前已完成的对话历史时，可以从当前线程分叉。分叉后的线程会独立发展。
• 子智能体（Subagents）：当一个父任务可以拆分为多个边界明确的部分、并且最终要汇总为一个结果时，可使用子智能体。父任务可以分发后续指令、等待结果，并整合各部分。
• 自动化（Automations）：当同一段对话需要按时间表被唤醒，并持续推进某个循环时，可附加线程自动化。

一个实用的交接提示词是：

“找到名为 [名称] 的线程。向它发送以下更新：[决策和来源]。要求它完成 [边界明确的任务]，把结果保存到 [位置]，并在可供审阅时向我反馈。”

对于重要工作，不要假设交接已经成功；应检查另一个线程或共享文件。

目标（Goals）

Codex 中通过 /goal 命令启动的目标，是面向较长任务的持续性目标。你需要告诉它“完成”的标准、成功应如何验证、以及必须遵守哪些约束。Codex 会持续朝该结果工作，直到完成、暂停，或需要你的输入。随着工作变化，你可以暂停、恢复、编辑或清除目标。若无法使用 /goal，可能需要先启用 Goals 功能。

当一个任务终点明确、但需要许多步骤才能完成时，适合使用 /goal。例如“所有事实性主张都要给出处”“遵循品牌文风”“未经我审阅绝不发送”等长期规则，应放在项目文件或可复用 skill 中。

目标与 skill 的区别是：skill 教会 Codex 如何处理一种反复出现的任务；目标则定义你在一段较长工作中想完成什么。目标达成后，它就结束了。

插件（Plugins）

插件是围绕某种可复用工作流构建的可安装组合包，内部可能包含 skills、应用和 MCP 服务器。在从零开始构建一个常见工作流前，先浏览 Codex 插件目录。流程仍在频繁变化时，先用本地 skill；当流程稳定、且你希望与他人共享时，再将其封装为插件。若工作流依赖成套应用或 MCP 服务器，插件尤其有用。

安装插件并不意味着插件获得无限权限。其应用和 MCP 服务器仍受各自身份验证、权限、隐私规则及工作区政策的约束。能够安装哪些插件，还会受到套餐、地区和工作区设置影响。

站点（Sites）

Sites 能把计划、报告、仪表盘和其他工作材料转成托管网页或 Web 应用。当多人需要一个能记住进度、并支持重复任务的共享工作空间时，适合用 Site；若大家只需要阅读，则保留为文档即可。配置了持久化存储后，Site 可以保存工作进度。

应先手动跑通底层工作流。确认确实需要 Site 后，在部署前保存一个供审阅的版本。每一个部署 URL 都属于生产部署，因此在扩大访问范围前，必须检查内容、数据处理方式、访问设置和目标受众。Site 可以限制为工作区管理员可见、工作区全员可见，或仅对指定成员与群组开放。

说明

移动端 Codex

Codex 的移动端访问能力允许你通过 ChatGPT 移动应用，远程控制主机上的 Codex 应用。移动端适合完成工作流中较轻量的环节：你可以随时启动任务、回答问题、批准操作或审阅草稿。已连接的主机必须保持唤醒、联网、运行最新版 Codex 应用，并登录同一账号与工作区。较重的审阅工作仍应使用更大的屏幕。配置要求请参考 OpenAI 的远程连接指南。

Codex 不是什么

Codex 需要监督。它不能替代品味、判断、责任承担、人工审阅或事实核验。当源数据不可访问、成功标准完全主观，或者出错后果严重时，应避免让它自主运行。

实用规则

若一项任务至少具备下列特征中的两项，就很适合交给 Codex：

• 需要从多个来源提取数据
• 涉及你经常重复执行的步骤
• 可以依据客观标准验证
• 会产出长期可保存的成果，例如文档、计划、报告或脚本
• 需要综合大量输入信息
• 足够令人厌烦，以至于你经常拖延或回避

说明

当任务具备以下特点时，适合委派：

• 可重复
• 客观
• 容易验证
• 低风险

当任务具备以下特点时，适合与 Codex 协作：

• 有歧义
• 强依赖判断
• 需要探索
• 需要迭代

Codex 的知识工作闭环

每一个可持续的 Codex 工作流都遵循同一个五步模式：

说明

连接 → 提供上下文 → 委派 / 协作 → 审阅 → 复利沉淀

连接（Connect）： 让 Codex 访问你工作中使用的系统，例如 Gmail、Slack、Notion、Google Drive、日历、分析工具、客服平台或本地文件。没有已连接应用或来源访问权限时，Codex 只能使用它可访问的本地与项目文件、已上传或链接的材料，以及你在当前线程中提供的上下文。建立连接后，它可以检索已批准的来源，而不必依赖你记得往提示词中粘贴什么。

提供上下文（Contextualize）： 将目标、偏好、项目细节、来源链接、审阅标准和长期规则放入 Codex 可访问的文件，并在 Codex 的 AGENTS.md 文件中引用这些文件，使其能方便地读取。这决定了智能体是每次都需要重新听取简报，还是已经理解你是谁、在做什么，以及你偏好的工作方式。

委派 / 协作（Delegate / collaborate）： 判断任务是否需要紧密协作，还是可以自行运行。无论哪种方式，都应明确输入、输出格式和验收标准，然后让它开始工作。

审阅（Review）： 在最终承载结果的目标应用中检查输出。若 Codex 起草的是 Slack 消息，就在 Slack 中审阅；若它写的是战略文档，就在 Google Docs、Notion 或 Proof 等文字处理工具中审阅。终端或 Codex 应用里看起来没问题的内容，放到最终使用场景中可能呈现不同效果。

复利沉淀（Compound）： 将有效做法转为可复用资产。保存提示词，记录工作流，把错误补进审阅清单，并持续更新上下文文件。每次会话都应让之后的会话更快。

第二部分：搭建环境

连接你的系统

连接你希望 Codex 访问的工具，包括 Gmail、Slack、Notion、Google Drive、日历、分析工具、客服平台，以及 Codex 已有集成能力的其他服务。连接相关工具后，Codex 就能查看你真实的工作上下文，并基于消息、文件、会议和重复性任务建议适合的工作流。

连接某个工具，并不等同于授予 Codex 在其中无限制行动的权限。应从支持真实工作流所需的最小权限开始。要求 Codex 在任何已连接工具中修改数据之前先取得批准。插件与应用仍受各自身份验证、隐私、数据共享和工作区政策约束。

说明

Codex 如何接触你的工具

Codex 可以通过多种路径使用同一个工具。分清这些路径，能避免大量混乱：

• 本地文件（Local files）：让 Codex 直接访问你打开项目中的材料。
• 应用（Apps）：将 Codex 连接到 Slack、Gmail、Notion、Google Drive 等外部服务。
• 技能（Skills）：为某类具体任务封装可复用指令、参考资料，有时还包括脚本。
• MCP 服务器（MCP servers）：暴露额外工具或共享信息。
• 插件（Plugins）：把 skills、应用与 MCP 服务器打包为可安装工作流。
• 浏览器使用（Browser use）：在应用内浏览器中操作本地预览、由文件支持的页面和允许访问的网站。已登录网站通常需要 Chrome 扩展或其他已认证界面。
• 电脑使用（Computer use）：在支持的情况下，于桌面界面中点击和输入。这类任务可能影响项目文件夹外的文件和设置，因此应尽量缩小其操作范围。

基本原则：优先选择结构化程度最高的路径。先使用本地文件或应用连接；只有任务确实依赖界面操作时，才使用浏览器或电脑控制。

在集成配置完成后，可使用以下初始提示词：

提示词

连接我工作中使用的工具：[列出你的工具——Gmail、Slack、Notion、Drive 等]。然后分析我在这些工具中的工作模式，并建议我最应该优先搭建的三个工作流。对每个工作流，请说明输入来源、输出成果、运行频率、批准方式，以及什么条件能使这个工作流值得长期保留。

工具连接后，Codex 能分析你的真实工作，并建议有价值的工作流。但“重复出现”本身并不意味着任务一定应自动化。

构建你的 Codex 工作空间

在运行任何工作流前，先构建 Codex 的工作空间。跳过这一步，很容易在后续卡住。

Codex 工作空间是一个文件夹：它可位于本地，也可以在需要版本控制时同步到 GitHub。这个文件夹包含 Codex 所需的指令、上下文文件、工作流文档、来源材料与审阅标准。你可以把它理解为一本同时供你和智能体查阅的入职手册，以及一个工作档案柜。

不要一开始就自己设计整套归档体系。先让 Codex 对你进行访谈：

提示词

我希望你帮助我为知识工作创建一个工作空间。

请一次只问我一个问题，依次了解我的角色、职责、进行中的项目、重复性工作、来源系统、协作者、输出格式、工作偏好、审阅标准和安全边界。

访谈完成后，请总结你学到的信息，并提出一个便于你我共同浏览的工作空间结构。解释每个顶层文件和文件夹的用途。在我批准方案前，不要创建、移动、重命名、归档或删除任何内容。

若你已经有现成的文件体系，可让 Codex 检查它，并提出最小且有用的补充方案。你不需要把所有工作都迁入一个新的“AI”文件夹。保留当前的事实来源，并清晰地向 Codex 标明它们的位置。

示例工作空间结构

your-workspace/
├── README.md                  # 从这里开始：工作空间导览
├── identity/                  # 关于你自身的信息
│   ├── context.md
│   ├── preferences.md
│   └── rules.md
├── playbooks/                 # 流程：可重复工作流
│   ├── workflows/
│   ├── inbox-sweep.md
│   └── research-brief.md
├── sources/                   # 来源架：输入材料
│   ├── sources/
│   ├── key-links.md
│   └── recurring-docs.md
├── outputs/                   # 已完成成果
│   ├── outputs/
│   ├── drafts/
│   └── reports/
└── reviews/                   # 质量检查：护栏
    ├── data-checklist.md
    └── writing-checklist.md

你在做的事情有一个名字：上下文工程（context engineering）。它指的是安排指令和来源材料，使 Codex 能在正确的时刻找到正确的信息。

Codex 会在开始工作前读取 AGENTS.md。根目录中的文件应保持简短：帮助智能体了解工作空间、指明权威文件，并列出整个工作空间通用的规则。更详细或项目专属的指令，应放入其所管理文件夹内部、更靠近任务的 AGENTS.md 中。Codex 会组合适用文件，并以更具体的指令为准。

只有在支持文件确有价值时才保留它们。context.md 可以解释你是谁、正在做什么；preferences.md 可以说明你希望如何处理工作；rules.md 可以定义批准边界；STATUS.md 可以记录当前优先级和未决事项。一个保持更新的小型工作空间，胜过一套无人维护的复杂体系。

说明

上下文文件应包含什么

context.md 应涵盖：

• 你的角色，以及你负责的业务职能
• 活跃项目及其当前状态
• 你每天使用的工具，以及每个工具的用途
• 你最紧密合作的人员或团队
• 在你的工作环境中，决策通常如何产生

preferences.md 应涵盖：

• 写作风格与语气，例如正式或口语化、简短或详尽
• 沟通偏好，例如哪些内容你希望在发出前亲自审阅，哪些可以先起草并排队等待处理
• 决策偏好，例如什么时候应先询问，什么时候可以先执行再汇报

rules.md 应涵盖：

• Codex 未经明确批准绝不可执行的操作：发送、发布、归档、删除、修改事实来源，或转移资金
• Codex 无需询问即可执行的操作：起草、总结、研究、列提纲、整理
• 你的工作特有的长期约束，例如客户保密规则、品牌标准、数据处理要求

让 Codex 创建工作空间结构时，可使用以下初始提示词：

提示词

将此文件夹配置为一个简洁的、用于知识工作的 Codex 工作空间。先创建一份简短的根目录 AGENTS.md，说明此工作空间的用途、哪些文件是权威来源、重要工作应如何验证，以及哪些操作需要得到我的批准。仅创建已批准方案所需的上下文、偏好、状态、来源地图、工作流与审阅支持文件。

完成前，请通过向我解释我的角色、当前优先级、事实来源和批准规则来测试这套配置。标记任何缺失、相互矛盾或难以找到的信息。

第三部分：Codex 的五个使用层级

Codex 的高级用户并不是一步到位的。他们会分阶段成长，而每个阶段都要求你以不同方式理解 Codex 在做什么、擅长什么。若跳得太快，你会感到挫败：要么是你还不够信任它，要么是还没有为更自主的工作搭好基础设施。在每一个层级，你都应知道何时把工作交给 Codex，何时作为协作者继续参与。

请把这些层级理解为一把“复杂度阶梯”，而不是身份等级。第 1、2 级是合理的入门范围；第 3 级属于中阶；第 4、5 级属于进阶。即使经验丰富的操作者，也可能把高风险工作保留在第 1 级，因为密切审阅本来就是正确设计。

第 1 级：一次性知识工作

心智模型： Codex 是能力强、做事细致的研究与起草助手。

模式： 协作。在这个层级中，没有任何事情被自动化。你运行单次会话任务，在成果离开你手中前审阅全部内容，并逐步熟悉 Codex 对不同类型工作的处理方式。

最适合开始的任务：

• 总结会议转写，并提取决策、待确认问题与后续行动。
• 将散乱笔记整理为结构化大纲。
• 根据一组链接和文档形成研究简报。
• 依据风格指南改写草稿。
• 为文档、发布计划或战略备忘录创建审阅清单。
• 将书面草稿转为音频，以便在路上编辑。

提示词模式：

提示词

使用附上的 [文档 / 链接 / 笔记]，产出 [具体成果]。准确性优先于文采。所有事实性主张均需附上来源链接。请标记任何不确定之处，或任何需要我核验的内容。最后列出在这份成果可正式使用前，我应该回答的三个问题。

审阅习惯： 在润色任何输出前，先让 Codex 列出它作出的假设，以及它最不确定的地方。这样能在你投入时间精修之前暴露问题。

何时进入第 2 级： 当你不断希望 Codex 能记住上次告诉它的内容时。

第 2 级：多来源工作流

心智模型： Codex 是一个跨系统分析师，能整合你在合理时间内无法手动汇总的信息。

模式： 协作。在这一层，Codex 可综合多个已连接系统中的输出，例如 Slack 线程、Notion 页面、邮件档案、分析仪表盘和 Google Drive 文档，但仍需要你的引导与反馈。

多来源任务示例：

• 根据内部会议转写、Slack 讨论、客户笔记和战略模板形成市场进入计划。
• 根据分析数据、营收数据、客服量和社媒指标生成每周 KPI 报告。
• 综合 Slack、Notion、Drive 链接和既有草稿形成摘要。
• 从团队站会、指标与未决决策中整理一份每周管理层简报。

如何委派多来源任务：

提示词

我需要 [具体成果]。

使用以下来源：

• [工具 1]：[在其中查找什么]
• [工具 2]：[在其中查找什么]
• [工具 3]：[在其中查找什么]

输出格式：[描述你想要的结构]。

开始前，请先给我一个简短计划：说明你将检查哪些来源、产出什么成果、预计会遇到哪些缺口或未知项，以及在宣布任务完成前将执行哪些检查。若任何步骤需要发送、发布、归档或修改事实来源，必须先询问我。

关于数据的警告： 一次性从多个系统拉取数据，可能因数据过期、定义不一致、权限缺口或关联错误而出错。任何会影响业务决策或智能体行动的指标，都应逐列与主数据源核验。一个数字越接近事实来源，越值得被仔细检查。

让输出可被智能体读取： 你在 Codex 中生成的计划和报告不仅会被人阅读，也越来越会被其他人的智能体读取。请使用清晰、结构化、可快速浏览、可被查询的语言。明确的章节标题、显式写出的决策和带标签的行动项，会让成果同时适用于人和智能体。

何时进入第 3 级： 当你每周不止一次运行同一个多来源工作流，并开始希望它能自动发生时。

第 3 级：定期工作流

心智模型： Codex 是一层自动化运营能力，替你处理可预测、周期性出现的工作。

模式： 混合模式。有些任务完全可预测，无需来回沟通，适合委派；涉及判断、战略或创意决策的任务，则更适合协作。

一个实用判断法： 如果清单能覆盖大多数情况，就委派执行；如果你每次都需要以不同方式思考任务，就采用协作。

无论采用哪种方式，都应寻找“电脑杂务”——那些持续占用时间和注意力、却不需要人在每一个触点上作判断的重复任务。

常见的杂务候选项：

• 每日下班前检查未回复的 Slack 消息和邮件，并起草回复。
• 从分析、营收和客服数据中生成每周指标简报。
• 每次录音会议后，清理会议笔记并提取行动项。
• 识别客服问题模式并路由问题。
• 将草稿整理为可交接给编辑审阅的版本包。
• 为开放岗位进行招聘研究。

工作流模板：

在创建任何持续运行的工作流前，先填写以下模板。把它保存为 Codex 每次运行该工作流时都应读取的指令文件。第四部分的每个工作流都是这一画布的具体示例。

说明

工作流名称：

触发条件或运行频率：

输入来源：

输出成果：

批准规则：

Codex 无需询问即可做什么：

Codex 必须先询问才能做什么：

验证步骤：

最终输出保存在哪里：

何时应停用或修订此工作流：

自动化工作流的审阅纪律： 不要只在 Codex 内部审阅自动化输出。应在目标应用中审阅：Slack 消息在 Slack 中看，邮件草稿在 Gmail 中看，文档在文字处理工具中看。输出在最终使用工具中可能呈现不同效果，而切换场景常能发现问题。

何时进入第 4 级： 当提示词驱动的工作流碰到天花板——任务过于复杂或高度定制，单靠文本无法可靠完成，而一个小脚本或本地工具能让它更稳定时。

第 4 级：自定义工具

心智模型： Codex 是一个构建者，能够搭建轻量级基础设施，使你的工作流更可靠、更快或更容易重复。

有时，最好的 Codex 输出不是一段纯文本，而是一个小脚本、本地应用、自定义仪表盘或审阅界面，让重复工作流变得更简单。

模式： 混合模式。有些情况下，Codex 可以独立生成一个成果供你审阅，然后继续下一步；另一些情况下，它产出的工具本身会成为你与智能体共同迭代的空间。

适合使用小工具的情形：

• 重复性工作流需要调用一个没有 Codex 集成的 API；一段短脚本能可靠地处理连接。
• 审阅流程需要把格式化输出与来源并排查看；一个简单本地应用可以提供这种视图。
• 任务需要定时运行；当你先手动验证提示词，并定义权限、审阅与失败处理方式后，Codex 自动化可以负责运行。
• 工作流会随时间积累结构化数据；轻量数据库或结构化文件可以持续跟踪。
• 报告或审阅队列已经不适合继续放在文档中；Site 可以给团队提供查看工作的共享空间，小应用则能保存进度并让人批准或拒绝事项。

非工程师的实用做法：

1. 先在 Codex 中手动运行一次任务，确认输出确实符合预期。
2. 问 Codex：“这个工作流中的哪些步骤，可以通过一个小脚本或工具提高可靠性？”
3. 让 Codex 制作工具原型，并用通俗语言解释它做什么。
4. 用你的真实数据运行，并验证输出与手动流程的结果一致。
5. 只保留真正减少摩擦的部分；没有收益却增加复杂度的部分应丢弃。

你不必理解 Codex 构建工具中的每一行代码，但你应该能够解释输入是什么、输出是什么、以及人应在哪里检查结果。若做不到，这个工具就还不适合自主运行。

当文档或电子表格足以完成任务时，应优先使用它们。若使用 Sites，请在部署前让 Codex 保存一个可审阅版本：每个部署 URL 都是生产部署。在扩大访问范围前，检查内容、数据处理、访问设置和受众。

何时进入第 5 级： 当你反复向 Codex 给出同类反馈，并且有长期偏好希望它能自行应用时。

第 5 级：能够复利增长的系统

心智模型： 当你保存有效工作流、维护审阅规则，并在可用时借助记忆或 skills 固化偏好，Codex 就会成为一个能够随时间不断改进的系统。

模式： 混合模式。一些指令决定智能体应如何开展自主工作，另一些指令引导模型在协作模式下如何与你互动。

“复利式工作”的想法来自复利工程（compound engineering）。这是 Kieran Klaassen 与 Nityesh Agarwal 在构建 Every 邮件客户端 Cora 时提出的一套 AI 原生编码方法论。典型例子是一份产品需求文档（PRD）为下一份 PRD 写好脚手架：你产出的成果，会变成加快下一轮工作的工具。下面四个习惯说明知识工作者如何将这种方法落地，而不只是工程师。

每一次有价值的会话，都应让未来的会话更快、更可靠。实践中，这要求你在完成任何重要工作后持续做四件事：

1. 把成功提示词保存为工作流文件。 当某个提示词准确地产出了你想要的结果，就记录它。写明输入来源、原始提示词、输出格式与审阅步骤，并保存到 workflows/ 文件夹。下次需要同类输出时，智能体就有可参考的依据。
2. 把错误加入审阅清单。 当 Codex 出错——例如数字不对、语气不合适，或作出了不该作出的假设——就在相关审阅文件中加入一条具体检查，并要求 Codex 按这些护栏自检。
3. 在重大项目后更新上下文文件。 项目结束时，更新 context.md 来反映变化：新优先级、新工具、有效做法与无效做法。你在下一次可将该文件指给 Codex，或把它转为可复用 skill / 工作流。
4. 让 Codex 识别可复利的机会。 在任何一次完成有价值工作的会话末尾，运行以下提示词：

提示词

根据我们刚刚完成的工作，这个工作流中的哪些部分应变成可复用 skill、自动化或小工具？我应在项目文件中补充哪些上下文，避免下次重新建立这些信息？

当一个工作流稳定到适合分享时，只有在插件目录中不存在同类方案的前提下，才考虑自行打包。Every 的复利工程指南说明了：一个持续维护的插件可以封装一套完整工作方法，而不是只封装单个提示词。

第四部分：工作流库

这些工作流用于帮助你起步。请根据自己的工具、标准和批准规则，调整其中的输入、输出与步骤。

选择能够完成任务的最低复杂度工作流。Every 已在内部测试了更多示例，并将其改写为不依赖私有系统的形式。若想了解原始工作流库背后的更多实践背景，可阅读《一个应用统治所有知识工作》与《Codex 原生应用的黎明》。

1. 收件箱清零审阅队列

最适合： 邮件积压经常让你焦虑，或导致事项遗漏的人。

输入来源： Gmail 或你选择的邮件客户端。

输出成果： 一份结构化清单，包含回复草稿、建议操作（归档、委派、标记），以及那些仅有草稿仍不足够、需要你亲自关注的邮件。

Dan Shipper 曾借助 Codex 连续 10 天保持收件箱清零。要运行这一工作流，可让 Codex：

1. 通过应用内浏览器中运行的 Cora 收集邮件。
2. 将邮件队列渲染为一个单独页面。
3. 与你逐项处理；你口述希望 AI 执行的操作，例如“研究这件事”“起草那个回复”“找出律师要求的文件”。你可以通过聊天完成，也可以用 Monologue 一类语音听写工具完成（原文更推荐后者）。

首个提示词：

提示词

检查我过去 [时间范围] 的收件箱。

对每一封需要回复或行动的邮件：

1. 进行分类：需要回复 / 需要行动 / 可以归档 / 已处理
2. 如需回复，请按照 preferences.md 中的风格，以我的口吻起草回复
3. 如需行动，请清楚描述要执行的行动
4. 标记任何仅靠一封回复草稿不够的邮件——即我必须亲自思考后才能回应的事项

不要发送任何内容。只创建草稿。我会在 Gmail 中审阅。

审阅步骤： 在发送前，于 Gmail 中审阅全部草稿。不要只在 Codex 内部批准。

如何形成复利： 运行数次后，新增一份规则文件，描述你的分类偏好：哪些发件人永远优先、哪些主题无需回复即可归档、哪些请求必须由人亲自撰写回复。

2. 每日未回复消息汇总

最适合： 同时通过 Slack、邮件和其他渠道沟通，且容易忘记哪些消息还没回复的人。

输入来源： Slack、Gmail 以及其他你使用的沟通工具。

输出成果： 按紧急程度排列的未回复事项清单，其中包含回复草稿或建议反应。

首个提示词：

提示词

查看我过去 24 小时内的 Slack 和 Gmail，找出所有直接发给我、但我尚未回复的内容。

对每一项：

1. 若简短确认即可，请起草回复或建议一个反应（例如点赞）
2. 标记需要更周全回应的事项
3. 标记所有有时间敏感性的事项

按紧急程度整理成清单。不要发送任何内容。

审阅步骤： 在 Slack 与 Gmail 中审阅。

如何形成复利： 多次运行后，保存一份规则文件，明确哪些 Slack 频道优先级高、哪些发件人必须由人回复、哪些消息类型可以用反应代替文字回复。

3. 研究简报

最适合： 需要为会议、提案、内容创作或战略决策准备某个主题的深入且带来源依据的总结的人。

输入来源： 你提供的链接、Notion、Drive、网页搜索。

输出成果： 一份结构化简报，包含背景、关键事实、开放问题与来源链接。

首个提示词：

提示词

围绕 [主题] 制作一份研究简报。

优先使用的来源：[列出指定链接、文档或数据库]。

请按以下结构组织：

• 背景：为了就此进行有价值的交流，我需要了解什么
• 关键事实和数据点：每一项均附来源链接
• 该领域中相互竞争的观点，或重要分歧
• 在 [会议 / 决策 / 截止日期] 前，我应该能够回答的开放问题
• 若我希望继续深入，还应阅读的三项内容

标记任何你把握不足的主张。

审阅步骤： 检查来源链接。使用任何统计数据前，先与原始来源核对。

如何形成复利： 在 workflows/ 文件夹保存简报模板。每次完成简报后，将重复出现的来源（新闻简报、数据库、关键作者）补入 sources/key-links.md，让 Codex 默认检查它们。

4. 写作审阅循环

最适合： 希望在写作时让 Codex 同步陪跑——检查内容、标记问题、并行反馈，却不打断写作节奏的作者。

输入来源： 以文件形式保存或位于受支持审阅界面中的草稿，以及工作空间中的相关风格指南、来源文档与审阅标准。

输出成果： 一份带行内反馈、问题标记与修订建议的注释稿；它随写作过程持续生成，而不是只在最后统一做一次审阅。

配置方式：

在 Proof 中打开草稿，或让草稿作为项目文件可被访问。启动一个已加载工作空间上下文的 Codex 会话，并为 Codex 设定要监测什么、如何回应的长期规则。

首个提示词：

我正在撰写 [描述文章：类型、受众、目的]。

提示词

当我写作时，请运行持续审阅循环，检查：

• 需要来源支撑，或陈述语气强于证据支持程度的主张
• 论证变得不清晰、或逻辑出现断裂的段落
• 违反 preferences.md 中风格偏好的句子
• 看起来像填充语、无意义铺垫或 AI 生成腔的内容

未经我要求，不要改写任何内容。随着我写作，用简短说明标记问题，指出问题是什么、怎样可以修正。每隔 [X 分钟 / X 段] 或在我要求时向我汇报。

审阅步骤： 在自然停顿点——例如一个章节或一段写作结束时——阅读标记的问题，决定哪些要处理、哪些可以忽略。不要让反馈循环中断写作流；它的价值在于持续累积，而不是实时回应每一个标记。

如何形成复利： 每次写作后，将重复出现的标记补入 reviews/writing-checklist.md。反复出现的模式，可以成为偏好文件中的长期规则，让 Codex 下次主动检查。

5. 写作研究的来源管理

最适合： 需要在起草前整理来源材料的作者与研究人员。

输入来源： 链接、PDF、旧草稿、笔记、转写文本。

输出成果： 一份结构化文档，其中包括核心论点、按主张组织的支持证据、反方论证，以及缺口分析（还缺什么）。

首个提示词：

提示词

我正在写一篇关于 [主题] 的文章。我想提出的核心论点是 [论点]。

这是我的来源材料：[链接 / 文档]。

请建立一个“证据室”，并做到：

1. 清晰陈述核心论点
2. 为每个主要观点列出最强的支持证据，并附来源链接
3. 列出最强的反方观点，以及我可能如何回应
4. 识别所有缺口——即我正在提出、但缺乏强证据支撑的主张
5. 标记彼此冲突的来源

审阅步骤： 起草前先阅读证据室。对你计划直接使用的统计数据或引用进行核验。

如何形成复利： 将证据室格式保存为工作流模板；在上下文文件中加入有关你写作声音与常见主题的长期说明，使 Codex 能校准其表达框架。

6. 音频简报

最适合： 听比读更容易处理信息的人；或希望离开屏幕但仍能掌握工作进展的人。

输入来源： 任何书面材料，包括草稿、研究简报、会议总结、战略文档、报告、长邮件和文章。

输出成果： 保存到手机可访问位置（Dropbox、Drive 等）的音频文件。

首个提示词：

提示词

将附上的 [文档 / 草稿 / 报告] 转换为清晰的音频文件。请以自然语速朗读：不要太快，也不要太慢。将它保存到 [Dropbox / Drive 位置]，文件名为 [文件名]。

审阅步骤： 在通勤、散步或其他离开屏幕的时间收听。想到问题时在手机上记笔记，再带着这些发现回到原始材料。

如何形成复利： 在上下文文件中加入你的音频偏好，例如速度、文件格式、命名规则与默认保存位置，以便不必每次重复说明。你也可以在某些工作流结尾让 Codex 自动转换内容，例如：“生成每周指标报告后，将其转成音频并保存至 [位置]。”

7. 市场进入（GTM）计划

最适合： 负责推出产品、功能或项目，已经在会议和 Slack 中完成思考，却尚未有时间将其正式成文的人。

输入来源： 会议转写、Slack 线程、客户笔记、常用战略模板。

输出成果： 一份完整的市场进入计划，既方便人审阅，也方便智能体查询。

首个提示词：

提示词

为 [产品 / 项目] 制作一份市场进入计划。

请从以下来源提取信息：

• 会议转写：[Notion 位置或链接]
• Slack 讨论：[频道或搜索关键词]
• 客户研究：[文档或位置]
• 需要遵循的模板：[链接或粘贴模板]

这份计划应让人能在五分钟内读懂，并具有清晰结构，使智能体能够回答其中的具体问题，例如“目标 ICP 是谁？”“发布时间线是什么？”

先进行一步复利工程头脑风暴。请在 Proof 或 Notion 中给我草稿。任何你添加、但来源材料中并未出现的内容都要标记出来——我只希望整合已作出的决策，不希望未经审阅就把新的建议写进计划。

审阅步骤： 在 Notion 或 Proof 中审阅。确认每一项主要主张都能追溯到来源材料。模型添加但并非来自来源材料的内容，应明确标记，供你决定。

如何形成复利： 保存模板和提示词。每次发布后，在上下文文件中加入复盘说明：计划中哪些判断正确、哪些错误。未来的计划会根据过去的结果进行校准。

8. KPI 报告

最适合： 负责跟踪指标，并需要跨多个数据来源获得稳定、可靠视图的人。

输入来源： 产品分析（PostHog、Mixpanel、Amplitude）、营收数据（Stripe）、客服量、社媒指标与已保存的历史报告。

输出成果： 一页式报告，涵盖重点摘要、使用指标、系统健康度与后续事项。

首个提示词：

提示词

为 [时间范围] 生成一份产品脉搏报告。

数据来源：

• 产品分析：[工具及应提取内容]
• 营收：[工具及应提取内容]
• 客服：[工具及应提取内容]
• 社媒：[工具及应提取内容]

结构：

1. 重点摘要（3 至 5 条，概括最重要的事情）
2. 使用情况（核心参与度指标、价值实现指标、转化、相对上一周期的变化）
3. 系统健康度（错误率、延迟、主要错误特征）
4. 后续事项（1 至 5 个值得调查、且足以直接行动的问题）

标记任何与上一份报告显著不同的数字。若发现异常，请在写入报告前进一步调查一层。

审阅步骤： 将报告中的每一个数字与其来源核对。在逐列确认准确性前，不要将该报告作为业务事实来源使用。不同口径和错误匹配的记录，可能让报告看起来正确，实际却不正确。

如何形成复利： 将每份报告作为带日期的文件保存到 outputs/reports/。时间一长，Codex 可以比较报告、识别趋势并标记变化；该文件夹会成为产品的工作记忆。

9. 客户支持问题队列

最适合： 希望把客服反馈模式转化为产品决策和小型修复任务的团队。

输入来源： 客服平台（Intercom、Zendesk）、问题跟踪工具（Linear、GitHub Issues）。

输出成果： 去重后的问题清单及建议优先级，以及适合直接交付修复的小问题。

首个提示词：

提示词

检查我过去 [时间范围] 的客服队列。

对每条支持会话：

1. 识别底层问题或请求
2. 检查 [Linear / GitHub Issues] 中是否已有类似问题
3. 若已有，请建立关联；若没有，请起草一个新 issue
4. 标记出现超过 [阈值] 次的问题——它们属于优先事项
5. 对看起来可以直接修复的问题，注明其可作为直接实施候选项

暂时不要在跟踪工具中创建 issue。先把清单交给我审阅。

审阅步骤： 在任何事项进入跟踪工具前审阅问题清单。确认去重准确，因为客服工单往往会用不同说法描述同一个底层问题。

如何形成复利： 每次结束后，记录重复出现的问题类型，使 Codex 下次能更快分类。建立一份持续维护的已知问题清单，让去重能力随时间改善。

10. 面向非工程师的 Pull Request

最适合： 需要对代码库进行小而边界明确的修改，例如文案更新、配置调整或内容编辑，但不具备深厚工程背景的人。

输入来源： 相关文件或代码仓库，以及对修改的清晰描述。

输出成果： 一份便于审阅的 Pull Request（PR），且不触及预期范围之外的内容。

首个提示词：

提示词

我需要做如下修改：[清楚描述变更]。

在做出任何修改前：

1. 向我展示会受影响的文件
2. 确认变更范围——除了这些文件之外，不应触及其他文件
3. 在执行前，用通俗语言解释你准备做什么

完成修改后：

1. 总结修改了什么，以及为什么修改
2. 列出所有被触及的文件
3. 说明你如何验证修改正确
4. 标记审阅者需要重点查看的任何内容

只做最小但有用的修改。不要重构，也不要顺手改进相邻内容。

审阅步骤： 在创建 PR 前先审阅 Codex 预览；再在 GitHub 或代码审阅工具中审阅 PR 本身。若你不确定，应请技术同事在合并前批准。

如何形成复利： 保存一份你偏好的 PR 格式模板。每次 PR 完成后，记录任何需要纠正的地方，使未来 PR 避免同类问题。

11. 招聘候选人短名单

最适合： 需要为某个背景要求明确的岗位开展主动招聘的人。

输入来源： LinkedIn、Twitter/X、公司网站、校友数据库、公开职业社交网络。

输出成果： 一份候选人名单，包含背景概述以及联系信息或可建立联系的切入点。

首个提示词：

提示词

我正在招聘 [岗位]。理想候选人具备 [背景画像——经验、过往公司、技能、职业路径]。

请寻找符合这一画像的候选人。对每位候选人：

1. 用两到三句话概述其背景
2. 说明其为何符合画像
3. 找出任何可建立联系的切入点（共同联系人、互相关注、共同组织）
4. 提供其公开职业主页链接

返回最匹配的前 [数量] 位候选人，并按匹配度排序。

审阅步骤： 在进行任何联系前审阅每位候选人。通过所附主页确认背景概述是否准确。不要通过 Codex 直接发送外联消息。

如何形成复利： 将岗位画像保存为模板。成功招聘后，记录最终录用者的真实背景与初始画像之间的差异，以校准未来搜索。

12. 战略计划

最适合： 希望将 OKR 规划、季度规划或战略复盘从数天压缩至数小时的管理者和运营人员。

输入来源： 历史规划文档、会议转写、管理层上下文笔记、相关指标。

输出成果： 一份可供审阅和迭代的计划草稿或 OKR 集合。

首个提示词：

提示词

我需要为 [范围] 起草 [季度计划 / OKR 集合 / 战略复盘]。

请使用：

• 历史计划：[位置]
• 最近会议转写：[位置]
• 当前指标：[位置或说明]
• 管理层上下文：[文档或说明]

请按 [所需格式] 组织输出。

标记任何你建议、但缺乏来源材料明确支持的目标或举措。我希望整合已作出的决策，而不是未经审阅就写入新的建议。

审阅步骤： 在 Notion 或 Proof 中审阅。在向管理层或团队分享前，确认每一项重大承诺都能追溯到确实已经作出的决定。

如何形成复利： 每个规划周期结束后，将复盘补入上下文文件：目标最终是否可实现？原计划缺少了什么？之后的规划会从过去的结果中受益。

13. 个人学习工具

最适合： 希望用 Codex 支持技能培养、练习或自主学习的人。

输入来源： 外部 API、文件、结构化练习材料、个人笔记。

输出成果： 围绕学习目标构建的自定义交互工具，例如导师、测验或练习环境。

示例：

一位音乐人想练习识别和弦。他连接 MIDI 键盘，描述自己的需求，Codex 便构建一个小应用：它能听取弹奏内容、识别和弦，并持续记录练习进度。

首个提示词：

提示词

我想为 [技能或学科] 构建一个个人学习工具。

我目前的水平：[初学者 / 中级 / 我已掌握的内容]。

我希望练习的内容：[该技能的具体方面]。

我希望获得反馈的方式：[即时 / 每次练习后 / 打分]。

请构建一个可以在本地使用的原型。在我开始前，先解释它做什么，以及如何使用。

审阅步骤： 在真正的练习材料上试用该工具，再决定是否长期使用。验证它是否真的在考察你原本想练的能力。

如何形成复利： 每次练习后，让 Codex 根据你觉得最有用和最没用的部分更新工具。随着需求越来越清楚，工具也会持续改善。

14. 持续生长的创意库

最适合： 编辑选题规划、产品创意、客户需求、研究线索，或任何有用信号会逐步到来的领域。

输入来源： 已批准的频道和文档、公开来源、既有内容，以及一套评分标准。

输出成果： 一个持续维护的待办库，记录证据、状态、重复项与最小下一步行动。

首个提示词：

提示词

为 [领域] 创建一个创意库。对每一个候选项，记录问题或机会、来源链接、已有的相关内容、该创意为何有助于目标受众、当前状态，以及最小的下一步行动。

在添加任何候选项前，都先与现有创意库进行比较。不要因为一个微弱信号就提升某项优先级。保留被拒绝的创意及其拒绝原因。

审阅步骤： 检查来源质量、重复创意，以及标准是否随着时间漂移。一次扫描若没有发现有用内容，应如实说明，而不是为了填满创意库而添加无价值条目。

如何形成复利： 先手动运行收集流程。只有当数据字段、资格规则与审阅过程稳定有效后，再把它转成 skill 或定时扫描。

15. 共享审阅 Site

最适合： 已经不适合继续用文档操作的报告、路线图、来源室、仪表盘和审阅队列。

输入来源： 已验证的手动工作流、当前成果与来源数据、目标用户、所需操作、访问规则与负责人。

输出成果： 先保存一个 Site 版本供审阅；只有在获得批准后才部署。

首个提示词：

提示词

请比较：继续将这项工作保留在文档中、迁移到电子表格中、以及创建一个 Site，分别有什么优劣。请基于以下因素提出建议：谁会使用它、他们需要查看或完成什么、它必须记住什么状态、信息更新频率，以及由谁维护。

若确实需要 Site，请构建并保存一个审阅版本。未经我批准内容、数据处理方式、访问模式与受众前，不要部署。

审阅步骤： 用真实数据和真实任务进行测试。部署前检查来源是否变化、保存的数据、访问设置，以及被选中的保存版本。

如何形成复利： 只有当控件支持某个重复行动时，才增加控件。记录负责人、数据来源、失败时的行为，以及在何种情况下应停用该 Site 的计划。

16. 内容更新队列

最适合： 需要定期更新、但绝不应自动改变的公开页面、知识库、周期性报告或资源列表。

输入来源： 当前成果、已批准来源、明确的“什么值得更新”规则，以及带日期的历史决策记录。

输出成果： 一份建议修改及其支持证据的清单。

首个提示词：

提示词

根据 [已批准来源] 审查 [成果]，找出值得考虑的更新。对每一项建议，请展示当前材料、建议修改、支持证据，以及为什么该更新满足评估标准。

不要编辑或发布任何内容。将每一项建议放入审阅队列。若没有值得更新的内容，请明确报告这一点。

审阅步骤： 在该成果原本应使用的目标位置接受或拒绝每一项建议。发布前核验链接、日期、主张和渲染后的外观。

如何形成复利： 记录你接受与拒绝了什么。系统可以从这些选择中学习，但未经批准绝不应发布。

第五部分：高质量地使用 Codex

如何引导 Codex

高质量地使用 Codex，本质上是一项管理工作。你要评估“人才”（哪些提示词、智能体和工作流值得信任），设定愿景（应该让 Codex 做什么，“完成”应该是什么样子），发挥品味（发现技术上正确、但在当前情境中不合适的输出），并知道何时放手、何时接管。

给 Codex 一个结果目标。描述你最终希望得到什么，而不是规定它每一步该怎么走。例如，“使用这些来源和这种结构，为 [主题] 制作研究简报”，通常比“先搜索 Slack，再搜索 Notion，然后……”产出更好的结果。

对于长时间运行的工作，先要求它提供计划。任何需要几分钟以上、或会触及多个系统的任务，都应让 Codex 在开始前说明它准备做什么。这样可以及早发现误解，并在它走得太远前调整方向。

在开始前问 Codex 它需要什么。对于复杂任务，一段简短的任务简报提示词可以节省时间：

提示词

开始前，请告诉我：还需要哪些额外上下文，能帮助你把这件事做得更好？你最希望知道的关键信息是什么？

对重要主张要求提供引用与审计线索。任何会分享出去、或将用于决策的文档，都应为事实性主张附上来源链接。将这条规则写入你的偏好文件，作为长期要求。

当计划已经合理时，不要微观管理每一步。只有当方法错误、前提发生变化，或 Codex 触及了你尚未批准的边界时再打断它。其他情况下，让它先完成一个连贯的工作回合，再进行审阅。

永远在目标应用中审阅。

在规则文件中明确设置“不可发送、不可发布、不可归档、不可修改”等规则。它们应默认适用于所有敏感工作流。任何难以撤销的行动，都必须要求 Codex 事先询问。

在批准任何重要输出前，请问这三个问题：

说明

生成这份成果时，你做过的最困难决定是什么？

你考虑过哪些替代方案，又为什么排除了它们？

你对哪里最没有把握？

这些问题能暴露模型作出的判断、它放弃的选项，以及最可能存在错误的地方。

安全、信任与风险

常见失败模式及应对方式：

说明

自信地出错。 Codex 可能用很高的自信陈述错误事实。对任何重要事实性主张，都必须回到来源核验。未经核对，绝不要把统计数字或主张转交给他人。

指标错误。 合并多个数据来源容易引入定义不一致与计算错误。对任何用于决策的指标，都应逐列验证。

超出范围的改动。 Codex 有时会修改文件，或顺手优化你所分配任务附近的内容。尤其是涉及代码时，不要只看最终输出；应逐行审阅改动（也称为 “diff”）。

自动化失效。 当工具更新 API、凭据过期，或上下文文件陈旧时，持续运行的工作流会停止工作。每一个自动化都必须有负责人定期检查。“设置后就忘记”不是一种稳定的运行模式。

插件和集成失效。 插件与集成需要维护：权限会过期、API 会改变、配置需要更新，某些变更还需要重启 Codex 或新开线程。如果工作流产出异常，先检查所有预期连接是否仍在工作，再假设是提示词的问题。

使用额度限制。 长时间会话可能碰到使用额度上限，导致任务中途停止。复杂工作流应拆分阶段，而不是试图在一次会话中完成所有事情。

不可信输入。 Codex 读取的任何内容——邮件、网页、共享文档、客服工单——都可能包含面向智能体而不是面向你的指令，其中有些甚至可能对人眼隐藏。若 Codex 在浏览不可信网站或处理外部消息时同时拥有广泛写入权限，这些隐藏指令就可能被转成行动，例如把数据发送到不该去的地方。因此，应将破坏性操作置于审批之后，并为每个工作流授予完成任务所需的最小权限，让被劫持的指令无处可用。

人的最终负责标准： Codex 可以接触工作流中的任何成果，但人必须指挥工作、为输出负责，并能够讨论其中任何具体决策。若有人询问 Codex 起草文档中的某一条要点，你应该能够回答。AI 起草的文档没有问题——甚至应该成为常态——但若有人与你逐项讨论，而显然你根本不知道内容是什么，这就是一个问题。

团队工作流：从个人 Codex 到共享操作系统

个人 Codex 工作流会随时间积累价值；团队工作流的复利更快，但也更需要协同。

团队使用 Codex 后会发生什么

团队对智能体的信任，是通过操作它们的人建立的。当同事收到由 Codex 起草的文档或计划时，他们信任它的程度，取决于他们对分享这份成果的人的信任程度。

让团队 Codex 发挥作用的基础设施

共享审阅界面。 共享文档审阅工具（Proof、Notion、Google Docs）比仅在 Codex 内部审阅，更容易让团队检查与评论智能体生成的文档。

明确交接。 子智能体会向创建它们的任务汇报；定时线程任务也会保留在自身对话中。不同线程不会自动共享更新。当一个线程需要另一个线程的工作成果时，应发送清晰交接，并将结果保存在共享文件或审阅工具中。为每个工作流明确负责人和批准规则。

共享 skills 与插件。 维护良好的 skill 可以封装团队审阅标准；插件可以将工作流与它所需的应用或 MCP 连接一并分发。在要求所有人安装同一套配置前，团队应检查这些依赖项和权限。

共享且可被智能体读取的文档。 同时面向人和智能体编写的计划、战略文档和运营指南，会成为共享基础设施。任何团队成员——或任一成员的智能体——都可以查询其中的具体信息，而不必打断作者。

明确所有权。 每个持续运行的工作流都要有明确署名的负责人。该负责人应监控输出质量、在工作流失效时更新它，并在其不再有用时将其停用。没有所有权的自动化会逐渐退化。

说明

让团队开始使用 Codex 的简单方法

不要试图同时改变所有人。先从某个角色的一个可被清楚识别的问题开始。展示成果物、审阅步骤，以及人仍然负责什么。下面三件事一起做，能让有价值的工作流在团队中传播：

1. 由领导者发出一条说明：使用 AI 是期望，而不只是“可有可无”的加分项
2. 每周召开一次会议，任何人都能展示自己构建的提示词或工作流
3. 定期发布消息，点名表扬工作表现突出的成员

设定期望、给人们分享有效做法的场所、并认可他们的成果——这已经解决了大部分难题。

第六部分：开始行动

七天 Codex 高级用户计划

第 1 天：连接并检查。 安装 Codex 桌面应用，打开一个你愿意作为项目使用的文件夹。连接一两个能够支撑你已经在做的真实工作的来源。运行第二部分中的“工作流发现”提示词。先不要构建或自动化任何东西。

第 2 天：让 Codex 访谈你。 让它提出工作空间结构和一份简短的根目录 AGENTS.md，再加上你真正需要的上下文、偏好、状态、来源地图、工作流和审阅文件。在它修改文件夹前，先批准该方案。

第 3 天：运行三项一次性任务。 选择一项总结任务、一份研究简报，以及一份草稿或计划。使用第 1 级的提示词模式。认真审阅每项输出，并记录 Codex 做对了什么、哪里需要纠正。

第 4 天：建立第一个可重复工作流。 选取第 3 天最有价值的任务，填写第 3 级的工作流画布，并把它保存到工作空间的 workflows/ 中。用不同输入再运行一次，在考虑定时运行前验证输出。

第 5 天：增加审阅规则。 创建 reviews/data-checklist.md、reviews/writing-checklist.md 和 reviews/comms-checklist.md。每份文件先写入 5 条检查项，基于你在第 3、4 天观察到的问题。它们会随着时间逐渐增长。

第 6 天：把一个工作流变成可复用资产。 记录提示词、输入、输出格式、审阅步骤和已知边界情况。只要流程仍在变化，就继续把它保留为工作流文件；当步骤稳定到可复用时，再将它转为 skill。在从零打包常见工作流前，先浏览插件目录。

第 7 天：形成复利。 在 Codex 会话结束时，运行以下复利提示词：

提示词

根据本周我们完成的所有工作，哪些内容应该变成可复用 skill、自动化或小工具？我应该在项目文件中补充哪些上下文，让未来会话从更好的基础开始？

审阅 Codex 的建议，并实施未来一个月内最能节省时间的那一个。

说明

30 天延伸计划

• 第 1 周：一个个人工作流稳定、可靠地运行
• 第 2 周：一个多来源工作流，至少从三个已连接工具中提取信息
• 第 3 周：一个稳定流程被打包为工作流或 skill，并具备明确的审阅规则
• 第 4 周：只有当工作本身确有必要时，才增加一项进阶能力：Site、插件、小工具或自动化

今天就开始： 在 Codex 中打开一个安全的文件夹。选择一项你已经知道如何完成的工作。为智能体提供来源，定义成果，并告诉它你将如何检查工作。先把这一次运行做好，其他能力会从这里逐步生长。

---