法律与专业服务：交付的是哪一种信任

同一份合同，一位律师代表买方，另一位代表卖方。两人可能同意某个句子是什么意思，却完全不同意应该怎样修改。让 AI 找出这句话，是检索问题；让它准确解释，是理解问题；让它给出适合本次交易的改法，则必须知道谁的利益、哪一次谈判、什么可以让步。

这也是法律与专业服务对 FDE 提出的特殊要求：靠近用户，不只是多懂几个行业名词，而是理解一项意见何时可以成为客户采取行动的依据。文稿做得越快，这个问题反而越明显。如果专业人员要重新核实全部资料、追查每处修改，生成速度并不等于交付速度。

本章主要看国际律所 Allen & Overy，简称 A&O，以及后来合并成立的 A&O Shearman，与法律 AI 公司 Harvey 的合作；再用普华永道的并购工作流和一份法院判决作比较。公开材料能证明客户专家参与研发、试用和产品化，足以讨论相似的共同工程模式；它们没有逐项公开现场人员的 FDE 职称。具体项目的组织身份与可借鉴的交付方法，需要分开判断。

从会问问题，到参与造工具

A&O 在 2023 年 2 月 15 日的公告中回溯了起点：自 2022 年 11 月起，由律师与开发人员组成的市场创新团队，牵头试用 Harvey 测试版。公告同时要求，输出须由本所律师仔细审查。¹ 这不是一个先完成软件、再交给全体律师学习的故事。客户内部已有一支能够把业务问题带入开发过程的混合团队。

到 2023 年 12 月，律所披露了另一项组织安排：早期使用者小组收集适用场景、有效做法和不奏效的地方，将经验传给全所。合伙人 Peter Van Dyck 举的例子也很具体：他用 Harvey 寻找专利诉讼相关案例，再交给对应司法辖区的同事继续分析。² 前一步缩小查找范围，后一步判断材料是否真正适用，两者的责任没有被一句“AI 已经查过”合并。

对工程师而言，这种用户反馈远比笼统的满意度有用。“答案不好”可能是没找到资料，也可能是选错了法域；可能是引用准确却无关，也可能是论证方向违反本次委托。不同错误需要不同修复。扩大搜索范围无法解决客户立场缺失，换一个模型也不能替代尚未确定的任务边界。

因此，早期共建最值得留下的资产，不是最长的提示词，而是一组已经说清楚的工作差别。哪些问题只需要资料线索，哪些可以产生初稿，哪些需要当地专业人员判断？用户修改输出，是因为模型漏读了附件，还是因为客户临时改变了谈判策略？把两种修改混在一起学习，系统会把商业选择误当作普遍法律规则。

2023 年 12 月 21 日，A&O 宣布与 Microsoft、Harvey 合作推出合同工具 ContractMatrix。它运行于微软的云平台 Azure，可以作为网页应用或 Word 插件使用；律所称，内部律师参与了测试、改进与开发，五家大客户已为次年一月推出服务达成条款。³ 已有内部使用、已经签约与之后面向客户推出，是三个不同状态，不能用同一个“落地”抹平。

Word 插件这个细节并不炫目，却解释了共同工程为什么要进入真实工作。若建议只能停在另一个聊天窗口，律师还要找到合同原处、复制文字、保留修订痕迹，并检查转移时有没有出错。把建议放到文档里的正确位置，可能比让答案多一页更有价值。这里的产品体验与专业责任相连：人必须看得见软件到底改了什么。

一条合同修改，怎样走完交付

下面构造一个教学任务：企业准备采购一项软件服务，请律师协助审查供应商发来的合同。它只用于说明工作分配，不代表任何客户的实际项目，也不提供具体法律意见。我们选“是否允许对方向第三方转交某项义务”作为审查主题，不讨论哪种条款在某地必然有效。

任务进入系统以前，负责律师先确定委托范围：此次只检查约定的几类交易风险，还是要全面审阅？客户业务负责人补充交易背景：服务怎样使用，业务可以承受什么例外，哪些让步必须上报。文件管理员确认收到的是当前谈判版本，并列明正文引用的附件。工程师据此配置任务入口，而不是让模型从文件名称猜客户站在哪一边。

