超越基礎：Claude Code 進階用法（第 1/4 段） ☕ Buy me a coffee

🧑‍🏫 這是 Claude Code 團隊工程師 Daisy Holman 進階演講的第一段。她說明在大公司或大型專案裡，Claude Code 不能只用預設設定，要替它補上「存取、知識、工具」三樣東西。就算你不寫程式，也能從中學到一個道理：AI 做不好，常常是因為它缺少你腦中的資訊。這個思路適用在任何 AI 工作流程。

• 00:00 講者 Daisy Holman 是 Claude Code 團隊的工程師，這場主講是「beyond the basics」，重點放在 agentic software engineering，而不只是 agentic programming
  ↳ agentic 指 AI 會自己規劃、動手做事。講者區分兩件事：agentic programming 是讓 AI 寫程式，agentic software engineering 是讓 AI 參與整個軟體工程，包含協作、維護和上線。
• 00:45 這場演講鎖定軟體工程環境，談在這類環境裡客製化 agent 會遇到的限制
  ↳ 她關注的是真實公司裡的軟體開發現場：人多、系統大、規矩多。這場要談的是：在這種環境裡，想把 agent（能自己動手做事的 AI 助手）調成合用，會卡在哪裡。
• 00:45 講者很早就加入 Claude Code，參與過 plug-ins 和 agent teams 等專案；背景是程式語言
  ↳ 她是 Claude Code 的早期成員。plug-ins 是替 Claude Code 加裝功能的擴充套件。agent teams 是另一個專案，這段影片沒有細講。她的本行是研究程式語言。
• 01:15 講者曾任 C++ 委員會的 chair，認為程式語言領域的很多觀念也適用於 agentic harness 的設計
  ↳ C++ 是一個老牌、廣泛使用的程式語言，委員會負責制定它的標準。她認為設計程式語言的經驗，可以拿來設計 agentic harness，也就是包在 AI 模型外面、讓它能實際做事的那層工具。
• 01:15 講者的目標是：不論技術程度高低，都能輕鬆把想法做成可上線的產品，也希望軟體工程師參與其中
  ↳ 她希望不論會不會寫程式，每個人都能把點子做成真正能上線給人用的產品。她也希望專業工程師不是被取代，而是一起參與。
• 01:45 講者認為 Claude Code 是最早真正能大規模做到這件事的工具之一
  ↳ 她認為 Claude Code 是最早能在大規模的真實環境裡，把「點子變成產品」真正做起來的工具之一。
• 01:45 Claude Code 開箱即用，處理簡單的「programming 任務」就表現不錯；但複雜度一提高、進入「software engineering 任務」，就需要調整設定、做客製化
  ↳ 預設的 Claude Code 寫個小功能、修個小 bug 沒問題。但工作一旦牽涉很多人、很多系統、還要長期維護，就得替它調整設定、補充資料，它才會好用。
• 02:15 演講大綱：怎麼看待 context window、它和 software packaging 的類比（以及類比在哪裡不成立）、plugins 的關鍵抽象概念，以及哪些能擴展到大規模環境
  ↳ context window 是 AI 一次能讀進來的內容上限。software packaging 是把軟體功能打包、讓別人安裝使用的做法。她會拿兩者來類比，也會說明這個類比哪裡不適用。
• 02:46 所謂大規模，是指有數百、數千甚至數萬名工程師共用同一個 code base 的環境，必須有效率地傳遞資訊，又不能太快把 context 塞滿
  ↳ code base 是一個專案的全部程式碼。大規模指幾百到幾萬人共用同一份程式碼。難題在於：給 AI 的資訊要夠，但又不能一下子塞爆它的 context window。
• 02:46 時間允許的話，最後會介紹 Claude Code 的新功能，以及團隊內部怎麼用 Claude Code 開發 Claude Code
  ↳ 如果時間夠，她最後會介紹 Claude Code 的新功能，以及團隊怎麼用 Claude Code 來開發 Claude Code 本身。
• 03:18 講者也把「如何用資訊、連線能力等客製化通用的 agentic harness」當成一個學術問題來看，不只限於 Claude Code
  ↳ 她不只把這當成產品設定問題，也當成研究題目：一個通用的 AI 工具，要餵它哪些資訊、接上哪些系統，才能變成適合特定工作的助手？
• 03:48 客製化需要的東西分成三類：Access（存取）、Knowledge（知識）、Tooling（工具）
  ↳ 這是整場的架構。Access 是讓 AI 碰得到哪些資料和系統，Knowledge 是它該知道的內部知識，Tooling 是給它用的工具。
