把 Agent 当成单纯的对话窗口用简直是浪费
说白了，就是给 Agent 加上一个流量控制层。当一个任务进来时，它不再是直接写代码，而是先判断：这事儿需要直接上手？还是得先采访我确认需求？或者是得先去审计一遍仓库？
为了实现这个逻辑，我把这套工作流拆解成了几个严格的步骤，把它配置在本地的技能库里。
一、具体的执行链路
这套流程的核心是「能力 → 证明」的闭环，具体跑法如下：
1. 前置检查 (Preflight)： 强制要求 Agent 重述目标，检查仓库现状，把已知事实和猜测分开。
2. 路由分发 (Route)： 根据复杂度决定走哪个通道（直接执行 / 需求访谈 / 因果调查 / 详细规划）。
3. 定义数据包 (Packet)： 给接手的 Worker 定义好所有权、范围、约束条件和停止触发点。
4. 精准交付 (Handoff)： 只给 Worker 必要的上下文，防止信息过载导致幻觉。
5. 结果验证 (Verify)： 检查真实的 Diff，运行测试，扫描影响范围，而不是听 AI 说「我已经搞定了」。
6. 独立评审 (Review)： 用一个全新的上下文环境来判定结果是 ship（发布）、fix-first（先修复）还是 rethink（重新思考）。
7. 持久化记忆 (Remember)： 把重复出现的错误或修正点写进仓库的指令集或测试脚本里。
二、实操部署
如果你想在自己的环境下尝试，可以在本地创建对应的技能文件 ~/.codex/skills/codex-maxxing/SKILL.md，然后把下面的定义贴进去：
---
name: codex-maxxing
description: Route ambiguous, multi-step, or high-impact work through a bounded Codex workflow that converts agent capacity into inspectable proof. Use when a task spans multiple files, agents, tools, or uncertain requirements and needs scoped handoffs, deliberate planning, independent review, and durable repository memory.
---
# Codex Maxxing: Capacity to Proof
Maximize defensible progress per unit of attention. Keep the user in charge of the outcome, give each worker a bounded responsibility, and require evidence before calling work complete.
This is an orchestration skill. Select the lightest workflow that fits the task.配置好之后，在调用时直接指令：Use $codex-maxxing for this task. Keep the change bounded and report proof.
这套方案最聪明的地方在于它是不对称的：简单的改动依然快速通过，但模糊或高风险的任务会被强制拉入这套结构化流程。
