豆包工作能接手复杂法律工作了吗？

豆包工作发布以后，对法律人而言，真正值得追问的并不是“它能不能写报告、做表格或者生成 PPT”。这些能力当然有用，但还不足以构成一张新的法律工作界面。

我更关心的是另一个问题：一个拥有较好上下文、项目空间、文件处理、Skill 和持续执行能力的办公 Agent，能不能成为法律人搭建“法律 AI 工作台”的底座？

这里所说的法律 AI 工作台，不是一个放了很多法律工具的页面，也不是把聊天框改名为“项目”。在我的理解里，它至少要做到几件事：案件材料能够形成相对稳定的项目上下文；后续任务不必每次从零解释；事实、程序、争点和来源可以在不同成果之间传递；专业方法能够通过 Skill 被调用；人工发现错误以后，系统知道哪些文件需要跟着修改；而在证据不足、法律状态不明或者判断风险过高时，又能把问题交还给律师。

这也是我这次测试豆包工作的出发点。

8 月 25 日，豆包工作正式发布。官方把它定位为面向生产力场景的 Agent 产品，强调围绕目标拆解任务、调用工具、推进复杂流程，并与飞书等企业上下文连接。背后的 Seed2.1 也把复杂文件处理、项目规划、工具使用和真实工作流中的稳定交付列为重点能力。豆包工作发布信息、Seed2.1 发布说明

如果只看这些发布表述，它与法律工作的距离仍然很远。法律人的项目不是“一篇报告”，而是一组会持续变化的材料、状态、意见和交付物。真正的检验，只能把一个足够复杂的事项交给它，看它能不能从“回答问题”进入“承载案件”。

一、先看工作台：它提供的不是一个孤立聊天框

我先从最基本的使用流程开始。豆包工作提供飞书账号、豆包手机号和扫码等登录方式；如果选择飞书，还会进入企业授权流程。对普通用户来说，这只是登录步骤，但对法律工作台而言，登录身份和数据边界从来不是小事：项目以后能访问哪些企业材料、使用什么组织上下文、由谁保留权限，都从这里开始。

登录入口支持飞书账号、豆包手机号和扫码。二维码已遮挡。

飞书授权界面会显示账号、组织以及申请访问的企业能力。截图中的二维码和身份信息已遮挡。

登录以后，首页左侧不只有“新工作任务”，还包括定时任务、技能与连接器、伙伴对话、云盘、手机遥控电脑和项目。这个界面本身还不能证明每项能力都已经成熟，但它至少说明产品的组织单位正在从单次聊天转向项目、角色、工具和持续任务。

豆包工作首页：任务、Skill、连接器、伙伴、云盘和项目被放进同一工作环境。账号信息已遮挡。

“伙伴对话”和智能体小队提供了进一步拆分角色的入口。对于法律团队，它潜在对应的不只是多个模型一起聊天，而可能是研究、合同、合规、证据和交付等不同工作角色。不过，这次测试没有把多伙伴协作作为变量，因此本文只把它作为界面事实，不把它写成已经验证的能力。

伙伴与小队入口。它提供了角色化工作的可能，但不属于本次 ANPD 单工作台测试的结论。

在“技能与连接器”里，可以看到法规检索、合同、数据合规、PIA 等法律相关入口。这一点之所以重要，不在于平台已经替法律人准备好了所有能力，而在于专业方法第一次可以被放进工作台，与项目材料和任务一起调用。后面的测试也会证明：Skill 出现在页面上、安装到项目里、被 Agent 真正调用，并不是同一件事。

法律相关 Skill 与连接器界面。界面可见不等于本次已经逐一安装或验证。

最后，我新建了一个独立项目，把它命名为“ANPD 调查 TikTok 案”。从这一步开始，测试对象就不再是豆包的一次临时问答，而是一个有材料、有工作目录、有连续任务和多个成果的案件空间。

建立独立的 ANPD 项目，是把复杂法律事项放进工作台的起点。背景中的账号区域已虚化。

二、这 32 份材料到底是什么：先把案件讲清楚

为了测试工作台能否真正承载复杂法律事项，我选择了巴西国家数据保护局（ANPD）对 TikTok／ByteDance 未成年人个人数据处理展开的调查与处罚程序。调查从 2021 年启动，随后经历技术调查、预防性措施、企业回应、整改计划审议、行政处罚程序、董事会投票和第一审处罚决定，延续到 2026 年。处罚决定认定五项违法并处以合计 R$153,769,671.33 的罚款，但案件并不能被简单概括为“TikTok 没有取得父母同意，所以被罚”。

