Signal to BuildSIGNAL TO BUILD中文Owner sign in ↗
← Knowledge Notes
AI Engineering ／ Knowledge note · Chinese

AI Builders · 编程智能体与 Agentic Engineering(播客精炼)

Karpathy / Boris Cherny(Claude Code 之父)/ OpenAI Codex / Cursor / Notion / Pydantic 等 11 档播客横切。核心共识=2025/12 "从打字到调度" 拐点 + "skill = markdown + 脚本" + "凡是 agent 没法用 API 调到的就等于不存在";核心分歧=Claude Code vs Codex、MCP vs CLI、零人工审查走多远

Source collection：AI Builders · Published here：2026-09-26 · Note updated：2026-06-05

编程AgentAgent工程开发工作流

这篇 wiki 把 11 档英文播客(AI & I / Latent Space / No Priors / Training Data / Unsupervised Learning)里关于"编程智能体"的讨论拧成一股,按概念而非按集数组织。这一波人(Karpathy、Claude Code 之父 Boris Cherny、OpenAI Codex 团队、Cursor、Notion、Pydantic)在 2026 春天高度共识的一件事:写代码这个动作正在消失,人的工作变成"对一群 agent 表达意图 + 验收"。他们也在几个关键路口公开掐架——这篇专门把分歧也摆出来。

何时打开:

  • 你听人说"我已经不自己写代码了"但不知道这到底是吹牛还是真的发生了
  • 你纠结 Claude Code 还是 Codex(OpenAI 的编程 agent),想看真正天天用的人怎么选
  • 你是产品/运营,想知道"编程 agent" 凭什么能干非编程的活(写邮件、做调研、管指标)
  • 你想搞懂为什么大家都在说 "skill"、"harness(外壳)"、"MCP vs CLI" 这些黑话
  • 你想给团队/老板解释:为什么"会写代码"突然没那么值钱、什么才值钱

0. 一句话地图:这一波到底在讲什么

把"AI 写代码"想成一条电梯,这 11 档播客的人都站在不同楼层往上看,但都指向同一个顶楼:

楼层 0  人自己敲代码,AI 只做补全(2024,老黄那篇 newtype 讲过)
楼层 1  Vibe Coding:用嘴让 AI 写,人还盯着改       ← Karpathy 造的词
楼层 2  Agentic Engineering:派一群 agent 干活,人只表达意图 + 验收  ← 2025/12 拐点
楼层 3  零人工审查 / agent 自己开工单、自己改自己      ← "dark factory 暗工厂",最前沿
楼层 4  自动研究:给目标+预算,agent 自己跑实验自己迭代  ← Karpathy 的 AutoResearch

Why 这张图重要:很多人(包括你老板)还停在"AI = 聊天机器人"的认知,而台上这帮人已经在楼层 2-3 生活了。下面每一节都是这张图某一格的展开。

1. 那个拐点:2025 年 12 月,"从打字到调度"

几乎所有受访者不约而同把同一个时间点标成转折——2025 年 12 月。

Karpathy(OpenAI 联创、ex-Tesla,No Priors / Training Data 两档都讲了):

"I don't think I've typed a line of code probably since December." 译:我大概从十二月起就没自己敲过一行代码了。

"Code's not even the right verb anymore. I have to express my will to my agents for 16 hours a day. Manifest." 译:"写代码"已经不是合适的动词了。我现在一天 16 小时都在向我的 agent 们表达意志。用"显化(manifest)"更准。

他把自己的状态从 80/20(自己打 80% 代码)翻转成 20/80(80% 交给 agent),并说"一个普通软件工程师的默认工作流从十二月起已经彻底不一样了"。

Boris Cherny(Claude Code 的作者,Training Data)给出更极端的数字:

"For me, it's just solved. The model writes 100% of my code. There was a day last week I did 150 PRs in a day." 译:对我来说这事已经解决了。模型写我 100% 的代码。上周有一天我提交了 150 个 PR(代码合并请求)。

Why 拐点是真的、不是营销:两个独立的人(一个在 OpenAI 生态、一个在 Anthropic)用几乎一样的话、一样的月份描述同一件事。Karpathy 还补了句关键的——去年把 AI 当"ChatGPT 那种聊天玩意儿"的人,必须从十二月起重新评估,因为"agentic 的连贯工作流"这次是真的能用了。

对非技术读者的翻译:这就像打字员时代过渡到"口述给秘书团"——你不再纠结打字快慢,你纠结的是"我到底想要什么、怎么说清楚、怎么验收"。瓶颈从手指挪到了脑子。

2. 核心心法:Vibe Coding ≠ Agentic Engineering(别混)

这是 Karpathy 反复强调、最容易被外行搞混的一组词。

Vibe Coding(凭感觉编程) Agentic Engineering(智能体工程)
干什么 用嘴让 AI 生成能跑的东西 派一队 agent 做专业级软件
解决谁的问题 抬高地板:人人能做软件 守住天花板:专业质量不塌
还管不管质量 不太管,能跑就行 还得管(不能引入漏洞、对软件负责)
速度上限 一般 极高,"远超老的 10x 工程师"

Karpathy(Training Data):

"Vibe coding is about raising the floor for everyone. Agentic engineering is about preserving the quality bar of what existed before in professional software." 译:Vibe coding 是给所有人抬高地板;agentic engineering 是在飙速度的同时守住专业软件原有的质量门槛。

"10x 工程师"已经不够形容了——"10x is not the speed up you gain. People who are very good at this peak a lot more than 10x."(真正擅长的人峰值远超 10 倍。)

Why 这对产品经理很关键:你团队里那个"能用 Cursor 拼个 demo"的人,和那个"能调度一队 agent 交付不出 bug 的生产系统"的人,完全是两个段位。前者是 vibe coding(地板),后者是 agentic engineering(天花板)。招人、定级、分活都得按这条线重切。

