標籤: 醫療系統

「Claude Code 對我沒用，我試過，它做出來的東西都不對。」

這句話我聽過很多次。幾乎每次深入問，問題都不在 Claude，在提問的方式。

這篇文章用三個真實的軟體開發場景，直接模擬「不會用的人」和「會用的人」各自怎麼做，讓你看清楚差距在哪裡。

核心差距：有沒有給 AI 做事的結構

不會用 Claude Code 的人，把它當成「很聰明的搜尋引擎」，問一句，期待完美答案。

會用的人，把它當成「需要完整簡報才能開工的新進工程師」：你給的資訊越清楚，他做出來的東西越準確。

差距的本質是：你的輸入有沒有結構。

場景一：醫療預約系統（門診掛號）

痛點

診所要做線上掛號，需要處理：醫師排班、假日停診、同時段人數上限、患者重複掛號防止。每個規則都有例外，例外裡還有例外。

不會用的人怎麼做

直接開口：

幫我寫一個門診預約系統的 API，要能掛號、取消、查詢。

Claude 給了一個乾淨的 REST API，CRUD 完整，code 看起來不錯。

開始整合後發現問題一個接一個：

• 沒處理同時段上限（診所每診次只收 20 人，API 沒有 capacity 邏輯）
• 沒有重複掛號檢查（同一個患者可以掛同一診次兩次）
• 沒有假日判斷（系統不知道什麼是醫院休診日）
• 時區沒處理（台灣 UTC+8，stored as UTC，前端顯示全錯）

開始補需求：「喔對，要加上每診次人數上限」→ Claude 修改。「還有重複掛號要擋掉」→ Claude 再改。「假日要停診」→ 再改。每次修改都可能動到之前改好的邏輯，三輪之後代碼開始難以追蹤。

結果：8 小時，仍有未發現的 bug，信心不足。

會用的人怎麼做

第一步：CLAUDE.md 裡早就寫好領域規則

## 醫療領域規則
- 所有時間以 UTC+8 儲存，API 回應包含 timezone 欄位
- 患者 ID 採用身分證字號格式，需驗證格式（字母+9位數字）
- 診次 (session) 為最小預約單位，每診次有 capacity 上限
- 相同患者在同一診次只能有一筆有效預約

## 錯誤處理標準
- 業務邏輯錯誤：HTTP 422 + { code, message, field }
- 驗證錯誤：HTTP 400 + 同上格式

第二步：先寫設計文件（20 分鐘）

# 功能：門診掛號 API

## 輸入
{ patientId: string, sessionId: string }

## 驗證順序（按此順序，遇錯即停）
1. patientId 格式是否合法
2. sessionId 是否存在且為未來時間
3. 該診次是否已達 capacity
4. 該患者是否已有此診次的有效預約

## 邊界條件
- capacity 滿：422，code: SESSION_FULL
- 重複掛號：422，code: DUPLICATE_BOOKING
- 患者格式錯：400，code: INVALID_PATIENT_ID
- 診次已過去：422，code: SESSION_EXPIRED

## Done When
- 所有邊界條件有單元測試
- integration test 驗證完整掛號流程
- 0 TypeScript errors

第三步：分段給任務

請先閱讀 CLAUDE.md 和這份設計文件。
閱讀完告訴我你的理解，特別是驗證順序的邏輯，再開始實作。
先只實作 validateBooking() 函數和對應單元測試，不要動 API 層。

確認驗證邏輯正確後，再說「現在依照這個驗證函數實作 POST /bookings endpoint」。

結果：2.5 小時，第一次就通過所有測試，零修改。

場景二：股市回測系統

痛點

想驗證一個交易策略：當 5 日均線上穿 20 日均線時買進，死亡交叉時賣出。聽起來簡單，但台股有漲跌停、只能在交易日交易、最小交易單位是 1000 股、手續費和證交稅要扣掉，每個細節都會影響回測結果。

不會用的人怎麼做

幫我寫一個台股回測程式，策略是 5 日均線上穿 20 日均線買進，死叉賣出。