真正的争议横跨多个层次：平台的游客模式是否处理个人数据、相关处理是否存在有效法律基础；未成年人订立数字服务合同是否需要父母代表或协助；平台是否在数据处理发生以前采取了有效的年龄保障措施；既有保护措施是否能够被证明真实有效；后续通过的新法又会怎样影响未来的年龄判定方式。

这 32 份材料也不是 32 份同类型、同效力的完整决定。它们包括技术意见、监管公函、预防性决定、企业回应的官方转录、董事会投票意见、整改计划决定、处罚审案报告和正式处罚决定。其中 19 份是完整官方原文或公开版本，1 份是后续官方文书中的完整嵌入转录，另有 12 份只能通过后续官方文书的摘录来确认；部分信息还依法遮蔽。

案件程序也不是一条从调查直接走向处罚的直线。一条线围绕监察、预防措施和未来整改展开，处理的是平台今后怎样持续合规；另一条线是行政处罚程序，追究过去已经发生的违法责任。材料里还出现三个程序编号，某些文书会引用、采纳或转录其他文书。企业主张、技术部门判断、报告人意见、其他委员投票与最终决定必须分层处理，不能因为都出现在官方卷宗里，就写成同一种“监管认定”。

正因为如此，这个案子特别适合检验法律 AI 工作台。一个很小的程序词汇错误，就可能改变案件当前状态；一份中间意见和一份最终决定的混淆，会让读者误判文书效力；企业说自己做了什么，也不能直接变成监管机关已经确认其合规。

我最终想知道的是：大量异质文书进入同一个项目以后，豆包工作形成的是一个可以继续工作的案件模型，还是只在一个更大的聊天框里检索片段？

D01—D32 一次性进入项目，Agent 先逐份读取并做材料验收，而不是直接摘要最后的处罚决定。

三、测试的第一原则：一次性给全材料，不让搜索能力污染结果

我没有让豆包工作自己去网上搜索这宗案件。32 份材料在主测试开始前一次性全部进入项目，中途不再补文件，测试过程也禁止联网。

这样设计有两个原因。第一，我要把“获取信息”和“理解案件”拆开。如果允许搜索，最后出现错误时，很难判断究竟是网页没有找到、版本抓错、页面解析失败，还是关键文书已经存在但 Agent 没有理解。第二，真实法律工作中，律师经常已经拥有一个完整或相对完整的 data room，问题不是还要不要搜一篇新闻，而是这些材料之间有什么关系，哪些状态已经确定，哪些判断只存在于中间文书，后续加入新任务时能不能继承此前的案件理解。

人工完成的冻结母稿、逐文书精读、争点谱系和最终案例文章与豆包项目完全隔离，只在测试结束后用于核验。这一点很重要，因为如果把人工结论提前放入项目，测试的就不再是 Agent 能否重建案件，而只是它会不会复述一份已经整理好的答案。

材料进入以后，第一轮任务不是分析实体结论，而是验收：报告实际识别和读取到的文件数量，逐一列出文件名、日期、机关或作者、文书类型、案号及可读状态，并标记重复、不完整、仅为后续转引或无法读取的材料。

法律工作台如果连“自己到底拿到了什么”都说不清，后面的复杂分析没有可靠起点。材料治理不是行政准备工作，而是法律判断的证据边界。

四、A 组不是随便问一句：原生工作台拿到的是专家指令

这次测试最容易被误解的地方，是把它看成“裸模型”和“高级 Skill”的简单比较。

如果 A 组只收到一句“帮我分析这个案子”，而 B 组 Skill 内置了大量专业规则，最后 B 组更好，这种差异主要说明一个好 Prompt 比坏 Prompt 强，并不能说明 Skill 带来了什么稳定增益。

因此，A 组虽然不调用 legal-case-analysis Skill，却从一开始就拿到一条明显经过专家设计的任务指令：

现在请基于项目中的全部材料，形成一份供资深隐私与数据保护律师继续工作的完整案件分析底稿。请还原案件事实、程序发展、关键文书之间的关系、核心争点、ByteDance／TikTok 的主要主张与抗辩、ANPD 的分析和处理结果，以及当前能够确认和不能确认的事项。重要事实、程序判断和法律结论应指明来源文件。不要联网，不要补造材料。请先自行制定工作计划，再完成分析。

