LLM 实用方法论

各 KOL 关于"如何在日常与专业工作中有效使用 LLM"的观点汇总。

Andrej Karpathy（美，2025-02）

来源：How I use LLMs

• 心智模型先行：把模型当作"半年前通读互联网、只记得大概的 1TB 有损 zip 文件"，据此判断哪些问题可以直接问（高频、非近期、低风险），哪些必须配工具或核对来源。
• 管理 context window：换话题开新对话；context 是工作记忆，无关 token 降低准确率、拖慢速度。
• LLM Council：重要问题问遍多家模型交叉参考。
• 按任务选模型：难题用 RL 思考模型换准确率，日常问题用快模型；留意价位档对应的模型规模。
• 一切输出当第一稿：Deep Research 报告查引用、数据分析读代码、医疗信息核对原件——"初级分析师有点心不在焉"。
• 不独自读书：文献/古书装进 context window 共读。
• 语音优先：他超半数查询用语音输入（"别打字了，用语音，快得多"）。
• few-shot 优于纯描述：自定义提示词给具体示例，"教模型和教人一样，光讲不如给例子"。
• 专业编程用 IDE agent（Cursor 等）而非网页复制粘贴；"vibe coding"（他自认造的词）= 口述需求交给 agent，失败再退回手工。

姚顺宇（中，Google DeepMind，2026-05）：一线研究员的 coding 工作流

来源：张小珺访谈

• 模型写 90% 的代码（"不保守就是 99%–100%"）：人最重要的工作变成设计逻辑、给合理 context（如指一个 reference 文件）、审查代码是否真的合理（00:38:49–00:40:50）。
• 实验/实现 idea 的效率比一年半前提升 20–50 倍：可同时开好几个 idea 并行试，模型还能帮监控实验；但工作时间反而更长、密度更高——"越试越想试"（00:40:50–00:42:50）。
• 遇到看不懂的文件不再去约人、等几小时，"问一下 Gemini，5 秒告诉你结果就接着干"（00:41:50）。
• 判断人是否"靠谱"的面试题：24 小时从 0 到 1 做一个 RL 项目 + 1 小时讨论——考察能否有效利用 AI，以及是否真理解 AI 做了什么（全盘扔给 AI 会在讨论中露馅）（03:31:10–03:33:11）。

Peter Steinberger（美/奥，OpenClaw 作者，2026-02）：agentic engineering 方法论

来源：OpenClaw 访谈

• "Vibe coding 是蔑称"，他做 agentic engineering；agentic 曲线/陷阱：新手短 prompt → 中期过度复杂化（8 agent 编排、18 个 slash 命令）→ 精通后回归短 prompt。全自动 orchestrator = 回到 70 年代瀑布模型，丢掉 style 与 human touch（01:04:56–01:05:57、01:19:29–01:21:32）。
• 对 agent 的共情是核心技能：agent 每个 session 从零开始探索你的代码库，要指路、要"take your time"；世界级程序员骂 LLM，恰因编程太强妨碍其共情一个冷启动的系统（01:05:57–01:07:59、01:17:19–01:18:20）。代码库应为 agent 优化：别跟 agent 起的名字较劲——那是权重里最自然的名字，下次搜索它找的就是它（01:12:04–01:13:09）。
• 工作流细节：并行 4–10 agent；语音输入为主（与 Karpathy "别打字了"一致，他一度说话说到失声）；从不 revert、永远 commit main（"refactor 现在很便宜"）；每个 feature 合并后问"现在有什么可以 refactor 的"、"如果重来你会怎么做"；PR 审核第一问是"你理解这个 PR 的意图吗"而非看实现（01:13:09–01:16:17、01:35:58–01:37:00）。
• 模型手感论：Opus 角色扮演强、动手快偏 trial-and-error（"有点太美国"），Codex 默认读更多代码、可跑 6 小时（"是德国人"）；差异在 post-training 目标而非原始智能，换模型给自己一周适应期；"模型变笨了"多半是你的项目在长 slop（01:39:04–01:47:20）。
• MCP vs CLI/skills：CLI 可组合（接 jq 过滤、写成脚本）、零 context 污染；MCP 返回大 blob 必须整个进 context、需训练适配。skills = "一句话描述 → 按需加载"，与 CLI 天然互补；例外是需要状态的 Playwright（02:38:59–02:42:08）。

Noam Brown（美，OpenAI，2026-06）：日常已可信任

来源：No Priors 访谈

• 已日常用模型做税务建议、买房 paperwork——"某种程度上比信任人类专家还多"；提醒 2022–23 觉得不可信而弃用的人重新评估（00:30:18–00:31:18）。

Agent 时代的用法演进：治理 agent、AX、agent 管理学习曲线（2026-05–07）

• Andrew Feldman（Cerebras）："从 10x 到 100x 但非人人适用"：少数有"完美心智"的人把编码转成治理 agent——同时跑 8–10 个 agent、专设 QA agent、主动补足模型冗长/删注释的弱点；token 花费从 <$1K/人月 到 $25–30K（Cerebras 00:12:05–00:13:05）。为 Steinberger"agentic engineering"补上"多 agent 治理"的具体工作方式。
• Akshat Bubna（Modal）：AX≈DX：给 agent 用的和给人用的体验高度一致（余弦相似度 ~0.9）；建 modal bench 找 agent 做不到的事，agent 反复幻觉某功能就把它做成真 CLI / 加 skill——"agent 幻觉自己的功能"其实是产品反馈（Modal 00:06:08–00:07:10、00:57:42–00:58:42）。与 Steinberger"每个 MCP 做成 CLI 都更好"同频。
• Gavriel Cohen（NanoClaw）：agent 管理有陡峭学习曲线：最大误区是"扔个任务就走开等成品"，必须持续调 instruction/skill/context；个人 agent 的记忆用 LLM Wiki 优于检索（问"这周最该关注什么"没有语义搜索能答），痛点是造重复文件、需背景进程查重（与本库 Lint 同构）（NanoClaw 00:03:04–00:13:09）。

语音口述、loop maxing、prompt 自检、human-in-the-loop 当媒介（2026-07）

• 脚踏板 + Whisper Flow 把 LLM 从"打字"解放成"意识流口述"（Mati / ElevenLabs）：按住踏板给一两分钟 stream of consciousness，"LLM 特别擅长把一大段意识流理成东西"；语音 agent 让人反而更愿打断、对 AI 更坦诚（语音与法律 00:11:09–00:15:14）。为本页"语音优先"补上具体硬件工作流。
• Andrew Feldman 的 prompt 收尾模板：结尾固定加"检查你的工作 + 告诉我我没考虑到什么 + 每次运行都反问我几个问题"——这改变了 trend scouting 等任务的产出；配合"token maxing / loop maxing"（递归：问→学→再问，答案好很多）（Cerebras 与 BFL 00:27:21–00:32:23）。与 Karpathy"把输出当第一稿/查证"、NanoClaw"持续调 instruction"同一实践谱系。
• 生成式模型当"媒介"而非"自动出片"（Robin Rombach / BFL）：与 Scorsese 合作的用法是human-in-the-loop 把脑中画面迭代成图像（"语言是有损媒介、视觉更丰富"）、平行化 brainstorming/storyboard，而非一键生成整部电影（Cerebras 与 BFL 00:46:33–00:50:39）。呼应"人向设计/判断迁移"。
• 写好 verifier 是关键技能（志鹏 / vLLM-Omni）：code with AI 后，"实体 code 会被取代、重心转向写测试/verifier"；学习时"找一个不懂的人（或 agent）用费曼学习法讲懂"（志鹏访谈 00:15:15–00:24:23）。与 Modal"agent 幻觉即产品反馈"、NanoClaw"agent 管理有学习曲线"同属"人机协作方法论"。

中美对照

Karpathy 与姚顺宇都强调"把输出当第一稿/审查代码合理性"，但侧重不同：Karpathy 面向广义用户（心智模型、选模型、语音优先），姚面向前沿研究工作流（模型写 90% 代码、20–50× 实验加速、与 AI 协作能力作为招人标准）。两者共同印证 AI 与就业 里"人向设计、判断、监督迁移"的趋势。

token 治理：成本失控与组织行为学（2026-07）

来源：All-In / IPO、Token ROI 之辩 · All-In / SRO 与数据中心

• 规模的量级：RAMP 称其客户过去一年 token 支出增长 21 倍（不是 21%）。Chamath 自家 token 成本每 45 天翻一倍。
• 病灶是激励错位，不是技术（Jason + Chamath）：工程师不与钱挂钩、CFO 才与钱挂钩；工程师永远想用最新最强的，不会做这个权衡——"就像你订差旅时根本看不到价格，你说'给我商务舱'，差旅部门去处理"。RAMP CEO 的诊断补上另一半：AI 公司实际上给企业开了一个挂账（tab），CFO 很难前瞻地看到谁在花什么，且新模型上线时费率常上调。
• Chamath 自估：98% 的 Fable 5 prompt 其实该跑在便宜模型上。

有效的优化手段（按杠杆排序）

1. harness 的选择——Databricks 的 Ali 发现同一个模型下，harness 不同能省约 2 倍成本；他们用 GLM 5.2 时任务成本直接砍半。这是本批素材里最被低估的一条：harness 可能比模型选择更重要。
2. 对 agent 本身做优化——Jason 对自己的趋势发现 agent 做优化后 token 用量降 80%。
3. 模型路由——DoorDash 的做法是先用内部编码基准确认引入开放权重模型不降低代码质量，再让前沿模型做最难的活、把低层级工作下放（见 评估与基准）。⚠️ 但路由本身是否是好战略存在分歧，见 AI 商业化与价值捕获。创始人一手口径（No Priors 访谈 00:39:25–00:44:28）：6 月支出比 1 月涨约 20 倍（"20x 不是 20%"），靠治理 flatline；年初是"实验、放手让人跑"，现在到"一算 ROI、砍浪费"阶段——目标是"把便宜任务下放开放权重模型，拿到 Fable 级智能却付更少"。增长最快的席位反而在非技术岗（分析师、运营、客户经理的 QBR 自动化）。与 Chamath"98% 的 prompt 该跑便宜模型"、RAMP"21 倍"是同一现象的当事人版本。
4. 观测性——现在可以按小时、按任务、按模型查看 token 用量；RAMP 等已把 token 支出管理做成产品。

成本骤降如何改变使用方式（Jason 的一手记录）

token 成本降 95% 后（经 open router + Bittensor 子网跑 GLM 5.2），他的用法发生质变而非量变：agent 从日跑改成小时跑，再把一个 agent 拆成三个并行做不同事。"早上醒来 14 个任务已经完成，你会想：等一下，这完全是另一回事了。"

⚠️ 尚未解决的技术障碍：Nikesh Arora 提出的"model fungibility / headless"（热插拔最便宜的可用模型）目前做不到——卡在记忆、上下文、历史无法从模型里抽象出来并可移植。这是模型商品化的真实技术门槛。

落地组织形态：agentic pods / forward-deployed engineer

Uber CTO 的做法被本批素材当作范式：99% 工程师用 AI 工具、70%+ 的 PR 来自本地或云端 agent、工程师建了 200 个 agentic skill；关键动作是把工程师派驻进各职能部门（法务、运营、市场、客服、HR、采购），与懂流程的部门负责人共事。要点不是让 HR 的人自己 vibe code，而是"工程师 + 部门的系统架构者"配对去找 ROI——与 Legora 的 forward-deployed lawyer 是同一模式在不同职能的复制。

工具跳跃与 agent 漂移：一个机构的 AI-first 实录（Mark Cuban，2026-07）

来源：Mark Cuban 谈 AI 泡沫 00:15:08–00:18:10

本库此前对 agent 工具的记录多来自作者本人（Peter Steinberger / OpenClaw、Gavriel Cohen / NanoClaw、Anton Osika / Lovable）。Cuban 提供了一份外部使用方的实测交叉验证，包括本库首次出现的负面一手反馈：

• 他的实验设计是取消成本约束以观察上限："我就说，token max it。你们每人每月可以花几千美元，我不在乎，我只在乎收益。"
• 观察到的工具跳跃路径（人们在 OpenClaw、Hermes agent、Claude Co-work、Perplexity Computer 四者间来回）：
• 从 OpenClaw 开始建 → agent 开始坏、开始幻觉，太让人挫败；
• 转 Claude Co-work → "很好，但有点受限"；
• 转 Lovable → 给风投机构建起了内网（"没有哪家风投会花 50 万美元、12 个月去建内网，你就会说算了扔 Notion、Google Sheets 里吧"）。
• agent 漂移是新记录的失效模式："Agent 会腻，会漂移——因为底层大模型在变，它最初被编排的方式和大模型后来变成的样子对不上了。" 结果是要更多人来管这些东西。实践含义：编排不是一次性资产，它会随基座模型演进而衰减，需要持续回归测试（见 评估与 Benchmark）。
• 一个可复现的能力边界：让模型"每周搜一次某人的投资、写报告、发邮件给我"——做不到。它会提议做个 agent，然后给你 JSON 或 slop 代码，"于是你必须会编程才能改对"。
• 缺失的复利机制："它应该从所有报错里学习，然后说'我看到你在这里有问题，前三次尝试都失败了，让我告诉你遇到同样问题的其他人里 97.6% 是怎么解决的'。它连这个都不做。它就说：失败了。"
• 对输出准确性的实用态度（值得记）：一个 prompt 12 分钟生成虚构公司的专利 + 商业计划 + 授权清单——"就算它是错的，那又怎样？历史上写过的每一份商业计划书都是错的。"

品味 > 代码，调试 > 编写（Xaira / Bo Wang，2026-07）

来源：Causal Models Need Causal Data 01:21:26–01:23:31

• "在 agentic AI 时代人人都能写代码了，更重要的是对项目有正确的品味，这样你才不会漫无目的地烧 token。"
• 工作方式的位移，说得比本库此前任何一处都直白："我们过去花大量时间写代码、一点时间调试；现在让 agent 写大部分代码，我们把大部分时间花在调试上。" 他的实验室在专门讨论"怎么发现 AI 犯的错"、"AI 在哪些地方特别好、哪些地方仍然受限"。
• 学生如何培养品味（回应"思考过程都能外包给 LLM 之后怎么办"）：靠学术训练——"进入一个你一无所知的领域，毕业时成为这个题目上世界级的专家"；以及"学一样东西最好的办法就是把它编出来"（因为编的时候才知道论文里省略掉的细节藏在哪）。最后要靠与湿实验、临床团队的协作拿到真实世界的反馈信号来校准品味。
• 这与 志鹏"编程在编两样东西"、Anton Osika"工程不再是瓶颈，问题变成该造什么" 是同一位移的三个独立表述——分别来自中国开源社区、欧洲应用层、北美学术/生物科技。

"MCP 和工具是愚蠢的"：让模型写代码而非编排工具（Eiso Kant / Poolside，2026-07）

来源：Poolside 访谈

这是本页 Steinberger"MCP vs CLI/skills" 之争的一个更激进的模型公司版：

• 强观点："我支持 MCP 也支持 tools，但它们对我毫无道理。"复杂长任务里我们在模型和系统之间塞了一层 MCP/tool call；应该给模型一个装好 binary 的虚拟机 + 一个可操作的 codebase + 一个写 memory 的文件夹，让它自己写代码（含 if/for/条件）去干活——"Laguna S 已经大量这么做，前沿模型也越来越如此"。
• 预测："12 个月内不会再看到塞了 20–40 个工具的 system prompt。" 机制是：RL 训练里"模型想自由"，会用最高效的方式做事，而那不是调 50 个预设工具，是写小脚本（类似 code interpreter 的 EOF 写文件）。
• 对使用者的含义：给 agent 越少的 harness、越大的自由度越好；Poolside 自家 harness 只有约 6 个工具（shell / shell kill / shell wait / write / fetch web / bash）。这与 swyx"榨干单一模型"、NanoClaw/Steinberger 的极简 harness同向：能力越强，越该把编排还给模型自己。
• 但他也承认这仍是"个人 nitpick"——Poolside 依然支持 MCP/tools、这代还首次做了并行 tool calling（"很多人被训在这套上，会长期被支持"）。

拓宽"可能性想象"与 agentic search 的伦理边界（Akshay Nathan / OpenAI，2026-07）

来源：Latent Space 访谈

来自 OpenAI 产品负责人的高级用户建议，其中第一条与本页 Karpathy 的实用方法论 同族但更强调复试：

• 不断拓宽对"可能性"的想象，包括重试你以前试过并放弃的事（[00:37:23]–[00:38:23]）。他给的具体例子是绩效评估周期：半年前试过，完全没用；这一次"模型做得比我好得多"——因为它能拉到代码、评审、Slack 里的全部上下文，指出连他都没看到的成果。"即使你以前试过，继续推进对可能性的想象，大概是我最大的一条建议。"
• 喂得越多，回报越大：artifact 存进 library、跨时间可引用，模型会以你想不到的方式主动调用；"但它必须先有访问那些工具或上下文的权限"（[00:39:23]）。
• ⚠️ 一条明确的伦理边界（本页此前没有的维度）：用 AI 收集上下文做绩效评估是好的，"但我绝不会只用 AI 写出一份东西然后当作对某人的评估交上去"（[00:40:24]）。swyx 把前者归纳为 agentic search——"只是你现在能远比过去更有效地引导和定制它"，他接受这个说法。
• 模型是否会漏掉东西：他的回答很实用——"大概会漏，但我也会漏。"关键不是绝对完备，而是相对于人的基线；swyx 补的正面案例是自己让 Codex 给每个项目写独立 notes 文件、全局那份再从中抽取，"它会随机把四个月前某个项目的笔记拉回上下文，这是我自己绝不会做的"（[00:41:25]）。
• 子 agent 的用法分歧（可与 Poolside"给 agent 越少 harness 越好" 对读）：一派（swyx）无差别地在每个任务上要求用子 agent；另一派指定"这个子任务用子 agent"。给出的两个动机是净时间效率（并行铺开）与成本（把活卸给更小更便宜的模型）（[00:53:30]）。Akshay 的产品侧口径是：ultra / 多 agent 适合极复杂开放探索或高度可并行的任务；goal 模式适合能取得可验证一致进展的任务；但大多数任务两者都不属于，所以先用默认配置（[00:20:11]）。
• Chronicle（从你如何使用计算机中学习的记忆输入源）目前实验性、默认关闭，他建议直接打开试："它多半会发现一些你自己都不知道的东西。"（[00:59:36]–[01:00:37]）

⚠️ "模型不知道这份工作怎么做"：来自垂直部署一线的反预期（Lassie，2026-07）

来源：Lassie 那期（[00:46:33]–[00:48:34]）

本页此前的方法论多来自会用模型的人（Karpathy、Steinberger、swyx）。Frédéric Renken 提供的是把 agent 部署进真实业务后的观察，也是本页目前对模型能力最直接的一条限定：

"模型是在那么多数据上训练的、又那么大，然而它们其实根本不知道怎么干这些活。它们没有以任何形式编码这些工作流。"

• 相当一部分知识编码在办公室主管的脑子里，"很奇怪地在互联网上并不那么容易拿到"。因此他们必须去收集 SOP 与文档（比如"该怎么向某个 payer 提交保险理赔"）。
• ⚠️ 一处坦白的预期落空："我们开始用后来的那些推理模型时，其实假定它们大概就会干这活了，因为——它们为什么不会呢？但结果是它们并不知道大多数工作流的那些细节。"
• 他们的替代路径：从客户 ERP 里的历史数据反推工作流。
• 落到产品上的问题被他明确称为 UX 问题而非模型问题：怎么从人那里拿到"他们过去是怎么干这活的"，并转成能让 agent 变聪明的形式。
• 他个人期待的方向是更小、学得更快、用更少数据就能学的模型，但"感觉我们离那个还非常远"。

与本页其它条目的关系：这条与 Sinofsky"企业里所有有趣的事都是例外处理"同向但更强——不是模型抓不住例外，而是连常规工作流都没学会。而 Lassie 给出的工程解法是 Sinofsky 没给的：不追求 100%，95% 就出货，长尾靠部署后从数千名一线员工的反馈里收（[00:19:12]、[00:21:12]）。

⚠️ 没人回答"这个 trick 什么时候 work"（刘子鸣，中，2026-07）

来源：刘子鸣期（[01:07:15]）

本页收录了大量"某某做法有效"的经验（prompt 模板、子 agent、loop maxing、MCP 之争）。刘子鸣 从 physics of AI 一侧给了一条针对这类知识本身的批评，值得放在本页开头当作阅读提醒：

"我们很多时候会有一些 know-how，就是什么 trick 它 work 了、什么 trick 不 work，其实很多时候是针对这个'相'而言的……我们现在之所以很混乱，是因为所有的人都在说'我的这个 trick work'，但是没有人回答'我的这个 trick 在什么时候 work'、我的系统在什么相里面它才 work。"

• 他把这条接到 no free lunch theorem 上：既然没有一个模型、一个 trick 能在所有数据集所有任务上都更好，那么理清每个 trick、每个架构的适用条件才是做科学的态度，"而不是说你做出来一个东西，就在那里去卖'我们这个东西好'，全然忽视掉了它好是有一些适用条件的"。
• 方法论来源是扫相图（phase diagram）：同样是 H₂O，不同压强温度有不同的相；他称 AI 里"不管是训练动力学还是什么，也有非常多的相"。
• ⚠️ 对本页的实际含义：本页多数条目都是未标注适用条件的经验。引用时应尽量带上出处场景（谁、什么任务、什么模型、什么时间），而不是当作普适规则。

⚠️ 会变的东西不能烧进权重：微调与上下文的分工判据（Decagon，2026-07）

来源：a16z / Decagon

本页此前的 agent 实践多在怎么用这一层。Decagon 那期 给了一条该把知识放在哪一层的工程判据（[00:17:10]–[00:18:11]）：

"我不是在为行为做微调，我是在教 AI 我自己的流程。而那件事不是通过微调发生的，是在上下文里发生的——因为如果你把它微调进去，每次你改流程都得把它逆转回来，这说不通。"

判据一句话：变化频率决定层级——稳定的行为特征（如"怎么选客服话题"）值得烧进权重；会随业务变的流程必须留在上下文里。

配套的第二条区分（[00:16:08]）：微调是为"用例"定制，不是为"客户"定制——"我们做的绝大多数微调是为了客服这个用例。对我们值得，因为我们只干这个；但如果你是那家企业，值得把宝贵的研究资源拿去调一个客服行为的模型吗？大概率不值得。"

这与本页 Dan Biderman 的记忆/cartridges 是同一问题的两侧：Biderman 问的是上下文放不下怎么办，Decagon 问的是什么该进上下文。

⚠️ 模型具体变好在哪：指令跟随的宽度（Decagon，2026-07）

本页反复出现"模型变好了"这类判断，但很少有人说清变好在什么维度上、对产品意味着什么。Decagon 给了一条很具体的（[00:49:29]–[00:50:31]）：

"具体来说就是跟随指令的能力。 几年前的模型你得给非常非常紧的指引、非常具体、不许偏离。随着模型变聪明，你可以给越来越宽、越来越大的指引，并且信任模型有足够的判断力像人一样去解读、把缺的空白填上。"

落到用例上的判据：客服可以走一条很紧的路径就够了；销售资格判定要问开放式探索问题、对话会来回摆动，所以需要模型自己填合理的东西。 这正是他们从客服扩展到"AI concierge"的前提。

相关的一条能力证词（[00:32:16]，关于他们的 Duet agent——一个负责写流程、写测试、监控对话的第二个 agent）：

"我们刚创业的时候这是不可能的。只有当所有推理模型都变好之后才变得可能。" "很清楚，这些模型没有在我们这个特定任务上被训练过——就是写这些流程、写这些测试——但它们仍然做得很好。"

⚠️ 与本页 Lassie 的"模型不知道这份工作怎么做" 构成张力：同为垂直 agent 公司，一家说模型没编码行业工作流知识，一家说模型在没见过的元任务上泛化得很好。⚠️ 本库并列不裁决，但注意两者任务性质不同——Lassie 说的是"保险理赔单该怎么填"这类行业知识；Decagon 说的是"读一堆转录稿、写出操作流程和测试"这类元任务。 这个区分本身可能就是答案的一半。

一手实践：给自己造一个"越过肩膀看"的上下文 agent（Decagon，2026-07）

（[01:06:37]–[01:08:38]）本页此前的个人实践多是编码/搜索/口述。这条是决策场景的：

"模型已经很聪明了，我们俩经常用它头脑风暴，因为它们真的很会出好点子。然而我意识到，至少对我做的很多工作来说，瓶颈是业务上下文——每个想法背后有大量上下文：我们的约束是什么、我们要达成的目标是什么，这些东西每次都很难重新解释给 agent 听。"

他的做法：造一个 agent"一直越过我的肩膀看着，不断编译上下文——我们招了哪些人、还要招哪些人、在谈哪些单子、现在有哪些问题和挑战"。

用法举例（这是价值所在）：问"我们在考虑招这个新人，你怎么看"，它能自己推理出"我们之前有两个非常相似的候选人，他们有这些短板。如果招这个人，会是又一个有完全一样问题的人，所以我们需要互补的人"。

他的自陈动机："我的工作就是在大量上下文下做决策。如果我能把这件事越来越多地外包给模型，也许我能更快地把自己弄失业。"

⚠️ 另记一条模型行为的变化（[01:08:38]）："过去它们就是一堆马屁精，你说什么它都说'好主意'。现在它们会说'不，那是个坏主意，别那么干'。" 但有代价——他把一个"跟我唱反调、非常直接"的 prompt 推荐给太太，"一天后她说：哇 Claude 一整天都对我特别刻薄，我只好关掉了"。同一个配置在不同使用者手上效用相反，值得记入本页的个性化一侧。

token 治理的新机制：产品默认全量监听（Jason Calacanis，2026-07）

来源：All-In 2026-07-31

本页 token 治理 一节记录的失控机制都是人用得多（RAMP 21 倍、DoorDash 20 倍、Chamath 45 天翻倍）。2026-07-31 有一个机制不同的样本（[00:27:20]）：

"我们装了 Slack 里的模型集成……它会持续监听你放进去的每一个频道的 Slack。突然我们上周多了 1000 美元的额外账单，我不知道会这样。他们给每个人两三千块让你在公司里打开它。它监听每一条进来的消息、放进它的数据库，基本上不告诉你，然后开始未经许可地插进讨论里。"

处置：关掉，改成必须 @ 才叫得动。

⚠️ 为什么值得单独记：这不是"员工用得多"，是产品的默认行为就是全量摄入，且厂商用补贴推动开启。治理手段因此也不同——不是路由或用量看板，而是把被动触发改成显式调用。这条同时与本页 Mark Cuban 的 agent 漂移 相关：默认监听的 agent 会在没人要求的情况下改变自己的行为边界。

"一个 markdown 文件就是一名员工"：YC CEO 的 skillify 循环（Garry Tan，2026-08）

来源：a16z / Garry Tan

来自 Garry Tan 在 a16z 那期。本页此前关于个人 agent 的材料来自工具作者（Peter Steinberger）与部署方（Gavriel Cohen）；这是第一次由 YC CEO 从"这该成为组织默认形态"的角度表述。

循环本身

（[00:23:07]–[00:24:08]）做一次"力量展示"式的难任务 → 把过程变成 markdown + 代码 + 测试 → 放进 cron job。他的定性：

"一个 markdown 文件就是一名员工——而且是一名每次都把活干得完美、你要它干多少次就干多少次的员工。"

• 第一次一定很烂而且很贵。关键是能不能很快、很简单地说"agent，这儿错了，改掉"——那条修改轨迹会被沉淀成 skill 文件，"以后再出错就只是修个 bug，然后它就永远在那儿了"。
• 适用范围：主持人逐个点名销售、市场、客服，他的回答是"是的，一切"。
• 他自己的实践链条（[00:16:06]–[00:22:07]）：G stack / G brain（工程侧 QA loop 与 PM 自动化）→ Garyslist.org（自称 agentic newsroom，为写文章造了个人深度研究的 RAG）→ 抽出其中的 agentic RAG 图生成部分做成 Soda。他对 Soda 的功能定性值得单记："它让 agent 知道，对某个特定任务，该在脑子里留住哪一百万个 token。"
• ⚠️ 专名照录未核实：G stack、G brain、Soda、Memory Palace、Hermes Agent。

⚠️ 规模上限落在数据治理，不落在模型

被追问"这套递归自我改进什么时候崩、误差会不会累积"时（[00:26:08]），他的答案没有谈模型能力，而是谈数据：

• markdown 一多就是 provenance（来源溯源）问题和冲突管理问题——"有两条事实时，有溯源你就能说这条更近、这条赢"；
• 需要一个 cron job 定期扫过去，确保东西是准的、来自对的地方。

⚠️ 本库认为这条应与 Kavak 的"自我改进的组织" 互相引用：Kavak 提出了组织层的 RSI 主张但没给治理机制，Garry 的 provenance + cron 扫描是那个主张在数据层的具体化。

token maxing：用钱买两年时间差

（[00:22:07]–[00:23:07]）这是本页此前没有的一条成本-能力换算：

• 机制：ChatGPT / Claude 这类前沿产品"在算力上仍然相当受限"——不是模型不行，是厂商愿意给单次请求的算力有限。要"token max"就得用 OpenClaw / Hermes Agent 这类自托管 harness，一路调到满，让单请求装进 80 万到 100 万 token，并把这些写进 soul.md。
• 价码：一年五万到十万美元把 agent 开到全强度——"对一个 CEO 或创始人来说这非常划算。你得允许自己这样烧 token。"
• 收益的说法："你会活在 2028 年。"

⚠️ 全部为自述，无用量凭证。但机制陈述本身可证伪（"前沿产品对单请求限算力"），值得跟踪。

与本页其它条目的关系

• 与 Peter Steinberger 的 OpenClaw：Garry 说是 Brex 的 Pedro 把他带进 OpenClaw 的，且他点名 Peter 是"35–45 岁创始人"趋势的完美例子。
• ⚠️ 与 Kavak 的架构选择的正面分歧：Kavak 用有硬目标的长期 agent、明确反对流程式多 agent；Garry 的 skillify + cron 恰恰是流程沉淀的那一侧。两条在同一频道相隔两天出现，本库并列不裁决。
• 一个组织内使用的实例：Brex 的 Pedro 让 agent 读所有直属下属的会议纪要，看两层以下哪里坏了、谁和谁在冲突；先决条件是他开源了一个监视 agent 全部网络流量和动作的层（转录稿写作 Craptrack，⚠️ 拼写未核实），理由是"Brex 是监管最严的金融科技之一"（[00:29:10]）。⚠️ 这与本页末尾"默认全量摄入的 Slack 集成"那条属于同一治理问题的两种答案：一种是把被动触发改成显式调用，另一种是给 agent 加一个全流量审计层。

⚠️ "过程没有捷径，捷径在工具里"：用 AI 学习的边界（Chess.com，2026-08-13）

来源：No Priors / Chess.com

Erik Allebest 在 No Priors 那期。本页此前的材料几乎全是"怎么用 AI 干活"，这是第一条系统讲"怎么用 AI 学东西、以及它学不动什么"的。 收录它的理由是提出者手上有一份罕见的凭据：Chess.com 记录着数亿人在每个水平段犯错与进步的完整轨迹。

能加速的那一侧

• ⚠️ 他的回答是"我们已经在看到了"（[00:22:22]–[00:23:22]）：被问"给今天一个有天赋的 10 岁小孩配上工具，到 ELO 2000 能快多少"，他给的观察是棋手越来越年轻，七岁的孩子能让特级大师吃力。
• AI 作为学习工具的定位（[00:26:23]）："就像走进一位教授的办公室开始提问，只不过它随时在你口袋里"——可以深潜一个主题、接触想法、打磨想法，"以惊人的速度学习和训练"。
• ⚠️ 他自己列的问题清单，本库照录不收窄：有偏见、会告诉你你想听的话、过度膨胀你的自尊。前提是"对于用得好的人"。
• 一个具体的家庭样本（[00:23:22]）：他 18 岁的儿子靠 YouTube 和 AI 工具自学成为电子游戏创作者；⚠️ 一处很具体的分工——"他在创作那一侧不用 AI，但他用它做研究、找解决问题的办法。"

⚠️ 不能加速的那一侧（本节主体）

• 提问很关键（Sarah Guo，[00:24:22]）："如果人人都有这种信息获取能力，为什么我们不是一样擅长下棋？"
• 答案："你得做重复，把它装进你的脑子里。"
• ⚠️ 拿着那份数据集给出的专长获取结论是反高潮的（[00:26:23]–[00:27:24]）："幸运也不幸的是，答案其实相当简单——就是小积木的重复。" 做战术题、复盘自己的错误、练开局。
• ⚠️ 本页最该被引用的一句："过程真的没有捷径。捷径在工具里。"
• 他的神经网络类比，以及类比的断点（[00:27:24]–[00:28:25]）："和你训练一个神经网络是一样的——你喂它一堆数据。当然它能并行训练，能同时在所有这些记忆通道上训练；我们的大脑不完全那样工作，我们必须把重复放进去。"
• 配套的心法（[00:25:22]）："把你人生中任何一天乘以一千，那大概就是你人生的样子。"——每天 5 道战术题乘一千就是 5000 道。"真正复利的不是你某一天做的那件事，而是你的习惯。"

与本页其它条目的关系