Claude 給了一個 Python 回測，用 pandas 計算均線，邏輯清楚。跑了一下，報酬率看起來很漂亮。

仔細看才發現：

• 買賣都用收盤價，但實際上收盤價買不到（要用隔日開盤）
• 沒有漲跌停限制，假設任何價格都能成交
• 沒扣手續費（0.1425%）和證交稅（0.3%）
• 沒有最小交易單位，0.1 張也買
• 跑到非交易日（週末）的資料也在交易

這些問題加起來，讓回測結果虛報了約 30–40%。一個看起來賺錢的策略，修正後可能是虧損的。

結果：6 小時修修改改，最後不確定結果是否可信。

會用的人怎麼做

設計文件把所有台股規則先寫清楚：

# 功能：台股均線策略回測引擎

## 市場規則（必須完整實作）
- 交易日：排除週末 + 台灣國定假日（用 holidays-tw 套件）
- 成交價：訊號發生在收盤，執行在「隔一個交易日開盤價」
- 漲跌停：每日最大漲跌幅 ±10%，超過範圍無法成交，標記 LIMIT_HIT
- 最小交易單位：1000 股，不足整張無法下單
- 手續費：買賣各 0.1425%（可設定），最低 20 元
- 證交稅：賣出 0.3%（ETF 為 0.1%）

## 回測輸出格式
{
  total_return_pct: float,    # 扣除所有費用後
  trades: [{ date, action, price, shares, cost, tax, net_pnl }],
  unfilled: [{ date, reason }],   # LIMIT_HIT 等無法成交紀錄
  sharpe_ratio: float,
  max_drawdown_pct: float
}

## 邊界條件
- 漲停無法賣出（LIMIT_HIT_SELL）
- 跌停無法買入（LIMIT_HIT_BUY）
- 資金不足一張：跳過，記錄 INSUFFICIENT_FUNDS
- 最後持倉：回測結束日強制以收盤價平倉

提示方式：

請先閱讀這份設計文件，告訴我：
1. 成交時間點的邏輯（訊號日 vs 執行日）你的理解
2. 漲跌停時的處理流程

確認理解正確後，先只實作 TaiwanMarketRules 類別和測試，
包含漲跌停判斷、交易日判斷、手續費計算三個方法。
不要實作策略邏輯或回測引擎。

結果：3 小時，回測結果可信，且有完整的無法成交紀錄供分析。

場景三：電商金流串接（綠界 ECPay）

痛點

要串接台灣最常用的金流服務商，支援信用卡一次付清 + ATM 虛擬帳號。牽涉到加密簽章驗證、非同步回調（ReturnURL / OrderResultURL）、以及各種付款失敗情境。

不會用的人怎麼做

幫我串接綠界金流，支援信用卡和 ATM 付款。

Claude 寫了一個串接，看起來完整。測試環境跑起來。上線後三天，開始收到客訴：

• 付款成功但訂單沒更新（沒有正確處理綠界的非同步通知）
• ATM 超時未付款，訂單卡在「待付款」沒有自動取消
• CheckMacValue 驗簽偶發失敗（特殊字元的 URL encode 方式不對）
• 退款流程完全沒實作（以為付款和退款是同一組 API）

每個問題單獨看都能修，但修一個又會影響另一個。金流 bug 是最難測試的，因為要模擬真實付款行為。

結果：上線後 bug，緊急修補兩天，損失用戶信任。

會用的人怎麼做

先用 Plan Mode 讓 Claude 梳理所有狀態流：

【背景】
我要串接綠界 ECPay，使用 Node.js + PostgreSQL，
CLAUDE.md 中規定所有金流操作要記 audit log。

【目標】
支援信用卡一次付清和 ATM 虛擬帳號，訂單狀態要與付款狀態完全同步。

【約束條件】
- 不能有「已付款但訂單未更新」的狀態
- ATM 超過 3 天未付款自動取消訂單並釋放庫存
- CheckMacValue 驗簽失敗必須記錄並告警

