两天、60 美元、第一课仍未交付：一次 Codex 教学任务失控复盘

我原本只想让 Codex 根据当前进度，用 teach Skill 带我系统学习 RAG。
两天后，额度消耗接近 60 美元，第一节课却仍没有按时交到我手里。
最初我以为是 Sol + high reasoning 的 ” 过度思考 “，后来才发现：真正拖垮任务的不是模型想得太多，而是一套曾经很好用、如今却与强模型发生错配的重型流程。

一件本来很简单的事

事情的起点并不复杂。

我的 RAG 项目已经完成了最小链路、Embedding 检索、Benchmark 和一套比较完整的评测体系。我希望继续学习 RAG，但不想脱离项目空谈概念，于是调用了 teach Skill，大意是：

基于当前项目进度，系统地教我 RAG 原理。

我还给出了非常具体的约束：

• 每节课控制在一小时左右；
• 实验难度要适合当前环境；
• 不方便真实部署的内容，可以用架构图或 JavaScript 模拟；
• 先做出第一节课，再逐步推进后续课程。

正常情况下，我期待的是一条很短的交付链路：读取当前进度，确认本节目标，制作一页课件，加一个小实验，验证能打开，然后交付。

结果却完全走向了另一个方向。

Codex 没有直接制作第一课，而是先确认学习使命，再设计课程地图，再设计教学闭环，再创建教学工作区规格，再写实施计划，再让我选择执行模式。随后，任务进入了由多个子代理组成的实现、审查、修复、复审流水线。

每一步单独看都 ” 很专业 “，组合起来却让一个一小时课件变成了接近生产软件项目的交付工程。

60 美元到底花在了哪里

这里的 “60 美元 ” 来自我当时看到的 Codex 额度消耗，不是逐个 API Response 汇总出来的精确账单。Codex 会话没有向我暴露完整的逐次 Token 明细，因此我无法把每一分钱精确分配到某一次模型调用上。

但会话记录足以说明钱大致花在了什么地方：不是花在第一节课的正文，而是花在了流程的重复展开上。

整个教学任务被拆成四个实施任务。围绕这些任务，底层记录里出现了 21 次子代理派发尝试，其中 20 次成功创建代理、1 次因调用脚本语法错误失败；整个会话共出现 159 次 wait 调用，其中 156 次集中在子代理执行阶段。中间还发生了这些事情：

• Task 1 的实现代理长时间无响应，换了新的实现者继续；
• Task 2 经历实现、独立审查、修复和复审；
• Task 3 围绕静态 CSS 测试连续修复三轮；
• Task 4 又经历两轮修复；
• 聚焦测试、教学测试和全仓测试被重复执行；
• 页面在桌面端、手机端和多种权限状态下反复验收；
• 最后还要进行一次全分支审查；
• 临时工作区丢失后，部分任务重新启动；
• 额度窗口中断后，审查流程再次恢复。

最荒谬的阶段，是流程开始围绕这些问题继续迭代：

• 14px 是否低于约定的默认可读字号；
• .875rem 是否可能绕过测试；
• outline: 0px 会不会伪装成可见焦点；
• CSS 字符串里的 font-size 会不会被测试误判；
• 两张教学流程卡在桌面上是否足够均衡；
• fake DOM 是否真正模拟了同一页面内的连续事件。

这些问题不是完全没有价值，但它们与 ” 让我在一小时内学懂 RAG 的端到端链路和权限边界 ” 之间，已经相距很远。

流程在持续提高一个教学页面的边缘正确性，却没有优先完成最重要的事情：把第一课交给学习者。

我最初怀疑：是不是 high 模式想得太多

看到额度快速消耗，我的第一反应是：是不是 Sol + high reasoning 模式发生了过度思考？

这很符合直觉。高推理模式会投入更多计算，任务又涉及架构、安全和教学设计，它似乎很容易 ” 钻牛角尖 “。于是我先追问 Codex：为什么做了这么多思考？到底是提示词影响、Skill 影响，还是模型原本就打算这样做？

严格来说，我拿不到模型逐 Token 的隐藏思维链。我能得到的是可观察的决策说明、工具调用和流程记录。但这些证据反而让我发现：单纯把问题归因于 high reasoning，解释不通。

原因很简单：

模型可能会多想，但它通常不会凭空发明一套如此稳定、重复、格式统一的工程仪式。

如果只是模型自由发挥，流程应该更随机：有时多查资料，有时多写解释，有时增加几个测试。但这次执行呈现出高度规律的结构：每个任务都要经过实现、审查、修复和复审；所有任务结束后还要做最终审查；每一轮都有明确的报告、提交、测试和等待状态。

