Cheng's Tech & Life

你有沒有遇過這種狀況：叫 Claude Code 改完檔案，結果忘了跑 formatter，code review 被打回來的全是 style issue？ 或者更痛的——Claude 很盡責地幫你改了五個檔案，你說「好了可以了」，它就真的停了。然後你才發現 test 沒跑、lint 沒過、有一個 .env 被改到。 Hooks 就是拿來解決這類問題的。它不是什麼 AI 魔法，反而是整套 Claude Code 裡面最不 AI 的部分——純粹的 shell 腳本，在特定時間點被觸發，做你設定好的事情。確定性的行為，不靠 LLM 判斷。 概念：Hook 是什麼？一句話講完：在 Claude Code 生命週期的特定節點，自動執行你寫的腳本。 跟 Git hooks 很像。pre-commit hook 在 commit 前跑 lint，Claude Code 的 PreToolUse hook 在工具執行前跑你的檢查。概念相通，只是觸發的時機不一樣。 目前支援的 hook 事件超過 20...

凌晨兩點，手指一滑開了 bypass 模式，Claude Code 像脫韁的馬一路跑。跑得很順——直到它跑出一句 rm -rf 把半個 repo 幹掉。 不誇張，bypass 模式（bypassPermissions）跳過所有工具執行確認，效率直接拉滿，但副作用也很直接：AI 可能在你沒注意的時候送出 force push、hard reset，甚至砍掉整個 .git。這不是理論風險，是踩過坑的人才會去設防的東西。 這篇記錄一套雙層防護架構：permissions.deny 規則 + PreToolUse Hook 腳本，讓 bypass 模式既保留速度，又不會在關鍵時刻翻車。 第一層：permissions.deny — 粗粒度攔截在 ~/.claude/settings.json 直接用 pattern matching 把最危險的指令擋掉： 12345678910{ "permissions": { "deny": [ "Bash(rm -rf *)", ...

半夜十一點，deploy 跑到一半你想離開電腦去倒杯水。以前的選擇是：盯著螢幕等它跑完，或者賭一把直接走開祈禱不要炸。現在多了第三個選項——拿起手機繼續操作。 這就是 Claude Code Remote Control 在做的事。 不是雲端，是你的電腦先講最關鍵的一點。Remote Control 不是把你的 session 搬到雲端跑。它的運作方式是：你的本地終端機繼續執行，手機或瀏覽器只是一面「遠端鏡子」。你的 filesystem、MCP Server、專案設定，全部都還在本機上，沒有任何東西飄到雲端去。 跟 Claude Code on the Web 不一樣。那個是直接跑在 Anthropic 的雲端基礎建設上，你不需要本地有任何東西。Remote Control 則是讓你已經在跑的 local session，從另一台裝置接手操作。 用白話講：你在公司的終端機上開了一個 Claude Code session，搭捷運的時候拿手機繼續下指令，到家之後開筆電的瀏覽器接著做。對話紀錄全程同步，你在哪個裝置送出的訊息，其他裝置都看得到。 三種啟動方式Remote...

110 億美金——不是哪家新創的估值，是 IBM 買一家做 Kafka 的公司的價格。同一週，OpenAI 讓模型直接操作你的電腦，MCP 的安全問題被搬上資安大會。三月下旬這幾則消息串在一起，隱約有條線：AI 不再只是對話框裡的助手了，它正在嵌進系統骨架裡。 IBM 砸 110 億美元把 Confluent 吃下來3 月 17 日，全現金收購，每股 31 美元，溢價 34%。 Confluent 做的是企業級 Apache Kafka 即時資料串流，全球 6,500 多家企業在用，Fortune 500 裡面占四成。IBM 買它的邏輯很直白：AI Agent 要即時做決定，背後的資料不能是昨天的。但現實是，很多企業的模型到現在還在吃 batch processing 吐出來的東西，延遲動輒幾小時。需要即時反應的場景？根本跟不上。 收購完成後，Confluent 會整進 IBM watsonx.data，讓模型和 Agent 吃到持續更新的資料流，同時帶上血緣追蹤跟政策管控。IBM 官方的說法是解決「data latency gap」。 110 億不是小數目。Confluent...

寫 SQL、跑查詢、複製結果、貼給 AI、等回覆、發現少撈了一個欄位、再跑一次。這個迴圈跑過三輪以上的人，大概都會冒出同一個念頭：讓 AI 自己去查不就好了？ DBHub 就是幹這件事的。Bytebase 團隊開源的資料庫 MCP Server，裝上去之後 AI 直接透過 MCP 協定存取資料庫——查結構、跑 SQL 都行，你不用再當中間人搬運資料。 支援的資料庫MSSQL、MySQL、PostgreSQL、MariaDB、SQLite、Oracle，涵蓋範圍比預期廣。安裝走 npx 或 Docker 都行。 安裝方式專案級安裝連線資訊只在當前專案目錄下生效，不會跨專案污染。 MSSQL： 1claude mcp add dbhub --scope project -- npx @bytebase/dbhub --transport stdio --dsn "sqlserver://user:password@host:port/database" MySQL： 1claude mcp add dbhub --scope project -- npx...

最近在幫 Claude Code 設定 MCP Server 的時候，用到了 Google 官方出的 chrome-devtools-mcp 這個工具，主要是拿來做瀏覽器的自動化驗證。安裝指令裡用的是 npx 而不是 npm install，一開始我還沒特別在意，但後來仔細研究才發現，這兩者的行為差異其實直接影響到版本更新策略。這邊把我整理的筆記記錄一下。 npm install vs npx 到底差在哪？說實話，剛開始學 Node.js 的時候，我也搞不太清楚 npx 跟 npm 的差別，總覺得都是裝套件用的。但其實它們的設計理念完全不同。 簡單來說，npm install 會把套件下載到 node_modules/ 資料夾裡，持久保存在本地。而 npx 的概念則是「臨時下載、執行完就可以不管了」。 幾個關鍵差異整理一下： 版本解析時機：npm install 安裝時解析一次版本就固定了；npx 加上 @latest 的話，每次執行都會重新解析，自動抓最新版 磁碟空間：npm 裝了就佔空間；npx 用完可能會被快取策略清掉 啟動速度：npm 因為已經在本地了所以快；npx...

❓ 什麼是 ABA 問題？ABA 問題發生在使用 CAS（Compare-And-Swap）時： 執行緒 A 讀到某個變數值為 A 執行緒 B 將該變數從 A ➝ B ➝ A 執行緒 A 再次使用 CAS，認為值沒變，繼續執行，但其實值已變動過！ 這會導致程式誤以為狀態未變，但實際上已經被其他執行緒修改過。 🧰 解法：使用 AtomicStampedReferenceJava 提供 AtomicStampedReference<T>，這是一種「附加版本號（stamp）」的原子參考，可以避免 ABA 問題。 它在每次變更時，都會同步更新一個 stamp 值，用來追蹤版本。 🧪 範例程式碼123456789101112131415161718192021222324252627import java.util.concurrent.atomic.AtomicStampedReference;public class AbaProblemSolution { public static void main(String[] args)...

📌 一、什麼是「原子性變數」與 CAS？在多執行緒環境下，多個執行緒若同時修改同一個變數，容易發生資料競爭。 Java 提供 java.util.concurrent.atomic 套件，裡面有許多「原子操作」的變數類型，例如： AtomicInteger AtomicLong AtomicReference 這些類別提供 非阻塞（non-blocking） 的操作方式，底層就是使用 CAS（Compare-And-Swap，比較並交換） 實作的。 ⚙️ 二、CAS 的核心邏輯CAS 是一種樂觀鎖策略，基本流程如下： 讀取目前值 比對是否與預期值一致 若一致，就更新為新值 若不一致，就放棄（重試或結束） ✅ 優點：不用 synchronized 就能寫出安全的多執行緒操作 ❌ 缺點：高併發時可能需要一直 retry，自旋過多會浪費 CPU 💡 三、實際範例：用 CAS 實作「無鎖計數器」1234567891011121314151617181920212223242526272829303132333435363738import...

在這篇文章中，我想跟各位分享一個相當有趣又實用的 SQL 查詢範例。這支查詢主要用來檢查資料庫中各個資料表的 Identity 欄位（通常作為主鍵使用）的目前值（last_value），並根據該欄位的資料型態來推算其可能達到的最大極限值。 查詢範例以下就是完整的 SQL 查詢程式碼： 12345678910111213141516SELECT OBJECT_NAME(ic.object_id) AS TableName, ic.name AS IdentityColumn, ic.last_value AS CurrentValue, CASE WHEN ty.name = 'tinyint' THEN 255 WHEN ty.name = 'smallint' THEN 32767 WHEN ty.name = 'int' THEN 2147483647 ...

💡 Purpose: 此 SOP 說明如何從原始資料表進行備份、建立新表、資料遷移以及重新命名，目的是因應原資料表主鍵未設定自動遞增，需先備份資料，再依新的 DDL 語法建立自動遞增主鍵的表結構，最後將資料還原。請務必在每個步驟執行前確認相關操作已備份完成，以避免資料遺失。 前置檢查步驟 0：檢查表結構與資料筆數 取得資料表結構，確認是否已有自動遞增主鍵。 1exec sp_columns WCSTXXX; 檢查主鍵（例如：WCSID）是否有重複筆數： 1234select WCSID, COUNT(*)from WCSTXXXgroup by WCSIDhaving COUNT(*) > 1; 檢查資料表的總筆數： 1select COUNT(*) from WCSTXXX; 注意： 請將檢查結果記錄下來，作為後續參考依據。 備份原始資料步驟 1：備份現有資料表 將現有資料完整備份至另一張暫存表中，避免後續操作造成資料遺失： 1select * into backup_WCSTXXX from WCSTXXX; 建立新資料表步驟...