🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

自 2020 年以來,我一直在開源領域持續探索。最初,我是一名貢獻者;過去幾年,我又擔任了專案維護者。在這裡,我學到了很多東西,也盡我所能地回饋社會。

我一直想找到一種方式來追蹤我的進度,並在作品集中展示我的貢獻。它不僅僅是為了突顯成就;它還能監控我的成長,慶祝里程碑,並擁有一個可以與潛在合作夥伴或雇主分享的資源。

長期以來,這是一項手動的、令人沮喪的任務。

試算表之爭

我最初嘗試的追蹤方式比較老套。我嘗試維護一個 Google Sheet,記錄每個合併的拉取請求 (PR)、我提交的每個問題以及每一次有價值的程式碼審查。後來,我嘗試建立一個專門的 GitHub 倉庫,在那裡手動為每個貢獻加入 Markdown 文件。

您大概可以猜到這個故事是如何發展的。

是的,生活開始變得忙碌,我忙於其他事情。突然間,幾天就變成了幾週,不知不覺中,我的追蹤器就完全過時了。它變得陳舊而毫無用處。

Polywork曾經是一個很棒的平台,可以讓我展現自己的成就。我把所有東西都展示出來,從開源貢獻到獲得知名人士的認可。然而,它最終還是走到了盡頭。

後來,我了解了OpenSauced ,長話短說,我成為了一名文件維護者,對這個專案有了更多的了解。它是一個非常棒的工具,有一個很酷的功能,可以突出顯示開源貢獻,讓我可以非常輕鬆地將我的亮點頁面連結到我的簡歷上。它曾經是一個完美的解決方案……直到它不再完美。當它被棄用時,我又回到了原點。

嗯,有時候,靈感會在最意想不到的地方出現。

沙發上的靈感

是的,沒錯。靈感是在一個暑假期間,我正窩在沙發上休息,突然靈光一閃。

幾個月前,我和家人度過了一個漫長的暑假。我刻意遠離科技產品,不帶筆記型電腦,純粹地享受在一起的時光。

有一天,我正窩在沙發上看電視劇,突然想到要做一個開源作品集。我想:「肯定有辦法把這個流程自動化。」 於是我決定嘗試使用 GitHub API 來建立作品集。

但問題是,我並沒有很深的 API 知識,而且我當然不想花幾個小時閱讀文件,浪費我的家庭時間。 😅

所以,在沒有筆記型電腦的情況下,我又對這個想法念念不忘,於是決定嘗試氛圍編碼——這是我以前從未嘗試過的事情。說實話,我對人工智慧有點懷疑,而且我很難創造出有效的提示。我知道,如果我的提示不夠理想,我的免費積分很快就會用完,而且我不想等很長時間才能獲得新的提示。

但凡事都有第一次,不嘗試就不知道結果會怎樣,對吧?

有意義的開源貢獻的四個過濾器

我希望我的作品集不僅能追蹤和記錄所有進展,還能真實反映我所做的貢獻。所以,我對專案應該包含哪些內容、應該剔除哪些內容有一些想法。

1. 協同工作:為什麼只追蹤「外部」儲存庫?

我主要為組織或其他個人的專案做出貢獻並進行維護。我目前沒有自己專用的開源倉庫。這意味著,如果該工具追蹤我的所有活動,它可能會包含諸如個人配置更改或我自己倉庫中的快速沙盒測試之類的內容,而這些內容不屬於開源貢獻。

我的作品集必須是純粹的協作工作記錄。因此,腳本必須從頭開始設計,只捕獲我個人 GitHub 倉庫以外的活動(PR、問題)。

2. 道德底線:為什麼要排除私人儲存庫?

作為貢獻者或維護者,我有時會與我所在組織的私有倉庫互動。將這些活動納入公共作品集在道德上是不合理的——我沒有這些資料,而且這些工作(目前)還不是開源的。