这不像一次偶发的 ” 想太多 “，更像模型正在忠实执行某套流程规范。

于是我开始回头检查：到底有哪些 Skills 被加载了？

真正的根源：一条 Superpowers 技能链

最终定位到的不是某一个孤立 Skill，而是一条连续触发的流程链：

第一步：teach 把一次答疑扩展成长期教学工作区

teach 是我主动调用的。它的目标不是在聊天里随便解释一个概念，而是建立可持续学习体系。它要求维护：

• 学习使命；
• 可信资料清单；
• 独立 HTML 课程；
• 可打印的参考资料；
• 共享样式和交互组件；
• 学习记录；
• 交互练习和反馈闭环。

因此，teach 确实提高了任务的基础规格。但这部分仍然符合我的目标：我本来就希望系统学习，而不是得到一次性的简单回答。

问题出现在下一步。

第二步：brainstorming 把课程判断成 ” 架构型项目 ”

因为要创建新的课程、组件和教学行为，Codex 又触发了 Superpowers 的 brainstorming Skill。

这个 Skill 有一套很强的流程门禁：

• 动手前必须先确认设计；
• 不确定任务属于轻量还是架构型时，选择更重的路径；
• 一旦升级为架构型，中途不能降级；
• 架构型任务必须经过澄清、方案比较、分段设计、规格文档和用户审批；
• 规格通过后，必须进入 writing-plans。

于是，” 先做一节 RAG 课 ” 被解释成 ” 建立一套长期教学子系统 ”。

从形式逻辑上看，这个判断没有错：课程确实有目录、资产、记录和交互组件。但从用户价值看，它犯了一个更重要的错误：

它优化的是教学系统的完整性，而不是第一节课的交付速度。

第三步：writing-plans 把设计变成详细软件实施计划

规格通过后，writing-plans 接管流程。它要求把计划写得足够详细，让一个完全不了解仓库的工程师也能照着实施。

每个任务都要列出：

• 创建和修改哪些文件；
• 输入、输出和接口是什么；
• 先写什么失败测试；
• 怎样确认测试失败；
• 怎样做最小实现；
• 怎样确认测试通过；
• 怎样提交代码。

它还明确要求采用 TDD、频繁提交，并在计划结束后给出两种执行方式。其中 ” 子代理驱动 ” 被标注为推荐方案。

于是我选择了界面上看起来更合理的选项：

子代理驱动（推荐）。

现在回头看，这个选择其实缺少最重要的信息：成本。

我同意的是 ” 用子代理加快执行 “，不是 ” 为每个静态教学文件安排完整的软件质量流水线 “。但当时系统没有告诉我，这个选择意味着每个任务都可能触发新的实现代理、审查代理、修复代理和复审代理。

第四步：subagent-driven-development 让成本指数式放大

真正把事情推向失控的，是 subagent-driven-development。

它的核心原则是：

每个任务使用新的实现代理，随后进行任务级规格与质量审查；发现问题就修复并复审；所有任务结束后，再进行一次完整分支审查。

这套方法用于高风险生产代码非常合理。认证、支付、数据迁移、权限控制或核心基础设施，确实值得反复验证。

但这次的实际对象是一节教学课件。

一个静态课程页面的字号问题，也被放进了与生产缺陷相同的审查流水线。审查代理越认真，就越能找到新的边界；找到新的边界，就会触发新的修复；修复又会触发新的复审。

这形成了一个自我强化循环：

审查越细
  → 找到的边缘问题越多
  → 修复轮次越多
  → 新代码和新测试越多
  → 可供下一轮审查的表面积越大
  → 又能找到更多问题

它并不是在 ” 偷懒 ” 或 ” 胡乱消耗 “。恰恰相反，它是在非常认真地完成 Skill 交给它的流程。

问题是，这个流程不应该被完整应用在这里。

把结论还原到原始记录：四组可核对的证据

前面的分析不是根据最终结果倒推出来的故事。原始会话保留了用户消息、Skill 文件读取、代理派发、等待调用、提交和最终交付时间。下面只整理四组与结论直接相关的证据。

文中时间统一换算为北京时间（UTC+8）。会话跨越 2026 年 8 月 26 日晚到 8 月 28 日凌晨；从调用 teach 到第一课最终通过审查约 29 小时 54 分。这个墙钟时间包含用户确认、额度窗口和中断恢复，并不等于模型连续计算了近 30 小时。

