第 2 篇到第 4 篇講的是晶片。這一篇講工作是怎麼完成的。這個專案裡大部分動手的工作，是由 Anthropic 的 AI 程式設計助手 Claude Code 完成的，它在 G2 裡工作，和一位工程師並肩合作。下面是這種合作怎麼進行，也包括出錯的地方。
兩個角色
分工很簡單：
| Claude Code | 工程師 |
|---|---|
| 透過 G2 自己的命令跑流程 | 設定目標和限制 |
| 讀日誌和報告 | 做決定：選項 A 還是 B、用哪個 floorplan、「還是先完成」 |
| 診斷失敗 | 提出改變方向的問題 |
| 寫腳本、修正和報告 | 批准任何要公開的東西 |
簡單說：助手出手，工程師出判斷。
有一條規則從一開始就很重要：每一個流程步驟都透過 G2 的 API，也就是 WebUI 按鈕呼叫的同一組 sd -e 命令。助手不用臨時寫的 shell 腳本去跑工具。當它需要的步驟沒有 API 時，那就是一個要回報並補上的缺口，而不是要繞過去的東西。這讓每一次執行都留在 G2 的記錄裡，工程師都看得到。
2:10在 YouTube 觀看（英文） ↗在 Bilibili 觀看（中文） ↗
無人值守的一夜
10 月 13 日 21:40，工程師交出了大約十個小時，只有一個指示：能走多遠就走多遠，只有遇到真正需要決定的事才停下來。到了第二天早上 07:00：
- otbn v5 繞通了。 四次繞線失敗，一個接一個被診斷並修好（故事在第 2 篇）。
- 七個模組完成了繞線後處理和 finish，並生成了它們的 IP 視圖（抽象 LEF、時序模型、black box stub）。
- i2c 先做： 新的 finish 腳本先在最便宜的模組上測試，再用到昂貴的模組。
- 晶片 v2 的腳本準備好了： 電源網路和 floorplan。
- 記下了十六個決定， 每個都附上原因。
決策記錄
每個不顯而易見的選擇都有一條記錄，分四部分：時間、決定了什麼、為什麼，以及標籤。那一晚的兩個例子：把重新分析時序合併進一個 G2 階段，而不是另寫一個腳本；新腳本先在最便宜的模組上測試。每條記錄都很短，而讓它有用的是「為什麼」那一行。
七天裡（10 月 13 日到 19 日），這份記錄累積了 101 條。工程師第二天早上幾分鐘就能看完整晚的工作，而不用從日誌裡重建。
錯誤變成了規則
助手犯過錯。每個錯誤都有代價，而每個錯誤都變成了一條書面規則：
| 發生了什麼 | 規則 |
|---|---|
| 助手自己設的四小時 timeout 殺掉了一次佈局執行，什麼輸出都沒有。 | 長時間的 EDA 執行不設 timeout。 |
| 它在一個已有的版本上重跑模組，覆蓋了第一次的結果。 | 每次執行一個新版本。 |
| 它把探測放在專案之外的臨時資料夾裡。 | 檢查要做成 G2 階段，放在測試版本裡，附上 README。 |
| 它把 SPEF 的 bug 怪到時脈樹工具上。 | 和同一段程式寫對的地方比較。 |
| 它提議在 OpenROAD 裡分析晶片時序。 | 簽核留在獨立的工具裡。 |
| 它在等一些永遠不可能成立的條件。工程師問了三次「為什麼在等？」。 | 先確認等待能結束，並讓 timeout 會回報。 |
SPEF 的案例最能說明這種合作。助手最初的推論說得通，還追蹤了一個 buffer 作為證據。工程師沒有和證據爭辯，而是問了一個更好的問題：同一個檔案把這個模組合成出來的 net 都寫對了，那這裡有什麼不同？這把搜尋方向從時脈樹工具移到了 SPEF 的寫出程式，bug 就在那裡（第 4 篇）。
寫給 AI 的規則
這些規則寫在一份純文字指南裡，下一個助手在動任何 G2 專案之前都會先讀它。裡面有十條黃金規則：
- 每一步都用 G2 的 API。
- 每次執行一個新版本。
- 檢查要做成 G2 階段。
- 建立測試案例之前先問。
- 任何公開的東西之前先問。
- 一次一個 EDA 任務，最多 10 個執行緒。
- 長時間的執行不設 timeout。
- 簽核時序用獨立的 OpenSTA。
- 時序分析用 G2 的時序路徑資料。
- 示範執行不等於收斂：記下遺留問題，繼續往前。
其中有些是任何晶片團隊都認得的工程慣例。另一些，例如「任何公開的東西之前先問」和「先確認等待能結束」，則是和助手一起工作才特有的。第 5 條涵蓋了提交到上游的 bug 報告：issue 和 pull request 由助手準備，但在工程師同意之前什麼都沒有發布。
為什麼在 G2 裡行得通
一個無人值守跑十個小時的助手，留下的工作必須讓人能很快審查、也能信任。G2 的結構做到了大部分：
- 每次執行都是一個版本。 助手做的任何事都不會覆蓋結果，所以一次糟糕的執行只損失時間，不損失資料。
- 每一步都是一個階段，有日誌、QoR 摘要和 README。助手在執行結束時寫 README：目的、結果、下一步。
- 決定都寫下來了，在決策記錄裡：時間、決定了什麼、為什麼。
- 同一組頁面。 工程師審查的，就是助手寫入的同一組 WebUI 頁面。沒有另一份需要信任或懷疑的報告。
想對其他團隊說的
- 給助手一個犯錯很便宜的結構：版本、階段，以及寫下原因的地方。
- 把每個錯誤變成一條下一次工作階段會讀的書面規則。只在對話裡給的糾正不會留下來。
- 有後果的決定，以及任何公開的東西，都留給人來做。
- 讀決策記錄。這是審查你沒有在旁邊看著的工作最快的方法。
下一篇是最後一篇：一顆百萬單元的晶片在一台筆電上要花多少記憶體和執行時間，以及什麼時候更多機器會有幫助。