• ⚠️ 与 Garry Tan 的 skillify 是同一命题的两侧：skillify 讲把技能沉淀成 markdown 交给 agent 反复执行（捷径在工具里那一侧）；这条讲人脑侧的重复无法被外包或并行化。合起来是一条对本页有用的划分：能被工具吸收的重复会被吸收，剩下的那部分正好定义了"人还需要练什么"。
• ⚠️ 与本页"AI 让人停止思考"的既有担忧：他自己也引述过"有研究显示某些领域使用 AI 的人会停止动脑"（[00:24:22]，⚠️ 未给出处，本库未核实），并把结论落在"必须设置护栏"。这与他在同一期讲的"神经网络反而拓宽了棋手的策略空间"方向相反——同一位受访者身上并存的两条，本库并列记录，见 AI 与就业。

⚠️ "AI 太快，反而把人弄得极为疲惫"（曾鸣，2026-09-03）

来源：张小珺 / 曾鸣

曾鸣 在 张小珺第 153 期（[02:28:29]–[02:29:30]）。

"因为 AI 的工具如此高效率，把你自己弄得极为疲惫——因为你根本跟不上它的处理速度。"

• 他说 2026 年上半年大部分人都有了这个体感，而现在"大家都开始反应过来要有一些隔绝，然后怎么找到作为一个生物的人的一个合理的节奏，再去跟 AI 找一个新的平衡"。
• ⚠️ 为什么本页要记这条：本页此前的材料几乎都在讲怎么把 AI 用得更满（token maxing、skillify、harness 配置）。这是第一条指出"用满"本身有人侧代价的表述，而且出自一个把 AI 当主要信息输入方式的人——他自述日常就是"跟创业者聊 + 看最新资讯与访谈"，"我有很多的信息的输入可以做数据训练"（[02:28:29]）。
• 本库标注：这条与 Garry Tan 的 token maxing 不构成反驳——一个讲买到能力提前量的代价是钱，一个讲跟上机器节奏的代价是人。并列记录。

⚠️ "模型 + harness"：coding agent 何时变得真正可用（Satya Nadella，2026-09-15）

来源：All-In / Satya Nadella

Satya Nadella 在 All-In 那期（[00:12:11]）。

• ⚠️ 他给出的产品史判据非常具体：coding agent 是在发现"可以让 agent loop 接上文件系统"之后，才真正可用的——"那个突破才让 coding agent 跑起来"。

  "是模型加上 harness，才让我们做成一些事，进而带来广泛采用。"

• 他把这条接回 ChatGPT 时刻："对我来说那是最后那一步 RLHF，它让对话成为可能。" 也就是说，两次广泛采用的转折点都不是模型能力本身，而是让能力可被普通人使用的那一层。
• 往前看：有了 Astra / CUA（⚠️ 转录含混，见视频页）这类 computer use，也许能做完全自动化的长轨迹任务。
• ⚠️ 本页标注：本页既有的 harness wars 与 token maxing 关心的是个人怎么把 harness 调到最满；这一条给的是同一个词的产业史含义——harness 不是使用技巧，而是决定一项能力能否扩散的产品形态。
• 一条配套的企业侧要求（[00:13:12]）：他要外置于模型的 harness，理由是"我的记忆不该绑死在某一个模型上"——⚠️ 这把"harness 选择"从效率问题提升为数据归属问题，见 AI 商业化与价值捕获。

⚠️ "以前要做伟大的事需要知道两件事，现在只需要知道一件"（苏廷浩，2026-08-19）

来源：张小珺 / 苏廷浩

17 岁的 苏廷浩 在快问快答里自选的"必须知道的知识点"（视频页，[00:47:26]、[01:01:29]）：

以前你想做一件伟大的事情，你得知道两件事：伟大的事情长什么样，以及伟大的事情怎么做。现在有了 AI，只需要知道它长什么样，让 AI 去做。

• 他给的例子：以前想做个小游戏得看视频、查资料；现在跟 AI 说一个大概的、脑子里想出来的东西，它就可以帮你做。
• ⚠️ 他自己对代价是矛盾的："虽然把很大的乐趣去掉了，但还是省了很多时间，所以我也不知道具体是好坏。"
• ⚠️ 他对 AI 之于自己 ICML 论文的定位毫不含糊（[00:34:24]）："要是我没有 ChatGPT，我是写不出论文的。" 他问的包括怎么投稿、具体怎么回复 reviewer、怎么控制训练时间。落点是——"要是你有动力的话，用 AI 能走出很长的一段路。"
• ⚠️ 他对"省时间"的观察与成年从业者一致（[00:48:26]）："虽然省出了很多时间，但这几天跟一些业界的人聊，他们也觉得现在反而更忙了，因为能做出更多东西。" 配套的一条是 FOMO——"现在要是你不是用最领先的 AI 模型的话，会感觉有点浪费时间、浪费精力。"

⚠️ "把 PDF 丢进模型拿证明策略，比读引言快得多"（OpenAI 数学团队，2026-09-08）

来源：a16z / OpenAI 的两位数学家

两位 OpenAI 数学家 给了两条极具体的专业用法（视频页）。

• 文献定位（[00:03:02]）：其中一位把一个 Erdős 网站上标着 open 的问题丢进 GPT-5，五分钟后它找到了文献——而他和几个朋友已经为此花了几小时，还不确定问题是否够得着。他们随后又找到十来个类似案例。
• ⚠️ 吸收文献（[00:57:55]–[00:58:56]）：翻 arXiv 时想搞懂某个证明，读引言当然可以，但实际上把 PDF 丢进自己最喜欢的模型、让它给出大致的证明策略要快得多。他补了一句限定："现在还是有点来回折腾，但对我来说，有模型理解一段数学比没有模型快得多得多。"
• ⚠️ 由此推出的那条乐观论证：模型当然会让我们产出指数级更多的数学，但它们也让吸收这些数学容易得多——"所以它反正在解决它自己制造的那个问题"。
• 访问门槛的变化（[01:03:56]）："如果你在做某件需要一点数学的事，你突然不需要去找到这个题目的世界级专家才能把它用进自己的工作。"

⚠️ 任务规约的成本："告诉它怎么做"与"给一个模糊的 spec"差多少（徐天音，2026-08-22）

来源：月球大叔 / 徐天音

徐天音 的表述（视频页）：

• 能力不是瓶颈（[00:58:50]）："基本上任何系统任务，如果你告诉 AI 怎么做这个任务，AI 基本都能做。所以'AI 能不能做'不是问题——关键问题是你怎么去做，以及成本是多少。"
• ⚠️ 规约质量直接换成成本（[01:00:51]）："如果你只给它一个非常模糊的定义或 spec，它其实也能做，但可能需要很多轮迭代，代价会很高。"
• 人的角色（[00:59:50]）："AI 就像一个很聪明的人。假设你公司有极多的人、个个都很勤奋，你仍然需要告诉他们什么才是对的事。" 落到操作上就是给初级工程师示范什么叫好的工作——怎么权衡 trade-off、怎么拆解任务再一步步推进，然后让 AI 做重复性的部分。

⚠️ 与本页既有的 Chess.com"过程没有捷径，捷径在工具里" 并读：那条讲的是学习没有捷径，这条讲的是委派没有捷径——你省不掉"把任务想清楚"这一步，只能选择在前期付还是在迭代里付。

---

⚠️ harness 本身值 2 倍成本：一条本页此前缺失的实操量化（Ali Ghodsi，2026-09-18）

来源：a16z 2026-09-18

⚠️ 本页此前讨论过 harness 的选择，但没有量化过它的代价（[00:54:20]–[00:55:21]）："同一个模型、同一个版本，换 harness，实际成本差了将近 2 倍。" Databricks 因此自建 Omniagent 在不同 harness 间多路复用。

他们那套成本控制的完整做法（可直接照抄的清单）： - 在网关层加预算约束：按人、按组给警告（"你的预算还剩这么多、你快到上限了"）。 - 做分析以精确预测成本走向。 - 智能路由：接近预算或问题简单时自动挑更便宜的模型。 - 多路复用 harness。 - ⚠️ 结果："token 持续上涨，但成本基本持平。"

⚠️ 浮现出来的模型分工模式

• Ghodsi 的版本（[00:56:21]–[00:57:21]）：expert 模式——小而便宜的开源模型调用大模型，或反之，或让它们互相乒乓；⚠️ "我们会走到一个不再对所有事都用最聪明模型的世界——而那恰是过去两年的范式。" 他还给了一条具体观察："人们发现 pi 作为 harness 相当高效。"
• 主持人的版本（[00:57:21]）：⚠️ 用 Fable / Astra 做架构设计 → 用便宜模型做实现 → 再用 Fable / Astra 做审计（audit）。
• ⚠️ 他对浪费的直接批评（[00:56:21]）："人们真的会用自己的 harness 去重命名文件——你为此付的是高出几个数量级的钱。至少那个你自己敲一下吧，别让模型花五分钟转着圈给你改个文件名。"

⚠️ 为什么企业里 agent 还没落地：不是模型不够聪明（Ali Ghodsi，2026-09-18）

来源：a16z 2026-09-18

• ⚠️ 他的举手调查（本页最该引用的一条现状观察）（[00:38:13]–[00:39:13]）：从去年 Q3、Q4 起几乎一直有人说"AI 比我周围大多数人更聪明"；但问"你们当中有多少人在管理成百上千个组成蜂群、互相谈判、把生活全自动化的 agent，举手"——几乎没有人举手。 大多数企业就是 Microsoft Copilot；⚠️ "他们在用 chatbot 问问题，那基本上是一个非常美化、非常高效的旧日 Google 搜索。"
• ⚠️ 诊断（[00:40:13]）："模型已经足够聪明了，它们缺的是组织内部的 context"——没参加过每一场会、不知道流程、不知道"谁能真正把事办成"。
• ⚠️ 他的 Google 索引类比解释了"为什么现在的 agent 慢"（[00:46:16]–[00:48:17]）：今天的 agent（Claude Code、Codex、pi、open code 等）是一个 agentic 循环——能推理，但要一个一个地去查每个资源（一个个 MCP server），再综合。反事实：如果 Google 25 年前这么做搜索，那就是每次极贵、要等十分钟、而且质量差（只看了极小的子集）。 ⚠️ "他们怎么做的？他们有索引……我们需要为 AI 做同一件事。" 而这比 PageRank 难在权限、隐私与访问控制、以及对象类型远不止网页一种。
• 落地第一步就卡住很多组织（[00:44:16]）：⚠️ 每场会都要转录、全部数字内容都要喂进去——"而法务团队会说：不要录每一通电话。"
• ⚠️ 他自己公司的使用形态很具体（[00:49:17]–[00:51:18]）：组织是树结构，信息沿树上下流动（上报 → 拍板 → 往下渗透），而"如果你有 ontology，这里很大一部分现在可以由 AI 来做"；因为会议里发生的事就是某个聪明人用 Excel 做分析、做一份带图的 PPT。现场观察：⚠️ "只要有人说了什么复杂的东西，你就看到所有人低头看手机（去问 Genie）。" 现在他们的说法就是 "someone just Genie this"。
• ⚠️ eval 是自己训模型的真正拦路石（[01:00:22]–[01:01:22]）：他们在产品里自动生成 eval 并放在最显眼处，"但人们不想用；挪到后台做成可选的，然后他们就再也不去了"——类比 TDD："所有人都说那是对的方式，但实践中没人做。"

⚠️ agent 成为新的产品用户：Neon / Lakebase 的方法论（2026-09-18）

来源：a16z 2026-09-18

⚠️ 本页此前记录的都是"人怎么用 LLM"，这条记录的是"产品怎么被 agent 用"（[01:03:23]–[01:05:24]）：

• 起点是一个中立第三方的测试结果（[01:02:22]，主持人转述）：Lakebase / Neon 成了 agent 首选的 Postgres 数据库——"一年前我大概猜不到"。
• ⚠️ Ghodsi 的归因：他们执着的不是赢数据库战争，而是 "我们怎样成为对 agent 最好的那个"。具体做法：
• agent 要做实验、临时建库，所以库必须起得极快——"他们的执念是一切都要远小于一秒"；
• ⚠️ "你能在不到一秒内克隆一个巨大的数据库"；
• ⚠️ 杀手特性是 branching——同一个库上可以有很多很多分支，而且做得极轻量；
• ⚠️ 定价也是产品的一部分："agent 只是在造点软件、做实验，你不希望成本飙上去。"
• ⚠️ 他把这归入一个更大的模式（本页可迁移的一条）："我们在别的地方也看到过——UV、ripgrep，基本上是把一堆 Unix 工具重新实现成极快、极轻、而且对 agent 是 failsafe 的。他们只是把这件事做到了一个更难的问题上：数据库。"
• ⚠️ 新的 persona：数据库行业过去的执念是怎么帮 DBA、怎么帮应用开发者，而他们改成了怎么帮 agent。 结果（自述）："现在 Neon 和 Lakebase 上创建的数据库里，超过 90% 是 agent 创建的，不是人。"

DHH（美/丹，Rails 作者，2026-08）：三阶段划分、不要过度指定、16 线程

来源：Lex #501 / DHH

本页此前的方法论样本多来自 agent 原生的人（OpenClaw 作者、一线研究员、创业公司）。DHH 是二十年手工代码手艺人的转向样本，而且他给出了带日期的阶段划分。

• 三个阶段（[00:06:10]–[00:11:15]）：前 agentic 期（autocomplete / chatbot，"没有重写游戏规则"）→ 第一个 agentic 时刻（2025-11-24 Opus 4.5 起至 2026-02 底），关键不是原始智能而是 harness（用工具、检查自己的工作）→ 第二阶段（2026 早春） sub-agent 把耗时降到 1/5–1/10，但人必须在驾驶座 → 第三阶段（2026 夏）："我不再告诉它去哪儿，我告诉它我有什么问题"。
• 不要过度指定（[00:55:39]–[00:58:46]）：
• ⚠️ 他引 Boris：Opus 5 发布的 system prompt 比上一代缩小约 80%，因为 agent 不但不需要那么多人类指令，还会被过度指定的指令损害；类比"pointy-haired boss 进屋教你写码，你就赌气写更差的代码"。
• 这正是 agile 在 1990s 末的结论："没人在拿到东西之前知道自己想要什么"——所以"尽可能含糊地先把东西变出来，然后去用它"。
• 人类真正擅长的是 differential evaluation：给三个选项一瞬间能挑，给 22 个就崩（[00:59:48]）。
• Lex 的配套做法：10–20 分钟（有时一小时）的意识流语音长 prompt（Plaud 录音 + ElevenLabs 转写 + 带词典与代码库感知的清洗），理由正是"不会过度指定"；他还总结出"战略性地用模糊，像写诗不像对机器说话"（[02:17:41]、[04:03:22]）。
• ⚠️ 但仍需要一句人类反馈："make it simpler"（[02:14:38]）：agent 做完、另一个 agent 审完都说 OK，他说一句"看着有点复杂"，agent 就回"你说得对"并砍掉一半。他的工作方式类比 da Vinci 的工作室——给比例与形状的反馈，不再亲手雕刻（[02:15:39]）。
• 代码之美的回报在衰减，但带一个会过期的限定（[01:00:48]–[01:02:51]）：二十年来值得雕琢的理由是"架构连贯 ⇒ 小团队能便宜地演进"，而那个论证的前提是由人来改。⚠️ 现在还值得的唯一理由是 token 稀缺——为 agent 写不必重学全部上下文的系统仍有回报，否则就是 ball of mud（第一个 PR 中等，叠五个就不行）。
• 工具链（[01:34:34]–[01:40:42]）：终端优先（不用 app 版 harness）→ tmux → Herdr（tmux + agent 完成通知）；Neovim 退化成项目浏览器与 diff 入口，但他仍要看改动周边的上下文而不只是 diff。
• 并行度的饱和点（[01:36:35]–[01:38:39]）：KVM 盒子 + Tailscale 把闲置 mini PC 全接上，4–5 台机器 × 约 3 agent ≈ 16 线程就是他个人处理能力上限；产出从手写时的 20–30 行/小时到数百行/小时——⚠️ 他随即说"lines of code 是个蠢指标"，并认可社区对晒行数的嘲讽。
• 两个模型互审是标准作业流程（[02:38:35]）：Opus 或 Fable 做活 → 一律用 Codex xHigh 复审 → 推 GitHub 后 Copilot 再查一遍。理由平平无奇："让优秀同行 review 当然更好，所以把它做进流程。"Lex 的变体是 Fable 做计划与审查、Opus 5 做实现，这样不容易把 token 用光（[02:37:33]）。
• ⚠️ 语音 vs 打字这组对照新增一笔：DHH 全程打字，"我就是喜欢打字"（[02:16:39]）；Steinberger 恰好相反（以语音为主，"这双手太金贵了"）。本库两个最接近的样本在这一项上完全相反。
• 协作形态：从 chat 到异步工单（[02:42:45]–[02:43:46]）：37signals 把 agent 放进 Basecamp 当同事派 to-do，发现为异步沟通优化的协作工具比 chat 更合适——chat 诱使你坐着等。下一步是 Omarchy bot 定时自主处理 PR/issue，每天发一封邮件让他裁决；"human in the loop 现在就是上限"。
• 他对 burnout 的判断（[02:45:49]–[02:47:55]）：当前节奏"完全不可持续"，但需要持续盯 agent 的这个时刻会过去——"所有人都在造自己的那套 agent 协调器，这事当然会被解决"（类比 JavaScript 框架每五分钟出一个的年代）。

⚠️ 一条与"程序员更有优势"相反的限定（同期）

• 有些问题上程序员比非程序员更差（[00:52:35]–[00:53:36]）：因为"软件就是产品管理"（做什么、给谁、什么优先、v1 包含什么），而这类能力在程序员中分布极不均匀。他甚至说第一个 agentic 时刻里"知道得多"一度是减分项——他照自己的方式指挥 agent，而下一阶段允许任何人描述结果并拿到比程序员规定路径更好的方案（[00:51:33]）。
• 但限定的另一半（[00:16:29]–[00:17:29]）：要在已有的大型代码库上 vibe code，你得是程序员。Basecamp 5 的一手教训：让设计师直接 vibe 出大量 PR，单看每个都勉强说得过去，合起来摧毁了架构，最后人工清理。他同时反击"vibe coder 产 slop"的说法："看过普通程序员的产出吗？那也是 slop。"

企业侧：按团队/仓库/个人建 "brain"，纠正必须写回（Coinbase，2026-09-10）

来源：No Priors / Brian Armstrong

本页此前的"上下文工程"材料多是个人侧（CLAUDE.md、skillify 循环、给自己造上下文 agent）。这条是企业侧、带强制流程的版本，而且他自己把它叫 recursive self-improvement（本库在 ai-for-ai-and-auto-research 里单列并与实验室侧 RSI 区分）。

• 分层（[00:12:04]）：公司一个 brain，每个团队一个、每个服务/仓库一个、每个人一个。⚠️ 并附一条治理设计：个人 brain 离职可带走，政策在定。
• 内容（[00:13:04]）：该服务的全部历史事故、必须执行的财务管控、每一个 A/B 测试、完整的 PR 接受/拒绝历史。⚠️ "今天它就是 markdown 文件。"
• 与普通 context 工程的区别就在这一步（[00:13:04]–[00:14:05]）：人类 review 发现 agent 漏了东西时，不许手改了就发，必须把纠正的上下文写回 brain——"不只修这一次，而是修之后所有次"。⚠️ 他给的可观测指标是一次成功（one-shot）的 PR 接受率随时间上升（未给数字）。
• harness 侧（[00:14:05]）：内部 harness 叫 Toshi，把"改 PR 时顺手编辑 brain"做进流程；并可通过 x402 协议直接付费调用外部供应商（本页第一条"harness 自己能付钱"的记录）。
• ⚠️ 非工程背景的人也在直接发功能（一手）（[00:14:05]–[00:15:07]）：CEO 让一个贵模型把功能拆成 3 阶段 × 10 件，并行起 10 个 agent 执行第一阶段，并让它自行推荐更便宜的模型（结果起了一批开源模型与一批 Grok）。他的体验描述："不是去 Slack 上烦团队，而是直接发一个做好的 PR 给他们 review——这很上瘾。"
• Elad Gil 的配套观察（[00:16:07]）：非工程背景里用得最好的那批人几乎把它当电子游戏玩，不断给自己升级、给自己搭递归循环。
• ⚠️ 与本页 DHH 那条的对照：DHH 的 16 线程是一个资深程序员的手动并行；这里是把"计划—分派—选模型"也交给模型的另一种并行，而人只在终点做 review。
• 专才小模型打赢通才（[00:08:02]）：⚠️ 小的开放权重模型经微调或 RL 后在窄任务上超过前沿模型——他的例子是用内部 10 万个合规审查案例训练的小模型在合规队列上跑赢前沿模型（数字未核实）。他由此推出会有一个专才 agent 市场（"这个只擅长订披萨"、"那个只在海量私有 Figma 数据上训过"）。

⚠️ 另一种用法：把模型当生产依赖，拆到最小语义单元（Diogo Almeida / TypeSafe，2026-09-21）

来源：Latent Space / TypeSafe

本页此前的方法论都假设人在驾驶（agent 在你面前跑、你 review）。这条假设的是模型跑在后台、作为一个依赖被代码调用——所以结论几乎处处相反，值得与同次摄取的 DHH 并读。

建议本身

• 输入要结构化，不要拼 system message（[01:00:39]–[01:01:42]）：state、instructions、criteria 都可以是结构化 JSON，这样程序能把东西插进正确位置。⚠️ 他的判词："如果你还在把它变成 system message，你在用旧方式思考"；"system message 就是恶心的全局变量——你把所有指令一次性塞进去，然后指望每条都被命中，而不是并行地分别提问。"
• 拆到最小语义单元，问很多很多小问题（[01:02:43]–[01:07:48]）——"不管今天的模型能不能一次做完"。他给的收益是可测：发现"它没拒绝是因为我没指定这种情形"时，加一个问题、加一个阈值、把它记成测试用例，这件事就永久解决了——"你的软件不会因为 context rot 而忘记"。⚠️ 他称之为 "ML without the ML"。
• 具体例子：不要问"我该拒绝吗"，而把可能需要拒绝的不同情形拆成多个独立问题（[01:06:47]）。
• ⚠️ 长状态的省钱技巧（可直接用）（[01:38:12]）：给每条消息打 ID，然后对每个 ID 并行问一个问题——状态只付一次钱，却能问很多问题。
• 当模型答错时他只给三个杠杆（[01:08:50]–[01:12:52]）：改提问 / 拆更细 / 调阈值。没有 fine-tuning（他"能想象但担心"——怕损失通才带来的边缘情形能力），他更希望靠校准 + 模型级联（置信度高就接受，中间档升级到更大模型）。主持人补了行业事实：OpenAI、Anthropic、Gemini 都上过又收回过 fine-tuning，"微调现在基本是开源模型的领域"。

⚠️ 与 DHH 那条看似相反，其实位置不同

	DHH（视频页）	Almeida
使用位置	人在驾驶的 coding agent	跑在生产依赖里的决策
对指定程度的建议	尽可能含糊，先把东西变出来再去用它	拆到最小语义单元，每个都带阈值
可靠性来源	人的 review 与品味	可测的小决策 + 阈值 + 测试用例
对 agent 的反馈	"make it simpler"	加一个问题、记成用例

本库的读法：两条建议都在各自位置上成立，冲突只在被错位套用时出现——把"尽可能含糊"用在后台依赖上会得到随机坏掉的软件，把"拆到最小语义单元"用在探索式开发上会退回瀑布式规格。

⚠️ "KV cache 的暴政"：他点名的一串现象

（[02:10:38]–[02:15:48]）他为此写过一篇 "KV cache rules everything around me"，而且明说自己没时间做、希望别人做：

• 机制：KV cache 把你锁进一个模型，而且为了效率必须不断往后追加——于是做不了好的软件工程实践：状态管理、抽象、分解。
• ⚠️ 他说这一条解释了一串现象：为什么路由很难、为什么 sub-agent 看起来不 work、为什么 compaction 是个难题。
• 为什么 sub-agent 难：要传的状态太大——"你需要比读它所用的智能便宜得多的智能，才能把这个状态搬来搬去"。
• 他的愿望清单：显式标注状态；在带层级标签的子任务树里检索相关上下文；便宜地回看历史上下文（⚠️ "continual learning 其实是个内存管理问题，因为你没有聪明的查内存方式"）；并行 sub-agent 互相读写状态并用聪明的锁协调，而不是"你在干啥我在干啥、谁先写"。
• 格局判断（[01:40:15]）：⚠️ Claude Code 与 Codex 大致是第一第二，但都是围绕"单模型世界"建的；开源 coding agent 因为能混搭而兴奋，而"一个 while 循环能做的事就这么多"，所以它们目前大致同水平——"一旦有人找到只有某个 agent 能做的杀手用例，所有人就会涌过去，而开源的那些都能抄过来"。

⚠️ smart software ≠ just-in-time software：一条关于 coding agent 价值上界的区分（Diogo Almeida / TypeSafe，2026-09-28）

来源：a16z / TypeSafe

⚠️ 本页此前所有 coding agent 材料讨论的都是"怎么把 agent 用好"；这一节讨论的是"用好了之后会得到什么"——而他的答案是：同一种软件，只是写得更快。

• 他认可的那个描述（[00:03:05]）：他把 Claude Code / Codex 称作 just-in-time software（他归给 Garry Tan 等人），并说这是"了不起的描述：它当场造软件，你可以用自然语言编程"——⚠️ "但它和软件有着同样的表达力。"
• ⚠️ 他要的那个东西（[00:03:05]）："我要的是 smart software。与其自动化软件工程，我要扩大软件本身能做的事，让那些本来就该可自动化的东西变得真的可自动化。"
• Martin Casado 的翻译版本（[00:04:08]）：⚠️ "它们写代码，但那代码就是人本来会写的东西。也许更好也许更差，但它基本还是代码，和十年前的代码长得一样。"
• 共同落点（[00:34:19]）：⚠️ "不管你用多少 AI coding agent，软件本身并没有变好。也许你写得更快了。甚至可以说在变差，因为监督变少了"（配套的"10 行 PR"数字见 AI 商业化与价值捕获）。

⚠️ coding agent 的能力分工：语法强、架构"烂得离谱"，但也许够用

（[00:28:18]–[00:29:18]）⚠️ 本页此前对 coding agent 弱点的记录多是"上下文"与"审查"层面的；这是第一条把弱点定位在架构层、并同时给出反驳的材料。

• 他的判断：⚠️ "它们真的很擅长语法"，主持人接"语义上很差"，而他推得更远——⚠️ "我会说在架构上烂得离谱。" 理由是他对软件的价值判断："在我看来架构是软件里最具人类创造性的部分。"
• ⚠️ 但他立刻自我反驳（本库认为这是这段最该引用的一句）："也许模型在架构上不只是烂——也许它们是第 50 百分位的架构。而如果你对架构一无所知，那就完全够用了。"
• 所以这是一组权衡而不是结论：⚠️ 速度可以是你要拧的那个旋钮——"你愿意要第 50 而不是第 60 百分位的架构，因为你想跑得更快、想让 Codex 通宵干活。"
• ⚠️ 可操作的读法：这条给出的判据是你自己在该维度上的分位。对架构有判断力的团队，agent 的架构产出是净损失、需要人把关；对架构没有判断力的团队，它是净收益。本页把这条与上面的 DHH / Almeida 对照表并读：三者共同指向"agent 的价值取决于它替换掉的是谁"。

⚠️ 可靠性的四层拆解（比 09-21 那期更细）

被问"对一个本质上随机的东西，可靠性到底指什么"（[00:26:18]–[00:27:18]），他给了一个分层，⚠️ 本页记为目前对"LLM 可靠性"最可操作的一次拆分：

层	含义	他的判词
uptime / SLA	服务可用性	⚠️ "不是我主要指的那个"
determinism	同输入同输出	⚠️ "对单元测试有用，对真实系统没用"
robustness	每次给出相似的智能	判据：在 prompt 里加一个 UUID，输出就该一样，因为功能上是同一个东西——"但这不完全等于确定性"
（他说还没名字的第四层）	每次都是聪明的	⚠️ "它不必每次都是相似的函数，但它必须每次都是聪明的"；判准是"换成你在那个处境里，这是不是一个可理解的做法"，因为开发者可以围着这个编程

• ⚠️ 他给的终点状态（[00:27:18]）："让人们可以不写示例查询就直接对着 Jev 编程。你就是信任它，然后进入永久心流。" 他说 ⚠️ "很多软件今天就是这个状态"，所以"我不觉得这完全不现实"。
• 代价他也说了（[00:40:20]）：⚠️ "我们本可以早得多发布，我不觉得人们意识到这一点。" 他预期多数人永远不会真正理解这件事，"但它就是会有那种'哦我可以信任这个'的好氛围"——主持人当场命名为 ⚠️ "反挫败机器（anti-frustration machine）"。

⚠️ "AI 和软件是擦肩而过的两条船"：agent 为什么都长成 while 循环

（[00:39:20]–[00:40:20]）⚠️ 本页此前把 "agent = while 循环" 当成一种工程惯例；这一段把它解释成一个被迫的结果。

• Casado 的描述：⚠️ "你就算想把 AI 嵌进软件里，它也不听话——因为软件并不真的接受自然语言。你在 prompt 里塞'这是我要的 JSON 输出，这是 schema'，而它根本不照做。于是你最后做的，就是把输出直接丢给人。"
• ⚠️ Almeida 补完："或者丢给另一个 LM。而那就是 while 循环，agent 的那个 while 循环。所以从第一性原理出发，它必须是人在环里（聊天），或者是一个 agent（while 循环）——因为那个语言必须被喂回去。"
• Casado 的"五个悲伤阶段"（[00:40:20]）：想在自己的软件里嵌 AI 的人会经历否认 → 愤怒 → 接受（"算了，我把它丢给另一个 LM 或者一个人"）。
• ⚠️ 本页标注：这条解释与 Sinofsky 的"没有软件愿意被抽象成哑数据库"指向同一个接口问题的两端——Sinofsky 说被调用方不配合，Casado/Almeida 说调用方拿不到可用的返回值。

⚠️ 消费侧的一条授权边界，以及"助理最有用是在你手最忙的时候"（David Pawlan，2026-09-29）

来源：a16z / Assistant Benchmark

⚠️ 本页此前的 agent 实践全是开发者侧（coding agent、生产依赖、harness）。这一节是消费侧的第一条，来源是一个横评了 122 个个人 agent、亲测 26 个的人。

⚠️ 什么可以主动做、什么必须先要授权

（[00:26:17]）本页认为这是目前关于 agent 自主权最可直接落地的一条判据：

	可以主动做	必须先要授权
判据	⚠️ 你这边不需要任何动作	⚠️ 需要你改变行动、且直接影响你
例子	"我替你起草了这封邮件"、"我替你要到了机票积分"	发现你的保险收费过高，于是替你换一家保险
性质	省你钱、省你时间	一次代你做出的实质决定

• ⚠️ 后果是不对称的："这会是一条非常细的线，因为只要你越过一次，你就立刻失去用户的全部信任。"
• ⚠️ 但本页同时记下主持人的反向意见（[00:27:17]，Anish Acharya）："很多魔力恰恰来自擅自做主。如果你没在 X 上看到人们发'agent 干了这个、agent 干了那个'，那反而说明这些 agent 在这个方向上推得不够狠。" ⚠️ 两条并列：一条是留存视角（越界一次就完），一条是增长视角（不越界就没有传播）。本页不裁决，但指出它们争的是同一个旋钮。
• ⚠️ 一条把这件事抽象掉的说法（[00:25:17]，Acharya）：现在被叫做"人格"的东西会下沉成能力，变成 "它在歧义处怎么打破平局"；他给的维度名是 presumptuousness（擅自做主的程度）——"有些活你宁愿它 10% 的时候出错，只要它经常真把事办了；而金融 agent 你希望它极度谨慎。"

⚠️ 界面：助理最有用的时刻不是你闲着的时候

• 他的原则（[00:18:09]）：⚠️ "助理最有用的时候，是你最被占住的时候——不是你坐在沙发上花时间用它，而是你在园艺、在做饭、手上腾不开、没法跟界面互动的时候。"
• 配套的一次实测（[00:17:09]）：他把语音接入连接器称作 "这整个 AI 助理浪潮里的第二个魔法时刻"——骑车上班的 30 分钟里把邮件分类打标签、回了几封、发出日历邀请，到工位时收件箱清零。
• ⚠️ 一条与本页既有材料相反方向的观察（[00:20:11]，Acharya）："把 agent 加进群聊会让人觉得侵入，或者说它削弱了社交资本。" 他给的解释是麦克风隐喻（[00:22:14]）："消息这件事就像是有人拿着麦克风，而把麦克风交给 agent 让人不舒服；换成论坛或 Discord，agent 发一个帖子你可以选择接或不接，那就没那么侵入。"
• 由此得到的三种多人做法（[00:20:11]–[00:21:12]）：① 直接加群聊；② agent 网络（两个 agent 幕后代谈，再分别向各自主人汇报）；③ ⚠️ 沉默的听众——加进群聊但全程不说话，只听只记笔记，有行动项时单独私信相关的人。他认为第三种最有意思，理由是"又回到隐形 agent"。

⚠️ "这一波就是 Open Claw 的复刻，只是预配置好了"