证据一：完整会话时间线与关键节点

这条时间线最重要的不是 ” 模型一直忙了多久 “，而是第一课在整个流程中的优先级。任务先完成课程地图、教学闭环、设计规格和 880 行实施计划，随后又完成三项前置任务；真正生成第一课的 Task 4，直到第二天晚上才开始。

证据二：四个 Skills 的实际触发记录

下面不是根据文件名猜测影响，而是会话里实际发生的读取和交接。

四者的关系可以直接从原始内容中闭合：

用户显式调用 teach
  → Codex 判断创建教学内容需要 brainstorming
  → brainstorming 将任务判为架构型并要求写规格
  → 规格通过后强制转入 writing-plans
  → writing-plans 在计划头部推荐 subagent-driven-development
  → 用户选择推荐项
  → subagent-driven-development 要求逐任务实现、审查、修复复审和最终审查

因此，high reasoning 只能解释每一轮可能投入了多少思考，不能解释为什么每一轮都稳定遵循同一种角色和审查结构。流程结构来自实际加载的 Skills。

证据三：21 次子代理派发分别做了什么

原始记录中共有 21 次 spawn_agent 调用尝试。需要精确说明的是：第 14 次调用因为 JavaScript 模板字符串中的提交消息触发语法错误，没有真正创建代理；第 15 次是修正转义后的立即重试。因此，记录是 21 次派发尝试、20 个成功创建的代理。

从角色分布看，20 个成功创建的代理中，7 个承担实现、替换实现或专项修复，13 个承担审查或复审。也就是说，成功派发中 65% 是审查角色，只有 35% 是实现角色。

这还没有把 ” 恢复原实现代理继续修复 ” 计算成新的派发。例如 Task 3 的实际修复代码由已有实现代理继续完成，表中只统计随后新创建的复审代理。因此，21 次不是全部代理交互，只是新建代理的次数。

证据四：159 次等待调用怎样放大长会话成本

wait 的语义是等待正在运行的命令或子代理返回。等待本身不是 ” 模型在沉思 “，也不能把 60 秒等待直接换算成 60 秒推理费用。真正的问题是：高频等待把一次实现拆成大量 ” 控制器判断 → 调用等待 → 接收状态 → 再次判断 ” 的模型续接回合。

先看数量和墙钟时间：

159 次等待的配置也很有规律：127 次请求最多等待 30 秒，25 次请求最多等待 60 秒，6 次请求最多等待 40 秒，1 次请求 1 秒。把请求窗口上限简单相加是 92 分 31 秒；代理提前返回后，实际记录约 60 分 39 秒。

真正放大 Token 和上下文成本的机制有四层：

1. 每次等待前后都需要控制器重新续接。 控制器要判断代理是否完成、是否失联、是否需要追问、关闭、替换或进入审查。
2. 长会话前缀不断重复进入请求。 Task 4 重派附近的一条 Token 事件显示，单次续接输入为 77,315 tokens，其中 76,544 为缓存输入。缓存降低价格，却不等于零成本，也不减少调度复杂度。
3. 状态输出继续累积。 仅 156 次子代理执行等待返回的工具输出，序列化后就约 33,658 个字符；后续回合还要继续携带必要的任务状态、报告和审查结论。
4. 轮询让流程更容易继续展开。 每次醒来都可能产生一条状态说明、一次新的检查或一次替换决策。代理失联、临时目录丢失和最终审查中断，又进一步触发新代理和新的完整上下文读取。

因此，159 次 wait 不是 60 分钟 ” 纯浪费 “，也不是 159 次完整模型训练式推理。它是一个流程放大指标：说明主控制器为了维持多代理流水线，被迫进行大量细碎续接。真正昂贵的是等待两侧的模型回合、重复上下文、状态输出和失败恢复。

为什么曾经顺手的 Superpowers，现在反而成了限制

我以前很喜欢 Superpowers。

在模型能力还不够强的时候，代理经常会出现这些问题：

• 没看懂需求就开始改代码；
• 忘记测试；
• 做着做着偏离目标；
• 上下文一长就遗漏约束；
• 实现完不自查；
• 遇到复杂任务无法稳定拆解。

这时，强约束框架非常有价值。它像外骨骼一样，替模型提供任务分解、状态管理、测试和审查能力。模型本身做不到的事情，可以通过流程强制完成。

但模型能力已经发生了变化。

