像 Gemini 2.5 PRO 這類的 Frontier LLMs(前沿大型語言模型)，憑藉其對眾多主題的廣博理解，以及在幾秒鐘內掌握數千行程式碼的能力，能夠延伸並放大程式設計師的能力。如果你能以清晰的方式描述問題，並且能夠接受與 LLMs 協作所需的來回互動，就能達成諸如以下的驚人成果：

1. 在程式碼觸及任何使用者之前，就先消除你引入的臭蟲：我在 Redis 的 Vector Sets 實作中就體驗到了這一點。最終我本來也會消除所有臭蟲，但許多臭蟲透過 Gemini／Claude 的程式碼審查立刻就被清除了。
2. 更快地探索某個想法是否可行，方法是讓 LLM 撰寫用完即丟的測試程式碼，盡快驗證某個解決方案是否真的效能更好、是否足夠好等等。
3. 進行結對設計活動，將你的直覺、經驗與設計品味，與 LLM 內部蘊含的博士級知識相結合。在這個過程中，LLM 有時會提出愚蠢的路徑，有時則會提出極其出色的點子：你作為人類的存在，就是為了避開局部極小值與錯誤，並善用你的數位夥伴在某些各式各樣的知識上超越任何人類的事實。
4. 在你清晰的規格指示下，讓其撰寫部分程式碼來加速你的工作。
5. 使用 LLMs 作為你心智中特定部分的延伸，來處理那些遠離你專業領域、卻又與你的能力相鄰的技術（例如：為 Amiga demo 撰寫 68000 組合語言？），以補足你所欠缺的知識。

一年半前，我寫了一篇名為「LLMs and programming in the first days of 2024（《2024 年初的 LLMs 與程式設計》）」的部落格文章。在那篇文章中，我就發現 LLMs 已經很有用，但在這一年半裡，它們取得的進展徹底改變了局面。然而，為了發揮它們的能力，與 LLMs 互動的人類必須具備某些特質並遵循某些實踐。讓我們來探討這些要點。

大多數時候請拒絕 vibe coding(氛圍編程)

在這個歷史時刻，LLMs 是優秀的放大器，卻是糟糕的單人樂隊。仍然有一些小型的用完即丟專案，讓 LLM 寫完整份程式碼是合理的，例如測試、小型的數百行程式碼的工具程式。但雖然 LLMs 能在你的嚴格監督下（見後文）成功撰寫部分程式碼庫，並帶來非常可觀的開發加速（或者說，在與過去相同的時間內開發出更多／更好的成果——這正是我的做法），當把它們單獨留下、面對不簡單的目標時，它們往往會產生比實際需求更龐大、複雜、充滿局部最佳解選擇、在多方面都不夠理想的脆弱程式碼庫。而且，當手邊的任務複雜度超過某個水準時，它們就直接徹底失敗。明天這一切或許都會改變，但就目前而言，在每天與 LLMs 一起寫程式的經驗之後，我堅信最高的工作品質是透過「人類＋LLM」這個方程式來達成的。我相信人類與 LLMs 一起比單靠人類更有生產力，但這需要一個很大的「如果」，也就是：如果這樣的人類具備強大的溝通能力與豐富的 LLMs 使用經驗：能否有效溝通，是使用 LLMs 的關鍵因素。

提供充足的上下文

當你的目標是與 LLM 一起推敲如何實作或修復某些程式碼時，你需要向 LLM 提供大量的資訊：論文、目標程式碼庫的很大一部分（如果可能的話，整個程式碼庫，除非這會讓 context window(上下文視窗) 大到損害 LLM 的效能）。以及你對該做什麼的所有理解的腦內傾倒（brain dump）。這樣的腦內傾倒尤其必須包含以下內容：

• 關於那些看起來不錯但實際上不好的解法的提示，以及它們為何可能不是最佳選擇的原因。
• 關於非常好的潛在解法的提示，即使人類尚未完全闡述清楚：LLMs 經常能利用這些提示找到正確的路徑。
• 清楚說明該做什麼的目標、我們要求的不變量，甚至程式碼應有的風格。例如，LLMs 傾向於寫出充滿不必要相依套件的 Python 程式碼，但透過提示或許能減輕這個問題。就我的經驗而言，C 語言的程式碼往往好得多。

在處理那些不太普及／不太顯而易見的特定技術時，通常也把文件加入 context window 是個好主意。例如在為 vector sets（一種新到 LLMs 還不知道的 Redis 資料型別）撰寫測試時，我會在上下文中加入 README 檔案：靠這樣一個簡單的技巧，LLM 就能立刻以專家等級來使用 vector sets。

使用正確的 LLMs

最有名的 LLMs 並非最好的。程式設計工作主要應該使用：

• Gemini 2.5 PRO
• Claude Opus 4

就我的經驗而言，Gemini 2.5 PRO 在語意上更強大。能發現更複雜的臭蟲，對更複雜的問題進行推理。Claude Opus 有時（有時則不然）在撰寫新程式碼方面可能更出色，使用者介面也更討喜，而且一般來說，對於複雜問題你至少需要兩種 LLMs 來回對照，以擴展你（人類）對設計空間的理解。如果只能選一個，就選 Gemini 2.5 PRO。

對於要使用的 LLM，最根本的要求是：不要使用 agents(代理) 或像是內建整合式 coding agents 的編輯器之類的東西。你會希望：

• 永遠把東西呈現給最強大的模型，也就是 frontier LLM 本身。
• 避免任何只會向 LLM 展示部分程式碼／上下文的 RAG(檢索增強生成)。這會摧毀 LLMs 的效能。你必須掌控 LLM 在回覆時能看到什麼。
• 永遠讓自己留在迴圈中，親手將程式碼從你的終端機搬到 LLM 的網頁介面：這能確保你跟上每一個過程。你依然是撰寫程式的人，只是獲得了增強。

結論

儘管大家對能獨自寫程式的 agents 有著濃厚的興趣，但就目前而言，你若以明確的方式使用 LLMs、並留在迴圈中，就能將你作為軟體開發者的影響力最大化。未來這一點無可避免地會改變，隨著 AI 的進步，最終許多程式設計任務將更適合完全由 AI 來處理：在那樣的未來，人類將決定「做什麼」與「怎麼做」，這仍然至關重要。但我們還沒到那裡。在當下這個時刻，掌握主導權才能讓你運用 LLMs 產出最精煉的程式碼：需要精簡時就精簡，需要複雜概念時就運用複雜概念。

你將能夠做到那些原本位於你知識／專業邊界的事，同時在過程中學到很多（是的，你可以向 LLMs 學習，就像你可以向書籍或同事學習一樣：這是可能的教育形式之一，一種新的形式）。然而，所產出的一切仍將遵循你對程式碼與產品的理念，保持高品質，不會因為 LLM 引入的錯誤與缺陷而隨機失敗。你也將對所有撰寫的程式碼及其設計保持深刻的理解。

不時測試一下 agents 能做什麼是明智的。但每當你覺得它們做得不如你好時，就回到你的終端機，在 AI 的協助下寫程式（當你覺得它能提升你的產出時；有些時候你獨自一人反而做得更好）。當 agents 能夠展現出卓越成果的那一天到來時，我會是第一個轉向的人，而我仍會為了熱情而獨自寫程式。但就目前而言，讓我們跳過炒作，以最好的方式使用 AI，也就是：保持掌控。然而，還有另一種風險：出於某種意識形態或心理上的抗拒而迴避 LLMs，累積劣勢（並且未能培養出一大套——難以言喻——與 LLMs 協作所需的技能）。或許這真的就是所謂的「In medio stat virtus」（美德在於中庸）。