我为什么离不开 Codex：我的多任务 AI 工作方式

我现在的很多工作，已经离不开 Codex。

这里说的“离不开”，不是遇到问题时问它一句，也不是让 AI 偶尔生成一段代码。视频里展示的是我每天真实使用的工作界面：高源外、乐知、Digital Life OS，以及其他正在建设的网站和工具，都以独立任务的方式同时放在 Codex 里推进。

这已经不再是一次问答，而是一种新的工作方式。

我说的“离不开”，不是让 AI 替我做决定

过去使用 AI，常见的方式是打开一个聊天窗口，提出问题，复制答案，再回到编辑器里继续工作。上下文一长，项目之间一切换，很多背景就要重新解释。

现在，Codex 直接进入了项目环境。它可以阅读仓库里的代码和协作规范，理解当前任务的目标，在限定范围内修改文件，并运行测试验证结果。

但这不意味着把决定权交给 AI。

我仍然要说明为什么做、做到什么程度、哪些目录不能碰、哪些流程不能破坏。改动完成后，我还要看页面、检查差异、确认测试结果，并决定是否提交和发布。Codex 承担的是理解上下文和执行工作的部分，目标、边界与最终责任仍然在我这里。

视频开始后，可以看到左侧有很多彼此独立的项目和任务。

高源外博客在进行内容建设，乐知在处理产品规划、开发和运维，Digital Life OS 有文档整理与阶段审查，其他网站也有各自的设计和实现任务。它们不是混在同一个长对话里，而是分别保留自己的项目目录、历史上下文和当前状态。

有的任务正在执行，有的等待我确认，有的已经完成并等待检查。一个项目在构建或测试时，我可以切换到另一个任务继续沟通，不需要守着同一个进度条。

多任务并行真正节省的，不只是几分钟等待时间。更重要的是，切换项目时不必每次都从头恢复背景：当前在解决什么、已经做过什么、有哪些约束，都留在对应任务里。

视频里重点展示了“高源外”博客。

这个站点不是让 AI 随便生成一个页面就结束。我先确定它的定位：这是一个长期维护的个人内容站，视频负责传播，文章负责把技术细节、实践过程和长期经验留下来；视觉上采用暖白、墨色、山青和海蓝的“山海编辑风”；工程上继续保持 Astro 静态输出，不引入没有必要的数据库和后台系统。

Codex 在这些约束下阅读项目、编写代码、整理内容，然后把结果放回真实仓库。视频中能看到项目文件、任务对话和已经运行起来的“高源外”页面，也能看到我在不同任务之间查看进度。

页面完成只是其中一步。后面还要继续检查源码和改动，通过 GitHub 保存版本，查看部署结果，并在项目监控中心确认线上状态。需求、实现、预览、版本管理、部署和监控连接起来，才是一条完整的工作链路。

这也是我越来越依赖 Codex 的原因：它不是只在某一个环节给建议，而是可以在明确授权的范围内，参与一项工作从需求落地到验证交付的全过程。

同时运行很多任务，看起来像是把工作全部交给了 AI。实际上，任务越多，边界越重要。

我会尽量让每个任务只有一个清楚的目标：写一篇文章、修复一个问题、整理一组文档，或者完成一次部署检查。任务开始前先给出项目规则；任务进行中关注风险和依赖；任务完成后再检查它真正改了什么。

视频后半段展示了代码、GitHub、部署页面、监控中心，以及任务完成提醒。这些画面表达的不是“AI 已经全自动接管项目”，而是每一项工作都进入了可追踪的流程。

任务完成提醒只是告诉我“该回来验收了”，并不代表结果天然正确。测试通过也只是必要条件之一，页面是否符合预期、内容有没有讲错、改动会不会影响现有功能，仍然需要人工判断。尤其是提交、推送和正式发布这样的动作，必须由我明确决定。

以前做项目，我的大部分注意力放在逐行操作：找文件、改代码、等待命令、来回切换窗口。现在，其中越来越多可以交给 Codex 执行。

我的工作并没有消失，而是在向更上游移动：把模糊想法变成清楚目标，把复杂工作拆成可以验收的任务，把长期规则写进项目，然后审查结果、控制风险、决定下一步。

这更像是在管理一组能够理解上下文的 AI 协作者。每个任务各自推进，但都要遵守同一套工程纪律；它们可以并行工作，却不能越过授权边界。

所以，我说自己已经离不开 Codex，并不是因为它替我按下了多少次键盘，而是因为它改变了我组织工作的方式。

我不再必须亲自守住每一个执行步骤，而是把更多精力放在真正重要的事情上：我想解决什么问题，结果应该是什么样，以及如何确保它能够长期稳定地运行下去。