← 收录原文
BUILDERS · 精选整理

Builders 精选|2026-07-28

2026-07-28 · 历史整理稿

X / 推特

OpenAI Codex 与 ChatGPT 成员 Thibault Sottiaux

Thibault Sottiaux 说,OpenAI 现在的状态是“vibes are strong”,他从未见过公司如此专注且运转顺畅。更有信息量的是他对 ChatGPT “work”能力的描述:他强调不要只把 ChatGPT 当聊天框,而是让它真正替你完成任务。例子包括谈判网费、取消垃圾邮件订阅、为想买或想做的事寻找最合适的 deal。关键变化在于,这些事情都可以从手机上用一个 prompt 发起,不再需要用户自己在多个网站和应用之间切换。他说 ChatGPT 每天至少为他完成 20 件事,而且他仍然会被效果惊到。对 builder 来说,这条推文的信号是:AI 产品的竞争点正在从“回答得好不好”转向“是否能接上真实个人事务并完成闭环”。

AI 教程作者 Peter Yang

Peter Yang 从加拿大和非 AI 圈用户聊天后的观察是,普通用户最担心的不是 token 会不会用完。他听到的第一担忧是:我是否足够信任 ChatGPT,愿意把 Gmail、Calendar、Google Workspace、Microsoft Office 等个人和办公账户交给它。这个判断把 AI adoption 的问题从“算力和额度”拉回到“信任和授权”。对很多 builder 来说,做 agent 或个人助理产品时,用户真正卡住的可能不是不会 prompt,而是不敢把高价值数据和操作权限开放出来。因此,产品设计不能只展示能力,还要解释边界、可见性、撤销机制和权限控制。换句话说,连接 Gmail 或 Calendar 不是一个简单 integration,而是一次信任交易。

Meta AI 高级总监 Madhu Guru

Madhu Guru 反驳了“AI 还没有在产品里带来明显 shipped impact”的说法。他认为现在只是 phase 1:有 distribution 的公司正在快速扩展到相邻问题区域,AI 让它们能更快执行,并构建过去需要大量 custom software 才能完成的功能,例如 clothes try on。当前影响还没有在生态系统层面完全显现,是因为公司仍在摸索 playbook。到 phase 2,他预计会出现更多 net new features 和真正的产品创新。那时 AI 对软件生态形态的影响会变得难以否认。这个判断对 builder 的启发是,不要只用今天可见的新独角兽数量衡量 AI 影响,也要看既有分发渠道如何把 AI 能力嵌入具体工作流和消费场景。

Replit CEO Amjad Masad

Amjad Masad 转述一位前 Anthropic 员工的观察:黑客更倾向于使用被大量补贴的实验室 AI 订阅服务来发动攻击,而不是使用开放模型。这个点把 AI 安全讨论里的一个常见假设翻了过来:风险并不只来自 open models,封闭模型和商业订阅在价格补贴和易用性上同样可能被滥用。他没有展开具体证据,但强调这是一条值得注意的“interesting drop”。对 builder 来说,这意味着滥用治理不能简单等同于限制开源权重。只要高能力模型以低成本、低摩擦形式提供,攻击者就会选择最省事的工具。

Vercel CEO Guillermo Rauch

Guillermo Rauch 表示 Vercel 联署了 Open Weights and American AI Leadership letter。他把 open source、data、protocols 和 research 视为当代技术奇迹的基础,并认为 open weights 是下一个自然前沿。这说明 Vercel 在 AI 基础设施和开发者生态上明确支持开放权重路线。另一条推文则是非常具体的工程实验:他把 Vercel CLI TypeScript 用 scriptc 编译成 native。结果二进制体积为 1.28mb,平均启动开销 1.5ms,平均编译时间 2.94s,并使用 node:https、node:fs、node:path、node:os、node:crypto。代码由 GLM 5.2 Fast 翻译,最终没有嵌入 v8 或 QuickJS,而是 fully static,并且可以正常部署。对工具链 builder 来说,这里值得关注的是 TypeScript CLI 原生化的新路径:保持 TypeScript 可读性,同时拿到接近 native binary 的分发和启动体验。

Box CEO Aaron Levie

