一個 repo 為什麼能控制其他 repo?答案不是程式碼,是「權限」這條看不見的線
我搞不懂:一個 repo 怎麼有辦法去開另一個 repo 的 Issue、把它們綁在一起?我以為是程式碼之間有什麼隱形連線。Claude 先破除我的誤解——repo 本身什麼都控制不了,真正動手的是一個「有權限的身分(Token)」,透過 GitHub API 去操作。把四個 repo 綁在一起的,是權限和註冊表,不是程式碼。
標籤文章
我搞不懂:一個 repo 怎麼有辦法去開另一個 repo 的 Issue、把它們綁在一起?我以為是程式碼之間有什麼隱形連線。Claude 先破除我的誤解——repo 本身什麼都控制不了,真正動手的是一個「有權限的身分(Token)」,透過 GitHub API 去操作。把四個 repo 綁在一起的,是權限和註冊表,不是程式碼。
我拉了一個專案,它是「主支線目標規劃中心」,底下管著三個執行用的 repo。我請 Claude 解讀派工腳本的機制,順便教我這套結構在工程界的真實說法——結果一路從 hub-and-spoke 講到 orchestrator–worker、control plane,還發現它跟物流業的軸輻網路是同一個道理。
我把團隊套進軸輻網路:我是中樞 H、三個 repo 是執行的 M 群、同事小花是發需求的 N 群。然後我問——小花能不能同時升格成共同管理人?順著這題,Claude 帶我釐清了兩件事:角色不是人的屬性而是權限給的、以及為什麼「共用一把鑰匙」是資安大忌。
我請 Claude 深讀 awesome-mcp-and-skills repo 的 23 個 skill,逐一拆解程式碼品質,從 S 級到 B 級分層,提煉出 7 個設計原則,最後把自己的 md-to-pdf-kit 從零分升級到 S 級並部署上線。
從三層容錯到編排器模式,12 段技術精華花了三天學完。但最大的收穫不是技術,而是學會了怎麼學:追問、串連、動手做、再追問。
使用者不會告訴你哪裡不好,但 log 會。每天一句 prompt、3 分鐘看排行榜,30 天修了 110 個問題。這篇講怎麼做。
蒸餾精華最後一段講編排器模式。我追問了「能不能做一個貼連結就給影片、音檔、逐字稿的服務」,結果 12 段蒸餾精華全部串在一起了。
蒸餾精華第 8 段講台灣用語自檢 Prompt。我追問了「是否需要智慧繁簡對照表」,發現繁簡轉換不只是字體,是三層問題:字形、詞彙、語境。
蒸餾精華第 7 段講 PEP 723 行內依賴。我追問了「能不能用在每週建站、會議紀錄、學習筆記」,結果設計出了一套個人 AI 工作流:/new-site、/meeting、/note、/capture。
統一的 Provider 介面讓你能在不同 AI 服務之間切換,但「有能力做」和「該不該做」是兩件事。偷偷切換模型,使用者的讚美和批評都會記在錯的帳上。
你的程式需要等 API 回應、等部署完成、等轉檔結束。盲等 60 秒可能太長也可能太短。poll_until 每秒問一次「好了嗎?」——永遠在最快的時機繼續。
蒸餾精華第 11 段講 CLAUDE.md 觸發詞索引。我追問了「我的全域 CLAUDE.md 有用到這個原理嗎」,發現沒有,當場補上了路由表。