OpenAI Codex lead on the new shape of product work | Andrew Ambrosino

• 产品流程被"反转"了。 过去的整套流程（research → 文档 → 原型 → 实现）都建立在"实现很贵、只能造一次"的假设上，所以要在动手前把风险全部排除。如今实现近乎免费，OpenAI 内部一个急需的功能可能有"90 个不协调的团队在并行实现"。瓶颈不再是"造不造得出"，而是 Andrew 所说的——"dare I say taste"（容我说一句，是品味）：从 90 个尝试里挑出好的、判断该把什么折叠进什么、用什么形式呈现。

• Codex 已是 OpenAI 的"默认动作"。 全公司 90% 的人用 Codex——不是 90% 的工程师，是 90% 的整个公司；内部近 100% 员工每周使用。自 1 月以来使用量增长 6 倍，每周活跃用户已超 500 万。它从一个开发者工具，长成了营销、法务、财务、科学团队都在用的通用知识工作工具。

• "设计流程已死"半真半假。 流程的"具体形式"（用户研究→发散→收敛那套学院派步骤）确实死了，但流程的"定位坐标"——"我们现在处于探索的哪个阶段"——比以往任何时候都重要。危险在于：一个本是早期探索的原型，因为太精致 (production ready) 而被误当成"可以发布了"。

• 为"未来的模型"造产品，而不是今天的。 Andrew 笃定：2 月发布的 Codex 应用，如果在 11 月以完全相同的形态发布，会在市场上彻底失败——唯一的变量是这几个月里模型变强了。所以一个功能可能要"发布 6 次"才成；operator→Atlas→Codex 本质是同一个功能，换上不同智能水平后结果天差地别。早期 Codex "太 AGI 化 (too agi-pilled)"反而输给了更贴合当时模型水平的 Cloud Code（Claude Code）。

• 角色在坍缩，但学科不该被消灭。 "你的角色 = 你时间花在哪的平均值"：本周大部分时间在做 PM 的事，你这周就是 PM。但 Andrew 明确反对"取消产品岗、人人都是 builder"——那会把产品学科几十年沉淀的真实最佳实践一并丢掉。

• 贯穿全场的主线： 当实现的成本塌缩到接近零，价值就整体性地从"执行"迁移到"判断"——该做什么 (taste)、什么时候做（为未来模型下注）、做成什么样（选对媒介、守住抽象层）。Andrew 的每一个论断，无论谈设计、谈团队、谈规划还是谈他自己怎么用 Codex，都是在回答同一个问题：在一个"什么都造得出"的世界里，人的判断力如何重新定价。

核心要点：过去整套产品流程都为"实现昂贵、只能造一次"而设计——前期用文档、研究、原型把风险排干净。如今实现近乎免费，流程被整个倒过来：先大量造，再用判断力做策展 (curation)。

• 旧世界即便走出瀑布流，骨子里仍是"实现很贵"：所以要靠文档、研究、原型在前期排除一切风险，因为"原型和设计更便宜"是当时的隐含假设。
• 新世界里"你给人无限的 token"，OpenAI 人人都极具能动性 (agentic)、点子多，于是"人人都在造一切"。一个急需的功能，Andrew 估计"有 90 个不同的探索、90 个不协调的团队在并行实现和试"。
• 所以真正昂贵的不再是实现，而是策展过程：这 90 个尝试里哪些是好的？该把什么折叠进其他方面？这个 toggle 里该有几段？该怎么定框架、要不要并进另一个功能？

"It's backwards. The implementation is actually not the expensive part anymore. It's dare I say taste." —— Andrew

核心要点：Andrew 明确不认同"PRD 已死、原型当道"。当任何媒介的实现都变便宜，关键反而是为你要表达的"那个点"选对格式——求产品清晰度就写文档，要把东西塞到别人手里压测交互就做原型。

