那台被借走
兩次的投影機

開場｜一台投影機，兩張核准單

星期一，早上九點零五分。小晴抱著筆電站在器材室門口：「我十點要提案，昨天核准的投影機呢？」

管理員美玲翻開試算表，臉色變了一下。另一位同事阿凱也有一張核准單，設備編號一模一樣：P-001。

主管：「阿哲，你不是會用 AI？幫我們做個借用系統吧。可以申請、核准、歸還就好，很簡單。」

工程師阿哲打開 ChatGPT。他差點輸入「用 ASP.NET Core 和 PostgreSQL 做借用系統」，但停住了：畫面能跑，和公司不再把設備借兩次，是兩回事。

先看終點：本次到底要交付什麼？

一份能追溯決策的 MVP 規格、一條「核准 → 領用 → 歸還」垂直切片設計、資料庫防線、測試計畫與上線檢查。故事中的成功不是「AI 寫了好多程式」，而是我們知道什麼已確認、什麼仍需驗證。

第一幕｜先別讓漂亮答案替你決定需求

阿哲先試了一次模糊的問法。

幫我設計一套專業的設備借用系統，要完整一點。

看起來很完整。美玲卻問：「我們沒有罰款，而且申請還沒核准，為什麼就不能借給別人？」

第一個錯誤浮出來了：AI 把合理猜測寫得像既定政策。阿哲沒有要求它「更聰明一點」，而是改變工作順序。

先不要寫程式。我們要解決設備重複借出的問題。
請列出會改變資料模型或權限設計的關鍵問題。
區分：已知事實、待確認事項、你的建議。
不要自行把建議當成公司規定。

帶走的概念：好 Prompt 不是修飾詞多，而是能讓未決事項浮出來。

決策：Approved 開始占用，Pending 不占用。
理由：管理員需要在多個用途間選擇。
確認者：美玲（故事角色）
受影響：可用性查詢、唯一索引、核准 API、並行測試。
若改變：不能只改按鈕文字，要同步重看以上項目。

第二幕｜給 AI 一本薄薄的案卷

午餐前，阿哲把確認結果整理成一張「案卷」。他不再把整段聊天丟回去要求 AI 自己猜哪句最新。

【任務】設計設備借用 MVP 的核准流程。
【已確認／規格 v1】
一筆設備代表一台實體。Pending 不占用。
Approved、CheckedOut 占用。逾期不釋出。
不做未來預約、罰款、通知、自動核准。
管理員操作核准、領用、歸還；員工看自己的借用。
【技術】ASP.NET Core + PostgreSQL，版本尚待專案確認。
【本輪成果】狀態轉移表 + 不變條件 + 驗收案例。
【限制】不寫整個專案；新增假設另列，不能默默改規格。
【檢查】找出至少三個容易漏掉的失敗情境。

這就是 Context：讓這一輪判斷所需的資訊到位，而不是字數越多越好。即使留在同一個對話，也要有可引用、可更新的決策摘要。

這一輪要搜尋嗎？

美玲確認的內部政策，不需要上網找答案。若要選實際套件版本、查資料庫語法與安全設定，就查官方文件並記錄版本。本章的規則推導可以先做；不能把「AI 記得某個版本」當成部署依據。

阿哲要求更仔細地比較並行情境，卻沒有要求 AI 保證正確。推理深度能幫助分析，不能取代資料庫測試、權限測試或事實查證。

請先回覆：
1. 本輪會維持的三個不變條件。
2. 你仍缺少哪些資訊。
3. 你打算修改的範圍。
等範圍確認後，再產出修改。
不要把文件中的範例值當成正式環境設定。

第三幕｜把「不能重複借」變成能驗收的句子

「不可以重複借出。」主管點頭。阿哲追問：「兩個人同時按核准，也算嗎？」這句追問把漂亮需求變成工程問題。

Given P-001 有兩筆 Pending：A、B
When 兩個管理員同時核准 A 與 B
Then 只有一筆成為 Approved
And 有效占用筆數 = 1
And 只有成功者新增核准稽核
And 失敗者收到可理解的衝突訊息

這裡沒有規定 A 一定贏。先後順序可能不確定，但不變條件不能變。

第四幕｜逾期不是新的出口