这条指令已经把不少资深法律工作者会关注的要求放进了基线：使用者不是普通读者，而是要继续办理事项的律师；不能只写最终结论，还要恢复程序和文书关系；不能只呈现监管机关意见，还要恢复企业抗辩；必须区分能够确认和不能确认的事项；重要判断要挂回来源；材料不支持的地方不能自由补足。

换句话说，A 组的基线故意设得很高。Skill 如果要证明自己有价值，就必须提供超出一条专家 Prompt 的稳定工作方法，而不是仅仅多提醒几项分析要求。

五、完整测试方法：原生工作台、安装 Skill、显式调用与详细版分开看

本次比较固定了材料、模型、主要指令和禁止联网等条件，并在独立项目中运行。变化的不是案件，也不是人工答案，而是专业 Skill 是否存在、是否真正触发，以及采用何种深度。

这里必须把 B1、B2、B3 分开。B1 说明 Skill 装上了，却没有自动运行；B2 说明显式调用以后，Agent 会根据任务选择一个工作模式，但它选择的是 Internal Memo；B3 才是真正的详细版，而且因为本案不是单一判决，还需要把 Judgment Deep Read 适配成“逐文书、逐程序阶段、逐争点”的全卷宗分析。

除了主分析以外，我没有只看最终那一份报告，而是围绕同一项目持续下达任务，构成一条完整工作链：

这套方法刻意把几种容易混在一起的能力拆开：材料能否一次性读入、单轮能否答对、连续成果能否保持同一个案件模型、Skill 是否真正执行、错误能否传播修正，以及换会话以后项目是否还在。

六、A 组给我的第一个意外：不加 Skill，工作台已经可以做很多

A 组完成了全部 32 份材料的读取，生成一份 423 行、十节结构的案件底稿，并继续交付时间线、争点矩阵、管理层摘要、公开文章和来源审计。它能够识别两条程序线，恢复相当完整的企业抗辩，也知道把“企业主张”和“监管认定”分开；不少重要命题后面还挂有 D01—D32 的来源编号。

这一结果说明，工作台本身已经带来明显增量。过去在聊天框里做复杂案件，律师要反复上传文件、重述背景、复制上一轮输出，再手工把内容搬到 Word 或 Excel。项目环境至少让材料、任务和成果可以围绕同一个事项继续推进。即使没有专业 Skill，只要模型能力足够、专家指令写得清楚，原生工作台就能承担大量盘点、整理、转换和初步交付工作。

这也是为什么后面不能简单地说“加了 Skill，结果当然更好”。A 组并不是一个刻意做弱的对照，它已经接近一个现实中的强用户使用方式。

不过，A 组也很快暴露出两个值得法律人警惕的问题。第一，材料验收表明明只有 32 行，汇总说明却把 Nota Técnica、Despacho、Voto、Ofício 和 Relatório 合计成了 37 项。第二，原始材料明确保留 10 个工作日上诉期，部分核心成果在压缩时却把第一审处罚写得接近行政终局。

这些错误并不完全来自“没有读到”。相反，正确材料已经进入上下文，Agent 甚至能够在后来追问中给出相对准确的限定，但当复杂卷宗被压缩成一句管理层结论时，限定条件会被更顺口、更确定的表达吞掉。

七、裸工作台最典型的风险：它知道正确材料，却不一定守得住限定

在法律工作里，“知道一个事实”和“在所有成果中持续正确使用这个事实”是两种能力。

以处罚程序状态为例，D31、D32 都能支持这样的谨慎表述：第一审处罚决定已经作出，材料记载 10 个工作日上诉期，但截至现有材料无法确认公司是否上诉、上诉期是否届满，因此不能确认行政终局。A 组在某些局部分析中实际上读到了这些信息，到了完整底稿或管理层摘要里，却会使用“最终处罚决定”“处罚线已经终结”等容易让读者误判的说法。

这类压缩错误比普通漏字更危险。管理层摘要本来就是给没有时间读完整卷宗的人使用的，一旦最关键的程序限定在这里消失，后面所有沟通都会沿着错误状态继续推进。律师可能据此判断是否需要预留上诉资源，企业可能据此安排披露或付款，公开文章也可能把一个仍有程序窗口的决定写成已经终局。

所以，法律 AI 的准确性至少要分成两层：第一层是信息层，模型有没有见过正确材料；第二层是工作流层，正确状态能否在底稿、时间线、摘要、文章和来源审计之间保持一致。很多产品演示只能证明第一层，而真正进入执业以后，第二层才是更棘手的问题。

八、我没有继续让它多写报告，而是用四个“顺耳的错误”反向追问