• 很多产品负责人喊"PRD 死了、原型上位"，Andrew "完全不信"。对从没写过代码的人，直接跳到原型很诱人；但对工程师，写一堆"不值得读的文档"同样诱人。
• 判断标准是"点"与"媒介"的匹配：如果要表达的是某个模糊领域的产品清晰度，那答案可能就是一份文档；如果是想让人上手试、压测某个交互模式，那就是原型。
• Lenny 引入"primal mark（原初一笔）"的概念：画家落下的第一笔会成为之后一切回应的基准；有时原型恰恰是错误的"第一笔"——你会开始对着这个原型反应，而不是对着更大的想法反应。
• 旧世界里"媒介本身就编码了大量信号"：你看到一个像生产环境的界面，就意味着流程已到后期、风险已排除、设计已审过、商业目标成立。如今这些信号被"离婚"了——精致不再等于成熟。

"If implementation is abundant, then it's really important to pick the right format for the point you're trying to make." —— Andrew

核心要点：taste 被严重窄化为"美学"。Andrew 拆出多层：美学只是其一，更重要的是系统思维（这东西如何嵌入系统）、更宽的上下文（我们要去哪、这属于什么主题）、以及"如果什么都能造，到底该造什么"的根本判断。

• Andrew 引一条推文（出自 Linear 产品负责人）：人们过度强调 taste 的美学部分，并以 Paul Graham 为例——"他显然很有 taste，却穿着 cargo shorts"，借此说明 taste 远不止外观。
• taste 的层次：①美学层（比如这个交互动画"太snappy"，不匹配它想传达的语义）；②系统思维层（它如何嵌进系统）；③主题/方向层（我们往哪走、这属于哪个 theme）；④呈现层（如何把信息讲清楚）。
• Andrew 自承"可能在美学细节上花了太多精力"，但他认为真正的 taste 问题是："如果我们什么都能造，这东西到底该是什么、目标是什么、怎么抵达。"

核心要点：Andrew 给出"为什么前沿模型在设计上还很弱"的清单——既有会消失的实际原因，也有更棘手的深层原因。最难的是"设计-代码之间的抽象层"。

• 实际原因（会消失）： 设计比软件更难"评分"——代码能不能编译、做没做对，很好判定；而"什么是好设计"需要把人的品味做进反馈回路，更繁琐。另外，各实验室历史上优先investing于"能加速 AI 研究"的能力，写对代码能加速研究，设计不在那个飞轮里。
• 深层原因（难啃）：
• 文化与新颖性：去年"每个新网站都是 Linear 官网的翻版"。如果模型每次都输出 Linear 官网，那不是设计的胜利——设计比软件工程更看重新颖性，而工程恰恰希望尽量复用已知模式。
• 抽象层：模型即便会画好看的界面，设计与代码之间还有一层抽象。比如公司明天要 rebrand，浅层版本是"逐个更新 263 个组件"，深层版本是理解"这两个看起来不同的东西，其实都属于同一种列表、同一种样式、向用户传达同一种交互模式"——这一层"用当前技术还有点够不着"。

"If I have a model that outputs Linear's website every time, that's not the challenge here." —— Andrew

核心要点：Andrew 与 Claude Code 设计负责人 Jenny 大体同意"设计流程已死"，但他强调死的是那套学院派的具体步骤，而"我们现在处于流程哪个阶段"的判断比以往更重要——否则会把早期探索误当成可发布的成品。

• Andrew 坦言他在 AI 之前就不喜欢"正统设计流程"。他讲了个背景：多年前招设计师时，业内有篇尖刻文章批评"case study factory"——设计师被教育把"流程"置于一切结果之上，仿佛只要走完用户研究→发散→收敛，东西就一定好、一定有影响力，哪怕没人用。
• 这套流程的前提同样是"实现昂贵、只能造一次"，所以必须在动手前穷尽问题空间和解空间。Figma、Origami 等工具把交互原型提前进流程，是真实的进步；但现在你能把"全部实现"都提前进流程，错配就出现了。
• 危险场景：一个高度精致的原型看起来"可以出门了"，公司里足够多的人看到就问"能不能现在就发？"——但其实你正处在早期设计阶段，只是没人明说。
• "baby 版产品"成了新工具：很多公司有"baby cursor / baby codex"——一个大幅简化、近似生产应用全部交互的代码库，因此能更快地 vibe code 试验"如果侧边栏这样、如果这里来个群聊会怎样"。

