Quartz 5

工具-曳光彈開發

Properties1
tagssoftware, craftsmanship, architecture, development

8 min read

🎯 什麼情境該想到我

當你面對一個大又不確定的系統，不知從何下手、擔心各部分兜不起來時。

⚙️ 怎麼用

「曳光彈」是先射一發能看見軌跡的子彈來校準——在軟體上就是先打通一條最細的端到端路徑（能跑、能驗證），再逐步長肉。

  1. 做一個 walking skeleton：從 UI → 邏輯 → DB 的最小可運作骨架，貫穿所有層與整合點。
  2. 及早暴露整合風險：端到端先通，最難的「各部分兜不兜得起來」提前驗證。
  3. 在骨架上增量長出功能。

曳光彈 ≠ 原型：曳光彈是保留並持續發展的真實骨架；原型是探索用、用完即丟。

★ 為什麼「端到端先通」比「單元完整」重要

❌ 分層開發：先把 DB 層做完 → 再做邏輯層 → 再做 API → 最後接前端
   ★ 最大的風險（各層接不接得起來、需求對不對）留到最後才暴露
   ★ 而且前三個月沒有任何「能跑的東西」可以展示或驗證

✅ 曳光彈：先打通一條「最細但完整」的路徑
   前端一個按鈕 → API → 一條業務邏輯 → 一張表 → 回傳 → 畫面顯示
   ★ 第一週就知道：技術選型行不行、各層接得起來嗎、部署流程通嗎

★ 核心價值是「把最大的不確定性提前」，而不是「快速做出東西」。
它是風險管理工具，不是開發速度工具。

★ 骨架該包含什麼（判準很明確）

□ ★ 貫穿「所有層」：UI → API → 業務邏輯 → 資料存取 → 資料庫
□ ★ 貫穿「所有整合點」：認證、第三方 API、訊息佇列、快取
□ ★ 包含「部署」：能真的部署到一個環境並被存取
□ ★ 包含「測試」：至少一個端到端測試跑得起來
□ ★ 包含「可觀測性」：log、metric、trace 從第一天就接上

★ 最後兩項最常被跳過，但它們是骨架價值的一半——
能跑但無法測試、無法觀測的骨架，不是可以長肉的骨架。

★ 曳光彈 vs 原型（這個區分是實質的）

★ 曳光彈原型 Prototype
目的★ 驗證「架構可行」並成為正式基礎★ 探索「這個想法對不對」
品質★ 正式品質（只是功能少）可以很髒
之後★ 保留並持續長肉★ 丟棄
範圍很窄但很深（貫穿所有層）可能很寬但很淺
測試★ 有通常沒有

★★ 最危險的錯誤：把原型當曳光彈用。
「這個 demo 看起來能跑，就直接接著做下去吧」——
那些為了 demo 而走的捷徑（寫死的資料、沒有錯誤處理、沒有測試）會永遠留在系統裡。
決定一個東西是原型還是曳光彈，要在「開始寫之前」就講清楚。

★ 怎麼選第一條路徑

選不選
★ 技術風險最高的那條（用了沒經驗的技術、整合最複雜的）最簡單的那條
★ 能驗證核心假設的那條最有商業價值的那條（那是第二優先）
貫穿層數最多的只在單層內的

★ 例：做一個 AI 客服系統

第一條曳光彈不該是「登入功能」，而該是
「使用者問一句話 → 檢索 → LLM → 回應 → 顯示 → 記一筆 trace」——
因為那條路徑上有所有的未知數。

★ 之後怎麼長肉

骨架通了之後：
① 在骨架上「加寬」——同一層再加功能（第二個 API、第三個查詢）
② 需要時「加深」——把某一層做紮實（快取、批次、最佳化）
★ 每一次都保持「隨時可部署、隨時可 demo」

★ 這正是 保持可以發布 與持續交付的思路：
系統永遠處在「能動」的狀態，只是功能多寡不同。

★ 它解決的三個真實問題

問題怎麼解
整合地獄整合從第一天就存在，而不是最後才發生
★ 回饋太慢使用者/PM 第一週就看得到東西，需求誤解提早被發現
團隊不知道進度「骨架通了」是一個明確的里程碑

🧪 我實際套用的紀錄

  • 2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

  • ★★ 不要讓它變成原型。骨架的每一行都是正式程式碼，捷徑會留下來。
    → 有測試、有錯誤處理、有 code review。
  • ★ 骨架必須「窄」。貫穿所有層，但每一層只做最少的事。
    骨架太寬 = 你其實是在做完整功能，失去了「快速驗證」的價值。
  • 不要跳過部署。「在我機器上能跑」的骨架沒有驗證到最大的風險之一。
  • 需求極度不明確時，原型才是對的。曳光彈假設你知道要做什麼、不確定的是「做不做得出來」；
    如果不確定的是「該做什麼」，先做丟棄式原型。
  • 既有系統不適用。曳光彈是新專案的手法；既有系統要用 工具-接縫 與絞殺者模式。
  • ★ 骨架通了不代表風險沒了。規模、效能、邊界情況的風險還在——它驗證的是「可行性」不是「可用性」。

🔗 相關工具

Graph View

Backlinks