- 我提到 Hermes Agent 的 LINE adapter PR
- 這次我最在意的不是「我寫了多少程式」，而是過去踩過的 LINE reply token 問題，真的能轉成開源專案裡的工程設計。
- 我平常主要在 Claude Code 裡工作，這次也是一樣：我做領域判斷、架構決策和驗證，Claude Code 把它們整理成可運行的 Python。
- 對我來說，這次經驗比較像是在確認一件事：被 maintainer 採納的，不是 code volume，而是設計品質。
Vibe Coding 也能貢獻開源：用 Claude Code 寫的 LINE adapter 被 Hermes Agent 採用！
上個月我往 NousResearch 的 Hermes Agent 提了一個 LINE adapter 的 PR。Hermes Agent 是個很大的專案，可能可以說是僅次龍蝦（OpenClaw），最多台灣人知道的 Agent 開源專案了吧。
最後我的 PR #18153 沒有直接 merge；但 maintainer 後來把七個社群 LINE PR 合成成另一個正式 merged 的 PR #23197，並且明確標出我的設計是這邊拉進去的幾個設計。
有趣的是，這個 LINE adapter 並不是我一行一行寫出來的。整段過程比較接近大家說的 vibe coding：跟 Claude Code 一起讀文件，我做架構設計、驗證和修正，再讓 Claude Code 把它變成可運行的 Python 程式碼。
LINE 對 Bot 的支援很不友善，每筆推送都是錢
這個故事其實不是從 Hermes 開始，而是從之前一個比較 Local 的案子開始。
去年我幫酒字咖啡的嘎哥做了一個 LINE RAG bot。不做不知道，做下去才發現，LINE 的設計對 bot 真的很不友善。
Reply tokens must be used within one minute after receiving the webhook. Use beyond one minute isn’t guaranteed to work. – LINE Messaging API Docs
可能是為了避免有人用 Line bot 洗訊息（或因為要做成收費產品），LINE 把「回覆」跟「推送」規範的很嚴格，「推送」訊息每個月只有少量免費，其他都要按量收費。雖然「回覆」免費，但必須在一分鐘內送出，只要 RAG 沒找到，需要另外上網搜尋的時候，處理時間就會很容易把這個 token 拖過期。
這裡就碰到一個大問題，如果堅持用免費回覆，那就只能加快速度，間接限制 bot 的能力；但如果直接改成完成後推送，成本又會變得很不友善。後來我發現一個解法：用「快速回覆」按鈕機制讓使用者再觸發一次互動，就能換到一顆新的 token。
後來那個 bot 沒有繼續往前推，但 reply token、慢回應和成本這幾個坑，留在我腦袋裡很久。這也變成我後來看到 Hermes 的設計時，第一個想到可以貢獻的地方。
台灣人不能沒有 LINE，讓我想貢獻 Hermes Agent 的 LINE 支援
前陣子為了要設計給夢酒館用的 Agent，研究了一下 Hermes Agent，發現它還沒有支援 LINE 通道。
因為這次是想要設計給別人用的，我知道大部分台灣使用者的想像是可以直接在 LINE 裡面跟 Agent 對話。如果想把 Agent 帶到日常工作情境裡，LINE 幾乎是一個很難跳過的入口。Hermes 加上 LINE，剛好像是一個更接近日常使用的可能性。
PR 提交才發現已有六個社群在做 LINE adapter
於是我就開始做，然後把我的設計提交出去（PR #18153）。
結果沒多久，下面就有人留言提醒我：已經有另一個 LINE PR 了。
原本想說自己失禮了，一個 Vibe Coder 去跟別人搶提交，馬上把我的提交關掉。然後想說去看看別人是怎麼設計的，結果發現當時已經有六個 LINE PR，重新看完後，大家都在做 LINE support，可是沒有人真的在處理最麻煩的 Reply token 問題。
找到可以貢獻的缺口，用互補而非競爭的心態提交設計
我後來重新設計了一下，專注解決 reply token 問題，讓 LINE 在 Agent 工作流下，盡可能無感地維持免費，想著可以被整合進其他人的程式碼裡面就好了。
最後採用的做法其實不複雜。當 Hermes 的回應時間快要逼近 reply token 的安全邊界時，不要硬等到它失效，而是在安全門檻先把原本那顆 token 用掉，送出一個按鈕和一句「回覆中，請稍後」。
如果使用者之後點那顆按鈕，LINE 就會再送回一個新的事件過去，也就等於給 Hermes 一顆新的 reply token。這時候就可以用那顆新的 token，把排隊完成的答案送回去。對使用者來說，體感就是多點一下「看答案」；對系統來說，卻是在既有規則裡重新換到一次免費回覆的機會。
Hermes 後來在官方文件裡，把這個流程寫成預設的慢回應機制 — 45 秒先送按鈕，留 15 秒緩衝（reply token 視窗大約 60 秒）。
為什麼最後選用 Template Buttons 而不是 Quick Reply
其實第一版用的是之前 RAG 設計的「快速回覆」按鈕，但這有一個問題，如果使用者還在等答案時，又順手傳了一句新的訊息進來，「快速回覆」會直接被新的訊息洗掉。
所以我後來把它改成一個會保留在對話內按鈕（Template Buttons），沒有「快速回覆」那麼輕巧，但不會不小心被新訊息清掉，確保使用者體驗可以更完善。
整段程式碼都是 Claude Code 寫的，那我到底貢獻了什麼？
既然都是用 AI，那我的設計為什麼跟別人不一樣？這就要講到人跟 AI 到底該怎麼分工。
在這次的 PR 裡面，我跟 Claude Code 分別做了「設計、決策」，還有「研究、執行」兩個不同的工作。
我做的：
- 領域知識：以前做過 LINE RAG bot，reply token、慢回應、考慮推送成本這些經驗。
- 架構決策：選 Template Buttons 而不是 Quick Reply、設定 45 秒當作安全閾值。
- 真實驗證：用真實使用者的視角測試每一個按鈕、每一段等待。
Claude Code 做的：閱讀官方文件，確認我的想法跟現行版本相容，並把這些決定翻譯成可運行的程式碼。當方向夠清楚，它把很多原本耗時的機械工作快速做完。
這也是 vibe coding 最容易被美化的地方：它加速的只是「想法 → 程式碼」這一段；但所有前期思考、取捨、驗證，都還是需要人的判斷。
Hermes 把七個社群 LINE PR 合成，從我的 PR 拉了四個設計
過一陣子，Hermes 把七個社群 LINE PR 合成成一個正式版本，從我的 PR 裡拉了四個設計進去 — 其中最核心的，正是前面想解的那個 reply token 問題。
我回去翻合併後的程式碼，發現好幾處註解明確標著我的 PR 編號跟帳號。文件中特別標出我的設計是 the headline novel piece，前面那句「Template Buttons 不像 Quick Reply 會被新訊息洗掉」的觀察，也被備註進去官方文件：
Template Buttons stay tappable from chat history, unlike Quick Reply chips which are dismissed the moment any new message arrives in the chat.
有趣的是 — Teknium（Hermes 的 maintainer）並不知道我是怎麼產出程式碼的。
對他來說，他評估和採納的不是「這個人是不是工程師」而是我提交的設計本身。
被採用的不是程式碼，而是設計品質
這次經驗讓我最想留下來的一句話：
只要架構設計得當，vibe coder 也能貢獻開源程式。
跟別人比起來，我一定寫不出更好的 Python 程式碼，但我有對 LINE 限制的理解、對產品摩擦的敏感、使用成本的判斷、還有真實情境的驗證。
Vibe coding 真正的價值不在「我靠 AI 生出多少程式碼」，而在於清楚的問題意識和靈活的設計判斷。
即使現在人手一個 AI，程式碼產出可以被加速，但架構、設計、驗證，並不會因此自動發生。
所以我不會說「AI 幫我完成了一個 adapter」。比較準確的說法是：我指揮 AI，把一段自己經驗裡的領域知識，放大成一個能被開源專案採用的工程設計。
開源貢獻初體驗，感覺滿好的，迫不及待要找下一個貢獻機會了。
常見問題
這篇是在說 PR 被 merge 了嗎？
#18153 沒有直接 merged；maintainer 後來在合成 PR #23197 時，把我其中幾個設計拉進正式版本，並保留 Co-authored-by 署名。 這篇是在教人怎麼做 LINE bot 嗎？
為什麼會一直提到 vibe coding？