Aaron Levie 认为,AI 向真实世界扩散仍有巨大机会,因为多数企业需要大量支持才能把模型突破真正应用到 workflow。单纯的 intelligence 不足以改造流程,原因是它必须和真实世界的反馈回路连接起来。这包括接入各种企业系统、把正确数据送到 AI、通过合适 UX 让人在流程不同阶段做决策、让 workflow 反过来改善数据和模型,以及处理监管和合规问题。他举例说,在银行做 client onboarding 的 AI agent,和法律团队做 contract review 的 AI agent,实施方式完全不同。在 life sciences、financial services、legal、manufacturing 等关键行业里,AI 只有以具备上下文的方式接触真实业务才有价值。他把这层能力称为 applied AI layer,并认为其中一部分会由 labs 直接提供,但大量机会一定来自能深入各行业的独立公司。更反直觉的是,他认为模型越强,对 applied layer 的需求不会减少,反而会增加,因为可自动化的 workflow 越野心勃勃,所需的行业连接、数据、UX 和合规层也越复杂。

Builder Zara Zhang

Zara Zhang 提出,不要用 burned tokens 衡量 AI adoption,而应衡量“从用户需求出现到对应东西 shipped”的时间。这个指标把 AI 使用从消耗量转为交付速度,更适合评估团队是否真的获得了生产力提升。她还解释为什么市面上会有这么多 AI 教程:越通用的聊天产品越难使用,用户面对空白输入框会卡住,因为他们真的不知道该问什么。也就是说,AI 产品越 general,越需要 examples、workflow 和具体入口来降低启动成本。她还分享了自己的 X 发布方式:平均每天发约 3 条,最多花 15 到 20 分钟,不会过度思考,想到就发。多数材料来自她已经在线下对别人说过的话。对 builder 来说,这几条合在一起是一套很清晰的产品和内容方法:衡量交付周期,降低空白框焦虑,把已经验证过的真实表达转成公开输出。

FPV Ventures 合伙人 Nikunj Kothari

Nikunj Kothari 的一句话判断是:“proof of prompt is soon going to replace proof of work”。他的意思不是 prompt 本身会神奇替代劳动,而是随着 AI 工具进入构建流程,能否把意图清楚表达、拆成可执行指令、让系统稳定产出,会成为新的能力证明。过去 proof of work 展示的是你亲手完成了什么;未来 proof of prompt 可能展示的是你如何驾驭模型、工具和上下文完成结果。这个观点对招聘、作品集和团队协作都有影响:builder 的产出记录可能会从代码 diff 扩展到 prompt、工具调用路径和最终交付物之间的关系。它也提醒团队不要把 prompt 当临时文本,而要把高质量 prompt 看作可复用的工作资产。

Every CEO Dan Shipper

Dan Shipper 说他要休息一周,专门写一篇关于 Codex 如何诞生的 definitive history。这篇文章会基于他对 OpenAI 内部人士的深度采访,并计划几周后发布在 Every。他表示会在写作过程中陆续放出 breadcrumbs 和 learnings。对关注 AI coding agent 的 builder 来说,这可能是一篇值得追踪的内部史材料,因为它不是单纯产品评测,而是试图还原 Codex 形成过程中的组织、技术和产品判断。当前素材没有提供具体采访内容,所以只能确定文章方向和发布计划。值得留意的是,Codex 已经不只是一个工具名,也正在成为 AI 编程产品演化史里的关键案例。

Sam Altman

Sam Altman 用一个长 prompt 展示了 ChatGPT work 的能力。他从手机发出请求:基于全部聊天历史,为 8 位朋友规划 long weekend trip,给出最佳 3 个选项,做一个 full-stack site 让 9 个人协调各自想去哪里并达成决定,然后在达成一致后预约,并在 Gmail 里起草一封可以发给朋友的邮件。他的总结是:“it...just worked.” 这个例子密集地包含了个人上下文读取、多人决策支持、网站生成、后续预订和邮件草稿几个环节。重点不是旅行规划本身,而是 ChatGPT 从建议工具变成了可以串联多个动作的执行系统。它也呼应了 Thibault Sottiaux 的观察:手机上的一个 prompt 正在成为个人事务自动化入口。对 builder 来说,真正的产品挑战会落在跨应用权限、状态追踪、用户确认点和多人协作流程上。

