身為一個每天跟 LINE Messaging API、LIFF 混在一起的 .NET 開發者，我必須說 2026 年這個五月到七月，LINE 官方明顯是把「改版」這件事當成連續劇在更新，一集接一集，還時不時來個「未完待續」。這篇就把這段期間比較有感的更新，一次幫大家整理清楚，順便碎念幾句。

一、Rich Menu 終於有「數據」可以看了，不用再靠感覺

7 月 1 日這天，Messaging API 新增了兩支端點：取得 rich menu 洞察總覽、取得每日洞察數據。以前如果你的圖文選單是用 Messaging API 建的，你只能默默祈禱使用者有點下去；現在終於可以像用 LINE Official Account Manager 建的選單一樣，看到「顯示次數」跟「點擊次數」了。有趣的是官方特別強調，這兩套數據是互不相通的：API 建的選單看不到後台的數據，後台建的選單也看不到 API 的數據。所以如果你們家專案是兩種方式混用，記得數據要分開看，不然老闆問起「圖文選單成效」，你可能要交出兩份報告。

二、Rate Limit 被砍到只剩 0.5%，這是要逼死誰

這大概是整個五月最有戲劇張力的一則公告。5 月 7 日官方先預告：Get rich menu list 這支端點的速率限制，將從每秒 2000 次，改成每秒 10 次。沒錯，你沒看錯，是從 2000 掉到 10，砍幅超過 99%。然後 5 月 26 日，這件事真的發生了。

Get rich menu list
之前：2,000 requests / 秒
之後：   10 requests / 秒

如果你的系統有那種「每次使用者互動就順手查一次 rich menu 清單」的懶惰寫法，這波更新等於直接把你的架構考卷發回來重寫。建議是把清單資料快取起來，別再每次都問 LINE 要清單，畢竟現在問一次的成本，可能比你想像中貴很多。

三、LINE MINI App 內購：免費試用期結束，該收錢了

LINE MINI App 的應用內購買功能，原本佛心來著開放免費使用到 6 月底，官方在 6 月 5 日先預告、7 月 1 日正式上路：從 7 月 1 日之後的交易開始收取服務費用，費率則是以你申請當下公告的費率為準。同時官方也順手修訂了《LINE 應用內購買服務條款》，主要是把費用計算與請款結算方式講得更清楚。如果你們家產品有掛 MINI App 內購，這波記得回頭檢查一下財務試算，別讓會計部門措手不及。

四、日本認證 MINI App 可以跟 Business Manager 組織「牽紅線」了

6 月 10 日這則比較偏在地化：日本地區的已驗證 MINI App，現在可以把 MINI App 頻道連結到 Business Manager 組織，進而跟同組織底下的其他服務（目前支援 LINE 官方帳號）做整合。條件不少，包括地區都要設成日本、服務提供者跟已發布資料的營運公司要一致等等，細節偏繁瑣，但方向很明確：LINE 想把底下這些帳號體系越串越緊，官方也說未來會開放更多整合功能，值得先卡個位。

五、開發者帳號終於可以「刪除」了，但這是不歸路

6 月 24 日的更新算是補了一個长期缺口：LINE Developers Console 終於支援刪除開發者帳號。不過這裡有個重點要劃起來——刪除之後不能復原。而且如果你是某個 Provider 或 Channel 底下唯一的 Admin，刪除前系統會要求你先把權限交接給其他帳號，不然那個服務就等於被鎖死，沒人能再進去改設定。所以與其說這是「刪除帳號」功能，不如說它是一個「離職交接檢查表」，公司內部帳號有異動的話，記得先做好交接再按下去。

六、LIFF 悄悄升級了兩次，但你可能完全沒感覺

5 月 13 日發布 LIFF v2.29.0，6 月 29 日再發布 v2.29.1，兩次都寫著同一句話：只調整 SDK 內部行為，功能沒有變化。這種更新最適合「设了自動更新就不用管」，如果你是走 CDN edge path（https://static.line-scdn.net/liff/edge/2/sdk.js），會自動吃到新版；如果是 npm 使用者，記得手動更新一下：

npm install @line/liff@2.29.1
# 或
yarn add @line/liff@2.29.1

雖然官方說功能沒變，但內部行為調整這種話，老實講我都會半信半疑地多測一輪回歸測試，你們也是吧？

