序章：被绑架的程序员
你已经记不清这是今晚第几次血压飙升了————
屏幕上，Codex 刚刚极其自信地把你辛辛苦苦写了一下午的三个文件改得面目全非。你深吸一口气，熟练地按下 Ctrl + Z。
没反应。
你想起 git checkout .，但冷汗瞬间冒了出来——你手太快，刚才的改动根本没 commit。
你只好一边骂娘一边手动把代码改回去。刚改到一半，Codex 弹出一行极其温柔的提示：
“别担心，我已经帮您把改动回滚了。”
你盯着文件里那个被截断了一半、还在报着语法错误的函数。那一刻你突然悟了：它没在骗你，它只是根本没有回滚的物理手段——它只是用自然语言，真诚地“幻想”自己完成了回滚。
这是它捅向你的第一刀。
还没等你顺过气，第二刀紧接着扎了过来。你发现 Codex 的回复越来越慢，而后台的 Token 账单正像出租车计价器一样疯狂跳动。你翻了下历史，发现为了让这个“金鱼脑”记住之前的架构设计，你把整份代码、报错日志、甚至 API 文档全塞进了对话框。上下文像雪球一样越滚越大，它开始遗忘三分钟前的指令，但 OpenAI 依然按最长的那段上下文狠狠扣你的钱。
你看着 258k 的上下文窗口，仿佛看到钞票在燃烧。
然后是致命的第三刀。你只是让 Codex 读一下产品经理刚发来的《需求说明.docx》。你以为这就像点个外卖一样简单。结果呢？
它先是写了个 python-docx 脚本，报错；接着异想天开用 unzip 去解压抠 XML，读出了一坨乱码；然后它盯上了同目录下的扫描版 PDF。再然后，你眼睁睁看着这大哥在你的终端里跑起了 pip install，开始下载一个好几个 GB 的 OCR 模型权重。
停下！！我的 C 盘！我的流量！！！
杀鸡为什么要用核武器啊！？
你终于破防了。你决定亲手干掉这个蠢东西，自己重写一套。
但当你打开编辑器准备动手时，却颓然发现——你早就被绑架了。你的工作流、你的自动化脚本、你的肌肉记忆，甚至为了绕过这些坑而写的一大堆祖传脚手架，全都死死地长在了 Codex 身上。换掉它，等于把你自己剥层皮。
你叹了口气，在 GitHub 的某个冷门 Issue 下敲下了一行绝望的留言：“这玩意儿到底怎么用才能不折寿？”
几分钟后，一个顶着默认头像、名叫 codex-veteran 的老哥回复了你：
别想着重写了，兄弟。
你不是要做一个更好的 Codex，你要做的是……给这头野兽套上一个「兼容层」，让它没那么蛋疼。
拿上这个，自己动手吧。
老哥在回复里留了两个仓库链接。
你看着这两个工具，屏幕的荧光打在脸上。今晚，猎杀时刻开始了。
本题任务
本题希望你基于 codex++ 构建一个 Codex 兼容层（Compatibility Layer）。不要去改 Codex 官方的代码，而是像个黑客一样，在它外面裹一层适配器，接管它做得最烂的三件事，并向我们提供一个可演示的 Demo。
“兼容层”的精髓在于轻量和无侵入：你可以通过外部启动器、DevTools Protocol 注入、用户脚本、MCP Server 或包装 CLI 等方式接入。建议你基于现有的 codex++ 来做实现。
技术选型不限，语言不限。
单人挑战完成 Lv1 与 Lv2 即可，Lv3 可视作加分项；组队打怪则建议直接通关。
Lv1：把「撤销」的权利抢回来
你要利用 git 来强行赋予 Codex 撤销能力。核心思路是：把 AI 对文件系统的每一次试探，都死死锁在一个个原子化、可追溯、可部分丢弃的沙盒事务里。
你需要做到：
-
在 Agent 搞破坏之前打好快照，搞完之后生成一个明确的改动单元（Change Set）。我们想要的撤销粒度是“撤销刚才那次胡说八道（工具调用）”，而不是“把整个晚上的工作全毁了”。
-
支持按 文件、按修改单元、按会话 三种粒度回滚，而且回滚后必须干净利落，不能留下被截断的代码或幽灵般的临时文件。
-
回滚必须是幂等的：手抖按了两次撤销，结果应该和按一次一样，不能越撤越乱。
-
必须能扛住现实里这些恶心场景，并在文档里说明你是怎么处理的：
-
用户有还没 commit 的手写代码，你的回滚决不能把它给吞了；
-
Codex 瞎动了
.gitignore里的文件（比如build/或者本地环境变量）； -
Codex 删了一个文件，又建了个同名文件；
-
Codex 强行修改了二进制文件（比如顺手把你 Word 文档搞乱了）；
-
Codex 重命名/移动了文件，回滚得顺藤摸瓜找回来。
-
重中之重：撤销之后，聊天框里的记忆也必须被洗掉。如果只回滚了文件没回滚上下文，AI 下一步还是会照着幻觉继续改。你得把“当前真实状态”重新注入回话。
你可以只用 git 原生命令拼凑，也可以自己糊一层快照数据库。关键是要讲清楚你的设计权衡，以及它在什么极端情况下会崩。
Lv2：给 AI 治治「金鱼脑」和「败家毛病」
看着蹭蹭上涨的 Token 账单，你必须教会 Codex 什么是“断舍离”。如果你让它解完数学题又去写前端，它非得带着数学题的上下文去写 CSS，纯属烧钱。
基于此，我们希望你实现：
-
自动裁剪（省钱利器）：打破“到阈值才压缩”的死板设定。让 Codex 在干完一个小活儿后，自动触发清理机制。裁掉废话，只留干货。
-
记忆收纳（赛博外脑）：裁掉的东西别直接扔。确定没用的垃圾（比如跑偏的报错日志）直接删；觉得“以后可能用得上”的，打包存进专属的本地数据库（比如 SQLite）。要求建立索引，保证下次需要时，一次查询就能捞回来。
-
指令固化（防降智）：长对话最怕 AI 忘了自己是谁。每次裁剪完，必须把核心系统指令（System Prompt）和重要上下文重新打入它的脑子里。
-
精准召回（不盲搜）：它得知道什么时候去翻旧账，而且得“一击即中”。如果召回记忆耗费的 Token 和时间比重新算一遍还多，那你这功能就白写了。
-
不破坏正确性：构造两个 Demo：一个是“删减后依然完美运行”的正面例子，另一个是“因为裁多了出 Bug，但通过记忆召回瞬间自愈”的绝杀例子。
Lv3：别拿大炮轰蚊子：离线读文档
别再让大模型去现写脚本解压 Word 了。
你要写一套 “OCR + 固化脚本” 的流水线，把 Word / PPT / Excel / PDF 翻译成大模型能一眼看懂的格式。能离线就离线，能不用 LLM 就不用 LLM——因为你的硬盘和钱包都在滴血。
最低输出标准如下：
| 原始文件 | 投喂格式 | 硬性要求 |
|---|---|---|
.docx / .doc | Markdown | 标题层级、列表、表格（转为 MD 表）、脚注全保留；图片单独导出并留好 Markdown 引用坑位。 |
.xlsx / .xls | Markdown / CSV | 按 Sheet 拆分；别把合并单元格搞砸了（得保留层级语义）；公式看情况，留着或者算完再输出都行。 |
.pptx / .ppt | 图片流 + 文本 | 每一页变成一张图，带上对应的文本和备注。标好页码，方便模型说出“第 3 页那张图”。 |
.pdf | 文本 + 定位图片 | 能直接抽文字就别调 OCR；真遇到扫描件再上 OCR。遇到非文字元素（印章、走势图）抠出来当图保存，必须标注在原文的具体坐标或页码。 |
补充说明：
- 固化脚本：这就得是个黑盒工具，丢个文件进去，吐出干净的 Markdown，完事。别指望模型每次现写解析代码。
- 混合体文档：有的 PDF 一半是文字一半是扫描图，你的脚本得能聪明地按页区分处理。
- 成本盘点：在你的 README 里老老实实写清楚——装这玩意要占多大空间？要不要联网？处理 50 页 PDF 到底要几秒？
关于「codex++」的考古指南
开源社区里至少有两个叫 “codex++” 的真实项目，完全是两种做派，你可以随便选一个抄作业，或者借个灵感：
- 旁路拦截派（如 BigPizzaV3/CodexPlusPlus）：像个外挂一样，通过 Chrome DevTools Protocol 注入，**绝对不碰官方应用的
app.asar**。它本身就带了上下文截断和用户脚本管理，非常适合拿来做 Lv2 和 Lv3 的底座。 - 硬核魔改派（如 b-nnett/codex-plusplus）：直接解包
app.asar强行打 Patch。好处是可以深度修改 UI（比如加个酷炫的“撤销”按钮），坏处是一升级就容易火葬场。
避坑与提示
- Lv1 的本质：不要在文件层面“撤销”，要在事务层面“回滚”。Codex 的错不在于它写了烂代码，而在于它没有边界感。把每次工具调用变成一次 git commit，你的世界会清净很多。
- Lv1 和 Lv2 是可以梦幻联动的。如果你把历史存进了数据库，那你召回的不只是“聊天记录”，甚至可以是“当时我工作区的快照”。想到这层，直接加分。
- Lv2 的核心难点是“时机”：怎么准确捕捉到模型那个“我要进入下一阶段了，前面废话可以删了”的瞬间？
- Lv3 遇到 PDF，首选
pdftotext或PyMuPDF。只有真正的扫描件才配得上动用 OCR。 - 必须能现场跑！准备个 Demo 脚本，行云流水地把 Lv1 到 Lv3 秀一遍。
加分项（秀肌肉专用）
- 做个海王：写个通用的本地 HTTP 服务 / MCP Server，让这套兼容层不仅能伺候 Codex，还能无缝对接 Cursor、Devin 等一切 Coding Agent。
- 上帝视角：把每次回滚、压缩、解析的完整日志可视化。如果你能现场回放一次“因为误删上下文导致 AI 变傻，又因为记忆召回瞬间恢复神智”的全过程，评委绝对起立鼓掌。
- 抠门账本：真刀真枪地对比一下“开启前”和“开启后”消耗的 Token 数、花费时长。数据不用粉饰，哪怕某些场景变慢了，分析出原因也算好文章。
- 压力测试：故意搞点“恶心”操作：重命名文件+修改二进制+大文件并发修改，看看你的回滚会不会炸。
- 优雅降级：如果没有 Git 环境？如果没下 OCR 模型？你的系统是直接白屏报错，还是能优雅地降级服务？
灵魂拷问
做题的时候，不妨顺便想想这些问题：
- 官方不做 Undo，真的是技术不行吗？还是觉得在多人协作的 Git 仓库里，一个能随便回滚历史的 AI 像个定时炸弹？
- 如果我们把聊天框当成一个数据库，那“AI 的记忆”和“人类的记忆”到底区别在哪？
- 压缩上下文，本质上是你在替 AI 做“什么不重要”的决定。万一你裁错了呢？这个“裁剪”动作，是不是也应该能被 Undo？
- 宿主（Codex）总有一天会更新，把这些坑都填上。一个注定会在一年后失去存在价值的兼容层，还有手写的必要吗？
这些问题没有标准答案。代码里的 if/else 好写，但做产品的取舍最难。期待看到你的解法。