Posts

前言：沒有人準備「它不能用」的那一刻 我們花很多時間討論 AI 能做什麼、怎麼用得更好、哪個模型比較強。 幾乎沒有人準備一件事：它突然不能用的時候，你怎麼辦。 不是「回答得不好」，是「完全叫不動」。而且是在你最需要它的那一刻。 這篇文章記錄一次真實的狀況：一場需要即時互動的活動，開場前 48 分鐘，背後的模型服務回傳配額用盡。從發現到恢復共約 30 分鐘。我把整個排錯過程完整寫下來，包括我一開始判斷錯的那一段。 補一句背景：這次排錯實際動手的是我的 agent，我從頭到尾在旁邊看著。下文的「我」包含這段協作——包括判斷錯的那一步，我當下也跟著信了。 一、症狀：兩個看起來無關的異常 事情不是從錯誤訊息開始的，是從「怪怪的」開始的。 我在例行檢查日誌時看到兩件事： 第一件，錯誤層級的訊息： ERROR pool error in dispatch_batch: pool exhausted INFO pool full, suspending oldest idle session 連線池滿了，系統正在不斷把舊的連線踢掉換新的。 第二件，回應時間異常： 使用者 A 387,289 ms = 6 分 27 秒 使用者 B 299,965 ms = 5 分 00 秒 使用者 C 270,801 ms = 4 分 31 秒 正常應該是 17～30 秒。現在要 4 到 6 分鐘。 二、第一個判斷：錯的 我的第一反應是：連線池滿了，所以大家在排隊，所以慢。 這個推理完全通順。池子有上限、上限到了、新的請求要等舊的釋放、於是每個人的等待時間拉長。 我甚至已經開始查連線池的設定，想看看上限能不能調大。 ...

前言：能寫程式碼，不等於能交付 用 AI 寫一段程式碼，現在沒什麼難的。難的是用 AI 交付一件有人在等、有期限、出錯會被看見的東西。 這兩件事的差別，在第三週才會顯現。 前兩週你會覺得一切順利：AI 產出快、你改得動、進度看起來很好。到了第三週，你開始發現有些檔案不知道是哪個版本、有些決定不記得為什麼那樣定、有兩條線各自改了同一份文件而你不知道哪份是對的。再過一週，你花在「搞清楚現在到底是什麼狀態」的時間，超過你花在推進的時間。 我最近用 36 天交付了一件這樣的東西——一場實作型工作坊，包含課程設計、環境建置、教材、簡報、示範影片，以及現場帶場。全程用 AI 協作，最後 162 次版本提交、38 條平行工作線、54 份交接文件。 它沒有在第三週崩解。這篇文章拆解為什麼。 一、五個階段：交付鏈的骨架 先講骨架。任何有交期的交付，都會走過這五個階段——差別只在你有沒有把它們分開。 Phase 1 · 設計（Design） 這階段 AI 的職能是：選項生成、矛盾偵測、規格收斂。 不是「幫你想」，是「陪你想」。差別在於：AI 提出選項並指出它們之間的矛盾，決定仍然是你做的。 實務上最有價值的一件事，是 AI 會發現你自己看不到的衝突。當你說「這一段要壓在 20 分鐘」，同時又說「這三件事都要講清楚」，它會把這個矛盾攤在你面前，而不是默默把三件事都寫進去然後產出一份 35 分鐘的稿子。 這階段我改了四次整體結構，最後一次是把整套教學主軸推翻重來。每一次改版都留下一份定案紀錄，包含「為什麼廢掉上一版」。 這件事在第五週救了我一次——當我想把某個舊設計改回來時，那份紀錄告訴我當初為什麼放棄它。 Phase 2 · 建置（Build） 這階段 AI 的職能是：多線平行執行。 這是 AI 協作跟傳統工作最不一樣的地方。我同時推進四條線：教材、簡報、環境、影片。四條線各自有自己的工作目錄、自己的交接檔，互不干擾。 平行的前提是隔離。 沒有隔離的平行不是平行，是混亂——兩條線改到同一份檔案，你要花的時間比循序做還多。 這階段還有一個關鍵決定：有三種技術路線可以選時，不要用推理選，用實測選。 我在 agent 的設定架構上卡了很久，三條路各有理由。最後的做法是三條都實際搭一次最小可行版本，跑跑看，然後選那條真的跑得動的。花了半天，省下後面兩週的返工。 Phase 3 · 演練（Rehearse） 這階段 AI 的職能是：缺口盤點與時間帳記錄。 這是最容易被跳過、也最不該跳過的階段。 我做了四輪演練：先是全程走查（紙上），然後是分線試跑，然後是錄影下來用學員視角看一遍，最後是真人完整走一遍。 四輪的價值完全不同。前三輪抓到的是「流程有沒有斷」，第四輪抓到的是「人會不會照你想的那樣做」。 最刺痛的一次發現是：機器複驗過、標記全過的項目，真人一跑就翻案了七項。 因為機器會照著你寫的路徑走，人不會。人會在你沒想到的地方停下來、會用你沒預期的方式理解一句話、會在應該往下的時候往回捲。 從那次之後我的判準改了：機器驗過的只能算「沒有明顯壞掉」，不能算「可以了」。 Phase 4 · 修補（Remediate） 這階段 AI 的職能是：根因定位。 ...