請制定實作計劃，列出所有需要處理的狀態流轉，
等我確認計劃後再開始實作。

Claude 在計劃中列出了 14 個狀態節點，包含「非同步通知重複到達」、「驗簽失敗的處理」這些不明顯的情境。確認計劃後再開始做。

設計文件特別標明的邊界條件：

## 邊界條件（金流特有）
- ReturnURL（非同步）和 OrderResultURL（同步）可能「都」被呼叫
  → 用 idempotency key 確保同一筆交易只更新一次訂單
- CheckMacValue 驗簽：URL encode 順序必須按綠界規範（非標準 encodeURIComponent）
  → 測試案例需包含含特殊字元的 MerchantTradeNo
- ATM 逾期：用 pg-cron 排程，不要依賴前端觸發
- 退款：獨立 API，與付款 API 完全分離，需要人工審核 flag

結果：4 小時，上線零 bug，audit log 完整。

差距總結

面向	不會用的人	會用的人
提示方式	「幫我做 X」	「背景 + 目標 + 約束條件 + 邊界條件」
領域規則	每次用到才補說	寫進 CLAUDE.md，一次設定永久生效
邊界條件	做完後才發現沒處理	設計文件裡最前面就列清楚
複雜任務	一次丟，結果跑偏再修	Plan Mode 確認方向，分段執行
驗證方式	全部做完再整體測試	每段完成後先確認，錯誤早期發現
對話輪數	8–15 輪	2–4 輪
結果品質	能跑，但邊界不完整	完整，測試覆蓋所有邊界

為什麼大多數人卡在「不會用」

不是因為懶，是因為直覺錯了。

我們習慣搜尋引擎：問一句，得到答案。Claude Code 不是搜尋引擎，它是一個需要簡報才能開工的工程師。你給的資訊越完整，它做出來的東西越準確。

轉換這個直覺需要時間，但一旦轉過來，你就不會想回頭了。

從下一個任務開始，試著在開口前先回答三個問題：

1. 這個功能的輸入和輸出各是什麼格式？
2. 哪些邊界條件會讓它失敗？
3. 我怎麼確認它做對了？

把這三個問題的答案寫下來，你的 Claude Code 使用效果會立刻不一樣。

常見問題

Q：每次都要先寫設計文件，不會很花時間嗎？

一份最小版設計文件 20 分鐘。省下的多輪修改至少 2–4 小時。這筆帳很好算。

小功能（一個函數、修一個 bug）不需要設計文件，直接做。設計文件是為了「有多個邊界條件、或跨越兩層以上架構」的任務。

Q：CLAUDE.md 不是每個專案都要重寫一遍嗎？

寫一次，維護成本低。每次發現 Claude 做了一個你不喜歡的決定，把那條規則加進 CLAUDE.md，下次就不會再發生。它是越用越省力的資產。

Q：我的需求很複雜，文件要寫到多詳細？

詳細到「可以讓另一個工程師依照這份文件實作，不需要問你問題」。如果你寫完文件還是覺得有地方模糊，那就是還有沒想清楚的需求，先想清楚再開始比較省事。

從不會用到會用：各情境的具體升級路徑

看完上面三個場景，你可能知道差距在哪，但還不知道今天要改什麼。這一節給你一條明確的路，從第一步到進階，每步都有可以直接複製的東西。

第一步：今天就能做到（不需要任何準備）

在你現在的任何提示最後加上這一句：

先告訴我你的理解和假設，再開始實作。

就這一句。它會讓 Claude 在動手前先說出它的假設，你可以在它寫出一堆錯誤代碼前糾正它。成本 0，效果立竿見影。

三個情境的具體升級示範：

醫療場景：Level 0 → Level 1

不會用（Level 0）	初步會用（Level 1）
幫我寫門診預約系統	（見下方）

幫我寫門診掛號的 API。

輸入：{ patientId: string, sessionId: string, phone: string }
輸出：{ bookingNo: string, status: "SUCCESS" | "FULL" | "DUPLICATE" }