為了保持作品集的清潔、公開和道德,該腳本需要一個嚴格的過濾器來排除任何組織的私人儲存庫中的所有貢獻。

3. 質量過濾器:為什麼要忽略機器人和常規合併?

作為一名維護者,我的工作流程很大一部分都是例行公事:審查和合併來自 Dependabot 等機器人的 PR。雖然這很重要,但它並不能展現我的技術專長或人際互動能力。

因此,日誌需要反映真實的人工協作。解決方案必須主動排除任何由機器人帳戶撰寫的、已審核、合併或關閉的 PR。

4. 捕捉靜默價值:為什麼要追蹤「合作」?

維護者的任務不僅僅是合併 PR。回答問題、提供技術建議、幫助新貢獻者在評論區除錯問題,或解釋問題/PR 關閉或重新打開的原因,都能創造巨大的價值,而無需點擊「提交審核」按鈕。這些工作至關重要,但卻常被忽視和忽視。

我的作品集必須涵蓋這些貢獻。劇本需要一個專門的類別來追蹤「合作」——任何我參與討論或協助,但未提交正式評審的問題或公關。

我需要篩選訊息,設定道德界限,並全面考慮各項工作。因此,我決定建立一個智慧且有主見的追蹤器。

透過我的手機建立自動化

這個專案,即精選開源組合,是使用我的手機建置的。

我使用智慧型手機、GitHub 行動應用程式、行動瀏覽器和Gemini 2.5 Flash作為我的 AI 編碼助理(因為它是免費的!)拼湊了這個專案。

這是一種艱難的工作方式。小螢幕讓導航和測試變成了一場噩夢。測試我的更改的唯一方法是將它們直接推送到我的main分支,然後執行 GitHub Action 工作流程。這是一個緊張而耗時的除錯過程。

我非常依賴人工智慧來幫助我建立 Node.js 腳本並編寫必要的 GitHub API 查詢。

實現自動化

我的精選開源專案組合系統終於可以自動追蹤我的貢獻了。以前我手動記錄和格式化需要花費數小時,現在只需幾分鐘即可自動完成。它基於 Node.js 腳本和 GitHub Actions 工作流程建置,嚴格遵循我對有價值、道德的貢獻的定義。

本計畫的運作方式如下:

1. Node.js 腳本(大腦)

此腳本使用 GitHub API 尋找我的活動。其核心是「智慧同步」邏輯,它決定如何取得資料以及取得哪些資料。為了平衡效率和資料完整性,此腳本設計為兩種執行模式:

  • 快速增量更新,僅獲取新活動以最大限度地減少 API 呼叫並保持系統高效執行。

  • 完全同步,從頭開始重建作品集以清除快取並驗證自追蹤開始以來的所有資料。

然後,腳本應用“四個過濾器”並在我的存儲庫之外尋找四種關鍵貢獻類型:

  • 已合併的 PR:追蹤已合併的 PR

  • 問題:追蹤我提交的錯誤報告或功能請求

  • 已審核的 PR:追蹤我正式審核的 PR

  • 合作:追蹤我對其他人的問題/ PR 的首次評論和討論

要實現所有四個道德過濾器,需要精心建立查詢。例如,為了確保品質和協作,用於尋找已審核 PR 的搜尋查詢必須使用特定的排除篩選器。以下是腳本產生的複雜查詢字串的一部分:

// Snippet of the search query logic:
`is:pr -author:${GITHUB_USERNAME} ... -user:dependabot -user:github-actions[bot] updated:>=${yearStart}`

完整的解決方案結合使用這些搜尋運算符和腳本中的附加 JavaScript 邏輯,以確保最終報告中不包含來自已知機器人的 PR 或我個人儲存庫中的貢獻。

2. GitHub Actions 工作流程(自動化)

