我原本只是想回答一个很简单的问题：我到底是怎么使用 Codex 的？
但当我把最近十周的任务记录、项目控制文件、模型配置和几次典型长任务放在一起看时，答案比我预想得更复杂。
我已经不太像是在使用一个“写代码的 AI”，而是在搭建一套个人的受控执行系统：它会操作文件、浏览器、应用和远程服务，会读取项目状态、分阶段执行、保存证据，也会把成功流程沉淀成可以复用的技能。
这套方法比我想象中成熟，但也比我想象中笨重。
我当前真正的问题，不是 Codex 能力不够，而是治理流程开始占用过多上下文和注意力。下一阶段的重点不应该是增加更多规则和代理，而应该是让授权边界更清楚、验收更机械、执行更自主。
我是怎样做这次审计的
这不是一次严格的学术研究，而是一次面向自己的使用复盘。
我检查了本机可访问的十周左右的 Codex 使用记录，包括一百多个执行线程、六十多个主任务、近四十个工作目录、二十多次显式子代理协作，以及几套已经形成的个人技能。这里的线程包括子任务和内部执行过程，因此不能简单等同于“我主动发起了一百多个项目”。内部 token 统计也不等于账单金额，只适合用来观察上下文是否膨胀。
我还抽样回看了几类差异很大的任务：个人数据迁移、生产站点维护、在线文档整理、复杂基准审计和一般知识工作。最后，我把这些习惯与 OpenAI 团队、独立开发者和长期使用 AI Agent 的实践者进行对照。
结果逐渐显现出一个稳定模式。
我已经把 ChatGPT 和 Codex 分成了两个角色
我通常用 ChatGPT 理解问题、讨论方向、学习新概念；真正涉及文件、应用、网页、命令行和远程环境时，我会把任务交给 Codex。
进入 Codex 后，我的典型流程大致是：
- 读取项目规则、当前状态、计划、决策和下一步；
- 先说明目标、不做什么、会修改什么、如何验收；
- 等我确认后，按一个 phase 或一个 job 执行；
- 必要时拆分管理者、执行者、证据核验者或盲审者；
- 用日志、哈希、精确数量、截图、配置检查和公开页面完成验证；
- 把状态写回文件，让下一次可以从项目真相源继续；
- 如果某个复杂流程以后还会重复，就把它整理成技能。
这已经不是普通的“提示词技巧”，而是一套初步的个人 AgentOps：我不仅关注 AI 输出了什么，也在设计它如何获得上下文、如何行动、何时停下，以及怎样证明自己真的完成了任务。
哪些习惯值得保留
1. 用证据结束任务，而不是用一句“应该好了”
这是我目前最有价值的习惯。
在数据迁移中，我会检查源数据、备份、哈希和恢复后的准确数量；在网站发布中，我会同时检查后台状态、分类标签、公开 URL、HTTP 状态和页面实际内容；在复杂审计中，我会要求每项结论对应原始轨迹、截图或工具结果。
AI 最容易制造的错觉，是“过程看起来很完整，所以结果大概正确”。明确的验收证据能把这种错觉压回现实。
2. 把项目状态放进文件，而不是押注聊天记忆
长任务一定会遇到上下文压缩、中断、换线程或换模型。如果目标、决策和未决事项只存在聊天里，下一次接手时就很容易重新推理，甚至推翻已经确认的事实。
把状态外置成文件，让任务可以恢复，是我从普通 AI 使用走向工程化执行的重要一步。OpenAI 的 Harness Engineering 实践也强调：仓库文档应该成为系统真相源，代理需要直接看到代码、文档、日志、指标和验证结果。
3. 明确“不做什么”和停止条件
对于个人数据、生产服务和账户类任务，备份、可逆性、权限边界和停止条件不是多余流程。它们决定了一次自动化到底是帮忙，还是把风险放大。
我会明确哪些动作不能顺手做、哪些资源不能碰、什么现象出现后必须停下。这种风险意识应该保留，而且应该进一步转成技术护栏。
4. 把成功经验变成技能
一次任务做对，只解决一次问题；把它整理成技能，才会形成复利。
我已经开始把签证办理、网站分享卡配置、复杂基准审计等流程沉淀下来。OpenAI 当前的 Codex 用例也把“把重复工作保存为技能”作为正式工作流，而不是附属功能。官方用例页面
我在哪里把事情做重了
1. 所有任务都套用了高风险项目的治理强度
我曾经要求每次 substantial work 都读取多份控制文件、先提交 Context Packet、等待确认，并且在缺少 Git 或项目文件时直接停止。
对生产环境、个人数据和不可逆操作，这很合理。但如果只是只读调查、文章改写或一个可逆的小修改，同样的仪式会产生大量无效摩擦。
问题不在于规则多，而在于没有风险分级。
2. 授权边界太细，形成了“确认—继续”循环
在一些长任务里，我反复回复“确认”“继续”“不用停”。这说明代理并不知道我到底授权了多大范围，只能把每个普通步骤都重新提交给我。
看起来我控制得很严，实际上我的注意力变成了整个系统的串行瓶颈。
更好的方式应该是：一次确认一个完整执行包。执行包里写清允许动作、禁止动作、验收标准和停止条件；只要仍在边界内，代理就应该继续运行，不必逐步请示。
这也符合最新 OpenAI 模型指导 的建议：把安全的本地动作、需要确认的外部写入，以及破坏性或扩展范围的动作明确分开，并且把规则集中写一次，避免重复的“请先询问”制造无必要暂停。
3. 强模型、最高推理和巨大工具面被当成了默认值
复杂任务当然值得使用最强模型，但“最强”不应该自动等于“最合适”。
OpenAI 当前建议把 medium 作为平衡起点，只有在代表性任务上测出质量提升时才使用 high 或 xhigh，把 max 留给最困难、质量优先的工作。官方还报告，在一组内部 coding-agent eval 中，精简重复提示和无关工具后，评测分数提高约 10%–15%，总 token 降低约 41%–66%；这个结果只是方向性证据，但非常值得在自己的任务上复测。OpenAI 模型指导
我的一些任务已经明显出现上下文膨胀：少数超长任务占据了大部分内部 token。继续堆模型强度、规则和工具，并不会线性增加质量。
4. 多代理加速了执行，也放大了审查成本
我曾在少数任务中同时调度接近十个子代理。对于相互独立的证据通道、盲审或可机器汇总的工作，这确实有效；但如果每个代理都需要我理解上下文、判断冲突和审查输出，并行越多，我越忙。
OpenAI 的 Symphony 实践提到，人通常可以较舒适地管理三到五个并行会话，继续增加后，注意力切换会快速上升。Simon Willison 也把审查视为并行编码代理真正的瓶颈：只有那些不会增加太多认知负担的任务，才适合同时展开。
5. 我有很强的文字护栏，但机械护栏还不够
规则文件会提醒代理谨慎，却不能完全阻止误命令、权限越界或外部内容中的提示注入。
真正可靠的安全体系应该同时包含：受限沙箱、最小权限、可恢复快照、明确批准点、自动验证，以及对外部写入的独立检查。文字告诉代理“应该怎样做”，机械护栏决定它“最多能做什么”。
前沿实践给我的启发
不同实践者走的是不同路线，不能简单照抄。
OpenAI 的 Harness Engineering 路线更像建设基础设施：短 AGENTS.md 负责导航，详细知识进入结构化文档，测试、lint 和架构约束负责机械执行。当代理反复失败时，团队优先补足可观察性、工具能力和自动检查，而不是单纯要求模型“再认真一点”。
Peter Steinberger 的个人开发路线更轻：短提示、原子提交、中等推理，并根据“爆炸半径”拆任务；他也会同时运行多个代理，但强调任务必须足够独立。Peter 的工作流记录 这种方式很适合隔离良好的代码项目，却不适合直接照搬到个人数据、账户和生产运维上。
与我的需求更接近的是 Jason Liu 描述的长期 Codex 工作方式：不只写代码，也处理演示文稿、转录、表格、浏览器和周期性事务；用持久任务保存工作流，用可审查的知识库记录状态，再把成功过程封装为技能。Codex Maxxing 白皮书
综合这些方法，我不需要在“严格控制”和“完全放手”之间二选一。更合理的答案，是按照任务风险动态切换治理强度。
我的 Codex 方法论 V2：三级风险模型
| 等级 | 典型任务 | 默认执行方式 |
|---|---|---|
| A：只读 | 调查、解释、诊断、总结、方案比较 | 直接读取和分析，不创建整套控制文件，不请求普通步骤确认 |
| B：可逆本地修改 | 代码、文档、配置草稿、数据整理 | 简短 Work Order，使用 Git 或快照，自动运行验收；一个 phase 一次授权 |
| C：外部或高风险 | 生产服务、账户、个人数据、发布、删除 | 完整 Context Packet、备份清单、回滚方案、最小权限和明确不可逆批准点 |
在这个框架下，我还会做五个具体调整。
一个 phase，只给一次授权
授权的对象不再是下一条命令，而是一个有边界的执行包。包内的安全步骤可以连续完成；只有遇到外部写入、不可逆动作、成本扩大或目标变化时才暂停。
小任务减少状态文件，大任务保留完整计划
小任务只需要短规则和一个自包含的执行计划。长任务或高风险项目再拆出状态、决策和会话日志。文件的价值在于恢复和约束，而不是数量本身。
模型按任务路由
机械、边界明确的工作使用轻量模型；普通复杂工作从中等推理开始；高风险判断、复杂仲裁和最终审计再升级。是否使用最高推理，应该由同类任务的结果证明，而不是由焦虑决定。
默认一名主代理加一名审查者
更多子代理只用于真正独立的证据通道、前期侦察、盲审和可机器汇总的工作。能够用确定性脚本完成的批量提取、去重和核对，不再交给许多代理重复阅读。
诊断先看系统，再让人测试
固定顺序应该是：日志、状态和 API → 建立假设 → 最小可逆测试 → 结果验证 → 最后才请求用户做 UI 盲测。
这能减少“你再点一下看看”的低质量协作，也能让代理承担真正的排查责任。
最后的判断
这次审计让我确认，我已经从“让 AI 帮我完成任务”，走到了“设计 AI 如何完成任务”的阶段。
这是一个进步，但也带来了新的陷阱：流程会因为一次事故不断加规则，最后所有任务都背着同样沉重的历史包袱；强模型和多代理会制造能力很强的感觉，却把审查成本悄悄转移给人；状态文件会帮助恢复，也可能因为重复而吞噬上下文。
所以，我下一阶段不准备继续增加控制层，而是要把控制方式换掉：
从逐步监督每一个动作，转向设计一个有权限边界、机械护栏和明确验收的执行环境，让 Codex 在这个范围内独立完成工作。
真正成熟的 AgentOps，不是让代理永远询问，也不是让代理拥有无限权限，而是让它在合适的范围内不需要问，在越过边界之前一定会停。
这可能也是我接下来使用 Codex 最重要的一次升级。