七、LIFF 瀏覽器大改版：多分頁圖示退場，換成三顆點點

5 月 19 日這則跟 UI/UX 關係最大：從 LINE 26.7.0 版開始，LIFF 瀏覽器的標頭規格整個翻新。原本那顆代表「多分頁檢視」的按鈕圖示，換成了直式三個點的選單圖示；點下去也不再直接跳去分頁畫面，而是彈出一個下拉選單，裡面塞了全部分頁、重新整理、最小化瀏覽器、分享、加到主畫面、我的最愛、權限設定、關於此服務、回報問題等一長串選項。另外，已驗證 MINI App 原本在標頭上的「最小化」按鈕，現在被收進下拉選單裡，原本的位置換成了「關閉」按鈕。如果你的 MINI App 有針對舊版標頭做過任何客製化引導教學或截圖說明，這波更新後這些素材大概都要重拍一輪了。

八、五月那場 LIFF/MINI App 事故：一段從 4/27 燒到 5/14 的小插曲

最後提一下背景插曲：4 月 27 日到 5 月 14 日之間，Android 版 LINE 26.6.0 / 26.6.1 有個 bug，導致在特定情境下（LIFF 瀏覽器開著時，用 Intent 或 App Link 又叫出同一個或另一個 LIFF/MINI App）會拿不到使用者 profile、LIFF API 也會怪怪的。官方後來在 5 月 14 日推出修復版 LINE 解決問題，但在那之前也貼心提供了一段暫時解法，用 location.href 做頁面轉跳、並在偵測到類似 invalid_request 的錯誤時手動登出再登入：

const params = new URLSearchParams(location.search)
const liffState = params.get('liff.state')
const redirectUri = liffState
  ? new URL('.' + liffState, location.href).toString()
  : location.href

liff.login({ redirectUri })

這種「先給暫時解法、再補正式修復」的節奏，其實蠻值得學起來——不管是自己開發的服務出包，還是等第三方修 bug，先讓使用者有路可走，永遠比讓他們卡死畫面來得體貼。

小結：這波更新告訴我們什麼

整體看下來，這兩個月 LINE 平台的更新可以歸納成三個關页字：限流變嚴、收費上路、體驗微調。速率限制被砍等於在提醒大家該做快取就要做；MINI App 收費代表商業模式正式進入下一階段；LIFF 的一連串小改版則是提醒我們，前端串接這種東西永遠不能「串完就沒事了」，得定期回去看看官方公告，免得哪天使用者截圖來問你「這個按鈕怎麼不見了」，你才第一次知道有這回事。

https://code.claude.com/docs/zh-TW/overview

安裝 claude code (命令提示字元)

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

OpenRouter 註冊

https://openrouter.ai/ 註冊新帳號

OpenRouter 使用在claude code的說明

https://openrouter.ai/docs/guides/coding-agents/claude-code-integration

.claude/settings.local.json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "<your-openrouter-api-key>",
    "ANTHROPIC_API_KEY": ""
  }
}

加上 “ANTHROPIC_MODEL”:”openrouter/free” (使用系統分配，或是到model 搜尋免費 free https://openrouter.ai/models?q=free)

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "<your-openrouter-api-key>",
    "ANTHROPIC_API_KEY": "",
     "ANTHROPIC_MODEL":"openrouter/free"
​
  }
}

開啟 claude code

經營一個網站超過十年，就像是看著一個孩子長大一樣，充滿了滿滿的感情與回憶。這十多年來，我的WordPress網站一直忠實地陪伴著我，但也面臨著需要「轉大人」的考驗。

最近，我下定決心要將網站的底層引擎升級到全新的PHP 8.5，希望能讓網站跑得更快、更順暢，給大家更好的體驗。沒想到，過程卻像是在闖關打怪一樣充滿挑戰！其中最大的一個關卡，就是一個叫做hacklog remote attachment的老套件。它就像是一個充滿回憶但也捨不得搬家的老頑固，不管我怎麼嘗試，它就是無法適應新的環境，導致我的升級計畫一直卡關失敗。

正當我感到有些頭痛，差點要舉白旗投降的時候，我想起了現在最厲害的好幫手，也就是人工智慧AI！我轉念一想，何不請AI來當我的專屬工程顧問呢？於是，我帶著這個老套件的難題，和AI進行了一場深度的跨界交流。

