医疗事故原告律师在专家证人质询中，平均要盯3小时以上。他们真正在找的只有两样东西：可用于庭审的承认，以及能用来弹劾证人的矛盾点。但这两扇窗口每次只开几秒——错过了，一周后读笔录时只能拍大腿。
一个技术团队最近把这事儿自动化了。他们的系统盯着实时口供流，每30秒跑一轮分析，把信号直接弹到律师的笔记本上。
核心设计：一份JSON里的10个侦探
系统的输出是一份结构化JSON，把口供拆解成10个并行维度。没有花哨的可视化，就是纯数据流灌进律师的屏幕。
医疗准确性模块给证词打分，标出错误陈述和准确部分。多伯特标准（Daubert）模块评估专家证人资格的风险点——这是美国证据法里筛掉伪科学证词的关键门槛。
历史证词比对模块专门抓自相矛盾。交叉质询模块更直接：生成问题、标出弱点、推荐追问策略。
侵权四要素（责任、 breach、因果关系、损害）各自有推进状态追踪。承认检测和回避检测是两套独立的布尔判断——前者锁死可用于庭审的陈述，后者识别证人打太极的模式并给出升级追问的话术。
病历矛盾模块把证人说法和电子病历硬碰硬。文献检索模块实时生成PubMed查询，为质询准备学术依据。
最后还有个基础规则触发器，监控美国联邦证据规则的几条关键条款：613（弹劾用先前不一致陈述）、803(18)（学术出版物）、803(6)（业务记录）、702（专家证词）、30(b)(6)（组织质询）。
技术实现：单调用、大窗口、流式吐结果
代码层面很直白。每30秒片段触发一次Claude API调用，用的是haiku模型。一个细节很关键：max_tokens设到8192——团队发现4096会在交叉质询建议生成到一半时截断，直接废掉这模块的可用性。
提示词工程是隐形工作量。buildPrompt函数要塞进三段上下文：当前口供片段、案件背景、病历数据。输出经过JSON解析和清理，通过WebSocket推送到前端。
没有复杂的管道编排，没有多模型路由。就是单调用、重提示、大输出窗口。
踩过的三个坑
原文只提了"Three things we got wrong the first time"，没展开。但结合上下文能推断几个方向：token截断肯定是其中之一——4096到8192的调整说明早期版本有输出完整性问题。
病历交叉引用和协同律师通道是完整博客里才讲的内容，暗示系统最初可能是单机版，后来才加入多用户协作。JSON结构的迭代也花了时间——10个维度不是一开始就定好的，是需求倒逼出来的。
模型选择值得玩味。haiku是Claude系列里最快最便宜的，团队没上opus或sonnet。说明这个场景要的是实时性优先，深度推理可以牺牲——毕竟律师自己还在场，AI给信号，人做判断。
为什么选医疗事故这个切口
法律科技（LegalTech）喊了很多年，但大多落在合同审查、尽职调查这些文档密集型场景。庭审是另一回事：时间压力、对抗性、不可预测。
医疗事故又有特殊性。专家证人通常是对方律师花钱买的学术权威，质询的核心是拆解其可信度。这要求质询律师同时具备医学知识和诉讼技巧——而同时具备这两者的人极少，时薪极高。
系统的价值在于把医学事实核查和诉讼策略生成，从"需要两个人"变成"一个人+实时辅助"。不是替代律师，是把律师的注意力从"记笔记、翻资料"转移到"观察证人、即时反应"。
JSON结构的设计暴露了产品思维。没有搞什么"AI置信度评分"这种玄学指标，每个字段都是可行动的：有问题列表、有引用原文、有下一步建议。律师扫一眼就能决定要不要打断、追问、还是放过去。
流式API的真正战场
Claude的流式API（streaming API）在这个场景里不是炫技，是刚需。口供不等人，分析必须比证人说话快。30秒窗口是产品定义的选择——太短，上下文不够；太长，错过干预时机。
对比传统庭审准备：律师团队要提前研究专家证人的所有发表物、往期证词、学术立场。工作量以天计。实时系统把部分工作搬到庭审现场，用算力换时间。
但限制也很明显。系统依赖病历数据的提前录入，依赖案件背景的完整配置。它解决的是"现场反应"，不是"准备不足"。
PubMed实时查询是个聪明设计。专家证人被质询时经常随口引用研究，律师当场核实几乎不可能。系统把"我查一下"变成"我已查证"，时间差就是心理优势。
这事的奇怪之处
技术文档里没提准确率、没提客户反馈、没提是否真在庭审用过。只说了"我们建了"和"JSON长这样"。
这可能是个内部工具开源化的故事，也可能是个产品化前的技术验证。medicalai.law这个域名暗示团队有法律行业背景，不是纯技术外包。
更奇怪的是模型版本号：'claude-haiku-4-5-20251001'。Claude的公开版本命名不这么写，这可能是内部定制版本，或者作者笔误。如果是前者，说明Anthropic有面向垂直场景的模型微调服务——这本身是个信号。
代码片段的呈现方式（Enter fullscreen mode / Exit fullscreen mode）来自Dev.to或类似技术社区。原文是技术博客，不是产品发布会。这意味着我们看到的可能是半成品炫耀，不是成熟方案推销。
对AI应用设计的启示
这个案例戳破了一个常见幻觉：AI替代专业工作。实际发生的是AI拆解专业工作，把其中可自动化的环节抽出来，让人专注不可替代的部分。
律师的核心价值不是"发现矛盾"——这是模式识别，机器能干。核心价值是"决定怎么利用这个矛盾"：当场戳破还是留到结辩？单独追问还是配合其他证人？这些判断需要案件全局、对手风格、陪审团构成的综合考量。
JSON结构的10个维度，本质是把"庭审质询"这个黑箱任务，拆解成可并行计算的子任务。每个子任务输出结构化结果，供人快速消费。这是AI辅助系统的通用设计模式：不是给答案，是给选项；不是替决策，是压缩决策时间。
实时性要求倒逼了架构简化。没有RAG（检索增强生成）、没有多轮对话、没有 agent 编排。就是单提示、大输出、流式推。复杂度的控制本身是种产品能力。
最后留个疑问：这个系统如果对面也用怎么办？双方律师都配实时分析，质询会变成什么形态？是算力军备竞赛，还是倒逼出新的庭审规则？美国证据法里的" surprise "原则（禁止诉讼突袭）会怎么适用？
热门跟贴