"边界就是产品"：工程团队先用上 AI 是因为他们有 code review、权限会越收越紧而不是越放越宽、以及"我们从没建过定制功能，而且没人要求过"（No Priors × Serval，2026-10-29）¶

嘉宾: Jake Stauch — Serval 联合创始人兼 CEO（企业自动化 / 企业服务管理，正面对标 ServiceNow；此前在 Verkada 卖企业物理安防给 IT 团队）；⚠️ 联创名为 Alex（转录稿只有名）
主持: Sarah Guo & Elad Gil（⚠️ 自动字幕把 Elad 写成 "Alod"）
来源: YouTube · 38 分钟
转录稿: sources/no-priors/20261029-EZcWEsMuLb4（⚠️ 自动字幕 en-orig，无说话人标签）

⚠️ 立场：他是在卖 Serval，全部产品、增长与客户陈述为自述；⚠️ 节目由投资方主持（No Priors 两位主播是投资人）。✅ 但本页认为这一期的厂商色彩比同类材料轻，依据是三处：他主动说出了自家路线里最难看的那部分（"确实有点烦人，得盯着那个流程"）、对自己的能力边界明确划线（"没人真的搞清楚该怎么把这件事做好"、"我不认为有谁短期内能承担那个风险"）、以及对"怎么证明 ROI"这个对自己有利的题目给了否定答案（"我不知道有谁真的搞清楚了怎么衡量你从买来的 token 里得到了什么"）。

⚠️ 自动字幕的专名还原：Serval is → "Servaless"、Veeva → "Vevo"、Claude Code → "cloud code"、Elad → "Alod"、addressable market → "dressable market"、SDLC / FTE / ITSM / HRIS 等缩写多处含混。⚠️ 一处数据缺口本页必须标出：他说"我们今天 200 人"，然后说"……in January"——而一月份的起始人数在转录稿里缺失，所以本页只记"今年从某个数长到 200 人"，不记增幅。

✅ 本页认为这一期值得长期保存的是七处，其中四处是本库此前完全没有的： ① ⚠️⚠️ "工程团队先用上 AI"有一个结构性解释，而不只是"他们是早期采用者"："他们能建、能拿这些工具做实验，是因为他们有 code review 这个流程。哪怕一个 19 岁的实习生去建一个很强的东西，再走这个流程然后进生产，这件事都是很安全的。" ✅ 本库此前把非工程部门的采用滞后归因于能力、工具与数据治理；这是第一条把它归因于"缺一套安全发布流程"的材料，而且它直接给出了处方。 ② ⚠️⚠️ "边界就是产品"："我们从来不认为自己在造 LLM。我们在造护栏，在造边界。而边界就是我们的产品。" ✅ 而推论是反直觉的："智能变得更好只会让我们的产品更强，同时也让客户更想把那些边界、那些护栏收得更紧。" ③ ⚠️⚠️ 一条明确的预测：企业里的个人权限会越收越紧，而不是越放越宽。论证是："我可能会安全地给你比你需要的更多的权限，因为我不觉得你能造成多大破坏。但如果你能用上这些 agent，那你用任何稍微超出常规的权限能造成的破坏就放大了。" → 收到真正的最小权限 → 于是例外会一直出现 → ⚠️⚠️ "通过拥有企业里权限是怎么被提升的这件事，我们反而变得越强势、越不可或缺——你把终端用户权限收得越紧越是这样。" ④ ⚠️⚠️ 而这是本库目前对"把个人 agent 带进大企业"最具体的一次反驳，而且理由不是安全政策："任何一个人的权限集合都太有限了，所以哪怕允许你把你的 agent 带来上班——很多情况下并不允许——它能做的事也极其有限。它连你的邮件都几乎读不了。" ⑤ ⚠️⚠️ 代码取代拖拽式编排的那条抽象层论证："拖拉拽的 workflow builder 是一个让人痛苦的抽象层级，因为它对非技术用户来说太复杂，而对技术用户来说又被抽象得很烦人。" ✅ 原来的阻碍是"没多少人会写代码、而且快不到让自动化划得来"，而 AI 把这条解掉了。 ⑥ ⚠️⚠️ 一条可被直接检验的 SaaS 末日拆分："确实会有一场 SaaS 末日，但发生在 point solution 那类小市值公司身上。我不认为你真能摆脱核心的记录系统——ERP、HRIS、ITSM、CRM。会出现新一代在位者。" ⑦ ⚠️⚠️ 组织形态上一条很硬的选择："我们没有产品职能。我们把产品开发真正下放给了工程团队。"（✅ 配套事实是工程师泡在客户 Slack 里、"大多数人每周至少上一次客户电话，我觉得大多数其实是每天至少一次"；⚠️ 而他承认的代价是"我们的产品发得、变得比任何人能跟上的都快，包括我自己"。）

一、⚠️⚠️ "给其余人的 coding agent"：一条把采用滞后归因到流程的论证¶

（[00:03:01]–[00:04:02]）✅ 本页认为这是全期最该被在实践中用 LLM 与 AI 与就业之外单独引用的一段，因为它给出的是一个可执行的处方，而不是一个观察。

主持人的提法：⚠️ AI 采用里最早的那一大块是 coding agent，而那是工程师在给自家业务建应用；而 Serval 在做的是把这个类目扩出去——让一个 IT 的人也能建全企业都能用的内部工具。