（[00:28:17]–[00:29:19]）⚠️ 这条出自一个测了 26 个产品的人，本页记为对整波消费 agent 最有祛魅价值的一句：

• "在个人助理这个空间里，我没看到什么是用 Open Claw 或者 Hermes 做不到的。" 真正的差别是 ⚠️ "你不用自己配置，不会每 7 小时弹一次报错，而且它非常好用。"
• ⚠️ 本页的交叉标注：这与同一周 Diogo Almeida 的可靠性四层形状相同——Almeida 说可靠性的终点是"不写示例查询就能直接编程"，Pawlan 说消费品相对开源原语的全部增量就是"不用配置、不会报错"。一个在模型侧、一个在产品侧，结论一致：这一轮真正稀缺的是可靠性，不是能力。

⚠️ effort 怎么配、CLAUDE.md 为什么会消失（Thariq Shihipar / Anthropic，2026-09-29）

来源：Latent Space / Anthropic

⚠️ 本页此前的 coding agent 实践多来自重度用户。这一节来自 harness 的作者一侧，所以它能给出机制解释而不只是经验。

⚠️ effort 主要花在验证上——所以配法是分域的

• 他的发现（[00:24:13]–[00:25:14]）：⚠️ "effort 基本随任务复杂度 scale。对安全来说高低 effort 对评测结果影响很大；但对软件工程影响没那么大——因为 effort 主要花在验证和边缘情况测试上。"
• 他的粗分布（[00:27:15]，依据是把 terminal bench 约 70 道题全过了一遍）：

任务	effort
代码审查、安全	⚠️ high / max
UI 之类	low / medium
做 API、要覆盖足够边缘情况	更高

• ⚠️ 由此推出一条反直觉判断（本页认为是这一节最该记的）（[00:25:14]）："前沿模型会对几乎所有东西帕累托占优……聪明的模型能用更少的 token 做完简单任务——因为验证。在极限下，完美的模型不需要验证，它干一次就完了。" 他的体感："我现在经常想说：你不需要起个 Chromium 把这些全截图一遍，我看得出来你做好了。"
• ⚠️ 一条省钱机制，而且不是"写长 prompt"（[00:23:12]）：人们撞上额度上限往往是因为事后来回返工（"我不喜欢这个，撤掉重做"），而前期给够上下文本来就能做对。他的建议是 ⚠️ "给模型该在哪儿花算力的许可——它并不直觉地知道你在做原型还是生产的东西。"

⚠️ 最具体的一条 prompting 技巧，以及它背后的失败分析

• 技巧（[00:28:16]）：⚠️ 让它写决策笔记 / 实现笔记。
• ⚠️ 理由（本页认为这条失败分析比技巧本身更有价值）："在基本每一道评测题里，它都想到了正确解法，然后决定不去做：'这是答案，要不要这么干？''大概不要吧。'然后继续往下走。而这就是失败的大多数。" 配套的一句：⚠️ "在 high/max 级别上，模型纯粹不知道怎么做的情况很少见。"
• 所以笔记的作用是可复查：你能看到它考虑过却放弃的选项，然后说"其实我要你做那件你没做的事"。

⚠️ CLAUDE.md 会消失，而且现在就可能不该写

（[00:29:18]–[00:31:19]）⚠️ 本页此前把 CLAUDE.md / AGENTS.md 一类文件当成稳定的最佳实践。这是来自作者一侧的反向判断。

• 结论：⚠️ "在极限下 CLAUDE.md 会消失，而且可能都不用那么远——我觉得现在开一个新项目，也许不带 CLAUDE.md 更好。"
• ⚠️ 机制（比结论更有用）：失败模式按模型变——"Fable 5.1 和 Fable 5 都不一样。这不是我们故意的，模型就是这么工作的"；而攒着一长串失败模式的日志"很可能会把 Claude 过度约束住"。
• 他们的应对（[00:31:19]）：⚠️ 给 skills 加了 eval 插件，所以现在可以评测一个 skill 是不是真的更好了（他说这还要花 token、也不完美）。
• ⚠️ 他对这整件事的元立场，本页认为该照录（[01:12:49]）："我们喜欢说，模型是长出来的，不是设计出来的。所以不是我们立意要一直改变一切。" 以及 "我其实只是在做报道。"

⚠️ 元技能是心智模型，而不是措辞

• 他的说法（[00:17:10]）：⚠️ "prompting 就像公开演讲或写作——是针对一个特定受众的，而那个受众是 Claude。你需要建立一个关于 Claude 怎么想、怎么工作的心智模型。"
• ⚠️ 反直觉的观察（[00:18:10]）："很多高手 prompt 都很短，但他们对 Claude 和对代码库的心智模型太好了，所以看起来毫不费力——但这是个高技能上限的事。"
• ⚠️ 他对所有人的判断（[00:07:02]）："总体上我认为几乎所有人都更偏'需要 agent 来澄清'那一侧——他们的歧义比自己以为的多，对问题知道得比自己以为的少。" 所以 "找出你的 unknowns 会永远是 agentic coding 里的一项技能——因为就算模型超级智能，它也需要知道你想要什么。"
• ⚠️ 地图与疆域（[00:19:11]）：不是设计师就只能说"给我八个 mockup"；是设计师就能给参考站点、字体、组件。落点是去学那套语言。他最好的例子是游戏设计（[00:20:11]）：⚠️ "很多人说我现在能 vibe code 一个游戏了，然后他们说——它不好玩"，因为手感是游戏设计师要花好几天的东西。
• 关于 taste 的分歧（[00:20:11]）：主持人的定义是"从 1000 个数学上都成立的答案里挑出人类会喜欢的那一个"；⚠️ 他有保留——"听起来有点精英主义"，而"工程师对他们那类特定问题有大量 taste"。他引 Jason Liu 的版本：⚠️ "要有品味，你得先去吃。"
• 语音 prompt（[00:22:11]）：⚠️ "文本的实际格式没那么重要，重要的是里面有多少信息"；而且可以在 prompt 中间改主意，它能跟上。
• ⚠️ swyx 贡献的一条（[00:31:19]）："足够高级的 prompting 与足够高级的高管沟通无法区分"——他指向 SCQA 模型（situation / complication / question / answer），"人们做 prompting 做了几十年，那玩意儿就叫高管沟通"。

两条可直接抄的小技能

• ⚠️ ELI5 skill（[00:32:20]）：提示词非常短，而且里面根本没写"像对五岁小孩解释"——关键词是 "big picture in few words"，而效果好得惊人。⚠️ 来路值得记：Anthropic 的人在过非常复杂的事故时想知道"到底在发生什么"。 它也治了 artifacts 的一个毛病——"artifacts 的毛病是塞太多字，人们不读。"
• 测你自己懂不懂（[00:33:23]）：给几个选项，选错就说明你以为在发生的事与实际不匹配。⚠️ 他的评语很实在："这是那种所有人都爱聊、但极少人真做的事——大多数人就是不想被考。" 可自设的规矩是："在你把东西发出去之前，你至少该知道实现了什么。"
• ⚠️ next steps 的最佳形态（主持人给的）（[00:44:31]）：让模型看整条 transcript，然后问 "原来的目标是什么？你的方案真解决了它吗？你是不是偷懒了？如果偷懒了也许是有原因的——也许你需要我的批准"，而且 ⚠️ "结果应该总是以多选形式出来"。

⚠️ 压缩（compaction）的三种做法，以及"大的 coding agent 都手动做"（OpenAI，2026-09-30）

来源：Latent Space / OpenAI Dev Day 现场

本页此前关于上下文管理的材料大多是使用者侧的经验（什么时候该开新会话、怎么写 CLAUDE.md、怎么卸载到文件）。这一期给了平台侧的口径，而且把选项摆全了。主持人先把问题立住（[00:36:35]）："缓存当然很需要，但归根结底你还是会撞上一百万 token 的上下文，而这在可预见的未来大概不会变——你仍然需要好的压缩。"

做法	机制	适用
Agents API 内建	OpenAI 自有的专有压缩，built into the harness——"你们替我们决定"	不想管
服务端压缩（Responses API）	"你告诉 Responses API，一旦撞到这个 token 阈值就自动压缩、把用到的上下文减下去"	要省事但要有阈值控制
/compact 手动	"如果你要完全控制，你可以在任何时候 /compact，用你自己的逻辑决定什么时候压"	要完全控制

• ⚠️ 本页认为最该记的一条实践观察（[00:37:35]）："我不知道为什么，但很多大的 coding agent 喜欢手动做。如果你看开源 Codex harness 里的实现，你会看到他们用的就是 /compact。" 这是一条来自平台方、关于"自家最强产品不用自家自动化"的直接观察——它给本页一条可操作的默认建议：压缩时点是产品决策，不是基础设施决策，所以能手动就手动。
• ⚠️ 一条前瞻，而且与另一家实验室撞上了（[00:37:35]）："我们在做一些新的压缩技术，有些你已经能在 Codex harness 里看到——是一些基于文件的系统，我们在实验。" 这与 Thariq 讲 Claude Code 把上下文往文件里卸载 是两家实验室在同一周、各自给出的同方向答案——本页记为"文件系统正在成为上下文窗口的标准溢出区"这条判断的第二个独立证据。

⚠️ 缓存与预热：一组可以直接拿去改代码的承诺

（[00:33:30]–[00:35:33]）他说缓存的动因是个人 agent 的形状——"特别是这些个人 agent，基本上是一条单线程一直一直往下走"。

• 30 分钟缓存命中保证（现有）；⚠️ 12 小时缓存窗口保证"刚为其中一个用户上的"，目前 preview、还没有公开 API，代价是"缓存多付一点钱"。动因很具体："即使你的线程做完一件事、三四个小时后再回来，你仍然拿得到缓存的性能。"
• ⚠️ 预热（pre-warming）已在 API 里："如果你知道自己接下来会用到这个 prompt，可以先预热缓存、现在就付缓存写入的费用，然后它在接下来 30 分钟就是现成的。" 主持人立刻接出用法——"而我可以 spawn 很多个那条线程的实例"，他答："正是。" ⚠️ 本页记这条为一个具体的 fan-out 模式：预热一次，派生多个实例共享缓存。
• 诊断：用 prompt / cache diagnostics 工具查"哪里掉链子了"；缓存读取价格在被压低，"对开发者来说应该去实现，因为显著更便宜"。

⚠️ 让 agent 测试自己写的软件：把"你是 agent 的 QA"这件事消掉（OpenAI，2026-09-30）

来源：Latent Space / OpenAI Dev Day 现场

• （[00:18:18]–[00:19:18]，Ari Weinstein）"computer use 让 agent 真的能测试它自己造出来的软件……传统上你在 Codex 里造一个东西，Codex 造好了，然后你得去测它，于是你现在就是 agent 的 QA。" 他的用法："造东西、让 agent 去测，等它到我手上的时候已经是能用的了。"
• 主持人给的两条一手用法（[00:19:18]）：① 一个视觉 play test skill——"能抓到很多你只看代码根本看不出来的设计问题"；② ⚠️ 一屏一屏克隆一个 SaaS："如果你在用一个很烂的 SaaS 想把它干掉，就一屏一屏地克隆"（computer use 驱动、截图、记录，再让 Codex 克隆全部）。
• ⚠️ 本页记第二条为一个值得单独注意的能力边界：本库此前关于"自己重写软件"的材料（DHH 的"各自造自己的 5%"）都停在论点层面，这是第一次有人把它描述成一条具体的操作流程。
• ⚠️ 本页同时标注它只补了哪一层监督：Ari 补的是"能跑"，不是 Almeida 担心的"设计质量"——而主持人那条"视觉 play test skill 能抓到只看代码看不出的设计问题"恰好说明设计质量那一层要另外搭。

⚠️ harness 的 80% 天花板，以及"直觉写不成规则"这条判据（a16z / Lio，2026-10-02）

来源：a16z / Lio

⚠️ 本页此前关于"harness 能不能顶住"的材料是分歧的：一侧是 Decagon 的"业务逻辑靠上下文而不是微调"、Ali Ghodsi 的"harness 差 2 倍成本"；另一侧是 TypeSafe / Jev 的"让代码而不是人来消费模型"。这一期给了一条划线的判据，而且它来自一个与 Jev 无关的垂直。

• 基础模型被他明说当成大宗商品（[00:34:17]）："我们用所有供应商的多个模型，我们真的把它看成一种大宗商品。它们有非常好的通用业务用途——读 PDF、生成 PDF、生成 Excel。"
• ⚠️ 而边界被划得很清楚（[00:35:18]）：有些用例"把基础模型和 harness 组合起来可以走得极远，也许能到这份工作的 100%"；⚠️ 另一些用例"你可以有最好的基础模型、最好的 harness——不管那是什么意思——还是只能到 80%"。
• 他给的两个 80% 用例：should-cost 建模（成本工程师看图纸判断零件该值多少）与价格对标。卡点是数据："所有这些信息都不是公开可得的——它们都是基于某一家企业、或者跨多家企业的专有数据，所以通用模型没法在上面训。"
• ⚠️⚠️ 而他对"为什么 harness 顶不住"的解释，本页认为是目前见过的最好的一个认识论例子（[00:36:18]–[00:37:19]）：
• "如果你给我一份 BCG 的报价和一份麦肯锡的报价，它们可能做完全一样的工作，但价格可能差 10 倍，而我完全不知道哪个更好。可如果你把它给一个采购经理，他一上手就会有一种直觉。"
• 第二个类比："我不知道该付多少钱给一个做视频的人，但这背后有一种直觉。可如果你让他们把规则写下来，他们做不到，因为那就是直觉和本能。"
• ⚠️ 本页把这条提炼成一条可迁移的判据：harness 的本质是把判断写成规则与上下文；凡是从业者自己也写不出规则的那一类判断，harness 就顶不住，只能靠在结果上训。 这与本页既有的"上下文工程 vs 微调"之争的关系是：⚠️ 它不是选边，而是给出了分界线在哪。
• 他给的方向（[00:36:18]）："也许不是训一个 LLM，而是像现在冒出来的 Jev 这类模型在做的——你用文本数据训它，但输出其实是一个结果，或者就是那个完美的价格。"（⚠️ 字幕作 "Jeff"/"Jev"，本库据第二处判定。）
• ⚠️ 本页标注三条限定：① 他只是"在思考、已开始微调"，没有任何已兑现的结果；② 他与 Diogo Almeida 同在 a16z 的内容生态里，所以这不是对 system one 模型类别的完全独立佐证；③ 主持人在同一处提到"Harvey 和 Decagon 现在真的在微调模型"（[00:34:17]）——⚠️ 本库关于 Decagon 的材料记的是"90% 开源 + 业务逻辑靠上下文"，与"在微调"不矛盾但口径不同，本页记为一处可对照的措辞差。

⚠️ 顺带：一条关于"性能百分比 ≠ 自动化百分比"的判据

（[00:41:20]）本页认为它应该成为此后评估任何"自建 vs 买"的默认提醒：

"你能在 8 小时里建出来，但你只能做到比如 70% 的性能。而问题是：70% 的性能或准确率，并不意味着 70% 的自动化。你可能有 70% 的性能，但你仍然需要做 100% 的工作，因为 70% 不算多——所有人还是得去核对数据。所以也许你甚至制造了比以前更多的工作。"

⚠️ 这条与本页 Ali Ghodsi 的"模型够聪明但缺 context"、Thariq 的"harness 的苦涩教训" 是同一条线上的三次表述，而这是唯一一条把它写成两个百分比之间的非线性关系的。

⚠️⚠️ harness 的理论：一条正面定义，"它们其实都是同一个"，以及 locally in distribution（Alex Zhang，2026-10-02）

来源：Latent Space / Alex Zhang

⚠️ 本页此前关于 harness 的材料全部来自实践者：Thariq 的"harness 的苦涩教训"、Ali Ghodsi 的"harness 差 2 倍成本"、Garry Tan 的 harness wars、Decagon 的集成与上下文。⚠️ 这是第一份把 harness 当作研究对象、并给出机制解释的材料。

⚠️ 利益相关：他与 Prime Intellect 合作做 Prime Agent（一个 RLM 式 harness），所以他对"这一类 harness 有前景"的判断有商业相关性。✅ 但本页注意到一处反向信号：他说"harness 的具体细节其实并不怎么重要"，而这对一个以研究 harness 为业的人是不利的表述。

⚠️ 一、harness 是什么：一条可用的正面定义

• 起点是一条干脆的承认（[00:33:20]）："我们发现的一件事是，next token prediction 对很多这类任务来说是一种真的很别扭的形式。" 他举 SWE-bench：你不会指望一次语言模型调用就在一个 codebase 里导航完。
• ⚠️ 定义："一个 harness 是一个关于你想让语言模型如何被贴合到某个问题上的、非常非常有主张（opinionated）的程序。"
• ⚠️ 而他由此导出的问法本页认为比定义本身更有用（[00:34:22]）："harness 里的哪些选择让语言模型解掉了这个任务？以及，我能不能干脆就有一个直接做这件事的语言模型？"

⚠️ 二、"所有主流 harness 其实是同一个"

• 那条判断（[00:32:20]）："人们会比较说'我爱 Claude Code''我爱 Codex''我爱 pi'——不，所有这些其实都是同一个。这些 harness 的大多数设计决策、设计选择都是一样的。" 更精确的版本（[00:51:31]）："当你把 harness 的逻辑拆开，它们实际上是同一件事。"
• ⚠️ 他给这一类起了名字，而本页认为这个命名本身很有用（[00:43:26]）："trajectory as a prompt"——把整条 rollout 轨迹保留下来当作主模型的 context。"即使你用子 agent，它仍然是这种形式。"
• 他引的外部支持（[00:42:26]）：harness tax 那篇论文（⚠️ 作者字幕作 "Arena"，本库无法还原）——"大多数 harness 选择不重要，因为所有这些 harness 都是一样的。" 他点的两个例外是 Grokbot 与 RLM 类抽象。
• ⚠️ 而他的收敛判断与本页既有材料一致（[00:43:26]）："随着模型变聪明，这个区分会变得不那么重要——如果你把 Astra 放进 open code 里，它不会发疯，因为它就是足够好。所以这些不同 harness 之间唯一的好处大体上就是成本。"
• ⚠️⚠️ 但他紧接着给了一个反例，而这正是本节真正的论点："而如果你把这些模型插进 RLM 里，它们还是不太行。它们还可以。而我认为这主要是因为我们所围绕训练的那类 harness 就是这一类 harness。"
• ⚠️ 他的类比给出了这条判断能被推翻的形状（[00:51:31]）："预训练的 scaling wall 之所以成立，是因为我们手上的架构选择是相对稳定的。但如果你彻底换掉架构，这条幂律会看起来非常不同。而 harness 也是一样。"
• ⚠️ 于是产业建议是（[00:43:26]）："需要有专门的团队去真的跑有意义的实验来 scale out 新的 harness 设计——比如在不同的 harness 设计上做后训练的 scale out。"
• ⚠️ 本页交叉标注：这与 Thariq 的"harness 的苦涩教训" 并不冲突，而且合起来比任一条更完整——⚠️ Thariq 从产品侧说 harness 的复杂度会被模型能力吃掉；他从研究侧说正因为都被吃掉了，现有这一类 harness 已无区分度，所以真正的空间在跳到另一类。收敛发生在同一类之内。

⚠️⚠️ 三、locally in distribution：本页认为这是目前对"为什么分解任务有效"最好的机制解释

（[00:49:30]–[00:50:31]）

• 先定义 in distribution：一个任务的 prompt 是模型见过、或见过某种版本的。
• ⚠️ 主流 harness 的毛病：不断把轨迹往后拼，"所以最终，除非你是 Anthropic 或 OpenAI、能在这类用户轨迹上训练，这些东西大部分最后都是分布外的"。
• ⚠️ 而 locally in distribution 是："如果一个 RLM 把它的计算分解成某种 meta harness、或者一个牵涉子 agent 去看局部问题的程序，那么在整个任务过程中每一次单独的语言模型调用都是分布内的——即使整个任务本身是分布外的。" 落点："如果每一次单独的语言模型调用的任务都是分布内的，你大概就会走到正确答案。"
• ⚠️ 本页标注这条为什么重要：本页此前关于"把任务拆小"的材料全是经验法则（拆小更可靠、给更清晰的工具、少放东西进 context）。这一条把它换成了一个可以被证伪的机制陈述：有效的原因是每次调用都落回训练分布内。 ⚠️ 而这也给出了它的失效条件：当子任务本身也在分布外时，分解不会帮忙。期内没有讨论这个边界，本页记下。

⚠️ 四、RLM 是什么，以及它真正的论题不是长上下文

• 定义（[00:45:29]）：⚠️ "一个 RLM 基本上就是一种 harness 设计，其中 harness 里唯一的工具是代码。" 三条展开：程序化调用子 agent（含调用自己作为工具的选项）；其它工具都是代码里的函数；context 永远存在代码环境内部的某块内存里。
• ⚠️ 口径修正（[00:47:29]）：原始问题是长上下文，而现在重心是组合性——"工具调用非常受限，因为你每一轮都得去调它们……而且没有一个你可以随时回溯的中心 context。RLM 就是专门围绕组合、以及拥有一个你随时能取用的中心 context 来设计的。" ⚠️ 本页提醒：引用他时应当用后者。
• 他给的两条实现要点（[00:57:37]）："诀窍就是把东西外化到文件系统上——那是最大的那个诀窍"；以及"强制一切都走代码；信任那个会写代码的模型，它会自己写自己的 harness"。
• ⚠️ 一条具体的产品痛点被主持人点出、他认同（[00:57:37]）：Codex 的子 agent"非常短命，而且它们主动劝你不要把它用在长时运行的事情上"——而 Prime Agent 的做法是持久化子 agent（"你可以进到那个子 agent 里、继续 prompt 它"）。
• ⚠️ 他对终局形态的预测，自评"相对安全的赌注"（[01:04:41]）："我们所认为的语言模型——我们去查询的那个东西——可能实际上是一个 swarm、或者一个 scaffold、或者某个 scale 得很好的怪 harness 设计，而用户就是看不到它。"

⚠️ 五、他对 Jev 的解读：本页第一次看到"输出空间"被当作一个可调项

（[00:21:12]–[00:30:20]）⚠️ 本页已有 Jev 的供给侧材料 与 同日一个应用层创始人的需求侧指认；这是第三方研究者的解读。

• ⚠️ 他认为它真正打开的问题（[00:22:12]）："Jev 真正有意思的地方是，它打开了这个问题：语言模型的形态是对的吗？在它们现在这个形式下，我们能不能考虑一个 text-to-text 之外的设计空间？"
• 成本论证很具体："如果我只需要做一次二元分类——我会让我的语言模型来做这件事、付 400 倍的成本吗？不会，那很傻。"
• ⚠️ 而他的定位是"一个新的可调项"（[00:23:14]）："我们现在有了一个新东西可以调——就是输出空间是什么，以及这怎么影响推理延迟。"
• ⚠️ 他对这个成见的来源给了一条很好的解释（[00:22:12]）："因为最长一段时间里，实验室是唯一控制这件事的地方……正因为如此，人们已经相当习惯了'一个语言模型就是一个自回归解码器'这个想法。我们接受了这一点。"
• ⚠️ 校准（calibration）那一条本页记为这条线上最具体的一次表述（[00:28:20]–[00:29:20]）：模型被调成给最可能的下一个 token，所以问它"你有多确信"时它只会给最可能的答案；他认为"校准大概是被低估的一块：人们只是把它当成一个很快的分类器用，但他们其实连概率或校准估计都没在用"，并给了合成数据的做法。⚠️ 主持人的收口最清楚：真正的差别在于"这是一次有依据的分类（grounded classification）"，而不是模型吐出来的那个百分比。
• ⚠️ 他明确不猜 Jev 是什么（[00:27:19]）："我其实不太确定他们的优化目标是什么、以及他们怎么训的。" 本页也不猜。

⚠️⚠️ 反"上帝 agent"：本页第一条从"用户失去什么"出发的论证（OpenRouter × Replit，2026-10-03）

来源：a16z / OpenRouter × Replit

⚠️ 本页此前所有关于通用 vs 窄 agent 的材料都是从能力、成本或安全出发的（Mark Cuban 的 agent 漂移、Pawlan 的 proactivity 护城河）。✅ Atallah 这一条的切口不同：它问的是"用户在交出工作的同时交出了什么，而那样东西有没有接收方"。

• ⚠️⚠️ 主命题（[00:19:16]–[00:20:17]）："用个人 agent 做跨域 join 最糟糕的部分是：你给它越多活干，你就越是在牺牲自己对正在发生什么的理解。而没有任何新的人来为这份被牺牲掉的理解负责。agent 不承担任何责任。"
• ⚠️ 他给的守恒量（[00:20:17]）："整个公司在所有人之间能容忍的皮质醇（cortisol）是有一个固定水平的"——"如果我要牺牲我对某个领域的理解、想少焦虑一点，那就得有别人来承担这份皮质醇。但 agent 不承担。"
• ⚠️ 他的处方是"把 agent 竖切 + 一个幕僚长做协调"，而理由是可调性（[00:22:21]–[00:23:22]）："10 个和那一个一样能干的幕僚长、各管你生活的一个板块"优于一个全能幕僚长，因为"后者给了你一种方式去调节：你牺牲多少理解，换来多少收益"——"我可以在 agent 表现不好的领域更往里投入，而在能力非常好的领域让 agent 接管我对我生活那部分的理解。"
• ⚠️ 那条自述的负面证据是本页认为最该被记住的一手材料（[00:21:17]–[00:22:21]）："我有一个通用 agent，每天找出需要我的事、试着判断该做什么。而它根本不可能被改进。我每次试着做一点改进，一周后我就在忽略它的输出了。" ⚠️ 归因："它就是感觉对任何它正钻进去的具体事情都不真的在乎。"
• ⚠️ 本页标注一条重要的对立证据，期内由 Masad 给出且未被裁决（[00:17:15]–[00:19:16]）：他在 Replit 上那个从 CRM agent 长出来的通用 agent 恰恰是平台吞掉了他建的领域专用 agent，而跨域 join 的收益他说得很具体——"它能看我的个人聊天记录、跨 GitHub repo、跨 Salesforce……哦，你一年前在某个会议上见过这个人，顺便说，他们团队另一个人正在和你的销售团队谈。" ✅ 本页记为方向相反的两条一手使用报告，不裁决。
• ⚠️ 而 Atallah 自己给这条主张加的限定，本页认为必须一起记（[00:24:23]–[00:25:24]）："我描述的这套东西的问题是，我们不知道'好'长什么样。还不存在哪一套专业化 agent 的系统，体感上能像 ChatGPT、Claude 或 Muse 那样优雅。它还没被发现。"
• ⚠️⚠️ Masad 补的那条权限结构论证，本页认为是这一整条线在企业语境下最硬的落点（[00:26:24]–[00:27:25]）："作为 CEO 我们可以有通用 agent，因为我们有 admin 权限。但对个别员工或某些团队，他们不可能有真正通用、完全有上下文意识的 agent，因为有访问控制的问题。" ✅ 本页标注：这把"agent 该不该窄"从一个产品品味问题改成了权限结构的推论——在企业里，专业化不是设计选择，是访问控制留下的唯一形状。

⚠️⚠️ 一家传统合规公司被 AI 重构的全过程，以及"落地问题，不是模型能力问题"（陈然，2026-10-06）

来源：月球大叔 / 陈然

✅ 本页认为这是迄今收到的最完整的一份企业 AI 落地一手清单——不是工具评测、不是能力演示，而是一位 CTO 把自己 2025 年进入一家传统合规服务公司之后改掉的每一件事列了出来，包括几件会直接减少收入的事。人物页见 陈然。

⚠️ 公司是 Pure Global（医疗器械的全球注册，近 20 个办公室），他是 CTO，所有效果与数字均为自述、本库未核实。 ⚠️ 他对这个行业给的类比："有点类似于你要出国要去申请绿卡一样，你要填很多文档。"

⚠️⚠️ 一、他改掉的六件事

• ⚠️ ① 把 SaaS 的源代码直接送给客户（[01:23:50]）："我们当时有一些 SaaS 的软件，就是每年收年费，那个觉得 SaaS 没有意义了。我们直接把源代码送给了一些有 SaaS 的那个客户，说这个事情我们不做了，源代码都给你，不要了。"
• ⚠️ ② 把部分付费数据库公开免费："以前是收费的，现在变成了一个获客的渠道。因为我觉得就是时代变了，就收费已经没有意义了。"
• ⚠️⚠️ ③ 用 AI 把内部系统全部重写，而他从中得到的结论本页认为是全期最该被记住的一句组织观察："扔掉了很多我觉得没有意义的功能，然后花了很多时间跟客户聊，只保留很少和客户真正需要的东西。然后事实证明呢，客户要的东西比我们原来提供的东西要简单很多——很多东西就是一个团队他觉得我要做所以要做，他为了证明自己的存在要做。但是当你能够去重写一遍的时候，你会发现真正重要的东西是很少的。"
• ✅ 本页认为这条的机制值得单独记住：⚠️ 重写成本被 AI 压低之后，"沉没的功能"第一次可以被便宜地清算——而清算的结果暴露的是组织动机（为了证明存在而建的功能），不是技术债。 ⚠️ 他给的收益是对齐："重写了一遍之后，很多东西就是很对齐，然后不管是 AI 用还是我们自己内部员工用都很顺手。"
• ⚠️⚠️ ④ 内部知识库，而他的表述非常极端（[01:25:52]）："今天所有的东西都是围绕着 AI 的知识库在进行了。大家都有问题，就是大家现在不要说话了，就彼此不要说话，就是你有事没事就问 AI 就行了。AI 答得不好呢，我们就改知识库。"
• ⚠️ 他给的两条收益：沉淀——"以前所有的知识都沉淀在不同的人脑盒子里，今天我们就是这个知识库不断地在成长变好"；上手速度——"所有新来的人都因为这个知识库的存在，而能快速地上手这个公司做很多事情"。⚠️ 他自己留了个口子："然后知识库当然怎么搭建又是一个很大的事情"——本期没有展开，本库记为未解答。
• ⚠️ 本页标注一处本期没有讨论的代价：⚠️ "彼此不要说话"同时意味着那些从未被写进知识库的隐性知识失去了传递路径，而"AI 答得不好就改知识库"这个回路只能覆盖被提问到的部分。本库记下这个问题，本期没有处理它。
• ⚠️⚠️ ⑤ 定价被整体重构，这是本库第一次看到一个行业的收费结构被 AI 直接改写（[01:27:54]–[01:28:57]）：行业原本按小时计费 + 第一年一笔大额注册费 + 每年年费，而且价格不透明。他们的做法是三条叠加：成为第一家在网上公开所有项目价格的公司、改成 flat fee（固定价格）、⚠️ 并把注册费直接免掉——"别人第一年注册费收你五千，然后每年年费收你三千；我们提供价格就是每年两千，第一年也是两千，第二年也两千。"
• ⚠️ 成本侧的理由："因为我们自己做注册的成本已经可以非常低了。"
• ⚠️ 而行业的反应他照录了，本页认为这段比任何数字都更能说明错位的程度："这个行业大家已经有时候不太理解我们在提供什么东西了——就是什么叫注册不要钱？那很多人会问：那什么意思？就是那注册不要钱了吗？对啊，不要钱了。"
• ⑥ 改了 incentive compensation（发钱的方式）——⚠️ 本期只提了一句，具体没有展开（他在别处主张合伙人式分成，见 AI 与就业 该节）。

⚠️⚠️ 二、结果：生产能力越过了获客能力

• ⚠️⚠️ 具体口径（[01:26:53]）："我们内部用了 AI 工具辅助之后，写文档的效率就是急转直上。我们原来可能这个 backlog 里面可能有五六十个项目等着做，然后现在就是已经没有项目可以做了。"
• ⚠️⚠️ 落点："所以我们为什么说我们最大的痛苦是客户不够——因为我们的 deliver、就生产的能力，已经远远超出了我们获客的能力了。所以我们现在基本上所有的人，大家都在研究怎么样获得更多的客户，这是我们唯一重要的事情。"
• ✅ 本页认为这是本页此前只在抽象层面见过、而这一期第一次给出具体 backlog 口径的一条：⚠️ 当交付不再是约束时，瓶颈整体平移到需求侧——而这也解释了他们为什么要再孵化一家公司专做获客（[01:20:46]，⚠️ 公司名字幕作 "VeguMat"，本库无法还原）。
• ⚠️ 他自己的一般化表述："在 AI 的这样一个疯狂发展的时代，就是当我们生产一个东西不再是一个问题的时候，获客就会是一个非常困难的事情。"
• ⚠️ 主持人在这里提了一个必要的质疑，而嘉宾的回答是时间窗（[01:29:58]）：主持人问"把价格打下来是不是有点行业内卷"，并自己给了反面证据（"公司里边的人其实都很开心，每个人的工作时长其实并没有显著增加"）；⚠️ 嘉宾的回答是他们在 2025 年 Sonnet 3.5/3.7 时期就动手，"抢占了 AI 这一波的红利"。 ⚠️ 本页标注：这是一条关于先行者的解释，不是关于"价格战能否持续"的回答，本期没有回答后者。

⚠️⚠️ 三、"落地问题，不是模型能力问题"

