程式碼與法庭交會之處：站在法律與技術前沿的 AI（第 3/3 段）

🧑‍🏫 這一段是 Solve 團隊實際操作他們的專利撰寫工具，示範做「人和 AI 一起工作」的產品時要守的三個原則：把過程攤開給人看、常做的工作要有專屬畫面、先集中對齊再放手執行。就算你不寫專利，這套思路也能直接拿來改善你平常用 AI 的方式，尤其適合那些不能整包丟給 AI 就不管的工作。

• 21:30 原則一的模式：系統要用推理（reasoning）和引用（citations）呈現自己的工作過程。
  ↳ 原則一：AI 不能只丟結論，要把「怎麼想的」（reasoning，推理過程）和「根據哪裡」（citations，附上出處）一起攤開，讓人能逐一檢查。
• 21:30 採用這個做法後，通用 agent 的能力越強，各項特定能力的表現也會跟著提升。
  ↳ 各種專門功能底下都是同一個通用 agent（能自己規劃、動手做事的 AI 助手）。所以只要底層 agent 變強，上面每個功能都會一起進步。
• 21:30 最後一個原則的出發點：一般來說，要完成的工作沒辦法靠一次長時間的自主執行做完。
  ↳ 最後一個原則的出發點很務實：真實工作通常沒辦法「交代一次，讓 AI 自己跑很久就全部做完」，中間一定需要人介入。
• 22:06 所以最好主動找出一組關鍵決策，在一個集中的時刻請使用者用人的判斷簽核，之後就能讓 AI 長時間自主執行。
  ↳ 與其讓 AI 三不五時跑來問，不如先挑出真正需要人拍板的幾個決定，一次集中請使用者確認。確認完，就能放手讓 AI 長時間自己做。
• 22:06 這些決策需要的前置分析或研究通常可以平行進行，原則的名稱就是從這裡來的。
  ↳ 做這些決定之前要先分析、查資料，這些工作多半互不相干，可以同時開工。原則名稱裡的「平行化」就是指這件事。
• 22:37 目標是同時減少和使用者的接觸次數，以及每兩次接觸之間要花的時間。
  ↳ 目標有兩個：少打擾使用者幾次，還有使用者每次回來確認之間，不用乾等太久。
• 22:37 Solve 平台有涵蓋專利生命週期各階段的模組：drafting、prosecution、litigation。這次示範聚焦在 patent drafting 模組。
  ↳ Solve 的模組涵蓋專利的各個階段：drafting（撰寫申請書）、prosecution（跟專利局往返答辯審查）、litigation（專利訴訟）。這次只示範撰寫。
• 23:10 示範專案：律師要為某種 circuit breaker 撰寫專利，已上傳發明人寄來的原始揭露文件。
  ↳ 示範情境：律師要替一種 circuit breaker（斷路器，電流異常時會自動斷電的裝置）寫專利，已經先上傳發明人寄來的原始說明文件。
• 23:44 專案裡還有發明人填寫的發明揭露表，以及律師引入的相關 prior art（講者說可能是用平台的搜尋功能找的）。
  ↳ 專案裡還有發明人填的發明揭露表，以及律師找來的 prior art（先前技術，就是已經存在的相關文獻）。講者說可能是用平台的搜尋功能找的。
• 23:44 專利申請書是用預設範本建立的。使用者常會自訂範本，把自己希望各章節怎麼寫的方式寫進去。
  ↳ 申請書是用預設的 template（範本）建出來的。很多使用者會自己改範本，把「每一章我習慣怎麼寫」先寫進去，等於事先把寫作規矩交代好。
• 24:18 畫面右側的通用 agent 可以拿來做分析或編輯，能引入專利文獻、非專利文獻、技術標準等資訊來源。
  ↳ 畫面右邊的通用 agent 是萬用助手，可以做分析也可以改稿，還能拉進專利文獻、非專利文獻（例如論文）、技術標準等資料來參考。
• 24:51 講者問 agent「我的發明和 prior art 相比如何」。agent 先讀發明揭露，再讀 prior art 文件，然後才回覆分析。
  ↳ 講者問 agent：「我的發明跟 prior art 比起來怎樣？」agent 沒有直接回答，而是先讀發明說明，再讀每份 prior art，看完才給出分析。
• 24:51 agent 的回覆先描述發明，再用表格把發明揭露和每份 prior art 逐一比較，最後指出其中一份 prior art 最相關。
  ↳ 回覆很有條理：先說明發明是什麼，再用表格拿發明和每份 prior art 逐項對照，最後點出哪一份最接近、最需要注意。
• 25:26 回覆附有引用，可以點進去確認內容正確。引用空間內的文件時會直接顯示預覽。
  ↳ 每個說法都附出處，點下去就能確認 AI 有沒有亂講。如果引用的是專案裡的文件，會直接跳出預覽。
• 25:26 引用 prior art PDF 時，可以看到分析精確依據了文件的哪些段落。以上示範的是原則一。
  ↳ 引用 prior art 的 PDF 時，能看到 AI 是根據哪幾段下判斷的。這整段示範的就是原則一：把推理和證據攤在使用者眼前。
• 25:58 原則二：針對特定、會重複進行的工作流程，有時要提供專屬介面，例如撰寫 claims。
  ↳ 原則二：有些工作很固定、又常常重複做，光靠聊天框不夠，要做專屬的操作畫面。撰寫 claims 就是一個例子。
• 25:58 客戶對 claims 常有各種偏好，例如要寫幾項、元素怎麼縮排、怎麼引用元素標號。
  ↳ claims（請求項）是申請書裡劃定保護範圍的核心章節。客戶對它的規矩很多：要寫幾項、元素怎麼縮排、元素編號怎麼引用。