为了判断案件模型是否真正建立起来，我连续提出四个诱导性问题。它们不是随机挑错，而是四个一旦回答失误就会改变案件性质或合规建议的问题。

第一个问题是：

整改计划获批是否意味着 ANPD 已经确认 TikTok 全面合规，或者历史违法责任已经消失？

豆包当轮先回答“都不是”，随后把监察／合规计划线与行政处罚线拆开。前者具有预防和矫正功能，处理未来持续合规义务；后者追究过去违法责任，五项罚款并不会因为整改路线获批而自动消失。它还指出合规计划是附条件批准，部分事项仍然开放，而 25% 减免来自放弃上诉的程序激励，不是历史责任免除。

同一企业、同一时期出现的两类决定被拆成两条程序线：未来整改路线获批，不等于全面合规，也不等于历史责任消失。

第二个问题是：

本案能否概括为“TikTok 没有取得父母同意，所以被处罚”？

豆包直接指出这种概括在法律上不准确。与父母介入相关的是 LGPD 第 7 条第 V 项下合同基础因缺少父母代表或协助而不能成立，并不是简单的“没有取得同意”。而且五项违规中，只有其中一项与这一问题部分相关；其他事项分别涉及游客模式缺乏处理基础、未在事前防止 13 岁以下儿童进入相关处理流程，以及平台未能证明保护和问责措施有效。更准确的压缩应当是：缺乏有效法律基础、未充分采取事前预防措施、未证明问责措施有效。

第三个问题是：

本案是否说明平台必须收集身份证或人脸信息才能进行年龄核验？

豆包同样没有顺着问题走。它区分了年龄保障义务与具体实施手段：ANPD 否定的是只靠用户自报生日，要求的是有效的预防式验证机制；本案没有指定必须收集身份证或人脸。企业自己也提出，证件、生物识别和人脸方案可能造成过度收集或排斥弱势群体。真正的分水岭是事前预防与事后反应，而不是“普通手段”和“敏感证件”的二选一。未来如果采用敏感数据手段，仍然要单独接受最小化、必要性和合法性审查。

前三问说明，工作台里的案件模型并不是只记住“未成年人、TikTok、罚款”几个关键词。它已经能够区分程序功能、法律基础、义务标准与技术手段，并把这些关系转换成双栏、逐项关系卡和边界卡。对律师而言，可视化并非装饰：它可以把一段复杂论证变成管理层、产品、隐私和合规团队能够共同审阅的工作对象。

但第四问也证明，界面表达得很清楚，并不等于法律判断已经完全正确。

九、第四问最值得保留：顶层结论正确，执行状态仍然写过头了

第四个问题是：

截至项目材料反映的状态，第一审处罚是否已经行政终局？

豆包的顶层回答是：“一审处罚决定已经作出并对外发布，但截至材料反映的状态，尚不能确认其已行政终局。”它引用 D32 已经作出并发布、材料记载 10 个工作日上诉期、现有材料没有披露公司是否上诉或期限是否届满，因此只能确认一审决定，不能确认行政终局。

如果只看第一段，这一轮似乎已经答对。然而同一回复后面又写了“决定已作出、已生效”“处罚附随义务已进入执行期”，卡片底部还出现“缴付与执行不受上诉影响”的过强表述。直到 B3 详细版后来回到 D32 第 5 项专项核验，才进一步确认执行以 trânsito em julgado 为前置；现有材料也没有上诉、弃权、缴纳或执行记录。

顶层状态卡把“已确认—材料未反映—尚不能确认”表达得很清楚；但同轮回复对生效和执行的表述仍然过强。

这一轮不能写成“四个诱导问题全部完全答对”，也不能用 B3 后来的修正倒推第一次回答已经正确。更准确的评价是：顶层结论守住了，但执行状态的配套表达没有守住。

这恰好说明律师复核的价值不在于重写一句更漂亮的话，而在于继续追问：“决定作出、发生效力、进入执行、行政终局，是不是同一个状态？”“决定主文是否把执行放在终局之后？”“卡片底部的业务含义是否获得了与标题相同强度的来源支持？”

十、Skill 装上了，却没有自动运行

第二轮测试开始以后，最先暴露的不是专业分析能力，而是 Skill 路由问题。

项目里已经安装 legal-case-analysis，但 B1 的运行轨迹没有显示它被自动调用。也就是说，Skill 存在、Skill 被调用、Skill 以什么模式执行，是三件不同的事。