沒想到，AI真的超級神！在它的耐心引導與程式碼微調之下，我們居然成功解開了這個老套件的心結，讓它順利跟上了時代的腳步。當畫面上顯示升級成功的那一刻，我真的感動到想從椅子上跳起來歡呼！

這不僅僅是一次系統的升級，更是我親身見證科技帶來無限可能的一刻。遇到困難真的不要氣餒，轉個彎，或許就會發現新的解法。有時候，只要一點點正向的信念，加上善用身邊的新工具，原本看似無解的難題也能迎刃而解！讓我們一起保持開放的心，快樂迎接每一天的挑戰吧！

先說背景：ChatGPT 有多誇張？

OpenAI 過去一年把資料庫規模擴大了 10 倍，要支撐的是高達 8 億月活躍用戶。這個量級是什麼概念？整個系統底層用的是 Azure Database for PostgreSQL，也就是微軟雲端上的 PostgreSQL 託管服務。 PostgreSQL 這個開源資料庫，平常我們可能覺得它就是個「普通關聯式資料庫」，但這次的故事告訴我們：只要配置得當，它真的可以撐到超大規模。

問題一：讀取副本老是跟不上主節點

什麼是讀取副本（Read Replica）？

簡單說，就是把資料庫「複製一份」給其他伺服器來分擔讀取流量，這樣主節點就不用一個人扛所有查詢。ChatGPT 的架構裡，一台主節點撐著超過 50 個分布在多個地區的副本，這數字已經很嚇人了。

發生了什麼問題？

在 OpenAI 某次大型服務上線前，工程師發現一個詭異現象：副本的資料會「越落越遠」，跟不上主節點的更新速度（這叫做 Replication Lag，複製延遲），而且它不會自己恢復，只能靠重啟副本才能解決，然後一天內又再次發生——陷入一個惡性循環。

問題的根源是什麼？

深挖之後，找到了罪魁禍首：TCP 壅塞控制演算法。 預設的 CUBIC 演算法在偵測到封包遺失（跨地區傳輸本來就難免）時，會把傳輸速度猛踩煞車，拼命退讓，導致複製速度大幅下降。

怎麼解決？

微軟團隊做了三件事：

• 把壅塞控制演算法從 CUBIC 換成 BBR（對封包遺失更不敏感）
• 調整 TCP 視窗大小設定
• 引入**公平佇列（Fair Queuing）**網路排程，讓封包傳送更平滑 這三招組合拳下去，問題就解決了。

問題二：讀副本超過 50 個後怎麼辦？

微軟加入了**串聯副本（Cascading Replica）**支援，讓副本可以再複製給下一層副本，不用所有副本都直接連主節點。這樣就能在不影響主節點的情況下，繼續橫向擴展讀取能力。 此外，他們還開發了一個新技巧：從同地區的另一個副本快照建立新的異地副本，避免過去需要跨地區大量複製資料（可能要花幾小時甚至幾天）的痛苦。

問題三：寫入量太大，單台主節點 IOPS 不夠了

讀取問題解決了，但寫入量的成長讓單台 PostgreSQL 主節點的 I/O 效能上限捉襟見肘。這也是為什麼 OpenAI 後來把部分適合拆分的新工作負載移到 Azure Cosmos DB（NoSQL）去了。 但問題是，有些資料就是很難拆分（sharding 困難），這時候怎麼辦？ 這就帶出了微軟的新架構：Azure HorizonDB，在 2025 年 11 月進入私人預覽。

Azure HorizonDB：為超大規模打造的 Postgres

這是目前最令人興奮的部分。HorizonDB 從根本上重新設計了 PostgreSQL 的儲存層，核心概念叫做「以 WAL 為中心的儲存模型」。

WAL 是什麼？

WAL（Write-Ahead Log，預寫日誌）是資料庫記錄「我要做什麼改變」的日誌，用來確保資料不會因為系統崩潰而遺失。PostgreSQL 傳統上是先寫 WAL、再把資料頁寫到磁碟。

HorizonDB 的創新在哪？

PostgreSQL 的計算節點不再直接寫資料頁到磁碟，所有持久化都透過 WAL 完成，資料頁由獨立的儲存層負責重建。 儲存層分成兩個獨立服務：