• 03:48 全場核心論點：如果 Claude 做不到你能做的每件事，它就沒辦法跟你一起完成你的工作
  ↳ 這是整場最重要的一句話：你看得到、做得到的事，如果 Claude 做不到，它就只能幫你做一小段，沒辦法真正陪你把工作做完。
• 03:48 軟體工程師現在的工作是做出自己的「小分身」，把自己的能力和工作量擴展到很多個 agent 上
  ↳ 意思是工程師的角色在改變：不只是自己做事，而是把自己的判斷和做法教給很多個 AI，讓它們同時替你分頭工作。
• 04:21 Claude 需要能碰到你碰得到的東西，不只是原始碼，還包括 Slack 訊息、email 等，才能理解任務的「why」，而不只是「what」
  ↳ what 是要改什麼，why 是為什麼要改。原因常常藏在 Slack（公司常用的聊天工具）或 email 裡，Claude 看不到這些，就只能照字面去做。
• 04:21 原始碼通常不會交代改動的動機；這些資訊已經存在別的地方，你也不會每次都想在 prompt 裡重打一遍
  ↳ 程式碼只會記錄改成什麼樣子，通常不會寫為什麼這樣改。那些背景早就在別的地方討論過了，你也不會想每次下指令都從頭解釋一遍。
• 04:52 開箱時 Claude 只看得到一個 repo 和一個 shell。這對沒有既有慣例、沒有累積技術債、沒有眾多利害關係人的 zero to one 專案還算夠用
  ↳ repo 是存放專案程式碼的地方，shell 是用打指令來操作電腦的視窗。從零開始的新專案（zero to one）沒有技術債（以前趕工留下、之後得收拾的問題），用預設設定就夠了。
• 05:25 原生的 Claude Code 很少足以支撐大規模、高品質的軟體工程；做很末端（leaf）的軟體或許還行，但只要有人依賴你、或有外部利害關係人，就要給 Claude 工具去理解他們的考量
  ↳ leaf 指位在最末端、沒有別人依賴的小程式，用預設還行。但只要有人靠你的軟體運作，或是有 stakeholders（會受影響的利害關係人），就得讓 Claude 了解他們在意什麼。
• 05:56 專業軟體工程（尤其是大規模的）大部分工作不在原始碼裡，而在設計文件、email、Slack 對話中
  ↳ 在大公司當工程師，大部分時間花在開會討論、寫設計文件、回信、在聊天群組裡對齊想法，寫程式只是其中一部分。所以關鍵資訊大多不在程式碼裡。
• 06:29 要給 Claude 的存取之一：團隊聊天。如果 Claude 看得到整串討論為什麼要這樣實作的 Slack thread，就能判斷某個策略為什麼行不通、哪個方案比較好
  ↳ thread 是聊天工具裡針對同一個話題的一串回覆。如果 Claude 看得到當初大家討論「為什麼要這樣做」的那串對話，它就知道哪條路試過行不通、哪個方案比較好。
• 06:29 大家常覺得 Claude 方向走偏，通常是因為你腦中有某個資訊是 Claude 拿不到的；讓它拿得到，它就更容易跟你同步
  ↳ 大家常覺得 AI「方向走歪了」，多半不是它笨，而是你知道某件事但它不知道。與其一直糾正它，不如讓它拿得到那份資訊。
• 07:00 存取之二：CI/CD，講者說這非常關鍵。現在不該再自己修 CI failures，agent 很擅長做這件事
  ↳ CI/CD 是程式改完之後自動測試、自動部署的流程，測試沒通過就叫 CI failure。她認為這種修錯的工作應該交給 agent，人不必再自己一個一個查。
• 07:00 存取之三：Dashboards。正式環境出問題時要能快速彙整大量資訊，而你的競爭對手正在用 agent 的方式做這件事
  ↳ Dashboards 是即時顯示系統狀態的監控畫面。線上服務出問題時，得馬上整合大量資訊找出原因。她提醒大家：你的競爭對手已經在用 agent 做這件事了。
• 07:34 排障必須用 agent 的方式做到有效率、準確、值得信任，而且 Claude 需要看得到「why」
  ↳ 排查問題要又快又準，結果也要值得信任。而且 Claude 得知道系統當初為什麼這樣設計，才不會只看到表面症狀就亂修。
• 07:34 存取之四：內部文件，例如設計文件、run books 等
  ↳ 設計文件記錄系統怎麼設計、為什麼這樣設計。run books 是出狀況時照著做的操作手冊。這些也都應該讓 Claude 讀得到。
• 07:34 講者的做法：會議錄音或轉成逐字稿，會後把會議紀錄丟給 Claude，問它有沒有能順手處理的 low-hanging fruit
  ↳ 她開會時會錄音或轉成逐字稿，會後把紀錄交給 Claude，問它有沒有 low-hanging fruit，也就是順手就能做掉的小事。