在这项教学设计中，负责律师还要与客户确认本次允许使用哪些文件、范本，以及哪些人可以查看材料与结果。上传到外部工具之前，团队须弄清资料送往何处、对方如何使用，再按已确认的安排操作。工程师把委托和资料的授权范围落实到检索，并让生成稿、操作记录及导出文件延续相应的访问限制。文件同在一个资料库，不意味着可以跨委托混用；允许某人提出问题，也不表示他可以读到全部答案。

第一步是把要审的对象固定下来。若正文引用附件中的“获准服务商”，附件却没有上传，系统应记录缺失。它可以提示律师索取文件，不能将“没有读到限制”写成“合同没有限制”。两者只有几个字的差别，客户采取行动时的含义却不同。

资料边界也要经过检查。团队可以在隔离测试中放入一份人工构造、标属另一委托的文件，分别检查当前任务的检索结果和最终文稿是否混入其内容，并测试未获准人员能否访问输出。发现越界，先暂停该任务、修正限制，再重新验证。这是本书建议的测试动作，不是对某家产品已经实现隔离的保证。

第二步是明确审查规则。企业既有的谈判手册，通常想表达理想条款、可接受退让和必须上报的情形。教学例子中，客户同意某类常规安排，却要求另外一类安排事先批准。专业人员负责把这些类别说清楚；工程师负责让规则与本次委托关联。只上传一份过去签过的合同并不够，因为过去接受过的条件可能只是那笔交易的例外。

第三步才轮到模型提出修改。它需要标出受影响的原文、适用的内部规则及理由。如果正文说“可以转交”，附件却限定对象，修改不能只盯住正文的一句。更不能在未获得授权时，把本来要求“检查并提示”的任务升级成“替客户接受新条件”。

第四步由专业人员作出处理：确认建议、改写建议，或交由客户决定是否让步。这里最好保留两个不同结果。“符合既定规则”表示可以按既有授权处理；“不符合规则但客户决定接受”表示一次经确认的例外。若两者都记成通过，下次系统就可能把例外当成默认规则。

最后一步是形成可交付版本。律师核对最终文稿与已同意的改动是否一致，企业有权限的人决定是否接受交易条件。工程师提供的是让版本、依据与决定对应起来的工具，不能因为自己搭建了审批按钮，就取得专业审查或商业批准的权力。

这条过程可以压缩成一张交接表。每一行留下的东西，都能帮助下一位参与者判断自己收到的究竟是什么。

这张表也给 FDE 划出了一个可执行的目标：让异常准确到达有能力处理的人。附件缺失交给资料负责人，规则冲突交给规则制定者，商业让步交给客户。若每个问题都退回技术团队，工程师再贴近现场，也只是在替组织保管一条没有分工的队列。

为什么多找几个 Agent 还不够

Harvey 在 2026 年 9 月 2 日公开的工程文章，提供了一个有用的产品层面解释。它称，当年早些时候重建了按谈判手册审合同的系统：旧流程逐条处理规则，可能丢失上下文，也可能对同一段文字提出冲突修改。新设计让工作 Agent 在文档副本中提出带规则标记的修改，再由统筹 Agent 合并并处理冲突。⁴

这份材料解释的是 Harvey 产品的工程变化，不能反推 A&O 某个项目已经使用同一版本。它的意义在于暴露了一种容易被演示遮住的困难：把工作并行分出去，并不自动得到一份一致的合同。

把冲突缩小到一句完全虚构的中性条款，比较会更清楚。原句是：“乙方向甲方发送月度服务报告，收件人为附件 A 所列联系人。”以下规则、改稿和裁决都只是教学，不来自任何公司，也不判断真实合同的法律效力。

统筹程序可以发现两项改动触碰同一句，并检查最终文稿有没有遗漏任一修改；它不能从两段流畅文字中自行推导出客户已经作出 D1。假如输入中没有 D1，正确交付应保留原文、两项建议和“待客户确认名单规则”，而不是擅自生成一个已接受版本。已填冲突裁决记录与空表同时保留这两个分支。

这样，机械合并与专业决定有了不同的检查对象。前者核对位置、规则标记和文字对应，后者确认本次授权怎样解释，是否需要商业让步。把所有冲突都自动消掉，反而可能把尚待决定的事藏进完成稿。

这就产生了两种不同的完成。技术完成，是文件能够生成、修订没有相互覆盖、链接可以打开；专业完成，是该检查的问题已经检查、必要例外获得处理、结论没有越过委托范围。一份没有报错的文件，只能证明前一种完成的一部分。