計算節點變成無狀態引擎

最妙的是，這個架構讓 PostgreSQL 的計算節點從此「輕裝上陣」——備份、複製、Checkpoint 等繁重工作全部交給儲存層，計算節點只需要專心處理業務邏輯，CPU、磁碟、網路資源都省下來了。 讀取副本也不再需要各自保存一份完整的資料拷貝，瞬間就能建立新副本，且每多一個副本完全不影響主節點效能。

總結：從這件事可以學到什麼？

這篇文章最有價值的地方，不只是技術細節，而是工程師解決問題的思路： 先找根本原因，而不是用重啟來掩蓋問題（TCP 壅塞控制的案例）。一步一步拆解問題，先解讀取延遲、再解讀取擴展、最後解寫入擴展。為未來設計，HorizonDB 的架構不是為了應付今天的問題，而是為了更大的明天。 PostgreSQL 在 8 億用戶的規模下能正常運行，背後是無數工程師的調校與創新。下次有人說「PostgreSQL 不能水平擴展」，你可以把這篇故事講給他聽。

原文來源：Microsoft Community Hub — Supporting ChatGPT on PostgreSQL in Azure（2026/1/29）

這次更新到底在改什麼？

簡單來說，就是 Claude Code 在 Windows 上存放「企業管理設定檔」的資料夾位置換了。 這個設定檔叫做 managed-settings.json，是企業 IT 團隊用來統一管理、控制 Claude Code 行為的重要檔案。

• 舊路徑（即將停用）： C:\\ProgramData\\ClaudeCode\\
• 新路徑（請更新到這裡）： C:\\Program Files\\ClaudeCode\\managed-settings.json 3 月 12 日之後，系統就不會再去讀取舊路徑的檔案了。也就是說，如果你的 IT 部門沒有在期限前更新部署位置，之前設定的企業管理規則就會全部失效！

誰需要採取行動？

並不是所有人都需要動作。 這件事主要影響的是：

• 公司有 IT 部門負責集中管理 Claude Code 設定的企業用戶
• 使用 MDM（行動裝置管理）或端點管理工具（例如 Intune、Jamf 等）來部署 managed-settings.json 的組織 如果你只是個人用戶，或是公司根本沒有部署這個設定檔，那這次更新對你沒有任何影響，不用緊張。

IT 同仁需要怎麼做？

步驟其實很簡單，就一件事：

在 2026 年 3 月 12 日之前，將你的 MDM 或端點管理工具的部署路徑，更新為新的路徑： C:\\Program Files\\ClaudeCode\\managed-settings.json 如果你已經完成了這個更新，那就什麼都不用再做了，大功告成！

小結

這次的改動說複雜不複雜，說簡單也要注意別錯過截止日期。如果你負責公司的 IT 管理，記得趕快去確認部署設定有沒有更新；如果你只是一般使用者，把這篇文章轉給你的 IT 同事就對了！ 總之，3 月 12 日這個日期記起來，別讓企業設定白白失效了。

資料來源：Anthropic 官方通知信件

話說有個工程師，平常就是那種會把什麼都拆開來看的人。他在用 Claude 的時候心裡一直有個疑問：

「Anthropic 說 Max 20× 方案有 20 倍用量，但……20 倍是哪個 20 倍啊？」

於是他開始挖。沒想到，他在 API 的回應資料裡發現了一個「忘記四捨五入」的小數：

0.16327272727272726

一般人看到這個數字：「哦，好像是 16% 左右。」

這位工程師看到這個數字：「等等，這個數字精確得有點可疑……」

然後他就把 Claude 的整個內部計費系統給挖出來了。就這樣。

先說結論：誰才是真正划算的方案？

作者把幾個方案的「實際用量」給算清楚了，結果讓人頗為傻眼：

每 5 小時的用量上限

每週的用量上限

看到了嗎？Max 5× 根本是在送福利，每週用量比官方宣稱的多了超過六成！

反觀 Max 20× 就比較尷尬了——每 5 小時確實給你 20 倍，但每週的總量上限，說好的 20 倍，實際只有 16.67 倍。更糟的是，Max 20× 每週能做的事，也只有 Max 5× 的兩倍，但價格卻是兩倍。所以 CP 值根本沒有更好。

