跳转至

Jay Parikh

Microsoft CoreAI 的 EVP（执行副总裁），实际统管包括 GitHub 在内的一批核心 AI 服务。⚠️ 转录稿把姓写成 "Parrick"，本库按主持人的介绍与职位判定为 Jay Parikh。

背景

⚠️ 以下履历出自主持人开场的介绍，本库未独立核实；⚠️ 其中几个专名在自动字幕里被错写，本库按常见写法还原并标出。

  • Facebook 工程负责人（主持人的说法是 "head of engineering for Facebook"）。
  • Lacework CEO（⚠️ 转录稿写作 "Lace Work"）。
  • Ning 与 Akamai 的工程 VP（⚠️ 转录稿写作 "Ning" 与 "Akami"）。
  • ✅ 主持人给的概括："基础设施、安全、甚至社交媒体领域的复仇者联盟。"

已收录访谈

核心观点（2026-11-08）

来源：Latent Space × Jay Parikh

⚠️⚠️ 本库判他最有价值的一条：代码变便宜不会取消开源供应链的理由，因为成本只是转移了

（[00:17:15]–[00:18:18]）被挑战的前提是主持人给的："GitHub 和我们这条开源供应链是建立在'代码很贵'这个前提上的。而也许现在代码很便宜了……也许加固系统的最好方式就是把一切 vendoring 掉或者重写掉"（把 2,000 个依赖砍到 20 个）。

  • ⚠️⚠️ 他的反驳不依赖任何产品优势，而是一条成本转移论证：

    "我也不觉得那是万灵药。因为，嘿，我在我的东西里用了 2,000 个开源项目，我要去掉其中 1,980 个，然后用剩下的 20 个——但那 1,980 个现在得由我来维护了。" "所以这是那种你必须选择把你的钱、你的人、你的时间放在哪里的情况。"

  • ✅ 而他的处方被说成一个方向选择："让我们去解决那个问题，也就是让开源里的东西变安全，而不是所有人都走进某种围墙花园的路子。" 配 "我不觉得开源会停下来。如果说有什么变化，我觉得开源对企业、对构建者、对创作者的价值只会从这里继续上升。"
  • ✅ 本库判这条值得长期保存的理由：⚠️⚠️ 它把答案定位在维护责任的归属上，而不是生成成本上——重写一次是便宜的，但拥有那段代码之后的每一次安全修复、现代化与升级都变成你的。 ✅ 检验方式：如果 vendoring 真的成主流，应先看到企业内部代码库规模与内部安全/维护投入同时上升，而不是只看到依赖数下降。
  • ⚠️ 本库记下他没有处理的一步：主持人的前提有两段（代码变便宜、安全评审也变便宜），而他只反驳了第一段。 🔗 相关讨论见 开源与基础设施、LLM 安全。

⚠️⚠️ harness 与模型路由是两层，各有各的"工作职责"

（[00:10:06]–[00:12:09]）✅ 本库此前的 harness 材料没有一条做过这个拆分。

  • harness（已作为 SDK 放出）：负责工具、MCP、模型的编排；"它背后的关键原则之一就是多模型"；必须持续适配新进来的工具与模型。
  • ⚠️⚠️ Fusion（选模型那一层）："把认知负担从你这个工程师身上拿掉——你面对的是所有这些价格性能各异的模型"，目标是"我们能让你很快拿到最好的质量，而且便宜得多"。
  • ✅ 两者的关系："你把 harness 和 fusion 想成一起起伏的（ebbing and flowing together）……你要有 fusion 来帮你搞清楚用哪个模型，因为今天选择太多了。"
  • ⚠️ 本库必须标注的限制：这是一个自家也卖模型的厂商在主张"我们帮你选模型"，而其中立性无法从本材料判断，本期也没有被追问。 🔗 对照一个中立路由方的版本见 OpenRouter 的 Alex Atallah 与 Amjad Masad——那一条给的理由是经济性（"fusion 把前沿质量做到四到五折"），这一条给的是认知负担。

⚠️ 他拒绝了两个送上门的有利说法

