極簡 AI Coding 心法：從第一性原理出發，不靠框架也能寫好程式
講者：陳宜昌 YC | MediaTek Research | Senior Technology Manager
題目：你真的需要框架嗎？極簡流 AI Coding 可能更適合開發者
YC 分享了自己在實務中使用 AI Coding 的經驗跟心法，聽完之後我覺得很有共鳴，因為他講的很多踩坑經歷我自己也經歷過，這篇文章是根據他的演講內容整理改寫的，希望能把他的觀點更完整地傳達出來。
AI Coding 是個人能力的放大器
YC 開場就點出一個重要觀點：AI Coding 是「個人能力的放大器」。
你有多少能力，AI 就能幫你放大多少。雖然現在很多非開發者也能靠 AI 工具做出以前做不到的東西，但他觀察下來，這些成果大多還是停留在腳本跟個人自動化的層級。回到整個軟體產業來看，我們還是需要具備開發者能力的人來跟 AI 共同協作。
他用了一個公式來說明：
開發能力 ＝ 理解決策與規劃能力 × AI 協作能力 × AI 本身的能力
前兩個是你可以主動提升的，理解、決策、規劃這些是資深工程師的核心能力；而 AI 協作能力，就是他這場演講主要想帶給大家的。
有趣的是，他也提到這對新手來說其實是個逆襲的機會，因為有些資深開發者不習慣甚至排斥 AI Coding，這時候如果你能把 AI 協作能力點滿，反而有機會彎道超車。
現有框架的三個問題
YC 提到了幾個目前主流的 AI Coding Framework，像是 GitHub 的 Spec-Kit 和 BMAD-Method。Spec-Kit 主張 spec-driven 開發流程，先把規格文件化再進入實作；BMAD-Method 則是用多個 AI Agent（AI PM、AI 架構師）來互相討論規劃。
他自己用了一段時間之後，歸納出三個批評：
第一，文件量太多。 這些框架產生的文件常常多到你根本讀不完，你跟專案之間就產生了認知上的 gap。更慘的是，程式碼在推進、文件卻沒同步更新，最後你的文件海裡一堆過時的東西，根本不知道哪些該留哪些該刪。
第二，過度 top-down。 這些框架都很鼓勵你做完整的規劃再一次執行，但軟體工程有很多任務其實需要 bottom-up 的探索。
他舉了自己開發 voicebot（語音聊天機器人）的例子，那個架構很複雜，牽涉多個 server 之間的連線跟即時 streaming。他一開始套用 Spec-Kit 的方法，團隊花了很多時間寫 spec，寫完之後一口氣產出程式碼——結果跑不動。修了兩三天之後還是動不了，於是把程式碼全部刪掉，把 spec 寫到極度細緻，再重新產出——還是不 work。
折騰了一個月，他做了一個決定：放棄框架，改用 bottom-up 的方式，一個一個元件建起來再組合。結果一兩天就跑通了。
第三，文件的規範不如程式碼扎實。 文件的主觀性很高，同一件事可以這樣寫也可以那樣寫，中間的模糊空間很大。但程式碼是客觀嚴格的，它可以被執行、被驗證、即時給你錯誤回饋，但文件做不到這些。
他強調這不是說文件不重要，因為跟 AI 協作你不靠文件是沒辦法做良好溝通的，但文件應該是輔助，程式碼才是主體。
你在用的不是 Chatbot，是 AI Agent
YC 點出一個很多人搞混的概念：為什麼用 ChatGPT 聊天寫程式效果差，但用 Cursor、Copilot 這類 AI Coding 工具卻好很多？
答案是 AI Coding 的本質是跟一個 Coding Agent 協作開發，而不是跟 Chatbot 聊天。
Chatbot 只針對你當下的問題做回答，但 AI Agent 有幾個關鍵特性：
高自主性：它可以針對你的問題去做各種任務，不只是回答問題
工具使用：它能呼叫外部工具，上網搜尋、搜尋檔案、下 terminal 命令
任務分解：把複雜任務拆成小任務去解決
ReAct 循環：Reasoning → Acting → Observing，不斷循環嘗試直到解決問題
這也是為什麼用 Chatbot 必須小心翼翼設計 prompt，但用 AI Agent 你可以很隨意地像聊天一樣就把任務完成。
他也比較了 Agent 跟 RAG 的差異，RAG 做的是相似度搜尋跟匹配，但 Agent 做的是像人類一樣思考、使用工具、完成任務。現在業界主流也在從匹配機制往 Agent 系統靠攏。
從第一性原理導出 AI Coding 心法
接下來是整場演講最核心的部分。YC 引用了 Andrej Karpathy 提出的 Context Engineering 概念：語言模型有固定的短期記憶（context window），我們要做的就是在這個有限的空間裡放入高品質的資訊，就這樣而已。
他從物理系的背景出發，主張用第一性原理，也就是那些長期不會改變的事實，並依此來建構整個 AI Coding 的方法論：
原理一：AI Coding 就是以 AI Agent 來合作寫程式，關鍵是做好 Context Engineering。
原理二：能產生服務的只有程式碼跟部署，文件不能直接產生價值。
原理三：專案中含有越多可以被驗證的東西，專案就越健康。驗證最好自動化，不行的話至少要讓人類可以驗證。
從這三個原理，他導出了七條 Best Practice。
七條極簡 AI Coding Best Practice
1. 不要讓自己 Out of Understanding
你是整個專案的負責人，你必須了解 AI Agent 在做什麼。不要只關注結果而忽略過程。大量的文件、不相干的程式碼都會造成認知上的剝離。
好的做法是：讓 AI 幫你做 summary、跟它做 Q&A，確保你理解專案的狀態。然後用簡潔的方式把理解寫成少量高品質的文件。
2. 給方向，但不要做微觀管理
兩個極端都不好。太抽象（「幫我做一個賣酒的購物網站」）AI 不知道你要什麼；太具體（「在第幾行加上一個判斷式」）那你自己寫就好了。
好的做法是：執行前先用 BDD 或架構圖勾勒簡單的規格，讓 AI 知道你想做什麼。然後在過程中跟 AI 進行多輪討論。YC 自己很喜歡的技巧是在指令後面加上「你有什麼不懂請詢問我」，讓 AI 不斷提問直到雙方同步，再開始實作。
用他的話來說：「先同步再領導。跟 AI 協作其實就是一種領導力的展現。」
3. 減少對 AI Agent 的干擾
過多的文檔、沒有結構化的程式碼、重複的程式碼、失效的文檔——這些都會讓 AI Agent 很 confused，不知道該聽誰的。
好的做法是：讓文檔跟程式碼保持一致。過時的文檔丟到 deprecated 資料夾裡，不要讓 AI Agent 太容易看到。只留下當下有用的東西。
4. 盡量避免 AI Agent 理解整個程式碼
如果你問一個問題，AI Agent 需要讀完整個專案的所有檔案才能回答，那代表你的架構有問題。好的架構讓 AI Agent 只需要理解局部就能開始動作。
具體做法有三個面向：
文檔化：寫 docstring，在程式碼開頭寫註解，讓 AI 看到開頭就知道後面在幹嘛
架構化：模組化設計、單一職責原理、Clean Architecture
命名：做有意義的檔案與變數命名（有 AI 幫忙，命名已經不是什麼痛苦的事了）
5. 增加 Coding Agent 的自主性
讓 AI Agent 在可執行的工作環境裡直接跑程式，如果程式沒辦法即時返回資訊，就把 log 倒出來給 AI 做後續處理。
最重要的是用 TDD（測試驅動開發）讓測試成為 AI Agent 的自動反饋。
TDD 的循環是可以概括成：
紅燈（先寫單元測試，此時主程式還沒寫所以一定會 fail）
綠燈（實作主程式，讓測試通過）
Refactor（重構程式碼但保持測試通過）
YC 的做法是，跟 AI 達成共識之後直接說「請用 TDD 來實作」，AI 就會自己走這個循環，產出的程式碼會非常穩固。
6. 增加 Human-in-the-Loop 頻率
一次不要做太多事情，每次做小小的原子化操作，完成一個小功能之後先 review，沒問題再繼續。善用 Git 把每個 checkpoint 存起來，就像玩遊戲解完一個任務就存檔，做壞了可以直接倒車回去。
7. 使用 Template 來規範寫作方式
他舉了自己做簡報的例子，他把想講的內容文檔化，用 storyboard template 讓 AI 依照模板填寫每一頁 slide 的內容，然後再自動轉換成正式簡報。
甚至他覺得投影筆太貴了，靈機一動用 AI Coding 花一個晚上做了一個手機投影筆的 app，能換頁、能跳頁、能看到簡報畫面、還有計時器，以前可能要花一個禮拜的工作，一個晚上就搞定了。
心法的精髓
YC 最後的總結是：AI Coding 就是跟 AI Agent 協作寫程式，關鍵在 Context Engineering，也就是讓好的結構跟資料出現在 AI 看得到的地方。
現有的框架有些已經脫離了第一性原理，產生過多的文件，嚴重污染 context。與其記住一堆框架的流程，不如理解背後的「為什麼」，然後靈活運用。
用他的話來收尾：「此時無招勝有招，最好的方法就是你的應變方法，然後跟著 AI 技術一起成長。」
本文根據 YC（聯發科 AI 專案工程師）的演講內容整理改寫。感謝 YC 提供逐字稿授權。
作者：Chi