# Every 团队使用 Codex 的深度实践

- 来源：meng shao (@shao__meng)
- 发布时间：2026-07-03 08:37
- AIHOT 分数：64
- AIHOT 链接：https://aihot.virxact.com/items/cmr47jts001b6sl3g08xlxrx9
- 原文链接：https://x.com/shao__meng/status/2072842101067481210

## AI 摘要

Five team members with different backgrounds (Natalia, Dan, Katie, Austin, Kieran) used Codex in distinct workflows. Common patterns emerged: context matters more than prompts; let Codex design its own system; delegate repetitive tasks to background threads; and build audit/feedback loops. Their setups range from outcome-first (Austin) to long-running router threads (Dan) to portable context folders (Kieran). The article recommends picking one style that fits your work rather than overthinking.

## 正文

Every 团队使用 Codex 的深度实践
https://every.to/context-window/codex-in-practice?utm_source=X

# 背景不同的五人、五种不同的工作流

1 Natalia：非技术构建者的"低摩擦 Claude Code"
· 痛点：她曾在 Claude Code 中精心维护文件夹结构，但在 Codex 里无需自己搭建。
· 用法：每天打开当天优先的项目线程，让 Codex 自行决定架构与文件组织。
· 关键场景：用 CRM（Attio）管理客户关系时，她给 Codex 访问邮箱、会议记录和销售管线逻辑，让它在夜间自动 enrich 数百条客户记录--原本需要数周的手工工作。
· 个人应用：为父亲的多护士护理流程建立"家庭操作系统"，把分散的医疗预约、随访协议、家属信息整合到一个中心位置。

启示：Codex 对非技术用户的核心价值是降低"系统搭建"的认知负担，把"架构能力"外包给模型。

2 Dan：长线程 + 内置浏览器 + 路由线程
· 原则：让 Codex 获得完成某任务所需的全部上下文。
· 长线程（long-running threads）：为邮件处理、Slack/会议摘要、招聘等重复任务建立不重置的线程，保留完整历史。
· 内置浏览器：Codex 可在应用内浏览网页、点击交互，无需用户复制粘贴上下文。这对调试 UI 和知识工作都有效。
· 路由线程（router thread）：他做了一个小工具 Mailroom，给 Codex 一个专属邮箱；路由线程每几分钟检查收件箱，把请求分发到对应的专业线程（合同→法律线程，权限申请→内部运营线程）。

启示：这是目前最成熟的"多智能体"个人工作流雏形--通过线程分工实现规模化任务处理。

3 Katie：本地"上下文文件夹"系统
· 背景：Claude Code 重度用户，迁移到 Codex 后让模型采访自己，自动构建更适合 agent 的文件系统。
· Katie Context 文件夹包含：
· AGENTS.md：目录与使用说明
· identity：角色与项目类型
· preferences：输出格式偏好，例如需要可分享时创建 Proof 文档
· rules："不要这样做"清单
· project map：各工作领域对应的文件、指令、流程
· Voice.md：写作风格、语言、语气指南
· 自动化创意库：她为专栏 Working Overtime 建立"idea farm"，让 Codex 监控 Slack 频道，按她的风格与选题标准评分并添加编辑备注。

启示：对于需要稳定输出质量的知识工作者，显式化个人偏好与风格比单纯依赖模型记忆更可靠。

4 Austin：结果导向的轻量模式
· 风格：自认不擅长组织，因此避免复杂结构。
· 用法：只给 Codex 一个结果目标，连接相关信息源，让它直接开工。
· 例子：为活动制作后续内容包时，他丢入 transcript、聊天记录、录音、Monologue 语音备忘录，让 Codex 去 Notion 和 Slack 搜索、建立 GitHub 资源库、起草邮件。
· 迭代机制：如果初稿不好，他让 Codex 基于既有机构上下文自我审计，找出哪里出错并改进；遇到增长工作问题时，让 Codex 审计 Every GrowthOS 仓库，删除过时指令。

启示：反馈-审计-精简的循环，比一次完美提示更重要。适合不愿花精力维护系统的人。

5 Kieran：可移植的跨 Agent 上下文系统
· 定位：Codex 只是他个人 AI 系统中的一个工具，核心资产是一个跨设备同步的上下文文件夹。
· 输入源：会议记录、Monologue 语音笔记、日记、Limitless 吊坠录音。
· 自动处理：新素材进入后，自动工作流会分类、提取关键信息并写入对应文件。
· 记忆层：生成日/周/月摘要，成为所有 agent 可读的可复用记忆。
· Codex 的角色：当需要跨工具快速搜索和执行时调用，例如收集 Cora 早期申请者的联系方式、补全缺失邮箱、建表、邀请进 Slack、发欢迎邮件。

启示：上下文资产的可移植性比绑定单一 agent 更重要。Codex 是执行层，而非记忆中枢。

# 跨案例的共性模式
从五个人的实践中可以提炼出四条普适原则：

1. 上下文比提示更重要
无论是长线程、文件夹系统，还是可移植知识库，成功的关键都在于把 Codex 接入邮件、会议、Slack、CRM、浏览器等真实信息源。

2. 让 Codex 自己设计系统
多数人并非手动搭建文件夹结构，而是让 Codex 通过"采访我"来生成适合自己的架构。这降低了启动门槛。

3. 把重复工作委托为"后台任务"
Natalia 的 CRM enrich、Kieran 的申请者处理、Dan 的邮件路由，共同点是：把低判断、高耗时的任务变成异步执行。

4. 建立审计与反馈循环
Austin 的"审计哪里出错"和 Katie 的"规则文件"都说明，Codex 不是一次设定就结束，需要持续根据错误更新约束。

# 实用建议：如何开始
文章本身的结论最值得参考：不要过度思考，先选一个风格切入。

· 如果你不想搭建系统 → 用 Austin 的结果导向法
· 如果你写作为主、重视风格一致性 → 用 Katie 的上下文文件夹法
· 如果你处理大量重复性行政/运营任务 → 用 Kieran 的可移植上下文法
· 如果你想让 Codex 像员工一样管理多线程工作 → 用 Dan 的长线程 + 路由法
· 如果你是非技术背景、希望降低工具学习成本 → 用 Natalia 的低摩擦 Claude Code 法

### 引用推文

> Every 📧：Codex works best when the setup matches how you work. Long-running threads, local context folders, outcome-first prompts - our team's setups look nothing alike....