🏗️ 工作的“外挂”化
最近研究了一个叫 oh-my-codex (OMX) 的项目。名字取得很有年代感，致敬了 oh-my-zsh，暗示着它想成为每个极客终端里不可或缺的“血液”。
但剥开这层情怀的外壳，你会发现一个深刻的逻辑尴尬：我们正在为了让 AI 正常工作，而不得不给它焊上一套沉重的、工程化到极致的底盘。
1.1 逻辑的补偿机制
OMX 并不是一个简单的 Prompt 集合。它动用了 Rust 来处理底层性能，利用 tmux 来调度多智能体协作，甚至还在项目里建了个 .omx/ 文件夹来强行充当 AI 的“长期记忆”。
这是一种典型的**“工作流通胀（Workflow Inflation）”**。AI 本身的逻辑是不稳定的、碎片化的，于是人类工程师不得不开发出一套比业务逻辑还要复杂的“约束系统”，来防止 AI 在执行任务时像脱缰的野马一样乱跑。
1.2 $符号的诱惑
OMX 将复杂的指令封装成了以 $ 开头的关键字，比如 $deep-interview（需求深挖）或 $ralph（循环执行）。这让开发者有一种在“编写 AI 脚本”的错觉。
但这种抽象带来的快感是有代价的。当你需要维护一套包含计划、日志、运行时状态的 .omx/ 数据库时，你不再是在写代码，你是在管理一个由硅基生命构成的、极其脆弱的分布式系统。
⚙️ 边缘观测者的冷思考
OMX 是严肃的，它的工程质量很高，甚至考虑到了不同系统的性能抖动。但这正是最讽刺的一点：AI 的普及本应降低门槛，结果却催生出了更高阶的、针对 AI 运行时的“运维工程”。
当我们需要用一个复杂的框架去“驾驭”另一个号称能替代人类的工具时，这种技术嵌套本身就带有一种荒诞的幽灵感。
OMX 解决了 Codex 的痛点吗？是的，它给这个赤裸的 AI 穿上了一套精密的铠甲。但这套铠甲是如此沉重，以至于只有那些最顶尖的极客，才愿意在享受 AI 生产力的同时，去承担这套系统的“逻辑折旧”。
“The smarter the AI gets, the more engineering it needs to stay on the rails. We are not automating programming; we are automating the management of chaos.”
逻辑溯源：oh-my-codex