⚠️⚠️ 而他给的因果是本节的核心：

"如果你想想为什么企业里早期的 AI 采用都在工程团队——当然有很多原因，他们显然在很多技术上都是早期采用者——但也因为他们能建、能拿这些工具做实验，因为他们有 code review 这个流程。哪怕一个 19 岁的实习生去建一个很强的东西，再走这个流程然后进生产，这件事都是很安全的。" "我们想把同样的能力带给企业的其余部分。"
形态：平台把 coding agent 带给 IT 部门，IT 再带给 HR、财务、人力、法务；⚠️ "底下是 coding agent，但上面有这些抽象、护栏和控制，所以东西要走审批、走 staging 与审批周期、留审计轨迹。"
⚠️⚠️ 而他的另一条核心洞察本页认为同样重要，因为它改变了谁是买家："IT 其实是想建东西的。而对世界上大多数组织来说，他们没有工程部门，他们有 IT 部门。大多数公司有 IT 部门，而不是一支软件工程师团队。所以是 IT 在为公司建和配置技术，而我们在给他们造那个 AI 平台。"
🔗 ✅ 本页标注这与本库既有材料的接口：⚠️⚠️ 本库此前关于"为什么企业里 agent 还没落地"的材料把原因放在数据治理（Ali Ghodsi）、工作流复杂度（Decagon）、流程知识（Lassie 的"模型不知道这份工作怎么做"）上；✅ 这一条给了第四个原因——缺一套能让不熟练的人安全地把东西推上生产的发布流程，而工程部门恰好早就有了。本页认为这四条不冲突，而这一条是其中最容易被照搬的。

⚠️⚠️ SDLC 作为采用的解锁条件，以及"有些公司永远到不了那儿"¶

（[00:17:10]–[00:19:10]）被问到除了"代码才是自动化的正确形式"之外还有什么核心设计原则，他给的第一条是软件开发生命周期。

内容："在工程语境里我们习以为常的那套——有 dev 环境，然后 staging，然后 prod，中间有这些闸门，也许还有分支让人们在上面开发而不会伤到别的系统。"
⚠️ 主持人当场确认了反差："而且说清楚一点，今天的 IT 自动化不是这么运作的。" ⚠️ 他的回答是部分是："有些情况下是，但我觉得大多数新的 AI 产品没有接受这一套。它们基本上在说：嘿，我们来建这些酷 agent，然后直接发到生产。"
⚠️⚠️ 而这句是本节的落点："但'如果你是一家大企业、一家大金融机构，你就必须真的走一套 SDLC 流程'这件事——他们不会在没有评审、没有用户验收测试和所有这些（合规检查）的情况下就上线新的 agent 能力。"
✅ 他对自己公司的取向给了一句很好的概括："所以我们想得很多的是：什么才会说服世界上最大的那些公司采用这项技术——而不只是什么东西很强、很酷、我们很想交到客户手上。"
⚠️⚠️ 而对主持人那句"很多 AI 公司要花一两年才想明白这些，有时更久"，他的回答比提问更强：

"我觉得有些情况下他们永远到不了那儿。有些公司就是看了一眼做企业软件要什么，然后决定：我们并不真想建那个东西。"
✅ 他给的机制是"要建的是一整套不同的建造原则和产品"，⚠️ 而他把这当成下沉到中小市场的那批公司的真实原因之一（"他们确实看过为企业建造的机会，但那需要一整套不同的东西，有些就是选择不做"）。
✅ 而他自己的站位是：⚠️ "把你最难搞的问题给我，我们来解，让 AI 转型在这个充满风险与治理顾虑的疯狂世界里变得可能。"

二、⚠️⚠️ "边界就是产品"，以及权限会越收越紧这条预测¶

（[00:12:09]–[00:14:09]）✅ 本页认为这是全期最该被 LLM 安全与治理与 AI 商业化与价值捕获同时引用的一段，因为它同时是一条安全架构判断和一条价值捕获判断。

被问"模型变强你是兴奋还是紧张"：

⚠️⚠️ "我们超级希望它们变得更好……我们一直根本上认为，我们不是在自己造 LLM。我们在造护栏，在造边界。而边界就是我们的产品——因为我们就是一家有大量规则、审批、流程和政治的大企业能安全、舒服地大规模采用这些工具的那条路。" "Serval 就是那个边界。Serval 就是那些护栏。" ⚠️⚠️ "智能变得更好只会让我们的产品更强，同时也让客户更想把那些边界、那些护栏收得更紧。"

⚠️⚠️ 而他主动推进到一条预测，并在主持人追问"为什么会这样"时给了论证：

"我其实认为，企业里个人的访问权限会被管得越来越严。" ⚠️⚠️ "因为我可能会安全地给你比你需要的更多的权限，因为我不觉得你真能造成多大破坏。但如果你能用上这些 agent，那你用任何稍微超出常规的权限能造成的破坏就放大了。而我们现在在网络安全风险上正看到这件事。" "所以如果我是一家大企业，我真正会想做的是把每个人的权限收到真正的最小权限——除非你的工作绝对需要，你不能访问任何文档、不能采取任何动作。"
✅ 而价值捕获的那一步是他自己接上的，本页认为这是本期最该保存的商业论证：