2026 年 1 月的時候，我還沒搞清楚「跟 AI 協作」是什麼。 Agent 工具剛熱起來，我才剛熟悉 Skill。手上有一件半年級的系統搬遷：人不多、週次很長、任務彼此卡住。我只知道一件事——若連「我們到底在排什麼」都對不齊，後面每一場會議都會重講一遍。 所以第一個決定不是「讓 AI 幫我寫 code」，而是：先有一張大家看了會站在同一頁的圖。 第一個動作：讓 Agent 產工作分解 我直接拿 Skill／Agent 試，先產專案的工作分解（WBS）。 過程並不順。我剛開始練 vibe coding——描述過程或目標一糊，產出就差十萬八千里。改描述、再產一輪，反覆幾次，才勉強對上。那時候的感覺不是「協作」，比較像「我在跟一台會寫字的印表機談判」。 我們也用過 JIRA、Asana。後來還是決定自己做：自製泳道圖，把任務拆到人和週次。團隊的組成用不了「只靠現成專案工具」就對齊；那時還有餘力，也想得蠻美好的。 圖一攤開：計畫排得出來，人補不上 圖攤開之後是這樣的：二十四週、四個人，計畫從 1 月中排到 6 月底。 第一週就亮了紅燈——有人負載被標得過高，有人第一項任務還是平台基礎學習。計畫排得出來，人補不上。這是 AI 幫我看見的，不是它幫我解決的。 真正寫進工作日誌、能對日期的，是 1 月 23 日。那天完成了泳道與任務系統的雙向更新；下午讓三個不同角色的 AI 同時審這張圖，從資料裡抽出兩百二十八項任務、二十四週、四個人，並列出致命風險——套件時程不夠、主力負載過高、上線週風險。同日開始做啟動簡報，另一個模型幫忙驗內容。 採不採納，仍是人決定。 為什麼那階段還稱不上協作 這張圖後來怎麼算「還算好」？不是它多漂亮，是開會時總算能用它對齊大家的理解與專案進度——誰在做什麼、卡在哪一週，有共同指認的畫面。 1 月底之前，AI 在這個專案裡做的事很窄：把圖畫清楚、把風險列出來、把啟動簡報的口徑對齊。判斷與執行仍全在人身上。 所以這階段我叫它工具，不叫協作。 它不會替你開會拍板，也不會替你扛上線那天的風險。它做的是把「要做什麼、誰在哪一週過載」攤到同一張畫面上，讓人第一次有機會在專案還早的時候就看見結構問題。 後來七個月裡，我們會把 Agent 用得更深——並行、重跑、拆任務、只丟意圖。那些都是後話。若沒有 1 月這張圖，後面每一次分工與風險對話，都還要從頭解釋「我們到底在排什麼」。 先有同一張圖，才有後面的協作。 Agent 出圖；人決定信哪一句、改哪一格、哪條風險要當真。

三個月前，我抱著「又一個 AI 工具試試看」的心態打開 Claude Code CLI。三個月後，它已經成為我每天工作流程的核心。不是因為它完美，而是因為它改變了我思考「人機協作」的方式。 這篇文章不是功能介紹，是我真實踩過的坑和摸索出的工作節奏。如果你在考慮要不要花時間深入學 Claude Code，希望這些心得能讓你少走一些彎路。 它不是更聰明的 Copilot 第一個要搞清楚的事：Claude Code 和 GitHub Copilot、Cursor 不是同一種東西。 Copilot 是補全工具，你寫，它預測下一行。Cursor 是 AI 增強版 IDE，聰明的自動補全加上 Chat 視窗。這兩者的核心假設是「你在主導，AI 在輔助」。 Claude Code 的核心假設是不同的：你在導演，AI 在執行。 你給它一個目標，它會讀懂整個 repo、寫計畫、執行程式碼、跑測試、修錯誤，然後回報結果。你的角色從「打字員」變成「技術主管」。 這聽起來很美好，但這也是很多人一開始用不對的原因——他們把 Claude Code 當成更貴的 Copilot 在用，然後覺得「也還好嘛」。 為什麼選 CLI 而不是 IDE 整合？ Cursor 有 Claude 整合，VS Code 也有 GitHub Copilot。為什麼要跑去用 CLI？ 老實說，我一開始也覺得很反直覺。但用了一段時間後，我理解了 CLI 的核心優勢：它可以在任何地方跑，不依賴 UI。 我現在的工作方式是：在遠端伺服器上跑 Claude Code，透過 SSH 操作。這讓我可以在任意機器、任意環境下發派任務，關掉 terminal 它還在跑。Cursor 做不到這件事。 另外，CLI 的腳本化能力也是 IDE 整合版本沒有的。你可以把 Claude Code 嵌進 cron job、CI/CD pipeline、Slack Bot 的觸發流程裡。這是一種完全不同的擴展維度。 ...

