前十天講的都是方法跟工具，今天開始進入實作。首先要介紹這次實作的系統：要做什麼、核心的三個部分是什麼、哪些功能會實作。

昨天說到

昨天講完 MCP，Act 2 就結束了，前面十天談的都是方法與工具：

• AI-DLC：怎麼讓 AI 參與開發流程
• Spec-Driven Development：為什麼要先有規格
• Claude Code：怎麼讓 AI 進入實際開發環境
• Command / Skill：怎麼把 SOP 變成可以重複使用的指令
• Hook：怎麼把規則變成真正的執行門檻
• MCP：怎麼讓 AI 取得外部資訊

但這些東西都還沒有一個真正的實作對象，所以從今天開始，換一個方向：

先把系統定義清楚，再讓 AI 開始做。

這個系統要做什麼

這次要做的是一個會議紀錄的版本控管與簽核工具，完整流程一句話講完：

建立會議與與會者 → 撰寫記錄 → 送出產生版本 → 與會者逐一確認或退回 → 全員確認才生效 → 決議項指派給負責人 → 全程留下稽核軌跡

它要解決的是一個很常見的狀況：會議記錄發出去之後，有人說「這段我沒同意」，但沒有人說得出來當時發出去的到底是哪一版、誰看過、誰改了什麼。

所以這個系統真正要管理的，不只是「會議記錄」，而是一份記錄從產生、修改、確認，到最後生效的完整過程。

核心的三個部分

後面的規格與實作，大多圍繞以下這三個部分：

一、版本控管

最基本的規則是：記錄一旦送出就凍結，任何人都不能改。要修正只能開新版本，舊版本永遠留著。

麻煩的地方在於，「編輯」這個動作會隨著狀態改變。

如果目前還是草稿：編輯 = 修改原本這一筆資料，但如果已經送出，甚至已經全員確認：編輯 = 建立一個新的版本；也就是說，同一個「編輯」按鈕，背後其實可能是兩種完全不同的行為。

二、簽核流

簽核規則目前先定為：全員確認才生效，任何一個人退回就回到草稿。

但這兩句話沒有回答的問題還有一堆：

• 退回之後，已經確認過的人怎麼算？
• 開新版本時，與會者名單變了怎麼辦？
• 一個人可以改變主意嗎？

三、稽核軌跡

紀錄：誰、在什麼時候、把什麼改成什麼。

看起來只是多一張 audit log，但實際上它會反過來影響資料模型的設計。

例如：

• 紀錄刪除要用軟刪除還是硬刪除？
• 稽核資料要不要跟主資料建立外鍵？
• 舊版本被刪除時，稽核紀錄還能不能保留？

這部分會在 D15 的資料模型那天再詳細處理。

預計要達成的功能

六項功能

小結

• 今天簡單介紹實作的對象：一個會議紀錄的版本控管與簽核工具。
• 整個系統的核心不是 CRUD，而是：版本控管、簽核流、稽核軌跡。
• 今天先定義的是產品範圍與核心規則，下一步才是把這些規則正式寫成規格。

明天：這是一個全新的專案，沒有既有程式碼可以讓 AI 先讀懂。AI-DLC 的第一步也因此要反過來做——不是先讀懂慣例，而是先把慣例定下來。