昨天 Day 22，我們沒有從零打造氣象資料服務，也沒有自己重寫一套科學繪圖工具。我們把公開資料、整理程式和 Academic Figure Skill 接起來，真的做出了一張正式的圖。
只是文章最後也留下一個有點太過美好的畫面：我原本只想每週看一次天氣變化，Skill 卻很盡責地準備了接近論文投稿規格的成果。
工具沒有做錯。它只是忠實執行了原本的設計，而那個設計未必完全符合我的用途。
於是，「不要什麼都自己做」之後，很快就會遇到下一個問題：既然別人已經整理出很好的工具和方法，我是不是整套照搬就好了？
這讓我想到另一個比較直接的說法：
穿上喬丹的球鞋，不等於你就是喬丹。
球鞋確實很好，也可能讓你更舒服地走上球場；但他看過的防守、做過的選擇，以及多年練出的判斷，不會跟著鞋帶一起綁到你身上。
CLAUDE.md，現在真的開始工作了Day 19 用過一份可以放進 CLAUDE.md 的守則。它提醒 AI 不要亂猜、不要把小事做得太複雜、不要順手修改不相干的程式，完成後還要驗證結果。
這些原則都很合理。第一次不知道怎麼寫規則時，先使用 forrestchang/andrej-karpathy-skills 這類別人整理過的範例，也比對著空白檔案苦想「我的 AI 工作哲學」實際得多。
但問題通常不在下載的那一刻，而在這套方法真的開始和我一起工作之後。
想像我把守則放進 Claude Code。AI 變得比較謹慎，遇到複雜修改時，不再埋頭就做，而是先把選項攤開：
Option A preserves the current abstraction boundary, but introduces an additional dependency.
Option B reduces indirection, but increases coupling between these modules.
We should decide whether the current interface is part of the stable architecture before refactoring.
如果你是資深工程師，可能已經開始比較兩種做法。但如果你正在做第一個網站，腦中可能只剩：
等一下，你剛剛到底在講什麼？（我好想關電腦……）
先不用假裝聽懂。現在至少可以看見第一個摩擦：這套規則要求 AI 說明取捨，AI 也照做了，但它使用的是軟工的語言，不是我現在能拿來做判斷的語言。
如果第一個障礙是英文，最直接的做法就是先請 AI 使用繁體中文。剛才三句話大概會變成：
方案 A 會保留目前的抽象邊界，但會引入一個額外的相依性。
方案 B 會減少間接層，但會增加這些模組之間的耦合。
在重構以前，我們應該先決定目前的介面是不是穩定架構的一部分。
至少現在不用一邊處理程式，一邊參加英文閱讀測驗。先把語言負擔拿掉，本身就是進步。
但讀完後，也可能出現一個很誠實的反應：
每個字好像都變成中文了，可是我還是不知道該選 A 還是 B。
翻譯解決的是「英文看不懂」，不一定能解決「概念還沒學過」。抽象邊界、相依性、耦合和重構雖然都換成中文，仍然是工程術語。
語言這道門打開了，但我還沒有走進房間。
看到每個字都是中文，卻還是不知道該選 A 還是 B，最常見的反應可能是：
請幫我分析兩個方案的優缺點，再直接選一個最適合我的做法。
很好，原本那份守則費盡心力把選擇攤到我面前，我看了三秒，又把整張考卷推回 AI 那邊。
這樣做不一定錯。低風險、容易反悔的小決定，讓 AI 先選一個確實很省時間。但如果選擇會影響後面的架構、費用或維護方式，而我連它用什麼標準判斷都不知道，那麼我得到的只是一個答案，下一次仍然不會選。
Matt Pocock 的 Skills 儲存庫裡有一個很短的 wait-what。它做的事很單純：當使用者沒跟上時，先停一下，補足必要背景，再換一種說法。
我可以借用這個做法，再補上一條適合自己的規則：當我不理解專有名詞時，先用目前專案的例子或生活類比說明；可以提出建議，但要告訴我判斷依據，以及什麼條件改變時會改選另一個方案。
同一段內容重新說明後，可能會變成：
選 A 的話，原本程式的分工可以先不動，但會多依賴一個外部工具。以後那個工具改變或停止維護，我們也得跟著處理。
選 B 的話，程式看起來會少繞一層；但原本各自負責不同事情的兩個部分，會綁得更緊。以後改其中一邊，另一邊也比較容易被牽動。
可以把它想成兩間原本各自有門的房間。選 A 是多請一位外面的管理員幫忙；選 B 則是在兩間房之間直接打通一扇門。現在要先決定：未來還需不需要維持這兩間房各自獨立？
現在再把白話和工程詞接回來，就容易多了。「原本的分工界線」是抽象邊界；「多依賴一個外部工具」是相依性；「改一邊容易牽動另一邊」是耦合；兩個部分按照什麼方式溝通，談的則是介面。
到了這裡，我不一定已經知道最佳答案，但至少開始有能力追問：外部工具可靠嗎？兩個部分未來會不會分開修改？這個專案只展示兩天，還是要維護兩年？AI 仍然可以推薦一個選項，但我不再只拿走結論。
這就是借來的方法第一次開始改變。原本的規則只要求 AI 說清楚取捨；我根據自己的困難，再加上繁體中文、白話解釋和判斷依據。專業內容沒有被刪掉，只是多鋪了一條我目前走得進去的路。
看到別人的規則檔、提示詞或 Skill 時，很多人的第一個動作是：我要先設計一份完美設定。
於是還沒真的工作，就開始搜尋「最強規則檔」、「必裝 Skill」和「最佳流程」。最後設定檔比專案本身還完整，拼來拼去還是拼出了深海的大鳳梨。
真正有用的客製化，通常不是坐在桌前想出來的。要先讓它工作，摩擦才會出現。
假設你連續三次請 AI 修改網頁，最後都發現它講得很完整，卻沒有先告訴你「這次究竟動了哪些檔案」。那你不必急著重寫整套方法，只要把這個痛點補成一句規則：完成前，先用白話列出改動的檔案、目的與尚未確認的地方。
下一次再用一個小任務試試看。它若讓你更容易檢查，就留下來；如果每個小修改都因此多出一頁報告，就把它縮短。規則不是一次寫完的憲法，而是你和 AI 協作時，根據真實摩擦留下的工作筆記。
借用 → 使用 → 觀察摩擦 → 修改 → 再驗證。
這不只適用 CLAUDE.md。提示詞、Skill、工具，甚至你和 AI 的合作方式，都可以慢慢長出自己的版本。
AI 社群很喜歡用誇飾法去描述東西：最佳提示詞、神級 Skill、必裝工具、完美工作流程。這些內容值得看，但帶回自己的工作前，最好補問一句：「這是對誰最好的做法？」資深工程師覺得順手的流程，不一定適合第一次做網站的小白；兩天內要做出展示作品的小組，和需要長期維護的服務，也不該承受相同的流程成本。
因此，別人口中的最佳做法，比較像一個已經有人試過、值得優先測試的起點，而不是禁止修改的終點。Day 22 教我們不要拒絕別人的成果；Day 23 則提醒我們，拿到成果後也不要放棄自己的判斷。
穿上喬丹的球鞋不會讓你立刻成為喬丹，但球鞋可以帶你走上球場。當你開始看懂一條規則、依自己的情況修改，再用下一次任務驗證，那一刻就不只是在模仿大神的外表，而是在練習大神也曾練過的能力。
我們不必成為下一個大神，也不必變成任何人的複製品。站在巨人肩膀上的價值不是省略練習，而是讓自己能從一個更好的起點開始練習。
借來的方法不合用，我們比較容易懷疑它，畢竟它本來就不是為我設計的。
可是，如果一套方法曾經讓自己考上學校、完成專案、受到稱讚，甚至得到升遷，它就很容易從「可以修改的工具」，變成「我就是靠這樣成功的人」。這時候，要改掉它可能比修改別人的規則更困難。
昨天有效的方法不一定會突然失效。更常見的是，它慢慢從捷徑變成慣性，而我們因為它曾經成功過，反而最晚發現。
Day 24，我們就來談這件更難的事：困住你的，會不會是那個做對了的自己？自身的經驗反而成為最大的絆腳石。
下次看到一份熱門的 Skill、規則檔或流程時，可以先問自己：它原本在解什麼問題？它和我現在的目標、能力與限制相符嗎？如果不完全適合，我能不能先改一條規則，再用一個小任務看看是否真的變好？
今天最想留下的一句話是：
穿上大神的球鞋不會讓你立刻變成大神；但從你開始看懂、調整與練習的那一刻，借來的方法就正在變成你的能力。
iThome鐵人賽
看影片追技術