"但那样你就会一直有例外。我们就是那个授予这些例外、并让你能围绕它设置审批程序、留审计轨迹和关联工单的层。" ⚠️⚠️ "所以通过拥有企业里权限是怎么被提升的这件事，我们反而变得越强势、越不可或缺——你把终端用户权限收得越紧越是这样。"
🔗 ✅ 本页标注这条与本库既有安全材料的关系，因为它们在诊断上一致、在结论上互补：
诊断侧一致：⚠️⚠️ CrowdStrike 的 Kurtz 与 Cloudflare 的 Knecht 反复指认的断点就是身份与凭据；Anthropic 平台团队的"大脑和手分开"（凭据在独立 vault、agent 只看到占位符、出口代理注入）是厂商侧的同一方向。
⚠️⚠️ 而这一条补的是企业内部的那一侧，而且它是本库第一条把"权限提升"讲成一个可以被拥有的产品位置的材料。 ✅ 本页认为这三者拼起来给出一个完整判断：agent 时代的控制点落在凭据与权限的授予环节，而那个环节同时是安全边界和商业要地。

⚠️⚠️ 为什么"把个人 agent 带来上班"在大企业里不成立：理由不是安全政策¶

（[00:04:02]–[00:06:05]）主持人问的是"这和 OpenAI 的 dot 这类职场 agent / 虚拟助理怎么交汇"。

⚠️ 他先划了适用范围："那些在消费者、SMB、甚至很多中端市场组织里确实很好用。"
⚠️⚠️ 而大企业里不成立的理由是权限的大小，不是政策的禁止：

"在大企业里有太多东西——这点我进来之前真的没体会到——围绕审批、围绕你能做和不能做什么，有太多流程；任何一个人的权限集合都太有限了。所以哪怕允许你把你的 agent 带来上班——很多情况下并不允许——它能做的事也极其有限。它连你的邮件都几乎读不了。" "所以当你想想你在工作上需要做的所有事、你想触达的所有系统、你能建的所有有意思的自动化——你个人的权限最后限制得太死，以至于这些个人 agent 也极其……没那么有用。"
✅ 他们的绕法是把权限来源换掉：因为他们对接的是能用服务账号凭据和管理员级权限的 IT 团队，所以"我们能造出一种结构，让人们可以拿到被提升的权限、在工作里做这些疯狂的事，但配上非常非常严格的确定性审批周期、确定性的工作流，以及审计轨迹——因为我们底下同时是一个工单系统。"
⚠️ 具体形态是 just-in-time："你说我想让我的 agent 去做 X、Y、Z……在 Serval 里这会生成访问请求、走审批流程，全部被记录，然后你拿到即时（just-in-time）访问去跑那个确定性工作流一次，而这一切都会被追踪。"
✅ 而他主动给出了代价，本页认为这处让步值得记：

⚠️⚠️ "是的，这比我们在 Instinct、Muse 这些工具里喜欢的那种魔法般的个人 agent 体验要烦人一点。但这就是一家大企业——尤其是受监管的企业——要想采用这类技术，必须成立的条件。"
🔗 ⚠️⚠️ 本页标注这与本库"个人 agent"主线的张力，不做裁决：本库此前的个人 agent 材料（Peter Steinberger 的 OpenClaw、Gavriel Cohen 的 NanoClaw、dots 的云上虚拟机）几乎全部是个人/开发者语境；✅ 这一条给了企业语境下的否定结论，而且理由是结构性的（权限集合太小），不是文化或政策上的。本页认为这条可以直接检验：如果个人 agent 在大企业里真的起来了，那一定伴随着一套新的权限授予机制。
⚠️ 他对未来的猜测是分家（[00:16:09]–[00:17:10]）："我觉得每个人都会有自己的个人 agent 替他做事、并委派给其他人的个人 agent……所以你的 agent 会和公司里别的 agent 说话"，⚠️ 而他认为工作与个人 agent 会分开："我觉得会分开。就像我有一个 Gmail、也有一个公司邮箱。" ✅ 他自己把这件事的核心讲成一个张力："雇员和消费者想从工作中的个人 agent 得到什么，和企业从治理角度需要什么——我觉得那个张力里会有很多机会。"

三、⚠️⚠️ 代码作为自动化的正确抽象：一条"AI 改变了哪个抽象层赢"的论证¶

（[00:10:09]–[00:12:09]）✅ 本页认为这一段与本晚第一期的 Supabase（migration 历史日志 → 声明式 schema）是同一类论证的两次独立出现，本页在末尾做了对照。

⚠️ 为什么选 ServiceNow 而不是 Salesforce："我们并不真的理解怎么打赢那些别的公司、我们的优势在哪、AI 解锁了什么他们追不上的东西。而我们因为做 IT 的经历而理解的是，ServiceNow 根本上是一个工作流自动化平台。"
⚠️⚠️ 而联创的早期主张是本节的核心：

"代码才是企业里表达自动化的正确方式。你就应该用代码来建所有自动化，而那些拖拉拽的 workflow builder 是一个让人痛苦的抽象层级——因为它对非技术用户来说太复杂，而对技术用户来说又被抽象得很烦人。代码是更好的自动化建造方式。" ⚠️⚠️ "显然的问题是，没多少人会写代码、而且快不到让自动化划得来的程度。所以当 AI 让这件事变得可能，对我们俩来说就对上了：如果代码是建自动化的正确方式，而现在任何人都能写代码，那我们就能建一个更好的自动化平台。"
✅ 而"最好的自动化平台市场在哪"这一步是他自己推的："其实就是去正面迎战 ServiceNow 这种巨大的遗留软件公司。"