• 08:05 講者說每場會議這樣做能拿到兩三個 PR，並強烈建議大家試試
  ↳ PR（pull request）是工程師提交一份程式修改、請別人審核的單位。她說每場會議這樣做都能生出兩三個 PR，很推薦大家試試看。
• 08:05 Claude 要知道你為什麼想做某件事，才能選出最好的做法，像同事一樣跟你合作
  ↳ Claude 知道你的目的，才能在幾種做法中挑出最適合的，而不是只照字面指令去做。這樣它比較像一個懂狀況的同事，而不是只會聽命令的工具。
• 08:05 講者的建議：試著整天不離開 Claude Code 工作；每次需要切到別的工具、再複製貼上給 Claude，就代表那是 Claude 缺少的東西
  ↳ 具體做法是：整天都待在 Claude Code 裡工作。每當你得跑去別的地方找資料、再複製貼上給它，就代表那個資料來源是 Claude 還碰不到的。
• 08:38 把這些時刻記在紙上，一天結束後想辦法把 Claude 接上這些來源。效果會比你預期好很多，全部接起來之前你不會察覺差距有多大
  ↳ 把這些「得切出去」的時刻記在紙上，下班前想辦法讓 Claude 直接接上那些來源。她說效果會超乎預期，只是在全部接好之前，你感受不到落差有多大。
• 08:38 Knowledge：你 code base 的慣例、組織記憶、上週才改的東西、內部用語、內部 API，都沒辦法訓練進模型
  ↳ 模型是事先訓練好的，不會知道你們團隊的程式寫法慣例、以前做過的決定、上週才改的東西、內部行話，以及內部 API（程式之間互相溝通的接口）。
• 09:14 Fine-tuning 對這種需求效果不好。講者提到 2025 年底有論文指出，用專業資訊做 fine-tuning 可能導致更多幻覺
  ↳ Fine-tuning 是拿自己的資料再去訓練模型。她說用在這裡效果不好，還提到 2025 年底有論文指出，拿專業資料做 fine-tuning 反而可能讓 AI 更常一本正經地胡說，也就是幻覺。
• 09:14 Fine-tuning 也不符成本效益：frontier model 更新太快，就算是大公司，針對 frontier model 做 fine-tuning 目前也划不來
  ↳ frontier model 是當下最頂尖的模型。它們更新得太快，你花大錢調好一版，新版早就推出了，所以連大公司都覺得不划算。
• 09:44 因此這些知識都要靠 in-context memory／in-context learning（ICL），也就是 in-context files 來提供
  ↳ 所以做法是把知識寫成檔案，在 AI 工作時放進它的 context 讓它讀，這叫 in-context learning（ICL）。說穿了就是給它看對的資料，而不是去改造模型本身。
• 10:14 講者引用 bitter lesson：長期來看通用 AI 會勝過專用 AI，現在在 frontier model 上就看得到這個現象；實務上不可能把你工作或 code base 專屬的東西訓練進模型
  ↳ bitter lesson 是 AI 領域的一個觀點：長期來看，通用的模型會贏過專為特定用途打造的模型。所以想把你公司專屬的東西訓練進模型，實務上行不通。
• 10:14 你能用的是 skills、tools（字幕另提到「AMD」）等來改善結果，但也只有這些，沒辦法影響模型的權重
  ↳ skills 是寫給 Claude 的說明檔，教它某類工作怎麼做。tools 是讓它能呼叫的功能。字幕另外提到「AMD」，但沒說清楚是指什麼。你能調整的就是這些，模型內部改不到。
• 10:44 好處是不需要懂模型權重就能客製化它的行為，而且能用的東西都只是文字檔，非常容易上手
  ↳ 模型權重（model weights）是模型內部學到的參數。好消息是你不用懂這些，只要寫文字檔就能改變它的表現，門檻很低。
• 11:15 很多人做到這一步就覺得夠了，但 in-context learning 其實還有很多可以優化的空間
  ↳ 很多人寫好幾份說明檔就覺得夠了，但她認為「怎麼把資料提供給 AI」還有很大的改進空間，不是寫完就沒事了。
• 11:15 Tooling：講者思考「給 Claude 用的 IDE 該長什麼樣子」，並拿人類寫程式都會用 syntax highlighting 來類比
  ↳ IDE 是工程師寫程式用的整合軟體，syntax highlighting 是把程式碼依照類型上色、方便閱讀。人類寫程式都靠這類工具，所以她在思考：給 Claude 用的工具該長什麼樣子？

講者認為客製化 agentic harness 需要的東西分成哪三大類？