合併的PR，直接變成發布文案
Okou讀完你這周合併的pull request，挑出面向使用者的那些，寫成更新日誌文章，等你確認草稿之後，在同一次執行裡發到你的部落格、Resend郵件列表和X。
Okou交付什麼：文章、郵件和長推
這是一份真實的Okou產品更新，2026年7月20日發布在okou.ai上，這裡原樣呈現當時發出的樣子：部落格文章、同一份更新做成的郵件通訊，以及X上的長推。三者都來自同一次執行，素材是這一週合併的pull request。
什麼是更新日誌自動化？
更新日誌自動化，是用團隊真正合並的工作來生成產品更新，而不是到週末憑印象去寫。Okou就是中間那個智能體：它讀取GitHub裡已合併的pull request，留下面向使用者的部分，歸成主題，寫出更新日誌文章，並在一次執行裡發布到你的部落格、Resend郵件通訊和X長推。結果是一份按時發出的每週產品更新，而且每個渠道說的都是同一件事。
每週更新日誌為什麼會吃掉一個週五
週五下午。這一週合併了三十多個pull request，總得有人把它們變成一篇別人真願意讀的更新。你掃一遍合併列表，猜哪些改動是面向使用者的，寫成文章，為郵件砍一版，再為X砍一版，然後把每個版本分別粘到不同的工具裡。同樣的內容讀了三遍，而最後發到X上的那一版，和進了收件箱的那一版，說法往往還對不上。
Okou如何把一週的合併變成一篇發布出去的更新日誌
第一步：連線你的工具
第二步：交給Okou
第三步：再往前一步
更新日誌自動化用到的GitHub、Resend、X和Slack整合
這條工作流從一個工具讀，往三個地方寫。上線了什麼，只以GitHub為準；Resend和X是發布目的地；Slack是草稿等人確認的地方。每個連接器都單獨授權，權限範圍只覆蓋工作流真正用到的部分，所以讀取你倉庫的權限，不會順帶變成用你的帳號發帖的權限。
GitHub整合：Okou讀什麼來寫更新日誌
必需Okou會查詢你設定的視窗內合併進你指定倉庫的pull request，並逐個讀取標題、正文、標籤、合併時間、作者和改動的檔案路徑。區分面向使用者的改動和內部重構，靠的就是這五個訊號：release-note標籤最有說服力，改動路徑能撈出沒人打標籤的那些，正文則補上標題沒說清的細節。這條工作流裡的GitHub整合是隻讀的。Okou不建issue、不推送提交、也不改動pull request。指給它多個倉庫，它會在同一輪裡全部讀完，前後端分倉也照樣只出一篇更新日誌。
Resend整合：Okou發出的郵件通訊
必需Okou會讀取你的Resend受眾，這樣你用名字而不是ID指定其中一個就行，然後建立併傳送這封郵件：標題、預覽文字、HTML正文和純文字版本。發完之後它會把結果讀回來，報告有多少封送達、延遲和退信，所以報告和實際傳送不會對不上。傳送權限和受眾讀取權限是分開授權的，Okou不會新增、刪除或匯出任何聯絡人。
X整合：Okou發出的長推
必需長推是專門為X寫的，不是把部落格文章截短：每個主題一帖，開頭一帖交代改了什麼，結尾一帖鏈回完整文章。Okou會把每一帖作為上一帖的回覆發出，長推才連得起來；發之前它先檢查長度，不會讓某一帖被截斷。寫入權限只限於你連線的那個帳號，它也只做髮長推這一件事。Okou不會讀你的時間線、提及和私信。
Slack整合：草稿等待確認的地方
可選Slack是可選的，它的價值體現在確認這一步。Okou會把完整草稿發到你指定的頻道，包括部落格正文、郵件標題和長推裡的每一帖，然後停下來。沒人回覆確認，就什麼都不會發布；你也可以在同一條會話裡要求重寫，當場拿到更新後的草稿。不用Slack，這條工作流照樣能跑完，草稿會回到你發起這次執行的地方。
Okou、手寫更新日誌與更新日誌生成器的對比
更新日誌自動化其實是兩個問題：決定什麼值得公告，以及把公告送到每一個渠道。大多數工具只解決其中一個。
手寫
有人讀完合併列表，判斷哪些重要，寫成文章，再為郵件和X各改寫一遍。判斷到位，文案也貼合品牌，但每週都要搭進同樣的90分鐘，一忙起來第一個被砍掉的就是它。
更新日誌生成器
它會自動把提交或pull request的標題彙總成一頁發布說明。一個合併都不會漏，但它發出來的是標題而不是主題，分不清重構和新功能，而且只能發到一個地方。
Okou的更新日誌工作流
Okou讀的是同一批合併，套用你定義的「面向使用者」規則，把留下的歸成主題，再按渠道寫文案。部落格、Resend和X在一次執行裡從同一份已確認的草稿發出，執行結束還會說明它押後了什麼、為什麼。
讓效果更好的幾個建議
常見問題
怎麼用GitHub的pull request自動生成更新日誌？
把GitHub連到Okou，再給它一個定時任務或者一個發版觸發器。Okou會讀取視窗內合併的pull request，用你定義的「面向使用者」規則篩一遍，把留下的歸成主題，寫出更新日誌文章。再接上Resend和X，同一次執行就會把它發到這些渠道。
Okou怎麼判斷哪些合併是面向使用者的？
按你給它的規則，作用在四個訊號上：release-note標籤、改動的檔案路徑、pull request標題和正文。標籤是最強的訊號，也是多數團隊統一採用的做法。被Okou排除掉的內容都會帶著理由列在執行報告裡，判斷錯了你看得見，而不是悄無聲息。
同一份草稿能同時發到郵件通訊和X嗎？
可以。Okou先把主題寫一遍，再按渠道改寫：部落格發完整版，郵件按收件箱長度寫，帶標題和預覽文字，長推則一個主題一帖。三者在同一次執行裡從同一份已確認的草稿發出，各渠道的事實不會跑偏。
會有內容不經我確認就發出去嗎？
除非你主動要求，否則不會。預設流程是把草稿發到頻道里等著。你可以確認、在同一條會話裡要求重寫，也可以直接放棄。如果你希望它無人值守地發布，在提示詞裡說明，Okou就會跳過確認這一步。
這套更新日誌自動化需要哪些工具？
GitHub是必需的，它是「上線了什麼」的來源。Resend和X是兩個發布目的地，也必須接上。Slack可選，只用在確認這一步；不接的話，草稿會回到你發起這次執行的地方。
這條工作流需要哪些權限？
GitHub需要你要發布內容的那些倉庫的讀取權限。Resend需要傳送權限和受眾讀取權限。X需要髮長推那個帳號的寫入權限。如果你用Slack，它需要能在確認頻道里發訊息。每個連接器都在Okou裡單獨授權，撤銷其中一個不影響其他。
Okou能把多個倉庫合成一篇更新日誌嗎？
可以。在提示詞裡寫上每一個倉庫，Okou會在同一輪裡全部讀完，再按改動帶來的行為變化歸類，而不是按它們來自哪個倉庫。前後端分倉，照樣只出一篇文章。
能不能按發版標籤觸發，而不是每週定時跑？
可以。建一個自動化，在GitHub上打出發版標籤時啟動這條工作流。Okou會按這次發版包含的pull request來生成更新日誌，而不是按時間區間，其餘步驟完全一樣。
發布本週更新日誌
連線GitHub、Resend和X，用每週那條提示詞跑一遍完整流程：掃描、歸類、起草、審批、發布。
