Codex 软件工程师使用教程（中文版）
Codex 软件工程师使用教程（中文版）
Codex 软件工程师使用教程（中文版） Codex 软件工程师使用教程（中文版） Modified May 28 No access Codex for Software Engineers 00:00 • 监控系统 • 团队沟通工具 • 工单系统 • 代码仓库 Codex 就不只是“写代码助手”，而是： 一个可辅助 incident triage 的 Agent 例如： • 去看日志 • 看最近变更 • 分析代码路径 • 帮你判断 root cause • 甚至准备修复 PR 这对平台工程、SRE、基础设施团队会很有想象空间。 二十一、Agentic Loop：Codex 在背后到底做了什么 教程里把 Codex 的工作方式叫做： Agentic Loop 你可以把它理解成一个循环： 1. 接收你的 prompt 2. 运行模型推理 3. 判断还缺不缺上下文 4. 决定要不要调用工具 5. 继续执行 6. 看反馈 7. 再决定下一步 8. 直到完成任务或需要你介入 它不是一次性回答，而是： 在一个不断“观察—行动—反馈—修正”的循环中工作 理解这个点以后，你会更自然地接受： • 它为什么需要测试反馈 • 它为什么会主动问决策问题 • 它为什么能长时间跑任务 二十二、工程师真正要做的是“上下文工程” 教程后半段其实在反复强调一件事： 用好 Codex，不只是写 prompt，而是做好上下文工程 你需要提供的东西包括： • 项目上下文 • Definition of Done • 约束条件 • 禁止做的事 • 可以去哪里找额外信息 • 哪些测试是关键反馈 如果这些东西给得好，Codex 的表现通常会稳定很多。 二十三、Agent.md / 项目说明文件为什么重要 在真实工程项目里，一个极有价值的做法是： 让 Codex 先帮你生成项目级上下文文件 比如： • 项目是干什么的 • 有哪些关键模块 • 构建和运行方式 • 常见约定是什么 • 哪些路径最关键 这样做的价值在于： • 帮 Codex 建立长期项目记忆 • 也帮新人开发者更快接手 • 还能为后续 Skills、Rules、Automations 提供稳定基础 二十四、Sandbox 和权限：为什么新手工程师最好先保守一点 Codex 运行在 OS 级沙箱里，这意味着： • 文件访问 • 网络访问 • 命令执行 都可以被限制。 教程里的建议非常实用： 刚开始用时，先保守一点 不要一上来就把权限全放开。先让它在更可控的权限模式里工作，逐步建立信任，再放宽范围。 这样做有两个好处： • 降低误操作风险 • 帮你更快理解 Codex 在什么情况下会请求批准 二十五、Context Window 不是你一直要手动担心的事 很多高级用户会问： 长线程会不会把上下文撑爆？ 这场课提到一个重要细节： Codex 会自动 compact 上下文 也就是说，当线程特别长时，它会： • 自动压缩上下文 • 保留继续工作所需的核心信息 所以多数情况下你不需要频繁手动开新线程。 但有一种情况仍然建议拆分： 当一个 thread 里开始混入多个不相关任务时 因为这会让上下文变脏。 更好的方式是： • 一个任务一条 thread • 多个 thread 并行 这样既适合你，也适合 Codex。 二十六、高绩效团队怎么用 Codex 教程最后提到一个趋势： 有些团队已经进入了非常“放手”的使用方式。 例如： • 大量任务直接委派给 Codex • 人主要做方向和边界控制 • 编码、测试、文档、检查大量交给 Agent 但这不是“开箱即成”，而是要靠： • 好的上下文 • 好的规则 • 好的反馈回路 • 团队级规范 逐步磨出来的。 也就是说： 高绩效团队并不是“用了 Codex 就自动变强” 而是“围绕 Codex 重新设计了工作方式” 二十七、如果你是软件工程师，最值得今天就开始做的 7 件事 1. 先在真实仓库里用一次 Codex 不要只围观 demo。 2. 用 Plan Mode 规划一个真实功能 尤其是有多种实现路径的任务。 3. 让 Codex 帮你 review 一个当前 PR 看看它会发现什么问题。 4. 让它生成当前项目的 ER 图或架构说明 这是最容易快速出价值的场景之一。 5. 把一个重复动作封装成 Skill 哪怕只是 dead code 扫描。 6. 接一个你团队常用的工具 No access Codex for Software Engineers 00:00 No access Codex for Software Engineers 00:00 • 监控系统 • 团队沟通工具 • 工单系统 • 代码仓库 Codex 就不只是“写代码助手”，而是： 一个可辅助 incident triage 的 Agent 例如： • 去看日志 • 看最近变更 • 分析代码路径 • 帮你判断 root cause • 甚至准备修复 PR 这对平台工程、SRE、基础设施团队会很有想象空间。 二十一、Agentic Loop：Codex 在背后到底做了什么 教程里把 Codex 的工作方式叫做： Agentic Loop 你可以把它理解成一个循环： 1. 接收你的 prompt 2. 运行模型推理 3. 判断还缺不缺上下文 4. 决定要不要调用工具 5. 继续执行 6. 看反馈 7. 再决定下一步 8. 直到完成任务或需要你介入 它不是一次性回答，而是： 在一个不断“观察—行动—反馈—修正”的循环中工作 理解这个点以后，你会更自然地接受： • 它为什么需要测试反馈 • 它为什么会主动问决策问题 • 它为什么能长时间跑任务 二十二、工程师真正要做的是“上下文工程” 教程后半段其实在反复强调一件事： 用好 Codex，不只是写 prompt，而是做好上下文工程 你需要提供的东西包括： • 项目上下文 • Definition of Done • 约束条件 • 禁止做的事 • 可以去哪里找额外信息 • 哪些测试是关键反馈 如果这些东西给得好，Codex 的表现通常会稳定很多。 二十三、Agent.md / 项目说明文件为什么重要 在真实工程项目里，一个极有价值的做法是： 让 Codex 先帮你生成项目级上下文文件 比如： • 项目是干什么的 • 有哪些关键模块 • 构建和运行方式 • 常见约定是什么 • 哪些路径最关键 这样做的价值在于： • 帮 Codex 建立长期项目记忆 • 也帮新人开发者更快接手 • 还能为后续 Skills、Rules、Automations 提供稳定基础 二十四、Sandbox 和权限：为什么新手工程师最好先保守一点 Codex 运行在 OS 级沙箱里，这意味着： • 文件访问 • 网络访问 • 命令执行 都可以被限制。 教程里的建议非常实用： 刚开始用时，先保守一点 不要一上来就把权限全放开。先让它在更可控的权限模式里工作，逐步建立信任，再放宽范围。 这样做有两个好处： • 降低误操作风险 • 帮你更快理解 Codex 在什么情况下会请求批准 二十五、Context Window 不是你一直要手动担心的事 很多高级用户会问： 长线程会不会把上下文撑爆？ 这场课提到一个重要细节： Codex 会自动 compact 上下文 也就是说，当线程特别长时，它会： • 自动压缩上下文 • 保留继续工作所需的核心信息 所以多数情况下你不需要频繁手动开新线程。 但有一种情况仍然建议拆分： 当一个 thread 里开始混入多个不相关任务时 因为这会让上下文变脏。 更好的方式是： • 一个任务一条 thread • 多个 thread 并行 这样既适合你，也适合 Codex。 二十六、高绩效团队怎么用 Codex 教程最后提到一个趋势： 有些团队已经进入了非常“放手”的使用方式。 例如： • 大量任务直接委派给 Codex • 人主要做方向和边界控制 • 编码、测试、文档、检查大量交给 Agent 但这不是“开箱即成”，而是要靠： • 好的上下文 • 好的规则 • 好的反馈回路 • 团队级规范 逐步磨出来的。 也就是说： 高绩效团队并不是“用了 Codex 就自动变强” 而是“围绕 Codex 重新设计了工作方式” 二十七、如果你是软件工程师，最值得今天就开始做的 7 件事 1. 先在真实仓库里用一次 Codex 不要只围观 demo。 2. 用 Plan Mode 规划一个真实功能 尤其是有多种实现路径的任务。 3. 让 Codex 帮你 review 一个当前 PR 看看它会发现什么问题。 4. 让它生成当前项目的 ER 图或架构说明 这是最容易快速出价值的场景之一。 5. 把一个重复动作封装成 Skill 哪怕只是 dead code 扫描。 6. 接一个你团队常用的工具 比如： • Linear • GitHub • Figma • Slack 7. 开始训练自己“一个任务一个 thread”的习惯 这是并行 Agent 工作流里非常重要的基本功。 二十八、这份教程的核心总结 如果把整场课压缩成几句话，大概就是： 1. Codex 已经不只是“帮你写代码” 它可以进入整个 SDLC。 2. 真正的提升来自 Agent 化委派 而不是只把它当补全工具。 3. Plan、Test、Review、Docs 和 Ops 一样重要 不要只盯着 build 阶段。 4. Skill、Automation、Plugins 是工程团队规模化使用的关键 它们决定你能不能把个人效率变成团队效率。 5. 最终比拼的不是谁 prompt 更花哨 而是谁能提供更好的上下文、更好的反馈回路和更清晰的任务边界。 二十九、你下一步可以怎么做 如果你准备真的把 Codex 用进日常工程工作，我建议这样走： 1. 安装并登录 Codex App / CLI / IDE 中你最顺手的入口 2. 在真实仓库中让 Codex 先生成项目说明或 Agent 上下文 3. 试一次 Plan Mode 做功能规划 4. 试一次 Code Review 5. 试一次 ER 图 / 文档生成 6. 把一个重复任务封装为 Skill 7. 再逐步尝试 Automation 和更复杂的多 Agent 并行 🎁 这是一份基于 OpenAI《Codex for Software Engineers》英文逐字稿整理的中文教程。 这是一份基于 OpenAI《Codex for Software Engineers》英文逐字稿整理的中文教程。 这份教程适合谁 • 软件工程师 / 全栈工程师 / 后端工程师 / 前端工程师 • DevOps、平台工程、基础设施工程师 • Tech Lead / 工程经理 / 研发效能团队 • 已经在使用 AI 编程工具，但想进一步进入 Agent 化开发的人 一、这不是“另一个补全插件”，而是新的工作方式 这场课开头先回顾了 AI 编程工具这几年经历的三个阶段： 1. 自动补全阶段 最早的 AI 编程体验，主要是： • 补全下一行代码 • 局部生成 • 处理单个很小的任务 2. 结对编程阶段 随后工具变得更像一个 pair programmer： • 能在 IDE 里和你一起改代码 • 有更长上下文 • 能处理稍复杂的连续任务 3. Agent 化委派阶段 这是本次软件工程师版教程的核心： • 不再只是一问一答 • 不再只是一段一段补代码 • 而是把任务委派给 Agent，在多个任务上并行推进 这意味着开发者的角色会逐渐从“逐行实现者”转向： • 任务定义者 • 上下文组织者 • 执行监督者 • 质量把关者 二、Codex 的三种主要使用入口 这场课提到，Codex 现在有三类主要 surface： 1. CLI 适合： • 习惯终端工作流的人 • 希望快速进入项目上下文的人 • 喜欢在 shell 中直接驱动 Agent 的工程师 CLI 是 Codex 最早也最经典的入口。 2. IDE 扩展 适合： • 长时间在 VS Code / JetBrains 中工作的人 • 希望一边看代码一边和 Codex 交互的人 • 想减少上下文切换的人 它的价值在于：你不必离开 IDE，就能调用 Agent、看结果、审查改动。 3. Codex App 这是本场教程演示最多的入口，也是 OpenAI 目前最强调的方向。 它的特点是： • 更容易并行跑多个任务 • 更适合发现和管理 Skills / Plugins / Automations • UI 更友好 • 对非重度终端用户更友好 如果你想更明显地体验“Agent 化开发”，Codex App 往往是最直观的入口。 三、为什么 Codex App 对工程师也越来越重要 有些工程师会默认觉得： • CLI 才专业 • IDE 才高效 • App 只是给新手看的 但这场课强调了一个现实： 当任务开始并行时，单纯终端和单一 IDE 视角会越来越吃力 Codex App 在这方面的优势很明显： • 可以同时跑多个线程 / 任务 • 有更清晰的视觉反馈 • 更容易查看每个任务当前做到了哪一步 • 更适合 orchestrate 多个 agent 所以它不是“简化版入口”，而是越来越像一个真正的 Agent 开发控制台。 四、软件工程师应该把 Codex 看成什么 这场课给出的答案不是“更强的 Copilot”，而是： 一个可并行工作的 Agent 开发环境 它可以贯穿整个 SDLC，而不只是 build 阶段。 很多团队以前只把 AI 用在： • 生成代码 • 写测试 • 补全函数 但真正高价值的做法是，把它放进整条软件交付链路里。 五、Codex 能覆盖软件开发生命周期的哪些环节 教程把软件开发拆成了这些阶段： 1. Planning 用来： • 拆解需求 • 设计任务边界 • 处理权衡取舍 • 与 issue tracker 结合形成实施方案 2. Design 即使你不擅长设计，也可以： • 拉取 Figma • 理解设计稿 • 生成实现计划 • 让 Codex 帮你做结构化落地 3. Build 这是大家最熟悉的部分： • 写代码 • 改代码 • 新建项目 • 修功能 4. Testing Codex 不只生成测试，它还依赖测试作为反馈回路： • 跑测试 • 看失败信息 • 修复再重试 • 直到达到 Definition of Done 5. Code Review 这是当前很多团队能快速见效的方向： • 自动 review PR • 找出明显问题 • 分级问题优先级 6. Documentation Codex 特别适合： • 理解老项目 • 生成架构文档 • 生成 ER 图 / 时序图 / 结构说明 7. Operations 它还可以辅助： • 问题定位 • 根因分析 • 日志和指标联动分析 • 安全 / 配置问题排查 六、软件工程师第一次上手，推荐怎么开始 这场课给出的建议很实在： 不要只拿 toy repo 试 虽然 demo repo 很方便，但如果你想真正理解 Codex 的价值，最好尽快： • 用你自己的工作仓库 • 或至少用一个你真正关心的个人项目 因为只有在真实上下文中，你才能看到： • 它是否理解你的代码库 • 它是否能处理你的架构复杂度 • 它是否真的能加速你的工作 如果你完全没项目 再退一步，也可以先用公开 repo 或 demo repo 试。 七、先认识 Codex App 的几个关键开关 在 App 里，几个很重要的控制项包括： 1. Model 选择你要用的模型。 2. Reasoning Effort 决定模型要“思考多深”。 典型经验： • 日常任务：Medium • 复杂任务：High • 高难度规划 / 大型代码库分析：Extra High 3. Speed 可以切换到 fast mode。 特点是： • 更快 • 会额外消耗一些 token 适合演示、快速验证、密集迭代。 4. Project 项目本质上是： • 本地文件夹 • Git 仓库 • 或者一个空目录（greenfield project） 5. Thread / Chat 每个 thread 都是一条独立任务线。 在 Agent 化工作流里，这一点尤其重要，因为： • 同一项目中可以并行跑多个 thread • 每个 thread 可以对应一个清晰任务 八、为什么要重视 Plan Mode 这场软件工程师版教程里，Plan Mode 是一个非常核心的能力。 它适合什么？ • 新功能设计 • 跨文件改造 • 新项目搭建 • 多种实现路径有权衡的任务 Plan Mode 的价值不只是“先规划再动手”，更重要的是： 它会主动把关键决策点抛给你 例如演示里，Codex 在规划 iOS 伴生应用时，会问： • 这个版本是做 MVP 还是做完整产品？ • 认证怎么做？ • 是否使用 mock data？ 这非常像一个靠谱工程师在实施前做方案确认，而不是默默瞎做。 九、Plan Mode 的推荐使用姿势 你可以把它理解成： 当任务有明显设计空间时，先别急着让 Codex 直接开工 更推荐先： 1. 描述目标 2. 开 Plan Mode 3. 看它抛出的关键决策点 4. 选择推荐项或给出自己的第四种方案 5. 让它生成计划 6. 再决定是否实施 这一步对工程团队尤其重要，因为它可以显著减少： • 路线选错 • 任务范围膨胀 • 一次性改太多导致不可控 十、一个典型例子：给现有系统规划一个 iOS 伴生应用 教程里的例子是： • 已有一个 support desk / ticket inbox 应用 • 现在想让支持人员在手机上也能看 ticket、回复 ticket 这类任务如果你直接说“做个 iOS App”，当然也能让它开工。但更优做法是： • 先让它 plan Codex 会去做几件事： • 看当前仓库结构 • 理解现有应用的数据模型 • 理解 API • 判断 iOS 项目应该放在哪里 • 列出需要新增哪些界面、测试和假设 最后你会得到一个比较工程化的计划，包括： • 目标 • 关键改动 • 要新增哪些接口 / 视图 • 测试计划 • 假设条件 这让 Codex 更像“写技术方案 + 负责落地”的伙伴，而不是只会写几段 SwiftUI。 十一、为什么测试在 Agent 工作流里更重要 这场课反复强调： 测试不仅是质量保障，也是 Agent 的反馈机制 对于人类开发者来说，测试是验证。对于 Codex 来说，测试还是“告诉它下一步该怎么改”的信号。 所以如果你想让 Codex 持续迭代、自动修复、跑长任务： 请尽量给它明确的反馈回路 最常见的反馈回路包括： • 单元测试 • 集成测试 • 构建结果 • 模拟器 / 浏览器运行结果 • linter / 类型检查 没有反馈回路，Codex 只能“猜它大概完成了”。有反馈回路，它才能像闭环系统一样持续修正。 十二、Design 阶段怎么配合 Codex 很多工程师不喜欢设计稿实现，原因通常是： • 读 Figma 费劲 • 组件和样式边界不清楚 • 很多细节容易漏 教程里提到一个很重要的做法： 用 Figma Skill + MCP 它的意义是： • 让 Codex 真正读取设计上下文 • 抽取组件信息 • 理解设计稿结构 • 帮你把“看设计稿”变成可执行流程 这对前端工程、设计到实现、Design System 落地都很有帮助。 十三、Code Review：把 Codex 当成第二审稿人 这场课里展示了一个很有价值的场景： 让 Codex Review 当前改动 好处在于： • 它可以从 diff 出发检查问题 • 可以指出 P0 / P1 / P2 风险 • 可以帮你提前过滤明显问题 但更重要的是，它不会强迫你“一次把所有事都修完”。 教程里还演示了一个很真实的工程决策： • 当前正在修 N+1 query 问题 • Code Review 又发现了另一个 P2 问题 • 这个 P2 问题和当前 PR 不同主题 更合理的做法不是“顺手全修”，而是： 把问题转成 ticket，延后处理 这体现的是很成熟的工程实践： • 保持 PR 单一目的 • 保持改动边界清晰 • 不让 Agent 越修越散 十四、和工单系统联动非常重要 教程里用的是 Linear，但核心思路适用于任何 issue tracker： • Linear • Jira • GitHub Issues • 其他内部任务系统 好的做法不是让 Codex 把所有发现都直接塞进当前分支，而是： 对“当前不该修”的问题，直接沉淀到任务系统 这样做的价值很大： • 保持当前分支聚焦 • 不丢失后续问题 • 让 AI 行为和团队协作流程对齐 这也是工程团队把 Agent 工具真正接入日常开发节奏的关键。 十五、为什么 Skills 对软件工程师同样重要 很多人会觉得 Skill 更像非技术用户功能，但其实工程团队也非常适合使用。 Skill 本质上是： 把重复做的工程流程固化下来 例如： • 查找 dead code • 跑某类性能检查 • 生成某种架构文档 • 审查某种 PR 类型 • 执行固定迁移检查 如果你发现自己反复给 Codex 写同一类 prompt，那就很可能该把它做成 Skill 了。 十六、什么时候应该创建自己的 Skill 一个很简单的判断标准： 同类工作你已经做了 3 次以上 那就值得考虑封装。 比如你经常做这些事： • 找死代码和不可达路径 • 看数据库查询问题 • 生成架构说明 • 解释仓库结构 • 执行迁移检查 都可以通过 Skill 固化。 十七、不会写 Skill 怎么办 这场课特别提到一个很好用的能力： Skill Creator 你不一定要自己手写 Skill 文件。更常见的方式是： • 直接告诉 Codex：帮我创建一个 Skill 例如： • “创建一个用来查找 dead code 和 unreachable code 的 Skill，并安装它” 然后 Codex 会： • 创建 Skill 提示词 • 创建需要的脚本 • 处理依赖配置 • 安装到本地 Skill 目录里 这意味着： 工程团队完全可以把“工作流抽象”这件事，也交给 Codex 来做 十八、Skill 应该怎么持续优化 一个很好的问题是： Skill 做完之后，怎么保持它不过时？ 这场课给出的答案很有启发： 用 Automations 做自我改进 例如： • 每天早上 9 点跑一次 • 回顾最近的使用会话 • 看看某个 Skill 哪些地方表现不好 • 自动提出改进建议甚至修改 Skill 这意味着你可以做出一种“会迭代自己”的工作流体系。 这是 Agent 化工程工具真正和传统脚本工具拉开差距的地方。 十九、Documenting Legacy Code：文档生成是大价值场景 很多工程师都经历过： • 接手老项目 • 代码能跑，但没人讲得清 • 文档缺失 • 架构关系模糊 Codex 在这里特别适合做两件事： 1. 解释给你听 例如： • 这个项目有哪些模块？ • 数据库实体关系是什么？ • 请求流程怎么走？ 2. 直接生成结构化文档 例如： • ER 图 • 架构图 • README 补全 • 模块关系说明 教程里展示了一个典型例子： 让 Codex 生成这个项目的 ER Diagram 它会扫描代码和模型关系，生成图和解释，让你不用先靠肉眼读完所有代码才能理解项目。 二十、Operations 场景：Codex 也能帮你做根因分析 教程里虽然没有完整展开，但点到了一个很重要的方向： 如果你把这些能力接起来： • 日志平台