先把四个档位理解成四种工作方式
Low 不是“低能”，Extra High 也不是“万能”。它们更像四种不同的施工方式。
Low 是快改模式。你已经知道要改哪里，也知道改成什么，只是想让 Codex 代你执行。比如改按钮文案、补一个简单校验、修一个很直观的报错、解释一段短代码、统一某个变量名。这类任务目标明确、范围小、回滚容易，开 Low 就够。
Medium 是日常交付模式。大多数普通开发任务都适合从这里开始。比如新增一个列表筛选、补一个接口字段、调整一个页面交互、给现有逻辑加测试、按已有风格扩展一个功能。它需要读一点上下文，但还不至于要做架构级判断。
High 是认真排查模式。任务开始跨文件、跨状态、跨前后端，或者 bug 根因不明显时，High 更合适。比如登录状态偶发丢失、支付回调状态不一致、前端字段和后端 DTO 对不上、缓存更新不稳定、测试失败但报错不直接指向根因。这里最怕的不是写得慢，而是 AI 只改了最显眼的一处，结果把真正问题留在后面。
Extra High 是深度代理模式。它适合高风险、长链路、复杂上下文的工作，比如权限体系、数据库迁移、支付链路、生产发布、跨模块重构、遗留项目梳理、复杂测试修复、需要连续跑工具并根据结果调整路线的任务。它的价值不是“多写代码”，而是减少误判。
换句话说，档位选择不是看任务标题长不长，而是看任务背后的不确定性有多大。
Low：你能预判改动位置，就不要浪费预算
Low 最适合两类任务：第一类是执行明确指令，第二类是做低风险小修。
比如你可以这样交给 Codex：
“把这个按钮文案从立即提交改成提交申请。”
“给这个表单加一个手机号必填校验。”
“这个 TypeScript 报错是某个字段可能为空，按现有写法补一下兼容。”
“帮我把这段 CSS 的间距从 12px 改成 16px。”
这些任务有一个共同点：你脑子里大概已经知道答案在哪里，Codex 只是执行得更快。它不需要扫描半个仓库，也不需要评估三种方案。
我自己的判断标准是：如果你能预判 80% 的改动位置，并且改错了也很容易回滚，Low 往往够用。
但有些任务看起来短，实际不短。
“帮我修一下登录问题。”
“优化一下权限逻辑。”
“把支付状态处理稳一点。”
“数据库这里帮我整理下。”
这些句子很短，但背后可能牵涉用户身份、缓存、路由、接口、异常分支、历史数据和生产风险。不要因为指令短就用 Low。任务描述短，不代表任务边界清楚。
Medium：普通开发默认从这里起步
如果你不知道该选哪档，Medium 通常是最稳的起点。
Medium 的优势是性价比。它会读相关文件，找已有模式，按项目风格做改动，再根据报错做一轮修正。它不会像 Low 那样太快落子，也不会像 Extra High 那样为了一个小改动做大范围探索。
在真实项目里，很多工作都属于 Medium：
新增一个后台配置项。
给列表页补一个查询条件。
让移动端页面多展示一个字段。
把接口返回结构和前端展示对齐。
为现有函数补两三个测试用例。
参考一个已有弹窗，新做一个类似弹窗。
这些任务需要上下文，但风险可控。你希望 Codex 看懂周边代码，不希望它自作主张改太多。
对软件公司和项目负责人来说，Medium 也是最适合日常协作的档位。需求没有那么危险，但也不是复制粘贴。让 Codex 用 Medium 做第一轮，能兼顾速度、成本和稳定性。
我不建议一上来就把所有开发都开到 Extra High。那会让简单任务变慢，也会让你误以为“AI 多想就一定更好”。很多时候，真正提高交付质量的不是档位拉满，而是指令写清楚、范围划清楚、验收标准讲清楚。
High：当任务开始有根因和副作用，就该升档
High 适合“容易做错”的任务。
这种任务通常不是不知道怎么写代码，而是不知道问题到底出在哪里。你改了 A，可能影响 B；修了前端，后端返回又不匹配；补了一个分支，测试又暴露另一个隐藏假设。
典型场景包括：
一个 bug 跨多个文件才能解释。
一个状态同时受前端缓存、接口返回、路由守卫影响。
一个接口字段改动会影响管理端、移动端和导出。
一个测试失败不是语法问题，而是业务假设变了。
一个旧模块没人敢动，但必须继续维护。
这时候，Low 容易只修表面，Medium 有时也会漏掉隐藏分支。High 的意义是让 Codex 愿意往前后多看几步：谁调用了这里，哪些文件依赖这个字段，测试覆盖了什么，改完以后还要验证哪里。
在 agent 工作流里，High 尤其重要。因为 Codex 不是只给建议，它会真的改文件、跑命令、看结果。档位太低时，它可能很快给出一个“看起来能跑”的补丁，但没有真正排清影响范围。
如果任务已经出现两次反复，或者你发现 Codex 一直在同一个错误点上绕圈，继续用同一个档位重试意义不大。更好的做法是补充上下文，然后升到 High。
Extra High：留给高风险、长链路和复杂决策
Extra High 不是日常开关，它更像保险。
它适合那些“改错代价高”的任务。比如权限、支付、订单、数据迁移、生产部署、安全边界、跨模块重构、核心业务流程、历史烂尾项目抢救。
这类任务的共同点是：正确答案不在眼前。Codex 需要读更多文件，理解更多上下文，比较不同路线，还要在执行后检查测试、日志、接口返回和副作用。
比如下面这些任务，我会倾向 Extra High：
梳理一个项目的登录、权限和角色体系。
重构订单状态机，但不能破坏已有订单。
修复支付回调重复通知导致的数据不一致。
把旧数据库字段迁到新结构，并保留兼容逻辑。
排查线上构建失败，同时判断是不是环境、依赖、代码三者之一。
让 Codex 连续完成“读需求、改代码、跑测试、修失败、更新文档、汇报影响范围”的长任务。
Extra High 的优势不是神奇，而是耐心。它会更愿意把上下文背起来再往前走。慢一点，但在高风险任务里，这种慢是必要成本。
不过，也不要把 Extra High 当成遮羞布。任务说明含糊、验收标准模糊、文件边界没说清，开再高也可能跑偏。高档位能提升推理深度，不能替代需求澄清。
三个问题，比“感觉难不难”更可靠
不知道选哪档时，可以先问三个问题。
第一，边界清不清楚？
如果你知道要改哪个文件、改成什么样，偏 Low 或 Medium。如果你还不知道根因在哪里，至少 High。
第二，改错代价高不高？
如果改错只是一个文案或样式问题，Low 就行。如果会影响登录、权限、支付、数据、发布，直接提高档位。
第三，Codex 需不需要自己连续决策？
如果只是照指令改一处，低档位够用。如果需要它读文件、跑命令、看报错、再判断下一步，就不要低配。
可以把它变成一个简单矩阵：
0 个“是”：Low。
1 个“是”：Medium。
2 个“是”：High。
3 个“是”：Extra High。
这个矩阵比“我感觉这个任务有点难”更可靠。因为它把难度拆成了边界、风险和自主决策。
档位之外，更重要的是你给了什么上下文
很多人把 Codex 用不好，不是档位选错，而是上下文给得太少。
你只说“帮我优化一下”，Codex 就只能猜。你说“只改这个页面，参考这个组件，不要动接口，改完跑这个测试，验收标准是移动端不溢出”，它的成功率会明显提高。
档位越高，上下文越重要。因为高档位会多想几步，如果方向给错，它也会在错误方向上多走几步。
给 Codex 上下文时，我建议至少说清六件事：
目标是什么。
哪些文件或模块可以改。
哪些行为不能变。
参考哪个已有实现。
验收标准是什么。
出错后优先看哪些日志、测试或页面。
这也是企业用 AI 编程工具时最容易忽略的地方。AI 不是单纯替代程序员敲代码，它更像一个执行力很强的工程协作者。协作者越强，越需要清晰边界，否则它会把模糊需求放大成模糊改动。
一个实用工作流：先默认，再升档，不要反复硬试
如果你不想每次都分析太久，可以用一个简单工作流。
很小的明确任务，直接 Low。
普通开发任务，默认 Medium。
Medium 做偏了，补充上下文后升 High。
High 仍然绕圈，或者任务进入权限、数据、支付、生产、重构，就升 Extra High。
这个流程的重点是“补充上下文后再升档”，而不是原封不动再试一次。很多失败不是模型完全不会，而是它缺少关键约束。把约束补上，再给更高思考预算，效果通常比盲目重跑更好。
对老板和项目负责人来说，也可以这样理解：
Low 适合小修改。
Medium 适合日常交付。
High 适合排查和稳态修复。
Extra High 适合关键链路和复杂项目。
如果团队正在用 Codex 做真实项目，不要只问“AI 能不能写代码”。更应该问的是：哪些任务可以让 AI 快速执行，哪些任务必须让 AI 多读上下文，哪些任务需要人工先把业务边界讲清楚。
最后记住这条原则
Codex 的 Low、Medium、High、Extra High，本质上不是四个能力等级，而是四种风险和成本配置。
Low 负责快。
Medium 负责稳妥完成日常任务。
High 负责认真排查复杂问题。
Extra High 负责高风险、长链路和复杂上下文。
真正会用 Codex 的人，不会所有任务都开最高，也不会让复杂任务一直低配运行。他会根据任务边界、失败代价和需要 Codex 自主判断的程度，给它匹配合适的思考预算。
如果你正在把 AI 编程工具接入真实业务项目，建议先把任务分层：小改、日常开发、复杂排查、关键链路。分清之后，Codex 的档位选择就不再是玄学，而是项目管理的一部分。
华茂思捷做软件开发、AI 应用落地和项目抢救时，也会用类似方式拆任务：先判断业务边界，再选择执行强度，最后用测试和验收闭环。需要把 AI 工具真正落到业务系统里，可以先看我们的核心服务，或者直接通过联系页面沟通具体项目。