LCC 會員經濟學：低成本航空的忠誠度戰爭 一個讓人不安的數字 全球前六大航空公司，帳上合計背負約 US$300 億（約 NT$9,600 億）的點數負債（數字根據 American Airlines、Delta、United、Lufthansa、Air France-KLM、IAG 各 2024 年報加總估算；各來源因計算方式不同略有差異）。 這些是旅客累積但尚未兌換的里程、點數、優惠券。從會計角度，它們是遞延負債，必須列在資產負債表上，等旅客兌換時才能認列收入。 問題是，這個數字每年還在成長。 傳統全服務航空（FSC）之所以能承受這個壓力，是因為他們的忠誠計畫真的在創造價值——Delta 的 SkyMiles 每年為公司帶來超過 US$74 億的聯名卡收入，會員消費比非會員高出 1.5 到 2.5 倍。 但低成本航空（LCC）面對的是完全不同的方程式。 LCC 的忠誠度困境：三重詛咒 如果你問任何一個 MBA，「LCC 旅客有沒有忠誠度？」標準答案是：「沒有，他們只看價格。」 數據是這樣說的：LCC 的忠誠計畫對旅客消費行為的影響力（β 值）只有 0.15-0.20，在購票決策因素中排名第七——遠低於 FSC 的 0.30-0.40。換句話說，給你點數幾乎沒用。 但這只是問題的一半。 第一重詛咒：低頻次。LCC 旅客平均一年飛 1.2-1.8 次，相比 FSC 常旅客的 8-12 次。你很難對一年只飛一次的人建立忠誠度。 第二重詛咒：高沉睡率。LCC 的會員沉睡率高達 60-70%，遠高於 FSC 的 40-50%。以虎航為例，推估的月活躍會員佔比不到 5%，而 AirAsia 能做到 30%。 第三重詛咒：低附加收入。虎航的附加服務（行李、選位、餐食等）佔營收比例只有 3.88%，而產業平均是 25-35%，Ryanair 更高達 35%+。沒有附加收入，就沒有足夠的利潤空間支撐忠誠計畫。 所以，傳統 FSC 的會員經濟模型在 LCC 中結構性失效。 那為什麼 AirAsia、easyJet 這些 LCC 還在做？因為他們找到了不同的玩法。 ...

我的 Zettelkasten 實踐：一年後的回顧 一年前，我決定認真建立一套 Zettelkasten 系統。 我讀了 Niklas Luhmann 的故事，看了 Obsidian 社群的炫圖，相信自己也能建立一個會自己長出洞見的知識網絡。 一年後，我的 Vault 有 123 則永久筆記、30 個主題地圖、數百個原子化概念。 這篇是我誠實的回顧：什麼有效、什麼沒有、以及 AI 如何從根本上改變了這套系統的運作方式。 什麼是 Zettelkasten（給不熟悉的人） 快速說明，如果你已經知道就跳過。 Zettelkasten 是德文「卡片盒」的意思，是德國社會學家 Niklas Luhmann 用來管理知識的系統。核心概念是： 原子化：每則筆記只有一個想法 連結：筆記之間用雙向連結串起關係 演化：系統會隨時間長出你意想不到的洞見 Luhmann 用這個系統在 40 年間寫了 70 本書、400 篇學術文章。 聽起來很吸引人，對吧？ 第一年：真實發生的事 前三個月：建立習慣的痛苦 最難的不是理解概念，而是改掉「剪貼收藏」的習慣。 以前我的習慣是看到有趣的內容就截圖，或複製貼上到一個叫「有趣的事」的資料夾，然後再也不看。 Zettelkasten 要求你在記錄的當下就消化——用自己的話說出這個想法，找出它和你已知的什麼有關聯，並且想清楚這對你意味著什麼。 這很慢。比截圖慢十倍。 但慢是有意義的。那個停下來消化的過程，才是真正的學習發生的時刻。 三到六個月：系統開始有重量 當永久筆記超過 50 則，有趣的事情開始發生。 我在寫一則關於「AI Agent 的安全邊界」的新筆記時，系統提示我有三則舊筆記和這個主題相關：一則是關於「分層授權設計」、一則是關於「人類監督節點」、一則是關於「Claude Code 的 permission mode」。 這三則筆記分別在不同時間記下，但它們拼成了一個完整的論述。 那個時刻，我理解了 Luhmann 說的「第二個大腦」是什麼意思。 六到十二個月：速度瓶頸 這是我沒有預期到的問題。 當我開始用 AI 工具（Claude Code、n8n 自動化）加速知識擷取，問題出現了： ...