⚠️ 两年半前的赌注，以及一个被建起来又变得不必要的脚手架¶

（[00:10:09]–[00:12:09]）✅ 本页认为这是本库少见的一条"脚手架随模型变好而作废"的完整记录。

⚠️ 主持人指出前提："两年半前你们开始做的时候，大部分编码的东西还是 tab 补全。它不 work。"
⚠️⚠️ 而他的赌注与它的理由很具体，而且带一条校准：

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

四、⚠️ 正面打在位者：两条标准打法都被拒掉了¶

（[00:07:06]–[00:10:09]）⚠️ 本页按创始人叙事处理——这类"我们从第一天就立志打败 X"的讲法有强烈的事后合理化倾向，而本页认为其中只有一条是可迁移的论证（见下）。

⚠️ 自述的起点：公司两年半；他在 Verkada 卖企业物理安防给 IT 团队时发现这个类目——⚠️ 他爱问的两个问题是"你们花钱最多的是什么？你们最恨的是什么？"，而 ServiceNow 在很多清单上都排在前面。 ✅ 但他同时给了对手应有的评价："他们是一家很棒的公司，做了那么多而且做得很好，你凭什么能和他们竞争？"
用户的不满他讲得很具体（[00:02:01]）："在那个平台上太难建东西"——非常健壮、可定制、强大，能映射所有企业工作流，但"你每一个想做点酷东西的想法，都得去实现，而且很多时候你要请咨询公司来实现"；⚠️⚠️ "所以它总是比你想它在的地方落后 6 到 12 个月。" ✅ 而他给了一个明确的适用边界："如果你建的是一个要用 5 年、10 年的东西，比如一个大的入职流程，而你的业务不会有任何变化，那是没问题的——你可以把那些前期投入都花掉，然后它被部署、工作一阵子。但如果你只是想跟上你想建的所有自动化，ServiceNow 跟不上。" ⚠️ 加上"而且它很贵，而且一直在变得更贵"。
⚠️ 两条标准打法与他的拒绝理由：
① 建一个层、和在位者好好相处：⚠️ 主持人当场指出"这会给你设上限"，✅ 并给了唯一的反例——Veeva（"他们从 Salesforce 上起步，然后迁移成了自己的平台。那是我能想到的唯一一个反向整合成功的"）。
② 下沉到中小与中端市场（✅ 主持人给的例子是 Rippling、HubSpot，⚠️ 以及"十年"这个时间尺度）。
⚠️ 他的说法是："我们看了看那些，然后说：为什么不直接去打那个最大的？难多了，但如果你赢了，奖品至少很大。" ⚠️⚠️ 以及那句自嘲："我喜欢说，一切都完全按照我们非常妄想的计划在走。"（自述：第一天在联创 Alex 的客厅里两个人，列了一张公司清单、圈出 ServiceNow。）
✅ 而本页认为这一段里唯一可迁移的论证是这条：

⚠️⚠️ "这对我们太重要了，因为如果你从第一天就为大企业建造，你最后会做出非常不同的决定。所有产品决策、你怎么搭团队、你怎么想增长，都和你先服务一个市场、然后希望以后扩张，根本上不同。"
✅ 本页标注：这条是关于路径依赖的，而不是关于勇气的——它可以被检验（去看那些下沉后试图上行的公司的产品与组织结构），而"我们第一天就圈了它"不能。

⚠️⚠️ "Serval 是你在公司里升职的方式"：一条本库此前没有的采用论证¶

（[00:14:09]–[00:16:09]）主持人的问题很尖：换掉一个嵌得很深的在位者，对客户个人来说是职业风险，为什么要做？

⚠️⚠️ "我们必须说服自己和客户：Serval 是你在公司里升职的方式。它不能是'Serval 是你冒的一个风险，希望另一边有点收获'。我们必须让客户相信：你做这件事，你会成就你的职业生涯。你不只是不会挨骂，你其实会升职。"

路径是自上而下：⚠️ "我们卖给 C-suite，很多情况下卖给 IT 领导层，然后往其它部门分发。"
⚠️ 而那条话术是："人们把职业生涯建立在 ServiceNow 上。你要把职业生涯建立在下一代上。"
⚠️ 自述的证据是一个客户："我们最大的客户之一是 Fox。Fox Corporation 全公司采用了 Serval，而在一线主导那次迁移的那个人，实际上被提名为全公司的 MVP"，还为这项工作拿了个奖。 ⚠️⚠️ 本页标注：这是单个自述案例，不构成模式。
✅ 但本页认为这个框架本身值得保存：⚠️⚠️ 本库此前关于企业采用的材料几乎全部落在技术与经济论证（ROI、工作流复杂度、数据治理、合规）；这一条把采用的决定因素放在个人的职业激励上，而且把它当成产品定位的一部分来做。本页认为这与本库多份"采用断点在中层"的记录（Cuban 的"我们能说服 CEO，但说服不了采购的人"、Decagon）是同一问题的两种处理方式：一方诊断阻力在哪，这一方给的是如何改变那个人的收益函数。

五、⚠️⚠️ ROI 证明是下一个行业问题，以及"按跑过的 workflow 计费而不是按 token"¶

（[00:21:11]–[00:23:14]）✅ 本页认为这是全期对 AI 商业化与价值捕获最有价值的一段，因为它给了一个定价单位的论证，而不只是一个趋势判断。

