掌握工具本身（大部分情況下）就夠了
面對層出不窮的AI工具感到不知所措？本文分享一個基於GitHub Copilot的簡單工作流程，通過原型設計、規劃、實施和審查，無需追逐新工具即可大幅提升AI使用效率。要點包括：選擇一個工具、開啓YOLO模式、從原型開始、有條理地規劃、使用Autopilot實施，以及人工審查與迭代。
如果你現在因為AI而感到不知所措，你並不孤單。
每天似乎都有新工具、新MCP、新模型、新技能、新工作流、新功能、新社交帖子，它們都有一個共同點：“看！我用一個奇怪的提示就完全搞定了AI。”
我不信。
我每天都在使用AI，我發現少即是多。真正帶來改變的並不是我安裝、配置或誘導AI做什麼——那些東西很有趣，但最終感覺像是噱頭。
我生產力的最大提升來自於我如何使用工具本身以及我對它的理解程度。
所以在這篇文章中，我將分享一個簡單的工作流程，只需使用GitHub Copilot的現有功能，就能大幅提升你在AI使用上的效率。沒有奇怪的提示，沒有別人都知道而你不知道的技巧，只是工具本身。工具本身就能滿足你——大部分情況下。
- 選擇一個工具
這很明顯，對吧？選一個工具！太容易了！
但即使在GitHub Copilot系列中，也有很多選擇，包括CLI、新的GitHub Copilot應用、VS Code、Visual Studio和JetBrains等。
好消息是這些體驗正逐漸集中在同一套工具上。不同工具的細節可能不同，但核心工作流是一致的。學會工具本身，就能在任何地方使用。
不過，我認為學會工具本身是關鍵，而學習的最佳方式是儘可能接近它。所以如果你剛開始，我建議從GitHub Copilot CLI開始。它是一個終端界面，只有文本，沒有太多UI需要學習。你輸入提示，AI代理執行操作。這種交互更直接、更即時，而且非常令人滿意。
在本演示中，我將使用新的GitHub Copilot應用。但該應用使用的工具與GitHub Copilot CLI、Visual Studio Code等地方使用的完全相同。
- 開啓YOLO模式
YOLO模式也稱為“允許全部”。這允許AI代理執行任何命令而無需請求許可。根據你使用的工具，這可能會有所不同，但大多數情況下只需在聊天中輸入 /allow-all 命令。否則，AI代理每次執行工作都會停下來等待你的批准。
AI代理需要自主性才能提升生產力。如果你必須批准代理做的每一件事，那還不如自己動手。而且，那是一種糟糕的用户體驗，沒有人願意整天坐在辦公桌前按“批准”按鈕。不停地按“批准”只會讓你變得不看內容就批准，這就失去了意義。
不過，使用AI代理時也要注意安全。好人也會遇到壞事。在使用YOLO模式時，你不應在本地機器上運行代理，尤其是在工作中——數據在組織的系統上是私密的，錯誤可能代價高昂。
幸運的是有很多在沙箱中運行代理的選項。一個簡單的入門方法是使用GitHub Codespaces或開發容器。
- 從原型開始
AI最神奇的一點是，你可以輕鬆地提前為任何東西創建原型。歷史上並非如此，原型設計是項目的完整階段，通常是一種奢侈。現在，一個提示就能搞定。
讓我們看幾個例子。
假設我們要構建一個日期選擇器Web組件。這看起來簡單，但實際上相當複雜。想想你可能用它做的所有事情。
如何在組件內導航？
選中日期看起來如何？
選中範圍看起來如何？
用户如何在日、月、年之間切換？
從簡單的原型開始，並嘗試幾種變體。我通常這樣開始：
“給我20個日期選擇器Web組件的模擬圖。把它們都放在一個HTML文件中，以便我比較。”
在這種情況下，AI生成了多種佈局，但其中一種模擬圖從年視圖開始。這很有趣。我希望我的日期選擇器能讓用户先縮放到年，然後到月，最後到日。這些東西在見到之前你通常不會考慮。
作為人類，我們處理圖像、形狀和有形佈局等感官豐富的模型比密集文本更快。早期創建低成本的原型有助於使複雜概念變得直觀。
這也適用於非可視化任務。
例如，如果要添加一個新的API端點，我仍然會先創建一個可視化原型，來理解需求和約束，然後再進行實現。
“為這個項目創建一個API的可視化模型。添加五種處理新API端點的方式，該端點允許用户下載他們的分析數據。”
由於GitHub Copilot應用支持Mermaid圖，代理將其渲染為Markdown，映射出實現該API端點的五種不同方式。
使用AI代理時，容易忘記一切都有細微之處。原型有助於提前發現這些細微之處，避免在返工上浪費寶貴的時間和令牌。
我建議對於大部分工作，使用中等大小的模型，如GPT 5.6 Terra或Claude Sonnet，並設置為中等推理。我還建議在完成特定功能、錯誤修復或增強的整個過程中堅持使用你選擇的模型。提示緩存會為你節省令牌。只要你不切換到不同的模型或推理級別，你之前的對話就會保留在緩存中，從而在未來的請求中獲得折扣。
- 有條理地規劃
現在你知道你真正想要的是什麼，而不是最初想象的樣子，是時候規劃實施了。
在不啓動新會話的情況下，切換到GitHub Copilot的規劃模式。
“/plan 構建一個日期選擇器Web組件。我希望用户能夠縮放到年、月和日。”
這是一個相當模糊的提示，你可能比我擁有更多模型上下文，但這只是演示。如果你沒有更多上下文，也沒關係，這正是這個步驟的目的。
理論上，如果你能用完美的順序和上下文編寫完美的提示，你可以讓模型一次性完成任務。理論上。
但我們沒有人能做到這一點。不過，規劃可以幫助你更接近這個理想，通過提出你在手動構建過程中需要回答的所有問題：
開始日期和結束日期可以相同嗎？
部分選擇是否有效？
用户應該能夠清除日期嗎？
“今天”是否應該始終可見？
允許手動輸入嗎？
日期以什麼格式存儲？
允許粘貼日期嗎？
列表還在繼續。你不可能想到所有這些邊緣情況，但模型可以幫助你識別其中許多。
你可以通過安裝Matt Pocock的“grill-me”技能，使規劃模式在問題和邊緣情況的數量上更加激進。
“/plan /grill-me 構建一個日期選擇器Web組件。我希望用户能夠縮放到年、月和日。”
這個規劃步驟至關重要。重點不是讓你接受AI的每一個建議。如果你這樣做，你就失去了這個規劃過程的價值。重點是讓你深入思考問題，並引導模型。這是你的專業知識發揮作用的地方。
你也可以向模型提問。在下面的截圖中，它問我關於“非連續日期”的問題。我大致知道模型的意思，但我要求澄清以確保我們理解一致。
即使你打斷並提問澄清問題，規劃過程也會繼續。
- 使用Autopilot實施
計劃完成後，GitHub Copilot很可能會提示你切換到Autopilot並開始實施計劃。
Autopilot是一個內置循環。它強制模型繼續工作，確保它確實完成了所説的任務——在這種情況下，完成計劃中的每一項。
GitHub Copilot在此階段會自動充當編排器。如果需要讀取代碼庫中的文件，它會使用小模型的“探索”子代理。如果認為某個操作相對複雜，它很可能會選擇大模型的“通用”子代理。雖然你可以通過自定義代理和指令在GitHub Copilot中獲得對編排的精細控制，但無需做任何特殊操作即可獲得子代理和多模型工作流的好處。這是開箱即用的，即使你並不知道這些功能的存在。
- 人工審查與迭代
這是你獲得多巴胺刺激的時候。你可以看到AI創建了什麼。
但很可能你不會得到完全想要的東西。這是正常和預期的。模型無法讀取你的想法，而且容易出錯。與模型迭代，直到你得到真正想要的東西。無論是代碼還是改進的UI，這部分你的品味將決定最終產品的質量。
例如，這是GitHub Copilot給我的日期選擇器。
我已經看到一些問題：
動畫不一致
懸停在選中日期上時文本不可讀，因為顏色對比度問題
頂部不需要顯示“12年”
當我點擊“今天”時，如果我在月視圖或年視圖，它不會跳轉到日視圖。
此外，我不喜歡這種設計。它看起來太像AI創作的——因為它就是！
所以這裏我們只是進入後續模式。我使用自己創建的CSS框架Postrboard。我將其添加為技能，只指向CSS並告訴代理如何使用。如果你願意，可以自己安裝使用，也可以選擇其他你喜歡的CSS框架。給模型一些設計指導非常有幫助，通常一個CSS框架就足夠了。
“好的——我們不需要登錄頁面，只需要組件、輸出和設置面板，用最小化設置。使用/postboard技能進行設計和顏色。”
對於日期選擇器，當我點擊某天時，它會嘗試放大，但無法放大，因為沒有可放大的內容。那裏不應該有縮放。
頂部不需要顯示“放大”
當我鼠標懸停在包含選中日期的月份或年份上時，懸停文本無法閲讀。
當我點擊“今天”時，它應該跳轉到日視圖，即使我在月視圖或年視圖。
月份下面不需要數字，也不需要放在方框中
年份也一樣。頂部不需要顯示“12年”。
注意這種對話方式。不要過度思考。當你修復一堆這樣的小問題時，直接交給模型。如果你有上下文，你就有提示。
最重要的是，不要滿足於“足夠好”的AI輸出。堅持質量。要毫不留情。那部分仍然是你的責任，知道什麼才是從AI中獲得的高質量結果。
[根據AI成本控制進行了截斷]