"To say the design process is dead, I feel like it's both true and false." —— Andrew

核心要点：Codex 团队的角色坍缩比公司其他部门更明显，因为这是给工程师做的技术产品——设计师"会说工程师的话"，PM 会写代码。Andrew 用"平均值"来定义角色：把一个人做的所有事平均起来，他的点落在哪，他就是什么。

• 关于"存在主义式的角色消失"，Andrew 说外界写了很多，但他们没看到那种极端坍缩；Codex org 的坍缩确实比别处多——因为产品本身技术性强，设计师、PM 都能讲技术、能写代码（同事 Alexander 有 CS 硕士，"我可没有 CS 硕士"）。
• 新的描述方式：人不再由"设计止于哪、工程始于哪"的栅栏定义，而由"他们工作的平均位置"定义。把设计团队某人做的所有事平均一下，有不少写代码、有不少产品工作，但平均点"在设计这边"。
• 这套生长自 dogfooding：团队有种执念，"哪怕 app 不是最好的工具，也尽量在 app 里做尽量多的事，好让它变成最好的工具"——"我们常常不去改进自己的流程，好让产品变得更好用"，这是个"深感别扭"的处境。
• "member of technical staff"称谓：Andrew 认为可能源自 Xerox（他实习的第一家公司也这么叫），是研究型公司的传统，如今更常见。

"Your role is the average of what you spend your time on. If most of your work is PM work, then okay, you're a PM for now." —— Lenny 转述 Andrew 的观点

核心要点：Andrew 对"取消产品岗、人人都是 builder"明确反对。消灭角色的危险在于，它会顺手消灭"这是一门有可知最佳实践的专业"这一事实。栅栏式的"这不是你的赛道"该消失，但技能门槛不该被否认。

• 他听过不少公司说"我们要取消产品岗，所有人都做 builder"——"我认为这是个糟糕的主意"。结果是：产品这门有真实最佳实践、真实试错积累的学科，被当成"我写了点代码"就抛弃了。
• 平衡点：不是所有人都能在广度和深度上做所有事（"这就是为什么经理不会消失"）。每个学科都有技能成分——很多工程师没意识到"别的角色不是在瞎 vibe"。
• 他的类比："你会用 Excel，但你不能因此就上财务团队。"
• 好消息是切换角色、学最佳实践、不把"会不会用某个具体工具"等同于"能不能胜任"都变容易了。Andrew 自述："我曾很久觉得自己不该当工程师，因为我不在乎汇编语言、不想背 TypeScript 语法"——而这种"会不会用这个工具 = 擅不擅长这个角色"的 gatekeeping 正在瓦解。

"Yes, you can use Excel, but you cannot work on the finance team." —— Andrew

核心要点：Codex/桌面团队是两位数工程师、约其一半的设计、少数产品，以 IC 为主、团队可以很大。产品工作像"区域联防"：两个产品的人贴得太近往往是坏信号，要主动拉开间距、补满公司级的覆盖。

• 团队画像：两位数工程师，设计约其一半，少数产品人（"产品更像是自己的一种防守站位"）。共同点是高能动性 + 高 taste，很多是前创始人、或在大公司做过"创始人形状的事"的人。OpenAI 让团队长得很大、以 IC 为主，"不是说没有管理，而是团队相当大"。
• "zone defense"：如果两个产品的人贴得太近，通常不是好信号。在这个充满混乱、点子满天飞的新世界里，自上而下的年度规划行不通，需要"taste makers"从源头引导产品该是什么。
• 做法是像"力导向布局"一样找空隙：谁最擅长什么、彼此拉开空间以做到全覆盖，再补空位。同时要招"有产品思维的工程师"，避免"一堆人写一堆代码、还得整个团队 review 产品连贯性"。