这对实际使用非常重要。很多人看到项目里安装了一个专业 Skill，便会自然认为下一次法律任务已经由这套方法接管。但如果 Agent 没有路由到它，最后得到的仍然可能是通用模型基于普通上下文完成的结果。除非运行过程把调用状态、模块选择和执行深度显示出来，使用者很难仅凭成品判断 Skill 是否真正发挥了作用。

因此，我没有把 B1 计入 Skill 增益，而是重新显式要求调用。此时进入 B2。

十一、B2 使用的是 Internal Memo，不是详细版

在 B2 中，Agent 显式调用了 Skill，但它主动选择的是 Internal Memo，最终形成 292 行的案件底稿。这与 Quick Brief 相比已经更适合律师接手案件，却仍然不是 Judgment Deep Read。

B2 的底稿不再只是把事实、争点和结论装进一个长报告，而是更明显地按照律师工作顺序组织：先交代程序姿态与文书效力，再重建事实和证据层级，然后处理企业主张、监管回应和仍需核验的事项。对“官方完整原文、后续官方摘录、嵌入转录、公开遮蔽”等材料状态，它也比 A 组更稳定地分层；面对材料没有答案的地方，更倾向于明确写出“尚不能确认”，而不是用一个流畅结论填满空白。

这种变化看起来不像多找了几个事实，却改变了律师进入成果的方式。接手案件的人不必先把一篇通用分析重新拆回程序、证据和任务，而可以从已经标出的状态、来源和待办入口继续工作。

不过，B2 也没有神奇地解决所有问题。它的核心底稿仍然出现了把第一审处罚写得过于接近终局的表述；部分企业抗辩反而没有 A 组恢复得完整；合同必要性分析被压缩，约 775 万账户这一证据锚点也没有保留下来。Skill 带来的结构改善，并不自动等于所有事实细节都更丰富。

十二、管理层摘要和公开文章，才真正暴露上游案件模型是否稳定

完整底稿之后，我继续要求两组生成 1500 字以内管理层摘要，再改写成面向法律、隐私与合规从业者的公开文章。

这一步的价值在于，它迫使 Agent 改变受众和压缩程度。资深律师底稿可以保留复杂程序关系和大量来源，但管理层摘要必须短，公开文章又需要可读性。如果 Agent 只是对同一篇报告做机械删减，最先消失的往往是“不确定”“尚未反映”“仅在某份中间文书中出现”这些看起来不够利落、却对法律判断至关重要的限定。

B2 的上游结构确实影响了下游交付。管理层摘要更愿意先说明发生了什么、当前处于什么程序阶段、哪些事项仍需补证，再给出治理含义；公开文章也更清楚地区分案件事实、企业抗辩、监管认定和从业启示，而不是把长底稿缩短以后直接发布。

但前述终局性问题也说明，仅仅在聊天里答对一次，不会自动修复已经生成的底稿、摘要和公开文章。一个真正可用的法律工作台，不能把每份成果都当作互不相关的文本；它需要知道这些文件共享哪些关键命题，一个命题被修正以后，哪些下游成果必须重新检查。

十三、我仍然想知道：如果任务需要卷宗级深读，Skill 还能做到什么

做到 B2 时，我已经可以确认 Skill 对程序结构、来源纪律和律师工作入口有实际影响。但它选择的是 Internal Memo，不能据此宣称已经测过详细模式。

因此，我又增加了 B3，并把要求写得非常明确：

请明确调用项目中已安装的 legal-case-analysis Skill，并执行详细版流程。本轮不要选择 Quick Brief，也不要选择 Internal Memo。请锁定使用完整 Source-to-Structure Pipeline，并采用 Judgment Deep Read 的深度；鉴于本案是 32 份监管程序卷宗而非单一判决，请将 Judgment Deep Read 适配为“逐文书、逐程序阶段、逐争点”的全卷宗深度解析。

同时要求它重新基于 D01—D32 独立完成，不沿用既有底稿；建立完整文书索引，列出日期、机关、类型、程序线、功能、对象、前后关系、法律效果和完整性层级；按双程序线分阶段深读；至少对 D01、D04、D05、D08、D10、D14、D26、D30、D31、D32 做逐章逐节解析；完成争点矩阵和交叉核验，并单列资深律师工作入口与 AI 不能替代的事项。

B3 明确锁定 Source-to-Structure 全流程与 Judgment Deep Read，并把单一判决深读适配为 32 份监管卷宗分析。

这张截图比“已生成一份更长报告”更能说明 Skill 做了什么：它先判断文书类型和分析模式，再把输入治理、程序治理、关键文书解析、争点矩阵、交叉核验和人工交接组织成一条工作流。

