我让 AI 帮我重构代码睡了一觉，第二天它把「不能动的模块」全改了

早上七点，咖啡还没凉，你打开电脑，准备验收昨晚交给 Codex 的重构任务。

然后你看到了这个：

- # 核心认证模块 — 请勿修改（已和 PM 确认）
+ # 重构后的认证模块 v2
class AuthManager:
    def verify_token(self, token: str) -> bool:
+     def validate_credentials(self, token: str, refresh: bool = True) -> dict:

你昨晚明确说过：认证模块先不动，等下周安全审计结束再说。

AI 记住了吗？没有。它不仅动了，还把方法签名改了，还顺手加了个 refresh 参数——逻辑上看起来"更好"，但和你们线上的 SDK 完全不兼容。

这不是假设场景。这是我在测试 Codex + Automations 跨天任务时，第 14 小时发生的真实事故。

---

第一章：「上下文断了」是个多严重的问题？

先说清楚为什么这件事值得认真对待。

普通 AI 对话的上下文窗口是有限的——你和 Claude Sonnet 4.6 聊了几十轮之后，它可能已经"忘记"了你在第三条消息里说的约定。这是模型的物理限制，不是 bug。

但问题在于：真实的工程任务根本不可能在一个 session 里完成。

一个中等规模的后端重构——比如把一个 Flask 单体拆成微服务架构——可能涉及：

15-20 个 Python 文件
3-5 个业务模块
数十条命名规范、注释风格、接口约定

你不可能守在电脑前盯着它跑完。你要开会、要睡觉、要处理其他事情。

理论上，Automations 解决了这个问题。但"理论上"和"实际上"之间，往往隔着一次踩坑。

---

第二章：Codex + Automations 的记忆机制，到底是怎么工作的？

用一个类比来理解：

普通 ChatGPT 对话，像是你雇了一个有严重短期记忆障碍的助手。你每次开口，他都只记得这次对话里说过的话。你昨天交代的事？不知道。 Codex + Automations，更像是你给这个助手配了一本「工作日志」。任务状态、约定规则、已完成的步骤，都记在本子上。他每次开始工作前，先翻一遍本子，再动手。

具体机制上，Automations 做了几件事：

① 任务持久化：任务不再依附于单个对话 session，而是存储在任务队列里，可以暂停、恢复、查看状态。 ② 上下文注入：每次 Codex 执行子任务时，系统会把「任务描述 + 已完成步骤 + 关键约定」重新注入到上下文窗口——相当于每次都把便利贴重新贴到 AI 眼前。 ③ 工具调用链：Codex 在 Automations 里可以调用代码执行、文件读写、测试运行等工具，每一步的输出都会作为下一步的输入，形成有状态的执行链。

⚠️ 关键限制：注入的上下文是「摘要」而非「全文」。当任务复杂度超过一定阈值，摘要的信息损耗会开始显现——这正是「失忆」的根本原因。

根据 OpenAI 官方文档（Automations Beta 说明），单次任务的上下文窗口上限与底层模型一致，长任务通过「任务状态摘要」而非完整历史来维持连续性。这个摘要机制是把双刃剑：它让跨天任务成为可能，也埋下了信息损耗的隐患。

---

第三章：实测——一个跨 18 小时的 Python 重构任务

测试环境