"If two product people are working too closely, that's often not a good signal." —— Andrew

核心要点：当下（及新世界里）最值钱的人，是能把一个想法从 idea 一路带到 done、且有 taste 知道"这很棒"、执着于把它打磨到位的人。IC 与管理的边界也消失了——人人现在都"两者皆是"。

• Lenny 总结这是他反复从从业者口中听到的主线：最有价值的是"高能动性、高 taste、能 shepherd 全程"的人。Andrew："对，这就是当下的核心。"
• IC vs 管理：不是管理消失、也不是人人变 IC，而是"人人现在都两者皆是"。IC 不再逐字敲代码，而是在管理——管理 agents、管理正在发生的工作；团队经理也在做同样的事，只是粒度不同。
• 他招人看"对学科的掌控力 + taste"：因为"你会有无限的 token，不能就这么产出 slop"，必须能在无限内容里判断什么是信号、什么是噪音。

"You're going to have unlimited tokens... you need to be able to determine what's signal, what's noise, in a world of just infinite content." —— Andrew

核心要点：Andrew 说团队在规划上"不搞任何革命性的东西"。基本原则是：时间越近越需要细节；不是不为 9 个月后规划，而是那必须保持很模糊——任何加给 9 个月计划的精度都是"虚假精度 (false precision)"，只会浪费时间。

• 人们"总是因为这个对我很不满"，因为东西在不断发布、不断变。Andrew 区分：研究侧不同（他不替研究发言），但应用/产品侧，"11 月能规划的，到 12 月也许还成立，但根本不是后来真实发生的事"。
• 规划的关键输入是"我们认为模型在什么时间线上能做到什么"。他在上一家公司就看到这个转变：一旦开始用模型驱动功能，传统产品流程就失效了。
• 替代做法：列出未来一两年所有感兴趣做的事 → 全部做原型 → 判断哪些现在就 ready → 其余的"放着发酵"，每次模型有新跃迁就把那东西换上新模型再试一次。因为"功能好不好，取决于模型够不够聪明，而不是功能的形状"。

"Any amount of precision that you add to a 9-month plan right now is false precision." —— Andrew

核心要点：Andrew 最有冲击力的判断之一——2 月发布的 Codex 应用，若以完全相同的形态在 11 月发布，会彻底失败；唯一变量是这几个月模型变强了。因此要为未来的模型造产品，一个功能可能要"发布 6 次"，形态甚至完全不变。

• "我非常确信：我们 2 月发布的 Codex 应用，如果在 11 月就 ready，会在市场上绝对失败"——产品形状一模一样，仅几个月的时机差，结果完全不同。
• 不要顽固地认为"这不 work，所以是个坏功能"——也许只是还没到时候。线索：operator (ChatGPT) → Atlas agent → Codex in-app browser，本质是同一个功能，但用不同智能水平重新发布，结果天差地别。
• 早期教训："我们当时太 AGI 化了 (too agi-pilled)"：最初的 Codex 是 codex web，你给模型一个任务，它跑去做完回来——听着不激进，问题是它没把任务做好。同期 Cloud Code（Claude Code）完全本地、不假装那么"AGI"，会问你问题、会停下来等你、你没法把人生全权委托给它——反而 work 得好得多，因为那才贴合当时模型所在的位置。

"The only difference was the models between November and February." —— Andrew

核心要点：被问到"最前沿的团队怎么干活"，Andrew 说"loop 已经是上周的事了"。真正的新问题不再是"多少代码是 AI 写的"（答案已是 100%），而是"监督 vs 非监督"。一个普遍痛点：模型只会增加复杂度，不擅长删代码。

