用 AI 代理開發以太坊：技能檔、輕量規格與回饋迴圈

值得記下的 5 件事

1. [5:10]
   工具設計要讓代理取得可直接運用的脈絡

   團隊過去用擴充套件降低人類開發者的整合負擔，如今則將部分做法改寫成英文技能檔，讓代理依指引產生程式碼、串接服務。重點不只是增加文件，而是把希望採用的工具、開發模式與程式風格，放進代理能讀取的脈絡。

2. [9:35]
   懂以太坊，不代表會主動採用合適做法

   Shiv 分享的評估案例中，代理會漏掉順暢的切鏈互動或以太坊名稱服務（ENS）輸入支援；也曾有開放模型找不到 Foundry 旗標，轉而自行產生以太坊虛擬機（EVM）。這類偏航在鏈上可能涉及金錢成本，仍須以明確提示與可靠資源引導。

3. [14:35]
   以完整功能切分任務，能縮短代理的回饋路徑

   Shiv 觀察，代理常傾向先完成某一層的全部工作，但他建議每個任務都涵蓋合約、頁面與前端 hooks。當前端實作暴露事件索引需求時，代理便能回頭調整合約，及早利用整合回饋修正設計，而非等各層全部完成才發現落差。

4. [16:58]
   人的責任是觀察並修正整個代理工作迴圈

   流程從規格、實作、驗證、程式碼審查一路到交付，仍需要人持續監督。若代理驗證耗時過長，或反覆出現同一錯誤，人應記錄問題、調整指引與流程，讓下一輪任務受益，而不只是逐次修補代理產出的程式碼。

5. [25:56]
   規格要保持輕量，程式碼本身也要承載需求脈絡

   面對既有服務是否應依規格重寫的提問，Shiv 選擇以輕量規格搭配現有程式碼作為代理脈絡。他提醒，多人協作時，其他成員的代理未必同步更新規格，文件容易過時，因此團隊仍須在規格與程式碼的描述能力之間取得平衡。