做了什么
- 专注工作台工单系统：送审、派单、批改、跟进全流程留痕
- 8 级程序状态机与法定期限分级守护
- 全息战略记录舱：预判、复盘、待办可追溯
- 卷宗 WebDAV 本地挂载、客户专属码扫码收件
- 每家律所独立数据库、独立实例、独立文件目录
我们想解决的不只是效率问题
律师办解决的是"事怎么办快、怎么办不漏"。但律师行业还有两个更深的问题：专业能力如何被看见，服务争议如何被公平判定。这是我们做二期和三期的原因。
三步走
每一步都建立在上一阶段沉淀下来的真实数据之上，不是三个互不相干的设想。
办案自动化
已上线
流程与期限交给系统
能力显影
研发中
让专业被数据看见
信任机制
规划中
争议可预裁判
一期 · 律师办（已上线）
先把"办案这件事"做成一套会自动推进的系统——这是后面一切的地基。
为什么它是地基
一期最大的副产品不是效率，而是结构化沉淀：程序类型、办理节点、时间跨度、文书产出与办理结果，都以可统计的形式留在了系统里。
过去这些信息散落在纸质卷宗和零散文档里，无法被统计；现在它们成为了二期能力画像的依据。没有一期的沉淀，二期无从谈起。
二期 · 实务能力雷达图（研发中）
让扎实办案的律师被数据看见，而不是被流量看见。
问题出在哪
当下律师的能力背书，很大程度上靠包装：谁的曝光多、谁的账号活跃，谁看起来就更"专业"。而真正埋头办案的律师，反而缺少一个客观的展示方式。
对客户来说也一样——除了熟人介绍，几乎没有低成本辨别律师实际执业水平的方法。
我们想怎么做
把一期沉淀的脱敏办案数据，自动生成律师的实务能力画像：
- 案由分布：擅长办理什么类型的案件
- 结果结构：胜诉、调解、撤诉等结果的分布情况
- 出庭与文书：出庭次数、文书产出量
- 办案周期：从立案到结案的时间特征
怎么算（口径）
只做统计聚合，不做单案披露。画像展示的是分布与趋势，而不是某个具体案件的当事人、案情或文书内容。
参与范围、可见范围与口径规则在开放前会完整披露。
隐私边界（先说清楚）
- 是否参与由律师本人决定，可随时退出
- 客户信息、案情细节不进入统计结果
- 客户与第三方只能看到聚合后的画像，看不到案件明细
- 律所可自主决定是否对外展示本所律师的画像
二期仍在研发中，功能形态与上线时间以正式发布为准。
三期 · 防投诉与预裁判平台（规划中）
把"律师有没有尽力"从各说各话，变成可核对的记录。
纠纷的真实成本
律师服务的结果天然带有不确定性，客户期望与实际结果之间的落差，很容易演变成投诉。而一旦进入投诉流程，双方往往都拿不出完整的过程记录，只能各说各话——最终消耗的是客户的时间、律师的声誉，以及主管部门的精力。
其中还不乏虚假或恶意投诉，缺少事实依据的快速辨别手段。
设想的机制
- 三方信任协议：客户、律师、平台在委托开始时明确服务范围与过程记录规则
- 全息服务记录：客户随时可见办理进度与关键节点（源于一期的能力）
- 对口匹配：基于二期的能力画像，把案件匹配给实际擅长该案由的律师，从源头降低期望落差
- 平台预裁判：争议发生时，在授权范围内调取案件电子卷宗与过程记录，核对"该做的步骤做了没有、期限有没有守住"
- 过滤虚假投诉：以过程记录为依据，快速区分"确实没做到"与"做了但结果不如预期"
对客户
选律师有依据，过程看得见，争议有据可查。
对律师
认真办案的过程被完整记录，不必为无依据的指责自证。
对行业
把无事实依据的投诉挡在早期，把精力留给真正需要处理的问题。
三期处于规划阶段，尚未开始开发；上述内容为方向性构想，不代表已具备的功能。
我们的一条底线
这套构想的前提是：数据属于律所与当事人，不属于平台。
因此一期才会把"每家律所独立数据库、平台运营方看不到案件文件"作为底层设计的前提，而不是事后补上的承诺。二期的能力画像、三期的预裁判，都只能建立在律师与客户授权的基础上。
这条底线如果守不住，后面的构想都没有意义。