Slack裡報bug，GitHub上出修復
在Slack裡用大白話說清一個bug。Okou會寫好GitHub issue並指派負責人；如果原因集中在某一個元件上，它還會提一個帶修復和迴歸測試的pull request，交給你審閱。
Okou交付的成果：從一條Slack訊息到一份待評審的修復
這是Okou團隊#bug-report頻道里的真實會話，按發生順序原樣記錄。一位同事貼上客戶的反饋，順口要了個修復。4分鐘後，Okou提交了帶診斷結論的GitHub issue。從第一條訊息算起14分鐘，它開好了PR併發出預覽連結。下面是兩張截圖：起點的那條會話，以及Okou寫的PR。它們都是公開的，你可以自己去看issue、程式碼差異和評審記錄。
會話裡發生了什麼
一位同事在#bug-report裡反饋了客戶遇到的PWA佈局問題，並附上截圖。Okou讀完會話，定位到頂欄渲染時沒有計入iOS安全區域內邊距，隨後提交了issue #11708，帶上標籤和判斷依據。會話裡提出要修復後，Okou只改了一個檔案（給移動端頂欄加上最小高度和安全區域內邊距），開出PR #11709並附上預覽連結，然後就停在這裡。評審和合並由人完成。
- 從訊息到建單
- 4分鐘issue #11708，標籤為bug和PWA
- 從訊息到PR
- 14分鐘PR #11709，附預覽連結
- 修復改動的檔案數
- 1由人合併，不是Okou
在Slack裡建立GitHub issue，到底是怎麼回事？
在Slack裡建立GitHub issue，意思是把有人在對話中描述的bug，直接變成倉庫裡一條結構清晰的issue，而不用任何人退出會話去重新敲一遍。難的從來不是呼叫API，而是寫出一個說得清的標題、把復現步驟和預期行為分開、選標籤、定優先順序、找到對的負責人。這些事由Okou來做：它讀你的Slack訊息和前後的回覆，寫出issue正文，打上標籤、給出講得通的優先順序，把Slack暱稱對應到GitHub帳號來確定負責人，最後把issue連結發回同一條會話，報告人掃一眼就能核對。
為什麼bug反饋總是死在Slack會話裡
有人在演示時發現了一個bug，或者客戶週六來信反饋。老路子很長：開啟GitHub，找到倉庫，按格式寫一條issue，指派給人，然後等這個人接手、讀程式碼、寫修復。一個十分鐘的改動，變成三個人、好幾天的來回，而且有一半的反饋根本沒走出那條會話。換個做法：你在Slack裡把問題說清楚。Okou建好issue，附上覆現步驟、標籤和負責人；如果原因範圍有限，它會接著提一個帶修復和測試的pull request。你審閱，然後發布。
Okou如何從Slack建立GitHub issue
第一步：連線你的工具
第二步：交給Okou
第三步：再往前一步
這套工作流背後的Slack與GitHub整合
這是一套中間放了智能體的Slack與GitHub整合：Okou在Slack裡讀對話，在GitHub裡寫記錄。每個連接器都單獨授權，權限範圍只覆蓋這套工作流真正用到的部分，所以讀取一個頻道，絕不等於拿到你倉庫的寫權限。
Slack整合：Okou讀的那段對話
必需Okou會讀你指給它的那條訊息，以及前後的回覆，所以晚三條才補上的資訊同樣會進到issue裡。它會帶上隨訊息附來的截圖，讀取報告人的暱稱來確定負責人，並保留訊息永久連結，讓每條issue都能回到反饋的起點。它只寫一件事：在同一條會話裡回覆issue編號和連結。Okou不會發到別的頻道、不會發私信，也不會改動任何人的訊息。
GitHub整合：Okou提交的那條issue
必需Okou在你指定的倉庫裡建立issue：標題是根據反饋重新寫過的，而不是照抄原訊息；正文包含描述、復現步驟和預期行為，會話裡提到受影響範圍時也會寫上。它會用你指定的標籤，或根據措辭推斷標籤，給出並解釋優先順序，再指派負責人。提交之前，它會先在未關閉的issue裡搜同樣的現象，找到匹配就改為在原issue下評論。當它還能順手修掉這個bug時，會推一個分支，開一條關聯關閉該issue並請求評審的PR。寫權限只限於你授權的倉庫，範圍也僅此而已：issue、評論，以及提交評審的PR。Okou不會合並、不會強制推送，也不會碰倉庫設定。
Okou、Slack裡的GitHub應用、自動化搭建工具，三者的差別
把一個bug從Slack訊息搬進GitHub，其實有三步：接住反饋、寫出一條能用的issue、把它送到負責人手上。現有方案各自只解決其中一步。
Slack裡的GitHub應用
輸入/github會彈出一個表單，標題、正文、標籤、負責人還是你自己填。它省下了切到瀏覽器的功夫，但寫issue的人依然是你；而對話進行到一半冒出來的表單，正是讓人說出「我待會兒再提」的那點阻力。
自動化搭建工具
無程式碼工具可以在觸發器命中時，把一條Slack訊息複製成一條新issue。它複製的是原始訊息，所以報告人當時怎麼打字，issue就長成什麼樣；而標籤、優先順序、指派和查重的規則，要你自己逐個頻道定義並長期維護。
Okou的Slack到GitHub工作流
Okou讀完會話再動手寫issue：一個像樣的標題，復現步驟與預期行為分開，標籤和講得通的優先順序，以及根據報告人暱稱匹配到的負責人。當原因收斂在單個元件裡時，它會繼續往下做，開出帶修復和迴歸測試的PR，關聯到issue，等你評審。提交前它會先查未關閉的issue，遇到重複就改成在原issue下評論，然後在會話裡回覆連結。
讓效果更好的幾個建議
常見問題
怎麼從一條Slack訊息建立GitHub issue？
把Slack和GitHub連到Okou，然後在頻道里描述這個bug並Okou。它會讀這條訊息和周圍的回覆，寫出帶標題、復現步驟、預期行為、標籤和優先順序的issue，在你指定的倉庫裡建立，指派負責人，再在會話裡回覆issue編號和連結。你不用填任何表單。
這和Slack裡的GitHub應用有什麼區別？
GitHub應用給你的是一個待填的表單：標題、正文、標籤、負責人還是你寫。Okou直接從對話裡寫出這些內容，提交前會查有沒有相同現象的issue，而且可以按計劃掃描整個頻道，而不是一次只處理一條訊息。
Okou只是建單，還是能把bug直接修掉？
兩者都可以，而且它會告訴你這次做了哪一種、為什麼。issue一定會提交。當會話或程式碼都指向同一個元件、預期行為沒有歧義、並且能先寫出一個會失敗的測試時，它還會開出帶修復和該測試的PR，關聯到issue並請求評審。涉及公共工具函式、設計token，或者需要產品決策的，它只建單不改動。Okou從不合並；每一個修復都以PR的形式交到你手上評審。
Okou能自動把issue指派給對的人嗎？
可以。Okou會拿你提到的名字，或報告人的Slack暱稱，去匹配倉庫裡的GitHub帳號，然後指派。在訊息裡直接寫出負責人是最穩的方式；沒人被點名時，Okou會指派給會話所指向那塊區域的負責人，並在issue裡說明它是怎麼判斷的。
Okou怎麼避擴音交重複的GitHub issue？
動手之前，Okou會按相同的現象、受影響範圍和措辭搜尋未關閉的issue。找到匹配時，它會把這條新的Slack會話連同報告人和時間點作為評論追加到原issue上，並在Slack裡回覆已有issue的連結，而不是再開一條。
如果bug反饋裡沒寫復現步驟，會怎麼樣？
Okou照樣提交issue，避免這條反饋丟失，同時打上需要補復現步驟的標籤，並在Slack會話裡向報告人追問。補充上來的答案，就落在那條已經和issue互相關聯的會話裡。
Okou能定時掃描整個頻道來建單嗎？
可以。把一個或多個頻道指給Okou，再給它一個時間安排，比如每週五下午4點。它會讀這一週的訊息，為每條描述缺陷的訊息提交issue，在重複的issue下評論，跳過功能需求和提問，最後彙報它做了什麼。
不用GitHub，換成Linear或Jira可以嗎？
只要是Okou連上的跟蹤工具，工作流的形態都一樣；本頁講的是GitHub這條路徑，用的是GitHub連接器。Linear的連線方式相同，你在指令裡點名要用哪個工具就行。
下一個bug，不用離開Slack就能建單
連上Slack和GitHub，像跟同事說話那樣把bug講清楚，寫issue和指派交給Okou。原因收斂的時候，PR也會一併等著你。