3. 软件 1.0 / 2.0 / 3.0:理解这一切的底层框架

Karpathy 的经典三段论(贯穿两档节目,Cursor 那期的 Dima 也借用了):

代际 你在"编程"什么 大白话
Software 1.0 写明确的代码 程序员手敲 if-else
Software 2.0 整理数据集 + 训练神经网络 "用数据编程"(深度学习时代)
Software 3.0 写提示词 / 上下文 把大模型当"解释器",上下文窗口是你的操纵杆

Cursor 的 Dima 又加了一层(从训练视角):1.0 雕代码 → 2.0 雕训练数据 → 3.0 雕评估标准(eval rubrics)。

关键的认知翻转(Karpathy):别把 AI 当成"老范式的提速器"。一整类 App 现在"不应该存在了"——因为神经网络直接把活干了。

"MenuGen example: he built a full app (OCR + image-gen + Vercel) to turn restaurant menus into pictured menus; the Software 3.0 version is just handing the photo to Gemini and saying 'use Nanobanana to overlay the dishes onto the menu'." 译:他原本造了个完整 App(文字识别 + 图像生成 + 部署)把菜单变成带图菜单;Software 3.0 版本就是把照片丢给 Gemini 说"用 Nanobanana 把菜品贴到菜单上"——整个 App 都成了多余。

Why 对产品决策致命:你正在做的某个功能,可能下一代模型一句话就替代了。"凡是你能验证对错的事,LLM 都能自动化"(见 §7)——所以做产品前先问:这事是不是模型一句话就能干?如果是,别造 App,造提示词。

4. 新工作方式:一个人指挥一支 agent 舰队

拐点之后,"工作"长什么样?受访者描述高度一致——多 agent 并行,人在中间当调度官。

  • Karpathy 的 "Peter Steinberg 原型":一个屏幕铺满几十个 Codex agent,每个高强度跑 ~20 分钟,本地 checkout 了 ~10 个仓库,人在仓库间来回派活。
  • Cherny 的手机流:现在主要用手机上 Claude App 的 code 标签页——同时开 5-10 个会话、几百个 agent 在跑、隔夜几千个跑更深的活。
  • Karpathy 对工作的重新定义:工作变成对仓库下"宏动作(macro actions)"——把互不干扰的功能丢给 agent 1、agent 2……一个做调研、一个写码、一个做规划,你练的是调度的肌肉记忆。

新的稀缺资源不是算力,是"令牌吞吐量(token throughput)"和人的注意力。

Karpathy:留着没用完的订阅额度会让他焦虑(Codex 用光就切 Claude),像"博士生看着 GPU 闲着难受"。

Ryan Lopopolo(OpenAI Frontier,Latent Space)把这点推到极致:

"The only fundamentally scarce thing is the synchronous human attention of my team." 译:唯一真正稀缺的,是我团队成员同步的人类注意力。

Why:令牌和 GPU 可以无限并行、便宜;人的注意力一天就那么几小时。所以整套工程的目标变成了"把人从环里拿掉"。

对你的启发:别再用"工时"衡量产出。新的产能单位是"你能同时盯住几个 agent 而不翻车"。这本身是要练的技能(Karpathy 反复说的"肌肉记忆")。

5. "Skill"、"Harness"、"Loop":黑话三件套(给非技术读者)

这三个词在每档节目里反复出现,搞懂它们这一波就听得懂一半了。

5.1 Skill(技能)= 一个 markdown 文件 + 几个脚本

Swyx(Latent Space 创始人,现在 Cognition,Unsupervised Learning 那期)给了最干净的定义:

"Skills = a markdown file + attached scripts. I don't see how it can be more simple than that." 译:技能 = 一个 markdown 文件 + 附带的脚本。我想不出还能更简单。

他把 agent 拆成最小公式:agent = "带工具的大模型在循环里跑" + 文件系统 + 检索 + 技能。这一层现在"基本达成共识"了。

大白话:skill 就是你把脑子里某个 SOP(标准流程)写成一篇说明书塞给 agent,它照着干。不需要写程序——会写 Word 文档就会写 skill。

5.2 Harness(外壳)= 包在模型外面那层"装配台"

模型是发动机,harness 是车架。"Harness engineering 有巨大的 alpha(超额收益)"——Anthropic 平台团队的 Angela(AI & I)说,他们给 agent 做记忆功能时试了好几种 harness,评测结果差异巨大:

"You can hill-climb a tremendous amount by just harness-engineering the right pieces together." 译:光靠把外壳的零件拼对,你就能爬升一大截性能。

5.3 Loop / Routines(循环)= 让 agent 自己定时反复干

Cherny 最爱的原语就是 /loop——让 Claude 用定时任务(Cron)反复跑:看护 PR(修 CI、自动 rebase)、保持测试健康、每 30 分钟聚类一次 Twitter 反馈。

"Loops are the future at this point. If you haven't experimented with it, highly recommend it." 译:循环就是未来。还没玩过的话,强烈建议试试。

新出的 "Routines" 是服务端版的 loop——关了笔记本它还在云上跑。

Why 这三件套是核心:它们让 agent 从"问一句答一句"变成"自己持续干活的同事"。这正是从楼层 1 爬到楼层 2-3 的台阶。

6. ⚔️ 分歧一:Claude Code vs Codex(到底用哪个)

这是整批播客最有看头的实战分歧。同一批顶级用户,选择不同、理由公开。

