某次同事處理交易建立 API 時，系統突然出現 SQL Server 唯一鍵衝突。第一個直覺通常是：「是不是查詢重複資料的 SQL 壞了？」但往下追查後，真正的問題其實是兩個請求都認為資料不存在，接著一起嘗試新增。
資料庫只是最後那個說「不行」的人。
這類問題不能只靠捕捉 SQL 例外解決，也不能把責任全部推給前端重複送出。比較完整的做法，是先確認重複請求如何進入系統，再把交易建立流程改成冪等：同一筆請求不管送來幾次，系統都只建立一筆資料，並回傳一致的結果。
先確認我們到底看到了什麼
當 SQL Server 回報 2601 或 2627，能確定的事情只有一件：系統嘗試寫入一組已經存在的唯一鍵。
它不能直接證明：
* 使用者連點兩次按鈕。
* 前端程式重複送出。
* 代理伺服器自動重試。
* 兩個請求一定同時執行。
* 第一個請求已經完整成功。
兩筆內容相同的 HTTP POST，只能證明接收端收到了兩個請求。至於它們是同時抵達、逾時重送，還是第一次成功後又送了一次，
在實際開發環境中，一套系統通常不會只有一個程式專案。
隨著系統持續發展，常常會拆成：
* Web 專案
* API 專案
* Batch / Console Job
* SQL Script
* 共用 Library
* 開發文件
* OpenSpec 規格
* AI Skill
* 團隊共用 Skill
而這些專案也不一定放在同一個資料夾底下。
例如：
D:\
├─ Projects\
│ └─ WebApp\
│
├─ DatabaseScripts\
│
E:\
├─ Tools\
│ └─ BackgroundJob\
│
└─ SharedAI\
└─ TeamSkills\
對一般 IDE 而言，這不一定是問題。
但當主要開發流程逐漸改成透過 Codex 協助時，就會遇到另一個需求：
如何讓 Codex 在同一個工作範圍內，同時理解並操作這些分散在不同位置的專案？
這篇文章記錄我最後使用 Windows mklink 建立整合 Workspace
AI Coding Agent 執行速度很快，但需求沒有明確規格時，結果容易偏離預期。這篇整理 SDD、OpenSpec 與團隊導入方式。
馬斯克提出把 AI 資料中心送上太空。這篇從散熱、晶片在輻射環境中的壽命（測試估計為 1.5 到 2 年），以及軌道維護三方面討論工程可行性。
DebugDiag Tools 是 Microsoft 提供的免費工具，可在 Windows 收集與分析應用程式的記憶體洩漏、當機和效能問題。
