Every 团队五种 Codex 工作流深度实践

Every 团队使用 Codex 的深度实践 https://t.co/OEoTVUfgAf # 背景不同的五人、五种不同的工作流 ① Natalia：非技术构建者的“低摩擦 Claude Cod...

Every 团队使用 Codex 的深度实践 every.to/context-window… # 背景不同的五人、五种不同的工作流 ① Natalia：非技术构建者的“低摩擦 Claude Code” · 痛点：她曾在 Claude Code 中精心维护文件夹结构，但在 Codex 里无需自己搭建。 · 用法：每天打开当天优先的项目线程，让 Codex 自行决定架构与文件组织。 · 关键场景：用 CRM（Attio）管理客户关系时，她给 Codex 访问邮箱、会议记录和销售管线逻辑，让它在夜间自动 enrich 数百条客户记录——原本需要数周的手工工作。 · 个人应用：为父亲的多护士护理流程建立“家庭操作系统”，把分散的医疗预约、随访协议、家属信息整合到一个中心位置。 启示：Codex 对非技术用户的核心价值是降低“系统搭建”的认知负担，把“架构能力”外包给模型。 ② Dan：长线程 + 内置浏览器 + 路由线程 · 原则：让 Codex 获得完成某任务所需的全部上下文。 · 长线程（long-running threads）：为邮件处理、Slack/会议摘要、招聘等重复任务建立不重置的线程，保留完整历史。 · 内置浏览器：Codex 可在应用内浏览网页、点击交互，无需用户复制粘贴上下文。这对调试 UI 和知识工作都有效。 · 路由线程（router thread）：他做了一个小工具 Mailroom，给 Codex 一个专属邮箱；路由线程每几分钟检查收件箱，把请求分发到对应的专业线程（合同→法律线程，权限申请→内部运营线程）。 启示：这是目前最成熟的“多智能体”个人工作流雏形——通过线程分工实现规模化任务处理。 ③ Katie：本地“上下文文件夹”系统 · 背景：Claude Code 重度用户，迁移到 Codex 后让模型采访自己，自动构建更适合 agent 的文件系统。 · Katie Context 文件夹包含： · AGENTS.md：目录与使用说明 · identity：角色与项目类型 · preferences：输出格式偏好，例如需要可分享时创建 Proof 文档 · rules：“不要这样做”清单 · project map：各工作领域对应的文件、指令、流程 · Voice.md：写作风格、语言、语气指南 · 自动化创意库：她为专栏 Working Overtime 建立“idea farm”，让 Codex 监控 Slack 频道，按她的风格与选题标准评分并添加编辑备注。 启示：对于需要稳定输出质量的知识工作者，显式化个人偏好与风格比单纯依赖模型记忆更可靠。 ④ Austin：结果导向的轻量模式 · 风格：自认不擅长组织，因此避免复杂结构。 · 用法：只给 Codex 一个结果目标，连接相关信息源，让它直接开工。 · 例子：为活动制作后续内容包时，他丢入 transcript、聊天记录、录音、Monologue 语音备忘录，让 Codex 去 Notion 和 Slack 搜索、建立 GitHub 资源库、起草邮件。 · 迭代机制：如果初稿不好，他让 Codex 基于既有机构上下文自我审计，找出哪里出错并改进；遇到增长工作问题时，让 Codex 审计 Every GrowthOS 仓库，删除过时指令。 启示：反馈-审计-精简的循环，比一次完美提示更重要。适合不愿花精力维护系统的人。 ⑤ 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 📧 @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. ( @tedescau refuses to search for specific files, for example) 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 2 👀 384 📊 2 ⚡