[{"content":"三個月前，我抱著「又一個 AI 工具試試看」的心態打開 Claude Code CLI。三個月後，它已經成為我每天工作流程的核心。不是因為它完美，而是因為它改變了我思考「人機協作」的方式。\n這篇文章不是功能介紹，是我真實踩過的坑和摸索出的工作節奏。如果你在考慮要不要花時間深入學 Claude Code，希望這些心得能讓你少走一些彎路。\n它不是更聰明的 Copilot 第一個要搞清楚的事：Claude Code 和 GitHub Copilot、Cursor 不是同一種東西。\nCopilot 是補全工具，你寫，它預測下一行。Cursor 是 AI 增強版 IDE，聰明的自動補全加上 Chat 視窗。這兩者的核心假設是「你在主導，AI 在輔助」。\nClaude Code 的核心假設是不同的：你在導演，AI 在執行。\n你給它一個目標，它會讀懂整個 repo、寫計畫、執行程式碼、跑測試、修錯誤，然後回報結果。你的角色從「打字員」變成「技術主管」。\n這聽起來很美好，但這也是很多人一開始用不對的原因——他們把 Claude Code 當成更貴的 Copilot 在用，然後覺得「也還好嘛」。\n為什麼選 CLI 而不是 IDE 整合？ Cursor 有 Claude 整合，VS Code 也有 GitHub Copilot。為什麼要跑去用 CLI？\n老實說，我一開始也覺得很反直覺。但用了一段時間後，我理解了 CLI 的核心優勢：它可以在任何地方跑，不依賴 UI。\n我現在的工作方式是：在遠端伺服器上跑 Claude Code，透過 SSH 操作。這讓我可以在任意機器、任意環境下發派任務，關掉 terminal 它還在跑。Cursor 做不到這件事。\n另外，CLI 的腳本化能力也是 IDE 整合版本沒有的。你可以把 Claude Code 嵌進 cron job、CI/CD pipeline、Slack Bot 的觸發流程裡。這是一種完全不同的擴展維度。\nCLAUDE.md：你和 AI 之間的說明書 開始一個新專案，第一件事我現在一定會做的就是寫 CLAUDE.md。\n這個檔案放在專案根目錄，Claude Code 每次啟動 session 都會讀它。你可以在裡面寫：\n這個專案是做什麼的 技術棧和版本限制 命名規範和程式碼風格 禁止動哪些目錄（例如 PROD 環境設定絕對不能改） 慣用的工作流程（例如「寫完記得跑 lint」） 我有一條規則叫做 1-Minute Rule：「任何預期超過 60 秒的操作，一律派給 Subagent 執行。」這條規則寫進 CLAUDE.md 之後，Claude Code 就會自動遵守，不用我每次提醒。\nCLAUDE.md 是你和 AI 協作契約的物化形式。花一個小時把它寫好，之後每一個 session 都會更順。\nPlan Mode：先想清楚再動手 這是我覺得最被低估的功能。\n預設情況下，你給 Claude Code 一個任務，它會直接開始執行。但對於複雜任務，這樣很危險——它可能走錯方向，等你發現問題已經改了二十個檔案。\nPlan Mode 的做法是：先讓 AI 提交一份執行計畫，等你確認之後再開始動。\n實際操作是這樣：\n你：幫我把這個 Python API 重構成 async，先給我計畫不要動程式碼 Claude：好的，我計畫做以下這些事： 1. 把 sync 的 requests 改成 aiohttp 2. 所有 def 函數加上 async/await 3. 更新 tests 請確認後我再執行。 你：第 3 點先不用，其他可以 Claude：了解，開始執行步驟 1 和 2... 這個流程讓我減少了很多「AI 做到一半發現走錯了」的情況。現在遇到複雜任務，我的標準開頭是：「先給我計畫，不要執行。」\nSubagent：並行任務的正確姿勢 這是 Claude Code 和所有 IDE 整合版本最大的架構差異。\nClaude Code 可以派生子代理（Subagent），讓多個任務同時進行。舉個例子：\n你在做一個功能，需要同時：\n寫後端 API 更新前端介面 補充單元測試 更新文件 在 Cursor 裡，你只能一件事一件事做。在 Claude Code 裡，你可以說「這四件事同時進行」，它會把任務分發給四個子代理並行執行。\n我現在的工作節奏是：每當有一個可以拆解成獨立子任務的需求，我就會明確說「這些可以並行」。節省下來的時間相當可觀。\n不過要注意：Subagent 也會消耗更多 token，而且並行任務之間如果有資源競爭（例如同時修改同一個檔案），可能會衝突。我的原則是：確定沒有依賴關係的任務才並行。\nHooks：自動化你的工作儀式 Hooks 讓你可以在 session 開始或結束時自動執行腳本。\n我設定的常用 hook 範例：\nSession 開始時：\n自動 git pull 拉最新 code 檢查 lint 是否有現有問題 顯示今天有哪些 open PR Session 結束時：\n自動跑 git status 確認沒有意外的修改 把工作日誌寫到指定目錄 這些聽起來很小，但當你每天開很多 session 的時候，這些儀式確保了你不會漏掉重要步驟。Hook 的設定檔是 settings.json，學習成本很低。\nPermission Mode：給 AI 多少自主權？ 這是一個需要根據情境判斷的問題。Claude Code 有三種模式：\nDefault（預設）：每次要對檔案做修改或執行命令，都會問你確認。最安全，但也最打斷流程。適合剛開始用、或在陌生 codebase 裡工作的時候。\nacceptEdits / dontAsk（不問模式）：對常見的低風險操作（讀檔、寫程式碼）不再詢問，但對危險操作（刪檔、執行 shell 命令）還是會問。這是我大部分時間的設定。（注意：確切名稱依 CLI 版本不同可能有差異，建議用 claude --help 確認）\nbypassPermissions（完全授權）：AI 可以做任何事，不問確認。我只在跑自動化腳本、或者我很確定任務範圍很小的時候用。\n我的原則：新任務從 Default 開始，熟悉了降到 dontAsk，永遠不要在不熟悉的 repo 上用 bypassPermissions。\n還有一個很有用的設定：在 CLAUDE.md 裡寫清楚哪些目錄是禁區。我有一個規則：PROD 環境的設定檔目錄只能讀取，不能修改。這個規則寫進去之後，就算用 bypassPermissions 也不會誤改到 PROD。\n最大的坑：上下文管理 說了這麼多優點，現在說最大的問題。\nClaude Code 最難的地方不是學習，是上下文管理。\n每個 session 有 token 上限。當你在一個複雜的大型 repo 裡工作，Claude Code 需要讀很多檔案來理解 context，這會消耗大量 token。當 token 快用完，AI 會開始「忘事」——它可能忘記你稍早說過的限制、或者對程式碼結構的理解開始出錯。\n我踩過最嚴重的坑是：一個超長的 session 裡，我在前半段說了「這個功能暫時不要改」，但到後半段 AI 忘了，在其他地方的改動中意外影響了那個功能。\n避免這個問題的方法：\n任務拆小：不要把一個大型重構放在一個 session 裡做完。拆成多個小任務，每個 session 有明確的開始和結束狀態。 重要限制寫在 CLAUDE.md：不要只靠對話傳遞約束，要把關鍵規則寫成永久性的 instruction。 Session 開始時主動提醒：對於真的很重要的限制，每次 session 開頭我會再說一次「記住：XXX 不能動」。 善用 git：每個小里程碑 commit 一次。這樣就算 AI 做出了奇怪的事，你可以快速 rollback。 適合什麼樣的開發者？ 老實說，Claude Code 不是對所有人都最佳解。\n最適合的情境：\n你需要在多個專案間切換，每個專案的 context 很重 你做的任務有很多「重複但不完全一樣」的工作（API 設計、測試補充、文件更新） 你習慣思考架構，而不是逐行寫程式碼 你在遠端伺服器工作，需要 CLI-first 的工具 說實話，這些情況 Cursor 更適合你：\n你主要工作是前端 UI，需要即時看到 UI 變化（Cursor 的 inline 預覽體驗目前還是更好） 你的任務非常短小，問答式就夠了（直接用 claude.ai 就好，不值得開 CLI） 你剛入門程式設計，還在建立基礎（你需要先有辨識 AI 錯誤的能力，才能真正用好它） 對我來說，Claude Code 最大的價值不是它能代替我寫程式碼，而是它讓我可以用更高的抽象層次工作。我花更少時間在「怎麼寫」，花更多時間在「要做什麼」和「為什麼這樣設計」。\n這種轉變需要時間適應。前兩週你可能會覺得它很難用、很慢。但過了那個坎之後，你會很難回到純手動寫程式碼的方式。\n從哪裡開始？ 如果你想試試看，我建議的入門順序：\n選一個你熟悉的專案：不要用 Claude Code 探索陌生 codebase，先在你了解的地方建立信任感 先寫 CLAUDE.md：花半小時把專案說明書寫好，這是值得的投資 從小任務開始：「幫我補這個函數的 unit test」比「幫我重構整個模組」更容易建立正確的使用習慣 用 Plan Mode 看 AI 怎麼想：即使你不需要它的計畫，看它的計畫過程會幫你理解它的推理方式 出問題時先看 session 長度：很多奇怪行為的根本原因是上下文太長 三個月後回頭看，Claude Code 改變的不只是我的開發效率，而是我對「軟體開發是什麼」這件事的理解。程式設計的核心技能，正在從「能不能打出正確的程式碼」轉向「能不能把問題描述清楚、把約束說明白、把結果驗證確實」。\n這個轉變讓很多人不安，但我覺得這讓軟體開發變得更接近它本來應該是的樣子：思考問題本身，而不是和語法搏鬥。\n","permalink":"https://blog.notes47y.win/posts/2026-04-09-claude-code-hands-on/","summary":"\u003cp\u003e三個月前，我抱著「又一個 AI 工具試試看」的心態打開 Claude Code CLI。三個月後，它已經成為我每天工作流程的核心。不是因為它完美，而是因為它改變了我思考「人機協作」的方式。\u003c/p\u003e\n\u003cp\u003e這篇文章不是功能介紹，是我真實踩過的坑和摸索出的工作節奏。如果你在考慮要不要花時間深入學 Claude Code，希望這些心得能讓你少走一些彎路。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"它不是更聰明的-copilot\"\u003e它不是更聰明的 Copilot\u003c/h2\u003e\n\u003cp\u003e第一個要搞清楚的事：Claude Code 和 GitHub Copilot、Cursor 不是同一種東西。\u003c/p\u003e\n\u003cp\u003eCopilot 是補全工具，你寫，它預測下一行。Cursor 是 AI 增強版 IDE，聰明的自動補全加上 Chat 視窗。這兩者的核心假設是「你在主導，AI 在輔助」。\u003c/p\u003e\n\u003cp\u003eClaude Code 的核心假設是不同的：\u003cstrong\u003e你在導演，AI 在執行。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e你給它一個目標，它會讀懂整個 repo、寫計畫、執行程式碼、跑測試、修錯誤，然後回報結果。你的角色從「打字員」變成「技術主管」。\u003c/p\u003e\n\u003cp\u003e這聽起來很美好，但這也是很多人一開始用不對的原因——他們把 Claude Code 當成更貴的 Copilot 在用，然後覺得「也還好嘛」。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"為什麼選-cli-而不是-ide-整合\"\u003e為什麼選 CLI 而不是 IDE 整合？\u003c/h2\u003e\n\u003cp\u003eCursor 有 Claude 整合，VS Code 也有 GitHub Copilot。為什麼要跑去用 CLI？\u003c/p\u003e\n\u003cp\u003e老實說，我一開始也覺得很反直覺。但用了一段時間後，我理解了 CLI 的核心優勢：\u003cstrong\u003e它可以在任何地方跑，不依賴 UI。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e我現在的工作方式是：在遠端伺服器上跑 Claude Code，透過 SSH 操作。這讓我可以在任意機器、任意環境下發派任務，關掉 terminal 它還在跑。Cursor 做不到這件事。\u003c/p\u003e\n\u003cp\u003e另外，CLI 的腳本化能力也是 IDE 整合版本沒有的。你可以把 Claude Code 嵌進 cron job、CI/CD pipeline、Slack Bot 的觸發流程裡。這是一種完全不同的擴展維度。\u003c/p\u003e","title":"Claude Code 實戰：從零開始的 AI 協作開發"},{"content":"LCC 會員經濟學：低成本航空的忠誠度戰爭 一個讓人不安的數字 全球前六大航空公司，帳上合計背負約 US$300 億（約 NT$9,600 億）的點數負債（數字根據 American Airlines、Delta、United、Lufthansa、Air France-KLM、IAG 各 2024 年報加總估算；各來源因計算方式不同略有差異）。\n這些是旅客累積但尚未兌換的里程、點數、優惠券。從會計角度，它們是遞延負債，必須列在資產負債表上，等旅客兌換時才能認列收入。\n問題是，這個數字每年還在成長。\n傳統全服務航空（FSC）之所以能承受這個壓力，是因為他們的忠誠計畫真的在創造價值——Delta 的 SkyMiles 每年為公司帶來超過 US$74 億的聯名卡收入，會員消費比非會員高出 1.5 到 2.5 倍。\n但低成本航空（LCC）面對的是完全不同的方程式。\nLCC 的忠誠度困境：三重詛咒 如果你問任何一個 MBA，「LCC 旅客有沒有忠誠度？」標準答案是：「沒有，他們只看價格。」\n數據是這樣說的：LCC 的忠誠計畫對旅客消費行為的影響力（β 值）只有 0.15-0.20，在購票決策因素中排名第七——遠低於 FSC 的 0.30-0.40。換句話說，給你點數幾乎沒用。\n但這只是問題的一半。\n第一重詛咒：低頻次。LCC 旅客平均一年飛 1.2-1.8 次，相比 FSC 常旅客的 8-12 次。你很難對一年只飛一次的人建立忠誠度。\n第二重詛咒：高沉睡率。LCC 的會員沉睡率高達 60-70%，遠高於 FSC 的 40-50%。以虎航為例，推估的月活躍會員佔比不到 5%，而 AirAsia 能做到 30%。\n第三重詛咒：低附加收入。虎航的附加服務（行李、選位、餐食等）佔營收比例只有 3.88%，而產業平均是 25-35%，Ryanair 更高達 35%+。沒有附加收入，就沒有足夠的利潤空間支撐忠誠計畫。\n所以，傳統 FSC 的會員經濟模型在 LCC 中結構性失效。\n那為什麼 AirAsia、easyJet 這些 LCC 還在做？因為他們找到了不同的玩法。\n三種突圍模式 新一代 LCC 發展出三種截然不同的忠誠度策略：\n模式一：母品牌整合型 代表：Scoot（新加坡）、Jetstar（澳洲）\n做法很簡單：LCC 飛行積累的里程，計入母公司的常旅客計畫（KrisFlyer、Qantas Frequent Flyer）。旅客在 LCC 省錢的同時，還能累積高端艙位的升等里程。\n優點是執行成本低，借用了母品牌的信任感。缺點是 LCC 在這個模型中沒有數據主權——旅客的忠誠是向母品牌的，不是向 LCC 的。\n模式二：獨立生態系型 代表：AirAsia MOVE、Go Rewards\nAirAsia 用了另一種思路：不是讓旅客在航空飛行中累積點數，而是把點數的使用場景擴展到日常生活。Go Rewards 讓旅客在超市、餐廳、外送平台都能累積和兌換，航空只是其中一個管道。\n這個模式的核心假設是：低飛行頻次不是問題，只要讓旅客在其他地方也和你互動，日常消費就能彌補飛行頻次不足。\nAirAsia 的月活躍會員能做到 30%，和這個策略有直接關係。但代價是巨大的前期投資和生態系建設能力——沒有 7,500 萬以上的旅客基礎，這條路很難走。\n模式三：訂閱制型 代表：easyJet Plus（£249/年）、Frontier Discount Den\n最直接的方式：付年費，獲得確定性的權益（指定座位、快速登機、手提行李保障）。不玩點數，不玩里程，就是「固定費用換確定性服務」。\neasyJet Plus 在歐洲市場表現穩定，原因在於歐洲有大量高頻通勤旅客，他們不是在找便宜，而是在找「可預期」。\nRyanair 曾推出 Ryanair Prime 訂閱制，8 個月後就下架了——因為他們的旅客飛行頻次還不夠高，無法支撐年費的感知價值。\n點數負債的數學：為什麼「發點數」是門生意 很多人以為航空公司發點數是在損失成本。事實上，設計得好的點數計畫是一門精算生意。\n關鍵指標叫做 Breakage Rate：永遠不會被兌換的點數比例。業界平均值在 10-20% 之間。\n這意味著航空公司每發出 100 元的點數，理論上只需要準備 80-90 元的兌換成本。其餘的 10-20 元，按照 IFRS 15 的會計準則，在點數到期或確認無法兌換時才轉為收入。\n更重要的是，點數計畫本身是一個現金流提前機制：\n旅客購票時，部分收入被確認為點數負債 旅客用點數兌換機位時，才認列為飛行收入 在這個時間差中，航空公司實際上無息借用了旅客的錢 設計不好的點數計畫才會讓負債失控——發點數太大方、兌換成本太高、沉睡率太低（代表大家都在兌換）。\n為什麼 12% 的旅客撐起整個獲利模型 這是最反直覺的部分。\n如果把 LCC 旅客按飛行頻次分群，高頻旅客（年飛 6 次以上）通常只佔旅客總數的 10-15%。但這個群體的 3 年 LTV（終身價值）是低頻旅客的 10 到 13 倍。\n以虎航情境為例：\n高頻旅客：3 年 LTV 約 NT$40,000+ 低頻旅客：3 年 LTV 約 NT$20,000 如果能把現有旅客中的 12% 從低頻轉換為中高頻，整個忠誠計畫的投資回報可以達到 165%。\n這就是「12% 法則」：不需要讓所有人都忠誠，只需要讓對的那群人更常飛。\n忠誠計畫的真正目的，不是「留住所有人」，而是「識別出最有價值的那群人，並給他們足夠的理由繼續飛」。\n台灣 LCC 的機會與挑戰 虎航（Tigerair Taiwan）是台灣市場最主要的 LCC，但目前的 tigerclub 會員計畫在多個關鍵指標上落後：\n指標 虎航 產業最佳 附加服務佔比 3.88% Ryanair 35%+ 每旅客附加收入 ~NT$80 AirAsia ~NT$1,800 月活躍會員佔比 \u0026lt;5%（推估） AirAsia 30% tigerCoin 回饋率 1% Go Rewards 1:1 差距是真實的，但換個角度看：虎航的附加服務佔比只有 3.88%，而產業平均是 25-35%。如果能提升到產業平均，相當於新增約 NT$347 億的年營收潛力。\n現在的問題不是「忠誠計畫值不值得做」，而是「用什麼模式做」。\n台灣市場的特殊條件：\n飛行距離短（2-5 小時），里程制度積累緩慢，旅客感知價值低 市場規模（年旅客量）不足以支撐 AirAsia 式的超級 App 但有足夠多的短途通勤商務旅客，訂閱制有潛力 最適合台灣 LCC 的可能是「輕量級混合模型」：訂閱制作為主軸（確定性權益），消費積點作為補充（提高黏著度），不追求大生態系但深化核心旅客關係。\n給旅客的實用建議 如果你是 LCC 的常旅客，這裡是幾個值得知道的事：\n1. 點數的時間成本很高 LCC 點數的年均貶值率約 15%，如果你累積點數超過 18 個月還沒用，實際價值已經縮水接近三分之一。\n2. 訂閱制通常比點數划算 如果你一年飛超過 4-6 次，easyJet Plus 或類似的訂閱制方案通常比追求點數更合算——確定性的座位保障和登機優先，對時間有限的旅客更有價值。\n3. 善用母品牌整合 如果你飛的是 Scoot 或 Jetstar，記得連結 KrisFlyer 或 Qantas 帳號，讓 LCC 的飛行也能累積高端里程。\n4. 附加服務的折扣才是真優惠 LCC 的忠誠計畫最實質的優惠通常不是里程，而是行李、選位、早鳥 check-in 的折扣。換算成現金價值往往比里程高。\n這場戰爭，誰會贏？ 低成本航空的忠誠度戰爭，不是傳統 FSC 模式的複製。\n贏家不會是把里程計畫照搬進來的那個，而是找到「在 LCC 的限制條件下，創造旅客真正感知得到的價值」的那個。\n這個條件是：低頻 × 低票價 × 高確定性需求。\n我的押注是：接下來三年，台灣 LCC 最有機會成功的路徑是輕量訂閱制，而不是里程計畫。理由很直接：台灣飛行距離短（多在 2-4 小時），里程累積慢、感知價值低；但商務短途旅客對「確定性」（選位、行李、登機優先）的需求很真實，且願意為此付出固定費用。easyJet Plus 在歐洲的成功，有部分可以在台灣市場複製。\n訂閱制解決了確定性問題。超級 App 解決了低頻問題。母品牌整合解決了里程感知問題。三種模式都有成功案例，也都有失敗案例。沒有人能同時做好三件事——但選對自己市場的那一件，就已經贏了一半。\n附注：AirAsia 每旅客附加收入計算基礎：AirAsia Group 公開的 ancillary revenue per pax 約 USD$20-25（2023-24 數據），折算約 NT$640-800。本文引用數字 NT$1,800 係根據研究報告，可能納入 AirAsia MOVE 超級 App 生態系的跨平台消費貢獻，計算口徑不同於傳統航空 ancillary 定義，供參考。\n本文研究素材來源：LCC 忠誠度計畫比較研究、LCC 營收結構分析、會員計畫痛點報告（2026 年 3-4 月）\n","permalink":"https://blog.notes47y.win/posts/2026-04-09-lcc-loyalty-economics/","summary":"\u003ch1 id=\"lcc-會員經濟學低成本航空的忠誠度戰爭\"\u003eLCC 會員經濟學：低成本航空的忠誠度戰爭\u003c/h1\u003e\n\u003ch2 id=\"一個讓人不安的數字\"\u003e一個讓人不安的數字\u003c/h2\u003e\n\u003cp\u003e全球前六大航空公司，帳上合計背負約 US$300 億（約 NT$9,600 億）的點數負債（數字根據 American Airlines、Delta、United、Lufthansa、Air France-KLM、IAG 各 2024 年報加總估算；各來源因計算方式不同略有差異）。\u003c/p\u003e\n\u003cp\u003e這些是旅客累積但尚未兌換的里程、點數、優惠券。從會計角度，它們是\u003cstrong\u003e遞延負債\u003c/strong\u003e，必須列在資產負債表上，等旅客兌換時才能認列收入。\u003c/p\u003e\n\u003cp\u003e問題是，這個數字每年還在成長。\u003c/p\u003e\n\u003cp\u003e傳統全服務航空（FSC）之所以能承受這個壓力，是因為他們的忠誠計畫真的在創造價值——Delta 的 SkyMiles 每年為公司帶來超過 US$74 億的聯名卡收入，會員消費比非會員高出 1.5 到 2.5 倍。\u003c/p\u003e\n\u003cp\u003e但低成本航空（LCC）面對的是完全不同的方程式。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"lcc-的忠誠度困境三重詛咒\"\u003eLCC 的忠誠度困境：三重詛咒\u003c/h2\u003e\n\u003cp\u003e如果你問任何一個 MBA，「LCC 旅客有沒有忠誠度？」標準答案是：「沒有，他們只看價格。」\u003c/p\u003e\n\u003cp\u003e數據是這樣說的：LCC 的忠誠計畫對旅客消費行為的影響力（β 值）只有 0.15-0.20，在購票決策因素中排名第七——遠低於 FSC 的 0.30-0.40。換句話說，給你點數幾乎沒用。\u003c/p\u003e\n\u003cp\u003e但這只是問題的一半。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第一重詛咒：低頻次\u003c/strong\u003e。LCC 旅客平均一年飛 1.2-1.8 次，相比 FSC 常旅客的 8-12 次。你很難對一年只飛一次的人建立忠誠度。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第二重詛咒：高沉睡率\u003c/strong\u003e。LCC 的會員沉睡率高達 60-70%，遠高於 FSC 的 40-50%。以虎航為例，推估的月活躍會員佔比不到 5%，而 AirAsia 能做到 30%。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e第三重詛咒：低附加收入\u003c/strong\u003e。虎航的附加服務（行李、選位、餐食等）佔營收比例只有 3.88%，而產業平均是 25-35%，Ryanair 更高達 35%+。沒有附加收入，就沒有足夠的利潤空間支撐忠誠計畫。\u003c/p\u003e\n\u003cp\u003e所以，傳統 FSC 的會員經濟模型在 LCC 中\u003cstrong\u003e結構性失效\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e那為什麼 AirAsia、easyJet 這些 LCC 還在做？因為他們找到了不同的玩法。\u003c/p\u003e","title":"LCC 會員經濟學：低成本航空的忠誠度戰爭"},{"content":"我的 Zettelkasten 實踐：一年後的回顧 一年前，我決定認真建立一套 Zettelkasten 系統。\n我讀了 Niklas Luhmann 的故事，看了 Obsidian 社群的炫圖，相信自己也能建立一個會自己長出洞見的知識網絡。\n一年後，我的 Vault 有 123 則永久筆記、30 個主題地圖、數百個原子化概念。\n這篇是我誠實的回顧：什麼有效、什麼沒有、以及 AI 如何從根本上改變了這套系統的運作方式。\n什麼是 Zettelkasten（給不熟悉的人） 快速說明，如果你已經知道就跳過。\nZettelkasten 是德文「卡片盒」的意思，是德國社會學家 Niklas Luhmann 用來管理知識的系統。核心概念是：\n原子化：每則筆記只有一個想法 連結：筆記之間用雙向連結串起關係 演化：系統會隨時間長出你意想不到的洞見 Luhmann 用這個系統在 40 年間寫了 70 本書、400 篇學術文章。\n聽起來很吸引人，對吧？\n第一年：真實發生的事 前三個月：建立習慣的痛苦 最難的不是理解概念，而是改掉「剪貼收藏」的習慣。\n以前我的習慣是看到有趣的內容就截圖，或複製貼上到一個叫「有趣的事」的資料夾，然後再也不看。\nZettelkasten 要求你在記錄的當下就消化——用自己的話說出這個想法，找出它和你已知的什麼有關聯，並且想清楚這對你意味著什麼。\n這很慢。比截圖慢十倍。\n但慢是有意義的。那個停下來消化的過程，才是真正的學習發生的時刻。\n三到六個月：系統開始有重量 當永久筆記超過 50 則，有趣的事情開始發生。\n我在寫一則關於「AI Agent 的安全邊界」的新筆記時，系統提示我有三則舊筆記和這個主題相關：一則是關於「分層授權設計」、一則是關於「人類監督節點」、一則是關於「Claude Code 的 permission mode」。\n這三則筆記分別在不同時間記下，但它們拼成了一個完整的論述。\n那個時刻，我理解了 Luhmann 說的「第二個大腦」是什麼意思。\n六到十二個月：速度瓶頸 這是我沒有預期到的問題。\n當我開始用 AI 工具（Claude Code、n8n 自動化）加速知識擷取，問題出現了：\n自動擷取的速度，遠超過人工消化的速度。\n我的 00_Inbox 資料夾開始堆積。每週有 40-60 篇來自 Threads、Slack、文章的素材等待提煉，但我能認真消化的只有 10-15 則。\nInbox 成了另一個「有趣的事」資料夾，只是格式更整齊。\n這讓我意識到：系統設計的瓶頸不在擷取端，在提煉端。\n什麼有效 梳理一年的歷程，我把發現整理成兩類：有效的和沒效的。先說有效的。\n1. 原子化筆記真的讓思考更清晰 最有價值的副作用：寫 Zettelkasten 的過程，強迫你把一個模糊的感覺轉化成一個可以說清楚的論點。\n「AI 很重要」不是一則筆記。\n「Context Engineering 是個人 AI 工作者在七層架構中最能差異化的層級，因為底層硬體和基礎模型不是個人能影響的，但 Context 的設計完全取決於工作者的領域知識」才是。\n這個練習，本身就是一種思考訓練。\n2. 跨領域連結是意外的驚喜 我不可能在寫筆記的當下就知道哪兩個想法未來會有關聯。但當系統幫我把「LCC 忠誠度計畫的高沉睡率」和「知識管理 Inbox 堆積問題」放在一起，我看到了一個共同的結構：\n當進料速度超過消化速度，任何系統都會累積「名義上擁有但實際上沒有用」的資產。\n這個洞見幫我重新設計了我的知識管理流程，也讓我在給客戶做 Loyalty 建議時有了新的角度。\n3. MOC 是讓系統「可用」的關鍵 永久筆記本身不夠，你需要一個導覽層。\n我的 20_MOC/ 目錄有 30 個主題地圖，每個 MOC 是某個領域的概念索引。當我要寫一篇關於 AI 開發的文章，我不需要搜尋所有筆記，只需要打開 AI工具與自動化_MOC.md，就能看到這個主題下所有相關筆記的結構。\n沒有 MOC，系統的知識是散的。有了 MOC，知識才是「可取用的」。\n什麼沒有效 1. 連結過度工程化 早期我很努力地為每則筆記建立雙向連結。後來我發現：不是每個連結都有意義。\n「因為和其他筆記有關就加連結」和「因為這個連結揭示了一個真實的思想關係才加」，是完全不同的事。\n前者讓你覺得系統很豐富，但搜尋時的雜訊也多了。後者的連結，每一個都值得點進去看。\n2. 系統維護的心理負擔 Zettelkasten 需要定期的「整理」：把 Inbox 的素材提煉成永久筆記、更新 MOC、定期回顧已有的筆記。\n這些工作沒有截止日，很容易被推遲。推遲一週，下週的負擔就翻倍。\n解決方案是把它當成固定儀式，而不是「有空再做」的事。\n3. 過度追求「完美格式」 我花了太多時間在格式：用什麼標籤、怎麼命名、要不要加 metadata。\n最後的結論是：格式服務思考，不是目的本身。 一則內容豐富但格式凌亂的筆記，遠比一則格式完美但空洞的筆記有價值。\nAI 如何改變了這套系統 這是一年後最大的改變。\nClaude Code 成為系統的一部分 我現在在 Obsidian 的專案根目錄有一個 _llm_index.md，是專門為 AI 設計的 Vault 導覽文件。它告訴 Claude：Vault 的結構、MOC 的主題分類、Zettelkasten 的時間分布。（關於如何讓 Claude Code 讀懂你的專案，CLAUDE.md 是另一個同樣重要的設計——原理是一樣的：給 AI 一份「說明書」。）\n當我要寫文章或做研究，Claude 可以直接參照這份索引快速找到相關筆記，而不需要我一一指定。\n這讓 AI 從「工具」變成了「有記憶的協作夥伴」。\n自動提煉流程（還在實驗中） 我正在用 n8n 自動化部分提煉流程：把 Threads、Slack digest 自動結構化，初步分類成可以快速審核的草稿。\n但這帶來了前面說的「速度瓶頸」問題——AI 可以自動生成草稿，但你還是需要花時間審核和決定「這個值不值得進永久筆記」。\nAI 加速了前段，但沒有消除人類判斷的必要性。事實上，在 AI 大量產出的時代，判斷力比以前更稀缺、更有價值。\n給想開始的人 如果你正在考慮建立 Zettelkasten，幾個誠實的建議：\n從小開始。不需要建立完整的系統才開始記第一則筆記。先從「把一個你今天學到的東西用自己的話寫一遍」開始。\nInbox 要每週清。如果你讓 Inbox 堆積超過兩週，你就失去了大部分情境，提煉的品質會大幅下降。\nMOC 越早建越好。當你有 10 則筆記的時候建 MOC，比有 100 則再建容易太多。\n工具選 Obsidian。不是說其他工具不好，而是 Obsidian 的本地儲存、Markdown 格式、和未來 AI 整合的相容性，目前是最好的選擇。\n連結要有意義。每次建連結前問自己：這個連結揭示了什麼真實的思想關係？\n一年後的結論 Zettelkasten 沒有讓我變成 Luhmann，但它改變了我思考和記錄的方式。\n最大的收穫不是那 123 則筆記，而是「用可連結的方式思考」這個習慣。\n當你習慣了問「這個想法和我已知的什麼有關？」，你開始看到世界的不同之處。\n那是 AI 目前還沒有辦法替代你做的事。\n系列相關：如果你想看 Zettelkasten 在 AI 協作場景的具體應用，可以看[用 AI Agent 團隊經營品牌 Blog：notes47y 的 Paperclip 實驗]。\n","permalink":"https://blog.notes47y.win/posts/2026-04-09-zettelkasten-one-year-review/","summary":"\u003ch1 id=\"我的-zettelkasten-實踐一年後的回顧\"\u003e我的 Zettelkasten 實踐：一年後的回顧\u003c/h1\u003e\n\u003cp\u003e一年前，我決定認真建立一套 Zettelkasten 系統。\u003c/p\u003e\n\u003cp\u003e我讀了 Niklas Luhmann 的故事，看了 Obsidian 社群的炫圖，相信自己也能建立一個會自己長出洞見的知識網絡。\u003c/p\u003e\n\u003cp\u003e一年後，我的 Vault 有 123 則永久筆記、30 個主題地圖、數百個原子化概念。\u003c/p\u003e\n\u003cp\u003e這篇是我誠實的回顧：什麼有效、什麼沒有、以及 AI 如何從根本上改變了這套系統的運作方式。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"什麼是-zettelkasten給不熟悉的人\"\u003e什麼是 Zettelkasten（給不熟悉的人）\u003c/h2\u003e\n\u003cp\u003e快速說明，如果你已經知道就跳過。\u003c/p\u003e\n\u003cp\u003eZettelkasten 是德文「卡片盒」的意思，是德國社會學家 Niklas Luhmann 用來管理知識的系統。核心概念是：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e原子化\u003c/strong\u003e：每則筆記只有一個想法\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e連結\u003c/strong\u003e：筆記之間用雙向連結串起關係\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e演化\u003c/strong\u003e：系統會隨時間長出你意想不到的洞見\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eLuhmann 用這個系統在 40 年間寫了 70 本書、400 篇學術文章。\u003c/p\u003e\n\u003cp\u003e聽起來很吸引人，對吧？\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"第一年真實發生的事\"\u003e第一年：真實發生的事\u003c/h2\u003e\n\u003ch3 id=\"前三個月建立習慣的痛苦\"\u003e前三個月：建立習慣的痛苦\u003c/h3\u003e\n\u003cp\u003e最難的不是理解概念，而是改掉「剪貼收藏」的習慣。\u003c/p\u003e\n\u003cp\u003e以前我的習慣是看到有趣的內容就截圖，或複製貼上到一個叫「有趣的事」的資料夾，然後再也不看。\u003c/p\u003e\n\u003cp\u003eZettelkasten 要求你在記錄的當下就\u003cstrong\u003e消化\u003c/strong\u003e——用自己的話說出這個想法，找出它和你已知的什麼有關聯，並且想清楚這對你意味著什麼。\u003c/p\u003e\n\u003cp\u003e這很慢。比截圖慢十倍。\u003c/p\u003e\n\u003cp\u003e但慢是有意義的。那個停下來消化的過程，才是真正的學習發生的時刻。\u003c/p\u003e\n\u003ch3 id=\"三到六個月系統開始有重量\"\u003e三到六個月：系統開始有重量\u003c/h3\u003e\n\u003cp\u003e當永久筆記超過 50 則，有趣的事情開始發生。\u003c/p\u003e\n\u003cp\u003e我在寫一則關於「AI Agent 的安全邊界」的新筆記時，系統提示我有三則舊筆記和這個主題相關：一則是關於「分層授權設計」、一則是關於「人類監督節點」、一則是關於「Claude Code 的 permission mode」。\u003c/p\u003e\n\u003cp\u003e這三則筆記分別在不同時間記下，但它們拼成了一個完整的論述。\u003c/p\u003e\n\u003cp\u003e那個時刻，我理解了 Luhmann 說的「第二個大腦」是什麼意思。\u003c/p\u003e\n\u003ch3 id=\"六到十二個月速度瓶頸\"\u003e六到十二個月：速度瓶頸\u003c/h3\u003e\n\u003cp\u003e這是我沒有預期到的問題。\u003c/p\u003e\n\u003cp\u003e當我開始用 AI 工具（Claude Code、n8n 自動化）加速知識擷取，問題出現了：\u003c/p\u003e","title":"我的 Zettelkasten 實踐：一年後的回顧"},{"content":"歡迎！ 歡迎來到 Notes47y 部落格 ✨\n關於這個部落格 這裡是我分享實踐經驗的地方，主要內容包括：\n🤖 AI 協作開發 Claude Code 使用經驗 AI 輔助開發工作流程 提示工程（Prompt Engineering）技巧 MCP (Model Context Protocol) 整合 📚 知識管理 卡片盒筆記法（Zettelkasten）實踐 Obsidian 工作流程設計 個人知識管理系統建置 ⚡ Salesforce 技術 Apex 開發最佳實踐 Lightning Web Components (LWC) Salesforce 整合方案 CRM 導入經驗 為什麼寫部落格？ 寫作是思考的延伸，教學是最好的學習。\n透過整理與分享，不僅能深化自己的理解，也希望能幫助到有類似需求的朋友。\n訂閱更新 RSS 訂閱：/feed.xml GitHub：@requiemnameless 讓我們開始這段知識分享的旅程吧！🚀\n","permalink":"https://blog.notes47y.win/posts/2026-02-11-welcome/","summary":"\u003ch1 id=\"歡迎\"\u003e歡迎！\u003c/h1\u003e\n\u003cp\u003e歡迎來到 Notes47y 部落格 ✨\u003c/p\u003e\n\u003ch2 id=\"關於這個部落格\"\u003e關於這個部落格\u003c/h2\u003e\n\u003cp\u003e這裡是我分享實踐經驗的地方，主要內容包括：\u003c/p\u003e\n\u003ch3 id=\"-ai-協作開發\"\u003e🤖 AI 協作開發\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eClaude Code 使用經驗\u003c/li\u003e\n\u003cli\u003eAI 輔助開發工作流程\u003c/li\u003e\n\u003cli\u003e提示工程（Prompt Engineering）技巧\u003c/li\u003e\n\u003cli\u003eMCP (Model Context Protocol) 整合\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"-知識管理\"\u003e📚 知識管理\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e卡片盒筆記法（Zettelkasten）實踐\u003c/li\u003e\n\u003cli\u003eObsidian 工作流程設計\u003c/li\u003e\n\u003cli\u003e個人知識管理系統建置\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"-salesforce-技術\"\u003e⚡ Salesforce 技術\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eApex 開發最佳實踐\u003c/li\u003e\n\u003cli\u003eLightning Web Components (LWC)\u003c/li\u003e\n\u003cli\u003eSalesforce 整合方案\u003c/li\u003e\n\u003cli\u003eCRM 導入經驗\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"為什麼寫部落格\"\u003e為什麼寫部落格？\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e寫作是思考的延伸，教學是最好的學習。\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e透過整理與分享，不僅能深化自己的理解，也希望能幫助到有類似需求的朋友。\u003c/p\u003e\n\u003ch2 id=\"訂閱更新\"\u003e訂閱更新\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eRSS 訂閱：\u003ca href=\"/feed.xml\"\u003e/feed.xml\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGitHub：\u003ca href=\"https://github.com/requiemnameless\"\u003e@requiemnameless\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003e讓我們開始這段知識分享的旅程吧！🚀\u003c/p\u003e","title":"歡迎來到 Notes47y"},{"content":"從指令到協作：重塑開發典範的 2025 年 AI 協作四大轉折點 前言：你的 AI 副駕，已從聊天室駛入你的專案核心 還記得 2023 年，我們在 IDE 和 ChatGPT 視窗間瘋狂複製貼上的日子嗎？那時的 AI 像個博學但健忘的實習生，雖然能給出精彩的程式碼片段，卻無法真正理解我們專案的全貌。我們像個循循善誘的導師，不厭其煩地提供上下文，只為求得一段可用的程式碼。\n快轉到 2025 年，場景已截然不同。AI 不再僅僅是個「對話框裡的聰明腦袋」，它已經進化成一個深度整合在我們工作流程中的「協作夥伴」。它能閱讀整個專案、串接外部服務、甚至能化身為不同領域的專家團隊，與我們共同完成複雜的任務。\n這一年，我們見證了 AI 協作從「點狀問答」到「立體協作網絡」的驚人躍進。這是一場從根本上改變我們工作方式的典範轉移。本文將以我個人的實戰經驗，歸納出推動這場革命的四個關鍵轉折點，並探討在這波浪潮中，我們人類的核心價值將如何重新定義。\nAI 協作的演進：從點、線到面 在深入探討四大轉折點之前，讓我們先建立一個思維框架：「點、線、面」的演進。\n點 (Point): 早期的 AI 對話是「一次性」的。你問一個問題，它給一個答案。每個互動都是一個孤立的「點」，缺乏連貫性。 線 (Line): 隨著記憶功能的增強，AI 能記住對話的上下文，讓互動得以延伸成一條「線」。我們可以圍繞一個主題進行深入探討，而不會輕易失焦。 面 (Plane): 2025 年的突破，則是將多條專家「線」整合起來，形成一個多維度的協作「面」。我們不再是與單一 AI 互動，而是指揮一個由多個 AI 專家組成的團隊。 這個「點→線→面」的框架，將貫穿我們接下來要探討的四大轉折。\n轉折點一：專案級上下文感知 (Claude Code) —— AI 終於學會了閱讀 第一個轉折，是 AI 從「失憶金魚」進化為「專案圖書館員」。\n年初，Anthropic 推出的 VS Code 擴充套件 Claude Code，徹底改變了遊戲規則。它最關鍵的突破，在於賦予 AI 檢視整個專案資料夾 的能力。\n這意味著，AI 不再需要我們手動餵養程式碼片段。它能像一位新加入的團隊成員一樣，自己去閱讀專案結構、理解程式碼之間的依賴關係、甚至參考過去的工作日誌（Work Log）。每一次的協作成果都被記錄下來，成為未來任務的養分。當你需要修改一個與三個月前某個功能相關的模組時，AI 不再是一臉茫然，而是能迅速調閱相關文件與程式碼，提供精準的建議。\n這種專案級的上下文理解，將 AI 協作從脆弱的「對話線」，升級為一張穩固的「專案知識網」。溝通成本大幅降低，協作的深度與廣度也因此得到了前所未有的提升。\n轉折點二：外部工具調用 (MCP) —— AI 伸出連接真實世界的觸手 第二個轉折，是 AI 打破了數位牢籠，學會了與外部世界互動。\n如果說 Claude Code 讓 AI 擁有了「眼睛」和「記憶」，那麼 MCP (Model Context Protocol) 的普及，則為它裝上了「手臂」。MCP 允許大型語言模型安全地與外部 API 和工具進行互動。\n我喜歡用《駭客任務》中的機械烏賊（Sentinel）來比喻這個概念。MCP 就像 Sentinel 身上那些可以隨意伸縮、接駁各種系統的萬用觸手。需要分析設計稿？AI 伸出觸手接上 Figma。需要自動化一個工作流？它接上 n8n。需要管理程式碼版本？它直接與 GitHub API 對話。\nAI 不再是一個只能紙上談兵的「顧問」，而是成為一個能親自動手的「執行者」。它可以在 VS Code 這個「智慧中樞」內，調度各種外部服務來完成任務。從前需要我們手動在多個平台間切換、操作的繁瑣流程，如今只需對 AI 下達一個指令，便能一氣呵成。這使得 VS Code 真正成為了一站式的 AI 協作指揮中心。\n轉折點三：專家代理人 (Subagents) —— 如同 Trinity 瞬間載入專業技能 第三個轉折，是 AI 從「通才」進化為「專家團隊」。\n還記得《駭客任務》中，Trinity 為了救 Neo，說了句「我需要學會開 B-212 直升機」，下一秒，駕駛技能就被瞬間下載到她腦中嗎？Subagents 的概念正是如此。\n在 Claude Code 中，我們可以透過 .claude/agents/ 目錄下的描述檔，定義不同角色的「專家代理人」。你可以創建一個嚴謹的「資深測試工程師」、一個善於規劃的「敏捷專案經理」、或是一個天馬行空的「創意文案大師」。\n當你面對一項任務時，不再是與一個泛用的 AI 對話，而是可以召喚對應的專家。例如，當你需要規劃專案時程，你啟動「專案經理」Agent；當你需要重構程式碼，你呼叫「系統架構師」Agent。\n這正是「點→線→面」演進中的「面」——我們的工作區不再是單一的對話線，而是由多個專家對話線交織而成的協作平面。你可以隨時根據任務需求，組建一支夢幻 AI 團隊，而你，就是這個團隊的指揮官。\n轉折點四：自主技能 (Skills) —— AI 獲得了「神經反射」 第四個轉折，是 AI 從「被動執行」邁向「主動判斷」。\n如果說 Subagents 讓 AI 擁有了「特化手臂」，那麼 Skills 功能就為這些手臂裝上了「自主反應的神經」。\nSkills 是定義在 ~/.claude/skills/ 目錄中的一組可重用指令集。與 Subagents 不同，Skills 可以由 AI 自主判斷並調用。\n舉個例子：過去，當 AI 寫完一段程式碼後，你需要明確指示它「請執行單元測試」。但現在，如果你定義了一個名為 run_unit_tests 的 Skill，AI 在完成程式碼撰寫後，可能會自主判斷：「根據任務上下文，我應該運行測試來驗證我的程式碼。」然後自動調用該 Skill。\n這是一個從「被動聽令」到「主動解決問題」的質變。AI 不再只是等待我們下達一個個具體指令的操作員，而是能夠理解「任務目標」，並自主拆解、調用技能來達成目標的智慧夥伴。這極大地降低了我們的認知負擔，讓我們能更專注於「做出決策」，而不是「分派執行任務」。\n結論：從「操作員」到「指揮官」—— 我們在 AI 時代的新價值 回顧 2025 年，AI 協作的四次躍進，將 AI 從一個工具，變成了我們的夥伴。這個夥伴不僅能理解我們的專案（Claude Code）、與世界互動（MCP）、扮演專家（Subagents），甚至能主動思考如何完成任務（Skills）。\n這場變革中，我們人類的角色也發生了深刻的轉變——我們正從繁瑣的「操作員」，進化為宏觀的「指揮官」和「決策者」。\n我們的價值不再是寫出每一行程式碼，或執行每一個命令。我們的核心價值在於：\n定義願景與目標： 我們決定要去哪裡。 做出關鍵決策： 在十字路口，我們選擇方向。 進行創造性思考： 我們提出 AI 無法獨立想出的突破性想法。 承擔最終責任： 我們對結果負責。 2025 年，AI 協作讓我們得以從重複性勞動中解放出來，將更多的精力投入到真正需要人類智慧的戰略性和創造性工作中。這不是一個「被取代」的故事，而是一個「被增強」的序章。站在 2026 年的開端，我們有理由相信，更精彩的人機協作新紀元，才剛剛開始。\n","permalink":"https://blog.notes47y.win/posts/2026-01-23-2025-ai-collab-four-turning-points/","summary":"\u003ch1 id=\"從指令到協作重塑開發典範的-2025-年-ai-協作四大轉折點\"\u003e從指令到協作：重塑開發典範的 2025 年 AI 協作四大轉折點\u003c/h1\u003e\n\u003ch2 id=\"前言你的-ai-副駕已從聊天室駛入你的專案核心\"\u003e前言：你的 AI 副駕，已從聊天室駛入你的專案核心\u003c/h2\u003e\n\u003cp\u003e還記得 2023 年，我們在 IDE 和 ChatGPT 視窗間瘋狂複製貼上的日子嗎？那時的 AI 像個博學但健忘的實習生，雖然能給出精彩的程式碼片段，卻無法真正理解我們專案的全貌。我們像個循循善誘的導師，不厭其煩地提供上下文，只為求得一段可用的程式碼。\u003c/p\u003e\n\u003cp\u003e快轉到 2025 年，場景已截然不同。AI 不再僅僅是個「對話框裡的聰明腦袋」，它已經進化成一個深度整合在我們工作流程中的「協作夥伴」。它能閱讀整個專案、串接外部服務、甚至能化身為不同領域的專家團隊，與我們共同完成複雜的任務。\u003c/p\u003e\n\u003cp\u003e這一年，我們見證了 AI 協作從「點狀問答」到「立體協作網絡」的驚人躍進。這是一場從根本上改變我們工作方式的典範轉移。本文將以我個人的實戰經驗，歸納出推動這場革命的四個關鍵轉折點，並探討在這波浪潮中，我們人類的核心價值將如何重新定義。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ai-協作的演進從點線到面\"\u003eAI 協作的演進：從點、線到面\u003c/h2\u003e\n\u003cp\u003e在深入探討四大轉折點之前，讓我們先建立一個思維框架：「點、線、面」的演進。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e點 (Point):\u003c/strong\u003e 早期的 AI 對話是「一次性」的。你問一個問題，它給一個答案。每個互動都是一個孤立的「點」，缺乏連貫性。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e線 (Line):\u003c/strong\u003e 隨著記憶功能的增強，AI 能記住對話的上下文，讓互動得以延伸成一條「線」。我們可以圍繞一個主題進行深入探討，而不會輕易失焦。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e面 (Plane):\u003c/strong\u003e 2025 年的突破，則是將多條專家「線」整合起來，形成一個多維度的協作「面」。我們不再是與單一 AI 互動，而是指揮一個由多個 AI 專家組成的團隊。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cimg alt=\"AI 協作演進：從點到線到面\" loading=\"lazy\" src=\"assets/2025-ai-collab/01_%E9%BB%9E%E7%B7%9A%E9%9D%A2%E6%BC%94%E9%80%B2_Triptych.png\"\u003e\u003c/p\u003e\n\u003cp\u003e這個「點→線→面」的框架，將貫穿我們接下來要探討的四大轉折。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"轉折點一專案級上下文感知-claude-code--ai-終於學會了閱讀\"\u003e轉折點一：專案級上下文感知 (Claude Code) —— AI 終於學會了閱讀\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e第一個轉折，是 AI 從「失憶金魚」進化為「專案圖書館員」。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e年初，Anthropic 推出的 VS Code 擴充套件 \u003cstrong\u003eClaude Code\u003c/strong\u003e，徹底改變了遊戲規則。它最關鍵的突破，在於賦予 AI \u003cstrong\u003e檢視整個專案資料夾\u003c/strong\u003e 的能力。\u003c/p\u003e\n\u003cp\u003e這意味著，AI 不再需要我們手動餵養程式碼片段。它能像一位新加入的團隊成員一樣，自己去閱讀專案結構、理解程式碼之間的依賴關係、甚至參考過去的工作日誌（Work Log）。每一次的協作成果都被記錄下來，成為未來任務的養分。當你需要修改一個與三個月前某個功能相關的模組時，AI 不再是一臉茫然，而是能迅速調閱相關文件與程式碼，提供精準的建議。\u003c/p\u003e","title":"從指令到協作：重塑開發典範的 2025 年 AI 協作四大轉折點"},{"content":"嗨，我是 Shawn 👋 notes47y 是一個用 AI Agent 團隊經營的個人品牌實驗室——從選題、研究、寫作到發布，每一個環節都有 AI 參與。這裡記錄的不只是知識，更是一套正在運作中的人機協作系統。\n我在做什麼 白天：Salesforce 技術顧問，幫企業導入 CRM 與忠誠度系統。\n下班後：用 AI Agent 團隊經營 notes47y，把工作踩過的坑轉化成對你有用的文章。\n這個 Blog 的三個主題 主題 在寫什麼 AI 協作 Claude Code 實戰、Agent 架構、Prompt 工程 知識管理 Zettelkasten、Obsidian、第二大腦建立 Salesforce Loyalty Management、產業洞察、技術選型 工具箱 主力 AI：Claude Code + Paperclip Agent Team 知識庫：Obsidian + Zettelkasten（100+ 永久筆記） Blog 技術棧：Hugo + PaperMod + Cloudflare Workers 任務管理：Paperclip（12 個 AI Agent 組成的內容工廠） 聯絡我 X：@notes47y Threads：@notes47y Instagram：@notes47y ","permalink":"https://blog.notes47y.win/about/","summary":"關於 Shawn Cheng 與 notes47y","title":"關於我"}]