我的 AI 輔助開發心得：70 分主義
from Pixabay
去年這個時候，我在某工程師內部社群做了一場線上分享。
題目是〈AI 輔助開發 Side Project 心得分享〉，講的是我開發 WeaMind 這個天氣預報 LINE Bot 的過程中，怎麼跟 AI 協作。
本文算是該分享的延伸。藉題發揮，說說我對目前 AI 的看法。
不過，一年過去，我的想法可能有了一些變化。剛好可以回顧一下，哪些不變，哪些則可以放寬或不再堅持。
請放心，本文不會對開發細節有太多著墨，這裡想要講的還是心法或說心態、AI 與開發者的關係等等。
雖然模型日新月異，這樣的關係也在不斷變化，但我還是試著在此刻留下一個小小的註腳吧！
系列：人類的時代
- Vibe Coding 與人類的時代
- 我的 AI 輔助開發心得：70 分主義
當時，我整理了四個善用 AI 的建議，以及三個對 AI 輔助開發的看法。我們會先講四個建議——它們比較是「戰術」層級的，然後談這篇文章的主軸：我怎麼看待 AI 輔助開發。
四個善用 AI 的開發建議
這些建議是我在實際開發中累積的經驗與想法。
一、規格先行
還記得那時候，每次要開發新功能，我都會先跟 AI 討論半天，讓它列出規格，再開始動手。
這個做法我到現在還是非常認同：先把需求討論清楚，再讓 AI 開發，比較不會受到「驚嚇」。
一年過去，這個「規格先行」也有了更系統化的實踐與方法論，例如 SDD（Spec-Driven Development，規格驅動開發）。
個人雖然不是 SDD 的愛好者，但我開發會用 Matt Pocock 的 grill-me skill 先討論好大致規格。
二、不要自己寫程式碼
這個建議在當時可能還有許多人無法接受或認同。一年過去，爭議本身甚至已經「過時」了。如今的爭論重點已轉向「要不要看程式碼」🤣
儘管如此，我建議讓 AI 寫程式碼——而不要自己寫，主要有四個理由：
- 效率考量：AI 寫程式碼的速度更快，特別是標準 CRUD 或重複性邏輯。
- 減少認知負荷：把心力放在架構設計和業務邏輯，而不是語法細節。
- 避免習慣性錯誤：人容易在程式碼中重複相同的壞習慣。
- 學習機會：AI 可能採用你不熟悉、但更好的寫法。
但我得說，這些理由，大多還是以你「多少會去看 AI 寫的程式碼」為前提。
如果不是這樣，那它的價值可能只剩下「效率考量」了。
三、任務拆分
這裡說的任務拆分，是把交代給 Agent 的工作適度拆小，不要讓它一口氣做太多事情，以免造成「上下文污染」（對話累積太多不相關甚至衝突的資訊，影響模型後續判斷）。
目前公認表現較佳的範圍是在 150k tokens 以內，超過就要留意了，哪怕模型擁有 1M tokens 的上下文視窗也一樣。
四、允許自己「不夠了解」
一開始用 AI 開發時，我會很認真看它寫的每一部分，結果進度相當緩慢。後來我逐漸接受：不是每個細節都需要鑽研到同樣的程度。
例如開發 WeaMind 時，我從比較高層次的角度使用 LINE Python SDK，沒有深入研究每個細節。單元測試也都交給 AI 撰寫，我只關心測試覆蓋率，還有 pytest fixtures 的設計是否合理。
允許自己「不夠了解」，接受自己對全局的掌握有深有淺。對於自己不那麼感興趣的部分，粗略知曉它在做什麼，其餘不求甚解。
我對 AI 輔助開發的三個看法
講完前面四個偏向戰術的建議，接下來進入本文的重點。
一、70 分主義
AI 是 FOMO 之源。
每天都有新工具、新模型、新的使用方式。你不學，就怕被淘汰；你學了，又發現永遠學不完。
考慮到這些東西大部分的生命週期都少於半年，我的結論是：70 分就好。
什麼意思？——比 70% 的人會用就夠了。也就是說，不能不會用，但也不必追求變成 AI agent 大師。
我認為，不要「太認真」有兩大理由。
工具生命週期過短
AI 工具發展迅捷，也意味著彼此之間的競爭、淘汰異常激烈。
對任何一項工具投入太多時間，可能都是不划算的。
以我自己為例，前陣子花了兩天研究並實作 graphify 這個 codebase 知識圖譜的開源專案。號稱可以提升 AI agent 開發效率、減少 token 消耗。
後來又有好幾個競爭者出現，諷刺的是，我看到一個 YouTube 影片對它們都進行測試，結果發現，原生的 Claude Code 效果，其實就足以排到第二了（比裝了 graphify 還好），這……
還好我只研究了兩天就放棄了！
套一段 Will 保哥的名言（大意、非原文）：
你就躺三個月，什麼 AI 資訊都不用管，三個月後還是會獲得 AI 發展的紅利。
當然，我們沒辦法真的躺三個月，畢竟還是要用 AI 工作、開發；但確實不用追著每一個新消息跑。
在 AI 時代，等待，也是一種力量XD
工具層面的進步
退萬步言（法律人最愛講的），縱使你再會用 AI，在我看來，那也只是工具層面的進步。
工具從來都不是重點——解決問題才是。
我總覺得，AI 無法成為軟體工程師的核心競爭力，因為它沒有真正的護城河：你能快速學會的事物，別人當然也可以。
會用 AI 不會讓你變得特別厲害，不會用 AI……還是要會一下辣😅！就說 70 分主義咩，哈哈。
二、善用 AI 的「黑暗面」
各種新聞和社群分享總是告訴你，AI 讓開發速度提升了 5 倍、10 倍、50 倍、100 倍，等等。比較少會提及 AI 輔助開發的黑暗面，畢竟這些不討喜。
不過，讓我們面對現實吧！大量使用 AI 輔助開發，至少會有以下問題：
- AI 讓人不想思考：程式寫完、能跑了，誰還要認真 review？很違反人性。
- AI 讓人不想學習：既然 AI 都幫你寫好了，為什麼還要花時間搞懂？
- AI 造成大量技術債（或說認知債）：一分鐘寫幾百行，你既不 review 也不想搞懂——想想真是很恐怖的事XD
我想這些問題都是真的，嚴重程度多少而已。
雖然我們可以告訴自己「時代不同了啦！以前那套開發模式已經過時」等等，但顯然的，這些並不足以說服我，上面提出的三個問題都不用擔心了。
這個議題，值得另寫一篇（預計是第三篇）討論，我們就先按下不表吧！
三、經驗、思考與組合
如果工具不是重點，那什麼才是重點？
我的答案是：經驗、思考與組合。
經驗
AI 時代，經驗反而更加珍貴。
什麼時候要介入、什麼時候可以放手讓 AI 去做、AI 的盲點在哪裡——這些都需要經驗才能判斷。
為什麼我們還是需要把 AI 工具學得比 70% 的人好？因為如何與 AI 互動本身，也需要大量經驗（和一定的基礎知識）。
思考
但經驗往往來自犯錯與思考。
問題是，AI 讓你不想思考——它太方便了，方便到你可以跳過思考這一步。
某種程度上，不想思考是人的本能，包括我也不例外，所以我們要適時勉強自己。
那什麼時候才是「適時」呢？這當然也需要經驗判斷XD，還有個人的偏好。
不踩坑、不犯錯，一切順風順水，很難想像一個人要如何養成核心的判斷力，以及對事情的好惡。
AI 確實會犯錯，甚至常常犯錯，但這不代表你會思考。如果像這篇〈別依賴「試誤法」寫程式〉般使用 AI，那它無論犯多少錯，都不會增加我們的思考。
組合
有了經驗、願意思考，我們就可以把這些累積和 AI 的強大進行跨域「組合」。
像本系列上一篇提到的 Peggy Lo，就是很好的組合範例。
身為 NGO 工作者，她做她擅長的事情，擁有大量經驗，知道如何思考——但本來不會寫程式。
AI 封裝了「寫程式」這件事情，變成解決問題中的一塊樂高積木，組合進整個流程中，做出了有價值的成果。
身為軟體工程師，我們需要藉由 AI 來組合。
以 WeaMind 為例，我有一個反覆切換地點查天氣的困擾，也有後端開發經驗，但當時沒有做過 LINE Bot。透過 AI 協助探索 LINE SDK，我就做出了一個符合自己需求的工具。
結語
這是「人類的時代」第二篇。
第一篇講的是我如何放下軟體工程師的傲慢，漸漸接納 AI 普及後任何人都能用 AI 開發這件事。
而這篇講的是我怎麼用 AI、我怎麼看待 AI。
回頭看一年前的分享，有改變的部分，但 70 分主義對我來說，並沒有太大變動。
其實，我也常常懷疑自己「是否還不夠了解 AI」、「是否還不夠善用 AI 以至於被舊思考模式限制了」。我並非自信滿滿。
但，哪怕是抱持著這些懷疑，我依舊相信，AI 不是答案，人才是。
這是人類的時代。