庭審律師的30秒窗口：實時口供分析系統揭秘

醫療事故原告律師在專家證人質詢中，平均要盯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 "原則（禁止訴訟突襲）會怎么適用？