Dan Shipper & Austin(Every 公司,AI & I《我们为什么从 Claude Code 换到 Codex》)的故事:

  • 半年前 Codex"是垃圾"——Dan 原话:"Codex... three months ago, six months ago, it was trash." Austin:"Nothing has ever made me feel more stupid than Codex two months ago."(没有任何东西比两个月前的 Codex 更让我觉得自己蠢。)它"会跟你吵架、没情商、有点自闭"。
  • 然后 OpenAI 在 ~3 个月里硬掉头,把 Codex 从"只给资深工程师的沙箱玩具"改成"日常主力"。Austin 现在 80% 的工作时间泡在 Codex App 里,理由不是模型更强(他认为最新 Opus 和最新 GPT 在他的知识工作上"至少打平"),而是 Codex 的桌面 App 比 Claude 桌面 App 快得多、强得多,子 agent 也强——他估"好 30-40%"。
  • 但他特意补一句:别人不一定非得换,Claude 桌面 App 本身已经改变游戏规则了。换的成本也极低:你可以直接叫 Codex"去把我所有 Claude 的东西搬过来"。

Karpathy 的"人格对比"(No Priors):Claude"像个队友",拍马屁拿捏得准(夸你时你觉得配得上,烂主意不会被强捧);而编程版 Codex"很干、似乎不在乎你在创造什么"。

Samuel Colvin(Pydantic,Latent Space)的神比喻——他同时用三家:

"Claude Code is like Captain America. Codex is this neurotic, geeky, like the Q guy in Bond. And Gemini is like the Joker — this unhinged lunatic that will occasionally do an incredible job, but half the time just delete all of your files." 译:Claude Code 像美国队长(稳、正);Codex 像 007 里那个搞技术的神经质极客 Q;Gemini 像小丑——疯批,偶尔神来之笔,但一半时间直接把你文件全删了。

怎么用这组分歧:

  1. 没有标准答案,而且半年就翻盘一次——别把"某某更好"刻进脑子,这是高波动期(Swyx 语)。
  2. 选择更多取决于桌面 App 的工程体验(速度、子 agent),而非模型原始智力——后者已趋于打平。
  3. Swyx 的商业视角:Anthropic 是高价精品(限额度、限模型发布、产品+模型捆绑);OpenAI Codex 是"快进来"(补贴、开放 SDK、重置额度)。建议:趁补贴还在薅羊毛,$200/月的套餐就足够当"能力探索者"。

Dan Shipper 的元建议:"Someone using a new tool with a new paradigm and a new workflow is just going to beat you by default."(用新工具+新范式+新工作流的人,默认就会赢你。)所以定期换工具试新范式,本身是竞争力。Every 公司每年搞两次 "Think Week"(整周不干日常活,只玩新工具),他建议团队至少每季度一天。

7. 决定一切的尺子:可验证性(Verifiability)+ 锯齿状智能

这是判断"AI 能不能帮你干某件事"的通用判据,Karpathy 讲得最透。

核心命题:经典计算机自动化"你能用代码写清楚的事";LLM 自动化"你能验证对错的事"(automate what you can verify)。前沿的强化学习(RL)只奖励"可验证"的领域,于是练出来的智能是"锯齿状(jagged)"——在数学/代码上是顶尖博士,在别处可能像十岁小孩。

Karpathy 的名句(Training Data):

"How is it possible that state-of-the-art Opus 4.7 will simultaneously refactor a 100,000 line codebase or find zero-day vulnerabilities, and yet tells me to walk to this car wash? This is insane." 译:最先进的 Opus 4.7 既能重构十万行代码、又能挖出零日漏洞,却建议我走路去那个洗车店——这太离谱了。

锯齿来自两股力:(1) 什么是可验证的;(2) 实验室选了把什么塞进训练数据。GPT-3.5 到 GPT-4 的国际象棋大跃进,不是通用能力涨了,是有人往预训练里加了大量棋谱。"你受制于实验室在干嘛。"

对产品/创业的可操作结论:

  1. 做事前先判断你的应用"在不在 RL 回路里"——在(数学/代码/可自动判分的事),你起飞;不在(模糊、说不清对错的事),你挣扎。
  2. 可验证的领域哪怕实验室不重点搞,你也能自己拉微调杠杆搞定(Karpathy 给创业者的建议)。
  3. 终极乐观:Karpathy 认为"一切皆可自动化"——连写作这种模糊领域,也能用"一组 LLM 评审团(council of LLM judges)"造出可验证性。这是"难 vs 易"的问题,不是"可能 vs 不可能"。

配套金句(他常引用的一条推):

"You can outsource your thinking, but you can't outsource your understanding." 译:你可以外包你的思考,但你没法外包你的理解。

人退化成"瓶颈/导演",但理解是没法委托出去的东西。这条对非技术个体尤其重要:工具帮你思考,但你必须真的懂,否则验收不了、也指挥不动。

8. ⚔️ 分歧二:MCP vs CLI(给 agent 接外部工具,走哪条路)

"怎么让 agent 用上外部工具/数据"有两条技术路线,业内分两派。先把两个词翻成人话:

  • MCP(模型上下文协议):一套标准插头,把工具"声明"给 agent,"你只能调这些工具",权限干净。
  • CLI(命令行工具):让 agent 像人一样在终端里敲命令。

反 MCP 派(Ryan Lopopolo / OpenAI Frontier;Notion 的 Simon 偏向 CLI):

  • Lopopolo 直言看空 MCP:它强行把所有工具的说明塞进上下文,搞乱自动压缩,agent 还会"忘了有哪些工具"。他偏好薄薄的 CLI 壳(比如只包他们真正用的 3 个 Playwright 调用),并把 CLI 包成省 token 的样子(只输出失败的测试、从日志里抠出异常)。
  • Notion 的 Simon Last 看多 CLI,因为它住在终端里,天然有分页、渐进披露,而且能自举(self-bootstrapping):"我的 agent 没有浏览器,我就让它自己做一个——100 行包一下 Chromium API。"

挺 MCP 派(Notion 的 Sarah Sachs 部分认同;Cherny 力挺):

  • Simon 也承认 MCP 的权限模型强:"MCP is just the dumb simple thing that works, and it is pretty good."(MCP 就是那个又笨又简单但管用的东西,而且相当好。)适合窄、轻、强权限的 agent。
  • Cherny(Claude Code 之父)对知识工作直接说最简单的答案就是 MCP——同一套连接器(Salesforce、Google 文档/日历)能跨 Cowork、Claude CLI、Claude Code 复用;没有 MCP 的系统就用"计算机操作(computer use)"兜底。