十四、详细版没有机械平均阅读，而是先建立全卷宗结构

B3 最终形成 545 行的全卷宗底稿，但篇幅不是最重要的变化。它真正做的是先建立 32 份逐文书索引，把完整原文、后续摘录、嵌入转录和公开遮蔽分层；随后区分监察线与处罚线，把多个案号和程序阶段重新归位，再选择十份关键文书进入逐章解析。

这种做法比“每份文件摘要一段”更接近律师阅读卷宗。法律文件的重要性并不由页数平均分配。某份技术意见可能保存最完整的事实调查，某份报告人意见可能形成完整法律推理，最终决定则决定哪些理由被采纳、哪些命令真正进入主文。Skill 的价值在于先建立索引和关系，再把深度投入到决定案件结构的节点。

B3 还把“文书关系”当成需要核验的法律事实，而不是文件目录中的自然顺序。例如 D32 的原文写明采纳并吸收 D31 的理由，正确内容方向是 D31→D32；D30 则采纳 D26。方向写反，表面上只是一个箭头问题，实际上会混淆报告人意见与最终决定之间的效力关系。

十五、几个最容易弄错的地方，详细版开始主动 cross-check

详细版最明显的增益，发生在高风险命题的专项核验上。

首先是 D32 是否行政终局。B3 不再停留在“决定已经作出”这一层，而是回到决定主文第 5 项，识别 trânsito em julgado 是执行前置，并明确材料中没有上诉、弃权、缴纳或执行记录。这才把一审决定、上诉窗口、执行条件和行政终局真正拆开。

其次是董事会投票。执行过程中，Agent 一度把 D27、D28、D29 识别为“不跟随报告人”，随后回读票面勾选项 Acompanho a Relatoria，自行更正为三票一致附议。这个过程说明详细模式不仅多写内容，也会对影响结论的视觉或格式化信息进行回查。

金额、日期和案号也进入交叉核验。五项罚款总额必须与 D31、D32 相互印证；三个程序编号不能因为材料被放进同一文件夹就被统一处理；D31→D32、D26→D30 的采纳方向需要用原文动词确认，而不能只靠文件编号猜测。

最后，B3 还识别到 D32 内部对相关法条的引用存在不一致。对于律师而言，这类发现的意义不是让 AI 直接宣布“决定违法”，而是把需要进一步核验的异常显式标出来，形成后续法律研究或程序策略的入口。

十六、详细模式依然会犯错，这反而让人的位置更清楚

B3 的增益很明显，但不能写成“已经达到人工母稿”或“可以独立交付”。

它没有恢复人工母稿中约 775 万账户的关键证据锚点；对 LGPD 第 7 条第 V 项的合同基础分析，仍然主要停留在未成年人合同有效性，没有充分拆出第二道门槛——每一项个人数据处理是否确实为合同核心履行所必需；对 D31、D32 删除命令中的年龄范围差异，也出现了统一化表达。

此外，结构更清楚、引用更密集，并不会自动消除材料本身的歧义、公开版本的遮蔽或法律解释分歧。模型可以列出几种可能理解，却不能替律师决定哪一种解释应当进入客户意见、监管沟通或诉讼策略。

因此，详细模式最真实的价值不是把律师移出流程，而是把律师从大量机械重组中解放出来，让有限注意力集中到异常、冲突、效力、解释和策略上。它缩小了人工必须逐字处理的范围，但没有取消人工判断。

十七、最像“工作台”的一轮，是人工指出问题后，它真的改了文件

测试后段，我没有直接告诉 Agent 正确答案，只说某个地方“可能存在错误”，要求它回到原始材料检查原结论、错误环节、修改方式、受影响成果，并实际更新文件、形成修改记录，不能只在聊天里解释。

第一处错误是 A 组材料验收说明里的 37 项统计。Agent 回读 32 份 Markdown 的文书元数据，确认原汇总相加确实为 37，而且所谓“双文种命名导致重复”的解释不成立；随后得到正确分布：8 份 Nota Técnica、10 份 Despacho、10 份 Voto、3 份 Ofício、1 份 Relatório，共 32 份。它检查 00_材料验收表.xlsx 和 01—06 全部下游成果，确认逐行验收表本身没有错，只有汇总说明受影响，于是实际修改该文件并新增勘误记录。

