我們犯了一個可怕的錯誤
作者利用AI輔助構建了一個基於Go的激進緩存層以節省成本，但在探索性測試中發現了一個根本性的設計缺陷——緩存IP前綴對於VPN出口點過於粗糙。儘管經過多輪代碼審查和測試，所有AI模型都未能發現該問題，直到作者提示“我們犯了一個可怕的錯誤”時，Claude才立即識別出問題。這反映了AI在“構建模式”下缺乏對問題本身正確性的審視，同時強調了人類在定義問題上的不可替代性。
過去幾天，我一直在實現一個自認為天才的省錢方案：為某個需要付費的服務構建一個基於Go的激進緩存層。從淋浴時的靈光一現，到與AI代理詳細規劃，再到快速搭建和多次代碼審查加固，整個過程看似完美。邊緣案例逐一發現並修復，經過我和AI代理的迴歸測試，一切似乎無懈可擊。我甚至為此沾沾自喜，覺得這是一個高效的勝利。
然而，在進行探索性測試時，我突然感到一陣熟悉的寒意——我意識到整個方案存在一個根本性的設計問題。這個疏忽微妙但致命：我緩存的是IP信息的前綴級別，而我所關心的某些類別，比如VPN出口點，需要每IP級別的精度。前綴級別的緩存對於“託管IP”尚可接受，但對於“VPN出口點”往往過於粗糙，因為VPN出口的IP地址通常是獨立的，不能通過前綴來概括。
當我開始將這個發現輸入Claude時，只打了“我們犯了一個可怕的錯誤”就意外按下了回車。但Claude立刻準確識別出了那個錯誤，甚至無需我説明具體問題——儘管此前我們經過多輪聲明代碼庫已基本完美，並獲得了Codex和Grok的額外認可。Claude的反應如此迅速，讓我震驚不已。
這讓我不禁質疑：如果這個錯誤如此明顯和根本，為什麼在設計規劃的多個階段從未被發現？為什麼其他兩個LLM——我們在設計階段多次徵求它們的意見——也毫無察覺？Claude的觀點，我深以為然，是我們從一開始就專注於一個聰明的解決方案，從未真正退一步審視更廣泛的問題。我們過於沉迷於構建，實現本身無可挑剔，但根本設計缺陷被忽視了。所有模型都處於“好好構建”模式，而非“我們是否在解決正確的問題”模式。一旦我們切換到“我們搞砸了哪裏”的思維，Claude就能毫不費力地找出問題。
如果是一個人類，能否發現這個錯誤？我最終發現了，所以更好的問題是“另一個人類能否在代碼提交前發現”？不涉及其他人的一個好處是，沒有浪費太多時間：一個本來需要至少一週的服務，在一個工作日內就完成了（儘管存在上述問題）。現在我正逐一檢查最近所有代碼庫，聲稱“犯了一個可怕的錯誤”，看看Claude是否能找到一個……
這個故事揭示了AI在協作開發中的一個重要盲點：它們擅長優化實現，卻難以質疑問題的根本前提。這提醒我們，無論AI多麼強大，人類始終需要保持對問題定義的主導權。在設計任何系統時，我們都需要不時退後一步，問自己：“我們是否在解決正確的問題？”否則，我們可能會構建一個精緻的錯誤。