所有節目›AI Engineer Europe 2026World's Fair 2026World's Fair 線上軌AI in HealthcareSoftware Factories
BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike在 YouTube 看這一場

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 照規則走。

關卡與 harness看原片 ↗

概要

  • 人和 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。

原話

  • “One thing harder than reading an AI code is reading AI tests.”

    比讀 AI 寫的程式更難的,是讀 AI 寫的測試

    ▶ 04:28
  • “because there is no space for discussion about these anymore”

    因為這些事已經沒有討論的空間了,風格與格式都是自動執行的規則

    ▶ 08:32
  • “You cannot keep finding them. You need to prevent them entirely.”

    不能一直找問題,要徹底防止它發生

    ▶ 09:28
  • “I have no fear of context compacts”

    我不怕 context compact

    ▶ 11:13
  • “So may the spec be with you.”

    願規格與你同在

    ▶ 12:16

延伸

  • Michal 曾在 Microsoft、Red Hat 工作,也花了十年做同一個產品,這些筆記就是從那段經驗整理出來的。
  • ADR 也會寫明涵蓋哪些檔案或資料夾;工具擋下 agent 時會告訴它違反哪條規則、為什麼、該怎麼修,agent 再回頭去找那份文件。
  • PRD 不只寫給 agent 看,也是寫給六週後忘了當初為什麼這樣做的自己。
  • Michal 說這套 loop 用了大約半年,一個 session 裡會有 20 到 50 次 context compact。

章節

點時碼直接跳到原片的那一段。

  1. 開場Michal 自我介紹,說明這場要談的是怎麼把決策記下來,讓人和 AI 都查得到。
  2. 猴子的故事用五隻猴子與梯子的故事說明,人和 LLM 一樣有脈絡限制,後來的成員不知道規矩的原因。
  3. ADRADR 記錄為什麼這樣做與如何強制執行,並用分層避免 n plus one queries 當例子。
  4. PRDPRD 是比較輕的文件,只要寫下為什麼、問題、目標和連起兩者的使用者流程。
  5. 規格驅動的缺口spec-driven development 寫完規格後,很難驗證產品真的照規格運作,而 AI 寫的測試又更難讀。
  6. BDD 與 Cucumber用 Cucumber 寫人話的場景,可以執行也容易審查,並能連回 PRD 和關鍵使用流程。
  7. 設計系統把按鈕等元件的樣子與使用規則寫下來,做成元件與預覽,再由小到大組合重用。
  8. 用 loop 強制執行文件本身不會自動被遵守,他們靠 loop 提醒 agent 有哪些規則。
  9. Git hooks 與 CIagent 要交 pull request 就得用 git,hooks 與 CI 跑同一批檢查,跳過會被抓到。
  10. 把問題擋在源頭以限制模組 import 為例,讓 BDD 測試只能走瀏覽器功能,並徹底防止 n plus one queries。
  11. 同一個 loop 換焦點針對 ADR、PRD、UI 設計不同 skill,UI 時跳過部分檢查、只跑受影響的測試。
  12. 代價與結語這套做法很吃 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 目前任職的公司

相關影片 同屬「關卡與 harness」