第二处错误是程序关系说明中的 D32⊂D31。Agent 回读 D32 的原文 cujas razões acolhe e integra à presente decisão，确认 D32 采纳 D31，正确表达应为 D31→D32；随后又核查 D30，确认 D26→D30。它发现 Excel 数据单元格原本方向正确，错误只存在于配套说明中的符号简写，因此只修改真正受影响的位置，并在表尾增加统一规则：以后使用“被采纳文书→采纳文书”的箭头，不再使用容易产生歧义的 ⊂。

人工只指出采纳方向可能有误，Agent 回到原文核验、排查影响范围，并实际更新受影响的文件。

这两轮体现了办公 Agent 与普通聊天工具最实质的区别。它不是在对话里说一句“你说得对”，而是回源、定位错误、检查影响面、修改文件并留下记录。法律 AI 工作台合理的目标本来就不应是一次生成绝对正确的母稿，而应当支持律师在审阅中持续修正案件模型，并让修正进入成果链。

边界同样必须写清：两处错误都不是系统主动发现，而是由人工指出；联动修改能否成功，也依赖用户有没有设计正确的纠错任务。Agent 已经可以执行复核流程，但“哪个异常最值得怀疑”仍然由专业人员决定。

十八、最不像“工作台”的一轮，是新开会话以后项目没有接上

如果只看同一会话中的 32 份材料和连续交付，很容易把“长上下文”理解成“项目记忆”。我因此关闭客户端，重新进入同一项目，新建对话，不重新上传材料，也不粘贴旧摘要，然后要求它先说明能够访问哪些既有文件，再用一页纸概括程序结构、当前状态和三个最容易被误读的问题，并标明来源。

两组都没有通过，但失败方式不同。

B 组检查以后明确表示，自己目前访问不到任何本项目既有案件材料或已生成成果，没有裁判文书、分析报告、任务清单，也没有上一轮对话历史可以继承。它拒绝在没有来源的情况下生成一页纸，要求重新上传文件、提供路径或说明企业知识库位置。

B 组没有接上项目，但承认材料缺失并停止。这是失败，也是相对安全的失败。

A 组同样没有访问到 ANPD 材料，却继续调用企业检索，把“本案”识别成 Quote.law 测评中的另一个 AI 漫像转换特效模型纠纷，并生成了那个案件的程序结构和误读问题。界面顶部仍显示 ANPD_TikTok_01，输出内容却已经属于另一个项目。

A 组在 ANPD 项目里填入了另一个案件的内容。这不是普通遗忘，而是跨项目污染。

对一般办公任务，这可能只是一次尴尬的答非所问；对法律工作，它可能同时触发事实污染、保密、权限、利益冲突和错误交付风险。B 组的“我没有材料，所以停止”虽然不满足功能预期，却比用其他项目补足缺口安全得多。

这次测试因此只能证明单会话内的 32 份长上下文处理和连续交付能力，不能证明稳定的跨会话项目记忆。长上下文描述的是一段执行过程中模型能看见多少；项目记忆还包括材料是否持续可达、权限是否隔离、任务做到哪里、哪个版本有效、哪些结论已经被人工修正。两者不能混为一谈。

十九、真正比较三层成果，不能只看谁写得更长

把 A、B2 和 B3 放在一起看，差异不是“有没有 Skill”这么简单，也不能用一个总分或篇幅来替代。

这张表反映出一个比“Skill 让模型提高多少”更有用的结论：原生工作台已经能够承担大量法律材料整理和多成果转换；Skill 的增益主要发生在工作顺序、来源纪律、状态核验和人工交接；详细模式则把更多算力与阅读深度集中到关键文书和高风险命题上。

因此，专家 Skill 的价值不应被理解为一段特别厉害的 Prompt。A 组已经证明，强模型加上专家 Prompt 本身可以达到很高的基线。真正更难固化的是：为什么要先确认程序姿态，哪些材料只能作为一方主张，什么时候必须回到原件，哪些限定不能在摘要中消失，何时选择 Brief、Memo 或 Deep Read，以及做到什么程度以后必须停止推断、交还给律师。

二十、工作台、Skill 和人，其实解决三个不同问题

跑完整个测试以后，我对这三层能力的分工反而更清楚了。

工作台解决的是“事情能不能持续做”。它负责承载材料、项目、文件成果、工具和连续任务，让同一案件可以从材料验收走到分析底稿，再走到时间线、矩阵、管理层摘要、公开文章和来源审计。它的价值不是多一个聊天入口，而是减少每一轮从零开始的上下文搬运。

Skill 解决的是“按照什么专业方法做”。它决定从哪里开始、先建立哪些状态、怎样区分事实与主张、什么时候回源、什么深度适合当前任务、哪些命题必须通过质量门，以及哪里应当设置人工接管点。它并不取代模型能力，而是把通用能力组织成专业人员可以重复调用和检查的工作方法。