两派其实都同意的那句话(Cherny):

"To the model is just tokens." 译:对模型来说,这些(MCP / CLI / API / 计算机操作)全都只是令牌。

接入机制本身不重要,重要的是省不省 token、权限干不干净、agent 能不能自己 debug。

Sarah Sachs 的成本视角(给产品/财务的关键):

"Needing language to execute deterministic tasks feels wasteful." 译:用(烧 token 的)自然语言去执行确定性任务,感觉很浪费。

按量计费下,让 agent 写一段代码去调 CLor(确定性、一次性成本),比反复付 token 费让 LLM 去敲 MCP 划算——尤其超出缓存窗口时。所以 Notion 对搜索这种核心能力故意不用 MCP,自己写。

怎么决策:窄而稳、要强权限 → MCP;复杂、要 agent 自己探索/自愈、量大要省钱 → CLI。

9. ⚔️ 分歧三:harness 是不是难点?真正的墙在哪

一个"业内自己打架"的话题——大家以为难的地方,可能不是真正的墙。

Anthropic 平台团队(Caitlin,AI & I)"辣评":

"I think people think the harness engineering part is the hard part... but everyone hits an infrastructure wall." 译:大家以为外壳工程是难点……但每个人最后都撞上的是"基础设施"那堵墙。

她的意思:提示词缓存、把上下文窗口塞满这些"外壳"活,Agent SDK 已经帮你搞定了;真正的墙是"产品化"——让服务器一直在线、按需启停、存对话记录、安全沙箱、容错(沙箱一死,整个 agent 就死)。这正是 Anthropic 做 "Managed Agents(托管智能体)" 的初衷。

但 Angela(同台)又坚持 harness 有巨大 alpha(§5.2)——所以这不是矛盾,是分层:外壳能让你爬升性能(有 alpha),但你要规模化跑生产,撞的是基础设施墙。

还有一个关于"模型锁定"的重磅观点(Angela):老一代模型时代,流行做一个"很通用的 harness"+热插拔模型;下一代,每家实验室技术路线分叉,harness 和模型变成"紧耦合的一对"。所以你要做冗余/切换,应该在"agent 层(harness + 模型一起)"切,而不是在底下做一个通用 harness 然后热插拔模型。

Why 对采购/架构决策重要:别再幻想"做个万能中间层,模型随便换"。这一波,模型和它的外壳是一套的,换模型基本等于换整套 agent。

10. 极端案例:把"零人工"推到尽头(暗工厂)

Ryan Lopopolo 的团队(OpenAI Frontier,Latent Space)做了一个激进实验,值得当"未来预演"看:硬规定团队一行代码都不许手写,逼自己把 agent(Codex)训成能干工程师全部的活。

结果(~5 个月):~100 万行代码、~1500 个 PR、3 个人、比手写快 ~10 倍——但头 1.5 个月反而慢 10 倍(在给 agent 搭"装配台")。

几个反直觉的运营心法:

  • 人类审查从"合并前"挪到"合并后":不再当守门员,而是合并后抽样看团队在哪卡壳。代码审查 agent 可以自主合并。
  • "模型本质上渴望文本(crave text)":整套打法就是把文本从一个 agent 灌给另一个 agent——文档、能教 agent 怎么修的报错信息、技术追踪表、质量分、PR 评论,全是在补 agent 缺的上下文。
  • 每个错误 = 一条还没写下来的隐性需求。把工程师脑子里"什么叫好"挖出来,编码成文档/测试/审查规则。
  • 代码是一次性的:他们的系统有个"返工"状态——PR 不能干净合并,就把整个工作区+PR 扔了从头来,然后问"为什么是垃圾",把答案编码进去。
  • 信任 = 可压缩的可读性,不是监控:他不想要你 Cursor 会话的录屏,他期待 agent(像队友)给 PR 附个视频证明代码是好的、可合并的。

Swyx 把这种现象命名为 "dark factories(暗工厂)",并标出两级"编程精神病":(1) 零人工代码(5 个月前觉得疯,现在正常)→ (2) 下一个前沿是零人工审查——不看就合并。"这是唯一可规模化的路径,需要把软件开发流程整个翻向更多测试/自动验证。数量 → 质量。"

重要免责(Lopopolo 自己反复强调):这一切发生在全新的 greenfield(空地)仓库,不保证能搬到老旧的存量系统(brownfield)。别拿这个去忽悠你公司的祖传屎山。

11. 自己训模型还是用前沿模型?Cursor 的 "agent lab 打法"

Notion 拒绝自己训(§13),但 Cursor 走了相反的路并讲清了"什么时候该自己训"。

Swyx 总结的 "agent lab 打法"(Unsupervised Learning):先用最强的前沿模型起步 → 为你的领域做专门化 → 等积累够多高质量用户工作量,再训自己的小模型省成本/降延迟。他叫这"反转的苦涩教训(reversal of the bitter lesson)"——先靠大通用模型起飞,再蒸馏成小模型跑高频低波动的活。

Cursor 的 Composer 2 实证(Training Data):

  • 把模型权重当成一块有限的"硬盘",把每一个 bit 都分配给唯一一件事——"在 Cursor 里做软件工程",而非泛泛的编程。
  • 专门化 = 它比 Opus 便宜约一个数量级的根因(小而专的模型可以低价服务)。
  • 从开源底座 Kimi 2.5(1 万亿参数 MoE、激活 300 亿)起步,做中段训练 + 强化学习,而非从零预训练——自上而下,为了最快出一个有用的模型。
  • 长任务靠把"压缩/自我总结"放进 RL 训练回路:模型是 20 万上下文窗口,但靠"边总结边重启上下文"能实际跑上百万 token。

