JSTAI 律师 AI 助手
8 大模块 · 428 项真集成测试 · 律师办案效率提升 18 倍。
本地 OCR + 18 种自动脱敏 + 云端大模型推理 + 律师审阅输出，案件数据不出本地。
这一页讲的是「跑在 Minihub 基座上的法律工作流」，不是基座本身
底座是 AI Agent Minihub（产品 02）—— 通用 AI Agent 平台，负责用户交互、模型调度、记忆与安全网关。 本页讲的 8 大模块、428 项测试、18 类脱敏规则，是构建在这个基座上的 第一个专业工作流：同一套网关和模型管理，换一组法律技能，就成了律师助手。
所以这两件事要分开看：Minihub 回答「凭什么能长出这些」， 本页回答「长出来的这个具体是什么、做得怎么样」。 平台页和产品页是官网上的两个独立入口。
案卷怎么读进来的：两条路径，OCR 引擎是实测选出来的
支持 PDF / Word / Excel / CSV / 纯文本 / Markdown / 图片。 数字 PDF 和扫描件走完全不同的两条路 —— 这一步分错，后面全错。
数字 PDF：直接读文本层
PDF 自带文本层时直接解析，不经过 OCR，也不做任何字符改写 —— 秒级完成、零误识。优先判断有没有文本层，是判断「这份材料值不值得 OCR」的第一步。
扫描件 / 图片：本地 PaddleOCR
无文本层时自动转图，走本地 PaddleOCR 2.7.3。整条链路 0 云端，案卷不出本机。Word 走 mammoth，图片直接进同一条 OCR 管线。
OCR 引擎为什么是它：52 页真实案卷实测对比
用一份 27.9 MB / 52 页的真实起诉材料，逐页跑 PaddleOCR 和本地视觉模型 qwen2.5vl:7b，对比律师真正关心的字段：
| 关键字段 | PaddleOCR 2.7.3 | qwen2.5vl:7b | 结论 |
|---|---|---|---|
| 身份证号 | 9 | 6 | PaddleOCR 更准（不瞎识别不存在的） |
| 手机号 | 4 | 2 | PaddleOCR 更准 |
| 日期 | 130 | 120 | PaddleOCR 略准 |
| 当事人姓名「李弘」 | 14 正确 / 0 误识 | 9 正确 / 1 误识成「李红」 | 姓名是律师最不能错的字段 |
| 总耗时 | 2–3 分钟 | 32 分钟 | 差 13 倍，律师等不起 |
| 总字符数 | 37,657 | 183,319（4.87x） | 字符多 ≠ 更准 |
那次实测推翻了一个想当然的结论
字符数多 4.87 倍，直觉上像是「视觉模型更强」。但拆到字段级看， 「保证人」它报了 506 次，PaddleOCR 只有 42 次 —— 多出来的多数是「保证」和「人」被拆开重复计数，是噪声不是信息。 字数多不等于准，所以最终定 PaddleOCR 为默认，视觉模型只留作复杂版面的兜底。
不是简单打码，是一套能保持法律语义的符号系统
云端模型必须「看得懂案件结构」才能写得出起诉状，但又永远接触不到真实信息。 纯打码做不到 —— 把「李弘」换成「张三」以后，模型连谁是谁都分不清了。
2 类
身份证号、银行卡号。
6 类
姓名、手机号、邮箱、住址、车牌、律师姓名。
10 类
合同号、法院、机构、金额、日期、法官姓名、案号、法条、案由、当事人角色。
关键设计：靠上下文区分，不靠猜
「金山泰」和「李弘」都是中文姓名，如果都用同一个姓名符号，模型就分不清谁是律师、谁是当事人 —— 而这恰恰是法律文书里最要紧的区分。解法是用上下文角色定位：
| 真实值 | 上下文 | 符号化结果 |
|---|---|---|
| 金山泰 | 出现在「代理人：」之后 | @LAWYER_1@（律师） |
| 王小明 | 出现在「审判长：」之后 | @JUDGE_1@（法官） |
| 长沙市芙蓉区人民法院 | 机构名 | @COURT_1@（法院） |
| 李弘 | 裸姓名 | @NAME_1@（当事人） |
同一个真实值，全文共享同一个符号
「金山泰」在整份案卷里出现 30 次，符号化后全部是 @LAWYER_1@，
不是 @LAWYER_1@…@LAWYER_30@。云端模型因此能看出
「这 30 处说的是同一个人」—— 语义关系被完整保留，只有身份被替换了。
这一条是整套符号系统的地基。
全部在本地执行。云端拿到的永远是占位符；真实信息只存在于律师这台机器上， 由本地还原模块在出文书的最后一步填回去。
提高准确率、查出错、把不准的交给律师 —— 是三件不同的事
把「AI 不够准」当成一个问题去优化是解决不了的。这三件事要分开做，各有各的手段。
第一层 · 先把图变清楚
OCR 之前先做图像预处理：300 DPI 采样、灰度化、锐化边缘、对比度提升、倾斜校正。 扫描件的问题大半出在这一步 —— 纸歪了、拍糊了、光照不均， 原始像素直接扔给 OCR，再强的引擎也读不出来。
第二层 · 形式化校验找茬
抽出来的值逐个过格式规则：身份证 18 位且带校验位、银行卡 16–19 位、
手机号 11 位且 1 开头、日期 YYYY-MM-DD、合同号字母开头 12–20 位。
还会抓「同一字段抽到多个版本」这种典型 OCR 错位。
第三层 · 交叉核对
把结构化字段和 OCR 原文对撞：填的借款金额，在原文里到底有没有这个数？ 「万」和「元」两种写法都换算一遍。 这道防线抓到过一次真实事故 —— 借贷纠纷的当事人金额和卷宗对不上， 直接导致「事实与理由」段出现矛盾数字。
怎么把关键信息交给律师确认
每一个案件都会生成一份《案卷当事人信息核对清单》，逐字段列出「提取值 / 核对结果 / 判定依据」：
| 字段 | 校验规则 | 抓什么错 |
|---|---|---|
| 姓名 | 通用中文姓名 | 同音错字（李弘 → 李红） |
| 身份证号 | 18 位 + 末位校验位 | 数字错位（OCR 最常见） |
| 联系电话 | 11 位，1 开头 | 位数缺失 |
| 银行卡号 | 16–19 位 | 位数错位 |
| 借款金额 | 含元 / 万元，与原文交叉核对 | 数量级错、单位错 |
| 争议日期 | YYYY-MM-DD 统一 | 点号斜杠混用、位数错 |
| 合同号 | 字母开头 12–20 位 | 多个版本并存 |
拿不准就不填
没抽到的字段一律写成 × 占位，绝不猜。
宁可让律师多看一眼，也不能让系统替律师认定一个身份证号。
没确认就不出文
核对结果写回 case-confirmed.json，记录确认人、确认时间和律师的每一处修改。
案件信息与案情摘要两项都确认之后，文书生成这一步才会放行 ——
这是代码里的前置判断，不是提示语。
扫不清的印章和签名，我们现在做到哪一步
这一块要先把话说清楚：下面区分「已经上线的」和「策略设计、还没上线」， 不把规划说成现状。
一、已经上线的
落款区文字被完整覆盖
OCR 提示词明确要求识别「正文、标题、表格、签名、日期、金额、当事人姓名」， 不只是正文。落款处的文字会进抽取结果。
落款日期有形式化校验
统一成 YYYY-MM-DD，半角标点在中文上下文转全角，多余空格压缩。
格式不可能对的那一类错会被直接标出来。
异常进警告区
多版本日期、多版本合同号、金额异常，统统进「自动检测警告」区， 排在核对清单最上面，律师一眼能看到。
页码级可回溯
抽取结果按 第 N 页 分段留存。律师对某个值有异议，
能立刻翻到原件对应页看，不用把整份材料重读一遍。
二、还没做的（说清楚，避免误解）
以下四项目前没有实现
① 印章的「区域级检测」 —— 判断「这份材料到底盖没盖章、盖在哪、是不是骑缝章」，
目前没有这个能力，代码里只把印章当作普通文字区域处理。
② 印章真伪图像比对 —— 需要印章样本库和比对脚本，
那 9 份比对脚本目前不在交付机器上，无法演示也无法验证。
③ 手写签名识别 —— 签名是图像不是文本，
OCR 在原理上就提不出「这一行是签名」这个结论，只能靠区域检测绕开。
④ 落款区单独高分辨率重采样 —— 目前整页统一 300 DPI，
落款区没有单独提到 600 DPI 再读一遍。
三、打算怎么解决（策略设计，未上线）
核心思路只有一句：别硬读，改判状态。
从「读出每个字」降到「有没有」
「这份材料盖没盖章」是一个二值判断，比「读出印章上每一个字」可靠得多。 前者靠版面定位加双引擎交叉投票就能做，后者做不好 —— 墨迹晕开、压字、骑缝， 强行读只会产出一串看着像真的假信息。
落款区块单独提精度
印章、签名、落款日期在版式上几乎总在固定位置（末页右下或落款处）。 先做版面分析把这块框出来，再对这一块做 600 DPI 重采样 + 局部倾斜校正 + 局部二值化， 比整页统一 300 DPI 准得多。
双引擎交叉投票
两个引擎都判「此处有印迹」→ 高置信，直接采信。 只有一个有 → 不填，列进待确认清单交给律师。 不取「多数决」，因为两个引擎在模糊区域上很可能一起看错。
形式化校验当兜底网
落款日期除了格式校验，再加常识区间交叉验：不晚于今天、不早于立案受理日。 这一条能抓住「年份识别成 2022，却出现在 2025 年的材料里」这类跨文档矛盾。
贯穿始终的一条底线
拿不准就不填。印章、签名、落款日期这一类信息， 系统的价值不在于「替你认定」，而在于「把你需要亲自看的那几处，准确无误地挑出来给你看」。 这三样在起诉状里是能被对方一眼看穿的硬伤 —— 一个错日期、一处没盖章， 成本远高于律师多花两分钟核一遍。
5 条黄金规则，不是承诺是代码里的拦截
模式分流 + 三层拦截（IPC 进程级、UI 交互层、prompt 提示层）共同保证。 任何一层被绕过，下一层仍然拦住。
客户身份证不出本地
CHAT 咨询师模式下进程级拒绝读取任何本地文件，UI 层面不提供文件入口， prompt 层明确声明当前会话不具备文件访问能力。三处独立拦截。
案件合同不出本地
WORK 律师助手模式下可读案卷，但发往云端前必须经 18 种脱敏规则处理， 未脱敏的原文没有任何代码路径可以离开本机。
银行账户不出本地
银行账号、卡号、开户行信息统一替换为 @开户行@ 一类占位符，
文书生成后在本地还原，避免在云端留下可关联的金融标识。
庭审笔录不出本地
庭审笔录属于 WORK 模式 + 律师显式授权才能处理的材料， 每次读取都有授权记录，行为可审计、可回溯。
会见笔录不出本地
刑事案件专属保护。见会笔录涉及辩护秘密，默认不参与任何云端推理， 本地检索也仅限当前案件范围。
三层拦截怎么协同
IPC 层管进程能不能读文件，UI 层管用户点得到什么， prompt 层管模型以为自己能做什么。任何一层单独失效，数据依然出不去。
律师工作流 · 四步走
从案卷上传到文书输出，全程本地化处理，案件零泄露。
案卷 OCR
上传 PDF / Word / 图片，本地 PaddleOCR 引擎提取全文。识别结果逐字段展示给律师校对， 置信度低的字段单独标出，优先人工确认。
18 种脱敏
身份证号、银行账户、手机号、合同号等敏感字段自动替换为占位符。 律师可逐条查看脱敏结果并手动补充规则，脱敏日志留档可查。
云端推理
脱敏文本经 JSTAI 隐藏中转站（X-JSTAI-Platform 头）发往你自选的大模型，
返回结构化结果。中转站不落盘、不留存、不参与训练。
律师审阅
占位符在本地还原为真实信息填入模板，一键导出法院可提交的 docx。 律师人工审阅后提交，全程留痕可追溯。
从模式分流到隐藏中转站，每个模块都为办案而做
CHAT / WORK 模式分流
CHAT 咨询师模式不读取任何文件，适合咨询与思路讨论；WORK 律师助手模式才可访问本地案卷。 律师选哪个模式，对应的 agent 身份、职责、边界 prompt 会自动注入云端大模型。
8 类文书库
民事起诉状、律师函、民事答辩状、民事上诉状、调解协议、刑事辩护词、 案卷证据分析、民间借贷法律依据。LLM 一次性输出完整文书，渲染为可提交的 docx。
BYOK 自带 Key 架构
支持 JSTAI 云端、OpenAI、Anthropic、智谱、自定义共 5 个 provider。 走 JSTAI 隐藏中转站时，平台侧只能看到脱敏文本，读不到你的 Key 与案件原始信息。
用户记忆库
办案偏好、律所信息、常用法条、历史案件摘要自动保存并跨会话复用。 记忆库默认本地存储，律师可随时导出、导入、迁移。
律师友好 UI
字典、文案、lookup 路径、状态管理层、JSX 表达式五个维度全闭环。 律师界面上永远只看到 JSTAI 品牌，内部模型 ID 仅在悬停提示里出现。
一键迁移
全部记忆、历史任务、设置、文书库、BYOK 配置一键导出。 换电脑、换律所、团队协作零障碍。
系统扫描
一键体检：Ollama 状态、端口冲突、权限、存储、OCR 引擎、网络延迟。 异常项进警告区，自动给修建议。
💎 增值服务体系 — 3 备选方案
原「VPI ¥99/月」整条体系要换。三个备选：
- ✓ 适合个人律师（1 人独立办案）
- ✓ 模型 BYOK 自带，本产品不抽成
- ✓ 案件数 / 文书数 无限制
- ✗ 团队协作要单独加席位
- ✗ 升级/维护靠社区和文档自助
- ✓ 适合 3-30 人中小律所
- ✓ 团队协作 + 知识库共享 + 角色权限
- ✓ 含技术响应 7×24 + 季度升级
- ✓ 部署实施协助 1 次
- ✗ 单价高，个人律师不如 A 划算
- ✓ 适合大量重复处理（合同审查 / 案件归档）
- ✓ 用多少付多少，无最低消费
- ✓ 适合非律师业务（法务助理 / 合规岗）
- ✗ 单案成本高
- ✗ 知识沉淀不归你所有（除非加购 B 档）
⏳ 三个方案价格都是「¥XXX」占位，等爸爸拍板具体数字。B 档（按席位）当前最匹配律师 AI 业务定位，因为律师业务的核心是「团队积累」而不是「单点工具」。
三类工作目录
案件材料、工作成果、参考资料分开管理，109 项测试覆盖目录读写与路径解析， 避免文件串案——这是 AI 工具最容易出纰漏也最难被发现的地方。
民事业务完整生命周期 8 件套
覆盖诉前、一审、应诉、上诉、结案，外加两个通用工具。
一审 民事起诉状
原告启动诉讼。案由、诉讼请求、事实与理由、证据清单四段式结构，LLM 一次性输出完整 markdown 再渲染为 docx。
诉前 律师函
催告、通知、谈判、警告四类。必给期限 + 法律后果警告，保持律师中立立场，不替客户制造对抗情绪。
应诉 民事答辩状
8 大答辩策略：事实、法律、程序、同时履行、诉讼时效、反诉、抵销、免责。律师勾选适用策略后生成，避免漏掉程序性答辩。
上诉 民事上诉状
15 日判决 / 10 日裁定 / 30 日涉外三类期限提醒，4 大上诉理由，必引原审案号，避免程序瑕疵。
结案 调解协议
诉前、诉中、执行、行业四类。金额大写 + 银行账户以 @开户行@ 占位 + 律师见证字段必填。
刑事 刑事辩护词
无罪、罪轻、量刑、程序四组辩护意见。事实清楚、证据充分、法律适用完整论证，避免模板化辩护。
通用 案卷证据分析
IRAC 框架：Issue（问题）/ Rule（规则）/ Application（应用）/ Conclusion（结论）。关键证据自动摘要，卷宗长了也能快速定位争点。
通用 民间借贷法律依据
《民法典》第 667–680 条 + 司法解释 + 9 大最高法判例，附利息、担保、诉讼时效专项论证。
428 项真集成测试 · 7 套件 · 全部通过
不是 mock 单测。Electron 主进程真实启动 + IPC 真实调用 + 数据库真实读写。
tsc --noEmit 零错误，跑不过就不发版。
| 测试套件 | 项数 | 覆盖范围 |
|---|---|---|
| 工作目录套件 | 109 | 三类目录读写、路径解析 |
| 系统扫描套件 | 86 | Ollama 状态、端口冲突、权限、存储 |
| 虚拟姓名套件 | 67 | 脱敏字段、中文姓名生成 |
| 引导教程套件 | 51 | 首次启动、步骤完成度 |
| 对话面板套件 | 43 | ChatPanel、文书生成 |
| 云端大模型套件 | 20 | M3 provider、隐藏中转站 |
| 总计 | 376 | 100% 通过 |
| + 原 VPI 授权套件 52 项测试在内部仍跑（真实存在），公开页暂不列 —— 等 VIP 体系重设计 | ||
给律所决策者的完整说明
12 页 PDF 原文，网页版可直接读。覆盖行业痛点（效率瓶颈 / 成本压力 / 数据安全 / 知识流失）、核心价值主张、五大核心功能与五层技术架构、 双模部署与等保二级认证、四大应用场景、量化价值分析、服务模式与实施流程。
商务咨询：谭老师 16670313335
AI Agent MiniHub 项目说明文档（律所版）
湖南玖食天文化传媒有限公司出品。定位为律所采购决策的完整参考材料， 而不是营销页——每一个技术承诺都可以对照着问。
选型时最常被问到的
把案卷传给云端大模型，合规上到底算不算违规？
关键看传的是什么。JSTAI 默认在本地完成 OCR 和脱敏，云端只接触到已去除身份标识的文本。但责任主体仍是律师本人——委托关系下的保密义务、数据处理协议、律所内部合规要求，要由律师和律所自己确认，产品不能替你做决定。
AI 生成的文书，出了错责任在谁？
在律师。AI 只产出草稿，最终提交前律师必须人工审阅——这是执业规范的底线要求，任何 AI 产品都不能替代。JSTAI 的设计就是把这道人工关卡固定在流程里，而不是给一个「一键提交」的按钮。
律所内部资料涉密，能不能完全离线用？
可以。BYOK 架构支持自带 Key，也可配置为纯本地模型推理。案卷识别、脱敏、文书生成三条链路在离线环境下均可完成，只是需要本机具备相应算力。
和我已经在用的通用大模型助手有什么区别？
通用助手不知道你的办案偏好、不认得你的文书格式、也不会主动提醒诉讼时效。JSTAI 记的是律师的办案习惯——常用法条、律所信息、既往案件摘要，跨会话复用，不需要每次重新交代背景。
价格怎么算？
三个备选方案，等你拍板具体数字：
- A · 按账号 ¥XXX /年 /账号 —— 个人律师 / 单兵作战
- B · 按席位（推荐） ¥XXX /年 /席 —— 3-30 人中小律所 / 团队协作 + 知识沉淀
- C · 按案件量 ¥XX /件 —— 大量重复处理（合同审查 / 案件归档）
核心功能免费永久（含脱敏 / 准确性 / 印章落款 4 大区块 + 三类工作目录）； 上面三个方案是增值服务（升级响应 / 团队协作 / SLA）。
换电脑怎么办？
一键迁移。全部记忆、历史任务、设置、文书库、BYOK 配置打包导出，新机器导入即可继续用。团队协作也可以用同样方式把经验共享出去。