夜雨聆风
这是法穿AI Copilot系列文章
在上一篇文章中，我们论证了通过 API 调用"人民法院在线服务"（以下简称"一张网"）进行立案数据预填报的合法性。
但合法性只是起点。今天我想往前走一步，做一个思想实验：如果正式发布"一张网"的 API 文档，开放标准化接入，会发生什么？
这不是一个遥远的假设。"一张网"本身就是一个成熟的前后端分离架构，所有 API 端点早已存在，只是尚未以官方文档的形式对外发布。从"逆向摸索"到"官方开放"，差的不是技术，而是一纸文档和一套接入规范。
"一张网"前后端分离架构之事实国内某律所2025年一年的立案量已超过十万宗。这不是靠增加律师人数实现的（该律所已被小红书实习律师列入黑名单，恶评如潮，哈哈哈），而是靠技术——通过 API 调用将立案流程自动化。
目前，一个律师手动在"一张网"上完成一宗案件的立案填报，从登录、选法院、填案由、录当事人信息、录代理人信息、上传材料到预览提交，熟练的情况下也需要15到30分钟。如果一个团队一年处理300宗案件，光立案填报就要耗费十几个工作日。
而通过 API 自动化，同样的流程可以在几秒内完成预填报，律师只需在最后的预览页面做一次人工审核。一年处理十万宗案件的团队，本质上就是把"人填表"变成了"机器填表、人审表"。
如果 API 文档正式开放，这种效率提升将不再是少数技术团队的"特权"，而是整个行业的基线能力。每一家律所、每一位律师，都可以通过标准化的 API 接入，将自己的案件管理系统与"一张网"直接对接。立案不再是"额外工作"，而是从案件管理系统"一键同步"的自然结果。
更关键的是，这与司法系统自身的智能化方向完全一致。深圳法院已经实现了AI辅助审判，越来越多的法院正在推进智能分案、智能排期、电子送达。既然审判端都在拥抱技术，立案端没有理由停留在手动填报的阶段。开放 API 立案，是整个司法数字化链条上顺理成章的一环。
案件收件箱：律师再也不用找借口说"漏看短信"了
每一位律师都经历过这样的场景：法院的立案通知、缴费通知、开庭传票以短信形式发送到手机上，律师因为出差、开庭、或者仅仅是短信太多而漏看，导致错过缴费期限或开庭时间。
这不是律师的职业态度问题，而是信息触达方式的问题。短信是一个单向的、非结构化的、容易被淹没的信息通道。法院发来的通知，和外卖提醒、快递取件码混在同一条短信列表里，漏看几乎是必然的。
如果"一张网"开放 API，法院的通知、材料、文书都可以通过 API 实时推送到律师自己的案件管理系统或律所的 OA 系统中。 具体来说：
案件编号同步：立案成功后，系统自动将法院分配的案号同步到律所案件管理系统中，与律师原有的案件编号形成映射关系。律师在自己的系统中就能看到"一张网"上的案件状态，不需要额外登录。
材料自动送达：法院发送的应诉通知书、举证通知书、开庭传票等材料，通过 API 推送到律师的收件箱中。律师在自己的工作系统里就能直接查阅、下载，而不需要登录"一张网"、找到对应案件、逐一下载。
法官信息同步：承办法官、书记员的姓名和联系方式自动同步，律师无需再通过短信中的零散信息拼凑联系方式。
对于律所管理者而言，这意味着所有的法院通知都可以在一个统一的仪表板上集中展示和跟踪。哪些案件待缴费、哪些案件即将开庭、哪些案件需要补充材料——一目了然。不会再有"我以为助理已经处理了""我没看到那条短信"这类借口，因为所有的信息都在系统里，有记录、有时间戳、有阅读状态。
本地完成：缴费、举证、申请调查令，不用再切换系统
目前律师在"一张网"上完成立案后，缴费环节的体验是这样的：法院生成一个诉讼费缴费二维码，发送到律师的手机或"一张网"的消息中心，律师收到后要把二维码转发给客户，客户扫码完成支付（或者直接通过银行转账到法院财政账户），律师再单独下载缴费凭证用于报销。
这个流程看似简单，但在批量案件场景下会变成一场噩梦。一个团队同时处理几十宗案件的缴费，每笔都要律师手动转发二维码给客户——律师在开庭、在出差、在会见当事人，二维码躺在消息中心无人问津，客户那边也在催。付款完成后，律师还要去下载缴费凭证，再转发给客户报销，徒增沟通成本。
如果"一张网"开放 API，这个流程可以变成完全不同的样子：
法院生成缴费二维码后，二维码数据通过 API 实时推送到律师的案件管理系统中。系统自动识别金额、案号、缴款账户等结构化信息，触发下一步流程：将缴费信息连同对应的案件信息一并推送到客户（委托人）的财务系统中。客户的财务系统按照预设的审批规则——比如"单笔5万以下自动审批"或"需部门负责人确认"——完成审批后，由客户选择扫码支付或银行转账到法院财政账户。付款结果通过 API 回写到"一张网"，缴费状态自动更新，律师在自己的系统中看到"已缴费"标记，缴费凭证自动归档，全程不需要手动转发二维码，不需要反复沟通催促，不需要手动下载报销凭证。
证据提交同样可以优化：律师在自己的案件管理系统中整理好证据目录和证据文件，通过 API 批量上传到"一张网"对应的案件中。证据的编号、名称、证明目的等结构化信息直接同步，不需要在网页上逐条手动录入。
律师调查令申请也是如此：将调查令申请所需的委托手续、申请书、调查提纲等材料在本地准备好，通过 API 提交到法院，申请状态和审批结果通过 API 回传。
这些都不是技术上的难题——"一张网"的 API 已经支持这些操作（否则网页端也无法完成），缺的只是官方文档和正式接入通道。一旦开放，律师的工作体验将从"登录网页、手动操作、等待响应"变成"本地系统一键完成、状态自动同步"。而缴费环节的变化尤其深远：它不仅仅是律师操作的便利，而是打通了律师系统与客户财务系统之间的最后一公里，让诉讼费的缴费从"律师转发二维码、客户手动扫码、律师再下载凭证"变成"系统对接、自动流转"。
这一步为什么值得迈出
有人可能会问：现有的网页端已经能满足立案需求了，为什么还需要开放 API？答案很简单：网页端是为"一个一个案件"设计的，API 是为"成千上万个案件"设计的。
当一个律师一年处理30宗案件时，手动在网页上填写信息是完全可以接受的。但当一个团队一年处理3万宗案件时，手动操作就不再是"效率低"的问题，而是"不可能完成"的问题。API 是唯一能支撑这个量级的接入方式。
而"一张网"已经具备了开放 API 的全部技术条件：
成熟的前后端分离架构——API 层已经独立于前端存在，不需要重新设计；
标准化的 RESTful 接口——所有端点都遵循统一的请求/响应格式，开发者学习成本极低；
完善的安全机制——JWT 认证、服务端权限校验、OSS 签名上传，安全体系已经就位；
已经被大量调用的现实——目前行业中已有多款工具在使用这些 API。
开放 API 文档，本质上是将"事实存在"的技术能力"正式承认"并纳入规范化管理。这不是从零开始建设，而是对现有架构的文档化和制度化。
司法效率的提升，不能只靠法官加班、律师提速。真正的效率革命，来自于系统层面的设计优化。"一张网"已经走完了"从纸质到线上"的第一步。下一步，是"从手动到自动"——而开放 API 文档，正是这一步的关键。
自动立案让律师从重复劳动中解放出来，API 收件箱让法院通知不再丢失，本地化操作让工作流不再中断。这三者叠加在一起，就是司法效率的质变。
"一张网"的 API 就在那里，文档迟早会被写出来。问题只是：是由官方来写，还是由开发者社区来写？