主持人的框架（她自述来自企业客户的一年历程）：⚠️ "我们先让人试；然后 token max；然后又要限制、搞清楚谁在有效地用。"

⚠️ 他的观察是分层的："我确实看到我们的 CIO 客户在试着从最初那个 token maxing 时代往回收。但我也认为我们在采用曲线上还太早，所以总量上不会是一次收紧——它其实会继续相当剧烈地上升，因为大多数公司还是第一次在搞清楚这件事。"
⚠️⚠️ 而他说客户要的不是省钱："我从客户那里一直听到的，不是对长期预算影响的担忧。他们知道短期会有一次回收，但他们仍然计划增加支出。他们需要的是更多 ROI 的证明。"
⚠️⚠️ 而他对这个对自己有利的题目给了否定答案，本页认为这处诚实值得记：

"而那很难。我不知道有谁真的搞清楚了怎么衡量你从买来的那些 token 里得到了什么。"
✅ 他说这是机会（"展示正在被完成的工作，并试着把它等价成在别的平台上、用别的成本模型、或者用人力本来会完成的工作"），⚠️ 并把它当成任务接受下来："这就是客户要的——帮我证明这件事值得。这就是作业。"
⚠️⚠️ 而定价单位那条本页认为是本节最可直接引用的：

"我们试着按跑过的 workflow 来定价，因为我觉得那更好地反映了实际被完成的工作——而不是只按 token，token 更像是啰嗦和低效。"
✅ 本页标注这条为什么值得记：🔗 本库此前的 token 定价材料是从供给侧给的（游凯超 / vLLM 的"按 token 计费而非卖工程师时间"、Baseten 的优化报价单）；⚠️⚠️ 这一条是从应用侧给的反向论证——token 数既包含价值也包含浪费，所以作为计价单位它把供应商的低效转嫁给了客户。本页认为这两条并读才看得清"按什么计费"这个问题的两面。

⚠️⚠️ SaaS 末日：一条可被直接检验的拆分¶

（[00:23:14]–[00:25:15]）

⚠️ 他说自建派的发现是经济学而不是能力："所有跟我聊过、试着自己 vibe code 这些工具的公司——尤其是主要的记录系统，不是那些 point solution——都发现建和维护企业软件相当贵。即便你能做，很多情况下在经济上也不合理，除非你的需求在某种意义上非常特殊。" ✅ 他把它归成老问题："为不属于你核心能力的东西买现成的，一直是 build vs buy 的论点。"
⚠️ 他列的具体成本项：边缘情况、"会坏掉、人们得去更新它，所以你得配一支团队、你在付那份人力"，⚠️⚠️ 以及一条很具体的组织事实——"而且很多情况下没人真的想在内部工具团队工作。"
✅ 而发生的地方他指得很清楚："很多公司有几百几百个 SaaS 应用，他们大概只需要几十个。所以我确实认为那些 point solution 的泛滥会收缩，而它们会被核心的记录系统和核心平台吃掉。" ⚠️ 主持人补了一句被确认的："中间件我觉得也会直接消失。"
⚠️⚠️ 结论是本节最该引用的：

"所以确实会有一场 SaaS 末日，但发生在 point solution 那类小市值公司身上。我不认为你真能摆脱核心的记录系统——ERP、HRIS、ITSM、CRM。我觉得那些会留下来。它们可能会转变，而我们在 Serval 看到的就是我们在置换那些工具。所以我觉得会出现新一代在位者。但我不觉得那些类目会就这么消失。"
✅ 本页标注这条为什么有价值：⚠️⚠️ 它把一个常被整体接受或整体否定的论断拆成了两半（point solution 会死 / 记录系统会换人但不会消失），而且两半都可检验。 🔗 与本页既有的 SaaS 末日材料并读：Benedict Evans 与 Sinofsky 的"护城河 = 例外处理"、Mark Cuban 的"窄数据集是魔法，通用场景不是"。

六、⚠️ 产品与平台的边界：一条"什么该进内核"的机制¶

（[00:19:10]–[00:21:11]）

⚠️⚠️ 一条很强的纪律："部署软件的时候，很重要的一点是我们其实从来不建定制功能。我们不建一次性的产品能力。而幸运的是在我们这个类目里，没人要求过我们这么做。" ✅ 理由是："人们要的每一个东西，都是别的客户在某个时点也会想要的东西。他们可能影响优先级，但那仍然是我们一直想要放进平台的东西。"
✅ 而因为底下是 codegen，所以"定制"落在了另一层："你在 Serval 里建的东西非常非常独特。一家公司的密码重置工作流会和另一家的非常不同——听起来很意外；入职、离职和所有这些内部自动化也一样，它们看起来非常不同，但那是被烘进平台的核心原语里的。"
⚠️⚠️ 而这句定位本页认为很准确："Serval 几乎变成了 IT 部门和其它部门建自动化、并大规模管理它们的那个 IDE。"
✅ "什么该升级成一等功能"的判据是重复："如果我们看到同一批客户一遍一遍建同样的自动化、还得用同样的方式去定制它们，我们就开始考虑：嘿，这是不是该成为产品里的一等功能？" ⚠️ 他给的两个例子很具体：① 很多客户在建工作流去检测互相冲突或过期的知识库文章 → 索性自动做掉；② 回收没人用的软件许可（"你在付钱但没人用的订阅，自动取消掉"）→ 直接做进平台。
✅ 本页标注这是一个可迁移的产品机制：⚠️⚠️ 在一个 codegen 平台上，"客户自建的重复项"本身就是产品路线图的信号源，而平台因此能用极低成本测试什么该成为内置功能。本页认为这比"我们听客户的"具体得多。

