这集讲什么
Legora 要做的不只是让 AI 帮律师回答问题，而是在无法查看客户机密数据的条件下，把检索、审阅、起草、协作与人工核查连接成可用的法律工作系统。
1-3要点
- 法律智能体的产品边界大于模型边界：检索、文件操作、引用、任务状态、权限和协作共同决定它能否进入真实法律流程。
- 保密约束会重塑评测方法：无法读取真实轨迹时，模拟项目、专家审查、有限分类信号与客户自愿提供的案例各有作用，也各有盲区。
- 模型升级既是红利也是回归风险：某个失败模式可能被新版本直接解决，但不同业务领域和任务也可能退步。
播出信息
- 日期：2026-11-02
- 时长：4041 秒（约 67 分 21 秒）
- 嘉宾：Jacob Lauritzen，Legora 首席技术官
- 音频：收听本集
- YouTube：观看视频
- Episode：节目页面
- 英文来源：youtube-captions
背景
Legora 从面向瑞典法律检索的聊天工具起步，逐渐扩展到尽职调查、合同审阅、法律起草和团队协作。本集的核心问题不是模型能否写出一段像律师写的文字，而是：当客户材料受严格保密约束，产品团队连真实运行轨迹都不能随意阅读时，怎样发现错误、评估改进，并让律师愿意把高风险工作交给系统辅助。
下文首次将面向法律工作的 AI agent 称为 AI 智能体（Agent）。节目同时讨论了法律工程师、驻场工程师、模型选择、检索架构，以及 AI 可能怎样改变律所的人才培养和收费方式。
总结分析
这集最有价值的视角，是把法律 AI 的难题从“选哪个最强模型”移回“怎样交付可信的工作”。Legora 起初只是能查询瑞典法律的聊天工具；如今，Jacob 描述的产品既要让 Agent 执行检索、审阅和起草，也要通过列表、项目、文件和协作入口组织人类律师的工作。模型进步确实带来了近乎白捡的收益：他举例说，一次新模型发布就把某项引用表现从约 70% 提升到约 99%。但这并没有消除产品工程，反而让团队更需要辨别不同业务、任务与模型版本之间的退步和改进。
法律领域尤其特殊：律所掌握的文件往往属于其客户，Legora 不能像许多互联网产品那样直接阅读用户轨迹、挑出失败案例再调试。它因此依赖模拟项目、专业人员评测、受约束的在线分类信号，以及客户主动提供的匿名化例子。这种限制也解释了为什么可追溯引用、权限治理和熟悉律所工作的人员不是外围配套，而是产品能力的一部分。
Jacob 对行业变化的判断相对克制。他不认同“初级律师立即消失”，却承认大量基础审阅会被自动化；他预计律师会把更多时间投向风险判断和客户关系，同时律所必须重新考虑按小时收费、培养新人以及沉淀机构知识的激励。尚未解决的张力贯穿全场：Agent 越灵活，成本、延迟和不确定性越难控制；客户越想定制，平台越需要稳定的底层组件；系统越能独立完成工作，人类就越需要明确该核查什么、对什么结果负责。
节目结构 / 议程
- 冷开场：能力跃升不等于法律工作全自动 — 00:00 🎧 · ▶️
- 从瑞典法律搜索到“做工作、组织工作” — 01:54 🎧 · ▶️
- 模型选择器：把复杂决策留给系统，还是交给律师 — 05:23 🎧 · ▶️
- 看不到客户真实项目，怎样建立评测 — 09:18 🎧 · ▶️
- 律所要把个人经验变成机构资产 — 12:18 🎧 · ▶️
- 初级岗位、按小时收费与真实需求 — 16:40 🎧 · ▶️
- 数据看不见：用有限信号观察质量与隐私 — 26:12 🎧 · ▶️
- 表格审阅：把大规模提取变成可检查的界面 — 33:33 🎧 · ▶️
- Slack 需求入口与列表：让任务能在人和 Agent 之间流动 — 37:53 🎧 · ▶️
- 法律工程师与驻场工程师：定制如何不拖垮产品 — 43:52 🎧 · ▶️
- 后训练与法律检索：先改善系统，再考虑造模型 — 53:05 🎧 · ▶️
- 长文档、数据权利与平台竞争的未解问题 — 1:00:16 🎧 · ▶️
分节详解
1) 冷开场：能力跃升不等于法律工作全自动 — 00:00 🎧 · ▶️
💬 他们说了什么：开场把几种看似冲突的判断并置：很多法律工作不需要最顶尖模型；一次模型更新可能显著改善引用；“律师助理和初级律师都没了”的断言并不符合 Jacob 看到的情况；但在大型并购中，他认为客户仍会需要法律专用产品。
💡 为什么重要：这些观点为全场划定边界：模型能力、人工岗位与专业软件的价值不会沿着同一条曲线变化。某项工作能被模型完成，不等于整项法律服务可以免去审查、协作和责任分工。
⚡ 争议点：大型交易客户一定选择法律专用平台，是 Jacob 的竞争判断，而不是本集提供了市场比较数据后得出的结论。
2) 从瑞典法律搜索到“做工作、组织工作” — 01:54 🎧 · ▶️
💬 最初的产品基本是聊天界面加瑞典法律搜索工具。后来，Agent 能起草、编辑 Word 文件、组织文件并执行复杂分析；表格审阅用于批量提取和检查协议。产品还增加列表、需求入口和协作空间。Jacob 将其概括为两件事：完成法律工作，以及组织法律工作。
💡 法律项目的交付并非一次问答。客户提出需求、团队分派任务、检索材料、审阅风险、修改文件、交还结果，构成连续流程。只优化回答质量，无法解决邮件链和反复传递文件造成的摩擦。
⚡ 覆盖更多工作环节会提高产品黏性，也会增加权限、审计和界面复杂度；“一个工作空间”能否比律所已有工具组合更好，仍取决于实际部署。
3) 模型选择器：把复杂决策留给系统，还是交给律师 — 05:23 🎧 · ▶️
💬 Legora 按任务拆分并路由到不同模型；主 Agent 目前提供模型选择器，但部分工具仍在内部选用其他模型。Jacob 原本抵制把选择负担交给律师，后来因用户希望试用新模型而让步。他估计现有模型已能把约 60% 的工作做得很好；剩下尤其是复杂分析，仍需要更强能力。
💡 专业产品真正交付的是任务结果，而非模型菜单。模型的准确度、价格、延迟、地区可用性和治理条件不同；“最强模型处理一切”既贵，也未必必要。
⚡ “约 60%”是嘉宾对当前工作分布的估计，并非公布了样本、任务定义和统计口径的行业测量。让用户自行选模型还可能使成本与结果更难预测。
4) 看不到客户真实项目，怎样建立评测 — 09:18 🎧 · ▶️
💬 团队用模拟法律项目评测模型，例如给出一个包含 10,000 个文件的尽调资料室，再检查系统能否识别风险、写出简洁而正确的报告。评测按业务领域和任务制作表现图；Jacob 说，新模型常有些项目进步、有些项目退步。专门团队当时约有 3 名工程师、3 名律师，还能借助约 100 名法律工程师的专业经验。他也举例说，某次模型发布将引用表现从约 70% 提升至约 99%，团队在该问题上没有另做改动。
💡 评测不能只问“最终报告像不像样”，还应拆开检索、风险发现、分析与表述。模型自然进步可能快速解决局部问题，但版本回退要求产品团队持续测量，而不是盲目升级。
⚡ 节目没有说明 70% 和 99% 的具体指标定义、样本量或适用范围；它说明一次内部问题的改善，不应解读成法律引用整体已有 99% 的可靠性。
5) 律所要把个人经验变成机构资产 — 12:18 🎧 · ▶️
💬 Jacob 设想，未来 5 到 10 年律师会减少翻查文件等重复劳动，把更多时间用于风险取舍、策略判断和客户沟通。他认为合伙制的一项作用，是让掌握核心人力资本的律师愿意留在机构；而 AI 系统或许能把某家律所的先例文件、工作方式和判断经验沉淀为更持久的机构资产。
💡 如果经验可被持续组织和复用，律所竞争就不只取决于当前有哪些合伙人，还取决于机构能否把优质做法留在系统中。相应地，贡献知识的人需要得到激励。
⚡ Jacob 明确表示自己不知道未来会怎样。将专业判断编码为机构资产也涉及客户资料的使用权，以及合伙人离开后如何分享所创造价值；技术可行不等于激励和法律安排已经解决。
6) 初级岗位、按小时收费与真实需求 — 16:40 🎧 · ▶️
💬 主持人提出“律师助理、初级律师不再需要”的尖锐说法；Jacob 回答，这不是他们目前看到的情况，机构仍须培养下一代，但优秀的初级律师可以借工具完成更多工作。他承认按小时收费曾削弱效率工具的吸引力，不过竞争压力正在改变这一点；他观察到美国已有部分较基础工作改按项目定价，或作为维护客户关系的服务提供。诉讼、并购中的高价值判断和客户关系仍重要。
💡 自动化会先改变任务组合，岗位变化则还取决于培训、审查责任、需求增长和收费方式。若把“基础任务减少”直接等同于“培养新人不再必要”，律所可能失去未来能作战略判断的人。
⚡ 效率收益最终归客户、律所还是软件公司，节目没有给出可量化答案；项目收费扩大后，也可能出现定价压力，而非单纯把节省的时间转化为利润。
7) 数据看不见：用有限信号观察质量与隐私 — 26:12 🎧 · ▶️
💬 Legora 看常规使用与续约指标，也尝试用较便宜的模型生成在线质量信号，比较功能上线前后是否改善。但 Jacob 强调，客户项目资料高度机密，而且常属于律所客户，团队基本不能查看真实运行轨迹。面对“能否改写轨迹、去掉姓名再分析”的建议，他认为这未必安全；较保守的做法是将问题归入预先限定的 10 或 20 类失败模式，或按任务和业务领域分类。早期选择 Azure，也与律所已审批 Microsoft 作为供应商有关。
💡 隐私不只是部署选项，还决定产品团队能看到什么、怎样调试、能否收集训练数据。低细节度的失败类别虽然不如原始轨迹丰富，却能在保密约束下提供改进线索。
⚡ 分类信号可能漏掉未知失败，且“去标识化”是否足够安全取决于内容与合同约束，不能用统一规则判断。嘉宾关于律所云服务接受度变化的描述，也不代表所有律所或司法辖区。
8) 表格审阅：把大规模提取变成可检查的界面 — 33:33 🎧 · ▶️
💬 表格审阅让律师对许多协议批量提取同类信息，再逐行核查或调整问题。Jacob 提到单次可处理的规模可达约一百万个单元格。在大规模展开前，系统会先运行前 10 行，让使用者判断提取字段和结果是否符合预期，再继续扩展。
💡 表格不是简单把聊天结果排成行列，而是给并行、重复的审阅任务一个可比较、可纠错的工作界面。先小样本试跑，再大规模执行，能避免把含糊指令放大成海量错误与费用。
⚡ 处理规模不等于准确率。前 10 行能帮助发现明显的字段或指令问题，却未必覆盖罕见合同条款、异常文件格式和长尾风险。
9) Slack 需求入口与列表：让任务能在人和 Agent 之间流动 — 37:53 🎧 · ▶️
💬 法务需求可从 Slack 进入 Legora 的列表，律师在其中分派、协作、启动 Agent 并标记完成，结果再回到 Slack。列表支持字段、触发器和自动化：Agent 能创建或读取列表，列表变化也能启动 Agent。Jacob 说，这些可配置的底层组件还能支撑客户特定流程，以及收购 Wexler 后面向诉讼的事实梳理能力。
💡 入口、任务状态和结果回传解决的是组织问题，而不只是模型问题。可重复利用的组件允许团队在不为每个客户重做一套产品的前提下，交付不同的工作流程。
⚡ 高度可配置可能变成难以审计的自动化网络。哪些能力应开放给最终用户、哪些应由法律工程师配置，需要在灵活性与可治理性之间权衡。
10) 法律工程师与驻场工程师：定制如何不拖垮产品 — 43:52 🎧 · ▶️
💬 大客户上线时，法律工程师会与律师梳理流程、教学并配置产品；遇到需要生产代码、复杂集成或扩展产品能力的任务，则由驻场工程师参与。Jacob 说两者的简明分界是：前者像高级用户一样配置，后者编写进入生产环境的代码。他也解释，早期团队抵制开放 API，是因为维护旧版本会妨碍快速修改数据模型；现在已有部分 API，但并未承诺开放产品全部功能。他还在思考能否直接把 Agent 当作触发任务的接口，同时承认其成本、延迟和非确定性问题。
💡 定制需求是企业客户采用产品的动力，也是软件公司规模化的风险。用可配置组件覆盖常见需求、把代码开发留给真正的缺口，才可能让客户感到功能丰富，而核心系统不至于碎片化。
⚡ “Agent 即 API”在开放式任务上有吸引力，却不能自动替代需要稳定输入输出、明确费用上限和严格可重复性的传统接口。
11) 后训练与法律检索：先改善系统，再考虑造模型 — 53:05 🎧 · ▶️
💬 Jacob 说 Legora 此前没有微调自己的模型；随着开放权重模型变强，团队开始考虑对法律检索这类范围明确、需要大量并行查询的任务做后训练，争取更低成本和延迟，而不是自建主 Agent 的通用前沿模型。他也强调，检索架构、流程和运行框架仍有大量改进空间。起草复杂合同时，律师通常先寻找同类交易及条款先例，因此好草稿也依赖好搜索。对于幻觉，Legora 的引用系统试图让用户从结论逐层点回表格单元格、原始文件及对应位置。
💡 法律 AI 的质量链条从“找到什么”开始，而非从“写得多流畅”开始。后训练只针对明确任务，能避免把资源投入与大型模型公司正面竞争；可追溯引用则让人类有条件复核产出。
⚡ 能找到出处不等于推理正确。来源也可能被断章取义，引用覆盖率更不能代替对法律适用、交易背景和风险判断的审查。
12) 长文档、数据权利与平台竞争的未解问题 — 1:00:16 🎧 · ▶️
💬 谈到难以复现的错误，Jacob 说若客户愿意提供匿名化文件和提示，团队才更容易重现并修复。主持人提出“收购律所以获得数据”，Jacob 随即提醒：律所持有的材料未必归律所所有，而且只有最终文件、没有形成过程的轨迹，训练价值也受限。他赞同不要默认使用通用嵌入模型，但强调 Legora 服务多种语言，检索方案必须兼顾多语种。谈及平台边界，他预计大型企业可能通过 Claude 等入口调用部分能力，律所则可能直接在 Legora 工作；对于模型公司是否会限制竞争者，他认为不太可能，但这是判断，不是保证。节目末尾还谈到法学院教育和招聘。
💡 取得合法、能用于复现问题且包含工作过程的数据，比单纯积累文件更难。与此同时，法律专用产品必须证明自己在深度流程、治理和专业检索上创造价值，而不能假设通用模型永远不会进入法律市场。
⚡ 匿名化后的资料能否使用、并购后能否取得历史客户数据，都要依具体授权和义务判断。模型供应商的未来商业策略同样不受 Legora 控制。
人物与机构
- Jacob Lauritzen：Legora 首席技术官；本集主要受访者，讨论产品、评测、模型、组织及行业变化。
- Legora：法律工作软件公司；节目所述产品包括 Agent、表格审阅、列表、项目、法务需求入口和 Word 相关能力。节目提到其早期名称为 Leia。
- 法律工程师：Legora 对兼具法律实务经验和技术兴趣的人才所用的岗位称谓；参与客户沟通、产品配置和评测。
- 驻场工程师：在客户场景中处理复杂集成、生产代码及产品能力缺口的工程师，与法律工程师分工协作。
- Wexler：节目提及的 Legora 收购对象，侧重诉讼材料中的事实提取与比对。
- Microsoft Azure：Jacob 称早期因律所对 Microsoft 的既有供应商审批，Legora 将基础设施部署于此。
- Anthropic、OpenAI、Google：节目讨论的模型与平台供应方；它们的能力、产品范围和商业策略均影响法律应用公司。
金句
“一部分是做工作，另一部分是组织工作。”——Jacob 对 Legora 产品方向的概括
“我们基本看不到任何运行轨迹。”——Jacob 谈法律客户资料的保密限制
“Agent 能创建列表，列表也能启动 Agent。”——Jacob 谈任务与自动化的连接方式
“我现在的工作，是让客户觉得我们造了很多东西，而实际上我们只造了少数几样。”——Jacob 谈可复用产品组件
以上为依据英文转写所作的中文意译。
洞见与延伸背景
- “看不到数据”可能形成另一种产品纪律。 团队不能靠随手翻阅客户案例调试，只能更明确地定义任务、取得授权案例、构建模拟环境，并设计不泄露内容的观测信号。这不会自动带来更好评测，却会迫使评测与隐私设计同时进行。
- 可追溯性需要延伸到中间成果。 当报告引用表格、表格引用文件时，仅在最终答案附一个链接不够；用户需要沿处理链检查结论从哪里来、在哪一步被概括或改变。
- 法律科技的采购决策包含组织信任。 Jacob 对 Azure 的解释表明，客户已完成哪些供应商审批，可能和技术方案本身一样影响上线速度；增加一个模型或转写供应商，也意味着增加数据处理审查。
- “更快完成基础工作”会反过来挑战培训机制。 若新人不再通过大量手工审阅熟悉文件与风险，律所需要设计新的练习、复核和反馈路径，避免只留下高年资律师会做、低年资律师无从学起的工作。
争议与需核实
- 能力数字的口径：约 60% 的工作已能做好、引用从约 70% 到约 99%、单次约一百万单元格，均为节目中的口述数字；缺少统一任务定义、测量方法和外部复核。
- 引用与正确性的关系：可点击定位有助于核查，但不能单独证明来源真实适用、概括完整，或法律结论正确。
- 就业与收费预测：初级岗位不会立即消失、项目收费增加及高价值工作保持需求，均受地区、律所类型、客户预算和监管条件影响。
- 客户数据权利：资料经过匿名化，或因收购而转移持有者，不必然取得训练、分析和再利用授权。
- 竞争预测：Jacob 对通用模型公司不会切断法律应用、复杂交易客户会选择 Legora 的看法，属于受访者的商业判断。
- 名称与术语：英文自动字幕中对公司名、人名和部分模型名存在明显识别误差；涉及具体产品、模型或收购对象时，以正式披露信息核对为宜。
行动建议
- 法律团队试点：选一个边界清楚的任务，如同类协议条款提取；先用少量文件确认字段、来源定位和人工复核办法，再扩大处理规模。
- 采购与合规团队：逐项确认文件权属、数据处理供应商、地区部署、保留期限，以及产品团队在什么授权条件下能取得故障案例。
- 产品与评测团队：分别测检索、风险发现、分析、起草和引用；每次切换模型都检查各业务领域的回归，而不只看总体分数。
- 律所管理者：同时设计效率收益的定价方式、初级律师培养路径，以及合伙人贡献可复用知识的激励。
- 使用者：把引用视为复核入口，不是正确性担保；优先检查高风险结论、异常条款和跨文件推理。
来源
- Episode 页面
- YouTube 视频与英文字幕；英文转写来源：youtube-captions
- 节目音频
