> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# 你的技術棧清單交付不了你的產品

上百位開發者把我的技術棧清單存進書籤——清單沒寫出來的，才是讓一套 Windows 桌面工具在 48 小時內上線的底層管線。

_釋出於 2026-10-12._
_更新於 2026-10-27._

> **技術棧清單越長，交付就越快嗎？**
> 這取決於清單漏掉了什麼。技術棧清單只列出工具名稱，並不會裝好它們的邊界——已驗證的 Webhook、租戶範圍限定、釋出簽名——而專案恰恰卡在這些接縫上。照抄的清單複製了工具，卻沒有整合。清單可以當作調研選單，但通往可交付產品的路是經過測試的管線工程，無論你如何獲得它。真正該問的是：你的每個晚上值多少錢。

## 書籤陷阱

前幾天我在 X 上回了一則貼文，貼出自己實際在用的技術棧——我的“2026 獨立開發技術棧”，一篇回覆塞了十幾款工具。[這則回覆](https://x.com/noah_z_zhang/status/2114919719538978934)收進一百多個書籤，還順帶替這個網站送來一百多次點擊。

後台資料就沒那麼好看了：多數訪客掃過一頁就走。技術棧清單讀起來像一份完工的計畫，可照抄的清單什麼也交付不了——每個工具仍然要安裝、要跟相鄰的工具接線、要測試，工具之間的接縫才是那幾週真正流失的地方。

這篇才是那些書籤真正想找的文章：不是我跑哪些工具，而是哪些底層管線早已能承重——以及它讓我在四十八小時內交付了什麼。


## 專案真正死在哪裡

多數獨立專案不是死在核心功能上。它們死在第一週，死在跟點子毫無關係的基礎設施上。動力的半衰期大約四十八小時——每有一小時沒花在產品本身，燒掉的都是單人開發最稀缺的資源。

那一週的形狀一致得驚人：

- 第一天：monorepo 目錄結構、ESLint、`tsconfig` 路徑、資料庫遷移。
- 第三天：還泡在支付服務商的文件裡，想把 webhook 冪等做對。
- 第五天：想加個桌面或移動版的配套應用——一條新的建置管線、一個新的驗證面、從零開始的自動更新。


## 一次端到端的 48 小時建置

上週我交付了 [SpinShare](https://spinshare.dev)，一套 Windows 原生桌面小工具：在檔案總管裡拖起一個檔案，按一下 Shift，游標底下直接彈出放射狀選單；放開就執行一次本機轉換或操作。不彈視窗、不上傳，檔案從頭到尾不離開這台機器。

真正值得檢視的是時間線：新開倉庫、Rust 核心邏輯、在現有計費軌道上接好離線授權流程、送進微軟商店審核——核心開發一共四十八小時，全程和 agent 結對寫程式，幾乎沒調過 prompt。Agent 沒翻車，原因一點也不光鮮：最容易讓它胡思亂想的架構邊界，早就封進我自己的 kit——supastack 裡了。

接下來是一筆帳：那兩天裡不必現做的管線工程。


## 安裝與護欄

`pnpm setup` 把環境引導壓成一條指令：預檢、環境變數對齊、依賴安裝、資料庫遷移。不存在“先花一個晚上拼出可用環境”這回事——倉庫要麼通過自己的檢查清單，要麼直接點名缺了什麼。

`.ai/` 鏡像文件、`AGENTS.md` 和 `.agents/skills/` 是一份寫給 agent 而非人類的契約——每個套件的職責邊界、測試規則與紅線（桌面應用是單 webview 殼層，絕不分叉產品 UI）。[專案結構指南](https://supastack.dev/zh-tw/docs/web/project-structure.md)展示了它讀到的目錄結構；[agent 工作流程文章](https://supastack.dev/zh-tw/blog/building-saas-with-a-coding-agent.md)講的是工作節奏。

寫下來的邊界，才是 agent 不會亂闖的邊界。


## 計費與釋出開箱即用

八個計費介面卡站在同一套契約後面——Stripe、Creem、Polar、Dodo、Lemon Squeezy、Paddle、Whop 和 PayPal——`webhook_event` 帳本讓每一筆結算在變成許可證或郵件之前都先驗簽且冪等。我的工作從它的下游才開始：按訂單數切換的 Early-Bird 檔位，以及 Ed25519 簽名的離線許可證金鑰——桌面工具必須不透過網路呼叫也能啟用。[計費模組指南](https://supastack.dev/zh-tw/docs/modules/billing.md)記錄了我擴充的那條流程。

釋出側同樣平淡無奇，而這正是重點。Tauri 2 管線——`desktop-release.yml`——建置簽章過的安裝包，並透過 minisign 產生 `latest.json`，為 Windows（NSIS 和 msi）、macOS（dmg）和 Linux（AppImage）提供 stable 與 beta 通道。我唯一親手做的封裝，是替微軟商店打的一個 MSIX；其餘內容[桌面端快速上手](https://supastack.dev/zh-tw/docs/desktop/ship-in-5-minutes.md)都講了。


## 使用者真正感受得到的那 10%

這是技術棧清單藏起來的算術：一個產品需要的東西里，大約九成是使用者永遠看不見的底層管線。看不見的管線正是地基應該扛的工作——也是唯一扛得動的部分。剩下的，才是產品。

因為我的地基已經在承重，四十八小時幾乎全部投進了使用者能感受到的那一成——這些工作塞不進任何一則技術棧留言，也絕不會在一週都耗在 webhook 和簽章上的時候發生：

- 用 Rust 寫的 Windows OLE 拖曳鉤子，選單只在真的拖著檔案、按住 Shift 時才待命——打字時絕不觸發。
- 多視窗系統匣流程，讓工具永遠離一次按鍵之遙，工作列上卻不留視窗。
- 放射狀選單的動畫，調到看起來是“瞬間出現”而不是“在播動畫”為止。
- 三十多個本機格式轉換器，每個都配了自己的單元測試。


## 務實的部分：定價與透明度

那個站得住腳的質疑是：“我有 Cursor——為什麼還要花錢買一份技術棧清單？”在你的時間還沒標價之前，它都成立。兩個晚上耗在 webhook 冪等上，代價就是你沒交付的那個功能。

關於透明度：[文件](https://supastack.dev/zh-tw/docs/web/ship-in-5-minutes.md)全部公開——目錄結構、雙 Web 引擎、跨平台同步、全部八個計費介面卡、AI 路由。我寧可讓懷疑者從頭讀到尾再走掉，也不想讓人衝著標題下單；[用腳手架還是從零開始](https://supastack.dev/zh-tw/blog/starter-kit-or-from-scratch.md)是這個決定最誠實的版本。

兩件務實的事：顯示價格已包含 $100 首發優惠，結帳支援支付寶。還有 50% 開發者返現——六十天內做出真實產品上線，公開分享開發故事（在 X、Reddit、YouTube 或類似平台拿到 5,000 次自然瀏覽或 50 個自然按讚），把連結透過電子郵件寄給我：退你一半，許可證照樣歸你。規則在[上線返現條款](https://supastack.dev/terms#launch-cashback)。


## 關於技術棧清單的常見問題

每當這套 kit 出場，同樣的質疑就會浮上來。它們值得正面回答。

- agent 不能幫我把這些全部生出來嗎？ — 它能產生看似合理的東西，但沒辦法一次跑通就驗證接縫。冪等的 webhook 是測出來的，不是產生的——腳手架只會把同一份清單再遞給你一次。
- 樣板不會讓產品變得千篇一律嗎？ — 管線是共享的，產品不是。SpinShare 的拖曳鉤子、系統匣行為和轉換器在 kit 裡根本不存在——客戶看到的那一成永遠是你的。
- 如果我只需要一個 Web 應用呢？ — 反正買的都是這套 kit；移動端和桌面端是可以採用也可以無視的端面，不是硬性要求。SpinShare 能存在，正是因為桌面那個端面早就建好了。
- 一套桌面小工具真的能代表買家故事嗎？ — 這是我手上最短的誠實例子：從空倉庫到商店送審只用兩天。同一套管線同樣服務 SaaS——[上線檢查清單](https://supastack.dev/zh-tw/blog/saas-launch-checklist.md)是更長的版本。
- 為什麼不直接把技術棧清單公開？ — 已經公開了：[技術棧指南](https://supastack.dev/zh-tw/docs/web/tech-stack.md)寫明每個選擇和理由。清單是菜單，不是計畫——本文的論點是，值得買的是一份已經蓋好的計畫。