AI 提議增加一個 Overdue 狀態。美玲說：「那今天一逾期，原本那筆 CheckedOut 不就不算占用了？」

阿哲把圖重畫了。這不是所有系統的唯一設計，但符合本案：逾期是由時間推導的標籤，不是釋出設備的生命週期狀態。

主路徑由左至右（小螢幕由上至下）。旁支：Pending → Rejected／Cancelled；Approved → Cancelled。CheckedOut 必須歸還，不能直接取消來掩蓋未歸還事實。

isOverdue = status == CheckedOut AND nowUtc > dueAtUtc
isOccupied = status IN (Approved, CheckedOut)

核准時必須設定未來的歸還期限；領用時再確認期限仍在未來。時間以 UTC 儲存，畫面依使用者時區顯示。剛好等於期限尚不算逾期，超過才算：邊界也要測。

第五幕｜兩個請求都說：我剛剛看過，沒人借

下午兩點，阿哲看到 AI 寫出的第一版邏輯：

如果查不到有效占用：
    把這筆申請改成 Approved
    儲存

「看起來對呀？」小晴問。阿哲把兩個請求並排放在白板上。

兩邊都沒有說謊，只是都用過時的觀察做決定。阿哲補上最後一道防線：

-- 設計片段：loans 的每列是一筆申請
CREATE UNIQUE INDEX ux_loans_one_active_equipment
ON loans (equipment_id)
WHERE status IN ('Approved', 'CheckedOut');

局部唯一索引只對符合條件的列要求唯一。兩筆申請可同時 Pending；一旦爭取同一設備的有效占用，資料庫不允許兩筆都成功。這是 PostgreSQL 支援的機制；此處不是已套用的 migration。官方：Partial Indexes

資料模型還需要 equipment_id、borrower_id 的非空與外鍵，status 合法值約束，以及占用／歸還階段必要時間欄位的檢查。索引只解決「最多一筆占用」，不會替你檢查管理員權限或合法狀態轉移。

第六幕｜把成功與失敗都寫進 API 契約

阿哲沒有直接叫 AI「補上錯誤處理」，而是先要求列出使用者會遇到的結果。

請依 R1–R5 設計核准 API 契約。
列出成功、未登入、無權限、找不到、
狀態已改變、設備被占用的回應。
操作人從伺服器驗證的登入身分取得，不接受 body 的角色。

以上操作都先做管理員授權；錯誤不能包含 SQL、連線資訊或其他人的個資。員工查自己的紀錄另做 borrower_id 篩選，不能信任前端傳來的 userId。

美玲又問：「我按歸還後網路斷了，再按一次呢？」這讓阿哲看見重試不是少見例外，而是正常使用情境。同一結果可重回，不代表副作用可重做。

第七幕｜這次，請 AI 寫小一點

阿哲準備請 AI 寫完整專案，想了想改成：「先做核准這一條。」小切片比較容易審查，也容易用測試推翻。

依規格 v1，先產出 ApproveLoan 的服務流程。
保留條件更新、局部唯一索引衝突處理、稽核同交易。
標明示意碼和未實作依賴。不要宣稱測試通過。
另外列出：這段程式仍不能保證什麼。

// C# 風格示意碼；不是可直接編譯的實作。
RequireAuthenticatedAdmin(actor);
ValidateFutureDueAt(dueAtUtc);
await using var tx = await db.BeginTransactionAsync();
try {
    // 參數化 SQL：
    // UPDATE loans SET status='Approved', due_at=@due
    // WHERE id=@id AND status='Pending' RETURNING id;
    var changed = await ConditionalApprove(id, dueAtUtc);
    if (!changed) {
        // 同交易查明不存在或狀態衝突；不建立稽核
        throw await NotFoundOrConflict(id);
    }
    await InsertAudit(id, "Approved", actor.Id);
    await tx.CommitAsync();
    return Approved;
}
catch (PostgresException ex)
    when (ex.SqlState == "23505"
       && ex.ConstraintName == "ux_loans_one_active_equipment") {
    await tx.RollbackAsync();
    return EquipmentOccupiedConflict;
}
// 其他例外不得偽裝成占用衝突；交易 dispose 回滾，
// 由統一錯誤處理記錄安全診斷資訊並回適當錯誤。