评估也要沿着这种差别展开。Harvey 披露，其内部律师参与建立测试标准，修改质量还由模型评委评分；新架构改善了内部评分，同时增加了平均等待时间。⁴ 这类评估可帮助选择设计，却不是客户交易质量的独立证明。等待时间变长是否值得，要看人拿到结果后少做了多少追查和重写。

本书建议，合同试点至少把三种错误分开记录：漏掉应提示的问题、提出不必要的修改、提出正确方向却改坏关联文字。第一种损害风险发现，第二种增加谈判负担，第三种制造隐蔽返工。把它们加成一个平均分，会让工程团队难以决定下一轮该修检索、规则还是文档处理。

测试材料也不能全是干净的标准合同。上述教学任务应包含缺附件、旧版本、对方已拒绝过的建议、同一问题在正文和附件表达不同等变体。负责律师先说明每种情况期待系统停止在哪一步，工程师再验证工具是否做到了。这样测出来的是一个可执行流程，而不只是模型认识了多少术语。

专业人员之间的分歧也有研究价值。两名律师给同一建议不同评分，未必说明其中一人看错了；他们可能对客户授权范围作了不同理解。测试负责人应先核对双方收到的背景是否一致，再判断分歧来自法律理解、商业偏好还是文稿风格。如果连专家采用的前提都没有固定，就要求模型稳定地给出唯一答案，工程团队很容易把尚未解决的业务问题误判成模型不稳定。

因而，有些测试的正确结果应是一项问题，而不是一段改好的文字。例如“这一例外是否已经获客户批准”，如果输入资料不能回答，工具能提出准确追问，比它猜中某位评审者的偏好更可靠。这样的评估会奖励适当停止，也让使用者逐渐理解工具的职责。

有引用，还不等于有依据

法律研究提供了另一种反面证据。英格兰和威尔士高等法院在 2025 年 6 月 6 日就 Ayinde 与 Al-Haroun 两案作出的同一份判决中，记录了 Al-Haroun 案的四十五处案例引注，其中十八处所引案件不存在；其余材料也有引文不实或不能支持主张的情况。律师承认依赖当事人提供的研究，未独立核验。法院强调，当事人的错误不能免除律师的责任。⁵

这不是 Harvey 或 A&O 的项目事故。它检验的是所有专业工具都要面对的交付条件：真正存在的文献，也可能被错误使用。一个链接可以打开，只解决了“找得到”；文中确有那句话，才解决“引得对”；这句话在本案中能支持什么，还需要专业判断。

因此，检索界面如果只展示一个绿色引用标记，很容易制造不必要的确定感。更有用的呈现，是让使用者看见原文位置、材料类型、适用范围与本次结论的关系。软件可以协助完成这些核对，却不应把检索成功包装成意见已经审定。

上述法院判决同时明确，使用 AI 开展法律研究的人，应在专业使用前对照权威资料核实；依赖别人完成的研究，也不能省略这项责任。⁵ 在本章的工程推演里，这意味着交接单上要写明“核查到什么程度”。同事已经读过一份文件，与同事已经认可该文件支持本次主张，是不同的信息。

当工具进入专业服务，最危险的责任空隙往往发生在这两种信息之间。技术人员以为专家会检查，专家以为系统已验证，管理人员以为有审核步骤就表示有人承担完整核对。解决办法不是再加一句“请注意准确性”，而是让审核对象具体可见：此次核对的是材料真实性、引用对应关系，还是最终意见。

这也给结果统计提供了尺度。“检查过多少份文件”只能说明处理量；“发现多少风险”还依赖风险的定义；“交给客户的意见是否减少返工”才更接近服务质量。最后一项需要实际交付记录，无法由生成次数直接换算。

客户开始共同出售专业能力

2025 年 4 月 6 日，A&O Shearman 与 Harvey 宣布合作推出多步骤法律 Agent，覆盖反垄断申报分析、网络安全、基金设立及贷款审查等任务。律所不仅计划内部使用，还将向客户和其他律所提供服务，并参与软件收入分成。公告中，融资业务合伙人 Filippo Crosara 介绍了双方共同开发的贷款审查、数据提取和组合比较能力。⁶

从 2022 年的试用到这一安排，客户身份发生了变化：先使用软件，再把本机构的专业做法做进工具，最后共同对外提供产品。这里的“接近客户”不能只按到访次数衡量。客户已经参与界定产品应当知道什么，以及哪些步骤值得标准化。

