评价一个法律案例网站，人们通常先看收录数量、法域范围和更新速度。这些指标当然重要，不过它们主要回答材料是否丰富。进入具体工作以后，法律人更关心使用过程：相关案件是否容易找到，法律争议背后的技术事实是否清楚，已有研究能否继续用于文章、备忘录或产品建议。
我最近体验的 AI诉讼网，已经沿着这条使用路径向前走了几步。网站以全球 AI 诉讼案例为基础，向上延伸出案例对比、律师分身和内容生成，同时提供 API 与 MCP 接入方式。把这些功能连起来看，它更像一个正在形成中的专业知识工作台，案例检索只是入口。
为了了解这套设计在实际任务中怎样运转，我让 Codex 围绕一款虚构的 AI 购物智能体进行测试。这个智能体可以在用户授权后登录电商账户，跨平台搜索商品、领取优惠券并加入购物车，还可以在一定额度内自动下单。我们想知道，用户授权与平台许可是什么关系，智能体访问不同页面时要遵守哪些边界，平台规则、身份披露和数据使用又会怎样影响责任判断。
从产品问题进入案例研究
这类问题如果只从法规开始，很快就会得到一张覆盖数据、平台规则、网络安全和不正当竞争的清单。清单能够提示风险，却很难告诉产品团队哪些事实最可能影响判断。诉讼案例提供了更具体的观察窗口，因为当事人的技术行为、平台的控制措施和法院关注的争点都已经进入同一场冲突。
第一轮检索找到了两个适合对照的案例，一个是 Amazon v. Perplexity，另一个是网站收录的广州互联网法院 AI 智能体不正当竞争案。前者涉及 Perplexity 的 AI 购物工具 Comet 访问亚马逊平台，后者把智能体操作、平台授权和技术措施带入中国司法场景。两案的法域和程序阶段并不相同，放在一起仍然有助于我们识别同一类产品问题：当智能体开始代替用户行动，用户、平台与工具开发者之间的授权关系会变得更复杂。
AI诉讼网的案例页把法域、案号、法院、程序状态、法律问题和 AI 技术类型放在同一个概览中，向下还可以继续查看案情、双方观点、法院说理、技术说明和行业意义。法律人可以从案由和裁判逻辑进入，产品人员也可以沿着 AI Agent、数据访问和自动化操作等技术标签理解案件，两类角色因此更容易围绕同一组事实展开讨论。
法律信息和技术行为出现在同一个案例入口中。
这种组织方式对 AI 诉讼尤其有用。很多争议表面上属于版权、数据或不正当竞争，责任判断却往往取决于更细的技术事实，例如系统访问的是公开页面还是受保护区域，平台能否识别自动化访问，智能体是否绕过限制，数据是否会被保存和再次利用。案例页面将法律标签与技术标签放在一起，相当于提前完成了研究中最费时间的一部分整理工作。
案例对比进一步把不同法域的材料放进同一视野。测试时，我把 Perplexity 案与广州 AI 智能体案放入对比页面，从法域、案件类型、法律问题、争议焦点和裁判信息一路读下来。阅读的重点也随之发生变化，我们开始关注访问对象、授权来源、身份披露、技术措施、数据用途和行为控制，而不再满足于知道两起案件分别得出了什么结果。
跨法域对照帮助使用者把案件结论还原为产品事实。
法规通常给出原则，案件则让原则落到具体行为。对于正在设计智能体的团队，这种对照可以直接反推产品问题：登录和授权流程是否清楚，自动化访问是否尊重平台设置，读取数据是否超出完成任务所需的范围，发生争议时又能否还原用户、智能体和开发者各自做了什么。案例因此从研究材料变成了产品评审可以使用的输入。
律师分身让案例开始承载个人判断
如果体验停在检索和对比，AI诉讼网已经是一座围绕 AI 议题组织得更细的案例数据库。它更有意思的一步，是在案例之上加入阿来律师 AI 分身，让用户可以直接围绕产品和法律问题发起对话。
我使用页面提供的问题“我的产品用了大模型 API，有哪些合规风险？”进行测试。分身从输入数据、输出内容、算法要求、备案与安全评估、平台责任等方向展开分析，并在回答中调用相关案例。对于刚进入一个问题的产品团队，这样的回答能够快速建立问题地图，也能把后续研究带回具体案件。
案例库成为分身回答问题时可以调用的知识底座。
分身的价值并不取决于它是否拥有一个律师头像。一个长期处理互联网与 AI 案件的人，会逐渐形成自己的选案标准、问题意识和判断习惯。他知道哪些技术事实值得追问，也知道一个程序性结论应当怎样放回业务场景理解。文章可以记录其中一部分，散落在不同案件和项目中的经验却很难被读者随时调取。
当案例、原创分析和长期形成的专业观点进入同一个交互入口，个人知识开始以另一种方式被使用。用户提出产品问题后，系统可以调用相关案例，沿着相对稳定的分析路径组织回答，再把需要继续确认的事项交还给使用者。它无法替代正式法律意见，却可以承担研究启动、材料定位和问题展开等前置工作，让专业人员更快进入需要判断的部分。
从这个角度看，律师分身是一种知识产品。它保存的内容包括案件和文章，也包括一个人如何理解这些材料、如何组织问题以及如何把法律判断讲给不同角色听。律师经验由此获得了比文章更强的可交互性。
内容生成有了专业材料作为起点
在分身之后，AI诉讼网还提供文章和文书生成。测试中，我让 Copilot 围绕“AI 智能体代表用户访问第三方平台时，应重点关注哪些法律边界”生成一篇面向产品经理和合规人员的文章。生成内容先调取相关案件，再按法域梳理事实与法律问题，并继续进入比较分析。
生成内容以具体案例为起点，并据此搭建跨法域分析结构。
通用大模型也能写出结构完整的法律文章，专业使用者更在意的是材料来源和核验路径。AI诉讼网提供了一种更接近法律工作的生成方式：先从专业案例中找到研究对象，核对事实与程序信息，再围绕用户提出的问题完成组织和表达。生成过程因而有了可以回溯的知识起点。
这种设计让问答、文章和文书不再彼此孤立。用户可以先通过案例页理解案件，再让分身展开问题，随后把同一批材料转成面向产品团队的简报、面向同行的文章或内部研究初稿。前一阶段整理的上下文能够进入后一阶段，法律人也不必在网站、聊天窗口和文档之间反复解释同一个问题。
有来源的生成并不会取消核验工作，它改变的是核验发生的位置。过去大量时间用于寻找案例和重新搭建结构，今后可以把更多精力放在确认材料、校准结论和结合业务事实上。对于经常需要把同一研究转成不同交付物的法律人，这种连续性比单次生成一篇文章更有价值。
MCP让网站能力进入日常工具
分身和内容生成都发生在网站内部，MCP则把案例能力带向用户自己的 AI 工作台。AI诉讼网目前提供本地 MCP 示例代码，可以将公开接口封装为案例搜索、里程碑案例、案件详情和原始法律文书等工具，并接入 Codex、Claude 等支持 MCP 的客户端。
案例检索和文书读取可以通过 MCP 进入外部 AI 工作台。
过去使用专业数据库，通常需要打开网页完成检索，再把材料复制到正在处理的项目中。MCP提供了另一种可能：用户可以留在自己的工作目录里，让 AI 调用案例接口取得材料，然后继续完成比较、会议准备、产品评审或文章写作。数据库不再要求所有工作都发生在它自己的页面中，而是逐渐成为其他工具可以使用的专业能力。
对已经把 Codex 或 Claude 用于项目管理和内容工作的法律人来说，这种变化会很明显。一个关于 AI 智能体的产品评审，可以在同一项目中调取相关案例，整理授权与访问变量，再把结果写入风险清单和会议材料。AI负责检索、组织和延续上下文，法律人负责核验来源、结合业务事实并作出决定，前后环节可以留在同一套工作记录里。
本轮体验确认了 MCP 的接入结构和可调用工具，后续还会继续测试它在实际客户端中的连续调用。即便如此，这个方向已经把网站的边界推得很远。案例库由供人查阅的目的地，逐渐变成可以嵌入项目的知识服务。
律师经验开始变成可以运行的系统
把这次体验放在一起看，AI诉讼网的产品路径已经相当清楚。用户先在案例页完成检索和理解，随后可以带着这些材料与分身对话，并继续生成文章或文书；当 MCP 接入外部工具后，同一批知识还能进入正在进行的项目。前一阶段积累的内容不必在每个环节重新整理，网站也由此从内容集合逐渐长成一套可以持续使用的工作系统。
AI诉讼网最值得借鉴的，是它没有把律师经验只写成文章，而是尝试把经验转化为数据结构、分析流程、交互产品和可被其他 AI 调用的能力。
这句话也解释了它的前瞻性。律师的专业积累过去主要存在于案件、文档、课程和个人记忆中，使用方式依赖阅读、检索与口头传递。当这些材料被结构化，并与稳定的分析路径和调用接口连接起来，个人经验就有机会进入团队协作，也能被新的 AI 工具反复使用。
这并不意味着所有判断都可以交给系统。法律工作的责任仍然落在具体的人身上，来源核验、事实适配和最终决策也不会消失。变化发生在前面的工作方式：材料更容易找到，思路可以被复用，已有研究能够继续进入下一轮任务，专业人员不必每次都从空白页面开始。
今晚直播，聊聊这套系统怎样被做出来
今天晚上 19:30，我会和 AI诉讼网的构建者张延来律师进行一场对谈。直播会从案例库的起点谈起，继续聊到律师分身、内容生成和 MCP，也会讨论一个案件如何从原始材料变成 AI 可以调用的数据，个人观点怎样进入分身，网站又为什么选择把能力开放给外部工作流。
7 月 21 日 19:30，扫描海报二维码预约直播。
过去讨论法律 AI，我们常常把注意力放在模型能回答什么。这次直播更想沿着一个具体产品往里看：一个律师多年积累的案例、文章和判断方法，怎样逐渐形成一套能够被检索、对话、生成和调用的系统。案例库提供了起点，后面的路才刚刚展开。