Federico(Cursor)的一句很重要的破除迷信——大家以为提示词能解决一切:"Prompt engineering has an upper bound."(提示词工程有天花板。)要做出顶级 AI 产品,必须靠后训练去影响模型行为。Composer 上线时带提示词,但他相信不带也能跑,因为训练已经把它推对了方向。

Why 对绝大多数公司的结论:你大概率不该自己训模型(§13 Notion 给了最强论证)。Cursor 能训,是因为它有"自己的产品当作天然的 RL 环境"("The most powerful environment is your own product." 最强的训练环境就是你自己的产品)+ 几万张 GPU。没这两样,老老实实用前沿模型 + 专心打磨 harness/工具/验证。

12. Monty:给 agent 用的"轻量代码执行" + "100 倍提速判据"

Samuel Colvin(Pydantic 作者)的 Monty 项目,讲清了一个产品经理也该懂的取舍。

它解决什么:agent 经常需要"写段代码算一下"。两种老办法各有毛病——纯工具调用(安全简单但表达力弱)、完整沙箱(强大但要外部基础设施,大金融机构不让用)。Monty 卡在中间:给你"代码模式"的表达力,但不用沙箱(单数微秒级延迟,而起一个沙箱要 ~1 秒)。

对所有人都通用的金句——"LLM 提速 100 倍(而非 3-5 倍)的四个条件"(Colvin 的便携判据):

  1. 内部实现模型很熟(如堆、字节码解释器);
  2. 外部 API 模型很熟(如 Python 语义"刻在它权重/灵魂里");
  3. 单元测试极其好做(对照 CPython 是否一致,能"自己 Ralph 到通过");
  4. API 不需要扯皮(Python 把所有报错/行为都定义死了)。

"If you cover all four of those things, that's why everyone is basically cloning Redis in Rust right now." 译:四条都满足,这就是为什么现在人人都在用 Rust 克隆 Redis。

Why 对你有用:这是判断"哪类工程任务交给 AI 会爆杀(而不是只快一点点)"的速查表——有现成标准答案、测试好写、不用吵规范的活,AI 一夜干完几周的量。反过来,没有客观标准的活,别指望它 100 倍(呼应 §7 的可验证性)。

还有一条类型安全的洞察:Colvin 最强信念——"type safety is important for humans but critical for AIs."(类型安全对人重要,对 AI 是生死攸关。)四个 Anthropic 的人各自独立告诉他:一旦你链式调用工具 / 用代码做工具调用,类型安全就特别要紧——这信号让他判断出 Anthropic 在做"编程式工具调用"(后来果然发了)。

13. 反共识:Notion 的"别什么都上 agent / 别自己训模型"

在一片"agent eats everything"的热潮里,Notion 的 Sarah Sachs & Simon Last(Latent Space)是清醒的反向参照,对产品经理尤其解毒。

"Auto(自动选模型)"才是难而重要的活:要说服用户相信 auto 不是最便宜最蠢的模型,而是最适配任务的那个。Robinhood 类比:auto = 智能投顾 / 指数基金。Notion 不把 auto 当利润机器,只是降焦虑——大多数任务用不上 Opus 级。

她点出一个跟前沿实验室的根本差异:

"It's not replacing people. It's replacing processes." 译:它不是替代人,是替代流程。

以及:Notion"并不是被激励让你烧尽可能多的 token"——很多时候正确的工具就是直接写段代码,根本不需要 agent。(对照前沿实验室靠 token 赚钱的动机,这话分量很重。)

坚决不自己训基座模型(Sachs):"不是我们的核心能力""没钱训基座";而且在自己工具上微调会失败,因为"我们每天都在改工具"——重训节奏根本追不上。Simon:训练是"实现细节",99% 的问题是某个工具里的 bug,修 bug 就行,精力放外层(harness、工具、验证)。唯一值得投训练的是检索/排序——因为现在大部分搜索流量来自 agent 而非人,agent 写查询的方式不同。

Notion 重建 AI agent ~5 次的血泪教训(对做 AI 产品的人是金矿):

  • 核心原则:"Give the models what they want."(把模型想要的喂给它。)别把你自家系统的复杂度暴露给模型。
  • 实例:放弃自家"变态的 JSON"数据库查询格式,换成 SQLite——因为模型对 SQL 很在行;放弃无损 XML 格式,换"Notion 风味 markdown"——因为模型懂 markdown。
  • 从"少样本提示"彻底转向"目标驱动的工具定义",这一步是最大的速度杠杆:之前只有 5-6 个人能碰那条共享提示词(一个"卓越中心"瓶颈),改成工具定义后,工具所有权能分散给各个团队。
  • 100+ 工具带来"渐进披露危机":光打个招呼就烧几千 token,任何人加个冷门工具都可能"把整体模型搞废"。解法:重做 harness,别一次把所有工具甩给 agent,让它自己搜索/筛选工具。

Simon 的一句重锤:"Everything is a coding agent. The coding agents are the kernel of AGI."(一切都是编程 agent;编程 agent 是通往 AGI 的内核。)——这跟开头 Dan Shipper 的"会写软件就会干任何知识工作"同一立场。

14. 比"会写代码"更值钱的东西:领域知识、判断、品味

这是全批播客对非技术个体最大的好消息,几乎人人都讲到。

Cherny(Claude Code 之父)的"印刷机时刻":印刷术前欧洲 ~10% 识字率,之后 50 年出版量超过此前一千年、书价跌 ~100 倍、识字率最终到 ~70%。软件正在被同样地民主化,而且比 50 年快得多。推论:

"The best person to write accounting software is not an engineer, it's a really good accountant. Because coding is the easy part. It's knowing the domain that's the hard part." 译:写财务软件最合适的人不是工程师,是一个真正厉害的会计——因为写代码是简单的部分,懂业务才是难的部分。

