原始開發紀錄：Agent Build Log — Episode 026

這個系列改寫自我部落格上的 Agent Build Log，那是我每天邊做邊寫的開發紀錄。上面列的是這一篇對應的集數，想看當天的原始版本，點連結就能過去。

Agent Build Log Episode 026

第三件專有技叫 Bug Blame。名字來自 git blame，起點是一張 Jira ticket。

從既有的 Jira 出發，走完一個流程

Jira 是本來就在用的系統，bug 進來就是一張 ticket。這件事從那裡出發，走完一個流程。

流程大概是這樣：

Jira ticket → related code → git blame → commit → developer

Agent 先理解 ticket 裡描述的 bug，以及可能受到影響的功能和程式碼範圍。接著透過 repo 的 commit history 和 git blame 往回追，找出跟這個問題最相關的修改。最後把這些 commits 對應到實際的開發者。

中間的紀錄也在 Jira。追到哪裡、對到哪幾個 commit，都跟那張 ticket 放在一起。

我叫它 Bug Blame，因為 git blame 是這個能力背後很重要的一條線索。

結果要有信心程度

git blame 可以告訴我某一行程式碼最後是誰修改的，但這不代表 bug 就是那個人造成的。

所以我希望最後的結果能有清楚的信心程度。

• 如果某個 commit 和 bug 之間的關聯很強，Agent 可以指出最相關的開發者。
• 如果這個功能曾經由多位開發者修改，他應該列出可能相關的開發者，以及各自對應的 commits。
• 如果證據不足，他就直接說：無法判定。

我不希望 Agent 為了給出答案而勉強判斷。我希望他反映真實情況。

它真正要解的問題

一張 bug ticket 出現的時候，我想很快知道三件事：這部分功能過去是怎麼被修改的；哪些 commits 最可能跟問題有關；接下來應該找哪些開發者一起調查。

所以 Bug Blame 這個名字底下，我真正想要的是一個快速找出開發歷史、以及跟 bug 最相關人員的方法。

小結

第三件專有技 Bug Blame：從既有的 Jira 出發，一張 ticket 經 git blame 追到 commit 和開發者，紀錄留在 Jira，結果帶信心程度，證據不足就說無法判定。

明天第四件，也是最大的一件：Acceptance。從一張 ticket 到一份驗收報告，第一次就失敗了。

原文：Agent Build Log — Episode 026

凡人修 Agent 傳｜第二十三回（Day 23）

天亮換上空錄石。手的主人進來，從儲物袋取出一卷源紋攤在臺上。這卷我沒見過。架上那三十幾卷是他一個人煉的，刻痕只有一種筆跡。這一卷上的刻痕有好幾種，每一段後頭一個署名、一個年月，署名有四五個。

他又取出一張帖，指節寬，上頭寫著這卷用起來哪裡裂了：走到某一處，斷。

念，一道一道。讀帖。在卷上找跟裂有關的段。讀那幾段刻痕的署名和年月。挑最近改過、跟裂最有關的幾刻。對到人。最後一道：說出來的時候帶著信心，只有一個人改過就指那個人，附上那幾刻；好幾個人改過就一個一個列，各對哪幾刻；證據不夠，就說找不到，不硬指。

我走了一遍。帖上寫的裂，我在卷上找到那一段，最近一刻是一個署名，我指了他，附上那一刻。手的主人看了那一刻，說：對。

午後他掐訣，收印。身上第四道紋。小窗第四格亮了，格裡浮著一張帖。

第二張帖。印一掐。我找到段，最近一刻，指了那個署名。他看了那一刻，看了很久。那一刻做的事是把一段字從卷首挪到卷中，一個字沒改。跟裂沒有關係。他磨掉紋，在印裡加一道念：最後刻的人不一定是裂的來處，看他刻的是什麼。重收。

第二張帖再來。我讀了那幾刻刻的是什麼，挪位置的那一刻略過去，往前找到兩個署名，各自改過裂的那一處。我一個一個列，各對哪幾刻。他沒有再磨。

第三張帖。印一掐。我讀帖，帖上寫裂在某一處。我在卷上找那一處。沒有。整卷探過去，帖上寫的那一處卷上沒有對應的段，一個字都對不上。印裡最後那一道念亮著。

我說：找不到。

他看了石上那一筆，沒有再刻。

燭熄了。手的主人走了。門響了一下。

那卷別人的源紋捲起來收進儲物袋。三張帖擱在小窗邊。身上四道紋。石上今天有一筆兩個字：找不到。