歡迎！ 歡迎來到 Notes47y 部落格 ✨ 關於這個部落格 這裡是我分享實踐經驗的地方，主要內容包括： 🤖 AI 協作開發 Claude Code 使用經驗 AI 輔助開發工作流程 提示工程（Prompt Engineering）技巧 MCP (Model Context Protocol) 整合 📚 知識管理 卡片盒筆記法（Zettelkasten）實踐 Obsidian 工作流程設計 個人知識管理系統建置 ⚡ Salesforce 技術 Apex 開發最佳實踐 Lightning Web Components (LWC) Salesforce 整合方案 CRM 導入經驗 為什麼寫部落格？ 寫作是思考的延伸，教學是最好的學習。 透過整理與分享，不僅能深化自己的理解，也希望能幫助到有類似需求的朋友。 訂閱更新 RSS 訂閱：/feed.xml GitHub：@requiemnameless 讓我們開始這段知識分享的旅程吧！🚀

從指令到協作：重塑開發典範的 2025 年 AI 協作四大轉折點 前言：你的 AI 副駕，已從聊天室駛入你的專案核心 還記得 2023 年，我們在 IDE 和 ChatGPT 視窗間瘋狂複製貼上的日子嗎？那時的 AI 像個博學但健忘的實習生，雖然能給出精彩的程式碼片段，卻無法真正理解我們專案的全貌。我們像個循循善誘的導師，不厭其煩地提供上下文，只為求得一段可用的程式碼。 快轉到 2025 年，場景已截然不同。AI 不再僅僅是個「對話框裡的聰明腦袋」，它已經進化成一個深度整合在我們工作流程中的「協作夥伴」。它能閱讀整個專案、串接外部服務、甚至能化身為不同領域的專家團隊，與我們共同完成複雜的任務。 這一年，我們見證了 AI 協作從「點狀問答」到「立體協作網絡」的驚人躍進。這是一場從根本上改變我們工作方式的典範轉移。本文將以我個人的實戰經驗，歸納出推動這場革命的四個關鍵轉折點，並探討在這波浪潮中，我們人類的核心價值將如何重新定義。 AI 協作的演進：從點、線到面 在深入探討四大轉折點之前，讓我們先建立一個思維框架：「點、線、面」的演進。 點 (Point): 早期的 AI 對話是「一次性」的。你問一個問題，它給一個答案。每個互動都是一個孤立的「點」，缺乏連貫性。 線 (Line): 隨著記憶功能的增強，AI 能記住對話的上下文，讓互動得以延伸成一條「線」。我們可以圍繞一個主題進行深入探討，而不會輕易失焦。 面 (Plane): 2025 年的突破，則是將多條專家「線」整合起來，形成一個多維度的協作「面」。我們不再是與單一 AI 互動，而是指揮一個由多個 AI 專家組成的團隊。 這個「點→線→面」的框架，將貫穿我們接下來要探討的四大轉折。 轉折點一：專案級上下文感知 (Claude Code) —— AI 終於學會了閱讀 第一個轉折，是 AI 從「失憶金魚」進化為「專案圖書館員」。 年初，Anthropic 推出的 VS Code 擴充套件 Claude Code，徹底改變了遊戲規則。它最關鍵的突破，在於賦予 AI 檢視整個專案資料夾 的能力。 這意味著，AI 不再需要我們手動餵養程式碼片段。它能像一位新加入的團隊成員一樣，自己去閱讀專案結構、理解程式碼之間的依賴關係、甚至參考過去的工作日誌（Work Log）。每一次的協作成果都被記錄下來，成為未來任務的養分。當你需要修改一個與三個月前某個功能相關的模組時，AI 不再是一臉茫然，而是能迅速調閱相關文件與程式碼，提供精準的建議。 ...