• "多少产品是 AI 写的"用去年的标尺看已经没意义——"现在 100% 的产品都是 AI 写的代码"。新问题是：写的代码是监督的还是非监督的？这是完全不同的事。他乐见 goalpost 移动，因为那意味着在进步。
• 大量探索集中在"自主开发的软件"、"harness engineering"——比如"如果半夜进来给代码库做垃圾回收 (garbage collection) 清理一下会怎样"。
• 痛点直球喊话："如果有任何公司的研究团队在听，请让模型更擅长删代码 (please make the models better at deleting code)。"模型总是增加复杂度，这在把开发完全交给 autopilot 时会变成问题——人侧和代码库侧都是。
• 还没到"设个 loop 就让它改进 app、自己听 Twitter/Slack/email"的地步，"但我们在努力让它发生"。被问到会不会到"win the market / 给我赚十亿"那天，Andrew："我不知道，老兄……我不做'永远/绝不'这种生意。"

"If research is listening at any company, please make the models better at deleting code." —— Andrew

核心要点：Andrew 把对 Codex 的个人用法刻意对齐到"自己当下要解决的问题"。最典型的是定时任务生成每日简报——从他所在的 3000 个 Slack 频道里筛出需要他注意的事，并能在运行后用自然语言反复纠偏。

• 他刻意让自己的用法跟随"我的工作变成了什么"：早期目标是"让 Codex 好到能用它自己来开发 Codex"，于是有了超快的个人 dogfooding 回路；后来角色变成做产品发现、找出谁在做什么、纠正跑偏的，用法也随之变化。
• 每日简报：早上起来看一份 brief，覆盖他所在 3000 个 Slack 频道里哪些事需要他关注；他可以回一句"给我五个问题，我来回答"。
• 设置方式（仍在 discovery 阶段）：做一个 automation / 定时任务，告诉它"我过哪些 Slack 频道、我在乎什么、哪些最重要"；前几次跑可能要纠偏——而这个 app 的好处是不必去改指令文件，可以直接说"下次跑时请改关注这个、弱化那条 workstream、上次漏了某事下次注意"，它就会更新通知你的方式。
• 5 月前后有一组发布，给 Codex 引入了 in-app browser、computer use 和 artifact 创建——那是"Codex for almost everyone"的发布，也是他第一次做"五个协调发布"：用一个 notion doc 自动从各 Slack 频道、PR 收集更新、更新状态追踪器，"当时我觉得自己站在如何管理产品发布的最前沿"。

"I don't have to find out how to edit the instructions. I can just be like, hey, next time this runs, can you please worry about this instead." —— Andrew

核心要点：每个人都在搭自己的个人系统，用法千差万别；当某些主题反复出现，团队就把它升格为 app 的一等公民。核心判断是：什么该成为产品原语 (primitive)，什么只是"你怎么做你的工作"，不该塞进产品。

• 大量个人工作流"有的就是会 click"。你问这儿每个人怎么用，答案都不同；当某些 theme 浮现，"我们就说：这该成为 app 上的一等体验，把大家都在搭的东西直接做好"。
• memory 就处在这种形状：很多人（包括其他公司的人）会说"我搭了个 obsidian / notion 区，教它怎么建我的'记忆宫殿 (mind palace)'"——但 Andrew 认为"不该让你非得这么做，应该有个 memory 功能替你完成"，因为这够通用。
• 反过来，有些是"你这份工作的流程"，那种该你自己搭，不必进产品。团队"一直在淘洗：什么对个人 work、什么该进产品、什么该成为 primitive、什么不该"。

核心要点：Codex 在"浏览器形状的活"上试过很多形态（operator、agent mode、Atlas、in-app browser、连接 Chrome 的扩展），学到很多。最难的问题是浏览器该是"只给 agent 用"还是"想让你拿它当主浏览器用"——两者权衡巨大，还牵出键盘快捷键映射等大量"无聊但棘手"的问题。

