與猶豫不決的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智能體在決策收斂方面的侷限性。它們可以快速診斷問題並提出多種解決方案，但缺乏一種機制來評估並停止在最佳選項上。霍伊特感慨：“這些機器令人驚歎，但我可不想有如此猶豫不決的朋友。”