任务：将一个 Flask 单体应用拆分为 3 个独立模块（用户服务、订单服务、通知服务）
规模：15 个 Python 文件，约 3200 行代码
关键约定：命名规范（snake_case + 模块前缀）、认证模块冻结、注释必须中英双语
API 调用：通过 [api.884819.xyz](https://api.884819.xyz) 接入，测试期间延迟稳定在 200ms 以内
时长：18 小时（含 7 小时睡眠中断）

时间轴记录

T+0h    任务启动，交代完整约定，开始重构用户服务模块
T+3h    用户服务模块完成，命名规范遵守率 100%，注释双语 ✓
T+6h    订单服务开始，发现轻微命名漂移（前缀偶尔缺失）
T+7h    【中断】关机睡觉
T+14h   【恢复】次日继续，Automations 加载任务状态
T+15h   通知服务开始，命名漂移加剧，中英注释开始只写英文
T+16h   【事故】认证模块被修改，方法签名变更
T+18h   任务标记完成，人工验收

上下文保留率评分（自定义指标）

我用三个维度来量化「上下文质量」：

| 时间节点 | 命名规范遵守度 | 模块边界识别率 | 注释风格一致性 | 综合评分 | | T+3h | 100% | 100% | 100% | 100 | | T+6h | 94% | 97% | 98% | 96 | | T+14h（恢复后）| 87% | 91% | 79% | 86 | | T+16h | 72% | 68% | 61% | 67 | | T+18h | 65% | 55% | 58% | 59 | 衰减曲线是真实的，而且在「恢复」节点有一次明显跳水。

第 1 小时 vs 第 18 小时：代码风格漂移 diff

# T+1h 生成的代码（规范）
def user_get_profile(user_id: str) -> dict:
"""
获取用户详情
Get user profile by user_id.
"""
return db.query(User).filter_by(id=user_id).first()


T+18h 生成的代码（漂移）
def getProfile(userId):
# Get user profile
return db.query(User).filter_by(id=userId).first()

注意到了吗？三个偏差同时出现：

1. 命名从 snake_case 变成了 camelCase（user_get_profile → getProfile）

2. 参数类型注解消失（user_id: str → userId）

3. 中文注释消失，只剩英文

这不是偶发错误，是系统性漂移。说明到第 18 小时，任务摘要里的「命名规范」约定已经被稀释到几乎无效。

失败案例：认证模块被修改的完整 log

[T+16:23] Codex: 分析 auth/manager.py...
[T+16:24] Codex: 发现 verify_token 方法签名与新架构不一致
[T+16:24] Codex: 正在重构以适配微服务调用模式...
[T+16:31] Codex: auth/manager.py 重构完成

任务日志里完全没有出现「认证模块冻结」的约定。这条约定在 T+0h 时被写入了任务描述，但在 18 小时的摘要压缩过程中，它被判定为「低优先级信息」而丢失了。

---

本次测试调用了 Codex API 进行多轮自动化任务。如果你想复现这个测试或搭建自己的 Automations 工作流，需要稳定的 API 访问渠道。国内用户可以通过 [api.884819.xyz](https://api.884819.xyz) 直连调用，注册即送体验 token，国产模型（Deepseek R1/V3、通义千问 Qwen3 等）完全免费，按量付费无月租——这也是本文测试环境的实际配置。

---

第四章：3 个会让它「失忆」的真实场景

场景一：任务超过 8 小时，指令开始漂移

现象：命名规范、注释风格等「软约定」在长任务中会被摘要系统逐渐稀释。 规避策略：

# Prompt 模板：强制约定锚点

在任务描述的开头和结尾各重复一次关键约定：

【铁律，任何情况下不得违反】
1. 命名：snake_case + 模块前缀（如 user_get_xxx, order_create_xxx）
2. 冻结模块：auth/ 目录下所有文件禁止修改
3. 注释：必须中英双语，中文在上

【铁律重申，执行每个子任务前先确认】
（同上）

通过在任务描述首尾各放一次约定，提高它在摘要中的权重。实测可以把漂移节点推迟到 T+12h 左右。

场景二：文件数超过 12 个，模块边界开始混乱

现象：Codex 开始把属于模块 A 的逻辑写进模块 B，或者重复实现同一个函数。 规避策略：把大任务拆成独立的子任务，每个子任务不超过 5 个文件。宁可多启动几次任务，也不要在一个任务里塞太多文件。

❌ 错误做法：一次性重构 15 个文件
✓ 正确做法：
- 任务 1：重构 user/ 模块（5 个文件）
- 任务 2：重构 order/ 模块（6 个文件）
- 任务 3：重构 notification/ 模块（4 个文件）

场景三：人为中断后重启，接续质量下降约 15%

现象：这是最难规避的。中断本身会导致任务状态摘要「固化」，恢复后的第一个子任务质量明显低于中断前。 规避策略：在恢复任务后，先让 Codex 输出一份「任务状态确认」，再开始执行：

# 恢复任务时的标准 Prompt

在继续执行之前，请先列出：
1. 已完成的模块和文件
2. 当前生效的所有约定（命名规范、冻结模块等）
3. 下一步计划执行的内容

确认无误后再继续。

这个步骤会强制 Codex 重新激活任务摘要里的关键信息，相当于「热身运动」。实测可以把恢复后的质量跌幅从 15% 压缩到 5% 左右。

---

第五章：值得用吗？给不同用户的一句话结论

独立开发者

适合用，但要管好预期。

Codex + Automations 能帮你把重复性重构工作自动化，节省大量机械劳动。但你必须接受「最后 20% 需要人工校验」这个现实。把它当成「80% 自动化 + 20% 人工兜底」的工具，而不是「全自动」的解决方案。

团队 Tech Lead

谨慎引入，先跑小规模试点。

跨天任务的上下文漂移问题在团队场景里会被放大——因为你的「关键约定」可能比个人项目复杂十倍。建议先在一个非核心模块上做试点，建立自己团队的「任务拆分 + 约定锚点」SOP，再推广。

AI 工具探索者

现在就值得上手研究。

这个方向代表了 AI 辅助工程的未来形态。即便现在还有明显局限，理解它的边界本身就是有价值的认知资产。而且随着模型迭代，这些边界会持续扩展。

---

「上下文连续性」，本质上是在测试一件事：AI 有没有资格被称为「同事」，而不只是「工具」。

工具不需要记住你说过的话。同事需要。

现阶段的 Codex + Automations，诚实地说，还卡在这两者之间——它比工具更聪明，但还没聪明到能被完全信任。它会在第 16 小时忘记你说「认证模块不要动」。就像一个刚入职的实习生，你交代的事情他认真记了，但记了 14 个小时之后，有些细节还是悄悄滑走了。

这不是在否定它的价值。这是在说：我们现在正处于 AI 协作工具从「工具」向「同事」进化的过渡期。知道它的边界在哪里，才能用好它，而不是被它坑。

---

这次测试还暴露了另一个问题：当 Codex 在 Automations 里跑了 18 小时之后，token 成本是多少？和人工重构相比，ROI 算得过来吗？ 下一篇我会把账单截图和时间成本全部摊开，做一次不留情面的性价比评估——如果你正在考虑把 AI 引入团队工作流，那篇可能比这篇更值得等。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI编程 #Codex #AI工具评测 #开发者工具 #8848AI #上下文管理 #AI工作流 #软件重构