⚠️⚠️ Catalyst：用一个 agent 来操作平台——"文档 → agent"的第三个独立样本¶

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

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

七、⚠️⚠️ background agent："企业软件里的终极登月"，以及他给的渐进授权路径¶

（[00:29:17]–[00:32:18]）✅ 本页认为这是全期最该被 LLM OS 与新计算范式与 LLM 安全与治理引用的一段，因为它把一个被广泛期待的形态和它的阻塞条件放在了一起。

⚠️⚠️ "我总是这样跟公司描述 background agent：这是企业软件里的终极登月。就是这些 agent 自己跑出去替你干活，神奇地发现你所有的问题、解决你所有的问题。如果我们能把它部署起来、它能工作、还能遵守我们的权限，那会很了不起。" ⚠️⚠️ "而我觉得没人真的搞清楚该怎么把这件事做好——因为一方面你希望它们非常自主地跑出去把事情想明白、解决问题，不用人盯着。另一方面，自主性在企业里非常可怕。"

⚠️ 主持人点出了对照事件："这就是那些 OpenAI、Hugging Face 事件之类的——agent 被给了一个任务，然后为了完成那个任务做了某些意料之外的事。"（🔗 本库记过这几起，见 LLM 安全与治理与 Modal 那期。）
✅ 而他对"想要什么"的表述是本节最清楚的一句："我最好的员工，你怎么对他们？你说：这是大方向上的任务，去吧，别来找我，你回来的时候已经做出了了不起的东西。我希望能这样信任 agent……而我不认为我们已经搞清楚怎么用一种在企业里感觉安全的方式做到这件事。"
⚠️⚠️ 被问"怎么才能安全"（主持人点了 constitutional AI 与某些 RL 形式作为选项），他给的是一条流程方案而不是技术方案：

"在大企业里我们是这么想的，它不完美，但它是一种能力的渐进升级（incremental escalation of capabilities）。它跑出去做这些事，然后回来说：嘿，我想要能做这些事，这会帮我做我的工作。然后你批准它们。而所有这些都是确定性工作流——我想调这个工具，我想跑这个做 X、Y、Z 的脚本，我能做吗？你就带着一定的权限和护栏去批准这些。" "随时间推移这个 agent 会变得挺能干，因为它有了一个足够大的工具箱，能解决大多数问题。"
✅ 而他主动给出了这条路径的两处代价与边界，本页认为这是本节最该保存的部分：
⚠️ 代价："它不完美，因为得盯着那个流程，挺烦人的。"
⚠️⚠️ 边界（为什么必须这样）："但我觉得这是你必须做的，因为否则它理论上就可以开始写能在你的系统上采取动作的代码，而那是一个无界的安全风险——我不认为有谁短期内能承担。"
⚠️⚠️ 而被问"这是模型问题还是护栏/harness 问题"，他的回答本页认为是全期最该被跨页引用的一句：

"我觉得老实说两者都是。记忆显然必须越来越好，因为你想理解偏好。上下文得大到不可思议，因为我不想跟你开一堆不同的对话，我想要一个一直回溯到我们第一次谈话的单一对话，而你记得其中相关的关键点。" ⚠️⚠️ "然后我觉得权限问题会一直是最大的那件事——因为即便我觉得你是一个非常非常有价值、很聪明的 agent、能替我做所有这些事，我又有多信任你可以就这么撒开跑、而我不必盯着你的动作？"
✅ 主持人的类比被他接受："对人也是这样——任何替你工作的人都得回来跟你确认'这是你想要的吗，这里有三个选项'。所以这是一个很正常的流程。"
🔗 ⚠️ 本页标注这与本库既有材料的接口：Anthropic 一侧的三道发布闸与"大脑和手分开"、OpenAI 的 Guardian 逐动作比对书面意图、Onyx Security 的"AI 看管 AI"——⚠️⚠️ 本库此前的解法方向大多落在"用模型层做判断"或"用基础设施做硬墙"；这一条给的是第三种：用人类审批把能力一项一项放出来，并明确承认它烦人。本页认为它的价值在于这是目前唯一一条明说"我接受这个摩擦，因为替代方案的风险无界"的方案。

八、⚠️⚠️ 组织：没有产品职能，以及"每个员工更能干了，所以我们要更多人"¶

（[00:32:18]–[00:37:19]）

规模（自述）：⚠️ "我们今天 200 人"；⚠️⚠️ "……in January，所以这是难以置信的一年"——本页标注：一月份的起始人数在转录稿里缺失，所以只记"今年从某个数长到 200 人"，不记增幅。
⚠️⚠️ 而招聘速度的论证本页认为是本期对 AI 与就业最直接的一条：