• 形态史：最初 app 是 Electron，in-app browser 比较 janky，定位是"开发用的、测前端用的开发者工具，不是别的"；后来切到驱动过 Atlas 浏览器的"owl 技术栈"，于是有了多标签、企业级安全（能登录你所有网站）。
• 核心两难：这个浏览器是"只给 agent 用"（你自己用 Chrome，让桌面 app 时打开一个它能快速操控、没有 Playwright 延迟的浏览器），还是"想让你把这个 app 当成什么都干的浏览器用"？后者牵出大量无聊但棘手的问题——比如键盘快捷键到底映射到 VS Code、Chrome、还是 Linear？
• Andrew 自述的杀手级个人案例：他用 Codex 做了个过滤垃圾冷邮件的小工具——每封邮件进来就判断是不是没人理的冷推销、打标签、归类。配置时要进 Google Cloud Console 配一堆 pub/sub API 和触发器，"那界面又烦又慢"。于是他说"要不你来做？"——结果第一次亲眼看到 computer use："它直接接管我的电脑、开始点，自己把它搞定了。"
• 这正呼应了"为未来模型造产品 + 更有野心"的主线：很多功能起步都是"产品不是为它设计的，但这是个能写代码的空白 chatbot，所以它什么都能做"——剩下的问题只是"哪些是值得它做的有用的事"。

"It just takes over my computer and starts going there. It figures it out. It's crazy just to watch it doing its thing." —— Andrew

核心要点：内部一个意外发现定下了方向——当公司把营销、法务、财务等非工程团队放到为他们专设的其他界面上时，没人愿意离开 Codex。于是 Codex 的定位变成"home base"：你在这里开始工作、结束工作、自动化工作，它再去调用你需要的任何工具。

• 起点：1-2 月内部 dogfood 时，工程和研究侧已收敛出清晰的内部 PMF，但同时营销、comms、财务、法务、几乎每个学科的人也在用 Codex——哪怕它对这些人"积极地不友好"（给他们看代码、申请运行 rg）。
• 于是公司想"把 Codex 的能力加到 ChatGPT 桌面 app、Atlas 浏览器等其他界面上，做成更通用的知识工作工具"。结果出现"最烦人的问题"：没人愿意为那些号称专为其他人群准备的 app 离开 Codex。
• 教训：开发者工具 vs 通用知识工作工具不是非此即彼。做 Excel 工作的人不想看到 git 仓库信息（"我们知道"），但能从他们做的事里判断他们做哪类工作，从而"从简单起步，按需把产品长复杂"。
• "super app"梗：有人管它叫 super app，"我真希望他们没说，因为现在我得天天听 super app"。Andrew 更愿意说它是个很好的"home base"：有些事全在 app 里做，有些事 app 替你打开别的 app 去做——比如 app 直接对接桌面版 Microsoft Excel 的 add-in（内置的简易表格编辑器不足以满足"为筹数十亿美元做财务建模"的需求），做完你就能关掉 Excel。

"Nobody would leave the Codex app for the apps that were allegedly for these other personas." —— Andrew

核心要点：Andrew 用 Brent 剪视频的故事，引出 Codex 与外部工具协作的两个几乎互逆的模型——一是 Codex 无缝调用你已在用的专用工具（连接器/computer use/扩展），二是把你的 web app 打开进 Codex 让它"加料"（Dan Shipper 的设想）。两者在同时大力推进。

• 完整故事：内部 DX 摄像 Brent 被分配剪辑 Codex 首发视频，他纯粹出于好奇"Codex 能不能剪视频"就开始用。Codex 不是视频编辑器、没有那套 UI，但它理解到 Brent 用 Premiere Pro，能通过编辑 Premiere 背后的文件做一些剪辑——但做不了全部。于是 Codex 顺理成章地"给自己造了一个能装进 Premiere Pro 的扩展"，再通过它对 Premiere 说"请把这个 marker 改一下"。"我们看到这一幕时挺炸的。"
• 模型一（Codex 用你的工具）："我们不需要给你做个更好的视频编辑器，但 Codex/ChatGPT 可以用那个视频编辑器、可以把活儿交接给它"——通过连接器、computer use、或本例的扩展。
• 模型二（你的 app 进 Codex）：Dan Shipper（Every）的设想——"我有这些能点来点去用的 web app，但我想在 Codex 里打开它们、让 Codex 在上面做额外的事"。"他每天都在 Slack 上为这个找我要东西。"
• Andrew 的产品哲学借此点题：几乎每个有用的活儿都始于这样一个故事——"产品不是为它设计的，但它是个能写代码的空白 chatbot，所以什么都能做"，剩下的只是好奇心驱动地去试、看它能不能搞定，"反正没有风险，就几个 token"。