这种变化也带来新的维护问题。律所内部的一套工作法，依靠共同训练、熟悉的同事和口头背景，可能运行得很好。交给另一家公司后，这些隐含条件不再存在。原先一句“按通常做法处理”，必须展开成适用条件、例外和谁可以批准。产品化会迫使专业机构看清，哪些经验能够复用，哪些依赖尚未写出的判断。

普华永道的并购业务出现了相近路径。2025 年 7 月 31 日，它宣布将与 Harvey 共同开发、已供自身团队使用的并购平台向客户授权；用途包括利用专业工作流生成尽职调查的初步风险提示报告。⁷ 尽职调查就是在交易前检查目标公司的资料和风险。“初步”二字不能删除：从资料中提出值得追问的问题，并不等于替投资者决定这笔交易是否值得做。

两种合作都提示，专业机构能提供的不只是行业知识文本。它还掌握问题应该以什么顺序提出、哪些异常值得升级、什么表达会误导收件人。若这些经验进入软件，FDE 式共同工程便有了清晰对象：把一项专业任务从输入做到可交接，而不只是给用户一个万能问答入口。

但把工作法写进产品，并不会自然解决客户之间的差别。用于卖方准备资料的工具，与买方发现风险的工具，即使读取同一批合同，也应具有不同任务范围。面向客户开放使用后，还要明确哪些资料属于哪次委托，谁可以改变规则，更新是否影响正在处理的事项。本章把这些列为交付设计要求；公开公告没有披露完整合同分工、收费结构或每项维护成本，不能据此估算利润。

以规则维护为例，新版谈判手册可能改变某类条款的处理方式。工程师不能只替换后台文件：正在谈判的合同，究竟继续沿用原授权，还是需要重新审查，应由客户与负责律师决定。系统则要能找到受影响的事项，显示它们此前依据的版本，并保留重新处理的结果。否则，昨天还被认定可接受的条款今天忽然变红，用户既不知道发生了什么，也无法向客户解释。

维护由此成为专业服务的一部分。需要更新的不只是法律资料，还有机构自己的立场和任务约定；更新的节奏也未必相同。把这些变动都交给模型自动吸收，会使产品越来越难以说明某次意见是在什么前提下形成的。

什么时候不必安排一个驻场团队

专业机构自身的知识管理与成熟工具，也可能带来上述改进，无须依赖长驻工程师。如果需求只是搜索经过整理的范本、比较两个文档版本、按稳定模板形成初稿，内部业务支持团队加标准软件，可能已经足够。

FDE 的必要性应从未解决的问题中产生。资料和权限分散在不同系统，现有工具无法可靠接入；客户规则频繁冲突，技术团队需要与专家共同重构任务；新工作流没有既有操作方式，必须在真实使用中反复校正——这些才构成较强的共建理由。不能因为专业人员的时间昂贵，就推导出工程师应该长期驻场。

试点也应给替代方案公平机会。同一类合同，可以比较现有工具加清晰模板，与新增 AI 流程分别需要多少资料准备、专业复核和客户解释。把所有人工准备都算给旧流程，却把新流程的规则维护和错误追查算作一次性建设，会得出过于乐观的答案。公开案例中的使用量与产品推出日期，尚不足以完成这种总成本比较。

还有一笔较慢显现的投入：人的判断能力。A&O 在 2023 年的经验文章中已提出，如果初级律师因工具替代部分工作而无法自然获得必要经验，就应主动设计训练。² 这个提醒与 FDE 有直接关系。工程师可以减少重复劳动，但需要和专业负责人讨论，哪类练习原本承担了培养能力的作用。

在教学采购任务里，可将已核验的旧合同保留为训练材料，让新人先说明某处为何需要上报，再比较工具建议。学习目标不是手工重做所有机械步骤，而是能识别何时不能接受一个看似合理的答案。否则，短期审阅更快，长期却少了能够检查工具的人。

法律与专业服务交付的信任，最终有一个具体形状：收件人知道这份文稿根据什么、检查到了哪里、还留下哪些决定，并且能够找到负责解释的人。共同工程若能使这些信息随工作一起移动，才把专业能力带进了软件。生成一份完整文稿，是这个过程的一步；让别人有根据地使用它，才是交付。