與猶豫不決的AI程式設計助手的趣事
作者描述了一個AI程式設計助手（Claude Opus 4.6配合GitHub Copilot）在修復GoAWK程式中的bug時，雖然快速診斷出問題，但隨後在7種不同修復方案之間反覆切換了25次以上，暴露了AI模型在決策時的不確定性。
本·霍伊特（Ben Hoyt）在個人部落格中記錄了一段與AI程式設計助手合作的趣事。他正在使用Opus 4.6（Claude的模型）配合GitHub Copilot外掛，在GoLand IDE中修復GoAWK直譯器的一個非平凡bug。問題源於一個Awk程式：BEGIN { a["x"]=1; for (NR in a) print NR, a[NR] }，預期輸出“x 1”，但實際輸出“0\n0\n”。
AI在幾個段落內就診斷出問題所在，速度甚至快過人類。它指出，特殊變數（如NR）被儲存為原生Go的int型別，導致字串表示丟失。然而，令人哭笑不得的是，AI隨後陷入了漫長的決策掙扎——在短短幾分鐘內，它提出了7種不同的修復選項，並在它們之間反覆切換了至少25次。
這些選項包括：A）保留特殊變數的字串表示；B）將特殊變數儲存為值型別；C）當特殊變數被字串賦值時儲存字串覆蓋；D）專門修復ForIn操作碼；E）在側欄位中儲存原始值；F）僅將lineNum和fileLineNum改為值型別；G）新增特殊值覆蓋對映。AI頻繁使用“實際上……”這樣的轉折詞，前後矛盾達19次之多。
有趣的是，最經常被提及的選項B（出現11次）正是最恰當的修復方案。霍伊特最終在一個拉取請求中實際採用了這個方案。然而，AI在決策過程中似乎無法判斷何時應該停止，甚至開始修改程式碼後又忘記自己已做改動，最終被作者取消。
這一案例生動展示了當前AI智慧體在決策收斂方面的侷限性。它們可以快速診斷問題並提出多種解決方案，但缺乏一種機制來評估並停止在最佳選項上。霍伊特感慨：“這些機器令人驚歎，但我可不想有如此猶豫不決的朋友。”