使用 github copilot 心得

最近看了很糟糕的 github copilot 分享，所以我也來分享一下

內文中的 github copilot 只是一個代稱，相似的工具有 OPEN AI 的 chatGPT，或是 jetbrains 的 AI Assistiant，我都是指它們的聊天功能，但如果文中明顯指的是程式碼自動建議功能，那當然就是 copilot 了。

第一個部分：協助討論釐清想法、調整方向

其實最主要的就是為了想要分享一下這些生產力工具的使用方法，或者說心得，但又不是很想講別人講過的東西，那些怎麼安裝，給予提示詞的技巧等等，我覺得應用起來就是那樣而已，沒甚麼特別好提的，於是寫著寫著，我發現好像把重點放在別的地方會更有趣一點，比如互動討論，從而提升自己的部分反而我比較有共鳴

所以我就模擬一下，我想要寫一份關於 Github Copilot 如何幫助我們的日常工作這個情境
我一開始沒有想太多，就是覺得日常工作有 Github Copilot 的協助可以幫助我提高工作效率，所以我打算從這邊開始著手，然後詢問意見，我列出了下面的表格，然後從這邊當出發點開始討論

---

工作類型	描述	時間比例
重要且緊急	正式環境的異常狀況處理，如訂單、信用卡等等之類；又或與公司商譽相關的任務處理	約 10-15%
重要且不緊急	日常的例行任務，如上版需求開發測試	超過 50-60%
不重要但緊急	需要即時回應的事情，如長官或客戶對某些問題的詢問	約 10-15%
不重要也不緊急	研究新技術或重構優化任務	約 10-15%

這四種任務的大致參考時間，前提是在健康的工作環境下

想法不錯，但感覺好像沒有那麼好寫，畢竟感覺範圍有點大了，我就去問了 AI，請他給我一些寫作上的建議，於是它回復了

您的草稿已經有了很好的結構和規劃，很明顯地將資訊人員的工作分成了四個主要部分，並准備針對每個部分詳細描述 AI 如何提升效率和生產力，我認為這個框架極好。這種針對性的方式可以讓讀者更具體地理解 AI 如何在日常工作中幫助他們。
以下是我對逐一討論的一些建議：
"重要且緊急"：您可以討論AI如何快速識別和解決這種任務的問題。例如，AI可以識別出模式，預測可能的問題，並在問題發生前給出警告。也可以使用機器學習來優化問題的解決方法，從而縮短解決問題的時間。
"重要且不緊急"：AI可以自動化許多日常任務，從而節省時間。例如，AI可以協助进行代码审核，找到可能的錯誤和改進點；或自動完成某些測試和驗證工作。
"不重要但緊急"：AI可以協助排序這些任務的優先級，確保能夠有效地回應。此外，一些 AI 工具可以自動回复一些常見問題，減少了人工回答的需要。
"不重要也不緊急"：透過AI進行資料分析和預測，可以提前找出可能的問題，提早開始對策，直接降低問題嚴重性，給予預警。

但這跟我希望強調 Github Copilot 工具的目標是不符合的，所以我又問它了

我希望能夠聚焦在 Github Copilot 或者是 JetBrains AI Assistant 這類的工具上，而不是更大範圍的AI，所以你給的建議對我這份文件的目標，並不符合

緊接著它又回復了

"重要且緊急"：這些工具可以幫助寫更高效的代碼。例如，它們可以提供實時的代碼建議來解決編程問題，從而減少解決代碼問題的時間。
"重要且不緊急"：Github Copilot和JetBrains AI Assistant可以進行代碼審核，提供清晰正確的代碼建議來改進和優化現有的代碼，這對於項目維護和重構工作非常有幫助。
"不重要但緊急"：這些工具能夠快速回覆常見的代碼問題，例如語法錯誤、未定義的變量等，從而提高開發者的解抖速度。
"不重要也不緊急": 工具如Github Copilot和JetBrains AI Assistant能協助初步的開發和研究新技術，提供編程語言或框架的使用建議，使得學習和適應新的技術變得更為輕鬆。

然後我越看越奇怪，怎麼這幾件事情講的都是在寫程式碼，我好像一開始想法就有點大了，畢竟 AI 能做很多事情，但是 Github Copilot 主要針對的還是程式碼寫作這一塊，所以我好像應該要改變一下我的文件結構，為此，我又再次請 AI 給我點意見

那麼我換一個思維，我想著重強調在軟體開發過程當中，該如何有效地去運用 Github Copilot 這類的工具，目前主要的使用方式不外乎就是直接編寫的過程中透過一些技巧讓工具自動產生程式碼，又或者是直接透過聊天的方式讓工具提供資訊或程式碼，當然，我還是請 AI 針對我的大綱給出建議