"招聘速度我觉得会比今天还要快。我们相信工作的需求是无限的，竞争是无限的，野心是无限的。所以尽管每一个员工做的事都比一年前多得多，我们对他们能做什么有更大的野心。" ⚠️⚠️ "所以因为每个员工的生产力都高这么多，我们其实想要更多的人，不是更少。"
🔗 ✅ 本页标注这是同一结构在本周的第三次出现：DoorDash 的"自动化更多 = 人更多"、Supabase 一边说"serverless 员工"一边要招尽可能多的 SRE（本晚第一期）、以及这一条。 ⚠️ 而三者给的理由不同：DoorDash 的是需求侧网络效应，Supabase 的是运维不可自动化，这一条是野心与竞争无上限。本页不裁决哪条更对，但记下"生产力提升 → 更多人"在三个不同业务里都被当作结论。
⚠️ TAM 的讲法本页按创始人叙事处理："可寻址市场的大小更多是关于我们野心的大小，而不是关于这个生意能做多大的根本限制"；✅ 而他主动说了这种状态的坏处：⚠️ "这不是严格地更好，因为现在有这么多开放空间、我们要做的关于到底聚焦什么的决定多得多。"
⚠️⚠️ 而组织形态上那条选择是本节最硬的事实：

"我们把产品开发真正下放给了工程团队。我们没有产品职能——因为他们才是每天在跟客户聊的人，他们能迅速适应客户今天、这一周在说什么，而不是一个月前在说什么。"
配套的具体做法：⚠️ "我们和客户是嵌在一起的。即便那些并不被派驻的工程师，也在客户的 Slack 频道里……大多数工程师每周至少上一次客户电话。我觉得大多数其实是每天至少一次。"
✅ 他给的比喻很好：⚠️ "这就像沉浸在一个国家里学外语。你变得如此沉浸在买家和客户的心智里，以至于你理解他们想要什么、他们怎么想事情，并且能实时适应他们偏好的变化。"
✅ 而他承认的三处代价本页认为比上面的做法更值得保存：
⚠️⚠️ "我们的产品发得、变得比任何人能跟上的都快，包括我自己。"（⚠️ 主持人补的一条被接受：客户也只能以某个速度吸收。）
⚠️ 招聘标准得改："我们做的一个改变是，工程师必须非常产品导向、必须真的理解我们的客户……因为他们要在边缘上做那么多决定，而不是每一个产品决策都能冒泡到领导层。"
⚠️⚠️ 以及必须愿意撤回："你必须愿意快速行动，也愿意在走错方向时撤销和回退，杀掉你的心爱之物。" ✅ 而他说自己最自豪的恰恰是这个："在 Serval 我最自豪的事情之一，是我们有多少次决定擦掉我们过去做过、而且曾经非常投入的东西，就说：算了，市场变了，客户变了，我们要用完全不同的方式做事。" ⚠️ 他把这当成跟上节奏的能力来源："那种一遍又一遍重新发明自己的能力和意愿。"

⚠️ 扩散与 FDE：本页标注一处三方分歧¶

（[00:06:05]–[00:07:06]）

⚠️⚠️ 他对瓶颈的判断："扩散显然是这里的缺口。技术能做的事太多了，而企业几乎只刮到了可能性的表面。而那里面很多就是理解人、流程、到底存在哪些工作流、你希望它们未来是什么样——而我们认为这些仍然需要人。"
形态是两个角色加一个服务部门："deployment strategist"（部署策略师）+ "deployed software engineer"（派驻工程师）到客户现场；✅ 然后是 "Pro Serval"（他说这个领域叫 automation engineering）做持续支持与服务，⚠️ 理由是："就像我们在软件工程上发现的那样，工作的需求其实是无限的。"
🔗 ⚠️⚠️ 本页标注这形成了本库里一处清晰的三方分歧，而且其中两方出现在本晚：
① Serval（本期）：FDE 是解法——建两个派驻角色 + 一个持续服务部门，因为扩散缺口需要人。
② Decagon 的"FDE 是陷阱"：同样的做法被判为陷阱。
③ Mark Cuban 的"forward-deployed engineer 是一个能力测量"（✅ 而他在本晚第二期里延续了同一立场）：⚠️⚠️ "如果你需要 forward deployed engineer，那这件事本身就把 AI 的水平说完了。"
✅ 本页不裁决，但指出三方其实在回答不同问题：Serval 回答"现在怎么把它落地"、Decagon 回答"这样做会不会毁掉你的毛利与产品"、Cuban 回答"这说明模型到了哪一步"。⚠️⚠️ 本页认为真正的分歧只在第二条与第一条之间，而那一条是可以被检验的（看毛利结构与服务收入占比随时间怎么走）。

⚠️ IT 这个用户：一条关于"不要居高临下"的产品立场¶

（[00:25:15]–[00:27:16]）主持人的问题是：IT 不是软件工程师，但他们懂业务；你怎么把 vibe coding 和"要建稳健的 IT 系统"调和？"他们懂安全架构吗？懂这东西怎么和治理集成吗？"

⚠️⚠️ 他的回答先否了问题的前提："IT 其实比很多人愿意承认的更接近软件工程师。尤其在大企业里，IT 部门在很多情况下就是那支工程团队——他们没有软件工程团队，所以 IT 运行所有这些系统，而 IT 经常确实在写代码、管系统。"
✅ 立场："所以我们把他们当成成年人对待。我们给他们我们会给软件工程师的那些工具。" ⚠️ 但有一条限定："我们不只是把 Claude Code 丢给他们然后说祝你好运。我们建的是一个专门针对他们用例的平台。"
⚠️ 而设计上是分 persona 的："我们不期待他们一定能写代码或者理解被写出来的是什么，但我们仍然让他们能看到底下的代码。你随时能看到代码，也随时可以走完整的软件开发生命周期——但你也可以不走。" ✅ 两端的 persona 他说得很清楚：一端是真的会写也确实在写代码的 IT 工程师；另一端是市场部或人力部的人——"永远不想看到代码，但仍然想要底下 codegen 的那种灵活性，因为他们有一个复杂工作流，而他们不想靠拖拉拽把它拼出来。"
⚠️⚠️ 而这段里最锋利的是他对既有产品的批评：

