---
title: "Vibe Coding 一些小技巧：AI 是放大器，別讓它放大你的技術債"
description: "Vibe Coding 看似高效，但在 AI 輔助下可能放大缺陷，導致系統難以維護。本文探討為何紮實的軟體工程思維才是關鍵，並分享如何透過具體工程小技巧，避免創作出無法整合的資訊孤島，打造真正穩健的應用。"
canonical_url: "https://blog.markkulab.net/post/beyond-vibe-coding-ai-amplifier"
author: "Mark Ku"
author_url: "https://blog.markkulab.net/author/mark-ku"
site: "Mark Ku's Blog"
date_published: "2026-04-11T03:44:07.737Z"
category: "AI"
language: "zh-TW"
license: "CC BY 4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
attribution: "轉載或引用請註明作者並附上原文連結"
---
# Vibe Coding 一些小技巧：AI 是放大器，別讓它放大你的技術債
## 前言：Vibe Coding 的另一面
最近越來越多人在談 Vibe Coding，憑感覺寫 prompt、讓 AI 生成程式碼、快速拼湊出一個「能跑」的東西，乍看之下效率驚人，但以我的經驗來看，這種模式有時候容易忽略軟體工程中很核心的一個問題：可維護性。
軟體開發有個常被忽略的現實：真正的成本不在開發，而在維護。IEEE 的研究指出，軟體生命週期中有 60–80% 的成本發生在上線之後。「跑起來」只是起點，之後的 bug 修復、需求迭代、系統整合，才是真正耗時耗力的地方。
關於這個問題，業界已有不少觀察。Google Chrome 工程主管 Addy Osmani 說得很直接：Vibe Coding 和 AI 輔助工程是「根本不同的方法」。GitClear 分析了大量真實程式碼後也發現，AI 採用後複製貼上明顯增加、重構反而減少，最終形成一座座資訊孤島，程式碼品質看起來還行，但因為沒有人真正寫過、理解過，長期維護的負擔會越來越重。如果工程基礎不夠紮實，AI 的確可能在不知不覺中放大一些技術債。
這篇整理了六個我覺得值得投入的工程小技巧，分享給同樣在 Vibe Coding 浪潮裡摸索的你。
## 小技巧一：技術選型，先想清楚再動手
Vibe Coding 的節奏很快，有時候容易在「先跑起來再說」的心態下直接開工，等到後來才發現選的框架不適合當下場景，但對工具的特性有基本認識，確實能避免走一些不必要的彎路。
當然可以！以下是在**不大幅修改內容**的前提下，針對語意通順與排版進行優化的版本：
---
### 我的選型思路
**以我目前常用的全端框架：Next.js 為例**
Next.js 本質上是 React 與 Node.js 的整合，因為腳本程式語言簡單，若前後端都在同一個專案中，這使得 AI 在協助開發時能夠縮小 Context，更容易聚焦於單一功能的實作，而 LangChain 也支援 Node.js 版本，使得開發 AI Agent 應用相當方便。
不過，它也有幾個特性需要留意：
#### **單執行緒問題**
Node.js 主要是單執行緒語言，預設只會使用一顆 CPU 執行。因此，當網站流量增加時，可能出現阻塞情況。此時可以透過 `worker_threads` 來解決。
**常見場景：**
* 高流量時 API 回應突然變慢
* 執行大量計算（如圖片處理、資料聚合、排名計算）時，整個 Event Loop 被阻塞，導致其他請求卡住
`worker_threads` 的核心概念是將 CPU 密集任務交由獨立執行緒處理，主執行緒則持續負責其他請求，待計算完成後再透過 `parentPort.postMessage` 回傳結果。
```
主執行緒（Event Loop） Worker Thread
│ │
│ new Worker('./heavy-worker.mjs') │
│ ─────────────────────────────────▶│
│ │
│ 繼續處理其他請求（不阻塞） │ CPU 密集運算（獨立執行緒）
│ │
│◀─────────────────────────────────│
│ postMessage({ result }) │
│ │
```
#### **不適合超高併發或持久連線**
Next.js 的生命週期是 **by-request**，因此較不適合長連線服務、佇列、排程任務，例如 WebSocket、Queue、或排程任務（Cron Job）。
#### **平行運算與後端技術選擇**
在 Next.js 的 Server Side 中，可利用 Node.js 的 `worker_threads` 進行平行運算。針對複雜運算，小型專案基於共用性考量，我通常選擇使用 **NestJS**；而在大型專案中，則傾向採用 **C#** 來實作高效能且穩定的 API。
#### **Node.js 數字運算：小數與大數**
在處理金額、統計或加密等場景時，需要特別注意 JavaScript 的數值精度問題。可以透過精度數學函式庫解決，例如：`decimal.js`、`big.js`、`bignumber.js`。
#### **善用 `http-proxy-middleware` 簡化架構**
實務上常見為了解決 CORS 問題或隱藏後端 API 真實位址，而在 Next.js 中重複實作一層 API 轉發，增加了開發與維護成本。較為乾淨的做法是使用 `http-proxy-middleware`，讓 Next.js 的 API Route 純粹作為代理，將請求透明轉發至後端服務。
**整體請求流程如下：**
```
┌──────────────┐ /api/proxy/* ┌──────────────────────┐
│ │ ─────────────────────────▶│ Next.js API Route │
│ 瀏覽器前端 │ │ (proxyServer) │
│ │ ◀─────────────────────────│ │
└──────────────┘ 回傳後端回應 └──────────┬───────────┘
│
pathRewrite: │ 移除 /api/proxy 前綴
/api/proxy/users → /users │
▼
┌──────────────────────┐
│ 後端 API 服務 │
│ (NEXT_PUBLIC_API) │
└──────────────────────┘
```
**代理過程中會自動處理：**
1. **relayRequestHeaders** — 轉發 Cookie（含 Turnstile bypass token）
2. **relayResponseHeaders** — 攔截 `Set-Cookie` 並進行額外處理
3. **onError** — 記錄代理失敗的錯誤 Log
#### **useEffect 的副作用**
React 的 `useEffect` 若管理不當，容易產生重複的 API 請求，在快速開發時特別容易踩到此問題。
#### **Prefetch 預設開啟**
`` 元件預設會在列表頁面 prefetch 所有連結，當列表很長時，可能帶來大量背景 Request，需依實際場景評估是否關閉。
#### **多語系（i18n）支援容易**
Next.js App Router 搭配 `next-intl`，多語系設定門檻低。語系檔以 JSON 維護，透過 middleware 自動偵測語系並重導向，元件中使用 `useTranslations()` 取得字串，整體架構清晰，無需額外複雜設定即可支援多國語言。
#### **前端狀態管理的選擇**
* **小型專案**：使用 `useState` 並透過 props 傳遞即可。
* **中型專案**：當元件層級加深、出現 props drilling 時，推薦使用 **Zustand**，其 API 極簡、幾乎沒有 boilerplate，學習成本低。
* **大型專案**：若需要嚴格的 `action/reducer` 分離與 middleware 機制，可採用 **Redux Toolkit**，雖然已大幅減少樣板程式碼，但整體複雜度仍高於 Zustand。
#### **使用 TanStack Query 管理 Server State**
Client state 是可完全掌控的，但 Server state 僅是後端資料的快照，source of truth 仍在伺服器端。實務上，每個 API 呼叫都需處理 loading、error、retry、timeout 等流程，並面臨快取與跨元件同步的問題，例如：
* API 資料是否需要快取？
* 使用者切頁後是否需要重新請求？
* 是否需要背景 polling 以保持資料新鮮？
* 在 A 頁面 mutate 資料後，B 頁面如何同步更新？
過去這些邏輯常分散在 `useEffect` 與 `useState` 中，導致重複開發。**TanStack Query** 將整個請求生命週期（發送、快取、重試、失效、同步）轉為宣告式設定，只需定義 `staleTime` 與 `refetch` 條件，其餘交由框架處理。
再搭配統一的 API 回應格式（`success` + `error.code`），即可在 `QueryClient` 層實作全域錯誤攔截，例如：
* `AUTH-001`：自動導向登入頁面
* `RATE-001`：顯示限流提示
如此一來，無需在每支 API 中重複撰寫 `try-catch`，大幅提升開發效率與一致性。
**AI Agent 框架：LangChain / LangGraph**
LangChain 可以想成沒有畫面的 n8n：讓工程師透過程式碼快速串接各種 AI 模型和外部工具，用同一套介面在 OpenAI、Gemini、Claude 之間自由切換，不被單一廠商綁死。內建的 Memory、Tool Calling、RAG 等模組，讓常見的 AI 應用場景不用從零開始刻。
LangGraph 則是 LangChain 生態系中專門用來處理多狀態、有條件分支的 Agent 流程。當 AI 任務不是一路線性跑到底，而是需要根據中間結果決定下一步，比如「先判斷文章品質，品質不足就重新生成，通過才繼續產出音訊」，這種有分支、有回退的工作流，用 LangGraph 來建模會清楚很多。
**搭配 Langfuse** 可以做 AI 可觀測性（Observability），記錄每次呼叫的 prompt、回應、Token 用量、延遲，方便追蹤哪個環節花費最多、哪個 prompt 品質不穩，對於要持續優化 AI 行為的產品來說相當實用。
**樣式框架：Tailwind CSS**
Tailwind CSS 採用 Mobile First 的設計哲學，預設 selector 從手機尺寸出發，再透過 `md:`、`lg:` 等前綴往上覆蓋桌機樣式，跟傳統「桌機優先再往下 override」的思維相反，但在響應式開發上反而更直覺。
搭配它豐富的 utility helper，很多過去需要手刻 SCSS 的常見排版、間距、陰影，直接用 class 就能搞定，省下不少設計時間。
另外我通常會在國外平台買一套 Next.js + Tailwind 的 UI theme 當起點來開發，在整成自己想要的風格，這樣既有現成的元件可以用，開發也比較快速，日後如果要換框架或重構樣式，因為 utility class 本身耦合度低，遷移起來也相對容易
**資料庫：我個人傾向 PostgreSQL**
MongoDB 的靈活確實很吸引人，不用寫 Migration、Schema 隨時改、早期開發很快，但我自己用下來，Schema 沒約束這件事長期反而是個麻煩，資料品質很難保證，`$lookup` 又遠不如 SQL JOIN 好用。另外沒設好索引很容易觸發全表掃描（COLLSCAN），在 MongoDB Atlas 這類雲端服務上，除了直接噴掉讀取單位費用，還會撐爆記憶體，逼得系統自動升級到更貴的規格，帳單可能會飆得很快。
所以我大多數情況還是選 PostgreSQL，完整 ACID、原生 JOIN、工具鏈（Prisma / Drizzle）成熟，`jsonb` 欄位需要彈性結構時也能用。對我來說，在 PostgreSQL 裡補彈性比在 MongoDB 裡補關聯查詢容易多了。
MongoDB 我覺得比較適合：資料結構天生是 JSON 且沒什麼關聯（如日誌、CMS 設定）、或需要超大規模水平擴展的場景，長期要維護的產品，我還是傾向 PostgreSQL。
**語言：TypeScript 是維護性的基礎**
這個我覺得不太需要說服，用過就知道。TypeScript 的型別系統在 AI 大量生成程式碼的情境下更明顯有價值，型別錯了 IDE 直接紅線，不用等到 runtime 才爆，AI 也比較不容易生出「傳錯參數但 JavaScript 不報錯」這種靜默 bug。
對長期維護影響最大的是重構時，你改了某個介面，TypeScript 馬上告訴你哪些地方要跟著改，而不是靠人工記憶或跑測試才發現漏了。搭配 Prisma / Drizzle 的型別推導，連資料庫查詢的型別都有保障，整條鏈路都是型別安全的。
### 資料夾配置與 Helper / Service 分層
AI 傾向將邏輯就近放置於最近編輯的檔案，隨著時間推移，容易導致元件夾帶 API 邏輯、工具函式散落各處，使得修改單一功能時需同時調整多個位置。因此，應將此開發規範更新至 Claude.md（專案操作手冊），以提升 AI 產出的一致性與可維護性。
我通常在 Next.js 專案裡這樣拆層：
- `data/`：純資料存取（讀檔案、打 API、查 DB）
- `services/`：業務邏輯（跨資料源的組合與規則判斷）
- `lib/`：有一定規模的工具模組（可獨立測試）
- `utils/`：無副作用的純函式小工具（日期、數字格式化）
- `hooks/`：React 專屬的自訂 Hook
- `components/`：純 UI，不含業務邏輯
- `app/api/`：只做請求接收與回應格式化
這樣分層後，跟 AI 協作時也更容易說清楚要改哪一層，減少 AI 亂改到不相干的地方。
## 小技巧二：統一 API 回應格式，讓錯誤有跡可循
API 格式不統一是我遇過最常見的維護痛點之一。常見的情況是用 HTTP 200 包裝所有回應，錯誤只回傳一段 `message: "Something went wrong"`，出了問題根本不知道從哪查起。服務數量一多，這種混亂只會越來越難收拾。
### 我的做法
我參考 RFC 9457（一份描述 HTTP API 錯誤格式的業界標準），設計了統一的 API 回應結構，成功和失敗都有固定欄位：
```json
// ✅ 成功回應
{
"success": true,
"data": {
"userId": "u-20260410",
"name": "Mark Ku"
}
}
// ❌ 錯誤回應
{
"success": false,
"error": {
"type": "https://api.example.com/errors/auth",
"code": "AUTH-001",
"message": "Token 已過期，請重新登入",
"traceId": "req-7f3a-4b2c-9d1e"
}
}
```
幾個我覺得比較實用的設計：
- 錯誤碼加領域前綴：`AUTH-001`（認證）、`IDM-4001`（身份管理）、`ORD-2003`（訂單），一眼就知道問題出在哪個服務
- traceId 貫穿全鏈路：從 API Gateway 到後端服務用同一個 traceId，跨服務除錯不再像大海撈針
- HTTP Status Code 如實反映：401 就是 401，不要再用 200 包裝錯誤
### 效益
API 行為變得可預測，前端可以用統一的錯誤處理邏輯。出錯時，拿著 `AUTH-001` 和 `traceId` 就能快速定位問題。
## 小技巧三：用 Keycloak 打造穩固的身份認證基石
Vibe Coding 的特性是快速生成、快速驗證，但副作用之一是容易產生大量各自獨立的小系統，每個 side project 或微服務都是一個全新的開始。系統數量一多，整合就成了最大的痛點，每個服務各有一套登入機制，用戶體驗碎片化，維護成本也急速上升。
身份認證是系統安全的第一道防線，以我的經驗，自行開發登入模組不僅複雜、耗時，更容易在「感覺差不多」的心態下埋入安全漏洞。常見的情境是：每個服務各自實作一套認證邏輯，Token 驗證方式不統一、Session 管理散落各處，出了問題很難追查。
### 實際怎麼導入
Keycloak 是 Red Hat 旗下的開源身份管理平台（IAM），支援 OAuth2、OpenID Connect，可以做為整個系統的認證中心，讓各服務不用各自實作登入邏輯。我的做法是用它集中管理所有服務的認證與授權：
- 社群登入：透過 Identity Brokering 功能，快速整合 Google、GitHub、Facebook、Line 等第三方登入，建議啟用 matching email 自動帳號連結
- 多租戶隔離：Keycloak 26+ 已支援 Organization 功能，為 SaaS 產品建立獨立的登入環境
- 安全強化：啟用 MFA（多因素認證）、嚴格驗證 Redirect URL、開啟登入事件監控
整體互動流程如下：
```
┌──────────┐ ① 登入請求 ┌──────────────┐
│ │ ──────────────────▶ │ │
│ 前端 App │ │ Keycloak │
│ │ ◀────────────────── │ (IdP Hub) │
└──────────┘ ⑤ JWT Token └──────┬───────┘
│
② Identity │ Brokering
│
▼
┌──────────────┐
│ 第三方 IdP │
│ Google / │
│ GitHub / │
│ Facebook │
└──────┬───────┘
│
③ OAuth2 授權 │
④ 回傳用戶資訊 │
▼
(回到 Keycloak
發行 JWT Token)
```
### 效益
認證集中到 Keycloak 之後，各服務只需驗證 JWT Token，不用再各自造輪子。出問題時也有登入事件監控可以查，比過去各自為政好追多了。
## 小技巧四：讓 AI 成為你的重構及測試夥伴，而非債務產生器
直接把程式碼丟給 AI 說「幫我重構」，有時候效果不如預期。GitClear 的數據顯示，AI 採用後程式碼重構行為反而減少了不少。Qodo 的調查也指出，很多開發者反映重構時 AI 缺少足夠的上下文，容易產生看似合理但實際上破壞既有行為的修改。
問題不在 AI 不夠聰明，而在於我們給它的指引不夠精確。
### 實際怎麼跟 AI 協作
核心概念是：先補測試，再交給 AI 重構，最後跑測試確認沒有回歸。讓 AI 在有安全網的範圍內工作，而不是讓它自由發揮。
第一步，先為既有程式碼補測試（確保行為有被覆蓋）：
```typescript
// 假設有一個計算折扣的函式，邏輯有點亂但「能跑」
// 重構前，先確保測試覆蓋其行為
describe('calculateDiscount', () => {
it('VIP 會員打 8 折', () => {
expect(calculateDiscount(1000, 'vip')).toBe(800)
})
it('一般會員無折扣', () => {
expect(calculateDiscount(1000, 'regular')).toBe(1000)
})
it('金額為 0 時回傳 0', () => {
expect(calculateDiscount(0, 'vip')).toBe(0)
})
})
```
第二步，小範圍請 AI 重構，人工審查：
```typescript
// 重構前
function calculateDiscount(amount: number, type: string): number {
if (type === 'vip') {
return amount * 0.8
} else if (type === 'svip') {
return amount * 0.7
}
return amount
}
// AI 重構後 — 人類審查確認邏輯不變，可讀性提升
const DISCOUNT_RATE: Record = {
vip: 0.8,
svip: 0.7,
}
function calculateDiscount(amount: number, type: string): number {
const rate = DISCOUNT_RATE[type] ?? 1
return amount * rate
}
```
### 效益
這樣能避免改完才發現行為偷偷跑掉。重點不是不用 AI，而是把測試當安全網，讓 AI 在這個範圍內發揮。
## 小技巧五：AI 生成的程式碼，別忘了資安掃描
AI 生成的程式碼有時候量很大，靠人工逐行 review 安全問題其實來不及，以我自己的經驗，AI 有時候會生成看起來沒問題但實際上有潛在風險的程式碼，像是直接拼字串組 SQL、把 secret 硬寫進程式、或是開了太寬鬆的 CORS 設定，這些如果沒有掃描機制，在 code review 時很容易漏掉。
### 實際怎麼掃
目前我主要用兩個方式來補這個缺口：
**1. 用 Claude Skill 做 code review**
直接請 Claude 針對生成的程式碼做資安角度的審查，找出潛在的 SQL Injection、XSS、Hardcoded Secret、權限漏洞等問題，比讓人工盯著看省力很多。
**2. 整合開源 CLI 進 CI/CD Pipeline**
把資安掃描工具接進 pipeline，讓每次 PR 或 push 自動跑，常見的選擇有：
| 工具 | 用途 |
|------|------|
| `Semgrep` | 靜態分析，支援多語言，規則可自訂 |
| `Trivy` | 掃描 container image、dependency 漏洞 |
| `Gitleaks` | 偵測是否有 secret / token 不小心進了 repo |
| `npm audit` / `pnpm audit` | 檢查 npm 套件的已知安全漏洞 |
掃描接進 pipeline 之後，每次 PR 都會自動跑一輪，不用靠人工記得。
### 效益
AI 生成的量越大，資安漏洞被忽略的機率就越高。把掃描自動化之後，這件事就不再依賴人工的細心程度，出問題前就能被擋下來。
## 小技巧六：為API訂閱打下基礎，導入 API Gateway（Kong），實現關注點分離，
AI 時代，打造自己的 SaaS 變得容易，但以我的經驗，沒有工程基礎，光靠 Vibe Coding 很難撐過複雜度的門檻。功能越疊越多，改 A 壞 B，認證、限流、日誌各自為政，重複的邏輯散落各處，出了問題也不知道從哪查起。
這正是我之前在 [Kong API Gateway 架構驗證](https://blog.markkulab.net/post/kong-api-gateway-architecture-verification) 中碰到的痛點，但每個服務各自實作一套，看起來都能跑，但維護起來很吃力。
### 導入方式
API Gateway 是一個位於所有後端服務前面的統一入口，把認證、限流、日誌等共用邏輯集中處理，讓每個後端服務只需專注自己的業務邏輯。Kong 是目前最成熟的開源選項之一。
整體架構如下：
```
┌─────────────────────────────────┐
│ Kong API Gateway │
│ │
┌──────────┐ │ ┌───────────┐ ┌────────────┐ │ ┌──────────────┐
│ │ Request │ │ JWT │ │ Rate │ │ │ User Service │
│ Client │ ────────▶ │ │ 認證驗證 │─▶│ Limiting │──│──▶ │ │
│ │ │ └───────────┘ └────────────┘ │ └──────────────┘
└──────────┘ │ │ │ │
│ ▼ ▼ │ ┌──────────────┐
│ ┌───────────┐ ┌────────────┐ │ │ Order Service │
│ │ Logging │ │ Request │──│──▶ │ │
│ │ 統一日誌 │ │ Transform │ │ └──────────────┘
│ └───────────┘ └────────────┘ │
│ │ ┌──────────────┐
│ ─│──▶ │ Payment Svc │
│ │ └──────────────┘
└─────────────────────────────────┘
```
### 效益
後端服務能專注於核心業務邏輯，不用再各自造輪子，所有流量政策集中管理，新服務上線時只需在 Kong 設定路由和 Plugin 就好，省了很多重複工作。
## 結論
Vibe Coding 的問題不在於用了 AI，而在於有時候容易跳過工程思維。軟體真正在解決的是複雜性，梳理需求、設計邊界、討論取捨，這些過程 AI 目前還沒辦法替代。
這六個方向都不是什麼新發明，它們在 AI 出現之前就存在，只是在 Vibe Coding 盛行的當下，反而更值得再想一次。選型想清楚、回應格式統一、認證集中管、重構有測試保護、資安自動掃、流量統一入口，每一個拿出來都不難，但疊在一起，就是讓 AI 幫你放大能力，而不是放大負擔的差距。
## 參考資料
- [Addy Osmani - Vibe Coding Is Not AI-Assisted Engineering](https://medium.com/@addyosmani/vibe-coding-is-not-the-same-as-ai-assisted-engineering-3f81088d5b98)
- [InfoQ - AI Amplifying Engineering（2025 DORA Report）](https://www.infoq.com/news/2026/03/ai-dora-report/)
- [GitClear - AI Copilot Code Quality 2025](https://www.gitclear.com/ai_assistant_code_quality_2025_research)
- [IEEE - Software Maintenance Implications on Cost and Schedule](https://ieeexplore.ieee.org/document/4526688/)
- [Qodo - State of AI Code Quality 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/)
- [RFC 9457 - Problem Details for HTTP APIs](https://www.rfc-editor.org/rfc/rfc9457)
- [Keycloak - Server Administration Guide](https://www.keycloak.org/docs/latest/server_admin/index.html)
- [Keycloak 筆記 - HackMD](https://hackmd.io/@ming1230/S1FXl3WjY)
- [Kong 官方文件](https://developer.konghq.com/gateway/)
- [Mark Ku - Kong API Gateway 架構驗證](https://blog.markkulab.net/post/kong-api-gateway-architecture-verification)
---
## 關於本文與作者
本文出自 [Mark Ku's Blog](https://blog.markkulab.net/post/beyond-vibe-coding-ai-amplifier)
授權條款： [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — 轉載或引用請註明作者並附上原文連結
### 關於作者
**[Mark Ku](https://blog.markkulab.net/author/mark-ku)** — Software Solution Provider
- 10+ 年資深軟體工程師，現為 AI 應用 Builder
- 專注大型平台架構設計，從北美電商到AI SaaS訂閱收費系統
- 結合 AI Agent 與自動化，打造高效可演進的產品技術基礎
### 作者開發的免費工具
以下工具皆可免費使用：
- [免費 PDF 簽名工具](https://blog.markkulab.net/tools/pdf-sign): 線上 PDF 簽名工具，瀏覽器內完成手繪、打字、上傳簽名，可拖曳放置、縮放、下載。所有處理都在你的裝置完成，檔案不會上傳。
- [VS Code Refactory](https://blog.markkulab.net/tools/refactory): Refactory 是一款 VS Code 重構擴充套件：34 個重構動作、37 條 code smell 檢查、Code Health 儀表板、18 種語言、534 支測試。懂你的專案慣例：介面放哪、DI 註冊寫在哪、'use client' 該不該加；還會用 git 修改頻率 × 複雜度排出「該先修哪個檔案」，並一鍵把壞味道交給你自己電腦上的 Claude Code 修。免費使用，原始碼不離開你的機器。
- [DB-Kit 資料庫管理工具](https://blog.markkulab.net/tools/db-kit): DB-Kit 是一個用 Tauri + Rust + React 打造的輕量跨平台資料庫管理工具，用單一一致的介面同時管理 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle、SQLite、MongoDB、Redis、Kafka、Elasticsearch 與 RabbitMQ 十一種資料來源：連線密碼以 OS keychain 加密、SSH Tunnel、完整 CRUD、視覺化查詢建構器、多結果集同時顯示、跨連線資料傳輸與比對同步、Excel / CSV 匯入匯出、執行計畫視覺化、ER 圖、排程備份、SQL 壓力測試（p50～p99 延遲百分位）、15 條規則的 SQL 審查、Kafka 訊息瀏覽與監控告警；繁中 / 英文雙語介面，內建 AI 助手（自然語言生成 SQL、AI 審查與調校建議）與命令列工具 dbk。免費開源（MIT），提供 Windows / macOS / Linux 安裝檔。
- [VS Code Super Mermaid](https://blog.markkulab.net/tools/super-mermaid): Super Mermaid 是一款 VS Code 擴充套件：開箱即用的漂亮 Mermaid 圖表，自動上色、即時預覽、滑鼠平移縮放、PNG / SVG 高解析匯出，內建 21 種範本與多種主題。免費開源（MIT）。
- [React Super Mermaid](https://blog.markkulab.net/tools/react-super-mermaid): react-super-mermaid 是一個開源 React 元件庫：一行 即可渲染漂亮的 Mermaid 圖表，內建 colorful / sketch 主題、平移縮放、圖內搜尋、SVG / PNG 高解析匯出。輕量、SSR 安全、完整 TypeScript 型別。免費開源（MIT）。
- [Jira / Confluence Super Mermaid](https://blog.markkulab.net/tools/jira-super-mermaid): Atlassian Forge app：在 Jira issue 與 Confluence 內文直接寫 Mermaid 語法，畫流程圖、時序圖、狀態機與甘特圖。11 種圖表、SVG / PNG 匯出、明暗主題、完整中日韓文字支援。取得 Runs on Atlassian 資格：圖表存在你自己的站台，app 不呼叫任何第三方服務。免費，即將上架 Atlassian Marketplace。
- [Mermaid 線上預覽](https://blog.markkulab.net/tools/mermaid-preview): 在瀏覽器裡寫 Mermaid、即時看圖，整張圖表壓進網址就能分享。免註冊、不上傳伺服器，相容 mermaid.live 的分享連結。
- [React Intl Phone Number](https://blog.markkulab.net/tools/react-intl-phone-number): react-intl-phone-number 是一個開源 React 元件：framework-agnostic、不依賴 antd，提供 E.164 進出、可搜尋國旗 / 國碼下拉、可配置驗證等級（strict / mobile-strict / loose）、可主題化 CSS 與 i18n，電話邏輯由 google-libphonenumber 驅動。輕量、完整 TypeScript 型別。免費開源（MIT）。
- [Uptime Kuma Cluster](https://blog.markkulab.net/tools/uptime-kuma-cluster): 把單機版 Uptime Kuma 改造成高可用叢集：OpenResty + Lua 智慧負載平衡、MariaDB 共享狀態、健康檢查與自動 Failover，附叢集管理 REST API，一行 Docker Compose 啟動。免費開源（MIT）。
- [特教專案](https://blog.markkulab.net/education): 為特殊教育學生製作的學習教材
### 每日 Podcast
- [科技新鮮事](https://blog.markkulab.net/category/tech-news): 每日精選 AI 與科技趨勢，透過語音摘要快速掌握最新技術動態，涵蓋 AI 應用、軟體架構、DevOps 與工程實戰。 — RSS: https://blog.markkulab.net/feed.xml
- [AI股市蝦聊](https://blog.markkulab.net/category/ai-stock-chat): 每個交易日用 AI 分析台股盤勢，以雙人對話聊當天的盤中觀察與隔日預測。 — RSS: https://blog.markkulab.net/ai-stock-chat/feed.xml
### 電子報
[訂閱電子報](https://blog.markkulab.net/subscribe) — 第一時間收到新文章通知，無垃圾信、隨時可取消訂閱。