• ⚠️⚠️ 原话（[01:30:59]）："基于 AI 的整个 workflow 这套东西，今天的问题就是大家只是说落地的问题，都不是模型能力的问题。怎么样落地可能是需要有人帮忙，但是模型能力已经很多时候已经完全没有问题了。"
• ⚠️⚠️ 而那句推论是全期最不客气的一句："换句话说，我们绝大多数人的工作的难度真的不高，就是大家做的事情的难度是低于模型能够提供的东西的。所以只要我们 plugin 插入这个模型，很多工作是可以被替代的。"
• ⚠️ 本页的限定必须一起引用：✅ 这条值得长期引用，但它的证据全部来自一家文档密集、合规驱动的业务。⚠️ 他没有讨论它在别的工作形态上是否成立，本库不把它当作跨行业结论。
• ⚠️ 而他对"工具什么时候变成工作流"给了一个很清楚的判据，本页认为这是本页此前缺的一条（[01:23:50]、[01:30:59]）：
• 时间点：2025 年 Sonnet 3.5 / 3.7 加 Claude Code 发布，"我们当时用了感觉就是完蛋了，就是工作以后肯定就是围绕这个东西进行的"。
• ⚠️⚠️ 对照："之前大家是用 ChatGPT，你是要复制粘贴，你感觉它不是一个工作流，它是一个助手；它甚至不是一个助手，因为它没有办法帮你做什么，它只是一个启发你的那个东西。"
• ⚠️⚠️ 判据是形态："它一旦进入了一个 CLI、一个 terminal，它意味着什么叫 workflow。"
• ⚠️ 他对自己为什么能更早判断的归因是身份："因为我们是一直一线写代码的人了，真的是知道这个东西它的威力在哪里的。"

⚠️⚠️ 四、AI 落地的头号前提，而他说这条从机器学习时代就没变

• ⚠️⚠️ 他第一份工作（Trulia，2014–2017）学到的那条，他明确说在 AI 时代同样成立（[00:25:45]–[00:26:48]）："我觉得今天在 AI 时代也一样——就是如果你这个公司不是一个从上到下去支持 all in 机器学习、或者 all in AI，就从 CTO 开始支持你做这件事的话，你这个公司的机器学习的算法根本落不了地，根本不会对你的这个公司产生很大的商业价值。"
• ⚠️ 四条机制："因为它很多改变是破坏性的改变"；"需要整个公司的 priority、就是优先级的对齐"；"然后很多组织架构都要做调整"；⚠️ "然后 CTO 要出来替你这个团队挡住所有的子弹"。
• ⚠️ 而没有这些支持时的失败形态他描述得很具体，本页认为这段值得当作自查清单："我们想做的实验也好、我们想上的算法也好，很痛苦、很难去做排期，然后也看不到效果。我觉得更多的时候就是一个自娱自乐，然后写写博客，然后看不到商业价值，有点自嗨的那种感觉。"
• ✅ 本页认为这条与他本人的经历构成了一次很干净的对照实验：⚠️ 同一个人、同一类工作，在没有高层支持的公司里"落不了地"，在自己当 CTO 的公司里把整个业务重写了一遍。本页认为这提高了这条判断的可信度。

⚠️ 五、他自己用 AI 的两条可操作细节

• ⚠️⚠️ token 套餐是"短期时代红利"，本库第一次拿到具体口径（[01:39:10]–[01:40:11]）：他每月在 AI 工具上花约 1000 美元，而主持人给的用量是"每个月上百亿甚至三四百亿 token"。机制：⚠️ "比如 OpenAI 200 刀的套餐，其实一个月能用 100 亿到 200 亿的 token 可以给你。你这个自己用 API 是非常贵的。"
• ⚠️ 他的类比："中国当时的外卖大战，疯狂地烧钱补贴你吃外卖；美国就是这个 token 大战，疯狂地烧钱补贴你用 token。" 做法是所有达标的模型第一时间开最贵的套餐（他点了 Anthropic、OpenAI、Google Gemini，⚠️ 另有一个字幕作 "olama" 的第三方云平台，本库无法还原）。
• ⚠️⚠️ 而他主动给的限定必须一起引用："这些公司回头要上市，他会有财务压力，搞不好他不补贴那么多的。所以这个是一个非常短期的时代红利。"
• ⚠️⚠️ 而他把"护城河"重新定义成 token 成本管理，本页认为这是本页此前没有的一个角度（[01:07:30]–[01:08:31]）：被问"别人用 AI 三天抄一个怎么办"，他的第二条答案是——"到最后就变成一个供应链的管理：就是我能不能用更少的 token 给你做更好的效果。那这就考验我自己本身对 AI 工具的理解能力了：可能别人要比我烧十倍的 token，或者别人获取 token 的价格比我高十倍一百倍，或者他要请一个全职员工来做这个事情，那他的商业他就无法运营下去。而对于我而言，我能想办法去获得更便宜的 token、我能去调不同的模型、我能找到它的边界。"
• ⚠️ 他对"做什么"给的选题判据本页认为很实用，因为它解释了他自己的失败率（[01:13:37]）："为什么我觉得我做那个 open exam preparation 很成功？是因为我自己当时考试的痛点很大……我是真正理解那个痛点，我相信做这个东西一定是有价值的，所以我愿意花一些时间去做。但是在很多别的行业，我哪怕做了一个东西出来，我觉得很难获得这个正反馈，因为我不知道它真正的痛点是什么，所以我也不完全知道该怎么样迭代。" ⚠️ 他自己的失败率是公开的：让 AI 自动找项目找到"一二十个，做出来可能大部分也都不太行"。

⚠️⚠️ "我其实不确定今天有谁真的擅长解决这些"：企业 agent 的两条阻碍与 eval 的空白（AWS CEO Matt Garman，2026-10-08）

来源：a16z / Matt Garman

⚠️ 本页此前的企业落地材料多来自卖方（应用公司、咨询方）或买方个案。这一节来自基础设施供应方的一号位（人物页见 Matt Garman），而本页认为它的价值在于两条：① 一条很干净的"企业想错了什么"的诊断；② ⚠️⚠️ 一次来自最该有答案的人的空白承认。

⚠️ 场合：AWS CEO 在一家风投机构的频道上接受采访。⚠️ 全期没有给出任何企业 agent 的收入或使用量数字，尽管他说"它今天已经是一个相当大的生意了"（[00:40:16]）。

⚠️⚠️ 一、阻碍一：企业把 agent 当成了人的替身

• ⚠️ 他描述的错误形态（[00:41:16]）："我们原先看到的是，企业有一个工作流，然后他们说：太好了，我让一个 agent 去做同样的工作流。"
• ⚠️⚠️ 而他们劝的是："不要只是复制 Bob 做第 1、2、3、4、5 步，所以 agent 也做第 1、2、3、4、5 步，然后 Bob 在最后检查一遍——那不是你想要的模型。你其实该退一步说：如果我想达成某件事，一个 agent 能怎么用不同的方式做到？它可以用大规模并行的方式做，可以试 50 种不同的东西……要重新思考一台计算机会怎么解决一个问题，而不是一个人会怎么解决一个问题。"
• ✅ 本页认为这条诊断的价值在于它指出了一个很具体的失败模式，而不只是喊"要重新设计流程"：⚠️ "按人的步骤排 agent + 人在最后验收"这个形态同时放弃了 agent 的两个主要优势（并行探索、可废弃的尝试），却保留了人的全部串行约束。
• ⚠️ 他对企业现状的判断是温和的："大多数企业建的 agent 都相对简单直接……而且基本是非自治的，还是人在环里"，但 ⚠️ "客户今天仍然从中拿到了很多价值"。

⚠️ 二、阻碍二：信任，而他认为这种谨慎可能是对的

• ⚠️ 原话（[00:42:16]–[00:43:16]）："企业感到紧张，可能很恰当地（maybe appropriately）让他们没法直接说'去吧，放开干'。你其实不想让一个 agent 发疯、不小心删掉一个生产数据库，那会相当糟。"
• ⚠️ 他列的控制项（[00:49:18]）："怎么确保 agent 有正确的权限？它们有正确的沙箱吗？怎么确保你有正确的一套护栏？怎么非常有意图地想清楚你想要 agent 做什么和不做什么？有没有人在环里？"
• ✅ 本页标注：权限粒度那条他在别处讲得更具体（"非常有时间盒的、短期的权限，只去做一个任务；你可能根本不想给它整个工具的权限"），详见 AI 算力与基础设施 该节。

⚠️⚠️ 三、本页认为全期最该被引用的一句：eval 的空白

• ⚠️ 被问企业是不是在学做 eval 系统，他的回答是 "老实说，他们需要帮助"，然后列了一串问题（[00:43:16]）："怎么有一个持续的测试回路？怎么想合理的 goal seeking？怎么把数据标注成让 eval 真能近似你在生产里要做的事？怎么在生产里度量并回测，这样你不会看到 drift？"
• ⚠️⚠️ 而落点是："所有这些都是企业今天不知道怎么解决的问题。我其实不确定今天有谁真的擅长解决这些。"
• ✅ 本页认为这条值得长期引用，因为说这句话的人处在能看到最多企业落地现场的位置上。 ⚠️ 它也与 评测与基准 里的那条主线一致：公开基准的饱和并不意味着企业侧有可用的评测能力——这是两个不同的问题，而后者目前没有人解决。
• ⚠️ 他把这条当作 FDE 热潮的解释："这就是为什么你看到这么多 FDE 团队冒出来……这是客户最需要帮助的单一最大领域。"
• ⚠️⚠️ 而他给的 FDE 模式有明确的退出条件，本页认为这与本库此前收到的另一种形成了直接对照（[00:44:16]）："我们的看法是我们想训练我们的客户让他们自己能做这件事。这不是那种传统的、我想要一个永远持续的人力驱动业务、你一遍遍付咨询费。我们的看法是：走进一个准备好接手的客户，在 45 天里做这些工作——教他们怎么做 eval、怎么把数据标注好、和他们并肩做——然后在 40 到 45 天结束时你就离开，那个客户已经准备好了。" ⚠️ 依据是客户意愿："他们不想在未来五年被一支外部队伍绑住。"
• ⚠️ 本页的交叉标注：✅ Periodic Labs 那期的 FDE 恰好是相反的设计——他们的 FDE 要长期驻场、在客户数据上训练、让客户"拥有他们自己的智能"。⚠️ 本页认为两者的差别来自交付物的性质：AWS 交付的是一种可被学会的工作方法（eval、标注、回测），而 Periodic 交付的是一个需要持续喂数据的模型。两条都不是普适的 FDE 模式，而是由交付物决定的。

⚠️ 四、Bedrock 的数据边界，与"企业其实在建自己的定制模型"

• ⚠️ Bedrock 的卖点他收敛成一条数据边界（[00:45:17]）："我们有一个保证：你的数据永远不离开你的 VPC。所以如果你跑在 Bedrock 里，你的数据不会回到模型提供方，他们永远看不到你的 prompt。" ⚠️ 措辞很强："让那些数据回到模型提供方，我认为是一件危险的事。"
• ⚠️ 他主动回顾了一次被批评的历史："三年前我因此挨了很多骂……我们因为慢于进入 AI 世界而挨了很多骂。而我们说：我们不会只是匆忙推一个服务出去。" ⚠️ 他现在给的结果声明本页记为未核实："绝大多数（从 PoC 到生产的客户）都落在 AWS 的 Bedrock 上"；以及 ⚠️ "你看到 OpenAI 的负载在往 Bedrock 迁移，你看到 Anthropic 真的在非常快速地增长"。
• ⚠️⚠️ 而开源权重这条路他给了本页此前没有的"实际发生在哪"的观察（[00:47:17]–[00:49:18]）："很多客户相信他们有有意义的专有数据，如果能混进去——做一些后训练、做一些微调——到一个开源权重模型上，他们可以蒸馏下来，实际能以更低价格得到一个表现更好的模型。"
• ⚠️ 他给的前置条件正好接上了上一节："这里面有一堆东西得跑通。他们确实需要有一个好的 eval 来真正证明那是真的。" ✅ 本页认为这是全期内部最自洽的一处：他把"自训小模型更划算"这条主张的成立条件明确挂在了那个他自己说没人擅长的能力上。
• ⚠️ 落地位置的观察："大多数人今天是在 SageMaker 里做这件事……而且他们也通过 SageMaker 托管推理。" ⚠️ 主持人的概括是 "SageMaker 获得了新生"，而他的回应把企业的行为说清楚了："它一直是个模型构建平台。而现在，如果你想想企业在这个世界里在做什么——他们基本上实际上是在建自己的定制模型。"
• ⚠️ 他对模型中立性的表述："我们也提供开源模型、提供专有模型……我们建这些积木，这样用你想要的任何模型建 agent 都更容易——无论它们在 Bedrock 里还是在 Bedrock 外。你可以用 Gemini 或者其它东西。"

⚠️ 五、AWS 自己怎么用：agent 优先的工程组织，以及一句"我不知道那个神奇答案"

• ⚠️ 被问哪里收益最大，他说 "显然是软件开发，这是真实答案"，⚠️ 而机制值得完整记（[00:53:21]）："我们叫他们 frontier team，他们思考的是 agentic development 而不是传统开发。而这不是代码补全——它真的是 agent 优先：agent 写所有的代码，你只是在管理一支 agent 团队、并驱动它。" ⚠️ 他强调不只是写代码："是产品开发整体，不只是写代码。"
• ⚠️ 非工程侧两个例子（[00:52:21]）：Amazon Quick 推给了每一位 Amazon 员工；⚠️ "HR 团队在建 agent，去驱动那些过去需要几人团队花几周做的事，现在一个人几小时就能做"；财务团队建 agent 拉各地税务规则做合规。⚠️ 他给的结构性意义："过去被软件开发者卡住的事情，现在业务线的人能够自己解锁、更快地创新。"
• ⚠️⚠️ 而组织形态那一问他明确说没有答案，本页认为这条承认比任何预测都有用（[00:54:22]）："我不知道那个神奇答案。我们在积极思考。" ⚠️ 他说正在试 pod 制，而给的具体变化是："在一个产品组织里，你过去会有一个团队长期拥有某一类能力，可能有 10 个人在做那件事。而今天你能创新得这么快，那件事不必是 10 个人了——可以是三到四个人。"
• ⚠️⚠️ 而他指出的后果不是裁员而是流动性，本页认为这是这一节最该被 AI 与就业 引用的一条："而他们造东西造得这么快，你其实想把他们挪到不同的项目和问题上去。所以要同时既运营和维护你已经造的东西、又在一个像 AWS 这么大的组织上保持敏捷与灵活地调动——这是我们正在实验和尝试的事。"
• ⚠️ 他对人数的判断是温和的："会有很多人、很长一段时间。我确实认为组织会变。" ⚠️ 主持人插的那句"agent 管人、人管 agent"他没有接，本页记下这处回避。
• ⚠️ 而他对客户实际怎么用编码 agent 的描述本页照录为一手观察（[00:09:04]）："我们发现绝大多数客户会去告诉他们的编码 agent——不管是 Kiro、是 Claude、还是 Codex——他们会说：我想在 AWS 上构建，这是我的凭证，这是我想怎么部署。然后 agent 很棒，它们就去做了。"

⚠️⚠️ 72 支队伍复刻同一款软件：一份关于"prompt 之前做什么"的横截面（Latent Space，2026-10-13）

来源：Latent Space / How to kill your SaaS

✅ 本页此前的 agent 工作流材料基本都是单个从业者的自述。这一期不同： 同一个任务、同一份规格、72 支队伍，而且参赛者的 prompt 与过程文档被自愿公开到 GitHub （[00:11:13]）。本页据此只记横截面上成立的模式，以及三位入围者的具体做法。

⚠️ 一、模型使用分布，以及出题人自己给出的"没有 alpha"

• 规模：公开 repo 的中位数是 91,000 行代码，"人们连着好几天跑 agent"（[00:10:12]）。
• ⚠️ 分布（[00:10:12]）：Claude Code 与 Codex 基本打平； 66 份提交里有 40 份同时用了两者；"几乎所有人都混用了不同模型家族"。 三位入围者都用了同一款 GPT 系模型，但另外 66 份里也有 50 份用了—— ✅ 他的结论是"所以这里没有 alpha"。 ⚠️ 型号在自动字幕里损坏，本页不写定。
• ⚠️ ✅ 一条难得的"主讲自己的实践被自己的实验数据反驳"的记录（[00:11:13]）： 他自述"我自己通常一个项目只用一个模型，这样所有 context 都留在一个地方"， 要一条 Codex 线程覆盖全部、一条 Claude Code 线程负责它最擅长的任务； "结果很多这些 builder 不这么干。他们会切换角色。"

⚠️ 二、三种多模型协作模式

1. 聪明模型决定做什么，便宜模型负责写被指定的东西。 例：Claude 做计划与评审，Codex 写大部分代码（[00:11:13]）。
2. 一个模型造、另一个检查，而且由"更擅长驱动浏览器或做测试"的那个来检查—— 他说"我认为现在那个是 GPT Codex"（[00:11:13]–[00:12:14]）。
3. ⚠️⚠️ ✅ 没有模型批准自己的工作（本页认为这条最有机制含量）： 一支队伍让一个 Claude 团队和一个 Codex 团队在各自的 worktree 里跑， 在对方验证之前谁都不能 merge。 他给的原理是 on-policy 与 off-policy 验证： "agent 对自己的工作往往比对别人的工作更宽松。而我认为这也反映了人类的行为。"（[00:12:14]） ✅ 本页标注这给"多 agent 交叉验证"提供了一条机制性理由， 而不只是"多跑几遍更稳"的经验说法。

⚠️⚠️ 三、"prompt 几乎是最后一步"

✅ 这是出题人自己对三位入围者共同点的总结，本页认为应完整保留（[00:16:17]）：

"注意没有一个人说自己打了一条 prompt 然后走开。真正的情况是，那条 prompt 几乎是最后一步—— 你是在建立起对问题的完整认知、以及 mock、文档、规格这些东西之后才走到它。 大部分工作是搞清楚这个软件到底在做什么，然后他们才能从那里偏离出去。"

三人的具体做法各不相同，但都在代码之前：

• 先把一切规划完（Marco）：坐下来 8–9 小时，以最细粒度规划出整个数据 schema、业务逻辑、 以及字面意义上的伪代码。⚠️ 他紧接的对照本页认为很有分量： "如果你把我四五年前做的这些任务、加上设计，字面上塞进一个 LLM，然后走开两三个小时， 你就能拿到整个东西、像素级完成。"（[00:13:14]） 他的输入是操作录屏 + 原产品 API 文档，并指定自己偏好的栈，理由是速度（[00:16:17]）。
• 先做研究（Yazin）：把需求文档转成 markdown，用 firecrawl 爬完原产品的整个帮助门户 以及几个类似站点，"就是想尽可能多拿信息"（[00:13:14]–[00:14:16]）。
• 先建护栏，并把它变成可复用模板（Valentin）： "我把它做成了一个模板而不是形式化文档……如果有人要接手这个项目， 你希望他能在上面写代码"，所以把 link、code review 等等都放进去， 做成 GitHub 模板，每个新仓库从它克隆，"而不是有一个 Google Doc 写着我做过什么"（[00:14:16]）。
• ⚠️⚠️ ✅ 一段很具体的探索记录（Valentin，[00:15:17]）： 他让 Codex"给我画出这个 app 每一个功能的每一条流程"； 令人意外的是 agent 用的是一堆 YouTube 视频、逐帧截图去判断发生了什么； 产出是一大堆 markdown，每个功能都写明预期；然后才规划并发—— "为每一步定出能并发多少个 agent"，有重叠的功能必须串行。 ⚠️ ✅ 而落点是他发现的那个失败原因：手工走一遍发现不完美， "因为我看到他其实从来没有在本地把 app 跑起来"—— 于是把整个流程重做一遍，但这次 app 在本地跑着。

⚠️⚠️ 四、自己当用户：三条可操作的做法

• ✅ 一条诊断："agent 非常擅长构建，但相当不擅长注意 UX 问题。" 具体例子：头像上传把照片存到了某处，但公开讲者页面根本不从同一个地方读取， 因为那是独立编码出来的（[00:17:17]）。 ⚠️ 本页标注这是一条典型的"分片生成导致的接缝失配"，而不是模型能力问题。
• ✅ 五分钟测试（Valentin）："如果我只有五分钟测这个产品，那会是什么样？ 而只要那五分钟不顺，我就会把整个流程重做一遍。"（[00:17:17]）
• ⚠️⚠️ ✅ 本页认为这一节最该被引用的是他的归因方式，因为它拒绝手工修补（[00:18:18]）： "我的目标从来不是手工去做任何'我不喜欢这个、我不喜欢那个'的事。" 做法是让 agent 去查自己的 trace 来理解根因。 onboarding 的例子：agent 的回答大意是"这只是一个关于 onboarding 的标题， 而 onboarding 就是要 onboard，但我们根本不知道什么才叫好的 onboarding"。 他的结论："所以这个流程里要解决的不只是'做一个 onboarding'， 而是'什么定义了好的 onboarding 路径、什么定义了坏的'。 于是我让他重做整个流程，但加入一步：去研究什么才定义了好的 onboarding。" ✅ 即把一次 UX 失败转化成一条缺失的规格研究步骤。
• 最朴素的那一种也有效（Yazin）：agent 做完把视频发回，他点着走、记一张待修清单—— 这样才发现"在不同视图之间切换真的很烦"（实际上得先登出再登入）， 于是补上登录、门户切换与邮件支持（[00:18:18]–[00:19:19]）。

⚠️ 五、本页对这一节的两条标注

1. ⚠️ 这是自制内容，主讲同时是出题人与结论叙述者。 ✅ 但模型使用分布、代码行数、提交数这类过程数据有统计口径， 且参赛者的 prompt 与过程文档公开，本页据此采用这些数字、不采用任何工具优劣排序。
2. ⚠️ "没有 alpha"这条结论只对本次任务成立（一次性复刻一块中档 CRUD 型业务软件）， 不应外推到其他任务类型。

⚠️ 本页第一条"主播把最难的提问外包给模型"的明确记录（Latent Space AI for Science，2026-10-14）

来源：Latent Space AI for Science / Ian Quigley

• ⚠️ 格式本身是嘉宾要求的：他请主播设一个 "don't come at me, bro" 环节，"我们问能想出来的最难的问题"（[01:25:46]）。⚠️ 缘起是他上周参加的一场癌症治疗学会议——一半时间讲内容、一半时间接受"非常激烈的拷问"，他的形容是 "既可怕又鼓舞人心"，于是 "我就来公开做一次"。
• ⚠️⚠️ 而主播明说提纲是生成的（[01:25:46]）："我们只有大约 24 小时准备，所以我觉得这些大部分会是 Claude 最难的问题。" ⚠️ 期内另有两处点名："Claude 可能在想的一个批评是……"（[01:26:47]）、"这个是纯 Claude 的，我在这上面没有任何想法"（[01:42:52]）。
• ✅ 本页认为可引用的观察是关于覆盖与深度的分工：⚠️ 那一段的问题覆盖面很齐（DEL 的 out-of-library 泛化、ADMET、bitter lesson 式的"更有钱的实验室为什么不能把你规模化掉"、商业模式、化学空间够不够大）⚠️ 但追问普遍只有一轮。✅ 本页的归纳是：生成的提纲补的是"该问到哪些面"，而不是"顺着答案往下钻"——后者需要现场判断，而本期几处最有信息量的内容恰恰来自主播自己的追问（按分子量排序 / CASF-2016、GenePT、mech interp 在生物学里的反向用法）。⚠️ 这条归纳是本页的。
• ⚠️ 本页同时记下一处相反方向的用法：主播在准备一个关于 DEL 分子形状的问题时自述 "我的理解来自和 Claude 聊、谷歌之类的"（[01:23:43]），⚠️ 而嘉宾的第一句回应就是修正——"那取决于 building block"。✅ 本页记为一次被当事人当场纠正的模型背景知识，按单例记录，不外推。

⚠️⚠️ 六个重度使用者的互相校正（Latent Space / High Taste Testers 第一期，2026-10-16）

来源：High Taste Testers 第一期

⚠️ 本节的归属声明：这期六人圆桌的自动字幕没有说话人名，本库未做说话人分离。✅ 凡本节写了名字的，都由片尾自我介绍或明确自指锁定（依据见 六人组页）；其余一律写"某位嘉宾"——这表示本库确实不知道是谁，不是匿名化。

⚠️⚠️ 过夜跑的那条闸门，和它刚被打开

• ✅ 本页认为这是本期最该被引用的一条使用纪律（[00:36:23]）："我其实真的相信，如果你在做生产软件，你整夜不停地跑模型，你会造出比你能可靠消费和吸收的更多的代码。"
• ⚠️ 而说这话的人自述这条闸门刚被模型质量打开："5.5 之前……它终于好到让我进入那个状态了。我很久没干过这件事，因为我相信上面那句。" 现在的节奏是 "晚上 10 点你把夜间 agent 都起来，早上 9 点你登上去干活"，手上 "10 个不同的原型"。推理档位 "说实话很多就是 medium 或 high"（[00:37:25]）。
• ✅ 本页标注：这条与 token maxing 那一类"尽量多跑"的主张不矛盾，但它给出了一个不同的限制变量——不是成本，是人的复核带宽。⚠️ 而它是一条自述的信念，不是测量。

✅⚠️ "有界的 Ralph 循环"：本页收录的最可直接照做的一条

（[00:37:25]，⚠️ 本库推断为 Dex Horthy）

"我会做一个穷人版的 Ralph 循环：我就排一串提示——做这个；好，现在做一次更好的 compact；现在做这个；现在读计划；现在继续把它做得更好；然后 compact。这些会排队、过夜跑……所以它像 Ralph 循环，但是有界的。你只排 5 到 10 条消息。"

• 同席给的类比："你在下棋，而且每一步都预先走了（premove）。"
• ⚠️ 他排进队列的提示里有两条是直接骂："嘿，这设计烂透了，重做" / "整个架构太复杂了"。✅ 即预置的不是任务，是预判的批评。
• 并行：一个 "detach 模式" skill——后台起 CLI 版本，理由是 "这样我能并行跑 40 个"，再 "盯日志、全部暂停、改进日志、再重跑"。

子 agent 与上下文：带数字的配置，和一条厂商口径

• ⚠️ 为什么用子 agent 而不是多会话（[00:38:25]，⚠️ 二手且不具名）："好几位 Codex 的人都说，子 agent 明显更好更快，因为缓存优化、以及模型对待子 agent 和对待不同会话的方式不同。" ✅ 本页此前关于子 agent 的材料多是使用偏好，这是第一条给出机制理由的厂商口径。

项	实测（⚠️ 均为个人设置，[00:38:25]–[00:39:25]）
子 agent 数量	"我 toml 里放到 48 个的时候，Astra 两小时就烧穿了我的额度"，退回默认；另一位 "我保持在 15 左右"
上下文	"如果你有不限量的访问，100 万 token 我觉得是个好主意"
auto-compact 阈值	一位设成 400k；另一位指出默认约 275k

• ⚠️⚠️ compaction 是被集体讨厌的那个原语（[00:39:25]–[00:40:25]）：想要的不是更好的摘要而是别摘要——"我希望它只是截断工具输出、截断字面上任何东西，除了摘要"，理由很具体："很多时候前面消息里就是一堆图片或者一堆别的什么。" ✅ 即他们要的是按体积剥离，不是按语义压缩。
• ⚠️ Claude Code 的一个被多人确认的症状："它会以为自己是个新人——'嘿，我看到你之前在做什么'"，被叫作 "Memento 时刻"。
• ⚠️ OpenAI 的 compaction 评价是"喜欢但太慢"——"如果你在跑 20 个东西，那就有影响"。

⚠️ 主线程该不该干活：一处明确的相反做法（不做裁决）

（[00:40:25]–[00:42:26]）

• 一派："别在主线程里干任何活。你的上下文应该是我和你的对话，不是执行。执行该发生在别处。"
• ⚠️ 另一派当场反着做："我在（主线程里）做事，然后在旁边开一条关于这件事的对话"——理由是 "那条支线是易逝的"。
• ✅⚠️⚠️ 但对最难的问题，两派给的是同一个配方："开 ultra，给它大量子 agent，然后告诉它——你唯一的工作就是派发子 agent；给它们设个计时器；如果它们停了或者偷懒了，就一直推它们。它就是那台推进机器。"
• 监督："我一直有一个 skill，开一条支线去看主线程的推理"；而且他们确实在看轨迹（"你会抓到它跑偏得很厉害"）。⚠️ 但提问的人自己先说 "我会看，而且我觉得我做错了"——✅ 本页记下这处犹豫：盯轨迹是否值得，这群人也没有共识。

✅⚠️⚠️ 助理碎片化：由"助理变多"本身造成的新成本

（[00:56:34]–[01:02:37]）✅ 本页认为这是本期的真正发现，而且全席承认没有好答案。

• ⚠️ 问题陈述："在这些工具之间切换是有注意力成本的。我现在到了这种地步——我不记得哪段对话是跟哪个助理进行的。"
• ⚠️⚠️ 而解释"为什么导入记忆不管用"的那个比喻是本节的核心："把它们的记忆从一个导到另一个也不够好，因为它们的记忆是以不同方式移动的。如果你把它们当成克隆体——克隆体在某个点上开始过上不同的人生，这个知道这件事，那个做了那件事。"
• 一个具体的应对：中心化 MCP 网关（[00:57:35]）——一个装着 Gmail / Drive / Notion 的网关，跑在家里的 Linux 机器上 + Cloudflare DNS 代理。✅ 关键在于它装的不只是连接："这些工具里包含了用它们的 skill、用它们的 prompt、每个的配置"，于是 "每配一个新助理只做一次 MCP 连接……我在那儿改一个东西，到处都改了，而真正干活的界面就变得相当轻量"。⚠️ 他自己给的例外是金融连接器——"那个我不会走直连 MCP"。
• ⚠️ 主持人给的规范性判断与所有人的实践相反（[01:08:43]）："应该有一个东西拥有你所有的搜索历史。所以你不该路由。路由是坏的。" ✅ 当场反驳也很干脆："但不测你就当不了 high taste tester。"

⚠️ 自建派 vs 产品派：两条反驳都值得记

（[00:17:15]–[00:20:16]）这群人大多直接把 coding agent 用成个人助理——"主 agent 就是 Pi，我给了它自己的 Gmail，它有信用卡，有提醒和 cron"；"我的个人助理还是一个 git repo，整个记忆系统都是 markdown"。⚠️ 而反驳有两条：

1. 你需要打磨过的产品：好用是因为移动端和网页界面顺手、而且 "你不用自己配记忆"。
2. ⚠️⚠️ "我不想多一个问题"（[00:20:16]）："我引入一个助理是来解决一个问题的，结果现在我有三个问题。我得维护基础设施。我想减负，不是增负。又多一个要我管的盒子，它还会宕。" ✅ 本页认为这是对自建派最有力的一条，而且它和"东西到底在哪儿跑"（见视频页第二节）是同一问题的消费者侧。

⚠️ coding agent 当通用助理时的两处摩擦

• 形态（[01:03:37]–[01:04:38]）：⚠️ "有时候你根本不想待在一个仓库里，你就想要个东西"——被夸的是"就是一台电脑"式的沙盒形态，被嫌的是开口先问"你想在哪个仓库里工作"。
• 被训练出来的交付偏好："它太爱开发了。你让它写点什么，它会发个 PR。我不需要 PR，我只需要一个答案。" 配上对系统提示的吐槽："整个系统提示就是'呃我做不了那个。你今天想写什么代码？'——我不想写代码。"

⚠️ 一条反直觉的日常选择：快答案仍然去 Google

（[01:07:42]–[01:08:43]）"任何我想要快答案的问题，我都去 Google"——⚠️ 理由是延迟而不是质量："大概 300 毫秒，页面加载完答案就在那儿了"，而 "ChatGPT 我总在最大推理档，要改设置，可改了之后我新开一个对话它又是那个傻设置"，"那就是 10 到 30 秒"。替代路径是 Raycast 的 AI（"command-enter，打你的东西，回车，完事"）。

• ⚠️ 另一位给了不矛盾的相反方向：旅行时问助理而不问 Google，"它大概没 Google 快，但如果我只想要一个是或否，它压倒性地没那么让人招架不住"。
• ✅ 本页判定：这组对照里被说出来的变量只有延迟和信息过载——三个人里没有一个说 Google 的答案更好。

✅ decision model 落地的一条方法（可直接照做）

（[00:22:17]–[00:23:17]）⚠️ 详见 评估与 Benchmark；本页只记用法：把已有的人工标签直接当 eval——"如果出来个便宜 10 倍的东西，它跟我历史标注的一致率超过 x%，那你只需要复核不一致的那部分" → "切换成本非常非常低"。还有一条更土的："穷人版 GEPA——这是一个不 work 的 case，拿它当 eval，然后一直改提示。"

⚠️ 一位做分布式系统的 CEO 的工作流：10 天做完 6 个月的项目，而人工把关在最前和最后（a16z / Grepr，2026-10-16）

来源：a16z / 为什么 AI 能写代码却还不能让它持续运行（Jad Naous）

⚠️ 全部为自述，本库未核实。 ⚠️ 关系披露见视频页（他与主持人是研究生同组同学，且主持人当年把他招进 a16z）。

栈与产出

