安装与登录
codex login第一次在本机启用 Codex CLI，确认账号、环境和工作目录。
如果登录态、工作目录和项目上下文不清楚，后续所有命令都可能在错误前提下运行。
- 先确认当前目录是不是目标仓库。
- 不要在未准备好的环境里直接执行高风险命令。
- 记录项目常用脚本，方便后续把验证交给 CLI。
Feature Explorer
按场景筛选功能，而不是死记命令
你真正需要掌握的是功能组合方式：研究、编码、审查、并发、审批和自动化如何衔接。
Codex CLI
按场景选能力，而不是背命令
先想清楚你在做什么，再决定该用 review、subagents 还是 approval modes。
代码审查 /review
/review在提交前检查风险点、回归面、缺失测试和风格不一致问题。
AI 不仅能写代码，更能帮你做高频 review，把隐含风险提前暴露出来。
- review 结论必须结合真实 diff 与测试结果理解。
- 不要把审查意见当作自动真理，仍要人工做最终判断。
- 对高风险改动要补充手动验证说明。
子代理并发
使用 subagents 拆分独立子任务当任务可以拆成独立的调研、实现、测试或文案工作时并发推进。
大型任务最怕一个代理上下文过载。子代理能把复杂问题拆散，再由主代理统一收口。
- 只在边界清晰时并发，避免多个代理改同一批文件。
- 主代理必须保留集成和最终验证职责。
- 不要把阻塞主路径的关键决策完全外包。
Web Search
在需要外部资料时启用 Web 搜索查当前文档、版本差异、官方说明和近期变更，尤其适合高时效信息。
很多技术和平台信息都会变，外部搜索能减少凭记忆回答带来的过时风险。
- 优先使用官方来源，并保留链接。
- 新闻、价格、平台能力等时效信息必须核对日期。
- 不要把搜索结果摘要当成无需验证的事实。
Approval Modes 与安全边界
按任务风险设置 approval modes控制是否允许自动运行命令、写文件、访问外部系统和执行高风险操作。
AI 越能执行真实动作，越需要清晰审批边界。审批模式决定了速度和安全之间的平衡。
- 依赖安装、外部发布、删除或重置类动作要特别谨慎。
- 高风险任务必须明确哪些情况要停下来请求人工确认。
- 审批策略应该和团队发布规范一致。
图像输入辅助排查
把截图作为上下文输入 Codex排查 UI 视觉问题、布局异常、设计差异或错误截图中的关键信息。
很多前端问题光靠文字难以描述，截图能让模型快速理解页面状态和异常位置。
- 截图只是补充，仍要提供相关组件或样式文件范围。
- 涉及敏感信息的图像要先脱敏。
- 视觉建议最终仍需回到代码和实际渲染验证。
MCP 工具扩展
通过 MCP 接入外部文档、系统和能力给 Codex 提供受控的额外工具能力，例如文档源、内部系统或特定服务接口。
MCP 能把通用 AI 助手变成了解你工具链和资料源的工程代理，提高上下文质量与行动能力。
- 先定义工具的安全边界，再开放给代理使用。
- 只接入真正能稳定提升效率的工具，不要让工具噪声压过主线。
- 高价值资料源应优先接官方或可信内部源。
Skills 与可复用工作流
把高频流程沉淀为 skills把项目规范、常用部署流程、固定代码模式和工具集成整理成可复用技能。
高手和新手的差距往往不在一次回答，而在是否能沉淀成稳定模板，下次继续复用。
- skills 应该聚焦高频、清晰、可复用的流程。
- 不要把过度依赖个人记忆的隐性知识硬编码进去。
- 随着项目演进要定期更新 skill 内容。
自动化与 CI
把 Codex 工作流接进脚本与 CI在 PR 检查、日常脚本、发布流程和批量维护任务中复用 Codex 能力。
当工作流走向团队协作时，真正的效率来自自动化，而不是每次从零描述任务。
- CI 中的 AI 步骤必须有清晰边界和可审计输出。
- 自动化不是放弃 review，而是把 review 前置和标准化。
- 部署链路中的凭据与权限必须单独管理。
Playbooks
知道功能还不够，你还要会组合打法
下面这些是最值得反复练的 Codex CLI 作战模板。每一条都对应真实工程场景，而不是抽象定义。
接管陌生仓库
先收敛上下文，再决定要不要写代码，避免一上来就在错误目录或错误假设下动手。
适用场景
你第一次进入一个项目，需要理解结构、脚本、测试、部署方式和风险边界。
命令策略
先让 Codex 探索仓库与关键脚本，再总结结构，最后才进入具体功能任务。
人工检查点
- 确认当前目录、分支和未提交改动状态。
- 让输出先回答“这个项目怎么跑、怎么测、怎么发”。
- 在真正编码前明确可修改范围与不可破坏行为。
常见失败方式
- 直接让 AI 写功能，但它并没有理解仓库结构。
- 忽略已有脚本和约定，重复造轮子。
- 没有先看 dirty worktree，导致误覆盖他人改动。
新增一条完整功能切片
把需求拆成 UI、状态、接口、测试、文档五个面，而不是一句“帮我做完”。
适用场景
你需要加一个真实功能，而且它横跨前端、后端或多个模块。
命令策略
先定义切片目标和验收标准，再把实现与验证拆给不同代理并行推进。
人工检查点
- 需求里必须写出用户价值、接口边界、输出位置和测试要求。
- 并发前确认不同代理不会改同一块核心状态逻辑。
- 主代理最终要统一看 diff、跑构建和做冒烟验证。
常见失败方式
- 一口气让 AI 改整个模块，最后很难 review。
- 没有把测试和文档纳入功能定义。
- 多个代理同时改同一批文件造成冲突。
提交前审查与加固
把 `/review`、构建、测试和人工检查连成一个固定动作，而不是凭感觉决定是否可发。
适用场景
功能基本完成，需要判断风险、补边界和准备上线。
命令策略
让 Codex 先做 review，再围绕 review 结论补测试、补文档、补手动验证清单。
人工检查点
- 先看高风险文件和行为变更，再看风格类问题。
- review 结论要配合真实测试输出理解。
- 对用户可见改动要补手动验收步骤。
常见失败方式
- review 没看 diff 就直接接受结论。
- 只做风格清理，不处理真正的回归面。
- 没有把上线后的监控和回滚点写出来。
结合截图排查前端问题
让图像输入和代码上下文互相补位，减少光靠文字描述 UI 问题的损耗。
适用场景
页面布局错位、交互不对、视觉与设计稿不一致，文字很难说清楚。
命令策略
给截图、组件路径、目标行为和当前异常，再要求输出定位思路与修改范围。
人工检查点
- 截图前先脱敏敏感信息。
- 必须补充相关组件、样式或页面文件范围。
- 修完后仍要回到浏览器实际验证，而不是只看代码。
常见失败方式
- 只有图片，没有代码范围。
- 把视觉建议直接合并，没有实际渲染验证。
- 忽略响应式和移动端表现。
把高频流程沉淀成自动化
当你多次重复同类任务时，应该把 prompt、校验和发布动作固化成脚本或 skill。
适用场景
团队已经形成稳定节奏，希望把 review、起草、补文档、发版说明等动作自动化。
命令策略
先抽象出固定输入输出，再把 Codex 放进脚本或 CI，而不是让每个人临场发挥。
人工检查点
- 自动化步骤必须可审计，能追溯输入、输出和责任边界。
- 凭据、审批和外部发布要与脚本本身分离管理。
- 先固化高频流程，再考虑扩展到更多场景。
常见失败方式
- 把不稳定流程过早自动化。
- 自动化脚本没有审批边界和失败回滚策略。
- 依赖单个高手脑内 prompt，没有沉淀成团队资产。
Multi-Agent
大型任务要会拆，会并发，会收口
子代理不是为了炫技，而是为了把读代码、写代码、验证和资料检索分层并行，让主代理守住关键路径。