同一筆申請被核准兩次時，條件更新只允許從 Pending 轉移；不同申請搶同一設備時，由索引限制。稽核與更新包在同一交易，才不會留下「核准成功，稽核卻失蹤」的半套結果。

EF Core 在支援交易的 provider 上，單次 SaveChanges 通常以交易處理；本例有多個操作，必須明確保證它們使用同一連線／交易。不能因為程式出現 BeginTransaction 就假定所有 helper 都參與了它。官方：Using Transactions

第八幕｜你坐到管理員的椅子上

美玲說：「程式我看不懂，但你讓我按一次，我就知道有沒有怪。」下面是只在這個網頁執行的狀態模型：不連資料庫、不登入、不寄信、不證明並行安全。它讓你看清規則造成的結果。

建議照順序按：核准 A → 核准 B → 領用 A → 時間超過期限 → 再核准 B → 歸還 A → 核准 B → 再歸還 A。

錯誤思路：
歸還任何借用 → equipment.available = true

本案思路：
確認這筆 loan 是否可歸還 → 轉移這筆 loan 狀態
設備是否占用 → 根據仍有效的 loan 判定

第九幕｜綠色勾勾，也可能只是畫出來的

AI 交出一張測試表，每列都寫「通過」。阿哲問：「你在哪個環境、用哪個版本、執行了哪個命令？」對方若拿不出紀錄，這些勾勾只能刪掉。

請產出測試案例，不要填入未執行的實際結果。
每例包含前置資料、操作、預期 HTTP、資料列與稽核斷言。
並行案例必須使用真實 PostgreSQL 的兩個獨立連線，
不能只用前端按鈕或記憶體 fake 宣稱通過。

並行測試要安排兩個工作者競爭，記錄回應、交易結果及最終資料；不要只依序呼叫兩次。使用隔離測試資料庫，不能在正式借用資料上試故障。

測試紀錄樣板（不是已執行結果）
程式 commit：
資料庫／provider 版本：
測試命令：
測試資料與隔離方式：
實際 HTTP：
最終 loan：
最終 audit：
結果：未執行 / 通過 / 失敗
失敗附件與重現方式：

預期：稽核失敗時 loan 維持 Pending。
實際：API 回 500，但 loan 變成 Approved。
附上：服務方法、交易建立處、兩個 helper 的連線取得方式。
請先提出可驗證的原因假說與檢查順序，
不要直接重寫整個專案，也不要斷言唯一原因。

第十幕｜交付不是把程式壓縮寄出去

星期五，美玲已經能說出「逾期不釋出」。阿哲準備交付，卻在舊資料中找到兩筆同設備的有效核准。若直接建立唯一索引，migration 會失敗。

他沒有讓 AI 自動刪掉其中一筆，而是產生衝突清單，請管理員確認真實借用狀態，保留修正紀錄。技術上的重複，不代表可以替業務決定哪筆是真的。

正式部署還需依資料量、維護窗口與實際版本確認 migration 策略。回滾不能只是「把索引刪掉」；那會拿掉保護，必須評估舊版程式與資料相容性。

依目前已確認內容產出交接摘要：
已完成（附證據）、未完成、已知限制、部署前必要檢查。
每項對應檔案或測試紀錄；沒有證據標註未驗證。
另外列出明天接手者的前三個動作。

終章｜你真正學到的，不是設備借用

美玲關上器材櫃：「下次再做請假系統，是不是把設備換成假單就好？」

阿哲笑了：「要帶走的是做事方法，不是照抄資料表。」

這些方法也能用在 Claude；本章是示範如何與 ChatGPT 協作，不是宣稱另一個產品沒有工作流程能力。

真正的吸收測試：不看上面，換一個規則

新需求：小晴已領用 P-001，想延長三天。員工可以提出延期，但只有管理員可核准。若設備已逾期，仍可申請；核准前原期限不變。

請先自行寫出：要問的問題、最小 Context、狀態／資料變更、兩個失敗情境及其可觀察斷言。不要只把「借用」換成「延期」。下方可寫草稿（不會自動儲存，離頁前請自行複製）。

六道容易答太快的口頭追問

沿用規格 v1。新增：員工可取消自己的 Pending。
Approved 的取消仍由管理員操作。
本輪只設計員工取消，不變更核准政策。
請列授權條件、條件更新、並行驗收與錯誤回應。