✅ 本库判这两处是他厂商色彩偏轻的主要依据。

  • ⚠️⚠️ ① 拒绝把 token ROI 算成收入（本库判这是全期最该单独保存的一句）（[00:21:19]–[00:22:20]）：当对话走到"我这周花了 1,000 美元 token……然后如果你能说我产生了 25,000 美元收入"时——"我觉得收入有点太……作为一个写代码的人，我不负责收入。但至少我交付了功能。我觉得能够谈的是这怎么转化成某种 ROI，也许不是收入。" → 替代口径是"成本节省，或者说这提高了参与度、留存，或者改善了 CSAT——这些都是可度量的，而作为产品团队和工程团队，你应该挂在这些结果指标上"。 ✅ 本库标注："token 支出 → 收入"是对卖 token 与卖 AI 工具一方最有利的叙事，而他主动把分子降级了，理由是职责归属而不是谨慎。
  • ⚠️ ② 拒绝"代码已经不重要了"（[00:08:04]–[00:09:05]）：主持人指出一个全是 markdown 的仓库被 keynote 重点展示、于是"语言占比已经不重要、什么是仓库、什么是代码" → 他只同意一半："我同意你。但我觉得还有大量代码存在。你想想所有那些用 Java 和 .NET 写的、今天在跑着业务关键的庞大生意的代码"，它们"要做安全修复、在现代化、在优化、在修 bug"，"其中一些东西有几十年历史"，⚠️ 而"其中一些正在我们说话的这会儿被 vibe code 进生产"。✅ 收口落在选择权："我自己就是个开发者。我对某些事很挑……有一种手艺，是我用我用的那些工具表达出来的。"

⚠️ 平台观：概念要可组装，而"PR 是否必需"属于配置项

（[00:06:03]–[00:07:04]）

  • 回应 "pull request 的终结"（主持人引 Peter Steinberger 的推动）："如果这些概念之一没用、或者人们不想要它是必需的，那它可以变成可配置的。" ⚠️ 约束条件是规模："跨越 2.25 亿开发者、大企业、小公司、学生等等，我们确实必须提供一个有很多概念的平台，然后你应该能把这些概念组装起来。"
  • ✅ 一手例证（本库认为比他的产品表述更有信息量）："我有些仓库是我自己瞎折腾玩的，我不做 PR……我就是在建、建、建、建，我不想处理 issue 或者 PR 或者任何东西。"

⚠️⚠️ "上下文复利"这条护城河主张，以及本库对它的处理

（[00:13:10]–[00:14:10]）

  • 主张：全部界面（手机、桌面、VS Code、.com）用同一个 harness 连起来 → "不管你用哪个模型……所有那些上下文、记忆、偏好，还有那个智能引擎，全都在一个地方为你复利" → ⚠️⚠️ "今天如果你用一家提供商的一个工具、然后切到另一家，它们不会把各自的智能复利到一起。"
  • ⚠️⚠️ 本库的处理：这把切换成本重新描述成了用户收益，而那正是锁定效应的标准讲法，本库不采信"所以对用户更好"这个结论。 ✅ 但本库记下它可检验的部分：如果上下文复利是真的，换工具的代价应随使用时长单调上升，于是流失率应随使用时长下降得比单纯的习惯效应更快。 ⚠️ 本期未给任何数据。

⚠️ 2027 的三条预测，其中一条是坦率的不知道

（[00:19:18]–[00:21:19]）

  • ⚠️ ① Azure 迁移"计划是明年。那是我们瞄的目标"（✅ 本库记为一个有明确日期的可核对承诺），并继续"在栈的每一层做阶跃式改进"。
  • ⚠️⚠️ ② 并发 agent 的量级："我们是在管理成千上万个 agent，还是几十个、几百个？我不知道。" → 应对是"用正确的原语来建平台，让你能把那些原语组装成你想要的工作方式"。 ✅ 本库判这是一个对自己不利的承认，因为平台的容量规划恰恰依赖这个量级。 🔗 而本库既有的一手并发数据（Steinberger 并行 4–10 个）与"成千上万"之间差三个数量级。
  • ⚠️ ③ 安全，以及 token 支出治理（术语在转录稿里写作 "POPS"，⚠️ 本库判定为 FinOps 之类的表述、不确证）："我怎么管理我在 token 上的全部支出，因为这是这些天一个非常热门的话题。" 具体是为组织拆解支出 → 给换模型的优化建议 → "尤其是财富 500 强，他们要治理、他们要能设上限"。

自述的安全工作（⚠️ 全部为能力声明，无口径、无第三方核实）

（[00:14:10]–[00:17:15]）code review max（"找到更高严重度、更隐蔽的 bug"，理由是"我们在生成多得多的代码，要确保质量门槛不下滑"）；GitHub Advanced Security 带 AI 扫描；keynote demo 里误推的 secret 在进入仓库前被拦住；与开源维护者合作"限制像 npm 这样的包管理器的暴露面，包括设置时间延迟、以及下架被攻破的仓库"。🔗 本库既有的相邻材料见 All-In × Nikesh Arora（PHP 漏洞周）。