"我觉得外面很多产品其实对 IT 有点居高临下：'噢，你其实不懂这些东西，所以你需要这个被阉割过的、更有主张的、更简单的版本。'实际上 IT 欣赏这种复杂度，欣赏这些平台的力量。我们想把那个交付给他们。"
✅ 本页标注这条与 Supabase 那条"声明式 schema 是为 agent 做的，但人类也一样受益" 是同一类判断：⚠️⚠️ 都在说"把强原语交出去而不是把它包起来"。而本页认为这一条更难，因为接收方不是开发者。

本库此前未有、本期补上的空缺¶

空缺	本期给的内容
"为什么工程团队先用上 AI"的流程解释	⚠️⚠️ "他们能拿这些工具做实验，是因为他们有 code review 这个流程。哪怕一个 19 岁的实习生去建一个很强的东西，再走这个流程然后进生产，都是很安全的"——✅ 本库此前把非工程部门的滞后归因于能力/工具/数据治理，这是第四个原因且最容易照搬
"边界就是产品"这个定位	⚠️⚠️ "我们不是在造 LLM，我们在造护栏、造边界，而边界就是我们的产品"；✅ 推论反直觉："智能变好只会让客户更想把护栏收得更紧"
权限会越收越紧这条预测，以及它的价值捕获含义	⚠️⚠️ agent 放大了"稍微超出常规的权限"能造成的破坏 → 收到真正最小权限 → 例外会一直出现 → "通过拥有权限是怎么被提升的，我们越是在客户收紧时越不可或缺"
"个人 agent 带进大企业"的结构性反驳	⚠️⚠️ 理由不是政策而是权限集合太小："它连你的邮件都几乎读不了"；解法是把权限来源换成 IT 的服务账号 + just-in-time 提权 + 确定性审批 + 审计轨迹（底下是工单系统）；✅ 并承认代价"比 Instinct、Muse 那种魔法体验烦人一点"
一条"AI 改变了哪个抽象层赢"的论证	⚠️⚠️ "拖拉拽的 workflow builder 对非技术用户太复杂、对技术用户又抽象得烦人"；原阻碍是"没多少人会写代码且快不到划得来"，而 AI 解掉了它
一个被建起来又被模型吃掉的脚手架	早期用示例库给 LLM 打底建密码重置这类工作流 → "后来模型就是变得太好了，很难给它一个它自动化不了的工作流，只要那些 API 存在"；✅ 瓶颈从"模型会不会写"转移到"目标系统有没有接口"
采用的职业激励框架	⚠️⚠️ "Serval 是你在公司里升职的方式。它不能是你冒的一个风险"；⚠️ 自述证据是单个客户（Fox，主导迁移者被提名全公司 MVP）
定价单位的论证	⚠️⚠️ "我们按跑过的 workflow 定价，因为那更好地反映实际完成的工作——token 更像是啰嗦和低效"；✅ 以及对自己有利题目的否定答案："我不知道有谁真的搞清楚了怎么衡量你从买来的 token 里得到了什么"
SaaS 末日的可检验拆分	⚠️⚠️ "会有一场 SaaS 末日，但发生在 point solution 那类小市值公司身上。我不认为你真能摆脱 ERP、HRIS、ITSM、CRM……会出现新一代在位者"；⚠️ 自建派的阻碍是经济学与维护（含"没人真的想在内部工具团队工作"）
codegen 平台上"什么该进内核"的机制	从不建定制功能（"而且没人要求过"）；定制落在用户自建的自动化里；而"客户一遍遍建同样的东西"就是升级成一等功能的信号（例：检测过期知识库文章、回收闲置许可）
"文档/培训 → agent"的第三个独立样本	Catalyst：一个给管理员用来操作平台的 agent，"你不需要把自己训练成会用 Serval 的人"，而 agent 就是主界面——✅ 与 10-27 Anthropic、10-28 Supabase 构成五天内三例
background agent 的阻塞条件与一条流程方案	⚠️⚠️ "企业软件里的终极登月……而没人真的搞清楚该怎么做好"；方案是能力的渐进升级（agent 申请、人逐项批准确定性工作流），✅ 并明说代价（"得盯着，挺烦人"）与边界（"否则它理论上就能开始写能在你系统上采取动作的代码，那是一个无界的安全风险"）；⚠️⚠️ "权限问题会一直是最大的那件事"
一条很硬的组织选择	⚠️⚠️ "我们没有产品职能"，工程师泡在客户 Slack、"大多数每天至少一次客户电话"，比喻是"沉浸在一个国家里学外语"；✅ 承认的代价是产品变得比谁都快（"包括我自己"）、必须把决策下放、必须愿意"擦掉过去很投入的东西"
"生产力提升 → 更多人"的第三个样本	⚠️⚠️ "因为每个员工的生产力都高这么多，我们其实想要更多的人，不是更少"（理由是野心与竞争无上限，与 DoorDash 的需求侧、Supabase 的运维侧理由不同）