繼續優化 LLM 輔助編碼體驗的旅程。特別是，我發現與其專注於一個完美的東西，我的使用越來越多樣化，跨越幾個工作流程，我將其 "拼接" 優缺點： 就我個人而言，我的 LLM 輔助的主力（約 75%？）仍然是 (Cursor) 的 tab 補全。這是因為我發現自己在代碼的正確部分編寫具體的代碼/註釋是一種高帶寬的方式來與 LLM 進行 "任務規範" 的溝通，也就是說，主要是關於任務規範的部分——用文本溝通我想要的內容需要太多的位和太多的延遲，而在代碼中以正確的地方展示它更快。有時 tab 補全模型很煩人，所以我經常切換它的開關。 下一層是突出顯示一段具體的代碼並請求某種修改。 再上一層是 Claude Code / Codex / 等等，運行在 Cursor 的旁邊，我會去使用它們來處理一些功能較大的代碼塊，這些代碼塊在提示中也相對容易指定。這些非常有幫助，但總體上仍然是混合的，有時略顯沮喪。我不以 YOLO 模式運行，因為它們可能會偏離軌道，做出你不想要/需要的愚蠢事情，我經常按 ESC。我也還沒有學會如何有效地使用多個實例並行——一個已經感覺夠難的了。我還沒有找到保持 CLAUDE[.]md 良好或最新的好方法。我經常需要進行 "清理" 的過程，以符合編碼風格或代碼品味的問題。例如，它們過於防禦性，常常過度使用 try/catch 語句，常常過於複雜化抽象，代碼過於臃腫（例如，當列表推導或一行的 if-then-else 可以工作時，使用嵌套的 if-else 結構），或者它們重複代碼塊而不是創建一個好的輔助函數，諸如此類……它們基本上沒有品味。在我逐漸進入一個我不太熟悉的 vibe-coding 領域時，它們是不可或缺的（例如，最近寫一些 rust，或者 sql 命令，或者我之前做得較少的任何其他事情）。我還嘗試讓 CC 在編寫代碼的同時教我東西，但這根本沒有效果——它真的更想寫代碼，而不是在過程中解釋任何東西。我嘗試讓 CC 進行超參數調優，這非常有趣。它們在所有種類的低風險一次性自定義可視化或工具或調試代碼中也非常有幫助，我絕對不會自己編寫這些代碼，因為這會花費太長時間。例如，CC 可以快速生成 1,000 行一次性的廣泛可視化/代碼，僅僅是為了識別一個特定的 bug，而在我們找到它後，這些代碼會被全部刪除。這是代碼後稀缺時代——你可以創建然後刪除成千上萬行超級自定義、超級短暫的代碼，現在沒關係，這不再是這種珍貴而昂貴的東西。 最後的防線是 GPT5 Pro，我會去處理最困難的事情。例如，我已經發生過幾次，我 / Cursor / CC 都在一個 bug 上卡了 10 分鐘，但當我將整個內容複製粘貼到 5 Pro 時，它會運行 10 分鐘，但最終確實找到了一个非常微妙的 bug。它非常強大。它可以挖掘各種深奧的文檔和論文等。我還用它處理其他更重要的任務，例如關於如何清理抽象的建議（結果混合，有時有好的想法，但並非全部），或者關於人們如何做這個或那個的整個文獻綜述，它會返回相關的資源/指針。 無論如何，編碼感覺在多種 "類型" 的編碼和許多工具的優缺點之間完全被打開了可能性。很難避免對未能處於集體可能性的前沿感到焦慮，因此隨機的星期天洗澡思考和對他人發現的好奇心。