Karpathy:人继续掌管品味、判断、审美、规格/设计、监督;agent 像"记性超好的实习生,负责填空",但你得拥有每个决策(比如"这些用户 ID 必须唯一")。

Sarah Sachs 点破工程师自身的身份危机:

"Every software engineer is going through the identity crisis that every manager goes through — their ability to write code is less important than their ability to delegate and context switch." 译:每个软件工程师都在经历每个管理者经历过的身份危机:突然发现自己"会写代码"不如"会委派、会切换上下文"重要。

对你(非技术 PM)的直接含义:

  1. 你的业务/领域深度第一次可以直接变成产品,不再卡在"找不到工程师"。
  2. 但别误读成"零基础也能开发"——你仍需编程思维 + 判断力 + 验收能力(呼应 newtype 老黄的同款警告,见 newtype · AI Coding 实战与工具栈演化 §10)。
  3. AI 写的东西署你的名,你就得对每一条负责。 Dan Shipper 说他常宁愿读你 agent 写的东西也不读你自己写的——前提是"你站得住、你想清楚了";信任来自人真的拥有每一行。

15. 把 Claude Code 当"第二大脑"(非编程用法)

Noah Brier(Alephic 创始人,AI & I)给出一个对知识工作者极有参考价值的范式:他用 Claude Code 的头号用途根本不是写代码,而是当"思考/调研/笔记的第二大脑"——架在他的 Obsidian 笔记库(纯 markdown + 文件夹 + Git 同步)上。

"Probably my number one Claude Code use is using it as a tool to interact with my notes." 译:我对 Claude Code 的头号用途,大概就是拿它跟我的笔记互动。

几个可直接抄的做法:

  • 在整个笔记库的根目录启动 Claude Code(不是某个项目子文件夹),让它能跨 ~1500 篇笔记搜索;用 PARA 笔记法分类。
  • 最爱的"重入"咒语:"Can you catch me up on the last few days of research?"(帮我接上前几天的调研进度。)—— 深度工作最难的是重新进入心流,这句直接点火。配 claude --continue 续上会话。
  • 造一个"思考伙伴"子 agent:专门提示它只负责促进思考、问尖锐问题、不准动手写,并维护一份"已挖到了什么"的运行日志。
  • 一个反复出现的模型坏毛病:哪怕你明说"别写、别产出",模型还是忍不住要产出成品。Brier 用一条强硬的开头指令对抗("不要创建提纲、草稿或任何版本……照字面执行")。他猜这是"乐于助人 + 产物经济学"的偏见被"自我摄入"进了模型。

Brier 的一个深刻 reframe:因为我们叫它"生成式(generative)",大家过度盯它的写能力,严重低估了它的"读"能力——而读才是日常更有用的:"我们产出成品的频率,远低于我们只是在思考事情的频率。"

Why 对你(做 kb 知识库的人)直接相关:这套"Claude Code 架在 markdown 笔记库上当第二大脑"的范式,和你自己的 kb 仓库工作流几乎同构——可作为优化自己 kb 用法的参照(见 Claude Code 工作流(跨作者主题综合))。

16. SaaS 会死吗?护城河重排 + Jevons 悖论

几位都谈到对软件商业的冲击,值得 PM 收着。

Cherny 用 Hamilton Helmer《7 种力量》框架:AI 削弱两种护城河——切换成本(工具间一键搬家)和流程力(Claude 4.7"给个目标就能爬升任何东西");但网络效应、规模经济、独占资源不变。推论:未来十年颠覆性创业公司数量 ~10 倍增长,因为一个小团队现在能造出和大公司一样值钱的东西、正面硬刚。

Swyx 的"编程战争"现状(数字仅为业内估算,口径有争议):Anthropic 单 Claude Code ~25 亿美元 ARR、OpenAI Codex ~20 亿、Cursor 传 ~20 亿。大概率终局 = 两大玩家 + 一长串细分长尾。当前是"能力探索期"而非"效率期"——现在的激励是让你烧更多 token,不是更少;"我们大概还在整体性地少用 AI"。

Karpathy 的 Jevons 悖论(软件版):软件曾经稀缺昂贵,降低门槛会释放更多需求(经典例子:ATM 普及反而让银行网点和柜员更多)。因为代码现在是"易逝、可随时改的(ephemeral)"而非一次性买断的订阅,他谨慎乐观:软件总需求会涨。

对产品决策的提炼:

  • 如果你的产品护城河靠"切换成本"或"流程复杂度"——危险,正在被削。
  • 靠"网络效应/规模/独占资源"——相对安全。
  • "AI vs SaaS" 的真实难点不是"能不能重建"(Swyx 公司花 20 万/年的 SaaS,他估 2 千就能重建),而是"怎么把不那么 AI-native 的团队一起带上来"——公司内部"AI 精神病程度"的落差正在造成真实裂痕。

17. ⚔️ 分歧四:Agent 是不是基础设施的新买家?(产品/增长视角)

对做产品、做营销、做开发者关系的人,这是最该立刻行动的一条。

强共识(Swyx + Vercel CTO Malte Ubel):agent 已经成了基础设施的"买家"。

"If it doesn't exist as an API that agents can use, it doesn't exist." 译:如果它不以一个 agent 能调用的 API 形式存在,那它就等于不存在。

数据:Vercel 的应用管理/配置流量里 ~60% 是机器人,不是人(Notion 的 Sarah Sachs 也说"长期看我们大部分流量会来自 agent 用我们的界面,而非人")。规则:多建 CLI,别只建 UI。

但 Swyx 又把这件事"祛魅"——他认同 Netlify 的 "Agent Experience(智能体体验)" 概念,但强调:

"Everything that you should do for agents is something that you should have done for humans anyway." 译:你为 agent 该做的一切,本来就是你早该为人类做的(好文档、一致且基本无状态的 API、可发现性/渐进披露)。除了"更多 spam、更大量"之外,没什么本质新东西。