結論：Max 5× 才是甜蜜點，Max 20× 的星號（*）是有原因的。

跟直接用 API 比呢？

好，那如果你是開發者，直接用 Anthropic 的 API 付錢，跟買訂閱方案比起來差多少？

也就是說，你花 100 塊買 Max 5×，等於在 API 上用了 1,354 塊的量。

這還只是「保守估計」。因為有個東西叫做快取（Cache）：

• 你和 Claude 聊天時，之前說過的話會被暫存起來（快取）。

• 下次 Claude 回答時，可以直接讀取快取，不用重新處理。

• 用 API 的話：讀快取也要付費（收正常費用的 10%）。

• 用訂閱方案的話：讀快取完全免費！

如果你在用 Claude Code（讓 Claude 自動幫你寫程式、改程式），每次它呼叫工具、做操作，都會重複讀取大量快取。這種情況下，訂閱方案的實際效益可以高達 API 費用的 36.7 倍。

三十六點七倍。你沒看錯。

他到底是怎麼挖出這些數字的？

這才是文章最有趣的部分，來聽工程師辦案過程：

第一步：發現可疑現場

作者做了個 Chrome 擴充套件，方便自己查看 Claude 的使用量。在研究過程中，他發現 Claude 在生成回應時，會在背景偷偷傳一個數字給瀏覽器，代表「你已經用掉的比例」，長這樣：

 0.16327272727272726

一個正常工程師會把這個數字四捨五入，顯示成「16%」就好了。但 Anthropic 的工程師忘了這樣做，把原始數字直接送出來了。

而這個原始數字，其實是：你用掉的量 ÷ 總上限

第二步：用數學魔法還原分數

這個小數點背後，藏的是一個分數。比如 0.5 背後是 1/2，0.333... 背後是 1/3。

但 0.16327272727272726 背後是什麼？

作者用了一個叫做 Stern-Brocot 樹 的數學演算法。這個方法就像在玩「猜數字」遊戲，但它特別聰明——它會優先猜「簡單」的分數，因為電腦系統內部用的數字通常都是整數，分母不會是天文數字。

這個演算法跑了幾十步之後，找到了答案：

449 / 2750

驗算：449 ÷ 2750 = 0.16327272727272726 ✓ 完美吻合！

第三步：收集更多證據，確認總上限

分母 2750 是什麼意思？就是那個時間點的「總上限比例分母」，但因為分數會被化簡，不一定是真正的上限。

所以作者在不同的使用量下，重複採樣了很多次，對所有還原出的分母取最小公倍數（LCM）。

當這個最小公倍數不再增加的時候，答案就出現了：3,300,000

這就是 Max 5× 方案每 5 小時的真實 Credits 上限。

第四步：搞清楚「Credits 是什麼」

知道了上限之後，還要知道「每次對話到底會消耗多少 Credits」。這部分作者就靠老派方法了：大量手動測試、記錄數據、列表格、盯著看、問 Claude、問 GPT、提假設、驗證假設……

最後他得出了這個公式：

 消耗的 Credits = 無條件進位（輸入 Token × 輸入費率 + 輸出 Token × 輸出費率）

費率的部分，跟 API 定價的比例完全一致：Opus 最貴、Haiku 最便宜，輸出 Token 是輸入的 5 倍。

這件事告訴我們什麼？

對使用者的啟示：

• 能買訂閱方案就買，CP 值遠勝 API。

• Max 5× 是最划算的選擇，Max 20× 沒有成比例地更好。

• 如果你在跑 AI 代理程式（像 Claude Code），省下的快取費用更是驚人。

對工程師的啟示：

• 側通道洩漏（Side Channel Leak）真的無所不在。Anthropic 只是忘了把兩個數字四捨五入，結果被人把整個計費架構給挖出來了。

• 這不是駭客攻擊，不需要入侵任何系統，只需要一點數學和一點好奇心。

最後

作者在文章結尾說了一句話，頗有意思：

「截至撰文時，那兩個浮點數還沒有被四捨五入。我猜如果這篇文章引起足夠的關注，這種情況可能不會持續太久。到時候我會有點難過，因為這樣我的擴充套件就沒辦法那麼精準了。」

