作为 Codex 的首位 PMM（产品营销经理），我清楚地记得，使用它曾经意味着我必须找到一个编码项目。通常是启动一个爱好应用、写一个小脚本，或找到一些技术任务来测试产品并理解其工作原理。
那是不久前的事！
今天，我在 Codex 中开始和结束每一天。我仍然用它做与代码相关的工作，但它现在是我处理 PMM 整天做的那种混乱、跨职能工作的主要工作空间：追踪上下文、理解变化、将分散信息转化为文档、帮助人们保持对齐。
以下是我在产品营销中几乎每天使用 Codex 的三种方式。
1. 作为个人助理
第一个工作很简单：帮我跟上。
我有一个名为 Assistant 的 Codex 自动化，每小时唤醒并检查所有重要行动项可能出现的地方：Slack、Gmail、Notion、Figma 和 Google Drive。
它不只是把通知倾倒到一个列表中。我要求它将它们分类到几个桶中：
- 紧急回复
- 与每周优先级相关的事项
- 利益相关者请求
- 值得了解的 FYI
这听起来很小，但它改变了我开始一天的方式。
不是打开五个不同的工具并试图记住我应该关心什么，我可以要求 Codex 把相关信号拉到一起，并解释需要注意什么。
有用的部分是 grounded 的 first pass。Codex 给我一个跨工作发生地点的视图，我可以把判断带到真正重要的事情上。
对于产品营销人员来说，这很重要。很多 PMM 工作依赖于早期捕捉小信号：利益相关者请求发布资产、改变定位的文档评论、需要跟进的产品细节、不应该无人回答的客户问题。
Codex 帮助我在不花整个上午刷新工具的情况下注意到这些事情。
2. 跟上产品和工程
OpenAI 交付很快。总是有一个更广泛的策略在运作，但发布的时机、范围和目标总是快速变化。
这创造了一个熟悉的 PMM 问题：你需要理解实际正在构建什么，然后才能很好地定位它。
过去，这通常意味着要求 PM 或工程师带我了解工作状态。当我需要判断、权衡或上下文时，我仍然这样做。但对于 first pass，我现在可以直接找到源材料，然后进行更高带宽的对话，因为我不是从零开始。
当我与 PM 或工程师交谈时，我已经有一个粗略的地图，了解什么变了、什么似乎重要、以及我还不理解什么，使用来自 GitHub、Notion、Slack 和 Linear 的信号。
我指向 Codex 到团队正在工作的 repos、项目和频道。然后我要求它帮助我理解：
- 已经构建了什么
- 什么仍在进行中
- 最近什么变了
- 功能实际如何表现
- 实现中出现什么边缘情况或限制
然后我对照 Linear、Slack、Notion 和文档交叉检查，以理解代码周围的产品故事。
这对产品营销来说是一件大事。
好的 PMM 总是需要接近产品。他们阅读规格、参加评审、关注发布线程、向工程师提问，并拼凑什么是真实的 versus 什么仍然是愿望。Codex 让你更直接地做这项工作。
3. 交叉职能对齐
交叉职能对齐是一个花哨的说法：确保每个人都理解其他人在做什么。
在实践中，这通常意味着创建一个文档。
困难的部分是文档需要时间。当工作快速移动时，花半天时间整理状态更新或对齐备忘录是不可行的。但不写文档也有代价。人们失去上下文，决策被埋没，团队开始从稍微不同的真相版本操作。
这是我不断使用 Codex 的地方。
我要求它查看工作已经在发生的地方：Slack 线程、会议转录、Google Docs、Notion 页面、发布追踪器和我有权访问的其他源材料。
然后要求它产生一个快速对齐文档：
- 已经决定了什么
- 什么仍然开放
- 谁拥有什么
- 自上次更新以来什么变了
- 需要什么决策
- 下一个里程碑是什么
从那里，我可以编辑语气、准确性和判断。
Codex 不需要在第一次尝试时就写出完美的文档才有用。它把原材料塑造成足够快的形状，让我可以把时间花在 PMM 实际增加杠杆的部分：锐化信息、注意差距、决定什么重要、并使下一步显而易见。
最大的变化
对我来说，最大的变化是 Codex 让我更接近源头工作。
不是等待上下文为我总结，我可以要求 Codex 帮助我直接检查底层材料：repo、tracker、发布线程、会议笔记、文档评论。
这并没有消除产品营销的人性部分。如果有的话，它让它们更重要。你仍然需要知道什么时候声明太强、什么时候信息会落地很糟、什么时候团队在互相说空话、或者什么时候发布计划有明显的差距。
但 Codex 改变了你能多快到达那个点。
对于 PMM 来说，这是值得关注的地方。
Codex 不仅在你写文案时有用。它在你试图理解工作、跟上做工作的人、以及将混乱的上下文转化为团队其他成员可以使用的东西时有用。