必須處理：
- 同一診次超過容量上限 → 回傳 FULL
- 同一患者重複掛同一診次 → 回傳 DUPLICATE
- 所有時間以 UTC+8 處理

先告訴我你的理解，特別是這三種情況你打算怎麼處理，再開始實作。

改變了什麼：加了輸入輸出格式、三個邊界條件、確認步驟。這 5 分鐘的準備，省掉事後發現「沒處理重複掛號」的 2 小時修改。

股市場景：Level 0 → Level 1

幫我寫台股均線回測。策略：5日均線上穿20日均線買進，死叉賣出。

台股特有規則（全部都要實作）：
- 訊號發生在收盤，執行在隔交易日開盤價（不是同日收盤）
- 漲跌停 ±10%，超過無法成交，記錄 LIMIT_HIT
- 手續費：買賣各 0.1425%，最低 20 元
- 證交稅：賣出 0.3%
- 最小交易單位 1000 股，不足不下單

先告訴我這些規則你的理解，特別是成交時間點的邏輯，再開始寫。

電商金流場景：Level 0 → Level 1

幫我串接綠界 ECPay，支援信用卡一次付清。

必須處理的情況：
- ReturnURL（非同步）和 OrderResultURL（同步）可能都會被呼叫，
  同一筆交易只能更新訂單一次（要有 idempotency 機制）
- CheckMacValue 驗簽失敗：記 log，不更新訂單，回傳 0|Error
- 付款成功後訂單狀態必須立刻更新

先告訴我你打算怎麼處理「非同步和同步通知都到達」這個情況，再開始實作。

第二步：下週可以做到（CLAUDE.md）

把你的領域規則寫成一個檔案，放在專案根目錄，命名 CLAUDE.md。之後每次對話都不用再重複說這些規則。

先從最小版開始，15 分鐘寫完：

# 專案規則

## Tech Stack
[填你用的技術]

## 這個領域的特殊規則
[把你每次都要補充說明的規則寫在這裡]
例：
- 台股交易日排除週末 + 台灣國定假日
- 醫療系統所有時間 UTC+8
- 金流驗簽失敗一律記 log 不更新訂單

## 代碼標準
[你每次都要糾正的習慣寫在這裡]
例：
- 禁止 any 類型
- 每個函數必須有對應測試
- API 錯誤格式統一：{ code, message, field }

## 邊界條件規則
[這個專案特有的邊界處理方式]

寫好之後，下次開口前說「請先讀 CLAUDE.md」或什麼都不用說（Claude Code 會自動載入）。

第三步：一個月後的進化（設計文件 + Plan Mode）

當你習慣 Level 1 之後，下一步是在動手前多寫一份設計文件。這份文件不是給人看的，是給 Claude 看的，20 分鐘寫完，節省的是事後 4–6 小時的修改。

設計文件的最小格式：

# 功能：[名稱]

## 輸入 / 輸出
輸入：[JSON 範例]
輸出：[JSON 範例]

## 邊界條件（必須處理）
- [條件 A] → [預期行為]
- [條件 B] → [預期行為]

## 完成定義
- [ ] 所有邊界條件有對應單元測試
- [ ] TypeScript 0 errors

有了設計文件之後，任務的啟動提示變成：

請先閱讀 CLAUDE.md 和 [設計文件名]。
閱讀完告訴我你的理解，特別是邊界條件部分。
確認後先只實作 [最小單元]，不要動其他層。

當任務更複雜（跨 5 個以上文件、不可逆的架構改動），改用 Plan Mode 啟動：

請先制定實作計劃，列出方案選項和取捨，等我確認後再開始執行。

階段	做什麼	時間投資	節省的來回
Level 0	直接說需求	0	0
Level 1（今天）	加輸入/輸出/邊界 + 確認步驟	5 分鐘/次	2–4 輪
Level 2（下週）	CLAUDE.md 寫入領域規則	15 分鐘（一次性）	每次省 1–2 輪
Level 3（一個月後）	設計文件 + Plan Mode	20 分鐘/功能	第一次就對