翻譯成白話就是：「我剛剛把 Anthropic 的底細公開在網路上，我猜他們很快就會把漏洞補起來，然後我的工具就沒這麼好用了。但這篇文章我還是要發。」

工程師的浪漫，大概就是這樣吧。

解決方案

如果你的 ngrok 網址顯示攔截，請直接檢查你的 vite.config.ts。你必須顯式地將 ngrok 提供的 domain 加入「允許名單」中：

// vite.config.ts
export default defineConfig({
  server: {
    allowedHosts: [
      'a134-211-72-118-118.ngrok-free.app' // 替換為你當前的 ngrok 網址
    ]
  }
})

 為什麼我們要關注這個設定？

從公司治理與資安維護的角度來看，這項調整背後有兩個關鍵思考：

1. 防止 Host Header 攻擊：Vite 預設不再信任隨機的 Host 請求。這能有效避免惡意網站利用瀏覽器漏洞，在使用者不知情的狀況下，與本地開發環境通訊並竊取原始碼或環境變數。

2. 開發環境的最小權限原則：雖然 ngrok 方便，但隨意開放外部存取內網環境是有風險的。透過 allowedHosts 的明確宣告，我們能確保開發者清楚知道哪些外部網域正在與本地服務互動。

技術小提醒

在測試結束後，記得將該設定移除或將其移至 .env 進行管理，切勿將特定 ngrok 網址永久硬編碼在 code 中並推上主分支，保持乾淨且安全的 Repo 是每一位資深工程師的素養。

祝大家今天開發順利，Bug 自由！

#Vite #ngrok #FrontendDevelopment #資安意識 #DNSRebinding #軟體研發管理 #WebSecurity #TypeScript

GitHub Copilot CLI 是什麼？

• GitHub Copilot CLI 就是把 Copilot 搬進 terminal 裡，讓你不用開 IDE 也能在命令列裡問問題、要指令、請它幫你搞定各種工作。​

• 作者分享會在陌生語言或新專案裡，用它幫忙「怎麼 build」、「怎麼下某個 shell 指令」，甚至讓它生成一個超大 lorem ipsum 檔來當 demo 測試檔案，省下一堆時間。​

安裝其實很簡單，只要一行 npm：

之後在 terminal 打 copilot 就能啟動 CLI，把它當成會寫文件、會記指令、偶爾還會幫你作弊查指令的搭檔就對了。​

先把 Copilot CLI 用爽：Banner、指令與互動

每次啟動都看到那個帥氣 Banner

預設 Copilot CLI 的動畫 banner 只有第一次出現，但作者表示：這麼帥的東西當然要每次看。​

有兩個做法：

• 到 C:\Users\USERNAME\.copilot\config.json（WSL 則是 ~\.copilot\config.json），把 "banner" 設成 "always"。​

• 啟動時改下指令：copilot --banner。​

在 Copilot CLI 裡直接跑 shell 指令

進到 Copilot CLI 之後，你輸入的每一行其實都是在跟 agent 聊天。那如果只是想跑個命令怎麼辦？
答案是：指令前面加一個驚嘆號 !。​

• 例如：!git status、!ls，就會直接在 Copilot CLI 裡跑 shell command。

• 好處是不用頻繁切來切去，可以一邊問 Copilot「我要怎麼做」，一邊直接執行它建議的指令。​

把 Windows Terminal 變成 Copilot 專屬套房

建一個「GitHub Copilot 專用 Profile」

作者的做法很簡單粗暴又實用：​

1. 複製現有的 PowerShell profile。

2. 改名字跟 icon（例如叫「GitHub Copilot」）。

3. Starting directory 設成你平常放專案的資料夾。

4. Command line 後面加上 -c copilot，例如：

   text

   "C:\Program Files\PowerShell\7\pwsh.exe" -c copilot


   這樣一開這個 profile，就自動進入 Copilot CLI，不用再多打一行指令。​

用 pane 分割：一半 Copilot，一半 shell

如果你想一邊跟 Copilot 聊天，一邊在另一個 shell 動手做，可以善用 Windows Terminal 的 pane 功能：​

• 按住 Alt 再從 profile 下拉選單開啟新 profile，就會以分割 pane 方式打開。

• 要關掉 pane 的話，用 Ctrl + Shift + W 即可。​

