每隔两小时，Codex 会为我准备一批待审的邮件回复草稿。
大多数草稿质量不错，但我还是会修改它们。
我可能会加上一条更早的会话记录或某次面对面聊天的决定，因为了解发件人而把语气放软一些，或者删掉一个我还没准备好做出的承诺。草稿可能写得很好，但仍然让人觉得千篇一律。这种千篇一律的感觉常被叫作 "AI 味"，但在这种情况下，问题不在于智能程度，而在于缺少上下文。
没有人做错什么。Codex 是基于它掌握的信息工作的，而我的修改则补上了它没有的上下文。有意思的是，这些修改本身也包含了上下文：它们揭示了在这个场景里什么才是重要的——我保留了哪些、改了哪些、拒绝了哪些、以及哪些是我觉得不适合发出去的。
大多数自动化工具都不会保留这些上下文。下一次运行还是从同样的不完整画面开始。
我发现把上下文分成两类来思考很有帮助。
首先，是工作开始前就需要具备的上下文：历史、事实、约束、关系、以及先前的决定。
其次，是工作完成后才显露出来的上下文：一个人在审查过程中保留了什么、改了什么、拒绝了什么、发出去什么、或者搁置了什么。
这样就形成了两个循环。内循环把正确的上下文带到任务中，生成一份草稿。外循环从审查中学习，并把学到的上下文提供给下一次任务使用。
内循环：为工作带来上下文
针对邮件场景，内循环会判断一条消息是否需要回复，找到相关的上下文，写出回复草稿，核实其中的主张，最后生成一份供审查的草稿。
这个工作流可以固定在一个用代码写成的流程里，或者用工作流构建器搭建：获取消息 → 过滤噪音 → 分类 → 起草 → 检查结果。或者，Codex 也可以通过一个简单的提示词（比如 "每天早上 9 点为我需要回复的邮件创建草稿"）来自行决定执行哪些步骤，它会检查新的线程、找回相关的历史记录、研究缺失的信息、准备回复、并标记出任何不清楚的地方。
两种方式都可行。重要的是：检索必须是写作的一部分。
一条回复可能依赖于一封类似的邮件、一个六个月前的决定、项目追踪器里的当前状态、或者某个核准来源里的事实。Codex 可以收集这些上下文，或者让子 Agent 去研究一个具体问题。目标不是检索所有信息，而是找到能让回复准确且具体的最小信息集。
我保持操作可逆：只创建草稿，从不自动发送。在我编辑之前，内循环会保存提议的回复、它的来源、以及生成它的提示词和写作指南的版本。如果没有这些记录，审查就只是一段轶事；有了它们，审查就变成了有据可查的过程。
外循环：从审查中恢复上下文
外循环在我审查草稿后启动。结果是：未修改直接发送、修改后发送、已删除、或待处理？
这些结果有不同的含义。未修改直接发送说明草稿没问题。修改后发送则提供了一组修改前后的对比。已删除的草稿比较难解读——可能是内容不对，或者根本不需要回复。待处理的草稿几乎说明不了什么。
即使是发出的邮件也只能记录我接受了什么，并不能反映回复是否有效。真正的结果可能要等来回复或后续工作才能看出来。不过，审查确实增加了写草稿时没有的旁证。
草稿和最终发送版本之间的差异就是旁证。它不自动等于一条教训，也不该自动变成提示词修改。
开头写短了可能只是写作偏好。多了一个事实可能揭示内循环找错了地方。删掉一个承诺可能提示工作流需要多加一项检查。重写了一段可能反映了一种应该保留给人做的判断。
差异对比（diff）可以展示什么变了。但理解这些变化的含义，才是外循环真正的工作。
外循环改进内循环
外循环的存在是为了让下一次内循环运行得更好。
它会审查 Codex 的草稿和我最终发送的版本之间有哪些变化，然后问：如果一开始就具备什么条件，能让 Codex 离最终版本更近？
答案可能是更好的写作指南、另一个信息来源、一个新的搜索步骤、一项检查来防止未经确认的承诺、或者更早地把任务交给我。不是每一次修改都要变成规则。外循环会寻找模式，提出最小的有用改动，然后由我决定保留哪些。
在实际操作中，我会把这些经批准的经验教训保存在一个简单的 Markdown 文件里。外循环会提出对这个文件的更新；内自动化在起草下一封邮件之前会读取这个文件。
这就是审查改进内循环的方式：我今天纠正的内容，会成为明天运行的上下文。
两个循环，两种节拍
两个循环以不同的频率运行。内循环快速响应，也许每两小时一次。外循环则等待足够的样本，在一天结束时运行，或者积累十封已审查的草稿后运行，样本少时则每周运行一次。
外循环运行太频繁，可能会从异常案例中学习。完全不管它，有用的修正又会随着下一封草稿消失。
同样的模式也适用于演示文稿、报告、简报和问题分类。在每一种场景中，如果工作流能够同时使用两种上下文——写初稿之前已知的上下文，以及审查之后才揭示的上下文——那么工作的质量就会提高。
模型已经足够强大。真正的机会在于构建那些不让模型每次运行都重新发现同样上下文的工作流。
内循环把正确的上下文带到工作中来。外循环把工作过程中揭示的上下文保存下来。