這就是讓它變得免提的原因。它有兩個調度方案,有效地最小化 API 請求,同時確保完整的資料歷史記錄:

  1. 每日輕鬆更新'0 1 * * *' )會觸發腳本的增量同步以保持最新狀態。

  2. 每月進行一次全面同步'1 0 1 * *' ),啟動一次完整的資料刷新。它會刪除本地快取和資料文件,重建從我開始追蹤的那一年開始的完整貢獻歷史記錄,確保準確性。

該操作執行腳本,然後自動將新產生的 Markdown 報告提交回儲存庫。

最終成果是一份詳細的季度 Markdown 報告,總結了我的工作成果,包括統計資料和主要貢獻專案。這是一個清晰、可驗證且持續更新的作品集,我對此感到自豪。

Markdown 中的季度 Markdown 報告總結了開源貢獻,包括統計資料和貢獻最大的專案

我從 Vibe Coding 學到的東西 我的開源作品集

這種「氛圍編碼」的經驗讓我學到了一些關於使用人工智慧進行建構的寶貴經驗,特別是對於那些仍在學習某些技術的開發人員而言。

1. 你仍然是建築師

AI 可以寫程式碼,但你必須是架構師。你仍然需要對你正在建立的東西有基本的了解。儘管我不太熟悉 GitHub API 的語法,但我了解所需邏輯:獲取資料、處理資料,然後將其寫入文件。這些基礎知識讓我能夠有效地指導 AI。

2. 做一個批判性思考者,而不是複製貼上者

這是最大的教訓。不要僅僅接受人工智慧給你的程式碼。要批判性地思考,提出問題,挑戰它的方法。我發現我不得不多次反駁Gemini:

  • “你能逐行給我講解一下程式碼並解釋它們的作用嗎?”

  • “建議的查詢似乎太複雜,需要一段時間來處理。我們可以簡化它嗎?”

  • “此腳本只需要查找我自己的存儲庫之外的活動。我們如何確保 API 查詢能夠處理這種排除?”

  • “您建議建立一個全新的庫,但是我們可以使用原生 Node.js 來實現嗎?”

  • “為什麼你採用這種方法而不是那種方法?有什麼區別?有什麼影響?”

有時,AI 會改變方法,同意一個更簡單的解決方案。有時,它會不斷提出一些對我的簡單應用來說過於複雜或不必要的建議。務必保持批判性思維,並且仍然需要用快速的谷歌搜尋來核實事實。

Vibe 編碼就像一個加速器,特別適用於需要快速彌補知識缺口的情況(例如,無需花費數小時閱讀文件即可編寫 GitHub API 查詢)。但最終程式碼的品質——簡潔性、效率和有效性——完全取決於人工審核和批判性挑戰。

輪到你了:開始自動化

如果我的故事引起了您的共鳴——想要追蹤他們的旅程但厭倦了手動工作的貢獻者——我鼓勵您嘗試這種自動化或建立自己的自動化!

{% 嵌入 https://github.com/adiati98/oss-portfolio %}

您最終可以專注於最重要的事情:為開源做出貢獻,而不是管理電子表格。

展望未來,保持批判性思維

雖然目前系統穩定且完全自動化,但這個專案遠未完成。我計劃在未來加入更多功能。持續的開發意味著有一件事是不變的:我必須繼續手動檢查和優化AI幫助產生的程式碼。我將專注於確保邏輯——從Node.js實現到底層資料請求——保持簡單、高效,最重要的是,遵循我建立此作品集所遵循的道德和協作原則。

這個專案證明了一個好想法的力量,即使它誕生於假期的手機上。它表明,借助現代人工智慧工具,你無需成為 API 專家即可建立複雜的解決方案。你只需要好奇心、批判性思考和嘗試新事物的意願。

您正在利用人工智慧建立哪些功能,讓開發者的工作更輕鬆?我很想聽聽您的故事!


原文出處:https://dev.to/adiatiayu/how-i-built-a-curated-automated-open-source-portfolio-18o0


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝22   💬9   ❤️6
604
🥈
我愛JS
📝4   💬14   ❤️7
273
🥉
御魂
💬1  
3
#4
2
#5
1
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付