於是我又很偷懶的把題目丟給它，請它發揮給我瞧瞧，這個時候就感覺自己是甲方，然後跟乙方提：你先做一版出來看看感覺如何，大概就是這樣的概念

一般情況下，到這邊為止就是一個不錯的 ending 了，我只要照著他的框架，填充一下細節就能夠完成這份簡報、或者是文件了

在剛剛這一連串的過程當中，我主要透過聊天的方式，將我的需求丟給 AI，並請它給我回饋，而我與 AI 來來回回的溝通，正是為了要完成某一個目標而逐漸修正結果的一個過程
當然這只是為了示範，我是怎麼將一個很模糊的想法，逐步透過 AI 討論將它轉變為一個較有條理的內容，可以看到我最初的想法其實是不 OK 的，在討論的過程當中再逐漸修正想法，等到比較確實可行的概念出現後，開始填充並完善細節

我之所以示範這個過程，目的是為了要著重呈現這樣的模式

表面上看到的：提出想法，討論並修正這樣的概念
但我想強調的是：解釋你的目標跟概念，溝通取得回饋，並隨時調整

第二個部分：自我提升

在大部分的情況下，你都可以初步相信 AI 給你的建議，就把 AI 當成一個書看很多，甚麼都懂一些的新進員工，只是剛到公司缺少一些經驗，然後讓自己跟他 pair programming

1. 請對答案持有基本的懷疑
2. 要能夠驗證回饋的資訊是否正確、是否可行

如果可以的話，問問它給出解決方案的理由是什麼，也順便告知它你否決掉某些設計的理由是什麼，在這個過程當中也可以增強自己的專業知識，是很好的方式

通常針對程式碼細節的部分，參考資料來自於網路公開資訊，時常會有神來一筆的狀況，但不可否認也會有給出錯誤解答的時候，因此在得到 AI 給予的回饋時，必須具備驗證答案的能力。因為種種原因，AI 給出的建議大多數時候不會完全滿足使用者的需求，這就是為甚麼需要給 AI 足夠的上下文判斷，在自動完成程式碼編寫的時候，這些上下文會透過工具本身去從你的專案裡面尋找，透過各種小技巧來提供更多的上下文，例如畫面上顯示的文字，同時開啟的分頁，專案類型中某些關鍵的設定檔等等，但是光是這樣還不能夠滿足我們實際使用上的需求，所以還有第二種方式，也就是透過互動的方式提供足夠的上下文，並以聊天的方式回饋，而這就不僅僅是侷限在程式碼的撰寫了，應該說，用聊天的方式來討論需求，這才是 AI 真正強大的部分

因為只要你提供了足夠多的上下文，他就能夠針對問題給出較細緻的回答，而過程中回饋的資訊有誤，或是有新的調整因子，也可以透過聊天來逐步優化設計，聊天的方式除了回饋， AI 也能夠透過這樣的方式，適當的引導使用者該如何給予資訊，所以該如何有效率的使用這個工具，則是取決於良好的溝通能力與抽象化問題的能力

有些人總是會詢問 copilot 關於實作的細節，但是我認為比較好的方式，是再更進一步去問問為甚麼採用這樣的方式來實作？跟原先的方法來比較差別在哪裡？有沒有其他辦法可以做到一樣的事情？每一種解決方案的優缺點在哪裡？我很難舉出一個具體的例子，所以只能拋出這些範例式的問題，我看過一些例子有一些人在建議大家學習這個 copilot 之類的生產力工具時，都著重在說他怎麼利用他解決了甚麼問題，節省了他多少查閱文件資料的時間，這當然很棒，我也常常用，但我更想幫他們補充的是，你要把這部分節省下來的時間，拿去多問一些類似上面這些問題，問自己或者問 copilot 都好，去多思考一下影響你做這些決定的原因，這樣才能讓 AI 去做低階工程師的事情，節省了你的時間，則拿去做更有意義跟生產力的事情

畢竟程式碼細節的部份可以請 AI 協助提供，我們需要做的事情是驗證並確認其可行性
將低階的工作交由 AI 輔助，我們才能夠將注意力移到高階設計這個範疇

所以長久下來，關於程式碼的實作細節可能會逐漸淡忘，但取而代之的是培養自己的高階設計能力，這對於軟體設計是很重要的。

結論

1. 把 AI 當成 pair programming 的隊友
2. 這個隊友有時候腦子怪怪的，你要有能力驗證他的回答
3. 如果他給予的建議不夠好，想想看是什麼原因讓它忽略了你認為理所當然的事情
4. 試著把自己的角色提升到更高的維度，去看原先困擾你的問題，你會在意的是實作細節嗎？還是這樣做帶來的影響？以及為甚麼這樣做？