今天更强的模型能够直接理解用户意图、阅读仓库、判断风险、完成多文件修改并主动验证。在这种情况下，旧框架里为弱模型设计的每一道强制门禁，都可能从 ” 能力补丁 ” 变成 ” 重复劳动 ”。

这里的关键不是 ” 强模型不需要流程 “。真正的问题是：流程是否仍然与模型能力、任务风险和交付目标匹配。

如果模型已经能稳定完成一次实现，那么再强制它把同样的上下文交给多个代理重复阅读，并不会自动得到十倍质量。更常见的结果是：

• 同一份规格被重复输入；
• 同一段代码被多个代理重复解释；
• 每个代理都倾向于证明自己的审查有价值；
• Minor 问题不断被升级成新的工作；
• 流程正确性压过了用户价值；
• Token、时间和注意力被消耗在交接上。

最终可能花了十倍甚至更多的代价，得到一个比强模型直接生成还臃肿、还迟缓的结果。

这正是我这次最强烈的感受：不是模型能力不够，而是框架没有让它直接发挥能力。

生产环境当然应该谨慎，但谨慎也必须有风险比例

” 生产环境再仔细都不过分 ” 这句话，只说对了一半。

认证、授权、隐私、支付、数据删除和不可逆迁移，确实应该进行高强度审查。一次错误可能造成数据泄漏、资金损失或长时间事故。

但不同问题的风险完全不同：

这次真正的错误，是把 ” 生产级 RAG 知识内容 ” 误解成了 ” 生产级课程软件交付 ”。

我要求的是：课程要讲清楚生产级 RAG 的安全边界。

流程理解成的是：课程页面本身也要按高风险生产系统的标准反复审查。

这两个 ” 生产级 “，完全不是一回事。

为什么流程越完整，结果反而可能越差

工程流程通常被认为可以提高质量，但它并不是免费的。每增加一次角色交接，都会产生新的损耗：

总成本 ≈ 实际实现成本
       + 上下文重复读取
       + 代理交接成本
       + 审查与复审成本
       + 等待和失败恢复成本
       + 新流程产物的维护成本

当任务足够高风险时，这些额外成本是值得的。

但当任务本身很小，固定流程成本可能远大于实现成本。更糟糕的是，审查并不只会发现问题，它也会创造新的工作表面积：为了覆盖一个边缘情况增加测试辅助逻辑，辅助逻辑又需要被审查，新的审查再发现辅助逻辑的边缘情况。

于是，系统开始优化 ” 如何证明自己没有 Bug”，而不是优化 ” 如何尽快给用户一个有用的结果 ”。

这也是为什么最终产物可能不如模型直接生成：

• 为了让任务能被不同代理独立执行，计划必须写得极细，压缩了实现者的判断空间；
• 实现者更关注逐条满足规格，而不是整体表达效果；
• 审查者更容易发现局部可验证问题，却不一定感知用户已经等了两天；
• 多轮小修让代码和测试越来越复杂；
• 设计在交付前被过早固化，强模型无法自然地用更简单方案收敛。

框架原本是为了减少偏差，最后却制造了另一种偏差：对流程的忠诚，高于对结果的忠诚。

这件事像极了现实生活

这次经历让我想到的不只是 Agent 框架。

很多方法在诞生时都解决过真实问题。旧时代的信息不足、能力不足和协作成本，塑造了当时的最佳实践。后来环境变了，我们却很容易把方法本身当成真理。

时代在发展，世界在变化。如果认知仍停留在原地，我们就会用过去解决问题的方式，去限制今天已经出现的新能力。

这就像：

• 自动化设备已经能自主校准，我们仍要求每一步人工签字；
• 团队已经缩小到两个人，却继续沿用大公司的七层审批；
• 模型已经能理解完整目标，我们仍把每个动作拆成机械指令；
• 风险已经从 ” 生产数据 ” 降到 ” 教学页面 “，流程却没有跟着降级。

这些制度并非一开始就是错的。真正的问题是，它们停止了进化。

一个曾经正确的框架，如果不能根据能力、环境和风险重新校准，最终就会从护栏变成枷锁。

我的处理：卸载本机所有来自 Superpowers 的 Skills

确认根因后，我最终选择卸载本机所有来源于 Superpowers 的 Skills，避免它们继续自动进入后续任务的决策链。

这里所说的 ” 污染 ” 不是恶意代码或安全污染，而是决策上下文污染：

• 一个普通任务因为匹配到 Skill 描述，被自动升级；
• 一个设计流程又强制触发下一个计划流程；
• 计划流程继续推荐多代理执行；
• 后续步骤已经不是模型重新判断 ” 是否有必要 “，而是忠实完成前置流程规定的动作。

