前言

昨天把 Spec Kit 裝起來、寫完憲法，今天讓它從一句話長出一份規格。

昨天提到，Spec Kit 的價值不只是幫我們產生 Spec，而是把一套 Spec-Driven 的流程直接放進 Claude Code。

但如果只給 Claude 一個很模糊的需求，它到底會問什麼？又會自己決定什麼？

所以今天不看文件，直接跑一次。

昨天說到

昨天走完 Spec Kit 的安裝流程，也看了一下它實際放進 Repository 裡的內容。

其中最重要的，是 .specify/memory/constitution.md，我在裡面寫了一份 187 行的專案憲法，還刻意放了兩個「探針」：

1. API 欄位一律使用 snake_case：因為 TypeScript 前端常見的是 camelCase，所以我想看看它會不會真的遵守。
2. 認證必須自己實作：我想看看做到登入時，它會不會直接建議 OAuth、Firebase 之類的第三方方案。

今天就拿登入功能來做測試，看看這些規則到底有沒有真的進入後面的開發流程。

拿「登入」跑完一輪

我給 /speckit-specify 的內容其實很短：

/speckit-specify 使用者用 email 與密碼登入，登入成功後取得一組 session，可以登出。
密碼連續輸入錯誤三次要鎖定帳號十五分鐘。

刻意沒有把所有細節都寫清楚，想測試它會不會反問我：

1. 鎖定是算帳號還是算來源 IP
2. session 多久過期
3. 要不要做密碼重設

它問的，不是我以為的那些

上述提到的三個問題，claude 都直接做了決定，然後把這些決定寫進 Spec 裡的 ## Assumptions，這樣下一次回頭看的時候，可以知道這些不是原始需求，而是當時的假設：

1. 帳號鎖定以帳號為單位，不區分 IP
2. Session 使用 24 小時絕對期限
3. 註冊與密碼重設不在本次範圍

而它提的問題是我之前沒預想到的：

帳號被鎖定時，要不要直接告知使用者「已鎖定，以及剩餘 N 分鐘」？

乍看之下，這好像只是 UX 問題，但其實是設計上的衝突：

如果直接告訴使用者「這個帳號已經被鎖定」，可能會讓攻擊者確認這個 email 真的存在，但前面另一條需求 FR-004 又規定：回應不能區分「email 不存在」與「密碼錯誤」。

兩條需求撞在一起了，Claude 是在產生 Spec 的過程中，自己把這個衝突抓了出來。

這也是我覺得 Spec-Driven 很有意思的地方：

它不只是把我講的話整理成文件，也會開始檢查不同需求之間是不是互相矛盾。

提問的標準

我反過來問 Claude 它提問的標準，而它的回答是：看業界有沒有慣例可以當成預設；像是我原先預設它會問我的那三題，就是參考業界的做法後，自己做了決定。

另外還有一個更有意思的地方，我原本需求寫：錯誤三次要鎖定帳號，想描述的是想達成的效果，不是我決定好的實作方式，但 Claude 把「帳號」過度解讀成「帳號層級計數」。

這也讓我重新意識到：

需求裡的「效果」和「實作」最好分開寫。

不然 AI 很容易把我們描述的結果，直接當成我們指定的技術方案。

/speckit-plan

接著我把這份 Spec 交給 /speckit-plan，我原本埋的兩個探針全部通過，而且比我預期的還完整。

snake_case

它不只是把 API 欄位命名成 snake_case，還進一步限制：

• 不使用 alias
• 不使用 by_alias
• 不透過 response middleware 轉成 camelCase

也就是說，它不只是「記得這條規則」，而是開始思考：

camelCase 可能從哪裡偷偷跑進來？

自建認證

Plan 裡使用的是：

• argon2-cffi
• Python 標準庫

沒有加入 OAuth、OIDC、SAML 等第三方認證方案，並且它在說明這個決定時，引用的不是我這次的 Prompt，而是三個步驟以前寫在憲法裡的規則，這其實就是我在 D03 一直想解決的問題：

Spec 要成為 AI 可以持續取得的 Context。

小結

• 我刻意埋了三個問題，Spec Kit 沒有直接問，而是把答案放進 Assumptions。
• 它真正停下來問的，反而是我沒想到的需求衝突。
• 兩根探針都通過了，代表規格確實進入了後面的工作流程。

Spec Kit 可以幫我建立 Spec-Driven 的骨架，但不一定會完全符合我的開發方式。

接下來，就輪到我開始把自己的 SOP 加進來。

明天：如果我想把團隊自己的 SOP 變成 Claude 可以執行的規則，該怎麼做？