人解决的是“最后怎样判断，并由谁承担责任”。律师要验证关键异常、解释法律、处理材料冲突、选择风险策略、识别跨项目污染、决定哪些事实可以进入正式意见，并对最终签发负责。剩余工作也许在字数上不占多数，却往往决定整个成果是否可以使用。

所以，我不再愿意把人机分工简单写成“AI 做 80%，律师做最后 20%”。真正的关系更接近：工作台承载复杂事项，Skill 组织专业方法，人控制高风险状态、作出判断并承担责任。

二十一、一个真正的法律 AI 工作台，还缺什么

这次测试证明，办公 Agent 已经能够在单次长程执行中处理复杂卷宗、连续生成多种办公成果，并在人工提示后完成回源和修改。这比传统聊天工具前进了一大步。但跨会话失败也说明，法律工作台不能只靠“更长的上下文”来定义。

一个真正稳定的法律 AI 工作台，至少要显式管理五类状态。

第一是材料状态：哪些文件已经进入项目，哪些是完整原文，哪些只有摘录，哪些因为权限或遮蔽不能读取。第二是来源状态：每个关键命题来自哪份文书、哪个段落，是机关认定、一方主张还是分析推论。第三是任务状态：材料验收、底稿、摘要、来源审计分别做到哪里，哪些任务依赖前一步。第四是版本状态：一个关键程序判断被修正以后，哪些文件已经更新，哪些仍然保留旧结论。第五是审阅状态：哪些内容由 AI 生成，哪些已经人工核验，哪些必须等待外部事实或最终决定。

如果这些状态没有被管理，项目看起来仍在持续，实质上却可能只是一次很长的对话。律师真正需要的不是永远不犯错的模型，而是一个让错误可发现、可追溯、可传播修正，同时不越过权限和证据边界的工作系统。

二十二、法律人接下来要学的，不只是 Prompt

当办公 Agent 已经可以一次处理 32 份监管文书，并持续生成时间线、矩阵、摘要、公开文章和来源审计时，法律人的 AI 学习如果仍然只停留在“哪个模型最好”“Prompt 怎么写”“哪个按钮在哪里”，很快就会不够。

下一步更重要的是怎样定义一项可验收的法律任务，怎样把材料组织成可信的项目上下文，怎样确认 Skill 这一次有没有真正执行，怎样为任务选择 Brief、Memo 或 Deep Read，怎样用高风险问题做反向验证，怎样让一个错误传播到所有相关成果，以及什么时候必须回到原文、停止让 Agent 继续推断。

这也是我为什么把这次测试称为搭建“法律 AI 工作台”，而不是试用一个新的办公工具。产品可以给出项目、文件、Skill 和连接器，但法律工作台最终仍然要由法律人自己设计：材料怎样进入，方法怎样调用，质量门设在哪里，谁可以看见什么，哪一步由人接管。

9 月 2 日 19:30，我们会把这个问题再往前推一步。届时会围绕 Google 法律 AI、DeepSeek Harness 和豆包办公，讨论怎样把研究、合同与 AI 合规工作重新组织起来；现场还会把同一份合同、同一个审核要求交给不同 Agent，观察模型、工作台、任务设计与人的判断分别改变了什么。

我们不会只看谁写得最长，也不急着做一个排行榜。更值得讨论的是：什么才算法律 AI 工作台；律师和法务在这类工作台里怎样工作；直接使用、搭建个人工作台与建设组织平台有什么差别；以及法律人现在应该先做什么。

9 月 2 日 19:30「法律 AI 工作台时代来了」公开课。扫描图片中的二维码添加微信预约直播。

这次豆包工作实验给出的结论并不是“AI 已经可以独立做完一宗复杂案件”。它真正说明的是，AI 正在从回答一个问题，进入持续处理一项事务；而法律人接下来需要建设的，也不再只是一套 Prompt，而是一套可以承载材料、方法、复核、版本和责任的工作系统。

测试说明：本文基于 2026 年 9 月 1 日对豆包工作的单案例实测。主测试使用同一批 ANPD 材料、固定模型与任务要求，禁止联网；过程事实来自 Computer Use 回看的豆包原始会话，不以最终人工母稿反推当轮回答。本文只对本次任务和当时产品版本负责，不构成对所有案件、模型或工作场景的普遍结论。豆包界面截图中的个人账号信息均已遮挡。