前言

慣例定下來了，接下來要把「我想做什麼」變成一份 AI 能執行的規格。但我不打算自己寫，而是讓 AI 當訪談者。

昨天說到

昨天把三塊規範補進了 CLAUDE.md：協作規則、不可違反的業務規則、什麼算做完。

那些管的是「不管做什麼功能都要遵守的事」，但真正要開始寫程式之前還缺功能的規劃。

以往都是我們寫需求文件，由 AI 幫我們檢查文件內容，但規格出問題的地方，向來不是我想到卻寫錯，而是沒規劃到的漏洞。

所以這次換個方式：讓 claude 來問我。

訪談怎麼設計

前幾天用 Spec Kit 的時候，/speckit-specify 就是一個訪談者。

那次實作的結論：

• 我刻意留的三個問題它一個都沒問（全自己決定，寫進 Assumptions）
• 它的判斷標準是「有沒有業界慣例」而不是「後果多嚴重」
• 問題如果一題一題問很沒效率

所以這次開場做了三件事：

• 限定範圍（只訪談「記錄撰寫 → 送出產生版本」這一個功能）
• 明確換掉判斷標準
• 要求一次列完問題

我要做「記錄撰寫 → 送出產生版本」這個功能。已知的規則寫在 CLAUDE.md 的
「不可違反的業務規則」那一節。

請先不要寫規格。先把你需要我決定、但目前無法從現有資訊推斷的問題**一次列完**，
每一題附上：
- 你會採用的預設值
- 猜錯的話最壞會發生什麼

判準用「猜錯的後果」，不要用「業界有沒有慣例」——後果嚴重的即使有慣例也要問。

驗收條件：寫成 EARS

訪談完會得到一批 User Story，但 User Story 本身太鬆——「身為與會者，我希望能確認記錄」沒辦法拿來驗收。所以驗收條件我要求用 EARS（Easy Approach to Requirements Syntax）的事件驅動句型：

When 使用者對一份已送出的記錄按下編輯,
the system shall 建立一個新版本，而不是修改原版本。

跟「送出後不可編輯」比起來，多了明確的觸發時機和明確的系統行為，而這兩樣正好就是測試的 when 和 then。

EARS 真正的作用是讓每一條驗收條件都寫得出一條測試。

實作

claude 的訪談

claude 回答的問題分成兩類：

• A 類：猜錯要改資料模型，或等於違反「不可違反的業務規則」
• B 類：猜錯要重寫程式，但資料救得回來

第一輪

第一輪它列的第一題指出我自己寫的規則互相矛盾，而 claude 並沒有直接幫我改規則內容，而是讓我做選擇。

照 CLAUDE.md，這功能會動到超過三個檔案，實作前我會先把要改哪些檔案列給你確認。

CLAUDE.md 確實在運作：協作規則第一條被主動遵守了，沒人提醒它。

第二輪

上一輪的第一個矛盾是兩條規範互相打架，我改完規則，它重讀之後又列了 6 題，其中一題是規範撞上既有的實作決定。

兩邊文件分開看都沒錯，但放在一起才發現規則相互矛盾。

結果

規格最後整理出決策來源對照表，每列標明是「你的決定」「我的預設，你同意」還是「CLAUDE.md 既有約束」。

之前 Spec Kit 那輪測試，把 claude 自己決定的事丟進 Assumptions，但沒紀錄哪些是它決定的，而現在每一條都查得到出處。

踩到的坑：寫得出檢查 ≠ 彼此不矛盾

昨天那篇的結論是「只放寫得出檢查的條款」，那三條規則也確實都寫得出檢查。問題是三條檢查各自獨立，沒有檢查到相互矛盾的部分。

所以判準要再加一句：

每一條都寫得出檢查之後，還要問：這些檢查有沒有可能同時成立？

這件事我自己做不到，因為寫規則和檢查規則的我用的是同一組假設，要發現矛盾，得有一個不共用那些假設的人去試著實作它 —— claude。

小結

• **規格真正的缺口不是寫錯，是沒想到還有漏洞沒有被規劃。**所以這次讓 claude 當訪談者，讓它對我進行提問。
• 把判準換成「猜錯的後果有多嚴重」之後，claude 第一個回覆就指出我昨天寫的規則互相矛盾。
• 寫得出檢查 ≠ 彼此不矛盾。

明天：這份規格 323 行，把「要做什麼」「怎麼做」「怎麼知道做對了」全寫在同一個檔案裡，明天要依照規格內容拆成不同檔案。