• 栈（[00:18:13]）：Windows + WSL + Claude Code + Opus 5.5。⚠️ 用 Windows 的理由是不想学快捷键（"我讨厌单键鼠标，讨厌为了一个快捷键要按那么多修饰键"）。
• ⚠️⚠️ 量化（[00:22:18]–[00:24:18]）：data lake 的 auto-promotion / shredding（把日志事件里每个字段提升成可独立过滤的列）——"大概花了 10 天。在以前的日子里，那大概要 6 个月"，"一个人，就是我自己"。
• ✅ 本页特别记下主持人在听数字之前先打的那个断，因为它正是本页需要的那种限定："顺便说清楚，这是生产代码，不是 demo mockup。所以你接下来要说的，是你 ship 生产代码拿到的收益。" —— "是的。" 归纳为 "10 倍、20 倍的改进"。
• ✅⚠️⚠️ 而本页的读法必须结合他自己的另一句（[00:14:07]）："对我们解决的问题，没有哪个模型能真正想通我们做的事。" → 所以这个 10 倍不是来自模型替他想，而是来自他把想清楚的东西交给模型去实现，正对应下面那个"人先过 PRD 与 design doc"的流程。

✅ 流程：人工把关在最前面和最后面，中间放手

（[00:21:17]–[00:22:18]）

1. 让主实现 agent 先写 PR doc（内含 design doc），并配一个 "tech lead reviewer" agent 去 review 它。 ⚠️ 两个 agent 不通过 PR 交互，而是直接通过命令行互问（"这讲得通吗？review 我的 PR"），"它们一起在这些 PR 上迭代"。
2. ⚠️⚠️ 他自己逐块过 PRD 与 design doc："确认它讲得通，逐块细看，确认所有算法成立、所有部件成立、分工成立、PR 之间的划分和它们的关系成立。"
3. 然后才放手："去开始做。看看有没有可以并行的，然后起别的 agent 去做。"
4. ⚠️⚠️ 而最后这条硬限制必须与"我 ship 了 20 个 PR 丢给团队 review"一起读：

   "但最终你必须把它全部放回一个栈里，作为一个人类一个一个过——否则它就会变得又乱又枝节横生，你根本没法收拾。"

✅⚠️ review 重心的转移，以及一条组织观察

• ⚠️⚠️ 审查对象变了（[00:20:16]）："在 review 周期里变了很多的是，我们开始更多地聚焦在测试上，以及做 golden expectations 这类事——它们是不是在以不同的方式漂移。" ✅ 即人工审查从"这段代码对不对"挪到"预期输出有没有漂移"。 ⚠️ 他没有给这条做法的失败模式，本页不替他补。
• ⚠️ "PR 到处乱飞"（[00:19:14]）：他自述 "过去两周我 ship 了这些巨大的、20 个 PR 的东西，直接丢给我的团队去 review"，主持人挑明其组织含义（"新的汇报结构就是下面的人给 CEO review PR？"），✅ 而回答比玩笑更有信息："不，所有人都在写同样的 PR。我也 review 我的人的 PR——PR 到处乱飞。" ✅ 本页判定这是一条"review 成为团队主要带宽占用"的记录。

⚠️⚠️ 两条与同日另一期直接冲突/对照的实践

项	本期（Grepr，Claude Code）	同日 Latent Space 那期
子 agent	⚠️ "不要用内建 sub agents，而是告诉 Claude 去起命令行子 agent，因为那些能保持持久会话"，好处是上下文效率（[00:20:16]）	⚠️ 转述 Codex 侧口径："子 agent 明显更好更快，因为缓存优化、以及模型对待子 agent 和对待不同会话的方式不同"（该期视频页 00:38:25）
并行度	✅ "我通常同时开三到四个会话窗口，因为超过这个数我就开始丢失上下文——它们完成得更快，然后就得等着我"（[00:21:17]）	"这样我能并行跑 40 个"（该期视频页 00:37:25）

• ✅ 本页不裁决，但指出差别可能在两处：① 优化目标不同（缓存命中与速度 vs 会话持久性与上下文效率），且用的 harness 不同（Claude Code vs Codex）；② 任务类型不同（本期自述是生产分布式系统，那边多为原型）。⚠️ 两边都是自述，没有任何一侧给了测量。
• ✅ 而两期在同一件事上一致：瓶颈是人的复核带宽——这边是"三四个窗口以上我就丢上下文"，那边是"你会造出比你能可靠消费和吸收的更多的代码"。

⚠️ "AI 开始训练他们"，以及 harness 本身是要学的对象

（[00:11:06]–[00:12:07]）

• ✅ 方向被他反过来说："真正好的工程师能以某种方式把它放进自己的工作流，而在那种方式里，AI 开始训练他们"——训练的内容是 "怎么跟它说话、怎么从它那里拿到最好的东西"。
• ⚠️ 被追问"这是模型特定的吗"，他的回答是分两层：不同模型有 nuance，但存在一套"和 AI 工作的方式"，也存在一套"和不同 harness 工作的方式"——他试过 OpenCode、Codex、Claude Code，"不同的 harness 在管理上下文、思考问题、何时起合适的子 agent、以及该告诉它什么样的 prompt 上做法不同"。
• ✅ 他给的具体 harness 知识："用 Claude Code，如果我不告诉它'别为了做基础研究起 20 个 Fable agent'，它就会去起 20 个 Fable agent 做研究，把你的 token 全烧掉。"

Dylan Field（美，Figma CEO，2026-10）：起稿交给 AI、愿景不交给 AI

来源：All-In 2026-10-19（嘉宾 Dylan Field）

• ⚠️⚠️ "透过 AI 的镜头"——本页认为这是对"什么时候不该用 AI"给得最干净的一条判据（[00:25:12]–[00:26:13]）：
• 该用："它给你一个东西，让你越过空白页、空白画布的问题。你可以对着它反应，说'这些我不喜欢，我去改'——这种来回很有用。"
• 不该用："如果你心里已经有一个愿景、有一个关于它该长什么样的观点，却把实现交给 AI，你就是在透过 AI 的镜头去做它。AI 有它自己的分布，你拿不到你真正想要的东西。"
• ✅ 分界线是"你心里有没有已经成形的目标"，而不是任务类型。
• ✅ Figma 的一条内部规范（可直接照搬的做法）（[00:24:12]）：任何用了 AI 的写作，在最上面标一行 "written with AI"。 他说内部有人拿它开玩笑，但大家确实在做。
• 理由是信任而不是合规："这样我们看到一个东西的时候，就都能相信它被照料到了值得你花时间去读的程度。" 他预测信任会出现分化（bifurcation），而"取得信任的一个方式，是用自己的手去做点什么"。
• ⚠️ 他描述的反面现象："我已经从很多人那里听到——'唉，今天又收到一份 AI 做的 deck'；我甚至不知道做它的人有没有写过它，他们自己知不知道里面是什么。"
• 工具侧的对应设计（[00:26:13]、[00:31:16]）："让 code 成为画布上的一种材料"——想搭建就搭建、想动手就动手、两者快速来回；节点式产品 Weave 可把一个模型的输出接到另一个的输入上。哲学句是 "用 AI 生成本身不坏，但你需要一种方式去塑形这块黏土。"
• ⚠️ "AI psychosis moment"（描述使用者，不是描述模型）（[00:32:18]）：新模型发布后几天，算法推荐把最好的结果推到顶，所有人都说"这模型就是一切"；几天后"我知道这个模型的主要套路了"，新鲜感消失，于是问"我怎么往前走"——"这似乎是我们一直在转的那个循环。" ✅ 本页记为一条关于"模型发布期的判断噪声"的实用提醒：发布后几天内的社区体感被算法选择性放大，不宜当作能力评估。

⚠️⚠️ Jean-Denis（美，Town CEO，2026-10）：tinkerer 瓶颈——"你不需要更多智能"

来源：a16z 2026-10-19（嘉宾 Jean-Denis / Town） ⚠️ 主持人是嘉宾公司的投资人与重度用户；下面取的是机制而非产品评价。

• 核心句（[00:46:26]）：他举的例子是一家海岛上出租冲浪板和沙滩车的小生意，用 agent 比对照片判断器材有没有损坏、据此决定退不退押金（"这不在我的 128×128 宾果盘上"）。归纳是——"真正发生的事是：那家小企业里有一个 tinkerer，有件事让他烦，然后他想出了怎么自动化。让它成立的是那个 tinkerer。问题在于世界上 tinkerer 不够多，或者说有时间去当 tinkerer 的人不够多。我认为这就是 AI 扩散不开的原因。"
• ✅ 他把这条做成了可证伪的对照（[00:46:26]）："过去 12 个月里，Claude 或 ChatGPT 里一直存在能让很多小企业省下大量时间的功能，但他们实际在做的是把它当成一个更好的 Google 搜索。"
• ⚠️⚠️ 原因归到产品形态而不是用户素质（[00:47:27]）："因为产品体验不能只是一个文本框。你没法教会一个人。你得直接把价值主张展示给他，并且替他做掉。"
• 落点（[00:48:28]）："你不需要更多智能。智能已经在那儿了。问题是怎么把它有效地大规模部署下去。" ✅ 本页标注这是本页收录的全部扩散类材料里，唯一一条明确把瓶颈从模型能力移到产品形态上的，并且给出了地理解释（"硅谷我们都在工程师旁边上班，公司里到处是 tinkerer；世界上绝大部分地方没有"）。

⚠️⚠️ "token 分配机"：怎么决定一件事值不值得交给 AI

• 框架（[00:23:14]）："我把产品想成一台 token 分配机。我们给人选项，告诉他可以把 token 用在哪儿，然后由人决定要不要那个结果。" 机制是成本下降 → 可做的事的集合扩张："随着 token 变便宜，会有越来越多你以前绝不会用今天这么贵的 token 去做的地方，而那些地方你以前更不可能用人去做。"
• ✅ 一笔可以照搬的账（[00:24:15]–[00:26:16]）：餐馆的批发商每月/每季发来上万条的价目表，理论上该每季比价，实际没人做（"它很烦，不属于你的日常运营，你也没有全职的人干这个"）。换成定时跑的 agent——"一个月跑一次大概一美元。十二个月里十一个月什么也没找到，而那一个月会给你找回几百、甚至几千美元。" ✅ 判据不是命中率，是期望值 × 成本极低。
• ⚠️ 他认为难点在"用户不知道该要什么"（[00:26:16]）："我们的活儿是把这个机会摆到他面前，因为他不会觉得那件事有价值——不是他不聪明或不懂自己的生意，他很懂。"

✅ 两条可直接照搬的落地规则

• 描述能力没用，描述结果才有用（[00:51:30]）："你不能告诉别人'现在有 computer use 了'，那什么也不是。" 要换成——"我可以给这个活动做海报，长得就像你一直在 Canva 里做的那些，用你已经在付费的订阅来做，要不要我试一版？" 然后才是"要不要我以后每次在日历里看到这类活动都先做一版？"
• 逐级赢得数据权限（[00:18:12]–[00:20:14]）："agent 只有在能访问驱动你业务的数据与 API 时才越来越有效……否则它们的聪明程度就只到它能访问的数据为止。" 路径是先 email + calendar（不碰核心记录系统）→ 产生价值 → "我有没有挣到让你连 CRM 的资格？" 企业侧必须同时具备的另一半是审计日志 + 特权信息隔离 + 给 CFO 的 token 成本控制。
• ⚠️ 他给的能力进展数字（自述、无来源，本页不作为事实）（[00:50:29]）："过去两个半月里助理能做到六个月前几乎不可能的事，而且 90% 的时候能做到，以前是 30%。" ✅ 但配套那条观察可用："人们对什么可能、什么不可能的心智模型会一直是过时的"——早期采用者反而更容易把两年前的印象固化下来。

⚠️⚠️ "你没法自动化一个并不存在的流程"：企业 agent 卡在组织侧而不是模型侧（Tenex，2026-10-21）

来源：Latent Space 2026-10-21（嘉宾 Alex Lieberman & CJ Hess / Tenex） ⚠️ 说话人卖的是企业 AI 转型服务，本节全部为一方自述。

• ⚠️⚠️ 本页此前收集的多是个人与小团队的工作流，这一节第一次给出"为什么到了企业就卡住"的机制性答案（[00:22:52]–[00:23:52]）：

  "你没法自动化一个并不存在的流程。"

展开：当四十个人大致在做同一个职能、每个人做法都略有不同时，造不出在后台替他们干活的 agent。⚠️⚠️ 关键后果是没有标准化就建不了 eval——"agent 不可能知道自己做得对不对"。所以 Tenex 给企业的顺序是先把流程建起来，再谈交给 agent。 - ✅ 本页认为这条把一个被普遍当作模型能力问题的东西改写成了组织问题，并解释了他们那张漏斗表为什么在最后一级断崖（铺通用 LLM 90% → 培训 60% → coding agent 约 50% → 生产环境里的非工程 agent 约 5%，[00:19:51]–[00:20:52]；详见 AI 商业化与价值捕获）：前三级是发工具，第四级是改流程。 - ⚠️ 本页的一处追问（期内无人提出）：把四十种做法统一成一种，代价由谁承担、谁裁定哪种对？这在组织里通常是一次权力事件，而 CJ 把它讲成纯技术前置条件。⚠️ 另外"标准化 → 上 agent"隐含了一个未检验的假设：现存多样性全是冗余，而不是在吸收例外。 - ✅ 过渡形态：先别追后台全自动（[00:23:52]）——让 agent 把工作"浮"给人、人复核后打回去，人逐步变成 agent manager，"我们正处在这件事的临界点上"。🔗 本页注意到这与 Dyna Robotics 的"任务级自主不构成商业闭环" 是同构观察：单点能力够了，但接进一条能无人值守跑下去的流程还差一层。

Tenex 的内部工程实践（CJ 侧）

⚠️ 单一团队自述，本页只记形态，不作推荐。

• "meta harness"（[00:07:35]–[00:08:37]）：从标准化一组 skill 长成了仓库内一套结构化文档 + 外面一层 CLI，由模型驱动出计划、可视化、给客户的 readout。
• ✅ 最值得记的一点：agent 的决策与过程日志全部 check 进 Git——"它永远不在某个人的脑子里，永远在仓库里"。CJ 明确站在"还是需要文档"一侧，反对"代码就是代码库的记忆"，理由是你需要知道当初为什么这么决定、当时的对话上下文是什么。
• ⚠️⚠️ "随着模型变好，我们反而削减了结构上的强制"——与"给模型更多脚手架"的直觉相反，本页记为一条可被后续材料对照的实践走向。
• 模型与工具（[00:11:39]–[00:13:44]）：团队自选，当下压倒性是 Opus 5.5（"又快又便宜"、"覆盖了我原来要两三个模型才能覆盖的全程"）；Fable"我自己不怎么用，现在不少人都在默认不用它"；codex 留给偏 computer use 的任务；⚠️⚠️ 他说效果最好的工作流是"Opus 写、codex 审，让它们在你机器上来回过"。CJ 自称 AMP maxing，并说 AMP 近期支持接入自有 Claude Code 订阅（主持人估计省约 80% 成本，⚠️ 现场估算无依据）。
• 一处产品观察（[00:13:44]）：被问"Anthropic 为什么没像 AMP 的 orb 那样拿下远程环境"，CJ 的解释是 AMP 非常有主见、不做通用解，而且跨模型能力让他能"让 Opus 写、再跳到另一个 orb 去审"，这是他在 Claude Code in the cloud / Cloud Tag 上做不到的。⚠️ 单人偏好，非评测。
• 工程师自身角色的位移（[00:06:32]）：CJ 自述轨迹是"写很多代码 → 写得少一些 → 现在模型给对上下文基本能到 90%"，于是价值越来越落在"坐下来听客户把脑子倒完、再把这些喂给模型"上。

---

⚠️ 一家 5,000 人公司的 token 治理：没有排行榜，只有三级提醒（Cloudflare，2026-10-23）

来源：No Priors / Dane Knecht（Cloudflare CTO）

⚠️ 单一公司自述，本页只记形态，不作推荐。 ✅ 但本页此前关于 token 预算的材料多是"该不该给预算"的讨论（如 No Priors 双主播那期），这是第一条具体的阈值与上报结构。

模型路由：他对当下做法的否定（[00:27:21]）

⚠️⚠️ "我觉得我们居然还在让人类来决定每个任务用哪个模型，这件事挺蠢的。"

✅ 主持人接"应该被智能路由"，他答"正是如此——人类永远不会擅长那个"。 ⚠️ 而他照录的现行手工分工，本页认为是一条干净的一手流程记录：

阶段	用什么
规划	顶级前沿模型
执行（计划写出来、迭代到认可之后）	一些开源模型
review 与红队	回到前沿模型

⚠️ 他自己标了"今天这一切都相当手工"，并预期"随着大家学习和实验，人们会变得智能（路由），而且随时间会有更多治理"。

⚠️⚠️ 治理形态：阶梯式提醒，而不是配额或排行榜（[00:28:22]）

• 原则："我们没有 token 排行榜。我们不鼓励这个。鼓励大家关注产出"——"他们不是按用没用来评价，是按发了什么、建了什么。" ✅ 整体上"largely 我们让人用他们认为合适的模型和工具"。
• ⚠️⚠️ 三级提醒：

当日用量	通知谁
约 300 美元	本人收到一封邮件（"嘿，你知道吗？"）
约 500 美元	你的经理
约 1,000 美元	一位 VP

• ✅ 他给的两条观察："大多数时候人们并没意识到自己在这么干"；"这些事很少发生，而且通常人们收到这些提醒其实是高兴的。"
• ⚠️ 本页标注：他没有说这三档是怎么定的，也没有给触发频率的任何数字（"很少发生"是定性的）。

⚠️ 配套的一条组织做法：把"能不能用 AI 做"做成一个邮件入口（[00:32:24]）

今年一月他们开了一个 agents@cloudflare 的邮件别名，让人把"我这件事能不能用 AI 做"发进去，回复会给他一个 skill file。⚠️⚠️ 而本页认为这条的价值在那个揭露："有一阵子人们真以为这全是 AI、是自动化的。其实是一群实习生在帮人写 skill file。"

✅ 他给的理由是这比外部咨询更快拿到真实需求："而不是出去雇一家咨询公司来把每一件要做的事都编目一遍——是那些自己意识到'这件事看起来比它该有的难'的人在说'我想知道 agent 能不能帮我'。" 🔗 与他另一条关于把组织知识写给 agent 读的做法同源（codex → "十诫"，见 LLM 安全）。

---

⚠️⚠️ 把 AI 助手功能全部砍掉：一份被自家使用数据否掉的记录，以及"10 后把 AI 当百科全书用"（Intent / 陈春宇，2026-10-23）

来源：月球大叔 / 陈春宇（Intent 创始人）

⚠️ 创始人自述，无绝对用户数支撑，本页只记形态不作为普适结论。

⚠️⚠️ 被否掉的那几个功能，正是当下最常见的几个（[01:00:57]–[01:01:58]）

他们在一个基于 Telegram 开源客户端做的 AI 版第三方客户端上，把以下功能全做了一遍：群聊事项总结、AI 搜索聊天记录、长按消息问 AI、自动备注、自动群管理。

	数据
上面那些 AI 助手功能	⚠️⚠️ "我们一看数据，每两三天用一次。那这不足以就是形成一个需求。"
⚠️ 顺手做的 AI 翻译	⚠️⚠️ 有用户把每月 3,000 条额度用满并付费（✅ 而订阅本是为防恶意刷量做的限流）

⚠️⚠️ 结论：Intent 第一版"把自己早期去构想的很多 AI 助手的功能全部都砍掉了，然后就只做了翻译这一个功能"。

✅ 本页认为这条值得保存的三个理由：⚠️⚠️ ① 这是本库第一份"AI 功能被自家使用数据否掉"的一手记录；✅ ② 判据是频次（每两三天一次 vs 把月额度用满），不是满意度或 NPS；⚠️ ③ 付费信号是意外产生的——防刷量的限流变成了需求验证。 🔗 与 Moshi 的"我把系统建好了……没人点" 并读：⚠️ 那条只有失败侧，这条给了被用的那一个作对照，因此判别力更强。

⚠️ 2023 年初的 multi-agent 尝试，以及当时的能力边界（[00:49:44]）

2023 年初他们就做了 multi-agent 协作 / swarm 系统——有 SDK、有整套文档、有自己的平台，⚠️ "然后没有用户"。⚠️⚠️ 而放到一门真实课程里时需求的形状完全不同："大家的需求是问答，是匿名提问，是结合课本和课件的问答——就是去做 RAG，然后是课堂管理。"

⚠️⚠️ 他给的能力限制那句很具体，本页认为这是一条有用的 2023 年基线："那个时候 AI 也没有像现在那么多智能，我们做不到把所有的接口都暴露给 agent 以后他能够自己操作，所以我们要写大量的中间件脚本。"

⚠️ 一条关于不同人群怎么用 AI 的一手观察（[01:26:29]–[01:27:29]）

⚠️ 样本是他们邀请用户分享的聊天记录，无规模：

• ⚠️⚠️ "10 后会把 AI 当百科全书用"——问的是生活中的事（"这个菜能不能吃""这个鸟叫什么"）；✅ 对照是"跟我们用 AI 很多时候帮我写邮件、处理账单是完全不一样的"。
• ⚠️⚠️ 老人、小孩与 non-tech 用户"会跟 AI 说谢谢"，⚠️ 而他顺带给了工程含义："这个往往在你缓存做得不够好的时候，是个巨大的 token 消耗。"
• ✅ 对照句："如果你是一个硅谷的工程师，你是不会在 Cursor 帮你改完代码之后跟它说句谢谢的。"
• ⚠️ 他提到"现在加了一些法律在限制人和 AI 进行情感连接"，未给出处，本页不采信该表述。

✅ 一条一手的 Cursor 早期观察（他自述是早期用户，[00:59:56]）

Cursor 早期直接 fork VSCode 在上面改，⚠️ "改完完全是负优化"——内存占用特别高、崩溃时"直接把 VM 实例一起带崩"、做代码索引"甚至会让服务器直接死机"。⚠️⚠️ 他的结论是"但这都不影响他们可以靠这个东西验证用户的需求"，✅ 而这正是他选择先在别人的开源客户端上验证需求的理由。

---

⚠️⚠️ "最要紧的两件事是计划和验证"：一次团队里没人会写 Rust 的整体移植（Anthropic 平台团队，2026-10-27）

来源：Latent Space × Anthropic（嘉宾 Katelyn Lesse & Angela Jiang） ⚠️ 平台负责人自述，数字未经核实。

✅ 本页认为这是本库目前最具体的一个"agentic coding 改变了决策边界"的案例，因为它有前后对照、有数字、而且作者明说"以前绝不会签字同意"。

• 起点：messages API 是个 Python 单体、"CPU 效率很低"（动因见 AI 算力与基础设施 的 CPU 零和那节）。
• ⚠️⚠️ 她主动说出了那个难看的事实："我们选了 Rust，而这在当时是个疯狂的决定，因为纸面上很明显，但我们团队里一个会写 Rust 的人都没有。"
• 分工："Claude 会写代码，而人去设计系统"；✅ Claude 的第二个作用是帮工程师互相碰想法、学会设计这个系统所需要学的东西。
• ⚠️⚠️ 而这条判断本页认为是全期最该被引用的一句：

"最要紧的两件事是做这件事的计划，和对这件事的验证。因为实际的实现就是 Claude 在写代码。"

• 可复制的做法：用 Rust 做了整个 API 的 fork → 跑影子流量 → 逐一验证两个系统的输出一致；✅ 刻意抵抗范围膨胀（"它是一次纯粹的 port"）；⚠️ 组织形态是一支小 SWAT 团队边做移植、团队其余人继续往 API 加功能，所以那支小队还得处理"你在这边加了功能却没考虑 Rust 那边"的静态分析告警。
• 结果：CPU 省约 40–50%、首 token 时间改善 10%–20%。
• ⚠️⚠️ "以前为什么不可能"的对照："你绝不会签字同意这件事。它会花好多年。你不会一次做完，你会把系统切成一块块。"

✅ 配套的三条实践建议

• eval（[00:48:21]–[00:50:22]）：⚠️⚠️ "你大概需要的是更多，而不是更少"；"投入不足大概是我们看到大家最大的错误"；✅ 同时"从简单开始"——⚠️ "有些人会看着那一整菜单的选项发疯，而在他们做这些事的时候，他们实际拥有的 eval 数量是零。" ✅ 而 Claude 很擅长造用来评估 agent 的 eval；🔗 更多见 评估与 Benchmark。
• 多智能体（本页认为是全期最可直接执行的一条，[01:44:51]）：一个 lead + 把任务拆开，✅ 只有两个要求——子 agent 之间异步、互不阻塞，以及共享统一状态。⚠️ "除此之外，就让它跑，看看 Claude 给你设计出什么。" ✅ 她的预测是架构会往这个方向收："Claude 会学会怎么拆分自己、调整自己去适配有意义的架构。"
• ⚠️⚠️ "文档 → skill"的位移，而且提供方是模型厂商自己（[01:37:47]–[01:39:49]）：cookbook 在变没用——⚠️ "你现在不太处于那种'复制粘贴代码然后用'的位置了"（她举的例子是团队里有人写的 computer use cookbook"至今让他难忘，因为它复杂得离谱"）。✅ 现在的形态是把 Claude API skill（由 DevRel 团队拥有）加载进编码 agent，或者"把 Claude 指向一个参考架构"。⚠️⚠️ 主持人的概括被确认："DevRel 最高杠杆的形式，是把所有最佳实践蒸馏进那些 agent 里去。"**

⚠️⚠️ 两条关于 slop 的规范，其中一条是新的

（[01:20:40]–[01:26:41]）

• 旧的那条：人仍然对质量负责——⚠️ "如果你让 Claude 整个生成一个东西、自己完全没花时间读过，那你就是把一整份额外负担推给了消费者。"
• ⚠️⚠️ 新的那条，本页此前没有："Claude 味（Claudisms）"本身成了问题——比如中间有一个破折号，读者的脑子就会跳成"我在读 Claude 写的东西"然后烦了，⚠️ "而也许那个人其实真的花了很多时间确保它高质量，只是用了 Claude 帮忙。" ✅ 所以规范是双向的：真 slop 退回去，但"别对那些小小的 Claude 味太挑剔"。
• ⚠️⚠️ 而工程侧的说法更强，本页必须标出（[01:23:41]）："对很多被写出来的代码，你真正需要的其实只是快速盖个章就继续走，你不一定需要有人深度评审每一行代码"——理由是更在意整体设计，并"依赖一大堆验证"。
• 🔗 ⚠️ 这与 Erik Bernhardsson 五天前的"代码评审我们当成可选的" 是同一结论的两次独立出现，而这次来自模型的生产方。 ✅ 两者都把质量保障从"评审"挪到了"验证"，⚠️⚠️ 而两者都没有给出验证覆盖率的数据——本页认为这是这条结论目前最大的空缺。
• ✅ 产品侧的版本：⚠️⚠️ "用模型能力的正确方式不是把 10 倍多的功能塞进生产"（她们引的一条推文），而是花更多时间理解用户、做实验；⚠️ 诊断是"一种正在冒出来的内在的懒"——"我根本不用去想流程里的某一部分了，因为 agent 在做"，"但那些仍然是极其基础的部分"。⚠️ 主持人自述的反方也被照录："因为实验成本这么低，我就觉得我应该做更多。"

---

⚠️⚠️ 为 agent 改造既有基础设施：声明式 schema、mode collapse、AI 支出横向数字（Supabase，2026-10-28）

来源：Latent Space / Supabase（Paul Copplestone & Ant Wilson） ⚠️⚠️ 利益相关：该期主持人是 Supabase 天使投资人，且该期是该播客首个赞助期。

⚠️⚠️ 一、声明式 schema：本页最干净的一个"为 agent 改掉行业标准"的例子

（[00:58:28]–[01:00:29]）✅ 本页此前关于"agent 作为用户"的材料多半停在原则层（Matt Garman 的"agent 作为用户"、Modal 的 AX≈DX、本页上文 Neon / Lakebase 那条）。这一条附带了一个被改掉的具体行业标准。

⚠️⚠️ "一般你跟 Postgres 打交道的方式是：每做一次改动就往 migrations 文件夹里加一个文件，它是一份历史日志。好，这很好，这是行业标准。但你想象一下，把一个 agent 丢到一千个文件上，问它'这张表是什么形状'——它只能在一千个文件里猜。"

• ⚠️ 替代办法被明确否掉："或者你得在本地把数据库拉起来、把 migration 跑上去、再去 introspect 这个数据库——但那太慢了。"
• ✅ 做法：把本地 supabase 文件夹里的 schemas 目录变成数据库的完全声明式状态（表、策略、数据库注释都抓进文件），发布新库 PG Delta，可用于任何 Postgres。
• ⚠️⚠️ 而那条关于 agent 的工作假设比实现更值得记："我们知道 agent 大体上会在代码上操作。它们不想去触达任何别的东西。它们必须在文件系统上非常快地迭代。"
• 公司形态的位移（他自己的讲法）：dashboard 公司（"那时候那是最好的 DX"）→ headless → "今年我们的大重点是从 dashboard 转向 code-first、git-native"。
• ⚠️⚠️ 而主持人在片头给了这件事一句反向注脚，本页认为这是本条最该被跨页引用的部分（[00:03:01]）：

  "我现在差不多把 Supabase 的势头看成是在做 Postgres 开发的最后一公里——让 agent 能真正很好地用它。但美妙之处在于，它其实并不是关于 agent 的。是我们一直都需要这个东西。所以人类也一样受益，我真的很喜欢这一点。我不喜欢只为了让 agent 高兴而做事。"

• ⚠️ 一条顺带的因果，形状值得记（[00:53:26]）：他们做不了 durable workflow 的原因不是产品优先级，而是一个运行时上限——"我们做 durable workflow 缺的是什么？compute"；社区在 functions 上搭 workflow 引擎"就是不行，因为那个 2 秒超时"。

⚠️⚠️ 二、mode collapse：担忧来自这波最大受益方之一

（[01:01:31]–[01:03:32]）✅ 本页认为这是本库目前关于"agent 会不会收窄软件工程"最完整的一次正反对话。

⚠️⚠️ "作为一个已经写了几十年软件的人，你对软件该怎么造是有强观点的……我发现我自己在把我的观点推给 agent。但现在越来越地——你不需要了。而我的担忧是：它们会不会全都收敛到同一种造软件的方式？" ⚠️⚠️ "所以你想要观点上的多样性，这样最好的想法才能胜出。但接着，模型会让你懒到根本没人去看细节。然后它们就全都收敛到同一种造软件的方式——而这会不会是个局部最优？"

• ✅ 主持人给它起名 "mode collapse"，⚠️ 而他的回答分两层：① "这是个有效的恐惧，但我觉得这不在你的控制范围里"；② 分层——⚠️⚠️ "低品味的、姑且叫随意的 app builder，会收敛到那个均值、那个模型。但那些有鉴别力的高技能的人，会一直真的在意细节，而且他们应该在意"，然后"它会逐层下渗"。
• ⚠️⚠️ 而嘉宾的追问本页认为比回答更有力，因为它指向这条机制的再生产问题："但这些高技能的人，还会继续被培养出来吗？"
• ⚠️ 主持人的回答是不确定 + 一条外推："我不知道。我确实觉得人们足够有热情。" ⚠️ "我确实觉得一般的大学大概完蛋了。" ✅ 依据是"一直都是这最顶层的一批人在推动很多事"，例子是"那种休一年假去 Recurse Center、就为了做些有意思的编程问题的人"。
• 🔗 ⚠️ 本页标注这与本库近期两期材料落在同一个未解问题上：Alpha School 的"两小时完成 85%" 与 Lex #503 那位数论学家的"学你头脑能承受的最难最抽象的数学"——⚠️⚠️ 当工具把下限抬起来之后，上限那批人还是怎么长出来的。本页不裁决，只记下这是三期独立材料里反复出现的同一个问题。

⚠️ 三、AI 支出：本页目前最具体的一组横向数字，口径全部由说话人自定

（[01:10:37]–[01:13:37]）⚠️⚠️ 以下四行为主持人口述、无来源，本库不采信具体值，只记为"一位长期观察者的经验值"。

口径	数字
一般个人	约 20 美元 / 月
一般员工	约 200 美元 / 月
OpenAI 的 50 分位员工	约 3,000–5,000 美元 / 月
最高分位	"可能是几十万美元"

• ⚠️⚠️ 而他给的那个比率比绝对值有用，因为它无量纲："一个好指标大概是你的 token 支出对人力支出的比率。对很多人来说可能是 0.1；你大概可以安全地做到 1；而如果你超过 1.5，你大概有麻烦了。" ⚠️ 本页标注：没有给出任何依据。
• ⚠️ Supabase 自己的数字（自述）：约 30 万美元 / 月、450 人（⚠️ 先说 600，被当场纠正）。✅ 本页按算术粗算约 667 美元/人/月，⚠️⚠️ 但本页标注这不是他们给的指标，而且他们没给人力成本，所以上面那个 0.1 / 1 / 1.5 的比率在这里算不出来。
• 内部政策是不管：⚠️ "Supabase 一直感觉像一堆不同的创业公司粘在一起"——各团队自己决定工具、运作方式；"AI 政策基本上没什么不同：很多人问 AI 编码政策是什么，我们说——这取决于你们团队自己。" ⚠️ "我们确实开始合并了一些，特别是围绕成本。"
• ⚠️⚠️ 而这条本页认为否掉了整节的记账方式（[01:13:37]）：

  "重点不该是你花了多少钱，而该是——用系统思维看，你端到端解决了多少个流程，让那里不再需要人在环里；或者把本来长时间占用人的问题，压缩成突然很短的问题。"

