AI 寫程式碼已經又快又便宜,真正的瓶頸移到了前面:需求到底寫得夠不夠清楚,清楚到 AI 不用猜。
業界這一年收斂出來的解法叫 Spec-Driven Development(SDD):先把需求、user story、驗收條件(AC)寫成結構化文件,再讓 AI 依規格實作。但如果每次都要貼一大段 prompt 來交代方法論,不但累,團隊裡每個人貼的版本還會不一樣。
更好的做法是:把方法論封裝成 Skill,把角色封裝成 Agent,一次打造、重複使用。
判斷準則很簡單:
- Skill 封裝「方法論」——人還在迴圈裡,skill 提供做事的章法。適合需求訪談、拆 story、寫 AC 這些人必須逐輪參與決策的上游工作。
- Agent 封裝「角色」——它有自己的乾淨 context,自主跑完一段工作,交出可驗證的產出。適合對抗性審查、依 AC 實作這些依既定判準自主執行的下游工作。
規律是:上游偏 skill(價值在逼出人類決策),下游偏 agent(價值在自主執行,人只驗收結果)。
圖 1:Skill 與 Agent 的判斷分流
這篇文章分三部分:第一部分打造四個 skill 和兩個 agent;第二部分用它們把台灣高鐵訂票系統從需求一路做到實作;第三部分帶你實際修改一次 skill 和一次 agent,並逐層驗證更新真的生效——因為環境會變、模型會換代,工具箱不是打造一次就完工的。所有內容都可以直接複製貼上,照著做就能完成。
第一部分:打造你的 Skill 與 Agent 工具箱
事前準備
你需要安裝好 Claude Code。打開終端機:
mkdir thsr-booking && cd thsr-booking
mkdir -p specs .claude/skills .claude/agents
claude
完成後的目錄結構會是:
thsr-booking/
├── specs/ # 規格文件(第二部分產出)
└── .claude/
├── skills/
│ ├── req-interview/SKILL.md # Skill 1:需求訪談
│ ├── story-splitting/SKILL.md # Skill 2:拆解 story
│ ├── ears-ac/SKILL.md # Skill 3:EARS 格式 AC
│ └── sbe-examples/SKILL.md # Skill 4:例子問答
└── agents/
├── spec-reviewer.md # Agent 1:對抗性審查者
└── tdd-developer.md # Agent 2:測試先行開發者
建立方式很簡單:把下面每一節的內容直接貼給 Claude Code,請它建立對應檔案。例如:
請建立 .claude/skills/req-interview/SKILL.md,內容如下:
(貼上 Skill 1 的完整內容)
六個檔案依序建完,工具箱就好了。
Skill 1:需求訪談(req-interview)
為什麼是 skill 不是 agent: 訪談的提問協議可以封裝,但回答問題的人不可取代。做成全自主 agent 等於讓 AI 自問自答,把「AI 猜測」重新包裝成「AI 決策」,整個流程的價值就被掏空了。
—
name: req-interview
description: 以結構化訪談方式整理軟體需求。當使用者想開發
新系統、整理需求、或說「訪談我」時使用。禁止在訪談前
直接產出需求文件。
—
# 需求訪談協議
## 鐵律
先不要寫任何需求文件。用訪談方式釐清需求,
每一輪只問 3~5 個問題。
## 訪談順序(前一面向釐清後才進入下一個)
1. 目標使用者與核心使用情境
2. 範圍邊界(這一版做什麼、明確不做什麼)
3. 業務規則
4. 限制條件(法規、支付、既有系統整合)
5. 成功指標
## 產出
訪談結束後,產出 specs/00-project-brief.md,必須包含:
– 目標與非目標
– 使用者角色
– 業務規則清單
– 風險與假設
– 未決問題(open questions)
## 最重要的規則
凡是使用者沒有明確回答、你不確定的地方,
一律列入「未決問題」,禁止自行填入預設值。
Skill 2:拆解 Story(story-splitting)
為什麼是 skill: 垂直切片和 INVEST 是可以寫死的判斷準則,但砍 story、排優先序仍是人拍板。
—
name: story-splitting
description: 將需求文件拆解為 epic 與 user story。當使用者
要求拆 story、建立 story map、或需求整理完成後使用。
—
# Story 拆解準則
## 輸入
specs/00-project-brief.md 與 specs/constitution.md
## 規則
– 每個 story 用「As a [角色], I want [能力],
so that [效益]」格式
– 採垂直切片:每個 story 對使用者有獨立可驗證的價值
– 用 INVEST 原則自我檢查每個 story,不合格的說明原因
– 標注 story 之間的相依關係
– 每個 story 給編號(US-01、US-02…)
– 標注最小可演示路徑(walking skeleton)
– 只能拆解 brief 裡有的需求,禁止自行發明功能
## 產出
specs/01-story-map.md,以 epic 分組
Skill 3:EARS 格式 AC(ears-ac)
為什麼是 skill: 這是最典型的 skill——句型限定、編號規則、「不准腦補」全是可封裝的規範。而且它會成為跨角色的共同語言:之後的 spec-reviewer 和 tdd-developer 兩個 agent 都依據這份 skill 來解讀 AC。
—
name: ears-ac
description: 為 user story 撰寫 EARS 格式的驗收條件。
當使用者要求寫 AC、驗收條件、acceptance criteria 時使用。
—
# EARS 驗收條件撰寫準則
## 句型(只准用這三種)
– WHEN <觸發事件> THE SYSTEM SHALL <行為>
– IF <錯誤條件> THEN THE SYSTEM SHALL <行為>
– WHILE <持續狀態> THE SYSTEM SHALL <行為>
## 編號
AC-{story編號}-{兩位流水號},例如 AC-04-01
## 必要涵蓋範圍
正常路徑、逾時、失敗、重複操作、併發情境
## 最重要的規則
凡是 spec 未明確定義的業務規則(例如時限幾分鐘、
可重試幾次),禁止自行決定,一律列在文件末端的
【待人類決策】區塊,等使用者裁決後才更新為正式 AC。
## 產出
specs/us-{編號}-{名稱}.md,一個 story 一個檔案
Skill 4:例子問答(sbe-examples)
為什麼是 skill: EARS 適合「觸發→反應」的單一行為;有配額、時間窗、規則組合的複雜業務規則,要用 Specification by Example 的例子問答釘死邊界——而例子的答案必須來自人。
—
name: sbe-examples
description: 用具體例子問答釐清複雜業務規則,產出 Gherkin
scenario。當業務規則涉及多條件組合(配額、日期、身分
交乘)或使用者要求「用例子確認」時使用。
—
# 例子問答協議(Specification by Example)
## 進行方式
– 每次只提出一個具體例子,必須含明確的數值
(日期、金額、配額狀態),不准用抽象描述
– 提出例子後,問使用者:系統應該有什麼行為?
– 使用者回答後,把確認過的例子寫成 Gherkin scenario
– 持續問到所有邊界都覆蓋,最後再問一次:
「還有沒有你想到、但我沒問到的情況?」
## 例子選擇策略
優先問邊界:恰好在門檻上、門檻前後一單位、
配額恰好歸零、多條規則同時適用時的優先序
## 產出
specs/us-{編號}-{名稱}.feature,累積確認過的 scenario
Agent 1:對抗性審查者(spec-reviewer)
為什麼是 agent 不是 skill: 同一個對話裡的 AI 會傾向認同自己剛寫的東西。審查者需要全新的乾淨 context、獨立角色、不需要人在迴圈,產出一份報告——這正是 subagent 的甜蜜點。
注意 tools: 只給唯讀權限——審查者不該有改文件的權力,這本身就是治理設計。
—
name: spec-reviewer
description: 對 specs/ 下的 AC 與 feature 檔做對抗性審查。
AC 撰寫完成後使用,或使用者要求審查規格時使用。
tools: Read, Grep, Glob
—
你是挑剔的資深測試工程師。閱讀 specs/ 目錄下所有文件,
進行對抗性審查:
1. 找出遺漏的邊界案例
2. 找出互相矛盾的規則(包含與 constitution.md 的矛盾)
3. 找出無法測試的敘述(含糊形容詞、沒有明確判準的句子)
4. 檢查併發情境:同一資源被兩個操作同時競爭時,
規格是否定義了明確結果
只提出問題與質疑,禁止修改任何文件。
輸出依嚴重度排序(Blocker / Major / Minor)的問題清單。
Agent 2:測試先行開發者(tdd-developer)
為什麼是 agent: 可自主執行、有明確驗證標準(測試通過 + AC 對照表),人只驗收結果。注意它載入 ears-ac skill 的規範來解讀 AC——skill 作為共同語言的價值在這裡兌現。
—
name: tdd-developer
description: 依 specs/ 下的 AC 以測試先行方式實作 user
story。當使用者要求實作某個 story 時使用。
—
你是嚴謹的開發者,依 .claude/skills/ears-ac/SKILL.md
的規範解讀 AC。實作流程:
1. 讀取指定 story 的 AC 檔與 .feature 檔
2. 先把每一條 AC 轉成一個失敗的自動化測試
(一條 AC 至少對應一個測試)
3. 執行測試,確認全部失敗
4. 實作程式碼,讓測試逐一通過
5. 全部通過後,產出對照表:
AC 編號 → 測試名稱 → 通過狀態
## 鐵律
– 過程中發現 spec 有缺漏或歧義,立刻停下來問使用者,
禁止自行腦補業務規則
– 禁止修改測試來遷就實作;測試錯了要先回報
– 【待人類決策】區塊還有未裁決項目的 story,拒絕實作
工具箱完成。接下來的實戰,你會發現每一步的 prompt 都變得非常短——因為方法論已經內建了。
第二部分:實戰台灣高鐵訂票系統
圖 2:高鐵訂票系統開發全流程與人類閘門
Step 0:建立專案憲法
憲法是「不管做哪個功能都不能違反」的全域規則,所有 skill 和 agent 都會參照它。貼給 Claude Code:
請建立 specs/constitution.md:
# 專案憲法:台灣高鐵訂票系統
– 介面語言:繁體中文;程式碼與註解:英文
– 法規:個資法(身分證字號必須加密儲存)
– 業務鐵律:一個座位在同一時間只能被一張有效訂單持有
– 付款規則:訂位成立後,限時內未完成付款即自動釋放座位
– 規格文件是 source of truth:需求變更時先改規格再改程式
Step 1:需求訪談
原本要貼一大段訪談指令,現在只要一句:
我要開發台灣高鐵訂票系統,請訪談我。
req-interview skill 會自動接手,開始逐輪提問:「非會員可以訂票嗎?」「一筆訂單最多幾張票?」「大學生優惠在哪個時點驗證身分?」「自由座要不要納入這一版?」你逐題回答,不確定的就說不確定——它會列進未決問題,不會自己猜。
為了讓後面的範例一致,假設我們的回答把第一版範圍定為:
做: 單程對號座訂票、非會員訂票、信用卡付款、超商與車站取票
不做: 自由座、TGo 會員、團體票、定期票、去回程票
你的檢查點: 打開 specs/00-project-brief.md,重點看「未決問題」清單——這是整份文件最有價值的部分,它把 AI 猜測轉成了等你拍板的決策。
Step 2:拆解 User Story
請根據 brief 拆解 user story。
story-splitting skill 產出 specs/01-story-map.md(節錄):
## Epic 1:查詢與訂位
– US-01 查詢班次:旅客輸入起訖站、日期、時段,
查看可訂班次與票價
– US-02 選擇票種:全票/孩童/敬老/愛心,及早鳥優惠
– US-03 選擇座位:標準/商務、靠窗/走道,或自動配位
## Epic 2:付款與取票
– US-04 完成付款:信用卡付款,逾時自動釋放座位
– US-05 取得票證:取票代碼,可於超商或車站取票
## Epic 3:訂位管理
– US-06 查詢訂位紀錄
– US-07 退票:依乘車前時間計算手續費
Walking skeleton:US-01 → US-03(自動配位)→ US-04
你的檢查點: 切片是否真的垂直?有沒有 brief 裡沒提、AI 過度發揮的 story?直接說「US-XX 刪掉」「US-YY 排第一」讓它更新。
Step 3:撰寫 AC
請為 US-04 撰寫驗收條件。
ears-ac skill 產出 specs/us-04-payment.md(節錄):
AC-04-01 WHEN 旅客完成訂位,THE SYSTEM SHALL 保留座位
並開始付款倒數(時長待決策)
AC-04-02 IF 倒數結束仍未完成付款,THEN THE SYSTEM SHALL
釋放座位、將訂位狀態改為「已取消」,並通知旅客
AC-04-03 IF 信用卡授權失敗,THEN THE SYSTEM SHALL 顯示
失敗原因,並允許在保留期限內重試
AC-04-04 WHILE 訂位處於「保留中」,THE SYSTEM SHALL 確保
該座位不出現在其他旅客的可選座位中
【待人類決策】
– 座位保留時間是幾分鐘?
– 授權成功但請款失敗,如何處理?
– 付款進行到一半、倒數歸零,以哪個時間點為準?
你的檢查點: 逐題裁決【待人類決策】,例如回覆:
保留時間 10 分鐘;授權成功但請款失敗視同付款失敗、
訂位保留至期限;以「付款請求送出」的時間點為準。
請更新 AC。
Step 4:用例子釘死早鳥優惠
早鳥優惠的規則比較複雜,請用例子跟我確認。
sbe-examples skill 開始逐一提問:
Claude: 乘車日 2026/08/20,今天是 2026/07/25(乘車前 26 天)。該班次 65 折配額已售完,8 折配額尚有餘量。旅客查詢全票票價,系統應顯示什麼?
你: 顯示 8 折早鳥票價。
確認過的例子累積到 specs/us-02-early-bird.feature:
Scenario: 65折配額售完,提供次一級折扣
Given 乘車日為 2026/08/20,今日為 2026/07/25
And 該班次 65 折配額已售完,8 折配額尚有餘量
When 旅客查詢該班次全票票價
Then 系統顯示 8 折早鳥票價
Scenario: 乘車前 5 天內不提供早鳥
Given 乘車日為 2026/07/18,今日為 2026/07/14
When 旅客查詢該班次票價
Then 系統僅顯示全票原價,不顯示早鳥選項
Step 5:呼叫審查者 Agent
請用 spec-reviewer 審查目前所有規格。
subagent 在全新的 context 裡讀完 specs/,回報問題清單,例如:
– Blocker: AC-04-02 說逾時釋放座位,但旅客此刻若正停在信用卡 3D 驗證頁面,規格未定義結果
– Major: 兩位旅客同時對最後一個座位送出訂位,「同時送出」的瞬間誰成立,規格未定義
– Minor: 早鳥的「乘車前 N 天」未定義以何時區、何時刻計算
你的檢查點: 逐條裁決——有道理的,請 Claude Code 補 AC;過度設計的,明確標注 out of scope 寫進文件。這就是把對抗性測試前移到需求階段,比寫完程式才發現便宜太多。
Step 6:呼叫開發者 Agent
請用 tdd-developer 實作 US-04。
它會:把每條 AC 轉成失敗的測試 → 確認全部失敗 → 實作到逐一通過 → 交出「AC 編號 → 測試名稱 → 通過狀態」對照表。如果 US-04 還有未裁決的【待人類決策】,它會拒絕實作——這是我們在 agent 定義裡寫死的鐵律。
那份對照表就是你的驗收閘門(Eval Gate):每一條需求都有對應的測試在守著,AI 產的程式碼不再靠肉眼逐行檢查,而是靠規格驗證。
第三部分:實際修一次 Skill 和 Agent
工具箱不是打造一次就完工的。環境會變、業務規則會變、模型每隔幾個月換代一次。該調整的訊號有三種:觸發失準(該啟動沒啟動,或不該啟動卻啟動)、行為偏差(有啟動但違反了裡面的規則)、環境變遷(規則改了、流程改了、模型升級了)。
圖 3:三種訊號的診斷分流
光講原則不夠,這一節我們真的跑兩次修改:一次修 skill(ears-ac),一次修 agent(tdd-developer),而且每次都驗證到確認新版真的在運作為止。
情境一:修 Skill——ears-ac 自行假設了業務規則
第 1 步:重現並保存失敗案例
某天你請它為 US-04 寫 AC,產出裡出現了這一條:
AC-04-01 WHEN 旅客完成訂位,THE SYSTEM SHALL 保留座位
並開始 15 分鐘付款倒數
spec 從來沒有定義過保留時間。skill 明明寫了「禁止自行決定」,它還是以「業界慣例」為由假設了 15 分鐘,而且沒列入【待人類決策】。
先別急著改,把證據存下來。貼給 Claude Code:
請把剛才這段對話中我的指令與你的產出、以及偏差之處,
存成 .claude/skills/ears-ac/failures/2026-07-15-自行假設時限.md
產出的失敗案例檔長這樣:
# 失敗案例:自行假設業務規則
## 我的指令
請為 US-04 撰寫驗收條件。
## 產出(節錄,偏差處)
AC-04-01 WHEN 旅客完成訂位,THE SYSTEM SHALL 保留座位
並開始 15 分鐘付款倒數
## 問題
spec 從未定義保留時間。skill 明明寫了「禁止自行決定」,
它仍以「業界慣例」為由假設了 15 分鐘,
且未列入【待人類決策】。
失敗案例是調整 skill 最重要的原料——沒有具體案例,你只會憑感覺加規則,越加越亂。
第 2 步:診斷分流
判斷是哪一種問題:產出有 EARS 句型、有 AC 編號,代表 skill 有被載入——所以不是 frontmatter description 的觸發問題,是內文規則不夠強。(反過來,如果它完全用一般方式回答、連 EARS 格式都沒有,那要改的是 description,把使用者實際會說的話——例如「列 AC」——加進觸發詞。)
第 3 步:讓 Claude Code 提出最小修改
不用自己盯著檔案猜,把失敗案例丟給它:
請閱讀 .claude/skills/ears-ac/SKILL.md 和
failures/2026-07-15-自行假設時限.md。
請診斷:是哪一段規則寫得不夠明確,導致它以「業界慣例」
為由自行假設了 15 分鐘?
提出「最小修改」——只改必要的地方,不要重寫整份 skill。
先給我修改前後的 diff,經我確認後才更新檔案。
注意兩個關鍵字:最小修改(防止 AI 順手重寫整份文件,讓你無法追蹤)和經我確認後才更新(連改 skill 這件事,人也要守閘門)。
它的診斷會指出:原規則只說「禁止自行決定」,但沒有封死「引用業界慣例」這條側門,也沒有交付前的自我檢查機制。你確認後,它做出的修改如下(這是實際執行後的 git diff):
— a/.claude/skills/ears-ac/SKILL.md
+++ b/.claude/skills/ears-ac/SKILL.md
@@ -21,6 +21,17 @@ AC-{story編號}-{兩位流水號},例如 AC-04-01
凡是 spec 未明確定義的業務規則(例如時限幾分鐘、
可重試幾次),禁止自行決定,一律列在文件末端的
【待人類決策】區塊,等使用者裁決後才更新為正式 AC。
+「業界慣例」「常見預設值」不構成自行決定的理由。
+
+反例(禁止):
+AC-04-01 … SHALL 保留座位並開始 15 分鐘付款倒數
+正確寫法:
+AC-04-01 … SHALL 保留座位並開始付款倒數(時長待決策)
+【待人類決策】座位保留時間是幾分鐘?
+
+## 交付前自我檢查
+輸出前逐條檢查每個 AC:是否含有任何 spec 中
+找不到出處的具體數值?有,就改寫並移入【待人類決策】。
三個修改動作,對應三種常見手法:封側門(把它用來合理化偏差的理由明文排除)、給反例(一個具體反例勝過三條抽象規則)、加自我檢查(逼它交付前逐條核對)。
第 4 步:確認更新成功——三層驗證
這是最多人跳過、也最不該跳過的一步。驗證分三層:
(1)檔案層:確認檔案真的改了,而且只改了該改的。
git diff .claude/skills/ears-ac/SKILL.md
看到的就是上面那份 diff——沒有多改一行,才叫最小修改。
(2)載入層:開新對話,確認新版有被載入。
這裡有個最常見的坑:skill 是在對話開始時載入的,舊對話裡改 skill,當下那個對話可能還在用舊版。 所以驗證前先結束 Claude Code(Ctrl+C),重新啟動 claude,然後問:
在寫 AC 之前,請先說明 ears-ac skill 目前對
「spec 未定義的業務規則」有哪些要求?
如果它的回答提到「業界慣例不構成理由」和「交付前自我檢查」,代表新版已載入。如果講的還是舊版內容,回頭檢查檔案路徑和 frontmatter 格式是否正確。
(3)行為層:用同樣的輸入重跑,比對行為。
在同一個新對話貼上當初出事的原始指令,一字不改:
請為 US-04 撰寫驗收條件。
修正後的產出:
AC-04-01 WHEN 旅客完成訂位,THE SYSTEM SHALL 保留座位
並開始付款倒數(時長待決策)
…
【待人類決策】
– 座位保留時間是幾分鐘?(spec 未定義)
15 分鐘消失了,問題回到了該回的地方——你的桌上。最後補一個反向測試,確認沒有修過頭:
什麼是 EARS 格式?
它應該正常解說,而不是硬套 skill 開始產 AC——這確認 description 的觸發範圍沒有被這次修改弄壞。
第 5 步:進版本控管
git add .claude/
git commit -m “ears-ac: 加入反例與交付前自我檢查,修正自行假設業務規則
失敗案例: failures/2026-07-15-自行假設時限.md”
commit message 記錄為什麼改,並指向失敗案例。半年後模型換代,你才知道哪條規則是為了防哪個坑、哪些可以拿掉。
情境二:修 Agent——tdd-developer 的測試跑了十分鐘
事故
你請 tdd-developer 實作 US-04,它交出的對照表看起來很漂亮,但整個測試套件跑了十分多鐘。一看程式碼,測「逾時釋放座位」那條 AC 時,它寫了真實的 sleep(600) 等倒數結束。功能是對的,但這種測試進了 CI 就是災難。
這就是「鐵律來自事故」:agent 的鐵律不是一開始想像出來的,是從真實事故長出來的。
修改
Agent 檔案就是純文字,修法和 skill 一樣。這次的事故很明確,可以直接下指令:
tdd-developer 在 US-04 用真實 sleep 等待 600 秒來測逾時,
導致測試套件跑了十分鐘。
請在 .claude/agents/tdd-developer.md 的鐵律區塊
加入一條規則防止此事故。最小修改,
先給我 diff,經我確認後才更新。
實際執行後的 diff:
— a/.claude/agents/tdd-developer.md
+++ b/.claude/agents/tdd-developer.md
@@ -18,5 +18,8 @@
## 鐵律
– 過程中發現 spec 有缺漏或歧義,立刻停下來問使用者,
禁止自行腦補業務規則
+- 測試時間相關邏輯(逾時、倒數、期限)必須使用
+ 可注入的時鐘或 fake timer,禁止 sleep 真實等待;
+ 整個測試套件必須在 30 秒內跑完
– 禁止修改測試來遷就實作;測試錯了要先回報
– 【待人類決策】區塊還有未裁決項目的 story,拒絕實作
注意這條鐵律的寫法:不只禁止(sleep),還給了正確做法(可注入時鐘 / fake timer)和可驗證的判準(30 秒內跑完)。可驗證的判準讓「有沒有改好」變成客觀問題。
驗證
開新對話,重跑同樣的任務:
請用 tdd-developer 實作 US-04。
驗收兩件事:
1. 新鐵律生效: 交付的對照表末端多了一行類似「測試套件執行時間:0.4 秒(使用 fake timer)」,程式碼裡的倒數邏輯改成了可注入的時鐘。
2. 舊鐵律沒被弄壞: 它在動工前仍然先確認了 US-04 的【待人類決策】已全數裁決——修一條規則,不能弄壞其他規則,這就是 agent 的回歸驗證。
順手把這次修改也 commit:
git commit -am “tdd-developer: 加入 fake timer 鐵律,禁止 sleep 真實等待
事故: US-04 逾時測試用真實 sleep 600 秒”
跑完兩個情境,git log 會長這樣——每一次修改都有出處、有理由:
fbf5067 tdd-developer: 加入 fake timer 鐵律,禁止 sleep 真實等待
89c5e02 ears-ac: 加入反例與交付前自我檢查,修正自行假設業務規則
c48c5e2 初版 skill 與 agent
另外,agent 還有一個 skill 沒有的調整維度:權限收放。tools: 是治理工具——spec-reviewer 多嘴改了文件?確認它只有 Read、Grep、Glob。tdd-developer 每次都要問能不能跑測試?放寬執行權限。原則是先給最小權限,出現具體需求才放寬,每次放寬都要說得出理由。
圖 4:Skill / Agent 調整循環與三層驗證
因應時代變遷:定期健檢
除了事故驅動的修改,建議每季(或每次模型大版本升級後)做一次健檢:
請閱讀 .claude/skills/ 和 .claude/agents/ 下的所有檔案
(含 failures/),以現在的你的能力為基準,回答:
1. 哪些規則是為了防範舊模型的弱點,現在可能已經多餘?
2. 哪些規則互相矛盾或重複?
3. 哪些 description 的觸發詞已不符合團隊的說話習慣?
只提出建議與理由,不要修改任何檔案。
它的建議你逐條裁決——跟審 AC 是同一個模式:AI 提案,人拍板。
三個常見錯誤
一、skill 肥大症。 每次出事就加一條規則,半年後 SKILL.md 變成三百行大雜燴,模型反而抓不到重點。規則超過一頁時先問:哪些可以合併?哪些其實是另一個 skill?(例如 ears-ac 裡長出一堆 Jira 同步規則,該拆成獨立的 jira-sync skill。)
二、否定句堆疊。 「不准這樣、禁止那樣」堆了十條,不如像情境一那樣:封側門 + 一個反例 + 自我檢查。否定句只告訴模型不能去哪,反例和正確寫法才告訴它該去哪。
三、改了不驗證。 憑感覺改完就收工,結果修好一個偏差、弄壞兩個原本正常的行為。三層驗證——檔案層(diff)、載入層(新對話確認)、行為層(同輸入重跑 + 反向測試)——一層都不能省。沒有回歸驗證的修改,跟沒有測試的重構一樣危險。
回顧:這套設計在講什麼
一、prompt 變短了,品質變穩了。 第二部分每一步的指令都只有一句話,因為方法論已封裝進 skill。更重要的是團隊效應:每個人呼叫的都是同一份 skill,產出格式一致、規則一致——skill 是團隊的共同語言,不是個人的 prompt 秘笈。
二、上游 skill,下游 agent,人守閘門。 需求、story、AC 這些上游工作,價值在「逼出人類決策」,所以做成 skill、人留在迴圈;審查、實作這些下游工作,價值在「依既定判準自主執行」,所以做成 agent、人只驗收結果。人的角色沒有消失,而是集中到了五個檢查點:未決問題拍板、story 取捨、【待人類決策】裁決、審查報告裁決、驗收對照表。
三、哪些刻意不自動化,跟哪些自動化一樣重要。 技術上完全可以做一個「自動訪談 + 自動回答 + 自動產 brief」的全自主 pipeline,demo 會很漂亮——但未決問題清單會消失,AI 猜測會重新偽裝成 AI 決策。忍住這個誘惑,是這套設計最重要的一條線。
四、skill 和 agent 是活的資產,用維護程式碼的紀律維護它們。 失敗案例驅動修改、最小修改、回歸驗證、版本控管、定期健檢——你對 code 怎麼做,對 skill 就怎麼做。而調整的每一步,仍然是同一個模式:AI 診斷、AI 提案,人拍板。
你只需要 Claude Code、六個文字檔、和一個 specs/ 資料夾。今天就可以開始。
發表迴響