"Naturally, what Codex then did was built itself an extension that could be installed into Premiere Pro." —— Andrew

核心要点：在固定环节"fail corner"，Andrew 给出反"一路向上"叙事的真实账本——他在到达这个高光点前失败了大约 10-15 年，上一家创业公司"基本是卖了零件"。这是他第一次不觉得自己在失败。

• "把这段描述播回给我挺好笑的，这大概是我第一次不觉得自己在失败。"他做了很久的创业者，最后把公司"essentially 卖了零件"，"那是很多年、一场苦役、在重度监管的领域"。之后又去一家在锁得很死的监管行业做 AI 工具的创业公司，"一次又一次试、一次又一次不 work"。
• 他的归因：有时只是某个时间点上技能、热情、市场的窗口刚好对齐了；"我失败了大概 10 到 15 年才到这个点，所以到现在每天还在惊讶事情居然顺利。"
• 现场质感：把 ChatGPT 与 Codex 嫁接的项目里，"有无数次微观失败"——"我们说这就是它该有的形状，扔进 Slack，然后就是一条 2000 条消息的串骂我们多蠢"。"这正是我爱 OpenAI 的地方——大家就是会直接告诉你"，对外产品之所以不错，正因为它内部经历了这种"2000 条·这玩意儿真烂"的循环。

"I failed for somewhere between 10 and 15 years before getting to this point, so I'm still surprised every day that things are going well." —— Andrew

核心要点：闪电轮里 Andrew 的书目和人生态度都收束到一个词——能动性 (agency)。片尾彩蛋进一步点出：在 AI 时代成功需要极高的自我觉察，而且"会的东西总要重新学"本身就是一种门槛，多数人不会是早期采用者。

• 书：作为幼儿家长，他推荐《The Gruffalo（咕噜牛）》；最爱的童书是老书《The Big Orange Splot（大橙斑）》——一只鸟把一桶橙漆掉在 Mr. Plumbean 整齐划一的房子上，他索性"豁出去"把房子彻底改造（吊床、鳄鱼……），邻居起初气炸（HOA、房价），后来一个个去找他喝"很有说服力的柠檬水"，最后全都改造了自己的房子。Lenny："我听到的是 agency。" Andrew："Agency，没错。你可以直接去做事 (you can just do things)。"
• 其他：剧追 Netflix 新版《Magic School Bus（神奇校车）》（Kate McKinnon 配 Frizzle）；最爱产品是 Linear（"在这个项目之前，Linear 是我最爱的软件产品"）；自认不是"motto 型"的人。
• 被问三种角色（PM/设计/工程）哪个最难，他拒绝给单一答案："让一个人觉得难的，恰恰让另一个人觉得容易"；这个 triad 正在出现"融合与流动性"，对有能动性、想直接把该做的事做掉的人是利好。
• 片尾彩蛋（停录后）：Andrew 反复强调"别和你当下的具体流程结婚，要和你独一无二能交付的结果结婚 (get married to the outcomes you are uniquely able to deliver)"；并坦言"在 AI 上成功所需的自我觉察程度很疯狂"——这里 work 的东西不会对所有人 work，"这里的人是自我选择出来的'我就是会去搞清楚下一步该做什么'的人，而大多数人不会是早期采用者"。他还自嘲"我讨厌重复自己，当创始人却得做'首席复读机'"，而 Codex 让他"每天用不同方式做同一份工作"——Lenny："你为自己的工作找到了 product-market fit。"

"Get married to the outcomes that you are uniquely able to deliver." —— Andrew