透過代理技能 (agent skills)，讓團隊人人有主任工程師思維

最近看到前 Meta 主任工程師 Lauren Tan 跳槽去 Cursor 後，把她平常工作時會用來理解新程式碼庫、理解還不懂的技術的流程，轉成一組代理技能 (agent skills)。

非常推薦，如果你是在團隊中的資深工程師，或主任工程師，透過這種方式，等於能幫團隊的成員在探索問題時，都能有相同的思考方式來搭配 AI 代理。

(備註：如果對代理技能是什麼不熟，可以參考這篇 代理技能 (Agent Skills) 是什麼? 解決了什麼問題? 文章)

把思考流程化

舉例來說，以下是 Lauren Tan 把讀程式碼的方式轉換成的代理技能

首先，先找到相關的程式碼。用 Glob 來找出目錄和檔案，用 Grep 找出關鍵的符號，用 Read 去理解實際的實作內容。不要只看名稱就用猜的，一定要讀程式碼。 照著這個模式進行：

1. 找到進入點：這個行為是被什麼觸發的？是使用者操作、API 呼叫，還是排程任務？先找出整個流程是從哪裡開始的。
2. 追蹤流程：從進入點開始，一路跟著呼叫鏈往下追。每個函式都要讀，搞懂資料是怎麼流動的、又在過程中被怎麼轉換。
3. 整理出關鍵的抽象概念：哪些型別、介面、服務或類別是核心？去讀它們的定義。弄清楚它們代表什麼、為什麼會存在。
4. 找出邊界：這個子系統跟其他系統是在哪裡接上的？輸入是什麼，輸出又是什麼？
5. 注意不直觀的地方：有沒有什麼地方讓你覺得很意外？有沒有看起來像歷史遺留的程式碼？有沒有什麼是新人很容易誤解的？
6. 持續探索，直到你能完整描述全貌，不需要含糊帶過：如果遇到追不下去的部分，就明確講出來「我沒辦法確定 X 是怎麼連到 Y 的」也比自己亂掰好。

看待抽象與複雜度的思考方式

以下是她在看不同層級抽象時的思考方式

• 每個抽象層代表的是真實的概念，還是只是「以防萬一以後會用到」的多餘間接層？
• 抽象邊界畫對地方了嗎？ 它們真的有把會獨立變化的東西分開嗎？
• 有沒有出現不必要的耦合，讓兩個元件共享了不該知道的實作細節？
• 商業邏輯有跟框架的配置纏在一起，還是乾淨地分離開來？

在看待系統的複雜性時，她則會問

• 複雜度集中在哪裡？是在真正需要複雜的地方（核心邏輯、棘手的邊界條件），還是在不必要的地方（樣板程式碼、多餘的間接層、設定檔）？
• 有沒有更簡單的方式能達到同樣的效果？
• 每個元件都有存在的理由嗎？還是有些只是舊設計遺留下來的殘骸？

感興趣了解更多的人，可以在這邊看到 Lauren Tan 的完整分享 (連結)

備註：如果你對協助團隊建立讓 AI 能成功的基礎感興趣，包含建立代理技能、複利工程 (compound engineering)、有效減少 AI tokens 消耗成本等主題感興趣，我們在近期受讀者好評的 E+ 《AI Coding 201 — 從實戰到最佳實踐》都有詳談，我們也把 E+ 連結在這邊 (連結)，歡迎加入後觀看