其实主要问题在 gpt5.6 比 5.5 更喜欢阅读整个文件导致上下文膨胀严重。而且高 reasoning 又忒喜欢反复思考原地踏步。其实主要问题都是 codex 本身的问题。我自己弄了个 harness 。
这个想法其实非常简单。假设 Codex 需要修改文件并运行测试，通常需要经历以下流程：
第 1 轮——应用补丁（修改 package 文件）
第 2 轮——应用补丁（修复 Bug ）
第 3 轮——应用补丁（修改测试脚本）
第 4 轮——执行构建
第 5 轮——运行测试和代码检查
第 6 轮——如果使用 Playwright ，Codex 还需要额外一轮读取截图等媒体文件
我们的思路是使用宏命令，将整个流程放入一个 RAG 中，从而在单轮内完成。例如：
步骤 1：检查运行环境
步骤 2：应用补丁（修改 package 文件）
步骤 2：应用补丁（修复 Bug ）
步骤 2：应用补丁（修改测试脚本）
步骤 3：执行构建
步骤 4：运行测试和代码检查
步骤 5：读取媒体文件
我使用 Codex 和 GPT-5.6-Sol High 对这种方式进行了测试。结果显示，它可以减少约 40%–80% 的大模型交互轮次，同时节省接近相同比例的 Token 。
具体实现和测试基准可以在项目的 Markdown 文档中找到。我使用 DeepSWE 任务和完整代码仓库重写任务进行了测试：repo: https://github.com/Tura-AI/tura
benchmark 文档： https://turaai.net/docs#benchmark-current-test-set-record
这个想法其实非常简单。假设 Codex 需要修改文件并运行测试，通常需要经历以下流程：
第 1 轮——应用补丁（修改 package 文件）
第 2 轮——应用补丁（修复 Bug ）
第 3 轮——应用补丁（修改测试脚本）
第 4 轮——执行构建
第 5 轮——运行测试和代码检查
第 6 轮——如果使用 Playwright ，Codex 还需要额外一轮读取截图等媒体文件
我们的思路是使用宏命令，将整个流程放入一个 RAG 中，从而在单轮内完成。例如：
步骤 1：检查运行环境
步骤 2：应用补丁（修改 package 文件）
步骤 2：应用补丁（修复 Bug ）
步骤 2：应用补丁（修改测试脚本）
步骤 3：执行构建
步骤 4：运行测试和代码检查
步骤 5：读取媒体文件
我使用 Codex 和 GPT-5.6-Sol High 对这种方式进行了测试。结果显示，它可以减少约 40%–80% 的大模型交互轮次，同时节省接近相同比例的 Token 。
具体实现和测试基准可以在项目的 Markdown 文档中找到。我使用 DeepSWE 任务和完整代码仓库重写任务进行了测试：repo: https://github.com/Tura-AI/tura
benchmark 文档： https://turaai.net/docs#benchmark-current-test-set-record
Select Language