播客

The MAD Podcast with Matt Turck — OpenAI’s Compute Chief: We Can’t Build Fast Enough | Sachin Katti

核心要点:AI 的瓶颈正在从模型层快速下沉到物理世界,OpenAI 最担心的不是需求不足,而是算力、供电、冷却、网络和施工能力都跟不上。

Sachin Katti 现在负责 OpenAI 的 industrial compute,此前是 Stanford 教授、多次创业者,并曾任 Intel CTO。他把 OpenAI 正在推进的算力建设形容为人类历史上最大的基础设施建设之一,而且公司内部每天都在做过去 Intel 可能要花数月才会做出的重大算力决策。Matt Turck 提到 OpenAI 今年 compute spending 的方向性数字约为 50,000,000,000 美元,整个行业今年 compute spend 可能达到 700,000,000,000 美元;Sachin 的回应是,这些数字还会继续增长,因为今天的建设会在一两年后转化为可被 OpenAI 等公司消费的算力。

第一,AI data center 的本质已经不是传统云机房,而是大型 supercomputer。Sachin 用一句很形象的话解释:“数据中心就是把电子变成 token 的巨大工厂。”模型越强、任务越复杂,就需要越大的计算机;这些芯片温度极高,不能只靠空气冷却,而要在 data hall、芯片、连接线缆、变压器等多个层面做 liquid cooling。他强调液冷不是新概念,真正的新问题是如何在这个规模上做到可靠、便宜、可扩展。冷却效率直接影响芯片能跑多热,而芯片越能稳定高温运行,就越可能获得更高 memory bandwidth 和 flops,最终产出更多 intelligence。

第二,电力不是背景资源,而是核心供应链。OpenAI 早期和其他公司一样接入 grid,但现在已经开始投资 grid 的发电和输电基础设施。Sachin 说,每建一个 data center,他们都会做 hard commitment:不是从电网里拿走现有电力,而是投资新增电力,让数据中心可以消费这些新增供给。这个表述说明 AI 公司正在从买云服务,进入到参与能源基础设施建设的阶段。

第三,OpenAI 正在形成自己的 compute muscle,而不仅仅依赖 partners。Sachin 说,OpenAI 一直相信 compute 是 intelligence 的基础;变化在于,在当前规模下,公司不能只等 partners 提供 compute,而要更主动地参与建设和获取所需算力。不过在商业结构上,Microsoft、Google、Amazon、Oracle 等 partners 仍会负责大量建设,OpenAI 作为 tenant 和 offtaker 承诺消费这些 compute。

第四,custom silicon 的速度来自团队、伙伴和 workload 可见性。OpenAI 的 Jalapeno 芯片从设计到 tape-out 约 9 个月,Sachin 说这是他职业生涯里见过最快的节奏之一。原因包括团队里有设计过 Google TPU 的成员、Broadcom 在 XPU ASIC 上有强执行记录,以及 OpenAI 知道未来模型 workload 可能长什么样,能缩短大量芯片设计决策。更关键的是,AI 已经开始辅助芯片设计和优化。他判断,“AI 会设计训练和运行下一代 AI 所需系统”的世界并不遥远,而且包括芯片。

第五,100,000 GPU 级别集群的网络可靠性需要新协议。Sachin 介绍 MRC 是一种新的 routing technology,用来扩展超大 cluster fabric。大训练任务中,GPU 之间持续通信,链路、交换机、NIC 的数量巨大,故障不可避免。MRC 的思路是 multipath spraying:在两颗芯片之间同时利用多条路径发包,任何一路成功都能继续推进,从而让训练任务不必关心底层网络故障。他把目标说得很清楚:network 应该是一个被抽象掉的系统,训练 job 不应该因为常见故障停下来。

最后一个容易被忽视的瓶颈是人。Sachin 明确提到 electricians、plumbers 等技能岗位短缺,而且 hyperscalers 和 labs 都会积极雇佣具备相关能力的人。另一个商业变化是 guaranteed capacity,本质上是 guaranteed tokens,也就是企业提前锁定一定美元价值的 intelligence supply。在 compute 短缺的世界里,token 会长期具有溢价;当 intelligence 成为企业运行的基本输入,锁定供应就会变成正常的 business hygiene。