• ⚠️ leaderboard 的副作用："我们弄了个排行榜，贴出来之后大家一般都有点羞愧。" ✅ 而主持人的双向解读被确认：⚠️ "那是你对其他所有人的投资，而且大概非常偏态——公司里有两三个人超级猛，其他人大概根本没在用 AI。" / "这正是我们看到的。" 🔗 与本页上文"token 治理：成本失控与组织行为学"一节里的偏态观察互为印证。
• ✅ 而"异步公司 = agent 友好"这条本页认为是本期最被低估的一点："因为我们是异步公司，Supabase 发生过的每一件事都有文档。所以围绕 Supabase 建一个公司级的 harness，基本上就是把它形式化：你可以把 AI 指向它，问'我们的原则是什么'，它会把我们整个历史上的决策原则都记录下来。" ⚠️⚠️ 本页标注：这是本库第一条把"远程/异步的文档习惯"直接讲成 agent 时代的资产的材料。

⚠️⚠️ 四、"AI SRE 还没被破解"：一家把实现大量交给 agent 的公司在招运维

（[01:13:37]–[01:15:37]）

⚠️⚠️ "我公开说过，AI SRE 是 agent 创业里最难的类目之一。我觉得我可能很快就会被证明错了，但到目前为止是对的。AI 还没破解它。" ⚠️⚠️ "造软件是——姑且说可以争论——被解决的问题。而维护、让东西一直跑着，是完全另一头野兽。"（✅ 嘉宾："不不不不，还没有。我同意。"）

• ⚠️ 而他们最想招的岗位恰好就是 SRE（"我们在以荒谬的速度增长，我们需要所有能拿到的 SRE"；约 50 个开放职位、完全全球远程、同薪）；✅ 筛选标准不是技术而是"你真的想远程工作"（"这真的不是所有人都适合的，我们很早就学到了"）。
• 🔗 ✅ 本页标注这与本库既有材料的同构：Dyna Robotics 的"机器人本身需要个保姆"、Decagon 的工作流复杂度分级——⚠️⚠️ 任务级能力达标 ≠ 运维闭环。✅ 而本页认为这一期的版本最值得记，因为说这话的公司愿意把写代码交给 agent，但要把"让它一直跑着"招人来做。

---

⚠️ 一条非工程师搭起来的开放记录挖掘流水线，以及"合同 prompt"（Mark Cuban，2026-10-28）

来源：a16z × Mark Cuban ⚠️⚠️ 立场：他全程在推销 Cost Plus Drugs（✅ 自己三次主动声明"我在卖自己的书"）；节目是 a16z 自己的播客，主持方是该赛道投资人。

⚠️⚠️ 一、把最高杠杆动作压缩成一个 prompt

（[00:18:17]–[00:22:21]）

⚠️⚠️ "把你现有的福利合同——不管是经纪人、顾问、TPA 还是 PBM 合同——过一遍 AI，用一个只问一个问题的 prompt：他们在哪儿坑我？我该怎么办？30 秒之内，你就会看到 bam bam bam bam。"

• ⚠️ 门槛他给了："如果你有超过 1,500 名成员"，收益"按你被坑的程度，可能是几百万甚至更多"。
• ⚠️⚠️ 而本页认为更该记的是他给的能力边界："一旦你签了那份带着你没完全理解的条款的合同，他们就赢了。地球上没有任何 AI 能保护你。" ✅ 所以这条实践的全部价值在签约前，而不在履约期——本页此前的合同/法律类用法材料没有这条时序限定。

⚠️ 二、流水线本身（本页目前最具体的一份非工程师搭建记录）

（[00:18:17]–[00:20:18]）⚠️ 他自述同时订阅 Grok / Gemini / OpenAI 等多家，另有两个本库无法写定的产品名。

1. "去给我找到每一个有开放记录（open records）渠道的州级实体、组织、企业。"
2. "把你能找到的每一份合同、RFP、随便什么都给我找出来。"
3. ⚠️⚠️ "然后帮我把索取这些材料的信写好，放进邮件，放进我的草稿箱，让我自己改一点，弄好了告诉我，我按发送。"（✅ 人保留在发送这一步，这是本页少见的一处明确的 human-in-the-loop 位置选择。）

4. 收回来的材料放进 Google Drive，每个 LLM 都有访问权；⚠️ "每次 Drive 上有新东西加载进来，你就过一遍，告诉我好消息、坏消息、该做什么，然后再给我一个简单版本，好让我发给那家公司或学校。"

5. ⚠️⚠️ 他对这件事的定性本页认为是最该跨页引用的一句："那些一直在清单最底下、我一直想做但永远做不到的事。现在它就这样来了。"

6. ✅ 产出被用在真实业务上：他说靠这个看到了"大三家在 PBM 侧、保险巨头在 ASO 侧签的所有这些合同"，于是能具体看到"那些学区、从丹佛到达拉斯到沃斯堡的城市、工会"是怎么被宰的。
7. ✅ 跨模型互检是他的例行做法（[00:57:46]）："从一个开始，然后说：嘿，你的一个同行就这份合同说了这个，你怎么看"；⚠️⚠️ "我把两台手机举在一起，把输出拿过来，让它们互相对话，这样我能在旁边听。"
8. ⚠️ 而他对可靠性的态度没变："你确实必须检查输出"，✅ 配他反复用的类比——"就像当年第一批电子表格，人们还留着他们的十键加法机，拿来核对表格对不对。"

⚠️ 三、给 C-suite 的教育清单，以及"模型延迟"

（[00:27:26]–[00:30:28]）✅ 本页认为这份清单值得记，因为它把"高管该懂什么"落成了四项具体内容。

• 他要教的是：agent 怎么工作、怎么用模型、开源与闭源模型的区别，⚠️⚠️ 以及模型延迟本身——"帮他们理解模型的延迟：我们三个人现在进行的这场对话，在任何地方的任何模型里都不存在，而且在它被发表之前都不会存在。" ⚠️ 他还加了一条模态限制："LLM 是文本和一些图片，不处理视频里正在发生的那些真实世界的东西。"
• ⚠️⚠️ 那句定性是他的招牌："AI 不聪明。它也许是书本上聪明，但它不是街头聪明，不是创业者式的聪明。你必须有个人在那儿引导它、帮它。"
• ✅ 而那个可复现的失败案例本页认为比清单更有说服力（[00:29:27]）：某消费食品公司负责人正谈 GLP-1 下的并购，⚠️⚠️ Cuban 当场让 ChatGPT 为对方的头号饼干造一个"更 GLP-1 友好、定价更低"的竞品，要完整物料清单、来源与制造方式——"大概三分钟我们就拿回给他了，他说：噢，操。他完全不知道。"
• ⚠️ 主持人的追问定义了要点："如果你不知道，那是个你可以问 LLM 的问题。而你不知道的是怎么让你的公司用上 AI——那才是大多数组织更大的那个挣扎。"
• ⚠️ 他给的瓶颈是心理上的（[00:57:46]）："现在创业者用 AI 最大的挑战是跟你的 AI 说话的那种自在程度，不管是语音还是打字——因为还有很多犹豫。" ✅ 而最后那条建议值得记：⚠️ "别害怕在那些让你感觉很不舒服、很怪的事情上用 AI，因为那种不舒服大概就是通往某个开创性东西的路。"
• ⚠️⚠️ 本页另记一处必须与"地下室里的万亿富翁"一起引用的自我限定："我们还没看到那种公司——'噢，那是什么？他们为什么在做那个？'那种。我们现在还没看到。" ✅ 这是一条自述的否证条件，出自说"会有地下室万亿富翁"的同一段对话。

---

⚠️⚠️ "工程团队先用上 AI 是因为他们有 code review"：一条把采用滞后归因到流程的论证（Serval，2026-10-29）

来源：No Priors × Serval（Jake Stauch） ⚠️ 立场：他在卖 Serval（企业自动化，对标 ServiceNow），陈述为自述；节目由投资方主持。

⚠️⚠️ 一、本页此前没有的第四个原因

（[00:03:01]–[00:04:02]）✅ 本页关于"为什么企业里 agent 还没落地"的材料此前把原因放在三处：数据治理（Ali Ghodsi）、工作流复杂度（Decagon）、流程知识（Lassie 的"模型不知道这份工作怎么做"）。⚠️⚠️ 这一条给了第四个，而且它带着处方。

⚠️⚠️ "如果你想想为什么企业里早期的 AI 采用都在工程团队——当然他们在很多技术上都是早期采用者——但也因为他们能建、能拿这些工具做实验，因为他们有 code review 这个流程。哪怕一个 19 岁的实习生去建一个很强的东西，再走这个流程然后进生产，这件事都是很安全的。" "我们想把同样的能力带给企业的其余部分。"

• 处方的形态：把 coding agent 给 IT 部门，IT 再给 HR / 财务 / 人力 / 法务；⚠️ "底下是 coding agent，但上面有这些抽象、护栏和控制，所以东西要走审批、走 staging 与审批周期、留审计轨迹。"
• ⚠️⚠️ 而配套洞察改变了"谁是建造者"："对世界上大多数组织来说，他们没有工程部门，他们有 IT 部门……是 IT 在为公司建和配置技术。" ✅ 加上一句他反复强调的："IT 其实是想建东西的。"
• ⚠️⚠️ 而把 SDLC 带进 IT 自动化是他给的第一条设计原则（[00:17:10]）：dev → staging → prod + 闸门 + 分支；⚠️ "大多数新的 AI 产品没有接受这一套，它们基本上在说：我们来建这些酷 agent，然后直接发到生产。"
• ✅ 本页标注这四个原因不冲突，而这一条最容易被照搬：⚠️⚠️ 它意味着"让非工程部门用上 agent"的第一步不是选模型，而是给他们一套 staging 与审批。

⚠️⚠️ 二、一个被建起来又被模型吃掉的脚手架（本页第三例）

（[00:10:09]–[00:12:09]）

• ⚠️ 赌注与它的校准："赌的是 coding agent 会变得非常好，理由是这是一个可验证的领域，应该能相当好地爬坡"；⚠️⚠️ "我没预期它们会在通用软件开发上好到今天这个程度，但对重置密码、取得审批这种确定性的程序性脚本，定义得太清楚、太可验证了。"
• 桥接期的做法：⚠️ "在所有早期 demo 里，我们会提示 LLM：这是一个你可能想怎么建密码重置工作流的建议做法。我们用很多例子给它打底，然后随时间把那个库做得越来越大。"
• ⚠️⚠️ 然后它作废了："但后来模型就是变得太好了，最后变成很难把它弄坏——很难给它一个它自动化不了的工作流，只要那些 API 存在。"
• ✅ 本页标注"只要那些 API 存在"是这句里真正的限制条件：⚠️⚠️ 瓶颈从"模型会不会写"转移到了"目标系统有没有接口"。本页认为这条转移比"模型变好了"本身更可引用。
• 🔗 ✅ 本页记为"围绕当期模型缺陷建的那层东西有半衰期"的第三例：Lovable 的"写 skills 阻止 agent 对数据库干蠢事"被模型自己吃掉（10-28）、Anthropic 的"在一些负载上智能看起来越来越饱和了"（10-27）、以及这一条（10-29）。

⚠️⚠️ 三、"文档/培训 → agent"的第三个独立样本，而这个最彻底

（[00:27:16]–[00:29:17]）

• ⚠️ 第一代的问题是通用的："你能建出非常了不起的复杂系统，但然后你得训练人去理解你全部的产品原语、以及这些系统怎么拼在一起"；⚠️ 第一代的解法是人（"我们派出所有这些 FTE 去跟客户解释……其实，让我直接帮你建吧"）。
• ⚠️⚠️ Catalyst 是"一个为管理平台而做的 agent"：建底层自动化，同时配置审批规则、权限检查、各种策略，理解整个部署。✅ 落点是："现在我不需要你去把自己训练成会用 Serval 的人。你可以直接跟一个真的懂怎么用 Serval 的 agent 说话，而那就是你进入产品的主界面。"
• 🔗 ⚠️⚠️ 五天内第三例：Anthropic 的"cookbook 在变没用、Claude API skill 由 DevRel 团队拥有"（10-27）、Supabase 的"把 Claude 指向一个参考架构"（10-28）、这一条（10-29）。✅ 共同形状是：产品的学习曲线不再由文档承担，而由一个懂这个产品的 agent 承担。⚠️⚠️ 而这一条最彻底，因为 agent 直接被做成了"主界面"。
• ✅ 而"空白画布问题"这个名字本页认为值得记：⚠️ "老一代自动化里你面对的是：我该从哪儿开始？" → 现在"产品会问：你想从哪儿开始？"，而且"你可以说：我其实不理解那个，你在说什么？能给我解释一下吗？" ⚠️ 他的定性是"它确实变成了一个建造伙伴"；✅ 而主持人加的那条是关于用户的："agent 能在建东西的过程中把用户带着走，这其实在抬升一大批用户的技术能力。"

⚠️ 四、把强原语交出去，而不是把它包起来

（[00:25:15]–[00:27:16]）

• ⚠️⚠️ 他先否了"IT 不懂技术"这个前提："IT 其实比很多人愿意承认的更接近软件工程师。尤其在大企业里，IT 部门在很多情况下就是那支工程团队。"
• ✅ 立场是"把他们当成年人对待，给他们我们会给软件工程师的那些工具"，⚠️ 但有一条限定："我们不只是把 Claude Code 丢给他们然后说祝你好运。" ✅ 分 persona：一端是会写代码的 IT 工程师，另一端是"永远不想看到代码、但仍然想要底下 codegen 的灵活性"的市场/人力部门的人（"因为他们有一个复杂工作流，而他们不想靠拖拉拽把它拼出来"）。
• ⚠️⚠️ 而对既有产品的批评最锋利："外面很多产品其实对 IT 有点居高临下：'噢，你其实不懂这些东西，所以你需要这个被阉割过的、更有主张的、更简单的版本。'实际上 IT 欣赏这种复杂度。"
• 🔗 ✅ 本页标注这与 Supabase 那条"声明式 schema 是为 agent 做的，但人类也一样受益" 是同一类判断（都在说把强原语交出去），⚠️ 而这一条更难，因为接收方不是开发者。

---

⚠️⚠️ 制造技师用 Claude 二十分钟换产线：一条受益人不是工程师的用法（a16z American Dynamism，2026-10-29）

来源：a16z × American Dynamism 50（Connor & Aaron/Erin） ⚠️⚠️ 立场：a16z 自己的播客，两位是 a16z 投资人，讲的是自家组合，数字为自述、无第三方来源。

（[00:14:05]–[00:15:06]）⚠️⚠️ 本页先标出转录稿的术语错乱：high-mix / low-volume（多品种小批量）与 low-mix / high-volume 在这段里被说反了；✅ 按上下文，难自动化、换线成本高的那一类是多品种小批量，本页按此理解。

• 旧的经济学：⚠️ "如果你要花很多钱搭一条高度自动化的产线，你真的需要在生产大量的某一个单品。那才是你把成本降下来、才 justify 得了投资一条相当定制的产线的方式。"
• ⚠️⚠️ 而变化落在人身上，本页认为这是本条的全部价值：

  "制造技师们本身有这种直觉，而现在他们有了软件工具，能够改变多品种小批量生产在产线上的经济性。" ⚠️⚠️ "所以你可以有一个制造技师——这不是有大学学位的人，这不是学过软件工程的人——现在能够用这些工具去重编、重配他们的产线，靠的是他们理解制造流程、他们知道自己在物理世界里在做什么。" ⚠️⚠️ "你不用再打电话叫系统集成商——那要三个月、几十万美元才能为一个新配置把一条线重配好。你可以让一个制造工程师用 Claude，二十分钟搞定。"

• ⚠️⚠️ 本页标注三处限定：① 自述、无来源、无案例名；② "三个月／几十万美元"与"二十分钟"未必是同一范围的工作（系统集成商交付的通常还含验证、安全与责任承担）；③ 同一段里"制造技师"与"制造工程师"两个称谓被混用，而这在工厂里不是同一岗位。
• ✅ 但本页认为这条仍然值得保存，因为它指认的受益人在本页此前的材料里几乎没出现过：⚠️⚠️ 没有学位、不写软件、但掌握流程知识的现场技术工人。 🔗 本页上文的用法材料几乎全部围绕开发者、研究者、投资人、律师与客服——这是第一条落在车间上的。
• ✅ 而上游价值那条因果比那个倍数更可引用（[00:15:06]–[00:17:06]）：产线更可转、更可调 → 原型能更快迭代 → 各部件更快进入量产节奏；⚠️⚠️ 否则顺序是反的——"等你终于把一枚量产级的导弹或飞机定下来，你才突然得回头去重新折腾、把所有这些子系统建起来以满足规模。" ✅ 主持人的概括被确认："你从一开始就是在为可制造性做设计（design for manufacture）。"
• ⚠️⚠️ 而同一期里那条反银弹陈述必须和上面这条一起引用："AI 还不会拧扳手。它某个时候会，但我们离那还远"；"不是某一颗银弹突然让一座工厂或一座矿完美。实际上是 15 到 20 件不同的事。" ✅ 而"15 到 20 件事"被落到了具体环节上（报价与接单 → 零件的物理制造 → 检验 → 转运），⚠️ 机会是能逐节重问"这个过去一百年一直这么做的流程，是对的流程吗"。 🔗 完整论证见 物理 AI 与机器人。

---

⚠️⚠️ "把爱因斯坦丢进律所，他也会有相当长一段时间产出不出来"：裸智能不够的最佳表述（Eve，2026-10-30）

来源：a16z × Eve（Jay）（人物页：Jay（Eve））

⚠️ 立场：主持人是投资方（a16z），嘉宾在卖产品——⚠️⚠️ 而"模型不够、还需要我们这一层"恰好是对他最有利的结论，本页因此只取他给的理由，不取他的结论。

（[00:20:10]–[00:24:12]）✅ 而本页认为理由本身是可独立评估的，因为它们是关于数据在哪的事实主张，不是关于产品的主张。

• ✅ 他先把赌注说清楚："我们就是在赌这些模型会变得越来越好，而我们的价值恰恰在那儿。如果有一千个爱因斯坦能用来做诉讼，我们会要的。"
• ⚠️⚠️ 然后是那一句："问题是，如果你把阿尔伯特·爱因斯坦今天丢进一家律所，他会有相当长一段时间产出不出来。"
• ⚠️⚠️ 三条理由全部落在数据可得性上，而不是品牌、工作流或监管：
• ① 数据不可爬："在原告律师业，绝大多数数据其实是不可爬的。真正和解并变成判例意见的案子不到百分之一。绝大多数在索赔前或诉讼前就和解了。"
• ② 聚合在对面手里："保险公司是在和十万家不同的律所打交道……他们知道所有案子。而因为信息分散在所有不同的地方小所手里，这些小所并不知道 Geico 的每一步棋。"
• ③ 一个可以直接去验证的知识缺口：⚠️⚠️ "你去 Google'怎么针对 State Farm 的软组织损伤案写一封出色的索赔函'——这东西今天哪儿都不存在。哪怕是刚进原告律所的新助理律师，这也是他必须自己学的。" 加上"在地方管辖里，法院系统、你的对方律师，行为方式都有点不一样，而这个语境也重要。"
• ✅ 而他对"这一层到底在做什么"的概括本页认为很准："把这份历史上极难利用的多属性、多维信息，变成'在此刻我能做的最好的一件事是什么，才能改善这个案子的结果'。而同一个问题在一个案子里会重复上千次，而人脑就是没法把这些全记在脑子里——但 AI 可以。"
• 🔗 ✅ 本页标注这与本页既有材料的关系：⚠️⚠️ 本页此前的"模型很强但用不起来"材料多把缺口放在流程知识、部署与上下文供给上（Lassie 的"模型不知道这份工作怎么做"、Serval 的"缺一套安全发布流程"）；✅ 这一条给的是最朴素也最难绕的一种：那些知识从来没有被写下来过，所以不在任何预训练语料里。本页认为这条可以直接检验——去 Google 他举的那个问题。
• ⚠️ 而落地的第一处他说得很实在："他们最先看到价值的地方当然是接案（intake）：我该接谁？我擅长代理谁？也许就从这里开始，然后不断变好。"

---

⚠️⚠️ 一条带具体归因的采用缺口：Gallup 的 10%/20%，而闸门被指认为"不敢给连接权限"（All-In 第 295 期，2026-10-30）

来源：All-In 第 295 期（人物页：All-In 四位主播）

（[00:58:33]–[00:59:33]）⚠️ 口径为节目引用的 Gallup 调查，本页未核实原始调查。

• 数据：在职场每日使用 AI 与"频繁"使用（定义为一周几次）的比例，"我们说的还是 10% 和 20% 这个水平"；节目的定性是"这还很初期"。
• ⚠️⚠️ 而归因很具体，而且它是一个可检验的因果主张，这是本页保存它的理由：

  "很多头部企业不让员工以不受约束的方式使用这个，而他们肯定不让员工接上自己的邮箱、知识库、Notion、Slack。大公司不让人真正用上 AI 的能力，因为他们怕网络安全。" "所以一旦网络威胁这件事被缓解，这会从 10% 的人是日活变成 60%、70%、80%。"

• 🔗 ✅ 本页标注这与既有材料的接口：⚠️⚠️ 本页此前关于"采用断点在哪"的材料给过四个原因——数据治理（Ali Ghodsi）、工作流复杂度（Decagon）、流程知识（Lassie 的"模型不知道这份工作怎么做"）、缺一套安全发布流程（Serval 的 code review 与 SDLC）；✅ 这一条给的是第五个，而它与 Serval 那条其实是同一件事的两种表述：Serval 说的是"没有安全地放行的流程"，这一条说的是"所以连接权限根本没给"。
• ⚠️⚠️ 而本页认为这两条合起来才给出完整形状，并且它与 Serval 的"把个人 agent 带进大企业不成立，理由是权限集合太小" 指向同一个瓶颈：不是模型能力，不是预算，而是没人敢把内部系统的读写权交出去。
• ✅ 本页标注检验方式，因为它比订阅数更难被美化：看企业把 AI 接进邮箱与内部知识库的比例，而不是看座位数或订阅数。 ⚠️ 这也意味着"每个员工都买了一份"这类采购信号（节目提到的例子是 Uber 给每个员工买了 ChatGPT）并不等于那条缺口被关上。
• ⚠️ 而同期的供给侧数据可以和它对读（见 AI 商业化与价值捕获）：S-1 的客户分层显示只有约 1,900 家客户年支出超过 100 万美元，而其中剥掉 AI 原生公司后"剩下的大概是几百家 Global 2000"。 ✅ 本页认为这两组数字方向一致：单座位订阅已经铺开，而把 AI 接进核心系统的企业仍是少数。

---

⚠️⚠️ 知识库交给领域专家策展，以及用"动作类型"而不是"内容判断"去触发查证（Arca，2026-10-31）

来源：Latent Space × Arca（Aman Singh）（人物页：Aman Singh（Arca））

⚠️ 立场：他代表 Arca（AI 原生财富管理机构），实现描述为自述。

⚠️⚠️ 一、"markdown 即员工 / skillify"这条线上第一个编辑者是领域专家的样本

（[00:22:11]–[00:23:11]）

• 形态：知识库"表示成文件"；⚠️⚠️ 而维护权的归属是关键——"我们保持它更新的方式，是我们把它交给了我们的专家去策展和更新。所以它是我们产品里的一等功能——左手边有一个叫 knowledge 的标签页，里面是我们的 agent 正在使用的完整运营上下文。"
• ✅ 而纠错闭环靠引用建立："当它们在做事的时候，它们能够引用知识。于是形成这样一个循环：哦，我们注意到这个知识是错的，而那会在我们的 trace 分析里被暴露给我们。而因为它是产品本身的一部分，人们可以进去直接编辑那个 skill。"
• 🔗 ✅ 本页标注这与既有材料的差别：⚠️⚠️ 本页此前的"文档/培训 → skill"样本里，编辑者基本都是工程师或开发者（Anthropic 的"cookbook 在变没用"、Supabase 的"把 Claude 指向一个参考架构"、Serval 的 Catalyst）；✅ 而这一条的编辑者是财务顾问，而且"skill"被做成了产品 UI 里的一个标签页。本页认为这是目前"把运营知识交给非工程师维护"的最具体样本，而它的关键设计是让 agent 引用知识——因为引用才使"这条知识是错的"可以被定位到具体条目。
• 🔗 ⚠️ 而这件事的前提是商业形态（见 AI 商业化与价值捕获）：他们不是 SaaS 公司、而是那家机构本身，所以可以要求自家专家承担策展工作。 ⚠️⚠️ 本页标注这是这条样本的适用边界：一个卖软件给别人的厂商无法要求客户的专家做同样的事。

⚠️⚠️ 二、一个很干净的陈旧参数化知识例子，以及一条可迁移的触发思路

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

• ⚠️⚠️ 问题被描述成过度自信加上知识陈旧，而例子具体到可以直接复现：

  "我们注意到，当模型在处理财务数据、在回答需要财务知识的问题时，它们对自己拥有的知识非常自信。" ⚠️⚠️ "一个小例子是，模型会很乐意用 2025 年的税率档位来做出一份分析，然后说：好了，就这样。但那显然是错的。"

• 对策："在模型即将给出一个财务建议、或者任何需要财务严谨性的动作时，去检测并推动模型使用我们那个关于世界今天为真的已核实事实的知识库，或者使用它的网页搜索。"
• ✅ 本页标注这个思路为什么可迁移：⚠️⚠️ 机制是"在动作类型上触发，而不是在内容上判断"——用"这是不是一个财务建议"这个相对容易的分类，去触发"必须查已核实事实库"这条硬规则。本页认为这比试图判断答案本身对不对要可靠得多，而它可以搬到任何有时效性参数化知识的领域（税率、费率、法规版本、API 版本）。
• ✅ 而他把这件事接回了 harness 的所有权："所以这算是关于 harness、以及拥有 harness 的一点——它让你能做这样的事，帮你的模型在重要的地方准确。"
• 🔗 ⚠️ 本页标注这与既有的幻觉材料是不同层次（见 LLM 心理学与认知短板）：那边讨论的是模型为什么会编；这一条处理的是模型没有编、但用的是过期事实——而后者在产品里更难被发现，因为输出看起来完全合理。

---

⚠️ 企业产品不能从第一性原理推，以及一条由实测推翻了直觉的决定（OpenAI 金融团队，2026-10-31）

来源：Latent Space × Joseph Kim（OpenAI，ChatGPT 金融业务）（人物页：Joseph Kim（OpenAI））

⚠️ 立场：OpenAI 的产品负责人，在推刚发布的企业产品。

⚠️ 一、一条有具体落点的产品方法论

（[00:04:03]–[00:05:03]）

"在企业侧，你必须面对你所在那个行业的现实，然后围着它去建。" ⚠️⚠️ "如果你只从第一性原理去想，你能推出一个说得通的结论，你能用逻辑和理由为它辩护。但如果你在开始建的时候忽略了你所处的世界的状态、以及行业里正在起作用的那些力量——竞争的力量、人们各自的目标——那你就不会建出对的产品。"

• ✅ 本页标注这不是一句空话，因为它有一个具体落点：按第一性原理应当接生态里现成的 MCP（客户可能已有 license，打包等于让他们付两遍钱）；而实测之后的决定是自营。 🔗 那组实测数字（"某些大厂名字错误率 40% 以上"）与由它推出的商业决定记在 AI 商业化与价值捕获。
• ⚠️⚠️ 本页认为可直接搬用的是这条顺序：先把第一性原理的结论写出来，再去测它依赖的那个经验前提（"生态里的工具够不够好"），而不是让前者替代后者。

⚠️ 二、人在环作为产品预设，以及它的真实用途

（[00:10:04]）

• 形态："是给在这个领域工作的知识工作者用的生产力工具"，分析师对待办清单的每一项先用 ChatGPT 试，"它可能带你走到 30%，也可能 80%，取决于任务"。
• ⚠️⚠️ 而他对这个预设的好处给的是一个组织性答案，不是技术答案："这让我们很容易建出一个产品，把审计与复核的责任交到人们手里、变成人们的职责。"
• ✅ 本页标注这条很值得实践者记住：⚠️⚠️ "human in the loop"在很多产品里的首要功能并不是提升正确率，而是让责任有一个明确的承担者——于是它既是安全设计，也是上市前提。 🔗 安全侧的完整讨论（含那条未经论证的支点）记在 LLM 安全。

⚠️ 三、哪些任务先被自动化：能力与意愿的交集

（[00:19:07]–[00:20:07]）

• ⚠️⚠️ 他说产品方向由两件事共同决定：① "今天的模型很擅长接受相当具体的指令然后去执行"；② "有一个很强的偏好，是把模型做得擅长人类不擅长、或者不喜欢做的事"（Excel"很枯燥，非常细节导向，容易做错"；片子"你在复制 logo，把它们非常精确地放在页面上某个位置"）。
• ✅ 本页标注这对选型很有用：⚠️⚠️ 落地顺序的正确判据不是"模型能不能做"，而是"模型能做 ∩ 人不愿做"——后者决定了采用阻力。 🔗 就业含义（这使早期替代看起来比实际温和）记在 AI 与就业。

⚠️ 四、一条给在模型厂商平台上做产品的人的事实

（[00:07:04]–[00:08:04]）

• ⚠️⚠️ "我们建的东西里 95% 是创业公司绝对能做的……而且我们并不真的需要动用我们改模型的能力。" 产品大部分建在对外开放的同一套 ChatGPT plugin primitives 上。
• ⚠️⚠️ 而那条 80/20 的提醒对实践者最有用："Codex 能把你带到一个能在市场上成功的产品的 80% 左右，但那 20% 是缺的……如果你就把 Codex 拿去当成一个金融产品发布，它会失败。"
• ✅ 本页的读法：通用 agent 产品在垂直场景的"最后 20%"不是打磨，而是成败所在；而这一期自己给出的那 20% 的内容恰好是数据、UI 与集成，不是模型能力。 🔗 完整讨论与本库对它的保留（那 20% 其实需要采购能力而非工程能力）记在 AI 商业化与价值捕获。

---

⚠️ 脚手架与测量设施都在同一条曲线上，以及几条可直接搬用的工程手法（Legora，2026-11-02）

来源：Latent Space × Legora（Jacob Lauritzen，CTO）（人物页：Jacob Lauritzen（Legora CTO））

⚠️⚠️ 一、"测量脚手架的那套设施"也会被模型进步作废

（[00:11:08]、[00:58:29]）

⚠️⚠️ "我觉得直到最近，老实说做这个其实不太值得——因为模型就是都变好了。所以就是：我们要花很多时间做真的很复杂的 eval，还是我们就去建？因为把 harness 做得更好能拿到的收益太大了。" ⚠️⚠️ "我们有一个问题，是它不能正确地标引用……结果下一个模型发布就解决了。它从大概 70% 变成了 99%。我们什么都没做，而且挺好的。" ⚠️⚠️ "我们的 Word 插件就是——我们做过 map reduce，我们改过，有过一个大的，有过好几次大的。就是随着模型变化，我们一直在改我们围着它搭的那套脚手架。"

• ✅ 本页标注这条比本库既有的"脚手架半衰期"多出来的那一层：🔗 既有材料（Serval 的示例库、Lovable 的 skills、Anthropic 的"智能看起来越来越饱和"）说的是脚手架会被作废； ⚠️⚠️ 而这一条说测量设施在同一条曲线上——于是"什么时候开始认真建 eval"本身是一个与模型进步赛跑的时点判断，而他的答案在 2026 年之前是"不该做"。 ✅ 本页的实践含义：自建 eval 的收益率不是常数，它随模型进步放缓而上升；在能力还在快速爬升的阶段，把同样的时间投在 harness 上收益更高。

⚠️ 二、切块失效的一个具体形状

（[00:58:29]–[00:59:29]）

• ⚠️ 他点的前沿缺口是长文档推理："你有一份很大的合同，你在跨着它做修改，这对今天的模型来说都很难：要记得你在上面改了这些东西，定义变了，顺序变了。" 做法是切块 + 编排修改，而不是一次喂进去一次输出。
• ⚠️⚠️ 而切块的代价他说得很准，本页认为这比"切块会损失上下文"有用得多：

  "有些文档会就某件事连着讲两页左右，而每一个单独的块都不见得与检索词相关，但它们合起来极其相关。"

• 🔗 ⚠️ 主持人给了一条方向相反的一手经验："我最近从 map reduce 转成了全部丢进 context，而且它更好。" ✅ 本页并列两条、不裁决：一个在超长结构化文档上仍然必须切，一个在新闻素材上已经可以不切——而差异大概落在"文档内部有没有跨块的引用结构"上。

⚠️ 三、三条可直接搬用的手法

