一個實用的 GitHub Copilot 工作流程，用於原型設計、規劃、實作與審查軟體——無需追逐每個新 AI 工具。
如果你現在對 AI 感到不知所措，你並不孤單。
每天似乎都有新的工具、新的 MCP、新的模型、新的技能、新的工作流程、新的功能、新的社群貼文，無一不是某種「嘿，你看！我已經用這個神奇提示完全搞懂 AI 了」的姿態。
我……不相信你。
我每天都在使用 AI，而我發現的是，少即是多。真正帶來改變的，不是安裝了什麼、配置了什麼，或是用什麼詭計騙 Agent 去做什麼。那些東西也許有趣，但到頭來感覺就像噱頭。
我最大的生產力提升來自於我如何使用這個 harness，以及我對它的理解有多深。
所以在這篇文章中，我將分享一個簡單的工作流程，你只需利用 GitHub Copilot 的現有功能，就能大幅提升使用 AI 的效率。不需要奇怪提示，不需要別人好像都知道的秘技。只需要 harness。Harness 就是你需要的一切——大部分時候啦。
免責聲明
我這裡用「harness」這個詞來指代「GitHub Copilot」。這篇文章的重點是保持簡單，所以只要知道 GitHub Copilot 是一個 Agent harness 就好。
我並不是說你永遠不需要任何技能、MCP、指令、自訂 Agent 等等。事實上，隨著你進步，需要為團隊定義複雜的工作流程並自動化事情時，這些東西會變得非常重要。事實上，我在這篇部落格文章中就用到了幾個！
我要指出的是，你並不需要那些東西就能在 AI 上取得巨大成功。
另外，現在外面有很多垃圾內容。如果你不相信，就叫 Agent 建立一個技能，做任何事都行。它會很樂意照辦。但那個生成的技能是否真的有效，卻可以輕易被發佈到任何技能或 MCP 註冊中心。
1. 選一個工具，隨便哪個
這很明顯，對吧？選一個工具！太簡單了！
但即使在 GitHub Copilot 家族中，也有很多選擇。包括 CLI、新的 GitHub Copilot 應用程式、VS Code、Visual Studio、JetBrains，等等，不勝枚舉。
好消息是，這些體驗正越來越集中於同一個 harness。不同工具的細節可能不同，但核心工作流程是一致的。學會 harness 一次，到處都能用。
話雖如此，我確實認為學會 harness 是關鍵，而學會它的最好方法就是盡可能靠近它。所以如果你剛起步，我建議從 GitHub Copilot CLI 開始。它是終端機介面，意味著純文字。沒有太多 UI 要學。你輸入提示，Agent 做事情。但互動更直接、更即時，而且老實說，非常令人滿足。
為了這個示範，我將使用新的 GitHub Copilot 應用程式。但該應用程式使用的 harness 與你在 GitHub Copilot CLI、Visual Studio Code 以及其他許多能找到 GitHub Copilot 的地方所使用的完全相同。
2. 開啟 YOLO 模式
YOLO 模式也稱為「Allow All」。這讓 Agent 可以執行任何指令而無需請求許可。這可能因你使用的工具而異，但對大多數工具來說，就是在聊天中輸入 /allow-all 指令。否則，Agent 每次需要做某些工作時都會停下來等你批准。
Agent 需要自主權，這樣你才能看到生產力的提升。如果你必須批准 Agent 做的每一件事，那還不如自己動手做。而且，那是一種糟糕的使用者體驗。沒有人想整天坐在辦公桌前按「核准」按鈕。而且一直按「核准」只會讓你習慣不去閱讀你被要求核准的內容，這就失去了意義。
不過，你還是要安全地使用 Agent。壞事會發生在好人身上。使用 YOLO 模式時，你不應該在本地機器上執行 Agent。尤其是在工作時使用 Agent 更是如此——資料在你組織的系統上是私密的，錯誤可能代價高昂。
幸運的是，有許多選項可以在沙盒中執行 Agent。一個簡單的入門方式是使用 GitHub Codespaces 或開發容器。
3. 從原型開始
AI 最神奇的事情之一，就是你可以輕鬆地預先為任何東西建立原型。過去可不是這樣。原型設計曾是專案的一個完整階段，而且常常是一種奢侈。現在，你一個提示就能做出來。
讓我們看幾個例子。
假設我們想建立一個日期選擇器網頁元件。這看起來很簡單，但實際上相當複雜。想想你可能想用它做的所有不同事情。
- 如何在元件內導航？
- 選中的日期長什麼樣？
- 選中的範圍長什麼樣？
- 使用者如何在日、月、年之間切換？
從一個簡單的原型開始，並取得幾個變化。我通常會從這樣的東西開始：
給我 20 個日期選擇器網頁元件的模擬圖。把它們全部放在一個 HTML 檔案中，這樣我就可以比較。
閱讀圖片描述
ALT
二十個日期選擇器原型，生成在單一 HTML 檔案中。
在這種情況下，AI 生成了許多不同的佈局，但其中一個模擬是從年份視圖開始的。這很有趣。我希望我的日期選擇器讓使用者能夠縮小到年份，然後到月份，最後到日期。這些是你看到之前不會考慮到的事情。
作為人類，我們處理圖像、形狀和具體佈局等感官豐富的模型，比處理密集的文字要快得多。早期建立低成本的原型有助於讓複雜的概念立即變得直觀。
這也適用於非視覺任務。
例如，如果我想添加一個新的 API 端點，我還是會先建立一個視覺原型來了解需求和限制，然後再深入實作。
為這個專案建立一個 API 的視覺模擬圖。為我們可以如何處理一個允許使用者下載分析資料的新 API 端點，添加五個選項。
閱讀圖片描述
ALT
一個比較分析匯出 API 端點不同方法的 Mermaid 圖表。
由於 GitHub Copilot 應用程式支援 Mermaid 圖表，Agent 會將其渲染為 Markdown，描繪出五種不同的實作方式。
與 Agent 一起工作時，很容易忘記所有事情都有細微差別。原型設計有助於提前發現這些細微差別，這樣你就不會把寶貴的時間和 token 浪費在重做上。
我建議對於大多數工作，使用中等規模的模型，例如 GPT 5.6 Terra 或 Claude Sonnet，並設定中等推理強度。我也建議你在這個特定功能、錯誤或增強功能的持續期間，堅持使用你選擇的模型。提示快取可以節省你的 token。只要你不切換到不同的模型或推理強度，你之前的聊天記錄就會保留在模型的快取中，從而為你將來的請求提供折扣。
4. 有條理地規劃
現在你知道了你真正想要的東西，而不是你最初以為你想要的東西，是時候規劃實作了。
在 GitHub Copilot 中切換到規劃模式，而不開始新的對話。
/plan 建立一個日期選擇器網頁元件。我希望使用者能夠在年、月、日之間縮放。
這是一個相當模糊的提示，你可能比我這裡有更多的上下文給模型，但這只是一個示範。如果你沒有更多上下文，也沒關係。這正是這個步驟的用途。
理論上，如果你能用完美的順序組合成完美的提示和完美的上下文，你可以讓模型一次完成任何事情。理論上。
但我們沒有人能做到。不過，規劃可以幫助你更接近那個理想，因為它會問出所有你如果自己動手實作時需要回答的問題：
- 開始日期和結束日期可以相同嗎？
- 部分選取是否有效？
- 使用者應該能夠清除日期嗎？
- 「今天」應該總是可見的選項嗎？
- 允許手動輸入嗎？
- 日期儲存在什麼格式？
- 允許貼上日期嗎？
清單不勝枚舉。你不可能想到所有這些邊緣情況，但模型可以幫助你識別其中的許多情況。
你可以透過安裝 Matt Pocock 的 「grill-me」 技能，讓規劃模式在問問題和邊緣情況的數量上更加激進。
/plan /grill-me 建立一個日期選擇器網頁元件。我希望使用者能夠在年、月、日之間縮放。
這個規劃步驟至關重要。重點不是要你接受 AI 的每一個建議。如果你這樣做，就否定了這個規劃過程的價值。重點是你要深入參與問題並引導模型。這就是你的專業知識發揮作用的地方。
你也可以反過來問模型問題。在下面的螢幕截圖中，它問我關於「非連續日期」的問題。我很確定我理解模型在這裡的意思，但我會要求澄清，這樣我們才能達成共識。
閱讀圖片描述
ALT
GitHub Copilot 規劃模式就日期選擇器提出澄清問題。
規劃過程會持續進行，即使你中斷提問澄清問題等等。
5. 使用 Autopilot 實作
計劃完成後，GitHub Copilot 很可能會提示你切換到 Autopilot 並開始實作計劃。
閱讀圖片描述
ALT
GitHub Copilot Autopilot 正在實作一個計劃。
Autopilot 是一個內建迴圈。它強迫模型繼續工作，確保它確實做到了它說它會做的事——在這裡就是完成計劃中的每一項。
GitHub Copilot 在這一階段會自動扮演協調者的角色。如果它需要讀取程式碼庫中的檔案，它會使用「Explore」子 Agent 搭配一個較小的模型。如果它認為某個動作相對複雜，它可能會選擇「General Purpose」子 Agent 搭配一個較大的模型。雖然你可以透過自訂 Agent 和指令 在 GitHub Copilot 中獲得對協調的精細控制，但你不需要做任何特殊的事情就能享受到子 Agent 和多模型工作流程的優勢。這開箱即用，即使你完全不知道這些東西的存在。
6. 人工審查與迭代
這就是你獲得多巴胺刺激的地方。你可以看到 AI 創造了什麼。
但很可能你並沒有得到你完全想要的東西。這是正常的，也是預期的。模型無法讀懂你的心思，而且它容易出錯。與模型迭代，直到你得到你真正想要的東西。無論是程式碼還是改進的使用者介面，這部分你的品味將決定最終產品的品質。
例如，這是 GitHub Copilot 給我的日期選擇器。
閱讀圖片描述
ALT
初始的日期選擇器結果。它顯示 12 個方塊，年份從 2018 年到 2029 年可供選擇。
我已經看到它有一些問題：
- 動畫不一致
- 懸停在選中日期上時，文字因為顏色對比而無法閱讀
- 頂部不需要顯示「12 年」
- 當我點擊「今天」時，如果我在月份或年份視圖，它不會帶我到日期視圖
而且，我不喜歡這個設計。它看起來有點太像 AI 創造的了——因為確實是！
所以在這裡我們只是處於後續模式。我將使用一個我建立的 CSS 框架，叫做 Postrboard。我把它添加為一個技能，指向 CSS 並告訴 Agent 如何使用它。如果你願意，可以自行安裝使用，或者你也可以選擇任何你喜歡的其他 CSS 框架。給模型一些設計指引非常有幫助，通常一個 CSS 框架就足夠了。
好的——我們不需要著陸頁面，只需要元件、輸出和設定面板，放在一個簡潔的環境中。使用 /postboard 技能來處理設計和顏色。
對於日期選擇器，當我點擊日期時，它會嘗試縮放，但因為沒有東西可以縮放而失敗。那裡不應該有縮放。
頂部不需要顯示「縮小」
當我滑鼠移到包含選中日期的月份或年份上時，我無法閱讀懸停文字。
當我點擊「今天」時，它應該帶我到該日期視圖，即使我在月份或年份視圖。
月份下面不需要數字，也不需要放在方塊裡
年份也一樣。而且頂部不需要顯示「12 年」。
注意這是多麼對話式的。不要想太多。當你像這樣修復一堆小問題時，直接把它們丟給模型。如果你的上下文有了，提示就有了。
最重要的是，不要滿足於「足夠好」的 AI 輸出。堅持品質。對它毫不留情。這部分仍然是你的責任，而知道什麼是高品質的結果、什麼不是，正是你帶來的價值。沒有任何 AI 能取代你的人性觸感和創造力。
這是我最終的日期選擇器看起來的樣子。滾動到這篇文章的結尾，看看它的實際運作。
閱讀圖片描述
ALT
最終的日期選擇器結果。它顯示左邊有一個月曆，右邊有視圖設定。
7. 對結果進行 Rubber Duck 審查
在你迭代並對創作的內容感到滿意之後，是時候進行最終審查了。
向 GitHub Copilot 請求一個 Rubber Duck 審查。你可以直接要求：
對這個日期選擇器元件的實作進行 Rubber Duck 審查
在 Rubber Duck 審查中，GitHub Copilot 會向一個來自不同 AI 家族的模型請求審查。例如，既然我使用的是 GPT 5.6 Terra，它會請求 Sonnet 進行審查。不同的模型是在不同的資料上訓練的，因此它們有不同的盲點。Rubber Duck 審查有助於識別單一模型可能遺漏的潛在問題。
請注意，你可以在這個工作流程的任何時候使用它。你可以對原型進行 Rubber Duck 審查。你可以對計劃進行 Rubber Duck 審查。這完全取決於你是否想對某個東西進行第二次 AI 審查。
如果你想更進一步，你可以將 Rubber Duck 與 Autopilot 結合起來，讓模型在一個迴圈中協同工作，以改進最終結果。
/autopilot 對這個日期選擇器實作進行 Rubber Duck 審查。當你得到結果後，仔細審查它並進行任何必要的調整。重複 Rubber Duck 審查，直到你和審查模型都同意，剩下的項目只會帶來遞減的報酬。
這一步之後，你將得到比之前更精煉的結果，並且很可能已經識別出許多額外的邊緣情況。這一步確實會花費更多 token，但你正在真正地讓程式碼更加堅固。把它看作對你未來自己的投資，因為你現在就發現了這些問題，以後就不必處理了。
8. 獲利
此時，你已經準備好暫存並提交，或者繼續進行下一個你想在這個 pull request 中添加的功能。
我建議你為接下來做的任何與這個日期選擇器無關的事情，開始一個新的聊天對話。你可以把聊天對話看作是主題性的；如果你開始偏離主要主題太多，可能是時候開始一個新的對話了。
這是我為這篇文章建立日期選擇器的工作流程的最終結果。
我知道這是一個有點刻意設計的例子，但我們能不能都暫停一下，驚嘆一下我們現在能用 AI 做到的事情？建立一個日期選擇器曾經是最難做到的事情之一。只要問問那些曾經建立過日期選擇器的英雄們就知道了。
事情不必複雜
這個簡單的工作流程對大多數人來說就足夠了。簡單性也有助於你多工處理。當你保持簡單時，更容易搞清楚哪個 Agent 處於什麼狀態，以及你上次在做什麼。你的上下文視窗也是有限的。
現在 AI 領域發生了太多事情。你可以建立和實驗的東西沒有上限。你可以添加 MCP 伺服器、技能、指令和自訂 Agent。你可以設定工作流程和迴圈，建立提示 Agent 的 Agent，以及搭建整個虛擬開發團隊。
但請記住，現在沒有人真正知道自己在做什麼。我們都在邊做邊學。今天 AI 的許多神奇咒語，明天可能會成為反模式。
專注於以最簡單的方式獲得可重複、高品質的結果。學會 harness，你就會沒問題。
