我不會動物醫療、不會救援 SOP、不懂訓練評分。但 場主會。
我的角色不是「變成這個領域的專家」，
是「把這個領域的專家變成可被產品化的系統」。
P3 / LAYER 1 探索 · CASE STUDY
Project Paws
用 Claude 把 20 年動物救援領域結構化成 7 份產品文件
Layer 1 = 把陌生領域拆給我聽，不是叫它回答
INTERVIEWS · DOCUMENTS
2／7
2 輪深度訪談（Alex × 場主 × 執行夥伴）→ 收斂出 7 份完整產品文件。我跟動物救援沒任何背景，但場主有 20 年實戰 ── Claude 在這裡的角色不是給答案，是把問題問對。
業務分類5大類
設計鐵律4
Alex 寫 LOC~0
2
ROUNDS
2 輪深度訪談
7
DOCUMENTS
~3,500 行 .md + .html
5
BIZ TYPES
救援/醫療/訓練/活動/出國
4
DESIGN LAWS
任一條被破，產品就死
4
PHASES
Phase 0 → 3 完整 roadmap
~0
LOC BY HUMAN
全部由 Claude Code 寫
📸 截圖導讀
7 張實際畫面 · 看真的，不只看字
閱讀地圖
先看做出什麼（SEC 01 七份文件）→ 5 大業務怎麼分（SEC 02）→ 背後怎麼跑出來（SEC 04 五子層）→ 換你怎麼做（SEC 07 行動建議）
SEC 01
他做出了什麼？7 份產品文件
先看具體成果 ── 2 輪訪談收斂成 7 份完整產品文件，約 3,500 行 markdown + HTML。後面 SEC 04 再看背後怎麼跑出來。
0
INDEX.md
整套文件入口、閱讀順序、跨檔交叉索引、4 條鐵律
300LINES
1
prd.md
單一產品文件來源 ── 產品定位、設計鐵律、完整功能 AC、Phase Roadmap、Kill Criteria、開發排程
720LINES
2
domain-knowhow.md
動物救援領域知識 ── 救援/醫療/訓練/活動/出國 + 四種離開狀態 + 角色 SOP + 術語 + 法規
610LINES
3
data-schema.md
資料模型 ── 4 核心表 + 6 輔助表 + Sheets/Postgres 兩版本 + AI metadata + Migration
580LINES
4
design-system.md
設計系統 ── 色彩 / 字型 / 間距 / 元件庫 / RWD / 動效 / 無障礙
700LINES
5
userflow.html
流程視覺化 ── 7 個流程 swimlane（含 RWD：桌機橫向 / 手機縱向）
7FLOWS
6
mockup.html
UI 原型 ── 7 場景互動式 prototype，行動 + 桌面雙視角，可切換裝置 / 角色
7SCENES
7
onboarding-playbook.md
執行劇本 ── 執行夥伴帶場主上車：Day -7 到 Day 30，含對話台詞、失敗 escalation
870LINES
SEC 02
5 大業務分類 × Phase Roadmap
Phase 1 (MVP)
Phase 1.5 (升級)
Phase 2+ (擴展)
救援 RESCUE
✓入所紀錄
—未規劃
—未規劃
醫療 MEDICAL
✓純記錄
✓自動排程提醒
—未規劃
訓練 TRAINING
⚠純文字
✓量化評分 1-5 + 停滯偵測
—未規劃
志工活動 ACTIVITIES
✓純記錄
—未規劃
✓排班
送狗出國 EXPORT
✓純記錄
✓文件追蹤儀表板
—未規劃
每類業務有自己的「狀態機」、「術語」、「不能做的事」 ── 這些都是場主做了 20 年才知道的隱性知識。AI 沒有領域專家，就生不出這張表。
SEC 03
4 條設計鐵律（背起來）
R1
場主永遠只做跟狗有關的事
不填表、不分類、不選下拉、不按儲存。 從訪談發現：場主一輩子沒填過 Excel，每次面對表單就會避開系統。
SOURCE: prd.md §2.2 R1
R2
系統邊用邊長
永遠沒有「建檔完成日」 ── 不要先建 120 隻才能用。邊用邊長是設計哲學，也是降低 Phase 0 失敗風險的關鍵。
SOURCE: prd.md §2.2 R2
R3
校稿責任不在場主身上
執行夥伴 / 工讀生負責校稿。場主只負責「跟狗有關的事」。把校稿責任放錯人是這類產品的常見死因。
SOURCE: prd.md §2.2 R3
R4
用場主已經會的工具優先
語音 + QR 掃碼 vs 表單 vs App ── 選場主已經會的。Phase 0 用 LINE 群組驗證就是這條的極致。
SOURCE: prd.md §2.2 R4
這 4 條每一條都是訪談收斂出來的「場主 不會這樣做」── 不是規格書抄來的設計原則。
SEC 04
背後怎麼跑出來？探索的 5 個子層
看完前面三個 SEC 的具體成果，這 5 個子層就是把 2 輪訪談收斂成 7 份文件的鷹架。從輸入到回饋，每一層都不能少。
L1
輸入層 ── 2 輪深度訪談
Alex × 場主 × 執行夥伴三方對話 ── 把腦袋裡的經驗「逼出來」
2ROUNDS
L2
對齊層 ── Claude 對話 + 反問 + 假設質疑
找出沒講出口的隱性規則 ── 用「我可以這樣理解嗎」反問場主，逼她否認或修正
N×ITER
L3
結構化層 ── 7 份產品文件
PRD / 領域 / 資料 / 設計 / 流程 / 原型 / 劇本 ── 從對話收斂成可被執行的規格
3,500LINES
L4
驗證層 ── 4 條設計鐵律 + Kill Criteria + Phase Roadmap
防止過度設計、避免做白工 ── 4 階段、3 個明確 stop point
4STOPS
L5
回饋層 ── 2 輪訪談收斂的 13 個關鍵決策
確保場主、執行夥伴、Alex 三方對齊 ── 全部寫進 INDEX.md §4
13DECISIONS
SEC 05
6 個角色與工具映射
M
場主（場主）
手機 only · 語音錄製為主
✕ 不該做：填表、按儲存、選下拉
I
執行夥伴（執行）
桌面 + 手機 · 校稿、整合視角
✕ 不該做：取代場主與狗的關係
P
工讀生
桌面 · 校稿補位
✕ 不該做：沒有最終決策權
V
志工
手機 · 任務看板
✕ 不該做：接觸醫療敏感操作
D
獸醫 / 顧問
手機（瀏覽）· 看歷史病歷、給建議
✕ 不該做：不直接寫入系統
A
領養人
手機 · 訪客頁
✕ 不該做：看不見內部資料
SEC 06
整體評估（3 個 insights）
01
領域知識才是燃料，不是技術能力
我不會動物醫療、不會救援 SOP、不懂訓練評分。但場主會。我的角色不是變成這個領域的專家，是把這個領域的專家變成可被產品化的系統。
CLAUDE 是引擎 · 領域專家是燃料
02
非工程師背景反而是優勢
不是傳統工程師（SRE / DevOps），意味著：不會試圖用技術上厲害的方式解決問題、會用「場主會用」的方式設計、會把錯誤的可能性放在第一位。4 條鐵律全部是「禁止場主做的事」。
工程師問「我能做什麼」 · 領域探索者問「場主會做什麼」
03
邊用邊長 > 一次到位
設計哲學上最大的反直覺：Phase 0 不寫程式。先用 LINE 群組驗證 2 週 ── 看場主會不會講話、執行夥伴會不會校稿。Phase 0 失敗 → 整個系統不做，省下 8-12 週開發。
Layer 1 的成果不只是「文件」 · 是「驗證假設的最低成本路徑」
SEC 07
給其他探索者的行動建議
Step 1短期
1–2 WEEKS · 你現在能做的
S1
找一個你最想懂的領域 + 一個能講話的領域專家
沒有專家就沒有 Layer 1，AI 不能憑空生領域知識
S2
把第一次對話錄下來、轉文字、丟給 Claude 摘要
你會發現專家講的「廢話」其實藏著規則
S3
用 Claude 反問你不懂的詞
你以為懂的詞，往往是領域專家才知道的潛規則
S4
產出第一份 domain-knowhow.md 草稿
不求完整，求結構 ── 之後 2 輪訪談會慢慢補滿
Step 2中期
1–3 MONTHS · 結構化階段
M1
找出 4 條設計鐵律
任何一條被破產品就會死 ── 領域知識的「底線」
M2
寫 Phase 0：零開發驗證
不寫程式跑 1-2 週，看核心假設成不成立
M3
設計 Kill Criteria
明寫「什麼條件下這個案子直接停」
M4
產出 7 份產品文件
不是用範本套，是用對話收斂
Step 3長期
3–6 MONTHS · 落地與進化
L1
跑完 Phase 0 → 1 → 1.5
看領域真的能不能落地
L2
把 4 條鐵律變成 CLAUDE.md
進入 Layer 3（標準化）的入口
L3
記錄探索流程本身
你做完一個 Layer 1，下一個領域就知道怎麼跑
SEC 08
風險矩陣（7 點）
R1
致命
場主試用後拒絕
致命。訪談時場主對「錄音」表現抗拒就是徵兆。Phase 1 上線前要解決，否則整個產品死。
對策：Phase 0 LINE 驗證 + onboarding-playbook §5-§9 對話劇本
R2
致命
執行夥伴過載而棄守
致命。執行夥伴開始抱怨「每天好多」就是徵兆。校稿責任太重會讓執行夥伴棄守，整個系統失去校對機制。
對策：onboarding §11 自我照顧 + 30 分鐘上限 + Alex 監控
R3
中
AI 中文準確度不足
語音轉譯出錯。場主講「狂犬病」被轉成「狂躁病」。
對策：30 段真實音檔實測 + Whisper/Gemini 雙線備援
R4
低
4 條設計鐵律被軟化
後期妥協。開始有人提「場主偶爾填一下表也沒關係」。
對策：4 條鐵律明寫進 prd.md §2.2，不允許口頭妥協
R5
中
Phase 升級觸發條件不明確
Phase 0→1 拖延。LINE 驗證 4 週還沒做決定。
對策：Kill Criteria 第 4 週 / 第 12 週 stop point（已有）
R6
中
領域知識更新跟不上現實
domain-knowhow 過時。6 個月後領養法規變了。
對策：半年回顧 domain-knowhow.md（M3 流程）
R7
低
Mockup / Userflow 與最終實作脫節
開發完發現 mockup 跑不起來。
對策：mockup.html 用真實互動，不只是視覺稿
SEC 09
Layer 1 探索的反思
為什麼這個案例是 Layer 1 的代表
Layer 1（探索）的核心命題：用 Claude 探索陌生領域。
很多人誤會 Layer 1 是「用 ChatGPT 查資料」── 錯。那只是查詢，不是探索。
真正的 Layer 1 = 把領域專家腦袋裡的隱性知識結構化成可重複使用的文件。
Project Paws 完整示範這個過程：
- 領域不熟（我） + 領域很熟（場主） → Claude 當翻譯機
- 2 輪訪談 → 從廢話中找規則
- 7 份文件 → 把規則寫成可被執行夥伴 / 工讀生 / 工程師讀懂的格式
- 4 條鐵律 + Kill Criteria → 防止做白工
跟畠山 case 的對應
畠山 case 的 ⑧「CLAUDE.md：給 AI 的業務手冊」概念，在 Project Paws 的 domain-knowhow.md 是同一個東西 ── 把領域 know-how 寫成 AI 可重複使用的指令集。
差別只在領域：
- 畠山 → 稅務（記帳分類規則 / 稅區分 / 安全政策）
- Paws → 動物救援（救援 SOP / 醫療規則 / 訓練評分 / 出國文件）
架構一樣。換領域、寫 domain-knowhow.md、跑 2 輪訪談、就跑得起來。
LAYER 1 EXPLORATION · 領域知識才是燃料，CLAUDE 是引擎