我没有否定 Superpowers 的历史价值，也不认为所有人都应该卸载它。对于较弱模型、能力不稳定的代理，或者真正高风险的生产任务，它仍可能非常有用。

但对我当前使用的强模型和任务类型来说，它带来的流程偏置已经超过了收益。与其试图逐条修改几十项规则，我更愿意先清空这层默认约束，让模型重新直接面对用户目标。

我准备怎样替代它

卸载重型流程不等于不要工程纪律。相反，我希望把流程改成更短、更明确、与风险成比例的五步闭环：

1. 先确认最终交付物

不是先问 ” 要走哪个流程 “，而是先问：用户最终要拿到什么？

这次答案应该非常简单：一节一小时内可以完成的 RAG 课程。

2. 判断真实风险

将风险分成低、中、高三类。

• 教学排版、示意动画：低风险；
• 仓库代码和普通功能：中风险；
• 权限、隐私、生产数据和不可逆操作：高风险。

只有高风险部分才增加专项审查，而不是把整个任务全部升级。

3. 默认直接实现最小闭环

强模型能独立完成时，让它直接完成。只有任务确实可以并行、上下文互不重叠，或者需要独立专业判断时，才使用子代理。

子代理不是默认仪式，而是一种有成本的工具。

4. 验证必须与失败代价匹配

教学页面做一次桌面检查、一次窄屏检查和核心交互检查即可。权限边界则必须做严格测试。

不要因为测试还能继续写，就继续写测试。

5. 预先写下停止条件

没有停止条件的审查，一定可以永远审查下去。

开始前就应该明确：

• 核心目标完成；
• 相关测试通过；
• 没有未解决的高风险问题；
• Minor 问题记录但不阻塞；
• 到达预算或轮次上限就停止扩展。

给 Agent 工作流设计者的几个提醒

这次事故让我重新思考 Skills 和 Agent 框架应该怎样设计。

Skill 应该提供能力，不应该无条件接管决策

一个好的 Skill 应当告诉模型 ” 你可以怎样做 “，而不是在任何匹配场景下都规定 ” 你必须完整做完哪些仪式 “。

推荐选项必须显示成本

” 子代理驱动（推荐）” 不是一个中性的标签。它至少应该同时显示：预计代理数量、审查轮次、时间和 Token 成本，以及什么类型的任务值得选择它。

风险应当局部升级，而不是整体升级

课程中有权限安全内容，不代表 CSS、排版、引用和所有测试辅助逻辑都要进入安全级审查。

多代理需要证明收益，而不是默认更先进

多个代理适合真正可以独立拆分的复杂任务。对于一个强模型本来就能一次完成的小任务，多代理更像增加沟通层，而不是增加能力。

框架也需要版本淘汰机制

Agent 框架不能只问 ” 是否减少了模型犯错 “，还要持续问：

• 它是否压制了新模型已经具备的能力？
• 它增加的质量是否值得增加的成本？
• 它是否仍然适合当前任务分布？
• 它有没有让流程指标取代用户价值？

写在最后

两天、接近 60 美元、第一课仍没有按计划交付，当然是一件尴尬的事。

但它也让我看清了一个比单次额度浪费更重要的问题：

当模型能力快速提升时，我们不能只升级模型，却继续沿用为旧模型设计的全部约束。

流程不是越完整越好，审查也不是越多越好。真正成熟的工程能力，不是为所有事情套上最重的流程，而是知道什么地方必须严谨，什么地方做到足够好就应该停止。

Superpowers 曾经帮助我把不稳定的模型约束成可用的工程代理。但在这次任务里，它也让我看到：任何框架一旦停止适应环境，都可能从能力放大器变成能力限制器。

工具会过时，最佳实践会过时，我们对模型的认知同样会过时。

真正应该保留的，不是某套固定流程，而是持续根据现实更新流程的能力。

证据范围说明

本文只使用并展开了四类直接证据：完整会话时间线、四个 Skills 的实际触发记录、21 次子代理派发尝试，以及 159 次等待调用。其他可能进行的对照实验或扩展分析不列入本文计划，避免再次把一次复盘扩展成没有边界的新项目。

本文是一份单次真实使用复盘，不是对所有模型、所有版本和所有 Superpowers 使用方式的普遍性基准。文章中的额度来自当时可见的账户消耗；关于具体 Skill 的影响判断，则来自会话中的实际加载记录、代理调用和任务执行轨迹。