對多 repo、microservices、或 dev/test 併行的人來說，pane 基本上就是多工的救星。

啟動就回到上一次的工作現場

開發時最痛苦的就是「重開一次，原本開了哪些 tab 都不見」；作者直接把 Windows Terminal 的 Startup 設定改成「Restore window layout and content」，讓 Terminal 重啟時自動還原上次 tab 佈局。​

對正在 debug 或 demo 的人來說，這個設定等於幫你省下一輪「再把環境全部打開一次」的懲罰。

背景圖 + 復古掃描線特效

• Windows Terminal 支援每個 profile 設不同背景圖，也可以在 Defaults → Appearance 當中設一張所有 profile 共用的背景圖。​

• 想要懷舊一點，可以開啟「Retro terminal effects」，讓文字帶一點發光跟掃描線效果，兼具情懷與中二感。​

Prompt 也要穿得體面：Oh My Posh 上場

光只有 Copilot 不夠，terminal prompt 本身也要有點「生活品質」：這時候就輪到 Oh My Posh。​

裝好 Oh My Posh + Nerd Font

• 安裝 Oh My Posh（作者偏好用 winget）：

  bash

  winget install JanDeDobbeleer.OhMyPosh --source winget
```[1]


• 接著下載一套 Nerd Font，作者愛用 Caskaydia Cove，你也可以選自己喜歡的字型，再到 Terminal 裡把該字型設定成 profile 的字型。​

選一個主題，變成你的個人看板

• 官方主題列表在 Oh My Posh 官網，挑一個順眼的主題後，在 PowerShell profile 裡加上像下面這樣的一行：

  powershell

  oh-my-posh init pwsh --config "THEMENAME" | Invoke-Expression


  之後每次開 PowerShell 都會套用這個主題。​

• 作者自己還貢獻了一個叫「cinnamon」的主題，可以把現在 Spotify 播放的歌顯示在 prompt 上，對邊聽音樂邊寫 code 的人非常友善。​

用 segment 把資訊塞進一行 prompt

Oh My Posh 的強項在於各種 segment，像是：​

• Git segment：直接在 prompt 顯示目前 branch、diff 狀態、是否有未提交變更等。

• npm、React segment：顯示目前使用的 npm 或 React 版本。

• 音樂、甚至健康狀態 segment 都有，terminal 直接變成迷你 dashboard。​

在 prompt 上看 Copilot 使用量：Copilot segment

如果你是 Copilot 重度用戶，可能會好奇自己 quota 用了多少。從 Oh My Posh 28.1.0 之後，可以新增 GitHub Copilot segment，在 prompt 上顯示 Copilot premium 配額使用百分比。​

作法大致是：

1. 從官方主題（例如 1_shell）複製一份 JSON 當自訂主題。​

2. 在右側對齊的 segments 列表中加入一個像這樣的物件：

   json

   {
"type": "copilot",
"template": "  {{ .Premium.Percent.Gauge }} ",
"cache": {
"duration": "5m",
"strategy": "session"
},
"properties": {
"http_timeout": 1000
}
}
```[1]


3. 在 PowerShell 裡跑一次 oh-my-posh auth copilot 做認證，之後 prompt 上就會出現一個小小的 Copilot 使用量 gauge。​

這樣你就可以一邊寫 code，一邊默默觀察自己今天「抄作業」抄了多少。

收尾：讓命令列變成你的開發主場

整篇下來，可以看到作者的核心理念很簡單：​

• Copilot CLI 讓你在 terminal 裡有一個隨叫隨到的 AI 搭檔。

• Windows Terminal 的 profile、pane、背景與啟動設定，讓你把工作流變成一鍵啟動。

• Oh My Posh 則把 prompt 升級成資訊看板，再加上 Copilot segment，命令列不只是黑框白字，而是你的開發 cockpit。​

如果你每天都會開 terminal，那這些設定多花的那幾分鐘，很可能會在未來幾個月裡幫你省下好幾小時的來回切換和查指令時間。下次打開 Windows Terminal，不妨就從幫 Copilot 開一個專屬 profile 開始。

告訴 AI 要做什麼，它信心滿滿地衝出去寫程式，但結果出爐時，您才發現它的想像跟您的想像南轅北轍。功能是能用啦，但就是不太對勁。於是您開始改改改，最後花的時間比自己從頭寫還多。