• ⚠️ ① fan out 之前先跑前 10 行（[00:37:23]）："我们的 tabular view 实际上会先跑前 10 行"——"这合理吗？它有没有给出我们以为它会给出的东西？" ✅ 主持人补的用法更一般："而且对建这个的人来说，在前 10 行上快速迭代到他们想要的结果，然后再放开跑，这非常好。"
• ⚠️ ② 领域转写：加关键词再跑一遍（[00:32:20]）：他举的失败是澳大利亚法庭上某类人的称谓"一直被转写成 condom"；🔗 主持人的工作流是："通常你在它上面跑一层 LM，抽出一些关键词，然后带着关键词再跑一遍转写模型。" ✅ 一般化的那句值得记："如果你在任何大规模上做过这件事，你会在任何不是普通日常对话的领域上捡到一大堆一大堆的转写错误。"
• ⚠️ ③ embedding 不要用默认的（[01:01:29]，主持人给的）："如果你是 RAG 重的负载，而你只是去看 MTEB、拿排第一的模型，你会留下很多在桌上"——建议看 Voyage 一类或定制 embedding。⚠️ 他认可，但加了一条限定："只是要确保多语言。因为我们服务那么多语言。"

⚠️⚠️ 四、引用能溯源到多层，而人实际上只做选择性复核

（[00:56:28]–[00:57:29]）✅ 本页认为这一段的价值在于它同时给了设计与真实使用行为，而两者不一致。

• 设计："我们有一套引用系统，基本上会检查它写的东西有没有一个链接……它会在 PDF 之类里用一个框高亮出这条信息是从哪儿取的。" ⚠️⚠️ 多层溯源："如果 agent 是基于一次 tabular review 写了什么，它可以引用那个单元格、或者那一行。所以你其实可以往下点好几层，一路验证上来。"
• ⚠️⚠️ 而真实行为是否定的：问律师是不是真的在核对，他答"最初会，但现在……"，⚠️⚠️ 主持人补"那种编出来的最高法院链接。他们不在乎"，他承认"这确实会发生"。
• 他的解释是选择性复核，并与 code review 类比："你有那种完全不在乎、就是甩 agent 的工程师，也有那种坐下来读每一个逗号的人"；"他们也知道：好，这些是关键的……我就重点复核这几样。而这些听起来合理，所以大概没问题"；⚠️⚠️ "就跟你从一个初级律师那里收到东西一样。"
• ✅ 🔗 本页标注这与 Joseph Kim 那条"把安全画像塑造成一个人" 的关系：⚠️⚠️ 它既证实了那条设计原则（人确实会把既有的复核习惯搬过来用），又同时暴露了那条原则的风险——"这些听起来合理，所以大概没问题"是对系统性、相关性错误最没有抵抗力的那种复核方式（完整讨论在 LLM 安全）。 ✅ 本页的实践含义：引用可溯源是必要的，但不能被当成已经被核验——真正起作用的是用户的注意力分配，而那是产品设计不能假定的东西。
• ⚠️ 另记一条模型写作风格的买方评价（[00:56:28]）："fable 和[另一个]绝对非常话多……非常冗长"（⚠️ "这一般来说不好"）；"Astra 写东西挺好，简洁得多"；⚠️⚠️ 而限定很重要："但话多/冗长这件事对我们来说其实有点难办"——✅ 本页标注这意味着风格问题不是靠 prompt 就能压掉的，而这是一条可被别人复测的说法。

⚠️ 五、"甚至在模型之前、甚至在 harness 里，就有一大堆低垂的果实"

（[00:52:27]–[00:54:28]）

• ⚠️⚠️ "老实说，如果你只是想为我们的客户做出更好的输出，有太多我们能做、而且立刻就有影响的事，都在训模型之前。"
• ⚠️ 他对检索侧的空间给了一个很朴素的描述："搜索和检索研究、或者 RAG 研究还有很多可做的……那也许不那么光彩。它其实甚至不是模型训练。有时候它就是架构和流水线。"
• 而法律 harness 里被定制的是什么（[00:54:28]）："我们编辑文件的方式很重要。我们做分析的方式很重要。你怎么做法律检索——这全都烤进去了。" ⚠️ 外加治理。
• ⚠️ 一条他顺带指出的结构洞察（[00:55:28]）：起草一份大合同本质上也是检索问题——"律师不会坐下来就开始打字。他们会先搞清楚：在类似的交易里我们用过哪些条款？"，⚠️ 而"类似"本身是多义的（同行业、同类型公司等），然后"你可能有好几份文档，再去搞清楚我该从哪份里取哪一部分"。

---

⚠️⚠️ "把 coding agent 从氛围的领域拿进测量的领域"：一套平台侧的度量设施，以及 80→15 美元/PR 的配置性归因（Warp，2026-11-03）

来源：Latent Space × Warp.dev（Zach Lloyd）

⚠️ 立场：他是 Warp CEO，这一期是带屏幕共享的产品演示 + 会议预热；本节所有数字为自述、口径自定、无第三方来源。 ✅ 本页收录它，是因为它的方法清单与本页此前的材料不在同一层——本页此前几乎全是个人侧用法（CLAUDE.md、skillify、effort 配法、spec 成本），而这一节是第一份平台团队侧的度量设施清单。

⚠️⚠️ 一、本节的主张，以及它为什么与本页此前所有条目都不同层

• 主张本身（[00:13:07]）："你在 Twitter 上一直看到这个——你该试试这个新模型、你该用这个新 harness。到底哪个更好？……这个世界需要的是把理解 coding agent 这件事从氛围的领域里拿出来，真正进到测量的领域里。"
• ⚠️ 使用者他自己收窄过（[00:12:07]）：不是日常工程师，而是"工程经理或 CTO，但也非常常见地是平台团队"，而那个团队要解决的问题是"我们怎么在我们公司里把 Claude Code（或者 Codex 之类）用到最好"。
• ⚠️⚠️ 而他指认的前置缺口本页认为是最该搬走的一条判断，因为它是位置缺口而不是能力缺口（[00:08:03]）：

  "我跟公司聊的时候大部分都没有这样的东西，因为他们的工程师基本上是各自在自己的终端里用 Claude Code、或者用 Codex 的 app 之类，在自己本地的环境里。"

• ✅ 本页的归纳：⚠️ agent 跑在个人机器上，公司层面就不存在任何可供分析的产物。于是本页此前那些"要沉淀、要写回、要建 eval"的做法（Coinbase 的 brain 必须写回、Garry Tan 的 skillify 循环、Arca 把每次编辑或取消变成 eval）全都隐含同一个前提：产物得落在一个公共位置上。本页此前没有把这个前提单独写出来过。

⚠️ 二、他们实际在看的四类指标，其中一个口径值得直接搬用

（[00:08:03]–[00:09:05]）

• ① DORA 类（发一个东西要多久）；③ 吞吐；④ 成本，可按人、按自动化、按 SDLC 环节切片——⚠️ 他说客户最在意成本："用对的模型、对的 skill 去调你的 factory，把每个 PR 的成本随时间降下来。"
• ⚠️⚠️ ② 而自动化程度那个口径本页认为是本节最可迁移的一条："对每一个被 merge 的 PR，人类一共得对它动手几次。"
• ✅ 本页标注它的好处：它不需要定义"成功"，只数人类介入次数，于是能在任务类型高度不齐的真实工作流上横向比较、也能跨时间比较。
• ⚠️ 而本页同时标出它的代价：这是一个会被优化的指标，而优化它最省力的办法是少动手。本期把它当作纯观测量，没有讨论这一点。

⚠️⚠️ 三、80→15 美元/PR：归因全部落在配置上，没有一条落在模型能力上

（[00:23:16]–[00:24:16]）✅ 本页认为这一节的价值在归因而不在数字。

• 他们刚开始用 factory 方式时约 80 美元/PR，调完降到 15–20 美元，而三条原因是：
• "用了 Opus 而本来不该用"；
• triage agent 挂在一个高功率模型上；
• ⚠️⚠️ "子 agent 开得太多，相比之下本该用更少的 agent"——✅ 本页标注这是本页第一条明确说"子 agent 开多了是成本浪费"的一手记录，而本页此前的多 agent 材料基本都在讲它的能力收益。
• 配套的两个数：过去一个月 PR 吞吐 +40%；"我们量了 revert 率，而它没有上升"。⚠️ 该指标的定义、窗口与基数均未给出，本页记为立场陈述。
• 🔗 ✅ 与本页既有量化并读：⚠️ Ali Ghodsi 的"harness 本身值 2 倍成本" 是从外部对比得出的一个倍数；而这一条是同一家公司内部纵向调优得出的 4–5 倍。两者方向一致、但这一条的归因更细，且明确指出可省的钱大部分来自"模型选得过强"与"agent 拆得过碎"。

⚠️ 四、落地形态：不另造界面，factory 当 headless 基建

（[00:25:17]）

• 他们的哲学是"把 factory 带进一家公司已有的知识工作工具里"："我们 60% 的工作是从 Slack 开始的"，也有从任务追踪器开始、也有"一个更习惯在终端里用 Claude Code 的开发者，在那儿做一堆活，然后把一份 spec 提交进 factory"。
• ✅ 结论句："factory 自身就像一块 headless 的基础设施，它有这么多不同的入口。" ⚠️ 基础设施分层清单记在 AI 基础设施。

⚠️ 五、本页对这一节的两条限定

1. ⚠️⚠️ 时机问题：factory 定义、scorer prompt、benchmark 任务集都是围着当代模型与 harness 搭的脚手架。 🔗 而 Legora 在前一天给了这条的买方版本——"直到最近，做真的很复杂的 eval 其实不太值得，因为模型就是都变好了"。 ✅ 本页记：两条并读的结论不是"该建"或"不该建"，而是建这套设施的收益率随模型进步放缓而上升，所以它是一个时点判断；而 Warp 这一期把它当成了无条件正确的方向。
2. ⚠️ 被问"最强的反驳是什么"时，他把问题换成了"它不适合谁"（规模 + 定制基建），✅ 本页记这是市场分层、不是对方法本身的反驳；完整讨论见视频页末节。

⚠️⚠️ 两条本页此前没有的个人上下文限定：它会衰减，而且会被探索行为污染（a16z × Assistant Benchmark 第二期，2026-11-04）

来源：a16z：家长式作风会杀死任何产品

⚠️ 立场：三人全部在这个赛道里有仓位或准仓位，且转录稿中无任何利益披露；这一期点名表扬了十几个产品。 ✅ 本页只取其中关于机制的几条，不取任何产品排序——理由见视频页。

⚠️⚠️ 一、好奇心之旅会污染偏好模型，而目前唯一的用户侧工具是全局开关

（[00:44:24]–[00:45:26]）✅ 本页认为这是这一期最该被长期保存的一条，因为它是一个真实、普遍、且不会随模型变强而消失的问题。

• ⚠️⚠️ Josh Elman 的问题陈述："我们用 agent 或者搜索去做的那些事，往往恰恰是我们不懂的事、不是我们生活里根本性的东西。"
• 两个例子都很具体：⚠️ 世界杯期间查了一堆资料，结果"ChatGPT 突然变成了个足球狂热分子。我说不不不，我当时就是对世界杯有兴趣，仅此而已"；⚠️ 为了解女儿喜欢的艺术家去听那些音乐，"但那不是我习惯听的艺术家或品味"。
• ⚠️⚠️ 而他给的现状是一个承认失败的变通："我其实经常进隐身模式，就为了不让东西被存下来——而这又其实也帮不上忙。"
• ✅ 本页标注这条为什么是一条结构性缺口而不是一个能力问题：⚠️⚠️ 个性化系统缺少一个区分"探索"与"偏好"的信号；而用户侧唯一可用的工具是全局开关（隐身模式），于是用户被迫在"污染画像"与"不留记忆"之间二选一——两个选项都放弃了本来想要的东西。本页认为这解释了为什么它不会随模型变强自动消失：缺的是一个意图标注机制，不是推断能力。
• ✅ 本页认为这给实践者的直接含义是：⚠️ 任何依赖长期记忆的用法，都需要一个把"我现在是在查资料，不是在表达偏好"说清楚的习惯——而目前这件事只能靠手动分会话或手动纠正来做。

⚠️⚠️ 二、上下文有半衰期：一条由说话人自己的失败项目支撑的限定

（[00:22:09]）

• ⚠️ Anish Acharya 做过一个从手机截图里抽取关键信息的 app，动机本身是一条好观察："截图差不多是手机上唯一能跨每个 app 捕捉上下文的方式。"
• ⚠️⚠️ 而结论是负面的："它还行，但我发现自己不会回去用。那些信息的价值随时间衰减得挺快。"
• ✅ 本页标注这条为什么比这一期其它产品点评可信：⚠️⚠️ 它是整期唯一一处由说话人自己的失败项目支撑的判断，而且结论对他自己不利。 ✅ 它给"个人上下文越多越好"这条默认假设加了一个限定：上下文有半衰期，于是一个靠存量上下文做差异化的产品需要先回答它的衰减速度。
• ⚠️ 他自己给的翻转条件也很具体：如果人们开始因为知道它会喂给模型而去主动多截图，那性质就变了（🔗 而 Josh 顺这条点了一个正在被做的形状：把截图与收藏组织成情绪板，写代码时直接让 agent 用"我存在这儿的例子"，于是"你在建你真正的风味档案"）。
• 🔗 ✅ 而本页认为这两条合起来构成对"把一切都记下来"这条默认路线的双向限定：⚠️⚠️ 一面说旧上下文会失效（半衰期），一面说新上下文会混入噪声（好奇心之旅）。本页认为这两条是本页目前对个人记忆类产品最有用的一组现实约束。

⚠️⚠️ 三、记忆是可携带的：一条实测，以及它对"要不要锁定在一个助理上"的含义

（[00:19:08]–[00:20:08]）

• ⚠️⚠️ David Pawlan 对榜单前 15 名实测了同一个请求：导出它掌握的你的全部记忆，以便搬去竞品——"除了一个之外，全都真的愿意这么做"，导出质量"相当扎实"（⚠️ 他的保留："我相信它们肯定扣下了一些你的劳动成果"）。
• ⚠️⚠️ 而这已经变成一个常见的新用户引导模式："去把这段提示词粘进 ChatGPT，下载那个文件，上传给我"；✅ 提出者自己的限定是"我们看看这能持续多久"。
• ⚠️ 另一种引导形态：语音通话入职（"跟我聊几分钟，我问你几个问题"），⚠️ 而评价是"它们非常让人放下防备"。
• ✅ 本页标注这条的实践含义：⚠️⚠️ 在这个品类里，"多年积累的上下文"目前不是一项不可转移的资产——所以选择一个助理时的锁定风险比直觉上低得多。 🔗 ✅ 而一条对照数字支持这个读法：⚠️ 那个带最大 ChatGPT 上下文继承优势的产品，在 354 人的重度用户调查里只有 3% 当主力；⚠️ 而 David 判定那个优势"完全可复制，只是因为他们用它用得最久"。

⚠️ 四、两条关于把偏好交给 agent 的实践观察

• ⚠️⚠️ 隐含偏好必须被显式化（[00:17:08]）："你那些隐含的偏好必须被显式说出来"——"我不是抠，我只是喜欢省钱"的人，大概得越过这一层，告诉 agent"我其实挺抠的"；✅ 而对照是"你自己替自己行动的时候，可以把那些偏好内置进去，而不必去照那面偏好的镜子"。⚠️ 本页记这是一项与能力无关的委托成本，详见 LLM 心理学。
• ⚠️ 多约束提示下的实际退化（[00:12:04]–[00:13:05]）：在一个同时要求"今天送到"和"尽可能便宜"的送花测试里，所有被测助理都满足了第一个约束，但大部分"在价格这一项上明显退了一步"，只有三个给两个约束同等权重。 ✅ 本页认为这给实践者的含义很直接：⚠️⚠️ 当提示里有两个互相拉扯的约束时，默认结果更可能是其中一个被实质放弃而不是被折中——所以值得把权衡方式本身写进提示，而不是只列出两个目标。

⚠️ 自建与自托管的真正增量是接缝，以及"show don't tell"作为一条方法（Latent Space × AIEi Shanghai，2026-11-04）

来源：Latent Space × AIEi Shanghai（swyx 作为被访者）

⚠️⚠️ 立场：这一期是 swyx 自家大会品牌在中国首场的预热节目，所有规模与成果数字为自述、无第三方来源。 ✅ 本节只取其中关于做法与权衡的几条。

⚠️⚠️ 一、自建的收益不在替代单个产品，而在跨产品的接缝

（[00:42:30]–[00:45:31]）

• ⚠️ 他自述自建或自托管了一长串东西（Calendly、Google Drive、GitHub、Dropbox、Slack、DocuSign），⚠️ 而前提他说得很坦白："所有这些都是因为我有钱、我有人，我可以派他们去做事。"
• ⚠️⚠️ 而他举的那个具体收益不是省钱：自托管的 DocuSign 签完之后，文件"直接进到我自己云盘上正确的那个文件夹"——⚠️⚠️ "而这在 DocuSign 里是不存在的"；✅ 落点是"我的 data room 里直接就有那些签好的文件，我根本不用碰"。
• ✅ 本页标注这条为什么值得记：⚠️⚠️ 自建的增量落在跨产品的接缝上，而接缝恰好是任何单一 SaaS 都没有动机去解决的地方。本页认为这给"要不要自己写"提供了一条比成本更有用的判据：如果你的痛点在某个产品内部，买通常更好；如果痛点在两个产品之间，自建的收益才是结构性的。
• ✅ 而他对这件事的一般化本页认为是一条很好的需求识别启发式（[00:45:31]）：

  ⚠️⚠️ "在每一百万次复制粘贴里面，我认为都有一个极好的创业公司和产品可以被造出来。"

• ⚠️ 他自己给了适用范围的限定："这不是说我在鼓励所有人都这么做"；✅ 正面主张是"你可以为自己造软件——为一个人的受众，或者一家公司的受众"。

⚠️ 二、维护成本与可用性的权衡，他给的是一条有条件的回答

（[00:36:26]、[00:38:27]）✅ 本页认为这处值得记，因为他没有回避这个最常见的反驳。

• ⚠️ 被问自建这么多东西维护会不会很难时："是真的，不是零。" ⚠️ 但他的权衡是明确的："好吧它宕一天，那又怎样，而你一天就能修好"——"我愿意用那段宕机时间来换'我能定制任何东西'。"
• ✅ 而条件是他自己给的，本页认为这是这条权衡能成立的关键：自建的对象必须不是关键任务级的东西——"你不是 Salesforce，不是 Google，不是 AWS，不是那种关键任务级 99.999% 可用的东西。你就是一个数据库，人们往里打字然后拿到点东西出来。"
• ⚠️ 他同时明确说这不是普遍建议："很多东西是糊的，而你不想用糊的东西。你的员工值得更好的，你也值得更好的。而且有时候从一个经过检验的 SaaS 买确实会更好。它当然会更好。" ✅ 他把自家的选择定位成偏好而非普遍最优："但对我们来说，我们想作为一家公司做到 AI-forward。"
• ✅ 本页的综合：⚠️⚠️ 这条权衡的可用形式是一道两问的自检——① 这个系统宕一天会不会出事？② 我的痛点在产品内部还是在产品之间？两问都指向"自建"时，它才是一个结构性更优的选择，而不只是一次省钱尝试。

⚠️ 三、"show don't tell"，以及演示本身就是 GTM

（[00:57:36]–[00:58:36]、[00:50:35]）

• ⚠️⚠️ 他对一类常见失败给的诊断很直接："show don't tell——给我看这东西带来的好处，不要用项目符号告诉我它是什么，不要给我 PDF、幻灯片、PowerPoint。就给我看。"
• ⚠️ 而他用的反例是中国机器人公司的演示选择："他们这周发的东西是在打功夫。但好吧，那个我见过了。给我看点我没见过的，那我才会真的注意。" ✅ 本页标注这是一条关于传播而非能力的批评（详见 中美 AI 生态对照）。
• ⚠️⚠️ 而正面例子被他用来解释一次技术路线为什么被接受（[00:49:34]）：Jev 的那个游戏演示"非常明白——你绝不可能用 LLM 去做这个"，⚠️ 而他明确说"那个演示才是所有人都在谈的东西"（⚠️ 该句的归属在转录稿里被讹写，本页只保留"演示本身是 GTM"这个结论）。
• ✅ 本页标注这条为什么该放在本页：⚠️⚠️ 他把"演示"从宣传动作重新定位成论证动作——一个好的演示不是在说明功能，而是在一次性地证明旧方案在这里根本不适用。本页认为这对任何要说服别人换工具的人都可直接采用：找一个在旧范式下无法完成的最小任务，而不是列举新范式的优点。

⚠️⚠️ 四、一个可操作的"品味"定义

（[00:59:38]–[01:02:41]）✅ 本页认为这是本页目前关于 taste 最有操作性的一条——本页既有材料多在断言它重要，少有给出判据的。

• ⚠️ 他自己先给了限定："我可以用一种没什么帮助的方式定义品味。"

  ⚠️⚠️ "品味是这样一种东西：从一个巨大的可能性集合里，你能又快又省地把它收窄到那个子集——而当你回头看时，那个子集立刻就显然是好的。"

• ✅ 而对照是暴力搜索："你可以暴力试一千个然后找到一个好的。但一个有品味的人可以说：这些显然是坏的。我解释不了……但它们显然是坏的。"
• ⚠️⚠️ 而那条外部判据本页认为比定义本身更可用（[01:01:39]）：

  ⚠️⚠️ "当别人开始抄你刚发的那个东西，你就有品味。"

• ⚠️ 他给的第二个例子落在"更无聊的问题"上，本页认为这处更有价值：Legora 在法律领域那套大规模并行的文档审阅流程——"一旦你看到那个，你就会想：我不想在别的任何地方做我的工作了"；⚠️⚠️ "而任何人其实都能想到这个点子。点子很便宜——但你没做。Legora 做了。"
• ✅ 本页的综合：⚠️⚠️ 他把品味定义成收窄能力而不是审美偏好，并明确否认点子的稀缺性。本页认为这与他对 Jev 为什么成功的归因是同一个论证（"此前已经有上千人试着说小模型好"），而它对实践者的含义是：在一个可能性极多的领域里，可被训练的部分是快速排除，而不是灵感。 🔗 ⚠️ 本页记下它与 OpenAI 金融团队那条"95% 是品味" 的关系：那条说品味是剩下的瓶颈，而这条给了品味一个可观察的外部判据，两者互补。

⚠️⚠️ "让它活得比它的创造者更久"：自下而上搭建的那项成本被命名了，加上 slop 的义务归属与一条非能力性的自动化闸门（a16z × Figma CFO，2026-11-05）

来源：a16z × Figma CFO（Praveer Melwani）

✅ 本页认为这条材料的位置值得先说：本页此前关于企业内部采用的材料绝大多数来自卖方或投资人；⚠️⚠️ 而他是一家上市公司的职能负责人，也就是实际在做采购与组织决定的买方。 ⚠️ 立场：这一期是 a16z 自家《You Need a New CFO》一文的配套节目，整期在验证一个已写好的主张；主持多次引用匿名的"我们投资组合里的某家公司"作为佐证。 ✅ 但本页判他的厂商色彩轻：他在买工具不在卖工具，而且数次对有利提法做了下修。

⚠️⚠️ 一、集中化的理由被从效率换成了存续

（[00:20:15]–[00:24:16]）✅ 本页认为这是本节最可直接搬用的一条，因为它给"让每个人自己搭"这条路线指出了一项此前没被明确命名的成本。

• ⚠️ 他先给专才划了功劳，而且划得很明确："让专才去想出点子并迭代……他们知道好是什么样子。他们知道他们想要什么……他们在做这些最初的原型上非常出色。"
• ⚠️⚠️ 而转折那句是本节的核心：

  ⚠️⚠️ "但我要不要那同一个人去负责检查所有上游依赖、去确保万一他离职了这东西是以正确的方式被托管的？还有，组织里其他人有没有同样的需求？大概没有。" ⚠️⚠️ "你把很多这些自下而上被做出来的东西拿过来，用一种能活得比它的创造者、比最初那个搭建者更久的方式，把它重建和再利用——我认为这就是 CIO 职能应该、或者可以演化成的样子。"

• ✅ 本页认为这条论证值得单独保存的理由在于它换掉了集中化的论据：⚠️⚠️ 通常"要不要集中化"被讲成效率问题（避免重复劳动）；而他给的是存续问题（创造者离职后这东西还在不在、还对不对）。本页判后者更难反驳，因为它不依赖任何关于重复劳动规模的估计——只要有人会离职，这个成本就存在。
• ⚠️ 他自己先把重复发现出来了，而这条路径值得记因为它是可自查的：内部审计（SOX）、GRC（ISO 与 SOC 2）、应付账款在各自做同一个"排查 → 拉信息 → 对账"的动作，推论是"那为什么不去建一个单一的平台来做这件事"。⚠️ 具体形态他给的是"CIO 组织内部那种集中的 PM 型职能"——与业务团队合作、找出真正在起作用的东西、"建这些别人可以在上面继续搭的地基"；✅ 而他自己指出这与传统 systems 组织差别不大，"变的是你能迭代的速度，以及你怎么赋能别人在上面搭"。
• ⚠️⚠️ 而他主动承认现在还没做到，本页认为这处让步使这条材料成为一条取舍而不是一个解法："跟 Figma 的所有事一样，我觉得我们长得比我们建起支撑它的工具更快"；"这事在我身上——我总要赋能组织去搭建，然后我不想通过在它上面造基础设施来把人慢下来。所以我觉得我们现在是在追着这件事跑"；⚠️⚠️ "我觉得我们现在在那个混乱的中间状态（messy middle）。"

⚠️⚠️ 二、那个失败模式被两处独立地具体化了，而它正好打在他自己的前 AI 时代功劳上

✅ 本页认为这条对照是本期最该被本页记住的结构，而它没有被节目里的任何一方连起来——以下归纳为本页的综合。

• ⚠️⚠️ 失败模式的具体样本（主持人转述，⚠️ 来源为一家未具名成长期公司）：

  ⚠️⚠️ "客户成功的负责人说，他每一个销售代表都有一个自己 vibe code 出来的仪表盘，而且数字各不相同。" ✅ 主持人自己的收束是："所以必须得有某种做对账的职能。"

• ⚠️ 而他自述的前 AI 时代第一次"解锁"恰恰是定义一致性（[00:03:03]–[00:04:04]，当时做法是写四五百行 SQL 生成 golden tables、再交给数据科学家加进 ETL）：

  ⚠️⚠️ "一旦我们在定义上、在谈论事情的方式上能保持一致——我们就再也不用争什么是真的、什么是事实了。然后我们可以越过这一层，真正聚焦在我们到底要怎么去推动业务上。"

• ⚠️ 他在定义归属上的回答与此一致，而且这是他对有利提法做下修最清楚的一次（[00:26:16]–[00:27:17]）：主持人的提法是"因为现在你能更容易地访问代码或 Stripe 的逻辑，这有没有改变你重访定义的频率"；⚠️ 他的答案是"我的团队拥有那边的产出"，落点在一致性——"他们知道我放出去的东西和我一个月前会放出去的东西是同一个。而且历史数从不改变"；⚠️⚠️ 最终回应是一句温和的否定："人们找到不同的方式来思考他们的业务，如果那赋能了他们把业务做得更好，那很好。但我确实觉得一致性本身也有一些价值。"
• ✅ 本页因此把这一期读成一条弧线：⚠️⚠️ 他认为让自己有效的那件事（定义一致性），正是分布式 vibe coding 侵蚀掉的那件事。而这解释了为什么他对集中化的理由落在存续与一致性而不是效率上——他此前的全部经验都指向这里。
• 🔗 ⚠️ 本页另记一条与此同源但被本期当成正面证据的材料，并标出它的论证问题（[00:19:15]）：主持人转述一家成长期公司"一两个月里他们团队做出了 40 或 50 个 agent"，⚠️ "那些里大概有 90%——我猜——已经没人再用了"，而结论是"但它让所有人进入了这个动作……我觉得这几乎和把那个 agent 真的搭出来一样重要"。⚠️⚠️ 本页只记录那个事实、不采信那个结论：那个 90% 是说话人自己标明的猜测，而"进入了自动化优先的动作"没有给出任何度量。 ✅ 而本页标注一处本期没有连起来的地方：那个 90% 的废弃率与"三个团队在各自重建同一个流程"是同一个现象的两种说法，本期把前者当成成长的代价、把后者当成要解决的问题。

⚠️⚠️ 三、slop：成本被归到生产者身上，而理由是一条很干净的不对称

（[00:15:10]–[00:17:13]）

• ⚠️⚠️ 症状侧（⚠️ 主持人转述一位未具名 CFO）：用 AI 导致"每天被创造出来的文档数量无上限，而你什么都找不到了——因为现在每个人都能写一份文档，或者在几分钟里写十份，而那本来要花你一两个星期"。 ⚠️ 主持人给的时间线描述是"我们从无上限的 token，走到人们在会上直接管它叫 slop"。
• ⚠️⚠️ 而他给的规范性论证是本节真正的可保存内容：

  ⚠️⚠️ "任何你放出去、要求别人消费的东西，都会花掉他们的时间、精力和气力。所以我觉得你要确保你给自己设一个同样的门槛，去评审、去读、去总结、把它变简单。" ✅ "你可以从一个不同的地方开始，这我完全没问题。但我确实觉得这件事落在我们所有人身上——要对我们怎么使用彼此的时间非常周全。"

• ✅ 本页认为这条论证的形状值得推广：⚠️⚠️ 生成成本塌缩而消费成本不变，于是两者之间原本的平衡被打破了——而他的处方是把那个差额以义务的形式还给生产者。本页判这比"不要用 AI 写垃圾"这类呼吁有用，因为它给出了义务的来源而不只是态度。
• ⚠️ 制度侧是披露标注："我们在内部也做得不错的一件事，是建立了一些政策——当你用 AI 写了某个东西的时候要标注出来。" ⚠️ 只给了政策的存在，没给执行方式与覆盖范围。
• ⚠️ 而他给了两侧的亲历："我待过那种东西看起来有点半生不熟的场合，你一戳就是：你真的理解这边在发生什么吗？"；"但我也待过那种场合，我会想：天哪，就凭你把这套搭起来的方式，你迭代的速度简直厉害得不行。"

⚠️⚠️ 四、一条被点名的、非能力性的全自动化闸门：审计师

（[00:39:20]–[00:40:20]）✅ 本页认为这条对判断一个职能的自动化上限比任何能力讨论都更有用，因为它指认的是一个具体的制度性守门人。

• ⚠️ 方向是正面的："我希望越来越多的东西能被完全自动化。我想我会从那些真正确定性的部分开始，以及我怎么给它喂足够的信息，好让我能觉得那边的输出是完全完全可信的。"
• ⚠️⚠️ 而门槛是：

  ⚠️⚠️ "我认为对一个真正业务关键的系统，要把东西做到那种 audit ready（可供审计）的输出，门槛是极高的。" ⚠️⚠️ "而我觉得这也会是一场和审计师之间很有意思的对话——什么东西才能让他们放心。" ⚠️ 他没有排除它："但我不会把它从图景里拿掉。我确实认为我们随时间会走到那儿。"

• ✅ 本页认为这条的价值在于它把闸门从能力换成了第三方的接受度：⚠️⚠️ 即便模型能产出正确的结果，在这个职能里"能不能全自动"取决于外部审计师愿不愿意接受这条产出路径。 🔗 ⚠️ 本页标注与既有材料的同形之处：Serval 那条"大企业不会在没有评审、没有用户验收测试的情况下就上线新的 agent 能力" 是同一类制度性闸门；✅ 而这一条更具体，因为审计师是一个有名有姓、有自己标准、且不受采用方控制的外部角色。本页因此把它记成一条可跟踪的观察点：财务全自动化的进展应该表现为审计准则的变化，而不是模型榜单的变化。

⚠️ 五、一次被明确说出的容差校准，以及"95% 的难处就是把数据放对位置"

（[00:17:13]–[00:19:15]）✅ 本页认为这是本期唯一一个被讲完整的用例，而它值得保存的原因是他主动说出了自己的容差——而本页的多数采用材料不说这一层。

• ⚠️ 场景：2027 年度规划期间的一次 T&E 评审，跨 Navan（⚠️ 字幕作 "Non"，本页按 Navan 还原，置信度中等）、Zip、Ramp 做模糊匹配；⚠️ 难处他举得很具体："那个人是真的为了一次 off-site 在出差吗？如果他本来就住在旧金山、只是过去一趟呢？"
• ⚠️⚠️ 口径判断："那里 95% 的难处就是把你的数据放到对的位置上"，"而这些模型很擅长替你做这些假设"。
• ⚠️⚠️ 而容差校准是这条用例成立的真正原因：

  ⚠️⚠️ "我并不需要什么 100% 完美的东西。我只是想要一个大方向上对的、和我要去的方向在同一条脉络上的东西，能给我足够的信息去理解：哪些是我真正需要把旋钮拧一拧的地方。"

• ⚠️ 自述周转是当天早上给反馈、"30 分钟之后"、进会议室时"一切都已经可视化好了"，而对比是"我不觉得他们靠手工能做出这个来"。
• ✅ 本页因此把结论定在：⚠️⚠️ 这个用例之所以成立，不是因为模型变准了，而是因为他事先判定了这项任务容许近似——而他要的产出是"该去拉哪几根线头"，不是一个结论。本页认为"产出是线头而不是结论"值得被当成一条可复用的用例选择标准。 🔗 ⚠️ 他在会计侧给了同形的第二例（flux analysis："给你一个关于什么变了的初步版本，给他们一组可以去追的东西"）。

⚠️ 六、两处很具体的内部实践，以及本页各自的一处标注

