AI Engineer Europe 2026 · 演講 · 2026-06-03 · 13 分
用文件與 loop 守住決策
BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike · Michal Cichra,Safe Intelligence
Michal 說人和 LLM 都會忘記當初為什麼這樣做,所以用 ADR、PRD、BDD 與設計系統把決策寫下來,再靠 git hooks 和 CI 的 loop 讓 agent 照規則走。
概要
- 人和 LLM 都有脈絡限制Michal 用猴子與香蕉的故事開場,說人會離職、LLM 沒有記憶,團隊久了就沒人答得出某個流程或程式碼為什麼長這樣。
- ADR 記下決定與執行方式ADR 寫的是為什麼這樣做、怎麼強制執行。Michal 舉的例子是程式碼分層來避免 n plus one queries,並用 lint 檢查 import;他們有大約 50 份 ADR。
- PRD 和 BDD 補上產品面PRD 寫一個功能為什麼存在、解決什麼問題、使用者怎麼走完流程,可以很輕。BDD 用 Cucumber 寫成人看得懂又能執行的場景,補上 spec-driven development 沒解決的驗證問題。
- 設計系統讓 UI 一致先把元件的語言與規則寫下來,例如同一頁只能有一個 primary button,再用元件、預覽和規則檢查來確保 agent 做出來的畫面一致。
- 用 loop 把規則變成強制的git hooks 與 CI 跑同一批檢查,agent 要交 pull request 就得通過;被擋下時會連到對應文件,讓它讀完再修。
- 代價是很吃脈絡這套做法會用掉大量 context,但 Michal 說重要的東西會留下來、agent 會重新查,所以不怕 context compact。
原話
▶ 04:28“One thing harder than reading an AI code is reading AI tests.”
比讀 AI 寫的程式更難的,是讀 AI 寫的測試
▶ 08:32“because there is no space for discussion about these anymore”
因為這些事已經沒有討論的空間了,風格與格式都是自動執行的規則
▶ 09:28“You cannot keep finding them. You need to prevent them entirely.”
不能一直找問題,要徹底防止它發生
▶ 11:13“I have no fear of context compacts”
我不怕 context compact
▶ 12:16“So may the spec be with you.”
願規格與你同在
延伸
- Michal 曾在 Microsoft、Red Hat 工作,也花了十年做同一個產品,這些筆記就是從那段經驗整理出來的。
- ADR 也會寫明涵蓋哪些檔案或資料夾;工具擋下 agent 時會告訴它違反哪條規則、為什麼、該怎麼修,agent 再回頭去找那份文件。
- PRD 不只寫給 agent 看,也是寫給六週後忘了當初為什麼這樣做的自己。
- Michal 說這套 loop 用了大約半年,一個 session 裡會有 20 到 50 次 context compact。
章節
點時碼直接跳到原片的那一段。
- 開場Michal 自我介紹,說明這場要談的是怎麼把決策記下來,讓人和 AI 都查得到。
- 猴子的故事用五隻猴子與梯子的故事說明,人和 LLM 一樣有脈絡限制,後來的成員不知道規矩的原因。
- ADRADR 記錄為什麼這樣做與如何強制執行,並用分層避免 n plus one queries 當例子。
- PRDPRD 是比較輕的文件,只要寫下為什麼、問題、目標和連起兩者的使用者流程。
- 規格驅動的缺口spec-driven development 寫完規格後,很難驗證產品真的照規格運作,而 AI 寫的測試又更難讀。
- BDD 與 Cucumber用 Cucumber 寫人話的場景,可以執行也容易審查,並能連回 PRD 和關鍵使用流程。
- 設計系統把按鈕等元件的樣子與使用規則寫下來,做成元件與預覽,再由小到大組合重用。
- 用 loop 強制執行文件本身不會自動被遵守,他們靠 loop 提醒 agent 有哪些規則。
- Git hooks 與 CIagent 要交 pull request 就得用 git,hooks 與 CI 跑同一批檢查,跳過會被抓到。
- 把問題擋在源頭以限制模組 import 為例,讓 BDD 測試只能走瀏覽器功能,並徹底防止 n plus one queries。
- 同一個 loop 換焦點針對 ADR、PRD、UI 設計不同 skill,UI 時跳過部分檢查、只跑受影響的測試。
- 代價與結語這套做法很吃 context,但重要資訊會留下,agent 能做長時間、目標明確的自主工作。
名詞
- ADR
- Architecture Decision Record,記錄為什麼這樣做、怎麼強制執行的架構決策文件
- PRD
- Product Requirements Document,Michal 說可以很輕,只寫為什麼、問題、目標和使用者流程
- BDD
- Behavior-Driven Development,用人話描述產品行為,並能直接執行成測試
- Cucumber
- Michal 拿來寫可執行場景的 BDD 工具,場景再由 steps 解析成程式執行
- spec-driven development
- 先寫 Markdown 規格再開發的做法,Michal 認為它缺少驗證產品是否照規格運作的一環
- n plus one queries
- Michal 用來示範 ADR 的問題,他們靠分層與 import 檢查徹底防止
- Git hooks
- 在 commit 與 push 時跑 lint、格式、型別檢查等任務,CI 上跑同一批
- Safe Intelligence
- Michal 目前任職的公司








