相信大家都聽過「GitHub Copilot」，它在我們coding的時候可以根據上下文自動吐出程式碼建議，只要輕鬆按下Tab鍵就可以直接寫入。我覺得它的命名非常有趣，Copilot在英文就是「副駕駛」的意思。我們從命名就可以看見這個產品的定位，這也同樣適用在大部分的AI工具上——開發人員aka螢幕前的我們，才是掌握方向盤的人，工具只是輔助！
.
.
我朋友曾經分享過一個故事。他隔天要交一個報告但想了半天還是不知道如何下筆，所以就將希望寄託在ChatGPT上。他打開視窗對ChatGPT下了指令：「我明天要交一篇關於新人在試用期的表現評語，請幫我產出300字。」接著，就得到了一篇奇幻故事XD。
AI工具沒辦法通靈知道我們在現實世界被主管交付了什麼任務、PM和設計想改什麼功能。我們要給予明確的任務指令，接下來才是AI工具發揮的舞台。
仔細回想，你是否對AI工具下過一些過於魔幻的指令呢？歡迎在下面分享你的有趣故事。
.
.
.
「副駕駛」要做什麼呢？
其實AI工具的角色比較類似於社團的副社長、副會長，可以幫助我們「加速執行的過程」。包含給我們程式設計的方案、除錯的建議等等，幫助我們更快完成任務。
當我們可以減少在執行上的瑣碎工作，我們就有空檔可以把注意力放在規劃、管理或技術研究的工作。
.
假設今天我們要一條龍包辦所有開發工作，會經歷哪些流程呢？下面我粗略的整理一下。
| 序號 | 開發階段 | 目標 |
|---|---|---|
| 01 | 企劃 | 釐清需求、確定開發功能、交付需求文件 |
| 02 | 設計 | 完成Mockup繪製設計稿 |
| 03 | 技術研究 | 確認新技術可行性、預估時間 |
| 05 | 資料庫 | 欄位規劃、開API，讓畫面上的內容都拿的到資料 |
| 06 | 開發 | 將專案推上線 |
| 07 | 驗收 | 確認所有功能是正常的 |
| 08 | 維運 | 處理臨時的需求調整、優化程式碼 |
接下來，我們看一下在每個階段既定的工作裡面，有哪些工作可能可以交給AI工具，或是導入工具輔助協作。(備註：我已實作過的地方會給1-5分代表導入工作所帶給我的加分程度，例如：「(4)」。)
.
企劃
在分工明確的團隊裡，工程師在這個階段通常是處於「備詢狀態」，讓PM和設計師確認這次要做的功能是做得到的，或是提供一些可行方案等等。但如果我們要做Side Project的時候，這些東西就統統得自己來。（下面的評分是以我自己做Side Project時的體驗分數）
| 序號 | 日常工作會碰到的事 | 導入工具評估 | 可能遇到的困難/備註 |
|---|---|---|---|
| 01 | 發想題目／腦力風暴 | Ｖ(5) | |
| 02 | 案例研究 | Ｖ | |
| 03 | 開會討論、整理會議記錄(PM) | ▲ | 應該有相關工具但還沒實作過 |
| 04 | 收納想法 | ▲ | 無法將所有討論過程告知工具，但可以整理單次討論的摘要 |
| 05 | 產出文件- Sitemap | Ｖ(2) | 產出文件不難，重點是有沒有收斂出結論 |
| 06 | 產出文件- Flow Chart | Ｖ(2) | 同5 |
| 07 | 產出文件- User Story | Ｖ(4) | 同2.4 |
| 08 | 產出文件- PRD | ▲ | 同4，但可以一起協作幫忙處理文書工作 |
.
設計
如果是商用的案子，我不確定AI工具生成的設計稿、圖片有沒有智慧財產權的問題，畢竟這方面目前也頗受爭議。但撇開不談，用AI工具協作產出的設計稿，很大程度上還是要依賴人工去作調整。
這是因為網頁設計和平面設計很不一樣，除了美感，還涉及了資訊架構的處理、UX易用性的考量等等——這些在現實的開發過程中，往往是歷經無數次的來回討論、折衷妥協才定案的結論。
| 序號 | 日常工作會碰到的事 | 導入工具評估 | 可能遇到的困難/備註 |
|---|---|---|---|
| 01 | 繪製Wireframe | ▲ | |
| 02 | 開會討論 | (已重複) | |
| 03 | 繪製Mockup- 靈感參考 | Ｖ(2) | 這個不需要「AI」工具，線上有許多模板素材網站 |
| 04 | 繪製Mockup- 選擇配色 | ▲ | 應該有相關工具但還沒實作過 |
| 05 | 繪製Mockup- 產出UI Kits | Ｖ(4) | 1. 自製：須依照工具的辨識規則將框線稿匯入 2. 非自己創作的素材，多少需要自己手動調整(但對設計麻瓜來說已經幫助很大了所以給4分) |
| 06 | 繪製Mockup- 排版 | Ｖ(4) | 不用自己產UI kits已經可以省很多工 |
.
資料庫
我過往在做Side Project的時候，只在這兩個情境使用到AI工具，畢竟要有什麼欄位還是得依照Mockup去開。但我相信這題交給正牌的後端工程師回答，會有不一樣的答案。
| 序號 | 日常工作會碰到的事 | 導入工具評估 | 可能遇到的困難/備註 |
|---|---|---|---|
| 01 | 開API | Ｖ(3) | 可以幫你想通常的類似情況，會需要什麼API，並給你一個60%的版本 |
| 02 | 開API的欄位、檢查有沒有漏掉 | Ｖ(2) | 同1 |
.
技術研究
資訊收集與整理、輔助程式開發都是ChatGPT的強項。以往我們要穿梭在不同技術部落格、論壇才能拼湊出大致上的方向，但這些經過訓練的AI模型已經都幫我們完成這些工作，直接提供給我們一個的最終方案。
| 序號 | 日常工作會碰到的事 | 導入工具評估 | 可能遇到的困難/備註 |
|---|---|---|---|
| 01 | 事前Study、看前輩的Blog | Ｖ(5) | |
| 02 | 實作POC | Ｖ(5) |
.
開發
我最有感的地方是，它消除了降低了原先的技術門檻。原本一個資深工程師才有能力實作的東西，現在一個初階工程師通過ChatGPT，比以前有更高的成功機率也能做出來。當然，這個「工具紅利」遲早會消失，接下來的戰場就是看誰工具用的好。
| 序號 | 日常工作會碰到的事 | 導入工具評估 | 可能遇到的困難/備註 |
|---|---|---|---|
| 01 | 建立開發環境 | Ｖ(5) | |
| 02 | 前端程式- 切版 | ▲ | 應該有相關工具但還沒實作過 |
| 03 | 前端程式- 套版 | Ｖ(5) | |
| 04 | 後端程式- 邏輯 | Ｖ(5) | |
| 05 | 後端程式- 更新規格 | Ｖ(5) | 更新規格本身有很多麻煩事，我這裡是單指產swagger文件，幫忙程度可以給到5分 |
| 06 | 前後端串測 | Ｖ(5) | 解bug的時候怎麼可能少了它 |
| 07 | 部署上線 | Ｖ(4) | 有許多地方還是要靠自己研究，但至少碰到問題有個方向 |
.
管理與優化
Code Review和寫測試，我認為也算是管理、優化工作的範圍內，而這兩點目前也普遍被認為是ChatGPT強項。
| 序號 | 日常工作會碰到的事 | 導入工具評估 | 可能遇到的困難/備註 |
|---|---|---|---|
| 01 | Code Review | Ｖ(3) | 目前能給有建設性意見的工具，通常無法整個專案一次性的完成，兩者無法兼顧 |
| 02 | 單元測試 | ▲ | 應該有相關工具但還沒實作過 |
.
.
.
看完以上的表格，是否帶給你一些使用AI工具的靈感呢？相信螢幕前的各位已經躍躍欲試，等不及揮舞著魔法棒。
BUT，請先暫停一下腦海中那美麗的畫面。
在我們即將開啟實戰之旅前，我想像個老太太一樣囉嗦的溫馨醒大家要清楚「工具的限制」。唯有清楚工具的定位和長處，我們才不會對工具不實際的期待與認知，才能更好地運用工具。
這裡我想用NBA球員舉例。
.
大家想到NBA的第一個印象一定是「地表最強的籃球員」，但你知道嗎......其實NBA聯盟現役的500人並不等於世界前五百強球員。在這500人裡面，只有極少數人是可以主宰比賽的Keyman，像是Lebron、字母哥、塔圖姆等等，絕大部分的人其實都是所謂的「 功能性球員(Role Player) 」。
功能性球員通常是某個領域的專家，例如籃板球專家、防守專家，他們上場只負責去執行特定的任務或戰術。他們無法主宰比賽，但沒有他們也別想拿下NBA總冠軍。
.
回到AI工具也是一樣，每個工具都有它的定位和長處，他們在不同領域也有各自的強項。我們在使用前必須要清楚這個工具是放在哪個階段去用的，同時回顧自身的情況，看看工具可能可以怎樣幫道我們。接著再一邊實作一邊測試它的天花板在哪。糊里糊塗的草率導入，只會搬磚砸腳。
AI工具究竟是神隊友和豬隊友？這個問題就取決於操控他們的人。
iThome鐵人賽
看影片追技術