#探寻人工智能，人与AI全新序章#
我这两天在研究 Codex 的一些问题反馈，这个案例挺有意思拿出来和大家分享。
6 月 11 日，一位 Windows 11 用户把一项范围很小的文件处理任务交给 Codex：读取当前锁文件，只处理一条游戏数据，生成一份小报告，然后停止。
他使用的是 Codex App、GPT‑5.5、Extra High（超高推理）和 Fast（快速模式）。从配置看，算力和速度都已经拉得很高。
结果第一次跑了两个多小时，第二次超过 4 小时，项目里依然没有一个文件发生变化。
Codex 并没有安静地卡死。它一直在读项目规则、检查锁文件、确认版本、恢复连接，看起来每一步都很认真。界面偶尔出现 `Context automatically compacted`，随后又开始读取刚刚检查过的文件。
4 小时里，它重复准备开工，却始终没有真正开工。
这类故障比直接报错更浪费时间。红色报错出现时，人会马上处理；Codex 一直显示 Working（工作中），反而容易让人继续等下去。
它忙了 4 小时，git 为什么还是一片空白
这次任务本身并不复杂。
用户已经把范围限制得很窄：
读取当前锁文件只处理一条输入记录不要使用旧会话记忆不要执行 Git 命令不要扫描整个项目生成一份小报告后停止按正常节奏，Codex 应该先确认输入，再创建目标文件，最后验证结果。
实际运行轨迹却变成了：
读取 START_HERE读取 ACTIVE_TASK读取 PROJECT_STATE读取 CANONICAL_PATHS检查锁文件和注册表自动压缩上下文连接中断恢复会话重新读取同一批文件再次压缩这套循环持续了数小时。
最危险的地方在于，它每轮都能产生新的界面文字：准备检查、继续处理、重新确认、恢复上下文。用户看到内容不断刷新，很容易把“有输出”误认为“有进展”。
文件任务有没有真正推进，判断标准其实很朴素：
git status --shortgit diff --stat项目没有使用 Git，也可以直接查看目标目录最近修改的文件。
Windows PowerShell 可以运行：
Get-ChildItem . -Recurse -File | Sort-Object LastWriteTime -Descending | Select-Object -First 10 FullName, Length, LastWriteTime界面说了多少话不重要。目标文件有没有出现、修改时间有没有变化、差异是否真实存在，才是文件任务的进度。
真正把它困住的，是“预检—压缩—重连”循环
这次事故不能简单归咎于上下文压缩。
Codex 处理长任务时，本来就会压缩较早的内容，把重要信息整理成摘要，为后续操作腾出空间。这个机制正常工作时，可以让一条长会话继续运行。
问题出在压缩之后的恢复方式。
这份案例里，Codex 没有从“已经完成预检”的位置继续，而是重新回到了入口：
先检查锁文件再读取项目热文件重新确认规则准备开始处理接着上下文又被填满，再次压缩，连接又出现异常：
websocket closed by server before response.completed恢复后，它依旧缺少一个可靠的“阶段记号”，不知道自己已经完成过哪些步骤，只能再做一遍最安全的准备工作。
完整任务通常可以拆成几个阶段：
预检开始预检完成开始写入执行验证生成最终报告任务结束这次 Codex 长时间停在前两步之间。它读了大量文件，却没有产生第一次耐久写入，因此每次恢复都很难证明自己已经走到哪里。
从用户视角看，它工作了 4 小时。
从文件系统视角看，它可能连第一个真正动作都没开始。
项目规则越完整，为什么反而越难走出门口
这个案例发生在一个规则文件较多的项目中。
项目里存在多份 Markdown 和 JSON 状态文件，例如：
_codex/00_START_HERE.md_codex/01_ACTIVE_TASK.md_codex/02_PROJECT_STATE.md_codex/indexes/CANONICAL_PATHS.md_codex/rules/*.md_case_queue/CURRENT_CASE_LOCK.jsonruntime/registry/*.json这些文件单独看都有合理用途：
START_HERE 告诉 Codex 从哪里开始；ACTIVE_TASK 说明当前任务；PROJECT_STATE 保存项目状态；CANONICAL_PATHS 避免使用错误目录；锁文件防止重复处理。问题出现在“每轮都要重新确认”。
规则越多，预检成本越高；连接或压缩一旦打断，重新读取的内容也越多。还没产生文件修改，上下文已经被规则、状态、注册表和工具输出占去一大块。
官方对 `AGENTS.md` 的建议也很明确：主文件应尽量简洁，任务专用的规划、审查和架构说明放进独立文件，需要时再引用。
我会把项目规则分成三层：
层级
适合放什么
加载方式
常驻规则
安全边界、测试命令、禁止事项
每次加载
任务规则
本次输入、目标文件、验收标准
当前任务加载
历史资料
旧状态、运行记录、完整账本
需要时查询
项目状态很完整，不代表每一个小任务都要重新阅读整套历史。
一次只改一个文件的任务，却先背完整个项目档案，开工速度自然会越来越慢。
实践：15 分钟止损，先逼出第 1 次真实写入
遇到这种空转，我不会再让它无限等待。
我的止损线是 10—15 分钟。文件编辑任务超过这个时间，仍然没有目标文件、Git Diff（代码差异）或修改时间变化，就先停止当前运行。
重新开始时，把任务压成一个“最小执行包”。
提示词可以这样写：
目标：只处理 CURRENT_CASE_LOCK.json 指向的这一条记录，生成 reports/case-当前编号.md，然后停止。允许读取：1. _case_queue/CURRENT_CASE_LOCK.json2. 当前记录对应的输入文件3. reports/FORMAT.md禁止：1. 不扫描整个仓库2. 不读取历史任务账本3. 不执行 Git 命令4. 不重复读取已检查过的文件5. 不修改目标文件以外的内容执行顺序：1. 先确认目标目录可写2. 在 5 分钟内创建目标文件，并写入任务编号和标题3. 再补充分析内容4. 最后检查文件存在、非空、格式正确止损条件：如果 15 分钟内没有产生文件变更，立即停止，报告已读取的文件、当前阶段和阻塞原因。这里最关键的要求，是尽早产生第一次耐久写入。
先创建目标文件，写入标题和任务编号，能够证明三件事：
路径正确权限可用任务已经离开预检阶段后面的分析即使中断，至少也有一个真实进度点。恢复会话时，可以从已有文件继续，而不用再次猜测任务有没有开始。
对于大型项目，我还会单独建立一个轻量任务包：
task-packet/├── TASK.md├── INPUT.json├── FORMAT.md└── OUTPUT_PATH.txt`TASK.md` 只写当前目标，`INPUT.json` 只放这一条输入，`FORMAT.md` 说明结果格式，`OUTPUT_PATH.txt` 给出唯一交付路径。
Codex 无需重新遍历项目账本，也不需要读取与当前记录无关的规则。
任务包有一个很现实的价值：就算 Codex 再次压缩上下文，它需要恢复的信息也只有四个小文件。
看起来在工作，其实没有进展的 4 个信号
第一，反复宣布“先检查一下”。
偶尔检查一次很正常。连续出现下面这些话，就要警惕：
我先确认当前锁文件我先重新读取项目状态继续前先核对版本我再检查一次规范路径第二，同一批文件被重复打开。
`START_HERE`、`PROJECT_STATE`、锁文件和规则文件循环出现，目标文件却从未创建，说明它可能卡在预检阶段。
第三，频繁出现压缩和重连。
单次 `Context automatically compacted` 不代表故障。压缩后重新回到相同预检流程，再叠加 `Reconnecting` 或 WebSocket 中断，循环风险就很高。
第四，工作时间增长，文件状态不动。
最可靠的监控仍然是：
git status --shortgit Diff --stat文件任务跑了半小时，差异持续为零，就应该要求 Codex 输出状态报告，而不是继续让它“思考”。
推理强度调到 Extra High，或开启 Fast，只能改变模型投入的推理和响应方式。流程已经卡进循环时，更高配置也可能让它更认真地重复同一件事。
哪些任务适合长跑，我会怎么拆
大型重构、跨模块迁移、复杂测试修复，本来就需要较长时间。只要它持续产生可验证进展，运行一两个小时并不奇怪。
我主要看三个指标：
第一，有没有耐久变化。
代码、报告、测试或状态文件持续更新，说明工作在推进。
第二，有没有阶段交付。
完成一个模块后留下 Diff、测试结果或中间报告，后续即使中断也能恢复。
第三，能不能明确说出当前阶段。
“正在工作”没有意义。“预检已完成，已修改 3 个文件，正在运行测试”才是可以判断的状态。
我会把大任务拆成这种节奏：
先侦察并输出计划完成第一个最小改动运行最小相关测试确认 Diff继续下一个模块最后统一审查一次让 Codex“理解整个项目并完成所有工作”，看起来省事，实际更容易触发大范围读取、上下文压缩和恢复困难。
先让它完成一个真实的小闭环，再逐步扩大范围，通常更稳。
干货提炼：别看它忙了多久，要看第 1 次写入何时出现
这次 4 小时空转，可以压缩成 7 条：
1. Codex 持续输出文字，不代表文件任务正在推进；2. 自动压缩本身是正常机制，压缩后反复重跑预检才是危险信号；3. 项目规则和状态文件越多，恢复任务的成本越高；4. 文件编辑任务运行 10—15 分钟仍然零修改，应立即止损；5. 重新执行时，只提供当前任务真正需要的文件；6. 要求 Codex 尽早完成第一次耐久写入；7. 大任务必须留下阶段状态、文件差异和验证结果。以前看到 Codex 一直显示 Working，我会担心中途打断会浪费已经做过的工作。
现在我会先检查文件。
如果 15 分钟过去，Git 仍然干干净净，目标文件也没有出现，那些不断滚动的状态文字，大概率还只是准备动作。
Codex 真正开始工作的标志，不是它说“我现在开始”。
是磁盘上终于出现了第一个可以验证的变化。
热门跟贴