• 26:32 客戶也可能在個人 library 裡存有撰寫 claims 的一般指引，或對這個專案的特別要求。
  ↳ 客戶也可能在個人 library（自己的資料庫）存了撰寫 claims 的一般指引，或是這個案子的特別要求，都能一起帶進來用。
• 26:32 使用者雖然是透過專屬介面設定需求，背後用的仍是同一套程式碼、同一個會展示推理與引用的通用 agent，而且它能直接起草該章節。
  ↳ 雖然使用者是在專屬畫面上做設定，背後跑的還是同一個通用 agent、同一套程式。它一樣會展示推理和出處，而且能直接把整個章節寫出來。
• 27:08 agent 會試著找出發明中具新穎性的部分，再圍繞這部分起草 claims。結果可以接受或拒絕，示範中講者選擇拒絕。
  ↳ agent 會先找出這項發明「新在哪裡」（新穎性，專利能不能成立的關鍵），再圍繞這一點寫 claims。寫完由人決定收不收，示範中講者選擇拒絕。
• 27:08 原則三「平行化對齊、依序執行」在產品中的例子是 application review（申請書審查）。講者改用一份已完成起草的專案副本來示範。
  ↳ 原則三叫「平行化對齊、依序執行」，產品裡的例子是 application review（申請書寫完後的審查）。講者換成一份已經寫好的專案來示範。
• 27:41 審查的目的是讓申請書符合律師認為重要的一組準則。示範用了四個平台推薦的準則。
  ↳ 審查就是拿一組律師在意的檢查標準，一條一條對照申請書。示範時用了平台推薦的四條標準。
• 27:41 實務上準則通常多得多，而且多半是使用者自己設定的，不是平台提供的。
  ↳ 實際上標準通常多很多，而且大多是律師自己訂的，不是平台給的現成清單。
• 28:13 系統會針對每個準則分別做子審查，而且同時平行進行。
  ↳ 每條標準各自跑一次 sub-review（子審查，只針對單一標準做檢查），而且全部同時進行，不用排隊等。
• 28:13 如果各子審查直接產出律師最終要的修改，建議之間會互相衝突，所以第一步是先產生 comments。
  ↳ 如果每個子審查都直接動手改稿，改法會互相打架。所以第一步不直接改，而是先留 comments（註解意見）。
• 28:47 範例 comment 指出「corresponds to」這個說法可能有歧義，例如可能被理解成「等於」。
  ↳ 例如有一則 comment 指出「corresponds to」（對應於）這種寫法有歧義，可能被理解成「等於」。法律文件用字一模糊，就容易出問題。
• 28:47 律師可以回覆 comment，不同意的可以駁回。之後才啟動 agent，只處理雙方已經對齊的 comments。
  ↳ 律師可以逐則回覆，不同意的直接駁回。等雙方意見對齊了，才讓 agent 動手，而且只處理已經同意的那些 comments。
• 29:17 建立這個對齊點後，審查中大部分的分析工作都能平行化。實務上可能有 30 個審查準則，全部都能平行跑。
  ↳ 有了這個「先對齊」的關卡，審查中大部分分析都能同時跑。實務上可能有 30 條標準，也能全部一起平行進行。
• 29:17 平行分析之後，再進入依序修改的階段，逐一處理，確保所有修改都已對齊而且前後一致。
  ↳ 分析完才進入修改，而修改是一條一條照順序做，確保每處改動都是雙方同意過的，而且前後文互相一致。
• 29:50 修改完成後，可能從 30 多個 comments 收斂到只剩一個。準則越多，comments 就越多，這也是先對齊很重要的原因。
  ↳ 修改完成後，30 多則 comments 可能只剩一則。標準越多，意見就越多，不先對齊的話，後面的修改很容易互相衝突。
• 29:50 原則三是疊加在原則一、二之上：審查也是一項特定能力，同樣由通用 agent 完成。
  ↳ 原則三不是另起爐灶，而是疊在前兩個原則上面：審查本身也是一項專門功能，背後一樣是那個通用 agent。
• 30:20 做法是給通用 agent 加上一個能留 comment 的工具，並且同樣提供引用，讓使用者看到它依據了哪些資訊。
  ↳ 具體做法是幫通用 agent 多加一個「留 comment」的工具。留言一樣附出處，讓使用者知道它是根據哪些資訊提出意見的。
• 30:52 審查完成後，agent 會說明它做了哪些修改，並引用文件中和修改保持一致的相關段落。
  ↳ 審查結束後，agent 會說明自己改了哪些地方，並引用文件中相關的段落，讓你確認改完之後前後說法還是一致的。
• 30:52 總結一：要做出對使用者真正有價值的應用，需要找到 AI 派得上用場、而且應用層能實質加值的領域。
  ↳ 總結一：要做出真正有用的 AI 應用，得挑 AI 幫得上忙、而且你在 AI 上面做的那層產品能實質加值的領域，不是只做 AI 的外殼。
• 31:22 總結二：不適合「委派模式」的領域特別有機會。不適合的原因有很多種，講者在演講中探討了其中幾種。
  ↳ 總結二：沒辦法「丟給 AI 就不管」的領域反而最有機會。做不到的原因有很多種，這場演講談了其中幾種。
• 31:22 總結三：使用者如果是和 AI 協作而不只是委派，就要仔細設計如何提供協作所需的可讀性（legibility）和控制權，UI/UX 層和底層 AI 層都要顧到。
  ↳ 總結三：人和 AI 協作時，要讓人看得懂 AI 在做什麼（legibility，可讀性），也要讓人能插手掌控。畫面設計和底層 AI 這兩層都要顧到。

在 application review 示範中，為什麼系統不讓各子審查直接產出修改，而是先產生 comments？