• ⚠️⚠️ 给每位领导者造人格，用来预审投资备忘录（[00:13:08]–[00:14:09]）：前提是"我们是一个非常以文档为导向的文化"，而他指出的规律是"我们作为领导者都倾向于有一种看问题的方式"；⚠️⚠️ 做法是 corp dev 团队"去给我们每一位领导者都造了独特的人格，作为一组他们可以拿来过一遍自己投资备忘录的东西"，形态是来回推演（"这是 Praveer 会说的，这是 Dylan 会说的，这是 Sean（我们的 CRO）会说的"），自述收益是找出需要补强或补尽调的区域、以及"缩短了我们所有人坐在一起的那个周期时间"。
• ⚠️⚠️ 本页必须标出一处当场无人提起的风险，因为本页认为它是这条实践的主要失效方式：这个流程优化的对象是"通过被模拟的那位评审者"，而不是"做对那个决定"。 ✅ 一旦它有效，它会系统性地训练组织写出能过模拟闸门的备忘录——而那个闸门恰好是由下属构建、未经被模拟者验证的版本，于是真实评审者身上尚未被建模的部分（尤其是改变主意的那部分）会被不可见地筛掉。 ⚠️ 本页记这是推测性风险而非观察到的后果，但认为它值得随这条实践一起被引用。
• ✅ 本页同时标注一个正面特点：⚠️ 它是自下而上被做出来的（由 corp dev 团队用来过自己的备忘录），而不是由被模拟的领导者布置的。本页认为"为一个已知的评审口味做准备"在 AI 之前也在发生，变化在于它现在是可共享、可继承、也可以被过度拟合的。
• ⚠️⚠️ "你能不能 vibe code 出这个产品"作为并购尽调的一项检查（[00:12:07]–[00:13:08]）：由财务背景的 corp dev 团队而不是产品团队来做，用来判断"你的护城河有多深、那里的技术有多有意思"；⚠️ 他自述副产品是可信度（"这是我做出来的，这是我看到的"），而"我们还是和产品团队合作"。 ⚠️⚠️ 本页标出它继承了一个本页已经量过的测量误差：复刻表面说明的是表面的可复制性，而护城河通常不在表面上——而 swyx 那次实验 里 69 份提交只有约 5 份达采购水平、且他承认"维护不是零"。他对此只有一句很轻的让场（"这一堆想法里显然有很多细微处，但它给你一个扎实的直觉"）。 🔗 本页把这条记进 AI 商业化与价值捕获，因为它是同一项能力的第三种用途。

⚠️ 七、"Excel？它就像我的爱的语言"——一条关于直接操纵为什么会留下来的论证

（[00:40:20]–[00:42:21]）

• ⚠️ 被问"Excel 受到威胁了吗"，答案是干脆的否定，⚠️⚠️ 而理由不是速度而是校准："它是我建立信任的方式，是我建立理解的方式"；✅ 比方是色轮——"你可以坐在那儿对一个 agent 提示它去把背景从红改成绿，或者我可以拿那个色轮，你会看到它所有不同的色调，你就得到了那种真实的手感。" ⚠️ 他给了让步："未来也许会有更好的东西，但对我来说，要把它从我手里撕走会非常非常难。"
• ✅ 而他给的反方向用法本页认为比"Excel 不会死"更有用："如果你给我一个 20 个标签页的模型，让我去一页页翻会非常困难。但如果我能把同样的上下文传给一个模型，帮我理解哪些是真正拨动指针的东西、哪些区域更敏感——这其实给了我一个更好的起点。"
• 🔗 ⚠️⚠️ 本页标注这与他那条面试探针是同一个判断的两次出现：他让 LLM 做的事和他考候选人的事是同一件——找出敏感度结构。 ✅ 本页因此把他的立场总结成一句他自己没说的话：敏感度是这个岗位上人必须自己拥有的那样东西，而定位敏感度的劳动可以外包。
• ⚠️ 主持人给了同向表述并加了一条能力断言："我觉得模型还没好到能真的做出一个预测或者一个模型，但我觉得那种组织仍然是有价值的。" ⚠️⚠️ 本页标注后半句未给依据，且与她在同一期引用的那些自动化案例口径不一致，本页不采信。

⚠️⚠️ harness 到底在挡什么，以及"每个问题最后都是搜索问题"（Reducto，2026-11-06）

来源：Latent Space × Reducto：失效模式在 recall 不在 precision、每月十亿页，以及白领的 Claude Code 时刻

⚠️⚠️ 立场：说话人是 Adit Abraham，Reducto 联创兼 CEO，而这一期同时是产品发布现场。全部数字为自述、无口径、无第三方来源。

⚠️⚠️ 一、本页第一次有人说出 harness 在挡哪种错误

（[00:06:07]–[00:08:07]）✅ 本页此前关于 harness 的材料回答的都是"它值多少钱、能到多高"： - ⚠️ Ali Ghodsi 的"harness 本身值 2 倍成本"（一个倍数）； - ⚠️ a16z / Lio 的 80% 天花板（一个上界）； - ⚠️ Alex Zhang 的 harness 理论（一个正面定义）。

⚠️⚠️ 而这一条给的是"它挡的是不会报错的漏抽"：

⚠️⚠️ "我们发现 precision 和 recall 之间有一个很奇怪的 trade-off。所以很多这些专门的文档处理平台，在你放开推理时间不设上限的时候，是比前沿模型更差的。"

⚠️⚠️ "但前沿模型的失效模式在 recall 上。所以它们在静默地丢行、漏掉一些上下文……如果你的抽取层就这么把信息整个漏掉了，那是一种你在生产里根本不会发现的损失形态——你不知道自己一开始就没抽出来什么。"

⚠️ "那些是有一个 harness 围着它、确保结果被核过的事情变得非常非常重要的地方。"

✅ 本页标注三点： 1. ✅ 它不以"我们更准"收尾而是换了被比较的维度：⚠️ "我不觉得这是二选一——确实有些任务前沿模型就很好。但如果你要找做这件事最高效的工具，你大概应该按你在做的任务去专门化。" 2. ⚠️⚠️ 它可检验：若成立，放开推理预算的 benchmark 上专门平台会落后，而在召回类指标上反过来。 3. ⚠️⚠️ 它对本页"harness 的 80% 天花板"那条有一个未被两边连起来的含义：✅ 若 harness 挡的主要是静默漏抽，那它的价值上界取决于任务里"漏了会不会被下游发现"——而不是取决于模型能力。本页记为推论，两期都没有说这句话。

⚠️ 配套：传统 CV 打底 + 大模型打难例，理由是长尾且不可预知

（[00:04:05]）⚠️ "难搞的地方是这归根结底是一个长尾问题。你会有很多页看起来就只是文字，然后每隔一阵子你会碰到一个特别复杂的表格——而你事先并不知道是哪一页有那个东西。" ⚠️ 于是起步形态是"用很多更小的传统 CV 模型做基线，然后用更大的模型做真正难的任务"（⚠️ 他说这个形态正在被自研端到端模型取代，见 AI 商业模式与价值捕获）。

✅ 二、"客观的要 zero-shot，主观的要可引导"

（[00:16:15]）✅ 本页判这条划界可以直接搬到别的 agent 产品上，而它不依赖文档这个载体。

✅ "对于客观的任务，比如解析——给定一页你可以非常明确地说'这页上就是这些东西'——我们要它横向，要它 zero-shot。而对那些属于见解之争的东西，比如某个财务团队对某个指标有不一样的定义，那些东西应该是可 prompt、可引导、并且随时间改进的。"

🔗 ✅ 与本页既有的 Decagon "会变的东西不能烧进权重" 同向但切的刀不同：⚠️ Decagon 切的是变与不变（决定微调 vs 上下文），这一条切的是客观与主观（决定 zero-shot vs 可引导）。 ✅ 本页判两条互补，且合起来能给出一个四格：不变且客观 → 烧进权重并要求 zero-shot；会变且主观 → 放在上下文里并留出 prompt 接口。 ⚠️ 本页标注这个四格是本库的归纳，两期都没有给出。

• ⚠️ 横向化的论证落在一个具体机制上（[00:13:12]–[00:15:14]）："你作为一个人看一页纸的时候，会做出大量根本性的判断，而那些都是瞬时判断。比如每次两段之间有一个间隔，你就知道，好，这是一个新的语义块。你不会有意识地感知到这件事，但它是直觉的。"
• ⚠️ 于是跨行业收益单向传导："我们在'对那些传真过来的、乱糟糟的医疗表格保持鲁棒'上做的工作，意味着我们天然也能给金融客户提供更可靠的方案。" ⚠️ 行业差异被降到细节层（法律在意划除线与下划线，医疗没那么在意）。

✅ 三、"每个问题最后都是搜索问题"：把 agentic search 与 RAG 归并

（[00:34:28]–[00:36:30]）⚠️ 起点是他说 chunking 现在"也许没那么能引起别人的兴趣了"，然后：

✅ "但很多问题归根结底都是搜索问题。不管你叫它 RAG 还是叫它别的，大量产品仍然是某种形式的搜索，再在搜索结果之上做某种形式的推理——这在我看来定义上就是 retrieval augmented generation。"

• ⚠️ 他说排斥来自一个误读："人们对 RAG 有一种反感，理由是'噢，我又不是在做聊天机器人'"，⚠️ 而人们想到 RAG 时想的是"你切块、你 embed、你用余弦相似度检索去决定塞什么进模型上下文"。
• ✅ 归并论证是行为层面的："我们很多客户还是会给 agent 一个文件系统，agent 爬那个文件系统去找相关上下文在哪，它在那个上下文上推理、把多份文档的信息拼起来"——"那个过程不管是 agent 在做，还是清清楚楚地呈现在你的搜索产品里，都是你在搜索信息、把上下文拼起来、综合它，最后做出某种动作。"

🔗 ⚠️⚠️ 本页此前关于"RAG 死了 / 被 agentic search（grep、文件搜索）取代"的材料都把两者当成替代关系，没有一条给出"它们是同一过程的两种实现"这个归并。 ✅ 本页记为一条可用的框架，⚠️ 但标注它是定义层面的论证、不含任何经验证据——它不说明在什么条件下该用哪种实现。

⚠️ 四、PDF 这个格式的原始设计意图被当作根因

（[00:02:04]–[00:03:05]）⚠️⚠️ "PDF 作为一个文件格式，最初的情境是为了让打印机忠实于原件。所以它根本不是围绕'agent 要来读它'这个问题设计的。" ✅ 本页标注这是一条可推广的提法：很多被 agent 消费的格式都是为别的消费者设计的，而失配的代价会落在读取层。 ⚠️ 他给的目标设定是自动驾驶类比（车道保持 vs 端到端自主），本页记为目标陈述、不含进度信息。

---

⚠️ 本地模型的第四个动机："我们不想被限流，我们要不计量的智能"（All-In，2026-11-07）

来源：All-In / 数据中心审批冻结、超大规模厂商造王者、4 万亿单日蒸发（⚠️⚠️ 全部为 Jason Calacanis 的自述，无口径、无第三方来源；且他在同一段里给了三个互不相同的回报数字，本库不采信任何具体倍数）

⚠️⚠️ 那条动机，以及它为什么是新的

（[01:14:01]）他的采购动作与理由：

"我们正准备给每个人订一台 512GB 的 Mac Studio，2 万美元一台"（⚠️ 他算成"桌面上 40 万美元的算力"）"先跑本地模型，然后再回落到它们，因为我们不想被限流（throttled）。我们想要不计量的智能（unmetered intelligence）。" 他的预测："所以海外数据中心会是未来两年的趋势。而本地模型的桌面使用。我就在这儿做这个预测。"

• ✅ 本页标注这条的新意在动机而不在做法：⚠️⚠️ 本页此前记录的本地/开源权重模型理由是成本、隐私/数据驻留、与延迟。"不想被供应商限流"是第四个，而它的触发条件很特殊——只在重度 agent 使用下才出现，因为限流是按用量而不是按用户数触发的。 ✅ 而它的检验方式很直接：看的是采购本地算力的主体是不是重度 agent 用户，而不是看本地模型的质量是否追上。
• ⚠️ 他自己给了能力侧的限定，本页认为这个限定让上面那条成立的范围变窄了："我们在做的事只是前沿模型能力的 70% 到 80%。我们显然不是在解 Navier–Stokes。"（⚠️ 转录稿写成 "neighbor Stokes"）✅ 本页的读法是：这条路线只在"任务不需要前沿档位"时成立，所以它与上一期他自己给的"二三档模型够用"那条切层机制是同一件事的供给侧版本。
• 🔗 本页既有的相邻材料见 开源与基础设施。

⚠️⚠️ 同一段里的采用缺口数据，以及一处本库必须记下的未对账

（[01:12:01]–[01:13:01]）

• 投入侧（自述）：20 人、一年在订阅上花"4 万到 5 万美元"（⚠️ 他说主要是 Grok 和 Claude）。
• ⚠️⚠️ 回报侧的三个数字互相矛盾，本页只记定性："我估计我们从那里拿到 200 万美元价值" → "我估计我们拿到大约 100 万美元的增量收入" → "我估计我们每花一美元拿到 15 到 21 的增量收入"。✅ 定性是"投资的速度在上升""做新媒体资产的速度在上升，因为我们把一切自动化了"。
• 采用缺口与放大链条："企业美国只有 10% 或 20% 的人在每天、经常性地使用这项技术。换句话说，还有 5 到 10 倍那么多的人可以开始每天用它" → ⚠️ "而我相信当他们转向 agentic，他们会开始用，因为它对普通人太容易接近了……你只要告诉它你想要什么，而它会用 50 倍那么多。所以我觉得这件事的需求有 500 到 1,000 倍。"
• ⚠️⚠️ 而本页必须记下的是同一条数据在八天里被给了两个不同的归因，而他本人没有对账：
• 2026-10-30 那期：归因到安全——"大公司不让人真正用上 AI 的能力，因为他们怕网络安全"，"所以一旦网络威胁被缓解，这会从 10% 变成 60%、70%、80%"。✅ 本库当时记下的检验方式是"看企业把 AI 接进邮箱与内部知识库的比例"。
• 本期：归因到易用性——agentic 让普通人不必学 code、不必配 rig 或 harness。
• ⚠️⚠️ 本页的判断：这两条不是互补而是竞争性解释，而它们的检验方式不同（前者看连接权限的授予比例，后者看非技术岗的日活比例）。本页因此把这条 10–20% 的缺口记为"原因尚未收敛"，并保留两个检验点。 ✅ 而本页记下这正好说明为什么该把归因与数据分开记：数据本身（Gallup 口径下的 10%/20%）在两期里是一致的。

⚠️⚠️ 一份被当成课表的方法论清单，以及两条本页此前没有的"我没有答案"（Stanford CS146S，2026-11-08）

来源：Latent Space × Mihail Eric（嘉宾 Mihail Eric / Stanford 兼任教授、Monaco 的 Head of AI；主持 swyx）

✅ 本页判这一期在本页的特殊价值在于体裁：全期是 swyx 拿着一份公开课程大纲逐周往下走、每周问"这一块现在的 state of the art 是什么"。 ⚠️ 于是它不是某一家的做法，而是一张"哪些方法已经稳定到可以进大学课表"的清单——而两位在场者都当场标注了其中哪些还不是定论。

⚠️ 一、十周大纲作为"已稳定"清单

（[00:15:07]–[00:19:10]）

周	内容	他给的理由（照录要点）
1	harness 内部机制；从零搭一个 coding agent 克隆	教学立场是"把那些像秘方一样的东西剥掉"
2	规模化的 context engineering；工具设计与 MCP	⚠️ "我仍然是 pro MCP 的……它已经是一个存在的标准，我觉得它会继续存在"
3	skills：从单一用途工具扩展到"流程"	"这开始引向 agent 的自动化"
4	agent 定制：config 文件（AGENTS.md / CLAUDE.md）、hooks、子 agent	"现代 harness 里存在很多不同的机制，各有不同用途"
5	agent-ready 代码库（⭐ 他自称最喜欢的题目）	权衡落在服务级边界、文档、可验证性
6	agentic code review	⚠️ "code review 现在正在变成瓶颈"
7	安全：新的攻击面	见 LLM 安全
8	背景 / 异步 agent	基于 repo 事件、CI/CD、SRE 式 bot 的触发；点名 Ramp 的 inspect、Spotify 的版本、Stripe 的 minions
9	AI-native 团队：LLM gateway、MCP portal、演化中的岗位	见 AI 与就业
10	software factory	"人还存在于哪里？那些被有意留下的人类介入的新咽喉点在哪里"

• ⚠️⚠️ 而两位主持当场加的限定本页认为必须与清单同等显著地记下来（[00:20:11]）：swyx——"其中有些比另一些更是已成形的模式……人们需要知道，这里面不是全都是已定的科学"，✅ 但他同时背书了清单本身："我会给所有这些背书，当作人们在谈的、你应该知道的东西——我们知道那些开放问题，只是可能还不知道答案。"
• ⚠️ 嘉宾自己的承认："很大一部分课程内容相对去年变了"，✅ 而去年到今年的差别本页认为描述的正是一个领域从"扫盲"进到"有原则"的那一刻（[00:04:00]）：

  "去年那一版……感觉更多是在做一次广度的巡游——这里是你能用 coding agent 的所有地方。……今年，我觉得有些原则正在固化下来——非常仔细的 context engineering 这个想法，以及真正把设计和架构想透、当作处理极复杂任务的手段。"

⚠️ 二、context engineering：RAPID，以及一条可独立验证的行业现状断言

（[00:32:18]–[00:34:18]）

• ⚠️⚠️ 现状断言：

  "即使在我面试人的时候我也看到这个——业界里非常少的人会进展到超出单纯的 vanilla prompting。就是'帮我做那个事'。而随着模型变好，那确实能带你走一段距离。"

• 失效条件是代码库规模："任何从 Google 这类有极大代码库的地方出来的人都知道，现实是你必须对你怎么把东西喂进 context 这件事思考得多得多。"
• 框架 RAPID，他自己对照为"功能上类似 Dex 的 RPI"：research → proposal（给出几种备选解法）→ plan（也就是 spec）→ implementation → 用测试收口。
• ⚠️⚠️ 而人留在哪一步是这套框架最实质的一处设计："这里我也把 human in the loop 请进来，让人当那个在一种方案和另一种方案之间做决定的人。" ✅ 本页标注这与本页此前多条材料一致——人被放在选项之间，而不是放在产出之后。 🔗 对照 Anthropic 平台团队"最要紧的两件事是计划和验证"。
• 适用规模："确实有一种做法能扩展到几百万行长的代码库。而它不是单纯的 vanilla prompt。"

⚠️⚠️ 三、sub-agent 的 context 继承：本页第一条由重度使用者明确说出的"我没有答案"

（[00:34:18]–[00:36:20]）✅ 本页判这类自认比论断更有保存价值。

"我现在对 context 的想法里最奇怪的部分，是当你切出一个 sub agent 的时候，因为 sub agent 可以从主线程继承你的全部 context，也可以不。……我不喜欢我现在做的任何做法。所以我没有任何答案。"（swyx）

• 他唯一确定的是扇出："当你想把工作扇出去，它不再是一个 agent 了。它是关于扇出工作，并确保它们都有对的 context、都有对的指引。"
• ⚠️⚠️ 而他描述的那个"扩张—收缩"循环本页认为是最具体的一处失效模式：

  "你总会经历这个扩张收缩的阶段——'天啊，这些家伙 context 不够，我得给他们更多 context'。好，很好。然后他们会对你很久以前随口说的某一条一次性评论过度调优，然后犯一些非常愚蠢的错，因为你不是那个意思，但他们当成了法律。"

• 嘉宾接的那一侧是"艺术多于科学"："扇出去做探索、扇出去做子任务，然后再做合并、压缩"；他引 Dex 的 "dumb zone"——"对 dumb zone 要更有意识一点"。
• ⚠️ 而本页记一条与之互补的模式（[01:56:00]）："dynamic workflows"——"很多关于子 agent 的讨论其实就是你在复制父 agent，但你实际上该写多得多的代码，然后把它当成一个子 agent 去跑"，定义是"你在为你正要做的那件事按需写一个 harness"。✅ swyx 说这是 Anthropic 那边的命名，嘉宾说 Monaco 也建了一个 GTM 版本。

⚠️⚠️ 四、skills：两人都认为是对的方向、错的形状

（[00:37:20]–[00:46:23]）

• ⚠️⚠️ 写 skill 这件事被低估（[00:42:21]）：swyx——"很多人在关注的是 skill 的消费……但不，你该自己写你的 skill"，而"实际上当你天真地去写它们，它们通常是坏的。写一个 skill 其实需要一点 skill"。
• ✅ 他的工作流是一条可直接搬用的手法："Claude Code、Codex 都有创建 skill 的 skill。然后我有一个 skill cutter skill 把它剪短——它基本上就是把那些默认创建出来的 skill 坏在哪里的每一种方式都记录下来。" 流程是每次创建后都跑一遍。
• ⚠️ 而他对"为什么不能直接扔掉 slop"给了一条很细的理由，嘉宾当场接住："slop 里有好东西，然后你得把它们筛下来" → "即使是 slop，它仍然是在 agent 的语言里。所以那个 slop 是有意义的。"
• ⚠️⚠️ 最具体的失效模式是误触发（[00:43:22]）：

  "最糟的部分是当一个 skill 在你不期待的时候触发了。你某一次写它是为了修一件事，然后现在你在做一件完全不同的事，它触发了。为什么？因为它写得差——因为触发条件写的是'只要什么什么发生就叫我'。"

• ✅ 应对是园艺式维护：点名 Eugene Yan——"他们对自己有多少 skill 很讲究。他们会剪枝。不用的，每几周清一次。"
• ⚠️⚠️ 而 swyx 那条判断本页记为他的推测（他自己标明这不是公开表态）（[00:44:23]）："我怀疑——Anthropic 那边有一些非常聪明的人想让 skills 死掉。" 理由是审美性的、而他承认对自己同样成立："它就是感觉很 sloppy。而我知道——我能看到我自己的 skill 也在变 sloppy。" ⚠️⚠️ 落点："它不是 AGI 本来应该长的样子。它就是每个人都有一大堆 markdown 文件。"
• ✅ 而反方的两条本页同样记下来，因为它们不是修辞上的平衡、而是不同的使用层级：
• 第二位主持："很多人其实不去看他们的 markdown 文件……光是聊天说出你想要什么、在聊天里创建一个 skill、用它、看输出——你不用看 markdown 也能拿到很多价值。" ✅ 可执行版本："如果你在重复做某件事，就说：看看我们最近五次是怎么做这件事的，给我做个 skill。"
• ⚠️⚠️ 嘉宾的区分本页认为可能更耐放（[00:45:23]）： > "但在像 Devin 这样的情形下，我们把 skill 形式化成了一种表示我们最佳实践的方式，然后把它暴露给 agent、给 code review 系统，让它按我们喜欢的方式去定义 API、按我们定义的方式去立服务级边界。这是一种表示组织级知识的替代方式，而不那么像那种'你不想每次都写 prompt 的任意事情'。"
  • 他的预测："我感觉这个定位、这个用途可能会比那些随机流程活得更久。"
• ✅ 本页的归纳：⚠️⚠️ 两人没有分歧，分歧是对象不同——swyx 说该死的是"个人的一堆临时流程"，嘉宾说能活的是"组织的成文规范"。而两者在文件格式上完全一样，于是"skills 会不会死"在当前形态下无法被回答。 🔗 对照 Garry Tan 的"一个 markdown 文件就是一名员工"（个人侧）与 Warp 把 factory 定义写成代码（组织侧）——后者属于嘉宾说的"能活的那一类"。
• ⚠️ 另记一个被点名的 skill，因为它的机制与本页"理解代码"这条线正好对上（[00:38:20]–[00:39:20]）：Geoffrey Litt 的 explain diff——跑完后除了可视化表示，"最后那个几乎像小测验的环节，你走一遍，真正强化你是不是理解了在发生什么"。
• ✅ swyx 给的反直觉：⚠️ "每个人都想用 coding agent 来把脑子关掉。他们就是'给我做个 app，读我的心'"，而"这些 skill 里很多其实是'不不，请多问我一些问题'这个门类的"。
• 第二位主持的收口句："把代码写出来、把活干完，这件事比以前容易多了"，于是"你该花更多时间想你到底在做什么"。

⚠️ 五、system prompt 变薄的归因：一条可用来做选型的机制观察

（[00:29:18]–[00:31:18]）

• 两人给的现状（本页记为一手观察、非厂商口径）："Claude Code 在所有 coding agent 里有最长的 system prompt，差不多两万 token"（swyx）＋"不过他们也把体积削掉了 80%"（嘉宾）＋"然后又长回来，又削，又长"（swyx 称之为锯齿形）。
• ⚠️⚠️ 而归因是本页认为最有迁移价值的一条：

  "曾经是 system prompt 一部分的东西——比如怎么用 git，或者怎么设置任务这类——已经不在 system prompt 里了。它现在实际上被期待更多地被捕捉在模型里，在模型权重自身里。"

• 他推成一个选型问题："这就提出了关于模型与 harness 的有趣问题……公司该投什么？你自己该投什么？" ✅ 现状判断是未定："我觉得作为一个社群，我们在两者之间来回摇摆得很厉害。"
• ✅ swyx 给了一条直接可用的推论：⚠️ "更弱、更老的模型，你需要给它们例子——这是好的、这是坏的。然后在某个时点你显然把那些削掉"，于是"如果你在用一个本地 coding agent、模型不是最强的，你可能需要加回这些例子"；反向代价是"随着模型变好，你什么时候会因为加了那些例子而过度约束了它"。
• ⚠️ 他对早期 Claude Code 流行的解释是"少而强的工具"："他们是最早真正倾向于'让更少的工具做更多事'的那批人之一——倾向 SQL、倾向 Bash、倾向那些像瑞士军刀一样强的东西。"

⚠️ 六、code review 的瓶颈化，以及一条与"上更多 agent"方向相反的企业诊断

（[01:11:35]–[01:13:36]）

• ⚠️⚠️ 他对年度最大变化的指认：

  "去年到今年之间也许发生的最大的一件事，是突然非常清楚地看到 code review 是一个瓶颈——特别是一旦人们变得非常 AI pill，生成端的速度变得那么高，理论上你一天可以提 30 多个 PR。"

• 两难是对称的：要么"你把自己插进中间……但那样你就字面意义上成了约束、成了速度的咽喉点"；要么"那大规模生成的意义又在哪里"。
• 他说中间地带的条件是前几周那些东西："如果你在 agent readiness 上投入了经过思考的设计，在可验证性上投入了经过思考的设计，那么有一类问题你可以在某个百分比的时间里放心地自动批准。" ✅ 形式化成两问："从架构的角度，要什么成立才能直接自动批准？什么时候你必须把自己插进来？" 以及 "即使你仔细看，你还在做逐行 review 吗？"
• ⚠️⚠️ 而本页认为最实用的是那条反向诊断（[01:11:35]）：

  "当我跟某个规模的公司聊，真正卡住他们的其实更多是那些低层的 DevOps、CI/CD 的东西——他们的 merge queue 堵了，立起一个 app 要太久。因为确实有更基础的事情，跟那些几乎没关系。再丢进一个 SRE bot 不会是问题的答案，因为有更系统性的东西他们需要先搞定。"

• 🔗 ✅ 本页标注它补齐了本页既有诊断里缺的一项：⚠️ 此前瓶颈被指认在组织侧（Tenex 的"你没法自动化一个并不存在的流程"）、数据侧（Legora）、权限侧（Serval）、流程侧（Serval 的"工程团队先用上是因为他们有 code review"）。 ✅ 而这一条指的是更土的一层——构建与合并的基础设施本身。

⚠️⚠️ 七、spec 的层级错位：本页第一条明确的"我试过、模型做得很差"

（[01:15:36]–[01:19:38]）

• 嘉宾的做法是一条可搬用的手法：PR 描述本身被当成 spec 写——"不只是一段话。它实质上就是这个 PR 里发生了什么的 spec，甚至有文件级的指针指到东西改在哪。" 判据是时效性："只要那是最新的、代表代码库此刻状态的东西，我觉得这其实就够了。"
• ⚠️⚠️ 而 swyx 的反驳是层级错位：

  "我说的是那个 feature、那个代码库的 spec，因为那是所有 PR 的总和。如果你的 PR spec 弄错了或者漏了什么，那就会成为整个代码库该做什么与你这个 PR 想做什么之间的差额。"

• ✅ 他自认无解："我自己也真的为这件事焦虑。我试着指示模型去做，它们做得很差。" ⚠️ 他对人的角色给了一个说法："所以人类是 spec 之神——'五周前我做了另一件事，而你现在在把它反过来'。"
• ✅ 嘉宾给的是一条第三方做法而非答案：Basis（做会计的那家）用 git 跟踪不同文件制品——"有些是 spec、是应当如何的意图，另一些是他们称为代码的 canonical state 的东西，那更像是隐性知识、隐性意图，也必须被形式化到某个地方"。 ⚠️ 效果的表述是转述："我觉得他们发现这对他们是有效的。"
• ⚠️ swyx 自己的构想他明确说可能永远不会做出来："program database"——替代 git，"捕捉所有 trace、把 spec 具体化、而且它还控制挂在它上面的 skills"；两条设计理由是"git 只关注代码"与"git 从设计上到处引入互斥锁，这很糟。你需要超级并发"。✅ 本页记为构想、非产品。

✅ 八、build / buy：一条口径，以及同一决策两次评估判据相反的记录

（[01:01:32]–[01:03:32]）

• 口径："你买是为了学，你建是为了留。" 边界条件是"我们一般是在觉得外面没有成熟供给的时候才自建"。
• ⚠️⚠️ 而本页认为最有方法论价值的是同一个决策（code review 工具）的两次评估：
• 第一次（一年多前）是统计驱动的普查（点名 CodeRabbit、Graphite、Ellipsis 等）："我做过一次分析，看我们的 PR，基本上做了一组饼图——这个在解决什么？我们对它啰嗦程度与有用程度之间的权衡满意吗？" 结论是没有一家越过门槛："它们还可以，但我不觉得它们已经越过了'立刻就有用'的那条线。"
• ⚠️⚠️ 第二次是反的，而他自己点明了："第二次我不打算再硬推了。第一次我有点像是'嘿，我们该采用一个 AI code 工具'。第二次我说不，我不会再那么干了。然后有机地，人们就开始说'嘿，Devin 挺好的，你能不能把我加进去？'" ✅ swyx 当场给了性质："纯凭感觉，对吧。"
• ✅ 本页判这一对照值得保存：⚠️ 同一个决策，第一次用指标判定"不买"，第二次用自发需求判定"买"——而他把后者当成了更强的信号。本页记这与本页既有的"先量化再采购"倾向正好相反，且他没有解释为什么第二次的判据更可信。
• 自建的两个系统：背景 agent 平台 Monocoder（建在 coder.com 的平台上）；一个 Slack bot（名字不可确证），"一部分是 AI 支持、一部分像客户成功、一部分像 QA 工程师"。
• ⚠️⚠️ 而这个 bot 带出一个本页此前没见过的工程问题："我们得回答一些有意思的问题，关于它在跟销售人员说话和跟开发者说话时分别有什么人格。" ✅ 本页记这是第一次看到"同一个内部 agent 对不同职能需要不同人格"被当作实际的工程问题提出。

⚠️⚠️ 九、psychosis：本页第一条把它写成雇佣条件的材料

（[01:52:56]–[01:55:00]）

• 引子是 Steve Yegge 那套"psychosis 的层级"与 Gastown 的结局，⚠️ 本页只取那条自我评价："在 Gastown 造出来的唯一有用的东西就是 Gastown。" swyx 的评价："那是个糟糕的失败。"
• ⚠️ swyx 给的通则："psychosis 是真的，而如果你不让自己对交付真实产品负责，你就只是在拿 LLM 瞎搞。"
• ⚠️⚠️ 而那条招聘门槛是本页此前没有的形态（[01:53:59]）：

  "我不想招任何没经历过 psychosis、又从另一头走出来的人。因为我现在正在为某个人经历 psychosis 付钱。那从他的薪水上说非常贵，从 token 上说非常贵，而我什么都没得到，而他也不明白，我的反馈传不进去。"

• ⚠️ 第二位主持给的学生版本："你以为你在高产，其实不是。你在做 Notion 图表、做各种个人优化，然后发现——糟了，我经历了 psychosis，但什么都没变。"
• ✅ 两人的建议是把它前置："那就去经历它。"
• ✅ 而本页记那条该放在所有采用度讨论前面的现状提醒（[01:51:55]–[01:52:56]）：
• ⚠️⚠️ 嘉宾的确认带了明确的强度："确实有很多公司还在'prompt ChatGPT'那个阶段的某个版本，或者他们刚拿到一个 Cursor 的授权、现在才在让人上手。这件事比我们相信的要真实得多——至少在硅谷这里，我可以 100% 确信地说。"
• ⚠️ 而两人一致认为更该用的阶梯是 Boris 那份团队采用五级（零索引：gated、assisted、parallel、supervised autonomy、AI native），✅ 而口径差别比阶段名更有用："Boris 写这个是为团队采用……而且他说 Anthropic 在第三阶段，我们还在试着到第四阶段。" ⚠️ 本页记这条为 swyx 的转述、未经核对，✅ 但它是本页目前关于"连最该会用的人也没走完"的最具体一条。 🔗 对照 Cloudflare 的 token 治理：没有排行榜，只有三级提醒。