关于 AEO/GEO(优化让聊天机器人推荐你):短期有复利红利(Resend 案例:2023 年才创立,现在 Claude 被问邮件服务商时 ~70% 默认推它);但 Swyx 判断 3-4 年后,记忆 + 个性化会比"被提及频率"更决定模型/工具的选择。默认名单会收窄到 ~3 个,不是 20 个。

对你的行动清单:

  1. 把你的产品/文档改成 agent 能 copy-paste 直接用(Karpathy 的反复吐槽:别再写"教人类怎么做"的文档,给"丢给 agent 的那段文本")。
  2. 有 UI 就配 CLI/API。
  3. AEO/GEO 现在做有红利,但别 all-in 押"刷存在感",中长期押"被记住/被个性化选中"。

18. 更远的天花板:AutoResearch、记忆瓶颈、世界模型

几条偏未来、但能帮你判断"接下来什么会来"。

Karpathy 的 AutoResearch(自动研究):把"人退出回路"推到科研。给 agent 一个目标 + 一个可量化指标 + 边界,它整夜自己跑实验。他在自己手调了二十年的 NanoChat 上跑了一夜,它找出了他漏掉的调参(一个被遗忘的权重衰减、没调好的 Adam beta)。他设想一个"研究组织 = 一组定义角色与连接的 markdown 文件"(他叫 ProgramMD),甚至能元优化 ProgramMD 本身。两个前提:(1) 只适用于有便宜、客观指标的事(能验证才能自动研究);(2) 整个栈还在"撑破缝",推太前反而没用。

Swyx:记忆是最大的限制约束:

"Context length is the slowest-scaling factor in LLMs. Memory is probably going to be the biggest limiting constraint." 译:上下文长度是 LLM 里增长最慢的因子;记忆很可能是最大的限制约束。

(上下文从 4k 涨到 1M 花了 ~3 年;Gemini 的 1M 存在两年却很少被用满。)

Swyx 在看的两个下一前沿:(1) 记忆/个性化;(2) 世界模型(world models)——他认为这对"智能本身"重要,不止机器人/游戏。

Karpathy 的"动物 vs 幽灵"心法(帮你建立正确心智模型):

"We're not building animals. We are summoning ghosts." 译:我们不是在造动物(被进化塑造、有内在动机和好奇心),我们是在召唤幽灵(预训练的统计模拟回路 + 强化学习的附肢)。

冲它发火没用;有正确的心智模型,你才更能驾驭它。

19. 反 pattern 速查表(横切全 11 档)

❌ 别这样 ✅ 应该这样 出处
还把 AI 当"聊天机器人" 当成可调度的 agent 舰队(2025/12 起范式已变) Karpathy
把 vibe coding 和 agentic engineering 混为一谈 抬地板 vs 守天花板,招人定级分开 Karpathy
把某类 App 当成要永久做的产品 先问"模型一句话能不能替代",能则造提示词不造 App Karpathy(MenuGen)
用"工时"衡量产出 用"能同时盯几个 agent 不翻车"衡量 Lopopolo / Cherny
死认"Claude Code / Codex 哪个最好" 半年翻盘一次,高波动期别刻进脑子;趁补贴薅 Every / Swyx
做万能 harness + 热插拔模型 模型和外壳紧耦合,在"agent 层"做切换 Angela(Anthropic)
以为难点是 harness/提示词缓存 真墙是基础设施产品化(在线/沙箱/容错) Caitlin(Anthropic)
默认自己训模型 99% 是工具 bug,修 bug;只在检索/排序投训练 Notion
把所有工具一次甩给 agent 渐进披露,让 agent 自己搜工具 Notion(100+ 工具)
用烧 token 的自然语言干确定性任务 让 agent 写段代码一次性算,别反复付 token Sarah Sachs
暴露自家系统复杂度给模型 "把模型想要的喂给它"(SQL/markdown 而非自家怪格式) Simon Last
写"教人类怎么做"的文档 给"丢给 agent 的那段文本";多建 CLI 少只建 UI Karpathy / Swyx
拿 greenfield 的"零人工"经验套祖传屎山 暗工厂打法只验证于空地仓库,存量系统另说 Lopopolo
外包了思考就以为能外包理解 思考可外包,理解不能;你得能验收 Karpathy
冲模型发火、当它是有动机的"动物" 它是"幽灵",建对心智模型才驾驭得动 Karpathy

引用与延伸

横切 11 档播客(全部全文消化,见 frontmatter sources):

  • AI & I by Every — 《Claude Code Can Be Your Second Brain》(Noah Brier)/《Why We Switched From Claude Code to Codex》(Dan Shipper + Austin)/《The Secrets of Claude's Platform》(Angela + Caitlin @ Anthropic)
  • Latent Space — 《Extreme Harness Engineering》(Ryan Lopopolo @ OpenAI Frontier)/《Monty》(Samuel Colvin @ Pydantic)/《Notion's Token Town》(Simon Last + Sarah Sachs @ Notion)
  • No Priors / Training Data — 《Karpathy on Code Agents & AutoResearch》/《Karpathy: From Vibe Coding to Agentic Engineering》/《Boris Cherny: Coding's Printing Press Moment》/《How Cursor Trained Composer》(Federico + Dima)
  • Unsupervised Learning — 《Ep 85: Has AI Infra Stabilized》(Swyx)

配套 wiki:

History

  • 2026-06-05 v1.0 创建 — follow-builders 播客合成,coding-agents 主题桶 11 档全文消化。主题驱动横切(非按集),突出 4 组分歧(Claude Code vs Codex / MCP vs CLI / harness 难不难 / agent 是否基础设施买家)。

2026-09-26 增补：共用执行框架，单独设计审阅与维护者权限

