同一天、同一个会场，三段没有访谈的演讲。海蒂把每一步拆给对的机制，凯文在绞肉机旁找他的用户，SEP 的两个人说黑灯工厂不是目标。我按上台顺序把它们串成了一期。
这一期是什么
Practical AI 第 378 期《丰盛的智能》，2026 年 10 月 29 日发布，全长 54 分 14 秒。这一期不是访谈：主持丹尼尔·怀特纳克（Prediction Guard 创始人兼 CEO）是今年第二届中西部 AI 峰会的司仪，他把会上三段演讲剪出来播出，中间用自己的串场和两段广告隔开 12。
三段话各自独立，但指向同一件事：
- 海蒂·波特（梅耶集团 AI 负责人、兰辛 AI 实验室创始人）讲怎么给工作流里的每一步指定机制，再用护栏、评测和观测把它围住。三个真实案例：一条橡胶软管产线、先正达的现场选种、斯坦福的外科共管。
- 凯文·索罗里奥（Focused 高级软件工程师）讲给蓝领工人造工具时，为什么「替他们造」会失败、「和他们一起造」要怎么开始。
- 克里斯·欣克尔（SEP 创新总监）与安德鲁·邓兰普（SEP 高级软件工程师）讲黑灯工厂不是每个团队的目标：六个约束决定四种模式，模式就是适配。
逐段要点整理
01 欢迎收听（00:00–02:26）
片头之后，丹尼尔用两分钟交代了三件事：他是这届峰会的司仪；他和会议方谈好了可以播出几段演讲；今天出场的是海蒂·波特、SEP 的克里斯与安德鲁、Focused 的凯文。他还说，明年峰会的细节一公布，会在节目里告诉大家。
这一段没有内容，但定下了这一期的形态：三段演讲的节选，加串场。
02 海蒂：机制、数据与四个词（02:26–07:58）
海蒂用一次举手开场：谁的 AI 试点没走出演示、或者在刚上生产时卡住了。举手的人不少。她的判断很直接——这些工作流失败，多数不是因为模型不行，是因为让模型干得太多：让它保存数据、当系统记录、做决定、再自己检查。
她的顺序是先数据后机制。数据质量决定了工作流可靠性的天花板，而她强调的问题不是「数据好不好」，是「对眼下这个任务够不够好」，要看四件事：准不准、全不全、一致不一致、够不够新。过期的数据不会报错，它会安静地给出错误答案——这一条她单独拎出来，因为 agent 帮不上。
然后是整场的四个词：机制（真正执行某一步的东西：规则、经典机器学习、像 Jev 那样的决策模型，或者 LLM）、护栏（对每条输出的运行时控制）、评测（可重复的测试）、可观测（能不能回放、能不能在事故前抓到漂移）。机制是按任务选的，不是按项目选的。
她还提醒别只看平均值：平均值会藏住最差的那批，而你要修的就是那批。
每个任务只有三个决定：谁来做这一步；工作怎么协调（写死流程、在决策点分叉、或者让 agent 在边界内自己走）；什么允许被执行。最后一个决定她给了四个刻度：后果重又说不准的让人批；量大而信心参差的按阈值放行、其余升级；时间敏感的先做再给撤销窗口；只有撤销便宜的才彻底自动化。
03 海蒂：护栏不是提示词（07:58–10:06）
这一节是整场最硬的一句：写在提示词里的规则，不是被确定性执行的。护栏是机器——一道闸、一次检查、一个人、代码里的一条限制。
她顺手拆了两个幻觉。一个是「编程不需要护栏」：传统编程一直需要变更控制这类东西。另一个是「有人审就行」：要审的东西上千条时，人只会盖章，橡皮图章式的复核不算护栏。所以护栏旁边还要有「恢复」：能回滚就回滚，不能回滚就要求事前批准。评测则是一切通往更多自主权的闸门——阀门不工作，就不该推到生产。
04 海蒂：一条橡胶软管产线（10:06–11:45）
第一个案例来自一篇同行评议论文，不是厂商的营销材料。相机加 YOLO 找缺陷（这一段没有 LLM）；命中之后从知识图谱取证据、检索作业指导书和维修记录；LLM 只拿到这些证据，写一份候选解释和纠正动作。
关键在多加的那一层：他们用基于规则的检查、也就是传统程序，去核对这份草稿有没有超出刚取的证据；证据不足就升级给人。操作员对任何一条都能接受、覆盖、写评论，不只是被升级的那些。这条产线被观测了五十二周。
她的结论：他们没让模型看管子自己想明白，LLM 负责解释，检查和护栏在别处。
05 海蒂：先正达的现场选种（11:45–14:24）
第二个案例是农业。农民会给自己的地选错种子，先正达的 Cropwise AI 让销售或种植者把工具带到地里，按当地条件做现场选种。用户先用平实的语言提问，LLM 来解释这句话；但在任何事之前，用户由 AWS 的身份服务授权，那是应用代码、不在 LLM 里；然后 Bedrock agent 把请求路由到知识库、API、Python 动作和数据 agent，去取天气、土壤、产品和农艺数据。要预测时，由先正达自己的种子与农艺模型出结果。LLM 的第二份工作是把结果讲成人话，决定由销售或农户做。
这套架构给了她第三课：换模型不难，换知识库也不难。评测用的是 100 组真实销售代表的问答，人工评审打分，再加一个模型当裁判。设计目标是——让模型和知识库成为整个系统里最容易被替换的部分。
公开资料里，先正达这套 Cropwise AI 确实是用 Amazon Bedrock Agents 搭的，AWS 自己的博客写过它的架构 7。
06 海蒂：斯坦福的外科共管（14:24–18:18）
第三个案例在医院。斯坦福医疗做了一个「外科共管导航」，每天筛第二天的择期手术，判断哪些病人需要外科共管（术前、术中、术后由内科与外科共同承担照护）。上线之前，日常的人工分诊漏掉了一半符合条件的病人。
系统从电子病历里取术前麻醉记录和用药清单，标准是机构自己拥有的一套评分规则，用他们自己的文献和教授经验写成，固定在提示词里。模型的唯一工作就是套用这套规则，回答是、也许、否——只有三种答案，没有可以幻觉的空间。每个病例都会出现在 EHR 列表里，标记或不标记，医生可以确认、拒绝或覆盖。
上线前他们拿五个模型跟共识病历复核做基准比较，选了表现相当、成本更低的那个。假阴性分析里，LLM 的错误很少，反而暴露出流程里一堆别的错误。这套系统是被设计成过度标记的：医生对「否」的判断 97% 同意，而被标记的病人里约四成被医生否掉，理由是没那么复杂。
她的收尾是四个问题，每个都能对上前面的案例：每一步是不是用了最简单能用的办法；护栏在不在（软管产线在证据薄弱时升级）；评测做没做（斯坦福比了五个模型，先正达测了 100 个真实问题）；有没有持续观测（盯了五十二周）。四问全过，系统大概在演示之后还能继续跑。
07 广告：Framer（18:18–19:23）
一段 Framer 的广告。为了完整保留节目内容，译文照录，正文不摘。
08 凯文：采用率是唯一指标（19:23–20:22）
丹尼尔介绍凯文：Focused 的高级软件工程师，自学出身，主要用 LangChain 那一套造定制 agent。这一段里还有一句背景：Focused 也是这届峰会的赞助方之一。
凯文开场讲客户的 CEO 那句话：采用率是关键，不管我们造什么，采用率必须是第一件发生的事。而他们要给一群蓝领造应用，CEO 自己先说这群人出了名地不接纳新技术：不信、不喜欢、看不见、不想要。
09 凯文：为谁造，怎么一起造（20:22–26:55）
他先拆「不好用」这句话：慢、会崩、不满足需要；或者工具做了它该做的事，但那不是他们需要的事。再拆「不帮他们」：技术从管理层上面好几层推下来，解决的是别人的问题，对一线只是多一道录入；他们会拖到下班前一次性补录，那时已经忘了一半。最后是「笨重」：要跑三四个系统抠信息再回来填，这事不会流行。
这些症状的共同前提是「替别人造」。隔着产品负责人转述，信息会被简化、被删、被漏；「替某人造」还在发一个信号：我比你更懂你的活该怎么干；它还会把「理论上」的标准流程固化下来。
「一起造」从一个目标开始，不是从功能开始。他举了自己的例子：现场技师修的设备从绞肉机到 ATM，这份广度他没有，agent 一定会给出答案，对不对他不知道，所以必须靠他们纠。
10 凯文：先故意做错（26:55–30:44）
这一段是全期最具体的。他说没有评测的 agent 只是概念验证——不管部署在多好的基础设施上。
他的做法是先合成一版数据、做一个能上手的东西，然后请对方挑错。理由是：从人那里拿信息很难，但给人看一个错的东西，他们会立刻指出错在哪。他引了导师那句话——说问题，别说方案——因为太在意自己的方案，别人提更好的想法时你会觉得受伤。
反馈要做得容易给：要他们标注数据就给一张 Google 表格；有时间就 vibe code 一个小应用，做成游戏。
11 凯文：数据飞轮与手艺人（30:44–34:44）
数据飞轮的四个部件：离线数据集（开发与度量都对着它）、上线后的线上评估器（代码型评审或模型裁判，看抽样的轨迹）、标注队列（可疑的进队列复盘）、回到离线数据集。数据集跟着用例一起长。
然后是宜家效应：帮着一建造出来的人，会成为你的拥趸——「这件工具我帮着建的」。
最后落到蓝领的身份：他们是手艺人，要看到你尊重他们的手艺，也要看到你自己有手艺。评测集不需要百万条，需要覆盖；细节里有上千种例外，得下去看。发布不是终点，循环得一直转。
12 广告：Prediction Guard（34:44–36:49）
一段 Prediction Guard 的广告，讲企业里 agent 身份与权限的问题：员工入职后怎么限定模型、MCP 服务器与工具的访问范围；agent 被创建与分享时权限怎么委托；员工离职后 agent 身份怎么处置。译文照录。
13 克里斯与安德鲁：六个约束，四种模式（36:49–53:06）
这是整期最长的一段，十六分钟。开场是那个大家都看过的画面：手离开键盘，agent 写代码、审代码、审 agent、测代码、发代码。克里斯说，总有人会拿这个来问你：我们什么时候关灯。
他们的立场来自三份研究：AI 不会修好你的团队，它放大已经在那里的东西。他们给受监管行业造软件——医疗、制药、航空航天——错一次的代价很高。模式不对时，团队会说出三种话：「我们在发 AI 垃圾，没人知道对的应该长什么样」「我们该多用 AI——多是多少我也不知道」「乐趣全没了，我整天就在审代码」。
三个案例对应三种模式。输电运营商的老系统，工程师反向工程了前后的模型，两天跑通原型；要上生产时 SEP 进场，一周没交付——因为 token 预算、领域知识在脑子里、可验证性要扩到几百万个输入参数这三件事同时压上来。建筑构件设计的软件失败成本太高，团队从个人模式走到共享模式就停住：领域元素、架构、规则、计划放进同一个知识体，人和 agent 读同一份。Forum 信用社要把 C# 的银行应用重写成 iOS/Android 原生，token 不设上限，agent 开始有自己的角色、向编排者汇报，团队给意图和上下文——结果是六倍的工作量缩减。
六个约束是：token 预算、组织准备、目标定义、领域知识、可验证性、代码监督。有些旋钮团队改不了，但把它指出来，本身就会推动组织去谈。
安德鲁被问「所以目标还是黑灯工厂吧」，他答：不一定，目标是适配。克里斯接着用精益讲：丰田从没要求所有产线都装安灯绳，「把质量做进去」这条原则处处成立，做法不是。最后是五条做法：共享基础设施、刻意迭代、先可验证再提速、系统性地追瓶颈、去掉苦工。
14 收尾（53:06–54:14）
丹尼尔说这场该列入开发团队负责人的必听清单，然后进片尾：网站、社交账号、Prediction Guard 的运营支持、Break Master Cylinder 的节拍。
口径与核对
这一期是三场演讲的节选，不是访谈。讲者讲的是他们自己的项目，数字与结论没有第三方复核，所以卡片上带了口径戳：官方文件、公开研究、节目中的说法、未定论。
- 能核到的：三位的姓名、头衔、机构与题目，来自峰会讲者页；先正达用 Amazon Bedrock Agents 的架构，AWS 官方博客写过；斯坦福的外科共管工具与橡胶软管产线研究，2026 年都有正式论文。
- 只有讲者口径的：那条产线被观测了 52 周、斯坦福比过 5 个模型与 97%/四成这两个比例、先正达的 100 组问答、Forum 项目的六倍工作量缩减、输电运营商原型的「两天」与「一周没交付」。这些数字没有第二来源，按原话记录。
- 一处听写疑点：海蒂提到「像 Jev 那样的决策模型」时，逐字稿写作 JEV；按上下文这是决策模型这一类的例子，译文保留了这个说法，没有替它改名。
- 章节是我重切的：官方 RSS 与 Transistor 给了 14 段章节时间点，但章节标题是自动生成的，与讲者实际讲的内容对不上（例如第 2 章标成「系统在持续演化」，实际是海蒂讲机制与数据）。所以图片上的「本期走向」与正文的分段都按实际内容重切，也是 14 段，时间点取自逐字稿。
- 广告段落按节目原样译出，不删不摘。
逐句全文翻译
以下是整集的逐句中文译文，按上台顺序排列，保留说话人标签（旁白、丹尼尔、海蒂、凯文、克里斯、安德鲁、广告），不做压缩、摘要或删减。三段演讲之间的串场与两段广告按原位置保留。
开场与第一场：海蒂·波特（00:00–18:18）
旁白：欢迎收听 Practical AI，我们在这里拆解人工智能在真实世界里的应用，以及它正在怎样改变我们生活、工作和创作的方式。我们的目标，是让 AI 技术变得实用、高效、人人可用。不管你是开发者、业务负责人，还是只是对技术背后的热闹感到好奇，你来对地方了。记得在 LinkedIn、X 或 Blue Sky 上关注我们，第一时间看到新一期、幕后内容和 AI 观察。更多内容在 practicalai.fm。
旁白：接下来，进入节目。
丹尼尔：这次我很荣幸担任今年第二届中西部 AI 峰会的司仪。看到大家在场里用非常实用的方式讨论 AI agent、决策模型、AI 安全这些题目，真的很棒。我和会议组织方商量好，可以把几位讲者在峰会上的片段分享给大家。所以今天是特别的一期：你会听到中西部 AI 峰会上几位讲者的节选。我们会有海蒂·波特，她是梅耶集团 AI 的负责人；然后是 SEP 的克里斯·欣克尔和安德鲁·邓兰普；最后是 Focused 的高级软件工程师凯文·索罗里奥。希望你们喜欢。
丹尼尔：我自己非常喜欢。也很希望明年能在中西部 AI 峰会上见到你——等会议方公布明年的细节，我们会在节目里告诉大家。那么，请欣赏这几段来自中西部 AI 峰会的演讲。第一位是海蒂·波特。
丹尼尔：她在网络、数据分析、机器学习、AI，以及大公司里本地与云上的部署，有几十年的经验。她的公司梅耶集团 AI 提供 AI 工具的培训、策略与咨询，也包括判断 AI 该放在你的哪些任务和工作流里。她今天要讲的，就是怎么把 AI 增强的工作流做得能撑住。欢迎海蒂·波特。
海蒂：好，谢谢。手里有翻页器。早上好，我是海蒂·波特。先举一下手：谁的 AI 试点没走出演示阶段，或者在刚上生产的时候就卡住了？好，人数不少。恭喜剩下那些第一次就成的。很多这类工作流之所以失败——原因不是模型有问题，是因为让 LLM 干的事太多了。唐和杰夫刚才讲得很好，讲了什么时候该对 AI 说「不」、什么时候说「是」。所以有时候，人们会要求它保存数据、让它当系统记录——它不是数据库；让它做决定，再让它检查自己的工作。我今天希望大家带走的问题是：看工作流里的这个任务，判断它该由哪种机制来做。然后，怎么判断答案是对的、怎么在它错的时候抓住它。也就是评测、护栏这些。但在看工作流之前，我们得先说一句数据。进到你工作流里的数据，我想大家多少都知道，但必须谈。它决定了你的任务和工作流能有多可靠。问题不是你的数据好不好——一般意义上的好——问题是：对你的这个任务来说，它够不够好。所以我们查四件事：准不准、全不全、一致不一致。就像杰夫说的，也许你的 agent 能帮上一点。但如果数据过期了，它会报错，然后安安静静地给你错误答案。这个我不知道 agent 能不能帮上。所以当流程里有一个 LLM，你需要在运行时把它扎进你的数据里，也就是我们说的系统记录。你把 LLM 接地到你的数据里，你去取事实，你用查询去查数据库、或者某种知识图谱，你让证据来驱动答案，并且把引用的来源带上，让人可以自己核对。接地这件事，只能和它背后的数据一样好。所以先把数据这一层修好，因为下游的一切都继承它的质量。
海蒂：那么接下来，看一个能跑的系统需要什么——在好的、干净的、整合好的数据背后。有四个词，我们后面这一场都用得上。机制：我们把真正执行某一步的东西叫机制，它可能是规则、是经典机器学习、是像 Jev 那样的决策模型，也可能是一个 LLM。而 LLM 有很大的跨度：直接问它、让它生成、让它调用工具、放进像杰夫讲的 agent 架构里，或者配上人工复核。这一步是按任务选的，不是按项目选的。然后是围着它的三道保险：护栏，是对每一条输出的运行时控制，它能抓问题、能升级给人、能在出问题的时候约束答案，也能在任何东西漏过去之后做恢复；评测，是可重复的测试，评测非常重要，却常常没被谈够，因为它决定你拿到的是不是对的答案、是不是一个好的结果。这里有一点我要强调：看一个工作流，别只看平均值，平均值会藏住坏结果，你得知道自己最差能差到什么程度，才谈得上修；可观测，今天没太多时间展开，但杰夫讲了一些，就是能不能恢复、能不能回放、能不能在事故之前抓到漂移。把每一步做对，然后给每一步配上保险。
海蒂：今天我会展示几个工作流的例子，跨制造业、农业和医疗，它们真的成功了，以及它们学到的经验。但先看怎么造。对每一个任务来说，这张幻灯片上东西很多，我知道，但其实只有三个决定。第一个，谁来做这一步，我们刚讲过，而 LLM 这种机制内部的跨度很大。第二个，工作怎么协调：如果你知道步骤，你可能就想用编程写死一个固定流程；或者在某个决策点上，用一个 LLM 或决策模型来分叉；也可以用 agent 架构，让 agent 去跑，但用成本、时间这些条件把它框住。我们后面会看到一个例子。第三个，从这里就开始进护栏了：什么允许被执行。你可以把它想成一个旋钮。后果重、又说不准的动作，让人来批。量大而信心参差的，让系统在置信度阈值以上自己执行，其余升级；或者反过来。时间敏感的工作，先做，然后给人一个否决或者撤销的窗口。只有撤销起来便宜的动作，才彻底自动化，比如用 agent 架构的时候。不管你先选了哪一种，去测它。把它当成一个假设。
海蒂：每一个任务的产出上，你都要想护栏。我们刚说过这很重要。要拿到你想要的结果，每一种机制周围都要有护栏。它们提高拿到好结果的概率，但你不会拿到完美的结果，所以你要对着自己的基线去衡量质量。第一件要认清的事——前面也提过——写在提示词里的规则，不是被确定性执行的。护栏是真正的机械：一道闸、一次检查、一个人、代码里的一条限制。这张幻灯片上你能看到，护栏的强度是跟着机制走的。有两点我想点出来。一是，你可能觉得，编程嘛，我们不需要护栏。需要的——传统编程一直都需要护栏，比如别把 bug 推进代码里，比如要有变更控制。另一点是，我们常想，让一个人来审 LLM 就好了。杰夫讲了这一点：当有上千条东西要审时，人会累，会橡皮图章式地一路盖章，那不是好的护栏。所以这些地方你得特别小心，我们在这里列了一些可能的补救办法。还有一列我想特别点出来：恢复。因为总会有东西漏过去，恢复是你怎么把它围住、怎么回到安全状态——回滚、撤回输出、撤销写入。所以能做成可撤销的就做成可撤销的；做不成的，就在执行前要求批准，同时小心人的疲劳。
海蒂：然后，这一切之上还有评测。就像我说的，这一点常常谈得不够。评测告诉你它到底在不在工作，也是所有通往更多自主权的闸门：如果阀门不工作，你不会想把它推到生产，因为很快你就没有能用的系统了。我给你们看几个真实部署的例子，挺好玩的。这是一个已经发表的、同行评议过的研究，所以它不是哪家公司做的、不是营销材料，是一篇关于一条橡胶软管产线的同行评议论文。一台相机看着这条线，一个改造过的 YOLO 视觉模型找缺陷。如果你看看它们看的东西，你会体会到这件事有多难，尤其是在速度下。它检测出缺陷，这一段没有 LLM。然后，一个被检测到的缺陷触发诊断：系统从知识图谱里检索证据，检索相关的作业指导书和维修记录。LLM 接下来只拿到这些证据、这些来自系统记录的东西——不是整个知识库——然后它起草一份候选解释和纠正动作。但关键是，这里还有一层护栏：他们用基于规则的检查、传统编程，去检查这份草稿有没有留在它刚取到的证据范围内。也就是用程序去查 LLM。如果看起来薄、如果证据不足以支撑，就把它送给人。所以这里有两道不同的护栏。这个例子的另一点是：操作员可以对任何一条做接受、覆盖和评论，不只是被升级的那些。控制权在他们手上。那我们学到了什么？注意他们没做什么：他们没让 LLM 去看那根管子、自己想明白一切。LLM 负责解释，另外还有检查和护栏。结果不错，但不完美。所以，接地之后仍然需要被检查。可观测性上他们做的，是把这条线盯了五十二周，确认它一直在正常工作。
海蒂：那我们看一个农业的例子，这个我特别喜欢。其实我想加一句：我觉得这个用例可以套到很多不同的场景里，你可以想想自己的情况。这是一家叫先正达的种子公司，有一个很大的种子目录，而农民有时候会给自己的地选错种子。销售，或者种植者，会把这个叫 Cropwise AI 的方案带到现场，根据当地条件做现场选种。人用平实的语言提问，然后 LLM 来解释这句话——这是 LLM 的好用法。但在任何事之前，用户是由 AWS 里的身份服务授权的，那是应用代码，不在 LLM 里。然后 Bedrock agent 把请求路由到知识库、API、Python 动作、数据 agent，去取天气、土壤、产品和农艺数据。当这个问题需要预测时，由先正达已有的种子与农艺模型产出。LLM 不做农艺。明白吗？它的第二份工作，是把结果用平实的话讲出来，然后由销售代表或种植者做决定。所以这个 agent 是从系统记录里取东西、拿到它需要的子 agent、再把子 agent 派出去。等一下我们会看到一张图。
海蒂：如果看这张图，蓝色是 LLM 或 agent 工作的地方，灰色是规则和机器学习，黄色是护栏。在这个例子里，LLM 是界面、是路由、是解释器，不是农艺师。这张图没有杰夫那张知识系统的图漂亮，但你能看到这里有若干个知识库、很多文档被拉进来。我为什么想在这里放这样一张图？因为这其中有一条很大的经验。前面两条我们已经讲过了，第三条是：他们设计这个系统的方式，让它不只经得起换模型——你知道，换掉一个模型；你还可以换掉知识库，或者换掉某些数据源。这样做，意味着你之后要重新评估；你看这里的评测说明，他们用真实销售代表的 100 组问答，由人工评审打分，还用了 LLM 当裁判。所以他们确实把这些都做了，确认工作流是成功的。但有一点很值得知道：这些不同的部件，你可以相当容易地换掉。所以这里的启示是：设计的时候，让模型和知识库成为整个系统里最容易被替换的部分。
海蒂：下一个我也很喜欢，来自医疗。斯坦福医疗做了一件工具，叫「外科共管导航」，它筛第二天的择期手术，看哪些病人需要外科共管。外科共管我得去查一下：就是术前、术中、术后，由临床医生共同承担病人照护职责的一种做法。上线之前，日常的人工分诊漏掉了一半符合条件的病人。所以，你知道，如果我要做手术、而我又符合共管条件，我想在座每一位都会希望有这层照看。所以这个系统对他们、尤其是对病人，是件大事。新系统从电子病历里取出术前的麻醉记录和用药清单，它用的标准是一套由机构自己拥有的评分规则——用他们自己的文献、自己教授的经验写的，固定在提示词里。我们讲过，提示词是可读的，不是强制。但在这个例子里，LLM 唯一的工作就是套用这套规则，回答「是、也许、否」。这样它没有任何可以幻觉的东西。是、也许、否，就这三种答案。同样，像那条橡胶软管一样，每一个病例都会出现在 EHR 的列表里，标记或不标记，医生可以看所有的病例，确认、拒绝或覆盖。决定权留在临床医生这里。
海蒂：上线之前，他们还做了一件事：拿五个不同的 LLM 跟共识病历复核做基准比较，最后选了一个表现相当、但成本更低的。模型再一次是可替换的部分，不是系统的中心。这个案例里我觉得最有意思的一点，是在假阴性病例的分析里——这是一个小样本——LLM 的错误很少。实际发生的是，他们在自己的流程里发现了许多别的错误，然后能去修其中一些错误。当然，也看了 LLM 的错误。所以斯坦福这条给了三条经验，全都关于「谁拥有这套规程」：机构拥有标准；他们比较了候选模型；第三——这一条我要特别点出来——他们去查了它为什么会不同意。他们这个系统典型的做法是过度标记，也就是宁可多报假阳性。当他们去看那些「否」的时候，医生 97% 是同意它的。所以它是被设计成过度标记的，而被标记的病人里，医生大约否掉了十个里的四个，理由基本是「没那么复杂」。
海蒂：这就是三个在跑的工作流，也是一个总览：把 LLM 用在正确的任务上，或者用在编排这一层。回到我们开头说的四个词——那四个部分——我们可以把它们对到刚才你看到的例子里。每一步是不是用了最简单能用的办法？先正达用的是农艺模型；护栏，那条软管产线在证据薄弱时升级，系统把答案扣住、升级给人。第三，评测，我们刚讲过斯坦福比了五个模型，先正达用 100 个真实问题测过。第四，可观测，那条橡胶软管产线，他们观测了五十二周。所以，如果这四个问题你都能答「是」，你拥有的系统很可能在演示之后还能继续跑下去。非常感谢。
丹尼尔：谢谢，太谢谢了，海蒂。太好了。我很喜欢你钻到每一个工作流里的那种方式，非常实用。
广告：不管你是早期创业公司还是财富五百强，有一个看起来像手工打磨的漂亮网站都很关键，而且网站、网站更新、落地页这些，要在几分钟里发出去、不是几天，才能跟上 SEO 和 AEO，让你的内容一直是新的。Framer 就是那个 AI 网站搭建工具，帮创作者、团队和企业比以往更快地发布生产级网站，同时把每个细节做对。提示、检查、编辑、发布，都在一个地方，节奏完全不同。想了解更多，找一位 Framer 的专家，或者今天就开始免费搭建：framer.com/practicalai，Framer Pro 年付方案打七折。就是 framer.com/practicalai。条款与限制适用。
丹尼尔：下一位讲者我很期待，凯文·索罗里奥。他是 Focused 的高级软件工程师，Focused 也是这里的赞助方之一。我认识凯文大概是两年前。他去年就在中西部 AI 峰会上。他们在 Focused 的团队很厉害，全是 AI 工程师，每天都在造 agent，跟各种类型的公司合作，而且真的把 agent 推到生产里、也真的做评估——就像我们今天上午听到的那样。凯文是自学出来的工程师，也是 AI 顾问，主要用 LangChain 那一套造定制 agent。今天他要分享的是：怎么和工人一起造 AI，而不是替他们造——这也是在一线赢得信任的一部分。请大家欢迎凯文。
第二场：凯文·索罗里奥（19:23–34:44）
凯文：我叫凯文·索罗里奥。我今天讲的，大部分来自我在 Focused 最近的一个客户。新项目刚开始，CEO 就跟我们说，采用率是关键。不管我们造什么，采用率必须是第一件发生的事。而我们要给一群蓝领工人造一个应用，他一开始就说，这群人出了名地不接纳新技术：他们不信、不喜欢、看不见、也不想要。所以要实现这个目标，我们想花几分钟说清楚：好，我们得让这群用户去用一个他们也许想用、也许不想用的工具。
凯文：那我们先挖一下，为什么过去有些工具会失败。意外的是，最先冒出来的几条里有一条是「它不好用」。当你跟人聊，他们开始用一个工具，而这个工具不满足他们的需要，他们就不喜欢它，就不用它。但「不好用」非常含糊。跟他们一起往里挖，你会挖出来：它慢、它会崩、它可能不满足他们的需要；它可能做了它该做的事，但那不代表它在做他们需要它做的事。所以有时候就是这里没接上。另一件可能发生的事，是这个工具其实没在帮他们。有时候技术是从管理层上面好几层推下来的，它在那儿是为了解决另一个问题，或者为了追踪某件事，跟他们每天干的活没有关系。要说有什么，它只是给他们增加了工作量：得进系统，把他们手上所有的信息更新进去。还有一种，是笨重。如果工具用起来笨重，他们不会用、也不想用。如果他们得进三四个不同的系统里把信息抠出来，再回到这个系统里填进去，再走一遍整个流程，那这个东西就是不会流行起来。所以这些都是「工具是替别人造的」时会出现的症状。
凯文：「不好用」通常意味着：我们对需求的研究不够，我们没有钻进用例，我们一开始就没搞清到底要造什么。「不是为他们造的」：如果它是为了别人的某个 KPI、OKR，或者别的什么指标，如果它其实不是为他们存在的，那它就是在挡路。他们因为必须用而用，但可能会拖到一天结束：「哦，我下班前把东西都录一下吧」——那意味着有一半重要的东西他们已经忘了。所以这些东西根本没进到你的系统里。最后，「笨重」很可能是因为设计它的人没在做这份工作。他们不明白，跑到四个不同的系统里、再进第五个，有多痛苦。所以，如果我们停止「替某人造」，真正开始「和他们一起造」……
凯文：「替某人造」最大的问题是，它永远隔着一个代理。多数时候，你有一个用户，比如一个产品负责人，他在解释这些结果。他在跟用户对话，但他在里面加了自己的理解：可能把事情过度简化了，可能删掉了东西，可能漏掉了很重要的用例，就那么一带而过。还有，回到刚才说的，当你替某人造的时候，你其实在发出一个信号：「我知道什么对你最好，这件事就该这么做。」如果你像我太太一样，我说「你去把这个做了」，她可不爱听；但如果我好好地问她，就没问题。所以就是这种情形：你走进来说，做这件事，而且你要这么做。你等于在说，我比你更懂你的工作该怎么干。这个信号很怪。而且它往往会把标准操作流程固化下来，而那些流程可能只是「理论上」的情形：理论上，我们所有的请求都落在这几个漂亮的格子里，永远不会出格——而这很少发生。
凯文：跟这个相对的是「和某人一起造」。当你开始和某人一起造，你会从一个目标开始。不是直接说你打算做什么，而是先回到：你真正想解决的问题是什么。让他们在房间里，让信息穿过两边的围墙流动起来，你开始和对方建立尊重与信任。因为我知道他们很懂自己的活。在这个具体的项目里，我们面对的是现场技师，他们修的设备从绞肉机到 ATM——真的是同一个人，可能今天被派去修你的绞肉机，明天被派去修你的 ATM。所以他们的知识面非常宽。那是我没有的东西。当我造一个系统、用一个 agent 去生成东西时，它一定会生成，它一定会给我一个答案。这个答案对不对？我完全不知道。所以我真的要靠他们来纠正我错的地方。这就是那些「实践中」的东西进来的地方。
凯文：跟人一起造，在 Web 应用、还没有 AI 的时代，也就是大概三年前，主要的形式是看纸上的原型。你和他们待在一个房间里，可能会在白板上画、用粗马克笔画，把东西画出来。我们真正想定义的是：什么信息需要在什么时候、以什么精度呈现出来？我们给他们的是对的信息吗？我们有没有给他们逃生的路？有没有办法让他们钻到那些现在可能没有的细节里？当你开始做 agent，就不太是关于版式了，因为我们很多人看到的，都是一堆聊天框，没什么版式可谈。你要和一个 agent 一起工作。那你怎么确认它在做对的事？对 agent 来说，你要的是正确的行为：在正确的时间调用正确的工具，用对的护栏，守住边界。所以它不太关乎设计，不太关乎版式和这类东西；真正要钻进去的是：它在做我想让它做的事吗？而评测恰好为这件事提供了最好的场地。
凯文：这话可能有点重，但一个没有评测的 agent，只是一个概念验证。不管它部署在多好的基础设施上，都一样。如果你没有评测，你就无法确认这个 agent 在按预期行事。所以在这个阶段，我会一直说，那更像一个概念验证。有了评测，好的一点是：你可以一遍一遍、一遍一遍地测你的 agent。我开这类项目的时候，通常会先合成一个数据集——把我知道的东西做成一个数据集，先让东西接起来、交到他们手上。我希望有人能看着它、摸它、告诉我它行不行，然后给我反馈。跟蓝领工人合作有意思的一点是，他们身上没那么多痕迹。如果你跟白领合作，你可能大部分工作不真正跟他们互动也能过——虽然我强烈建议让他们参与。但蓝领身上没有那种痕迹：没有邮件列表，没有一堆 trace，你平时跟白领合作时能拿到的东西，这里都没有。所以，真正开始为人造，第一件事是让所有人进这个房间，开始谈。
凯文：回到我刚才说的，那个合成的数据集、那个先让他们能上手的东西——我希望自己在这上面是错的。我做顾问的一个发现是：从人那里拿信息有时候非常难。但如果你给他们看一个错的东西，他们会非常快地告诉你哪里不对。所以，如果你一开始就知道「这不会对，第一版没有东西是对的」，那你就先带着一个想法开始：这是我提议我们要做的东西。让它错，没关系。拿到反馈，让反馈流动起来。我早期的一位导师常跟我说：说问题，别说方案。那是因为问题才是重要的。如果你太执着于一个方案，尤其是你自己想出来的那个，当别人提出一个可能更好、更高效的新想法时，你可能会有点受伤：为什么选的不是我的方案。所以在这个过程里，很重要的是意识到：你在那儿是为了解决问题，不是推广你想出来的东西。所以当你把那个想法摆出来，就让它错，接下反馈，然后开始迭代。
凯文：我觉得信任就是从这里开始建立的：当他们看到它一开始有多错，然后通过一些和他们的互动，他们开始给你反馈，你可以让它变成你期待它在做的任务，或者开始接近那个样子。他们的反应开始更说得通了。这样，你就会想定期从他们那里拿反馈。这种情况下，你要让给反馈这件事尽可能容易。比如你有一个想让他们标注的数据集，就给他们一张 Google 表格，他们可以自己找时间标好；如果你有时间，就 vibe code 一个小应用，做得有意思一点、游戏化一下，总之给他们一个把反馈给你的通道。然后你就可以把它用在评测里。这一段你会和他们大量迭代，之后你可以把圈子扩大一点。一开始你可能从几位代表开始，他们能展示自己的知识、帮你走在对的路上，但他们不一定见过每一种情况。所以你要把这个圈子稍微放大一点。这里就是你要开始建数据飞轮的地方。
凯文：如果你以前没用过数据飞轮：你建一个离线数据集，用它来做你的开发实践，用它来对着开发 agent，对着这个数据集去衡量。然后当你部署之后，你会有线上评估器，持续看抽样的一批 trace，给它们打分。可以是代码型评估器，非常确定；也可以是一个模型当裁判，帮你找出、标出以前你的 agent 没覆盖到的情况。这些会被加进一个标注队列。在队列里，你可以复盘、发现这个具体案例上出了什么问题，然后把它加回你的离线数据集。于是你就有了一个持续流动、跟着用例一起演化的数据集。飞轮建立起来之后，你邀请更多人上平台，你开始看他们怎么用，靠这个飞轮捕捉更多用例、继续建。
凯文：等你准备好了、对产品有信心了，就可以发布。最重要的一点是：让这个循环一直转。你总是会迭代。你会发现最初探索时没预料到的情况，会发现首次发布、头几轮 beta 用户、扩大圈子之后还没预料到的情况。所以把这件事转起来很重要。而参与其中的人——如果你听过「宜家效应」——你会对自己参与搭建的东西赋予很高的价值，尤其是在它还成得不错的时候。客厅里那件你自己装的宜家家具，是你的杰作，你确实很看重它，因为你亲手弄脏了手、你搭的、你是它的一部分。这就是可能发生的事。于是那些帮你一起建的人，会变成你的拥趸。他们会真的很满意：哎，看到没，这工具我帮着建的，我出过力，我让它更好了。
凯文：还有一个，专门针对蓝领工人：他们是手艺人。他们要看到你尊重他们，也要看到你自己有手艺。所以，钻进去。这些评测数据集通常非常精选，你不会有几百万条；你会有足够的、能代表这些用例的量，确保覆盖你期待 agent 做的所有事。你要钻进细节。蓝领工作里有很多细微差别，可能是上千种不同的情况冒出来，你真的需要钻进去，搞清这个案例和另一个案例差在哪。花时间钻进他们的流程、理解他们的流，然后能回来告诉他们：系统懂这个，因为你花了时间说「来，我听你说，把你会的讲给我」。还要展示它在变好。频繁地对齐，让你能说：我听见了，我做了这些改动，这是反馈，我们继续。这一切最后会在工程师和那个团队之间建立起很好的、很结实的信任。
凯文：我还挺幸运的，比如现在我们有一位以前的设计师——我说以前的设计师，他其实还在做设计，但现在是我们的首席 AI 策略师之一。他会进来，真的去听，帮着找这些细微差别，帮着带这个流程。看到当你真的和人一起工作、真的从他们所在的位置开始，你可以造出一个大家都为它骄傲、而且真的会用的系统，这真的很棒。我讲完了，而且我是午饭前最后一个，所以就不多占大家时间了。
丹尼尔：太好了，非常感谢凯文。我很喜欢……它有多聚焦在「为人而造」上。现在 agent 到处都是，拿到一个太容易了。
广告：不过，如果你是一家企业，正在考虑组织里有一支 agent 组成的数字劳动力，那么要考虑的事情就多了一整个层级，既有人类身份也有 agent 身份。比如，员工鲍勃被接入我的 AI 平台，我该怎么限定他对各个模型、MCP 服务器、以及那些服务器里的工具的访问范围？然后如果他造了一个 agent，他能把自己那份权限委托给它吗？如果他把这个 agent 分享给权限更高的爱丽丝呢？她能不能把这个 agent 的委托范围扩大？还有，如果鲍勃离开公司，这个 agent 身份还活着吗？这些难题，如果你有一个强大的、主权式、自托管的控制层就能解决，比如 Prediction Guard。我为我带的团队在 Prediction Guard 造出来的东西很自豪，它已经在不少组织的生产里部署，帮你有信心地管理你的 agent 舰队：知道它们能访问什么、它们是怎么跑起来的、它们怎么和人类身份交互、以及你是怎么通过控制机制介入它们的行为和运行的。欢迎看看我们在做什么：predictionguard.com/practicalai，跟我和团队约一次演示，看看怎么在扩大你的数字劳动力的同时不失去控制。就是 predictionguard.com/practicalai。
丹尼尔：接下来是来自 SEP 的两位，克里斯和安德鲁。如果你不熟悉 SEP，他们一直在给航空航天、医疗健康、金融等行业的客户做项目。欢迎 SEP 的克里斯和安德鲁。
第三场：克里斯·欣克尔与安德鲁·邓兰普（36:49–54:14）
克里斯：我点一下这里。好，欢迎。我估计你们很多人到现在都看过那些演示、那些视频：有人在操作他们所谓的「黑灯工厂」，手离开键盘，agent 写代码、agent 审代码、agent 审 agent、agent 测代码、agent 发代码。有些确实挺厉害，在某些情况下也说得通。但我猜，你组织里某个地方，有人看过那个演示，然后来问你：我们什么时候开始那样工作？我们什么时候关灯、开黑灯工厂？这就是我们今天要讲的。我知道这张图看起来像工厂里灯还亮着。不是的，不是。那是里面那些疯狂机器人发出的光。
安德鲁：里面没有人。对。
克里斯：我叫克里斯·欣克尔，是 SEP 的创新总监，这位是安德鲁·邓兰普，我们的一位资深 AI 工程师。今天，我们真的很想留给你两样东西。一个是一套理解框架，一个心智模型，帮你理解你的团队该怎么和 AI 一起工作。前面已经有人讲过怎么把 AI 用到产品里；我们稍微讲一讲，怎么让你的团队更好地用 AI 来写软件。我们想给你一套理解框架。第二个，我们想给你一组原则，帮你起步。所以如果你走进一个团队，那里说「我们想多用 AI，或者我们想做点不一样的」，你怎么开始？往哪走？我们会给你一组原则，希望能帮上忙。
克里斯：如果你留意过，关于 AI 有很多研究。这里是三份比较近的，其中 2025 年的 DORA 报告是最早的一份。有很多关于人们怎么用 AI、怎么利用 AI 的研究。我觉得有意思的是，这三份呈现出同一种模式，或者说结论是一样的：它们基本上都在说，AI 不会修好你的团队。它放大已经在那里的东西。这对我们很重要。当我们开始用 AI 赋能团队时，这是我们必须问的问题。你看，我们给一些「错了要出事」的公司造软件。看看周围——这是受监管的领域：我们做医疗、制药、航空航天。所以我们很认真地想过，用 AI 赋能一个团队到底是什么样子，这场演讲的题目就是从这儿来的。我们不相信每个团队都需要一个黑灯工厂。我们也不认为你必须走到那一步，才能从 AI 身上拿到显著的生产力提升。事实上，我会说，如果你在错误的模式下硬要往那儿走，就算最好的团队也会挣扎，会觉得很别扭。那挣扎是什么样？模式不对是什么样？你可能会听到这样的话：「我们在发 AI 垃圾，没人知道对的应该长什么样。」或者：「我们应该多用 AI。」——多是多少我不知道，但我们该多做一点。或者：「乐趣全没了，我一整天都在审代码。」如果你上周听到过其中一句，或者开会时听到类似的话，那你就来对会场了。当你做事的方式不适合你的处境时，更多的 AI 解决不了这件事。更多的 AI 修不好 AI 的适配问题。安德鲁接下来会走一遍我们三个客户的三个例子，三个不同的团队，都在用稍微不同的方式使用 AI、或以不同方式被 AI 赋能，我们会讲一点为什么会这样。
安德鲁：我觉得这三家都走在它们该在的位置上。谢谢克里斯。我们讲一个客户，他们是一家输电运营商。他们有一套仿真系统，仿真系统里有一些模型，把一种形式转换成另一种形式。这是一套遗留系统，业务用了很久，能把活干完，但他们想改进。于是一位聪明的工程师某天说：我有这些输入模型、这些输出模型，还有一大堆 agent，所以我可以把它们反向工程，把中间那个过程推出来。说得通。两天之后，你猜怎么着，他有了一个能跑的原型。于是他们想把这个原型推到正式环境，得上生产。这时候他们打电话给我们。我们派一个团队进去，他们开始了。一周过去，我们一行软件都没交付。发生了什么？发生的是，有新的力在起作用，团队面对一些新的约束。
克里斯：对。你是说，约束影响了团队能不能像我们希望的那样快？
安德鲁：正是。我们发现，所有团队在找准作用在自己身上的力时，都会看六个约束。我们有 token 预算，这个非常常见。也许一个组织全力押注 AI，但他们对「一天花 10 美元 token」有多舒服？100？1000？10000？这会改变团队的对话。组织准备：你有没有赞助人？有没有人愿意为这件事背书？目标定义：我们知不知道自己要去哪？我们是在试一个新东西吗？我们在做实验吗？领域知识：这个领域有多少是写在纸上的，有多少只装在人的脑子里？这会很影响 agent 能发挥多大的作用，能自动化到什么程度。可验证性：你能不能自动化验证？如果已经写到代码那一层了，agent 知不知道？你需要领域专家吗？还有代码监督：这对受监管行业是大事。如果代码必须有人看，那就会改变你和 agent 互动的方式。
安德鲁：如果我们回到那个两天的原型，发生了什么？在组织层面，他们有 token 预算约束。当我们变成一个团队时，他们的预算只允许开发人员干几天就没 token 了。在产品层面，太多领域知识在人的脑子里，所以 agent 到不了正确答案，因为你必须去问一个人。然后，还是产品层面，他们发现原型可以由一个人验证，但当我们把它扩到生产时，输入参数有几百万个，而我们没有好的办法把验证扩展到这个量级。
安德鲁：所以这些最终变成团队可以调的旋钮和刻度盘。有些刻度是固定的——你对 token 预算可能没有发言权——但把这个约束指出来，会带出一些对话，就像我们团队发生的那样：把「token 预算是个问题」这件事指出来，让组织知道这是他们需要参与权衡的。对领域知识来说，它会改变谁参与到项目里来：好，现在我们需要领域专家了，因为我们没有足够的信息达到我们想要的自动化程度。所以把这些约束指出来，是下一步的第一步，下一步就是团队在哪种模式下运行。
安德鲁：我们常见到四种模式。可能更多、可能更少，但这是一个很好的划分，几种非常不同的运行方式，它们是按 agent 自主程度从左往右铺开的。最左边，是个人模式，人在环里，很多时候他们就干自己的活。往右走，你会落到黑灯工厂：人走了，灯关了，机器人管着这个地方，产品从另一头出来，完全自主。我们那个两天的原型，他们是在「个人 agent 编程」模式下工作。因为他们只是要把原型做出来，不需要太担心规模化：他们能验证一个输出，然后说，好，流程跑通了。当我们团队上去之后，那种模式就崩了。那是不合的模式，那里出现了摩擦。
安德鲁：所以我们看一个不同模式的不同例子。我现在的团队做的软件，是给一家制造客户设计建筑构件的。建筑构件——这把扫帚其实是个很好的道具。你看周围，我们有混凝土块、有钢梁；抬头看，有托梁、有暖通设备，这些都是建筑构件。所以失败成本很高。对吧，我们不希望楼倒下来。那你怎么把 agent 织进去？因为如果我跟你说「这楼能站得住，因为我们的 agent 验证过了」，我估计你不会太高兴。
安德鲁：所以我们从个人模式开始，想走到共享模式。要做到这一点，我们必须建一堆共享的信息。那是什么样子？我们有领域元素、架构，可能有工作流、实现规则、代码、计划，但它全都在一个知识体里，所有人都有访问权。日常开发人员可能还是自己干活，可能会和 agent 结对，但现在我们知道我们在做什么了。我们都用同一套领域规则。这么做的意义是，我们现在给 agent 多一点自主，而这个组织的形状取决于我们项目允许的约束。我们本来可以走得更远，但我们不想，因为可验证性对我们真的很重要。对吧，房子不能倒，这是目标。所以再往前走我们不舒服。这是我们自己的选择，这对我们是好的适配。
安德鲁：好，如果我们想走得更远呢？我们有个团队做到了。这个团队在给 Forum 做一款手机银行应用——如果你不熟悉，Forum 是本地的一家信用社。他们有一款银行应用，能用，是 C# 写的，他们说：我们想上 iOS 和 Android 原生。好，很好。那 token 呢？哦，我们不在乎 token，想花多少花多少，我们看看能做到什么。好，你把需求都摆好了，就是换一个代码库，没有成本，组织背书。于是我们造出了屏幕上这样一套东西。你能看到，我们丢掉了「个体」这一层：我们在谈一个团队、一条 agent 的工作流。agent 开始承担自己的角色，它们在和一个编排者对话，团队提供意图、也许提供一些上下文，它们盯着仓库，但个体性已经没有了。我们在这里看到的，是更高程度的自主，而它体现为这个项目的工作量减少了六倍。所以你大概能看到，我们是怎么在台阶上往上走的。
克里斯：对。所以目标是，你从个人模式走到了共享模式。也就是说，目标是走到黑灯工厂，这才是我们要做的事，对吧？
安德鲁：也许，也许不一定。因为这里的目标是适配。对吧，我们就是这么开始的。约束导向模式，模式就是你的适配。所以我们跟团队做的事，是让他们评估这六个约束。约束评估的结果不同，你能活动的区域就不一样。约束更多的区域，你会在更个人化的模式下工作：也许你在做原型，也许你有很多约束，也许你必须保证每一行代码都对，也许你根本连不上互联网——那大概就要做得更个人一点。当你的约束长起来，我们就能拿到更高程度的自主，像 Forum 那个团队那样。但关键在于识别这些约束，然后挑最适合你的模式。
克里斯：所以你可能会问：那对我、对我的团队来说是什么样？如果我理解了这些约束，我该考虑什么？这实际上怎么落地？我花了很多年带团队、带客户做精益和精益软件开发。结果发现，精益对这个问题有答案。首先，精益会说：没有唯一的蓝图。不存在对所有人都对的一个答案。这也就是为什么我们不是所有人都需要一个黑灯工厂。丰田从来没有让谁去挂一根安灯绳。你可能不知道那是什么：那是他们装在产线旁边的一根绳子，任何人看到问题显现出来，都可以拉这根绳，把线停下来，把问题修好，再继续。这跟丰田「把质量做进去」的原则有关：不要等到最后才检验，而是当场停下来、把问题修掉，让质量在过程中被做进去。有意思的是——你可能听过、也可能没听过安灯绳——丰田并没有在每一家工厂的每一条产线上都装它。它非常看约束：根据那个情况、那条线的约束，他们才会实施。而「把质量做进去」这条原则，在所有地方都适用。
克里斯：所以，把这一点想清楚：原则到处成立，做法不是。做法会根据约束变化，就像安德鲁说的。所以在二十分钟里，我没法告诉你你的做法应该长什么样，但我觉得我们能做的是，走一遍一组能帮你起步的原则。对，好，我们有五条原则。好消息是，它们很好学。难的部分是掌握它们，但我们先过一遍。
安德鲁：我们这就过一遍。我们从基础开始：共享基础设施。回到我的团队，我们从个人走到共享，我们开始把知识拉进代码库，让每个人都有访问权，这就是共享基础设施。下一条，刻意迭代。这一条我看到很多团队掉队。他们在做事，他们甚至可能有了共享基础设施，但他们不谈它。也许某一个人用这个模型的体验很糟，也许另一个人觉得评审里的安全审计就是噪音。除非你在每周排出一段时间专门谈这些，否则它不会改善。
安德鲁：下一条，把它做安全，也就是先可验证、再提速。这正是我们团队在那个原型例子里发生的事：我们慢了下来，因为规模变了、约束变了，我们需要先确认拿到的是对的答案，然后再快起来。等我们准备好快起来，接下来就是找系统性的瓶颈。评审会是一个卡点。如果评审是卡点，你就要让它不再是瓶颈。一旦你做到，它会挪到别的地方。你得一直追。还记得我们回到的那些研究吗？团队所有的属性都会被放大。所以瓶颈只会比你以前更疼，你会感受到那种痛。你必须一直追着它们，才能让团队快起来。最后，去掉苦工。把一遍遍重复发生的事写成脚本。把思考留给人类，把分析性的过程留给 LLM。这会省 token，会更快，也会让团队的日子更好过。五条原则，三个团队，同样的原则，不同的模式，不同的做法。明白了吗？就这些，谢谢。
丹尼尔：太棒了。我觉得，基本上，任何管开发团队的人，都应该把这场演讲列为必听。太棒了。而且，那些问题确实是我们所有人的问题——当我们推进团队、理解怎么一起工作的时候，再理解怎么一起工作。
旁白：好，本周的节目就到这里。如果你还没看过我们的网站，去 practicalai.fm，也记得在 LinkedIn、X 或 Blue Sky 上关注我们。你会看到我们发布关于最新 AI 进展的观察，很希望你来加入对话。感谢我们的合作伙伴 Prediction Guard 为节目提供运营支持，去看看 predictionguard.com。也感谢 Break Master Cylinder 的节拍，还有你的收听。今天就到这里，下周再见。
References
- 1Practical AI 官方单集页
practicalai.show
- 2官方完整逐字稿（带说话人标签）
share.transistor.fm
- 3海蒂·波特的讲者页
midwestaisummit.com
- 4凯文·索罗里奥的讲者页
midwestaisummit.com
- 5克里斯·欣克尔的讲者页
midwestaisummit.com
- 6安德鲁·邓兰普的讲者页
midwestaisummit.com
- 7AWS：先正达用 Bedrock Agents 做的生成式助手
aws.amazon.com
- 8JAMA Network Open：EHR 集成的 LLM 分诊工具
jamanetwork.com
- 9ScienceDirect：橡胶软管缺陷检测与根因解释框架
sciencedirect.com
Comments