# harness 就是你的全部所需（差不多啦）：一套 GitHub Copilot 實用工作流 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 原作者：GitHub (@github) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥 · 日期：2026-07-29 > 原始來源：https://x.com/github/status/2082201573976056245 ## 中文摘要 # harness 就是你的全部所需（差不多啦）：一套 GitHub Copilot 實用工作流 ## 一個實用的 GitHub Copilot 工作流程，用於軟體原型設計、規劃、實作與審查——不用追逐每一個新的 AI 工具。 By @burkeholland 如果你現在覺得被 AI 淹沒，你並不孤單。 每天似乎都有新工具、新 MCP、新模型、新 skill、新工作流程、新功能、新社群貼文，內容大概都是：「嘿你看！我只用了一個奇怪的 prompt 就徹底搞懂 AI 了。」 我……才不信呢。 我每天都在跟 AI 打交道，而我發現的規律是：少即是多。真正產生差異的，不是我安裝了什麼、設定了什麼，或是用什麼技巧去誘導 Agent 做事。那些東西雖然有趣，但說到底感覺就像是噱頭。 我發現生產力提升最多的地方，來自於我如何使用 harness 以及我對它的理解程度。 所以在這篇文章中，我將與你分享一個簡單的工作流程。你只要利用 GitHub Copilot 現有的功能，就能大幅提升使用 AI 的效率。沒有奇怪的 prompt。沒有大家好像都懂的 skill。只有 harness。harness 就是你的全部所需——差不多是這樣。 ## 免責聲明 我把「harness」和「GitHub Copilot」這兩個詞交替使用。這篇文章的重點是保持簡單，所以只要知道 GitHub Copilot 就是一個 Agent harness 就好。 我並不是在暗示你永遠不需要任何 skill、MCP、指示詞或自訂 Agent 等等。事實上，隨著你不斷進步，需要定義複雜的工作流程並為團隊自動化各種事物時，這些東西會變得很重要。事實上，我在這篇部落格文章中就用了幾個！ 我想指出的是，要用 AI 獲得極高的成功，你根本不需要那些東西。 話說回來，網路上也有很多垃圾內容。如果你不相信，叫 Agent 隨便寫一個 skill 來做任何事，它都會樂意照辦。不管那個產生的 skill 實際上能不能用，它都可以輕易發佈到無數個 skill 或 MCP 登錄檔中。 ## 1. 挑選工具，隨便哪個工具都行 這很顯然，對吧？挑個工具！這太簡單了！ 但即使在 GitHub Copilot 家族中，也有很多選項。其中包括 CLI、全新的 GitHub Copilot app、VS Code、Visual Studio 和 JetBrains，族繁不及備載。 好消息是，這些體驗正日益集中到同一個 harness 上。細節可能會因工具而異，但核心工作流程是一致的。學會一次 harness，到處都能使用。 話雖如此，我確實相信學習 harness 是關鍵，而學習它的最佳方式就是盡量靠近它。所以如果你才剛開始，我建議從 GitHub Copilot CLI 開始。它是一個終端機介面，意味著它全都是文字。沒有太多 UI 需要學習。你輸入一個 prompt。Agent 開始做事。但這種互動更直接、更即時，老實說，也非常有滿足感。 為了這次示範，我會使用全新的 GitHub Copilot app。但該 app 所使用的 harness，跟你使用 GitHub Copilot CLI、Visual Studio Code 以及許多其他可以找到 GitHub Copilot 的地方時，所使用的東西完全一樣。 ## 2. 開啟 YOLO 模式 YOLO 模式也被稱為「全部允許」（Allow All）。這能讓 Agent 執行任何指令而無需詢問許可。這可能會根據你使用的工具而有所不同，但在多數情況下，它就只是聊天室裡的 `/allow-all` 指令。否則，每當 Agent 需要做點事時，它就會停下來等待你的批准。 要讓生產力提升，Agent 需要自主性。如果你必須批准 Agent 所做的每一件事，那你乾脆自己動手還比較快。再說，那是一種悲慘的使用者體驗。沒有人想整天坐在桌子前按「批准」按鈕。而且一遍又一遍地按「批准」，只會訓練你不再去閱讀你被要求批准的內容，這就違背了初衷。 不過，與 Agent 互動還是得注意安全。好人也會遇到壞事。在使用 YOLO 模式時，你絕對不想在你的本機上執行 Agent。當你在工作中使用它們時更是如此——資料在你組織的系統中是私密的，而且犯錯的代價可能很高。 幸好，在沙盒中執行 Agent 有許多選項。一個很好入門的選擇是 GitHub Codespaces 或開發容器（development containers）。 ## 3. 從原型開始 AI 最神奇的事情之一，就是你可以事先輕鬆對任何事情進行原型設計。歷史上並非如此。原型設計曾是專案的一個完整階段，而且通常是一種奢侈品。現在，只要一個 prompt 就能做出來。 讓我們來看幾個例子。 假設我們想建立一個日期選擇器網頁元件。這聽起來很直觀，但實際上相當複雜。想想所有你可能會想用它來做的不同事情： - 你如何在元件內進行導覽？ - 已選取的日期長什麼樣子？ - 已選取的範圍長什麼樣子？ - 使用者如何在日、月、年之間進行導覽？ 從一個簡單的原型開始，並取得多種變化版本。我通常會從這樣的東西開始： > 請為日期選擇器網頁元件提供 20 種展示外觀。把它們全部放在一個 HTML 檔案中，以便我進行比較。 ![GitHub Copilot 介面展示包含年份預覽與可用性熱力圖的日期選擇器設計原型網頁](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1b3febf3faab40ef.png)
展開畫面重點
視窗標題顯示 GitHub Copilot，分頁標題為「20 Date Picker Mocks」。網址列顯示 `file:///C:/Users/buhollan/.copilot/chats/5c01b42d-1f59-49ba-8e2a-caeca11c65e9/date-picker-mocks.html`。右上角有「Shared」按鈕、「Pick & Polish」按鈕以及主題切換圖示。頂部選單列有一系列篩選標籤，包含「All 20」、「Minimal」、「Expressive」、「Range」、「Mobile」、「Contextual」（目前選中）。主畫面分為左右兩個區塊：左側標題為「Year at a glance」（副標題：Navigate months before choosing a day.），下方展示一個 2026 年各月份（JAN 到 DEC）的小型月曆方格總覽，其中 9 月（SEP，格內序號 9）整格以紅色突顯；右側標題為「Availability heatmap」（副標題：Demand density for flexible scheduling.），下方展示以 2026 年 11 月（November 2026）為主、帶有綠色深淺不同色階的可用性熱力圖月曆，並於底部顯示「November 16」及「12 spots available」。下方兩個卡片標題分別為「19 Natural language」（標籤為 INPUT，副標題：Type intent; confirm the interpreted range.）與「20 Glass orb」（標籤為 EXPRESSIVE，副標題：A dimensional concept for premium experiences.）。
在這個案例中，AI 產生了一堆不同的版面配置，其中一個展示外觀是以年份檢視開始的。這很有趣。我希望我的日期選擇器能夠讓使用者縮小到年份，然後放大到月份，最後再到日期。這些都是在你親眼見到之前不會考慮到的事情。 身為人類，我們處理感官豐富的表徵（例如圖片、形狀和具體的版面配置）的速度，遠比密集的文字快得多。及早建立低成本的原型，有助於讓複雜的概念瞬間變得直觀。 這也適用於非視覺化的任務。 例如，如果我想新增一個新的 API 端點，我仍然會建立一個視覺化原型，以便在深入實作之前先釐清需求與限制。 > 請為這個專案的 API 建立一個視覺化 mockup。針對如何處理一個能讓使用者下載其分析資料的新 API 端點，提供五種處理方式的選項。 ![GitHub Copilot 介面呈現 analytics-api-download-options.md 檔案內容，包含「Five endpoint options」架構圖與 Option 1 的 HTTP 請求與回應範例](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1f42a3276cf68143.png)
展開畫面重點
視窗標題顯示 GitHub Copilot，分頁標題為 analytics-api-download-options.md。 上方標籤顯示： `POST /api/lists/{listId}/analytics/events` `Public, rate-limited` `Capture page views and clicks` `204 No Content` 標題： Five endpoint options Diagram 區塊顯示架構圖： 最上方節點：`Download analytics` 向下分支為五個選項： 1. `1. Account-wide synchronous GET`，其下方子節點為 `GET /api/analytics/export` 2. `2. Per-list synchronous GET`，其下方子節點為 `GET /api/lists/{listId}/analytics/export` 3. `3. Asynchronous export job`，其下方子節點為 `POST /api/analytics/exports` 4. `4. Content negotiation`，其下方子節點為 `GET /api/analytics + Accept: text/csv` 5. `5. Custom report POST`，其下方子節點為 `POST /api/analytics/export` Option 1 區塊標題： `Option 1 — Account-wide synchronous export (recommended MVP)` Http 區塊 1： `GET /api/analytics/export?format=csv&from=1751328000000&to=1753919999999` `Cookie: urlist_session=...` Http 區塊 2： `HTTP/1.1 200 OK`
由於 GitHub Copilot app 支援 Mermaid 圖表，Agent 會將其渲染為 Markdown，規劃出我們實作這個 API 端點的五種不同方式。 與 Agent 合作時，很容易忘記每個細節都充滿微妙之處。原型設計有助於事先揭露這些細節，讓你不致於把寶貴的時間和 token 浪費在重工上。 我建議在多數工作中使用中型模型，例如 GPT 5.6 Terra 或 Claude Sonnet，並把推理強度設為中等。我也建議你在這個特定功能、臭蟲或增強功能的整個期間，都堅持使用你所選定的模型。Prompt 快取（prompt caching）能幫你節省 token。只要你沒有切換到不同的模型或推理層級，你先前的對話就會被快取在模型中，讓你在未來的請求中享有折扣。 ## 4. 有條理地規劃 現在你已經知道自己真正想要的是什麼，而不是一開始以為自己想要的是什麼，是時候規劃實作了。 在 GitHub Copilot 中切換到計畫模式（plan mode），且不需要開新工作階段。 > /plan 建立一個日期選擇器網頁元件。我希望使用者能夠在年、月、日之間進行放大與縮小。 那是一個相當模糊的 prompt，你對模型的脈絡掌握可能會比我這裡多，但這只是一個示範。如果你沒有更多脈絡也沒關係。這正是這個步驟的目的。 理論上，如果你用完美的脈絡、完美的順序組合出完美的 prompt，你可以讓模型一次搞定任何事。理論上是這樣。 但我們沒有人辦得到。不過，透過提出你在親手打造時沿途需要自行回答的所有問題，規劃能讓你更接近那個理想狀態： - 開始日期和結束日期可以是同一天嗎？ - 部分選取有效嗎？ - 使用者應該能夠清除日期嗎？ - 「今天」應該隨時都是一個可見的選項嗎？ - 允許手動輸入嗎？ - 日期儲存為什麼格式？ - 應該允許貼上日期嗎？ 這個清單可以一直列下去。你不可能想得到所有這些邊界案例，但模型可以協助你找出其中許多案例。 透過安裝來自 Matt Pocock 的「grill-me」skill，你可以讓計畫模式在提出問題和邊界案例的數量上變得更積極。 > /plan /grill-me 建立一個日期選擇器網頁元件。我希望使用者能夠在年、月、日之間進行放大與縮小。 這個規劃步驟至關重要。重點不是讓你照單全收 AI 的所有建議。如果你那樣做，就否定了這個規劃過程的價值。重點在於讓你深度參與問題並引導模型。這正是你的專業知識派上用場的地方。 你也可以反問模型問題。在下面的截圖中，它問了我關於「非連續日期」（non-contiguous dates）的問題。我很確定我知道模型這裡指的是什麼，但我還是要要求釐清，好讓我們有共識。 ![載入 skill grill-me 後詢問互動模型與版本支援選項的互動介面](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b6c29b8f63dd43be.png)
展開畫面重點
畫面顯示 loaded skill grill-me，並有以下互動紀錄與選項： - 記錄 1：Asked user: What should "zoom" mean in the interaction model? - 記錄 2：Answer: Hierarchical drill-down: years → months → days, with the header or a control zooming back out (Recom... - 記錄 3：Thinking - 記錄 4：Asking user: What selection modes must the first version support? 對話區塊下方有一選單標題「What selection modes must the first version support?」，列出四個選項： 1. Single date only (Recommended) 2. Single date and date range 3. Single date, date range, and multiple non-contiguous dates 4. Wait - what would non-contiguous date ranges even look like here? (此項為目前選取狀態) 右下角有兩個按鈕：「Cancel Esc」與綠色的「Continue」。
即使你打斷它來詢問釐清性質的問題等等，規劃過程也會繼續進行。 ## 5. 使用 Autopilot 進行實作 一旦計畫完成，GitHub Copilot 很可能會提示你切換到 Autopilot 並開始實作該計畫。 ![顯示 Plan summary 的專案計畫摘要與後續執行選項介面](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/c84d195b051a6a7b.png)
展開畫面重點
畫面頂端標題為「Plan summary」，其下方條列了六點計畫說明： 1. Build a framework-free `<zoom-date-picker>` ES module plus a separate interactive demo, preserving the 20-mock comparison page. 2. Implement hierarchical year → month → day drill-down, fixed 3×4 year/month grids, a full 6×7 day grid, and stable panel dimensions. 3. Add elaborate cell-centered spatial zoom transitions with cross-fade and reduced-motion fallbacks. 4. Support inline/popover modes, native forms, ISO calendar-date values, constraints, localization, full keyboard accessibility, and responsive light/dark styling. 5. Expose a documented attribute/property/method/event API, CSS tokens, and `::part()` hooks. 6. Verify all navigation, selection, form, popover, keyboard, responsive, and motion states through the demo. 下方則列出兩個後續選項： 1. Approve and implement with autopilot (recommended) (右側標示 Ctrl+↵) 2. Exit plan mode and I will prompt myself
Autopilot 是一個內建的迴圈（loop）。它透過確保模型確實完成了它所說要做的事——在此情況下即完成計畫中的每一項任務——來強迫模型持續工作。 在這個階段中，GitHub Copilot 會自動充當協調者（orchestrator）。如果它需要讀取程式庫中的檔案，它會使用帶有小型模型的「Explore」子代理（subagent）。如果它認為某個動作相對複雜，它很可能會選擇帶有較大模型的「General Purpose」子代理。雖然你可以在 GitHub Copilot 中透過自訂 Agent 和指示詞來對協調過程進行微調控制，但你不需要做任何特殊設定，就能獲得子代理和多模型工作流程的好處。這開箱即用，即使你根本不知道這些東西存在也一樣。 ## 6. 人工審查與迭代 這是讓你獲得多巴胺分泌的時刻。你將親眼見到 AI 創造出了什麼。 但你很可能無法一次就得到你想要的精確結果。這很正常，也是預料中的事。模型無法讀懂你的心思，而且它容易出錯。與模型反覆迭代，直到你得到真正想要的結果為止。無論那是純程式碼還是改良過的 UI，這部分正是你的品味決定最終產品品質的關鍵。 例如，這是 GitHub Copilot 給我的日期選擇器： ![涵蓋 2018 至 2029 年共 12 年區間的年份選擇器介面](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e3ef9a51cc0f0963.png)
展開畫面重點
畫面為一個年份選擇器的 UI 元件，標題顯示「2018–2029」與「12 YEARS」，左右兩側分別有向左 `<` 與向右 `>` 的切換箭頭。 主體區域為 3 欄 × 4 列的格狀年份清單，各格子的內容與編號如下： - 第一列：`2018`（下方數字 `1`，字體較淡）、`2019`（下方數字 `2`，字體較淡）、`2020`（下方數字 `3`，字體較淡） - 第二列：`2021`（下方數字 `4`）、`2022`（下方數字 `5`）、`2023`（下方數字 `6`，此方塊呈現醒目的橘紅色背景，為選中狀態） - 第三列：`2024`（下方數字 `7`）、`2025`（下方數字 `8`）、`2026`（下方數字 `9`，右上角有一紅色小圓點） - 第四列：`2027`（下方數字 `10`）、`2028`（下方數字 `11`）、`2029`（下方數字 `12`） 底部左側有「Clear」按鈕，右側有橘色字體的「Today」按鈕。
我一眼就看出它有一些問題： - 動畫不一致 - 由於色彩對比的關係，當滑鼠懸停在已選取日期上時，文字無法閱讀 - 頂端不需要寫「12 YEARS」。 - 當我點擊「Today」時，如果我處於月份或年份檢視，它不會帶我切換到該日期。 此外，我不太喜歡這個設計。它看起來太像是 AI 創造的——因為它本來就是！ 所以在這裡我們處於後續追蹤模式（follow-up mode）。我要使用一個我建立的 CSS 框架，叫做 Postrboard。我把它加為一個 skill，該 skill 指向該 CSS 並告訴 Agent 如何使用它。如果你想用它，可以隨便把它安裝起來，或者你也可以挑選任何其他你喜歡的 CSS 框架。給予模型一些設計指引相當有幫助，通常一個 CSS 框架就是你的全部所需。 > 好，我們這裡不需要 landing page —— 只要在極簡的設定下呈現元件、輸出與設定面板即可。請使用 `/postboard` skill 來處理設計與顏色。 > 針對日期選擇器，當我點擊日期時，它會嘗試放大，但因為沒有東西可以放大而失敗。那裡不應該有放大功能。 > 頂端不需要寫「Zoom Out」 > 當我滑鼠懸停在包含已選取日期的月份或年份上時，我無法閱讀懸停文字。 > 當我點擊「Today」時，它應該帶我進入該日期的檢視畫面，即使我目前在月份或年份也一樣。 > 月份下方不需要數字，也不需要放在方框裡。 > 年份也是如此。而且頂端不需要寫「12 years」。 注意到這有多麼對話式了嗎？不要想太多。當你要修正一堆這樣的小問題時，直接交給模型處理就行了。如果你掌握了脈絡，你就掌握了 prompt。 最重要的是，不要滿足於「差不多夠好」的 AI 輸出。堅持品質。對此要毫不留情。這部分依然是你的責任，而辨識出高品質結果與平庸之作的差異，就是你所帶來的價值。沒有任何 AI 能夠取代你的個人風格與創造力。 以下是我最後的日期選擇器長相（原文文末附有可實際操作的互動 demo）。 ![GitHub Copilot 中的 Date Picker 介面預覽與右側 Settings 調整面板](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/8328ee604c46da98.png)
展開畫面重點
GitHub Copilot 介面，分頁標籤顯示「Zoom Date Picker Demo」與「Date Picker Workbench」，網址列為 `file:///C:/Users/buhollan/.copilot/chats/5c01b42d-1f59-49ba-8e2a-caeca11c65e9/date-picker-demo.html`，右上方按鈕包含「Shared」、「Dark mode」、「Pick & Polish」。 左側主畫面標題為「Date picker Component workbench」，下方包含一個月曆元件，標題為「May 2026」，日期包含星期日至星期六（S M T W T F S），目前選中橘色圓圈標示的日期為 7 日（7），下方有「Clear」與「Today」按鈕。 右側為「Settings」（LIVE 狀態）面板，包含下列設定欄位與控制項： - VIEW：下拉選單選取 `day` - DISPLAY DATE：日期輸入框 `05/07/2026` 附帶日曆圖示 - LOCALE：下拉選單選取 `English (US)` - WEEK STARTS：下拉選單選取 `Locale default` - MINIMUM：日期輸入框 `01/01/2021` 附帶日曆圖示 - MAXIMUM：日期輸入框 `12/31/2032` 附帶日曆圖示 - DISABLED DATES：輸入框填寫 `2026-09-08,2026-09-09,2026-09-24` - 核取方塊選項：`REQUIRED`、`READONLY`、`DISABLED` - 底部按鈕區：`Zoom out`、`Zoom in`、`Previous`、`Next`、`Today`、`Clear`
## 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 審查，直到你與審查模型都同意剩下的項目只會帶來遞減報酬（diminishing returns）為止。 經過這個步驟之後，你將會獲得比之前更精煉的成果，並且很可能已經找出了許多額外的邊界案例。這個步驟確實會消耗更多 token，但你這是在為程式碼進行實戰驗證（battle-hardening）。把這看作一項對未來自己的投資，因為你現在就把問題抓出來了，以後就不必處理這些麻煩事。 ## 8. 收割成果 此時，你已經準備好進行暫存（stage）與提交（commit），或者繼續處理你想要隨著這個 pull request 一起新增的下一個功能。 我建議針對接下來任何與這個日期選擇器無關的動作，都開啟一個新的工作階段。你可以把工作階段視為具有特定主題的；如果你開始偏離主體太遠，大概就是時候開個新的工作階段了。 以上就是我為這篇文章建立日期選擇器的完整工作流程（成品的互動 demo 附於原文文末）。 我意識到這是一個有點刻意的範例，但我們難道不能全部暫停一下，驚嘆我們現在用 AI 能夠達成什麼成就嗎？建立日期選擇器以前曾是你所能嘗試的最難的事情之一。去問問任何曾經打造過它們的大神就知道了。 ## 事情其實不必那麼複雜 對大多數人來說，這個簡單的工作流程就夠用了。這種簡單性也有助於你進行多工處理。當你把事情保持簡單時，更容易去推理哪個 Agent 處於什麼狀態、以及你剛剛在做什麼。你的脈絡視窗（context window）也是有限的。 現在 AI 領域發生了太多事情。你能建立和實驗的東西沒有上限。你可以新增 MCP 伺服器、skill、指示詞和自訂 Agent。你可以設定工作流程和迴圈、建立能對其他 Agent 發出 prompt 的 Agent，甚至建立整個虛擬開發團隊。 但請記住，現在沒有人真正知道自己在做什麼。我們都是在摸著石頭過河。今天對 AI 來說宛如魔法般的咒語，明天就會變成反模式（anti-pattern）。 只要專注於用最簡單的方式，取得可重複、高品質的結果。學會 harness，你就會過得很好。 ## 標籤 Harness, 教學資源, GitHub, Microsoft