如果有這樣的經驗，恭喜您，您已經發現了 AI 編程最大的痛點：假設。

假設的代價

AI 就像一個對公司環境完全陌生的新人。您說「幫我加個登入功能」，它會馬上開始瞎猜：要用 OAuth 還是 JWT？支援哪些登入方式？需不需要角色權限管理？如果 session 逾時了要怎麼辦？

結果就是，AI 按照自己的想像寫出來的程式，可能根本不是您要的。浪費時間，浪費生命。

Anthropic 最近推出的 Claude Code 新功能「AskUserQuestion」，就是為了解決這個老問題。說白了，就是讓 AI 學會先問清楚再動手。

反轉遊戲規則：AI 來面試你

以前我們痴迷於「提示詞工程」——費盡心思琢磨怎麼跟 AI 說話，才能讓它做對事。現在 Claude Code 的 AskUserQuestion 功能反轉了這個關係：換 AI 來問你。

這聽起來簡單，但威力驚人。

想像這個場景：您跟 Claude 說「幫我整合使用者認證」。以前 Claude 會直接開始寫程式，現在它會停下來，一個接一個地拋出關鍵問題：

• 您偏好哪種認證方法？（OAuth、JWT、還是傳統的 session？）
• 要支援哪些登入服務商？（Google、GitHub、email+密碼？）
• 需要角色式存取控制嗎？
• session 逾時後要發生什麼？

每個問題都附帶合理的選項和說明，就像在進行一場真實的技術討論。這個過程有個正式的名字，叫做「規格導向開發」（spec-based development）。

三步驟：問、寫、執行

AskUserQuestion 的最佳使用方式分三個階段：

第一步：面試階段

您只需要給 Claude 一個簡單的指令：「幫我建置使用者認證系統，先問我問題好嗎？」

Claude 就會開始提問。每一個問題都精準針對您的代碼庫，給您有意義的選項。

第二步：規格階段

經過一輪問答後，Claude 會產出一份詳細的規格文件。這份文件清楚列出要建置什麼、怎麼建置，一點都不模糊。

第三步：執行階段

有了規格在手，您就可以開始新的開發會話，把規格當作背景資訊。這次 Claude 執行起來精準無誤，因為所有的歧義都已經在一開始就解決了。

不騙您，就是這麼簡單。

Linear 整合：把 AI 變成團隊同事

事情變得更有趣的地方，是 Cyrus（一個整合 Claude 的開發工具）跟 Linear 的配合。

假設 Cyrus 在處理一個 Linear 工單，發現有不清楚的地方。它不會亂猜，也不會停滯，而是直接在 Linear 裡問您問題。您可以在 Linear 的活動區段看到 Cyrus 把工單標記為「需要輸入」，然後丟出問題，並提供清晰的選項讓您選擇。

您甚至不用切換視窗，直接在 Linear 裡點一個選項回應就行。這種異步協作方式超級適合遠端團隊：

• 異步開發：Cyrus 在您開會時繼續工作，有問題時自己提出來
• 背景資訊保留：問題和答案都成為工單歷史的一部分
• 團隊能見度：所有人都看得見決策過程
• 不打斷工作流：回答問題時不用離開 Linear

為什麼這件事重要

2026 年了，AI 的能力已經不是問題。真正的問題是：AI 有沒有弄懂我想要什麼？

當 Claude 問您「這個 API 應該快速失敗還是自動重試？」時，有個很微妙的轉變發生了。設計上的權衡變得顯而易見。不是在代碼審查時才發現埋藏的假設，而是在便宜的階段——決策剛做出來的時候——就把問題談清楚。

這就像是在玩「選擇你的冒險故事」。每個問題都是一個岔路口。每個答案都讓解決方案的空間變窄一點。到了 Claude 真正開始寫程式時，您們已經一起走過了整個決策樹，還有清楚的紀錄可以回顧每個選擇。

結語

AI 不是要搶您的工作。聰明的開發者已經發現，最有威力的不是 AI，而是懂得怎麼跟 AI 合作的人。

AskUserQuestion 功能就是這種合作的模板。下次當您要用 AI 寫程式時，與其期待它讀心術，不如主動告訴它：「先問我吧。」

結果可能會讓您驚訝。