LLM Wiki

Appearance

Built 26/04/17 07:54commit f2be6c7

Codex 操作实践 ​

中文 | English

摘要 ​

Codex 更适合作为一个可配置、可复用的队友来运营，而不是一次性助手：任务上下文要先结构化，耐久规则要放进 repo 与用户配置里，重复工作要沉淀成 skills 或 automations，而更高自治的执行面必须配套明确的权限与验证边界。

任务定界与耐久指引 ​

  • prompt 默认应写清 Goal、相关上下文、约束条件，以及明确的 "done when" 标准。
  • 模糊或多步骤任务应先规划，可通过 plan mode、访谈式澄清或执行计划文档实现。
  • 稳定规则不应反复手打一遍，而应转入 AGENTS.md、code_review.md、skills 或仓库内长期文档。
  • 对前端占比高的工作，应把视觉规则沉淀到 DESIGN.md 这类 repo 内设计契约，而不是在任务 prompt 里反复重述品味要求。
  • AGENTS.md 应保持短而可执行：它负责路由，不负责吞下全部细节。

配置面 ​

  • 个人默认值放 ~/.codex/config.toml，trusted project 的项目级行为放 .codex/config.toml。
  • CLI flags、--config 与 profiles 负责一次性覆盖或命名运行模式。
  • approval_policy、sandbox_mode 与 web_search 不是表面设置，而是直接决定 Codex 的权限、风险与工作方式。
  • 在托管环境里，requirements.toml 很关键，因为它能固定或禁止用户无权覆盖的安全敏感选项。
  • sample/reference 文档最适合作为“配置地图”来查，不应整段照抄；只复制真正需要的键即可。

能力打包 ​

  • 当所需上下文在 repo 外、且变化频繁时，用 MCP 比手工粘贴说明更稳。
  • 当某个工作流已经稳定重复时，把它沉淀成 skill；只有需要更广分发或打包 app 集成时，再升级成 plugin。
  • 当团队希望整条工作环保持可读时，具名命令家族很有价值：ideation、planning、implementation、review 与知识复利化都可以暴露成显式操作，而不是混成一种不可检查的 prompt 习惯。
  • 要把 hooks、slash commands、skills、MCP 预算和记忆工作流当作彼此独立的操作面；如果把它们混成一层“配置”，调试和复用都会变差。
  • llm-wiki skill 是一个具体例子：一个维护规范加上一组狭义辅助脚本，就可以把 markdown 仓库变成可重复、可长期运行的工作流。
  • 第三方 harness 仓库也可以把 Codex 做成一级执行面，而不是只留一段兼容性说明：AGENTS.md、项目级 config.toml、role 定义和 skill 布局，都可以与 Claude 面向的资产并行分发，同时保留同一套操作哲学。
  • 生态里的 playbook 也开始把 Codex 作为并列执行面来分发，而不是事后兼容：plugin 转换 CLI、共享工作流目录与 “best practice” 仓库都在朝这个方向发展。
  • bridge plugin 也是一种独立互操作层：另一个 harness 可以把 Codex 暴露成原生 slash commands，用来做 review、委派、后台任务控制，甚至阻塞式 review gate，而不需要分叉底层 Codex runtime。
  • Prompt 控制面目录也开始成为有价值的相邻资产：即使它们直接面向的是 Claude Code 而不是 Codex，也说明成熟操作者工具链正在把内建 prompt 层、slash command 行为、memory routines 与 safety logic 视为可检查的 runtime surfaces。
  • Prompt 组装分析同样重要：它能解释 output style、tool availability、subagents、skills、memory systems、MCP instructions、git state 等运行时条件，究竟如何决定哪些 prompt 片段真的进入一次 live session。
  • 团队级分发与打包语法同样重要：全局安装路径、repo bootstrap 命令以及具名 specialist-role 入口，决定了一套操作模型能否在多位开发者之间稳定复现，而不只存在于某个重度用户的机器上。
  • 只有当任务能被清楚拆成并行车道时，subagents 才值得用；否则主要是在增加上下文、token 和协调成本。
  • automation 应建立在“手工已跑稳”的前提上：skills 定义方法，automations 定义频率。

执行面与验证面 ​

  • 交互式 session 适合探索和迭代，因为 approval loop 可见且容易即时纠偏。
  • slash commands 是活跃 session 的交互控制面：它们允许你在不中断会话的前提下调整模型、权限、规划模式、compact、review 与诊断输出。
  • codex exec 适合 CI、定时任务与脚本化管道，尤其是在需要 JSONL 事件流、schema 输出或非交互续跑时。
  • 实现仓库本身也说明这些执行面不是纸面概念：app-server 请求路由、thread 生命周期、command-exec 控制与 review 流都被做成了显式 runtime 子系统，而不是薄薄一层 CLI 便利封装。
  • 非交互运行必须坚持最小权限，并保留足够的验证产物，尤其在它会改文件、重跑测试或提 PR 时。
  • 要把独立上下文当成验证工具，而不只是并发技巧：计划复审、独立 code review 与新上下文调试，往往优于把所有工作塞进一个过载线程。
  • review 和 testing 是 Codex 操作模型的一部分：不应只产出代码，还要跑检查、看 diff，并解释任务是否真的完成。

护栏 ​

  • 不要把耐久 repo 规则塞进每一次 prompt；prompt 只放任务局部差异，稳定规则放版本化文档里。
  • 在工作流没跑明白、仓库还不可信时，不要过早放宽 sandbox 或 approvals。
  • 还需要大量人工盯控的流程，不应急着自动化。
  • 不要把彼此无关的任务堆进一条超长 thread；一个 thread 对应一个连贯任务，真的分叉时再 fork。

来源 ​

相关页面 ​