证据范围：Logan Kilpatrick（feed 2026-06-11）与GitHub COO Kyle Daigle（2026-06-17）的本地截断稿，分别只覆盖至07:18、08:01；本节为 partial。下述产品细节是访谈当时的说法。

框架复用解决开发成本，任务差异决定最后一段体验。 Harness（安排模型调用工具、推进任务的执行框架）可以跨产品共用。Logan用“大约80%相同”形容底座复用，同时指出AI Studio编程与常驻个人助手各有优化。这是口头估计，不能把80%设为架构验收指标，也不能只凭节目标题推导“模型必将吃掉全部框架”。

“80% of the same stuff” 译：大约80%的部分相同。

当生成变得容易，瓶颈会移到审阅和贡献治理。Kyle提到GitHub内部法务、财务也在构建小应用；扩大的入口带来更多提交，却不自动增加维护者的处理能力。他描述的链条是先由agent辅助审阅、根据评论修改，再在允许范围内等待CI与政策检查后合并。已经生成代码、审阅通过、允许合并是三个独立状态。

开源又多了一层：公司能约束员工，维护者却未必能控制所有外来提交者。因此平台需要准入、贡献证明与权限等组件，让社区选择自己的规则，不能把一种担保制强推为全部项目的标准。

“really leave them in control.” 译：真正把控制权留给维护者。

给PM的验收问题：共享的是哪些执行能力？哪部分任务需要专门优化？谁能发起、谁能审阅、谁能批准？失败或等待检查时怎么呈现？不要用PR增长代替代码质量：访谈的1700万口径是2026年3月agent创建的PR；全年140亿提交是当时预测，均不是本次核验的业务结果。

2026-09-26 全文增补：设计Agent应支持发散、精修和审阅，而不只是生成

基于Figma Matt Colyer完整访谈00:00—33:52（full_scan）。主持人披露持有Figma股票；未来用户规模和主动agent形态属于观点与计划。

聊天很适合表达第一版意图，却不一定适合并排比较多个方向和精确移动元素。Matt用设计的“发散—收敛”说明画布价值：先保留多个候选，尝试风格、排版与可访问性，再聚类和选择。发散agent应带来不同方向，收敛agent帮助比较，直接操作则让设计师精修。这里仍有未来探索，不能把访谈愿景当已发布功能清单。

内置agent与外部agent可以承担互补路径。 设计系统提供团队组件与规范，外部agent则接入用户既有代码环境。访谈中的往返流程是代码页面→可编辑画布→设计上下文→实现分支与PR截图→人审阅；可评审的实现是终点候选，不是自动合并授权。

“the principles still matter.” 译：设计原则仍然重要。

工作流里最值钱的上下文往往早已存在。其PMOS示例从组织图、Slack与项目工具组合新人入职资料，把经理脑中的隐含关系变成可读取信息；不过“可访问”仍需与任务权限相符，不代表所有数据都可随意取用。

生成量增加后，审阅成了新的瓶颈。截图、录屏或第二个agent都只是候选界面，最终要让人理解改了什么、为什么符合标准、哪些地方仍不确定。软件生成越便宜，持续维护和结果验收可能越重要：嘉宾自建邮件agent后因长期维护成本反而购买更多软件。定时摘要已经能减少主动查看；邮件草拟则仍由用户逐封批准，不能把“主动”与“无须授权”混为一谈。

对设计产品的实用检查是：能否保留探索分支、遵守现有设计系统、做精确修改、显示实现差异，并把生成和批准分开。审美与好奇心帮助用户质疑输出，而不是把第一个看似漂亮的答案当完成。

2026-09-26 全文增补：代码生成提速后，重新测量评审与维护

AI Vibe Check 圆桌讨论了瓶颈迁移：当代码生成更快，团队可能被理解缺口、评审和后续维护拖住。评估应记录从需求到稳定交付的时间与总成本，并比较模型连同工具环境的整体效果，而不只看裸模型分数或代码量。

同一标价下，输出长度、思考量和重试次数也可能改变账单。可以用实际任务比较路由、较小模型和备用服务，并演练容量受限时先降级哪些功能。圆桌关于 API 中断、模型封闭、并购和公司走向的讨论属于情景预测或未经核验说法，不能当作已发生公告。把预测转成可检验的依赖演练，比直接据此迁移系统更稳妥。内容与归因见 圆桌精炼。

全文增补：数据合作的信息边界，与模型和运行环境分别验收（2026-09-26）

按 2026-08-04 本地归档的一期 AI Vibe Check 圆桌，普通 API 调用、领域定制、交付专家样本和共享失败评测，会给供应方提供不同的信息。该讨论包含未经核验的公司事件与政策猜测；本页只保留可用于设计产品的分析问题，不将这些叙述视为新闻事实。

为什么要分清合作深度。 一次调用提供的内容，与完整编辑过程、用户最终接受的版本和专家评测集合不同。评估供应商合作时，应分别说明哪些数据进入服务、允许做什么、哪些领域知识构成自身优势。这个信息结构分析不等于断言任何供应商默认拿客户数据训练，实际约定必须另行核对。

案例：数据价值在新增信息。 访谈说 “we wanna maximize the marginal information gain.”（要最大化每条新增数据带来的信息。）用户的修改、拒绝和稀有失败可以比重复常见成功样本更有价值。嘉宾关于更多数据的判断明确附有同等质量前提；样本数量不能替代覆盖范围和反馈质量。

何时用于模型选型。 分开测试权重能力与工具、权限、循环和评测方式，同一个模型换运行环境后结果也会改变。开放权重不自动说明许可条件、部署适配或安全属性。对假设的供应链隐蔽行为，嘉宾明确说当时没有证据证明发生；不能把风险讨论写成某类模型已有后门的结论。业务选型仍应回到任务正确率、实际成本、许可原文和自身控制要求。

来源：开放模型圆桌原文消化。

来源与关联资料