Re: [心得] AI Coding的目標:從單純寫Code到完成想法已刪文

看板Soft_Job (軟體人)作者giorno78 (天晴)時間1天前 (2026/05/04 20:18)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串1/1

首先，我必須要說，你搞錯了。照你的說法，軟體是由「人類規劃，AI 代工」的。你將 AI 視為一台速度極快的打字機，認為軟體是從無到有「寫」出來的。但事實上，軟體的本質並非被創造，而是被「發現」。米開朗基羅（Michelangelo）曾說過一句至理名言：「Every block of stone has a statue inside it and it is the task of the sculptor to discover it.」（每塊石頭裡都有一尊雕像，雕塑家的任務就是去把它敲出來。）這句話不僅是雕塑的最高境界，更是現代 AI 生成技術的核心底層邏輯。我們看看當今主導圖像生成的 Stable Diffusion 技術，它的運作原理是什麼？是從一張充滿隨機雜訊的畫布開始，透過 AI 一步一步地「去噪（Denoising）」，將不符合提示詞（Prompt）的雜訊剔除，最終「浮現」出那張完美的圖像。 AI 不是在畫畫，AI 是在充滿無限可能的像素雜訊中，把那張本來就存在的完美照片給「雕刻」出來。如果圖像生成是如此，軟體工程為何例外？請仔細深思這個事實：在每一台電腦的硬碟與記憶體的二進制排列組合中，早就已經存在著無數個「完美的軟體」。無論是一個無懈可擊的影音編輯軟體，還是一個顛覆世界的作業系統，它們的原始碼早已潛伏在你硬碟中的 0 與 1 無限矩陣裡，宛如藏在巨石中的大衛像。我們根本不需要「寫」程式，我們只需要把「不是這套完美系統的程式碼」給敲掉。這就是人類與 AI 合作的終極型態。在這過程中，甚至不需要你去規劃，因為你是人，人所規劃出來的軟體絕對不是完美的你只需要去感受，就像感受神性一樣去感受品味，讓 AI 剝去你硬碟中覆蓋那完美軟體的 0 與 1。在你感受變強烈的時候，告訴 AI 繼續通往直前。在覺得變弱的時候，叫 AI 試著其它方向看看。雖然過程中 SDD, TDD, 與 harness 都不可少，但最重要的還是你的感受。 ※ 引述《gigayaya (gigayaya)》之銘言： : [前言] : 花了好多時間終於努力在連假打完這篇文，大約有4500字，預估閱讀時間約30分鐘 : 原本有想說要不要拆成多篇，後來為了一致性決定還是放在一篇文章內，不好意思XD : 每次想說還可以再拖一下的時候就發現有新資訊出來在更新我的觀念，覺得再不發出來一 : 直放在我的電腦內我會永遠都發不出來XD : —正文— : [序] : 自從工程師們發現AI可以很好地幫助工程師們coding後，工程師們便開始了一系列的『使 : 用AI來開發』的技術探索。 : 從Prompt engineering開始研究如何設計prompt而得到品質更高的code。到發現光有 : prompt不夠，於是開始Context engineering的研究如何將AI需要的資訊在對的時機提供 : 給AI。到最近的 Harness engineering，工程師意識到讓 AI 全速衝刺反而容易失敗，沒 : 有防護措施的高速行駛容易因為一小點的偏差而將錯誤無限放大。於是開始為 AI 加上工 : 具、規則、檢查...等等，讓它能跑得更久、更穩，從一次性的代碼生成器，變成能執行 : 長期複雜任務的 agent。 : 隨著每次技術以及模型底層能力的迭代，工程師們deliver result的速度越來越快，品質 : 越來越高，但我相信不少工程師們心中應該都冒出同一個疑問： : 我們一直迭代『使用AI開發程式』技術的終點是什麼？ : 在最近幾個月閱讀許多資訊以及自己的實際經驗中我得出一個對於這件事情的答案，想藉 : 由這篇文章和大家分享。 : 如果你對於這件事情的終點沒有想像的話，或許你可以參考看看。如果你心目中的終點和 : 我不一樣的話，也歡迎分享你的想法多互相討論，讓我們更往前進一步。 : 最後，因為這裡是Soft_job版，所以我討論的前提都是在software development這個非常 : 局限的框架底下，希望大家讀文章的時候不要無限上升到人類與AI的方方面面上XD : — : [我們用AI來開發程式的最終目標是什麼？] : 我覺得我們之所以要用這麼多的AI工程技巧在開發程式上，最終目的是為了要：『設法降 : 低從想法到產品落地之間的成本』 : 想像未來的一個場景： : 你是Meta Messenger團隊的一員，有一天下午你躺在沙發上對這個產品有一個新的想法： : 『在一個chat中的textfield左邊的+號裡面有一個新的白板icon，點開會打開一個小白板 : ，使用者可以在小白板上用筆跡畫一張圖並且送出』。於是你拿出你的手機，在Jira網頁 : 上開一個新的ticket，內容是描述你對這個新功能的想法以及規格。開完後你發現某個 : AI bot已經pick這張ticket開始實作。三小時後你收到一個PR request請你驗收這個功能 : 的實作，你review了一下看到所有test都pass所以按下了approve按鈕，15分鐘後世界上 : 所有的使用者的Messenger都有這個白板功能了。 : 假設這件事情未來真的會發生，那會怎麼發生？我們目前距離那裡還差多遠？ : — : [為什麼我們想要達成最終目標？] : 自從2025年AI coding的能力提升到開始可以應用在產品級生產環境之後，我們迎來了『 : coding民主化』的時代。意思是『AI能力進化到任何一般人都可以很簡單地使用AI生產出 : code以及program來完成他們的需求』 : 這個能力在以前對於『一般人』來說是一個很有技術門檻的事情，通常來說你需要去上個 : 課，不論是大學四年本科的學習或是資策會的半年衝刺班甚至是上youtube看一段教學影 : 片，對一般人來說『coding一個程式去做一件事情』都是要花成本去學習的任務 : 但現在隨著AI模型的能力上升以及工具的普及，任何人都可以下載Claude Code，開啟一 : 個session，對著AI使用自然語言跟AI描述你的需求，AI就會生產一段可以完成這個任務 : 的code給你。 : 這代表著未來『code/程式』將會到處都是，任何人不論是會計師還是律師還是ooxx，任 : 何有電腦的人他都可以自己產生他自己需要的程式，就像智慧型手機在現在幾乎人手一機 : 一樣非常普遍而不是稀缺資源。 : 那在這個『任何人都可以生產程式』的情況下『什麼程式』才有真正的稀缺價值呢？我覺 : 得是『擁有更好更能滿足使用者』的程式會變得更有價值。 : 例如：當市面上有一大堆相同功能的記帳軟體之後，一個有真正創新且獨特使用者品味的 : 程式將會更脫穎而出，因為人們用了許多平庸的程式之後會更加能夠體會『好』的東西是 : 為什麼『好』 : 但是因為生產程式碼很快，假設今天大家的程式都是N，你想到了一個很好的新功能將你 : 的程式往前推進到N+1取得領先位置，過了10天後你的對手也跟進新功能變為N+1，大家又 : 回到相同的起點你的領先優勢只維持10天。你必須在那10天對手還沒追上你時想出下一個 : 新功能，在對手N+1追上你的時候趕快推出N+2保持更好的產品狀態繼續取得領先，這樣你 : 才能在這市場中一直佔據領先地位，最後取得商業上的成功。 : 所以在我的想像中，未來的軟體領域比拼的是『想法/idea』的競爭。當每間公司每個app : 都有能力做到同樣的功能擁有同一個起跑線的時候，想出下一個『使用者更想要的功能』 : 的那個app就可以脫穎而出 : （當然品質的要求沒有下降，還是跟目前一樣甚至更高） : 於是為了達成這個目標，我們軟體工程師在公司中的任務就是：『打造出能夠越快將想法 : 遞交給使用者的程式及架構』。這個目標的scope已經不是只有傳統軟體工程的範圍了， : 借助AI達成這個目標已經是一個必備項目了。所以做為軟體工程師你除了熟練原本的code : 架構外也要熟練/了解各種AI工程技巧來幫助你達成目標 : 現在『比拼idea』的方式是：比誰更快把idea做出來 : 未來『比拼idea』的方式是：比誰更快把『更好』的idea做出來 : —- : [如何達成這個目標？] : 首先我想我們應該都有一個共識就是AI產出code的速度比人類手敲鍵盤快非常多，所以想 : 要快速產出大量程式碼的最好方式就是指揮AI去寫，但是在現實中有很多問題需要克服： : A. 你下的prompt是否足夠準確讓AI產出你真正想要的東西(prompt engineering) : B. 你必須要給予AI足夠的背景知識去完成這個任務(context engineering) : C. 你必須確保AI產出的code品質被驗證滿足標準(harness engineering) : … etc. : 其中還有許多困難，但簡單來說就是將現在的『工程師完成一個新功能』這件事情在「滿 : 足標準」的前提下：『快速化』、『自動化』 : 將原本可能一個sprint(2 weeks)才能完成的任務在幾小時內完成 : 或許未來的codebase中可能有50%或是更高比例的file是給AI工程用的而不是產品本身 : 另外這件事情不只是模型能力提升或是AI使用技巧的迭代就可以簡單達成的，你還需要原 : 本軟體工程師的經驗以及能力，將整個codebase進行一次全面的轉型 : 例如： : A.要讓你的application可以快速地新增功能並且不破壞其他原本舊有的功能，你的架構 : 在模組化以及抽象化的取捨會更重要 : B. 要能夠隨時deliver新功能給使用者的一種方式是藉由熱更新，但能夠熱更新在設計產 : 品架構之初就必須考慮設計好否則後期大改架構的成本很高 : C. 實作code的時候很常遇到trade-off的問題，像是兩個選擇都可以但沒有哪一個一定比 : 較好的情況。這時候你必須做出決定給出AI指引某一條路並且你知道為什麼這是對產品比 : 較好的選擇 : … etc. : A和B兩點背後都可以轉換成類似design pattern的問題，而我們都知道這類問題通常都沒 : 有一個永遠的最佳答案，每個專案每個產品在乎的事情都不一樣，只有根據你們公司策略 : 、領導決策、產品定位、團隊規模、系統效能...等等才能選出最適合的答案。而這也是 : 軟體工程師體現價值的地方。 : 但其實你也可以說一旦我們對於最終目標有共識大家都去追逐這個目標之後，AI就可以自 : 動對所有的application產生符合這個目標的最佳code。但這邊我有一個理論是當大家都 : 最佳化後就代表大家也都同樣平凡，到那時候就會有一個人類從無到有想出下一個新目標 : 做出差異化來提高價值，於是我們永遠都會有下一個目標可以追逐 : 我覺得在目前的現實世界中，Claude Code是最接近這個例子的program : Claude Code可以一天迭代1,2個新版本遞交新功能，搶佔最新的技術前沿，使得後面的追 : 趕者追得很辛苦不容易趕上，進而維持Claude Code在CLI工具上的領先地位 : 而Claude Code也可以藉由頻繁的更新迭代收集更多最新的使用者數據，來讓他們統計使 : 用者數據來決定下一次版本迭代的目標，讓整個飛輪高速地旋轉起來 : — : [測試/驗證的重要性] : 在這個最終目標的情境下，目前如果我們想要更快的遞交新想法，整個瓶頸會卡在測試這 : 一個步驟。 : 因為(在不透過人類去使用的前提下)我們是通過測試去觀測我們產品，換句話說，測試的 : 品質會大大地影響我們如何理解我們的產品以及品質。 : 例如：我們的產品是一個簡單計算機app，結果我們的測試一直都沒有『驗證加號＋』的 : 運算邏輯，那這樣子就算我們能夠大量快速地deliver許多新功能並且每次所有test都綠 : 燈pass又有什麼意義呢？ : 所以，在未來的時代我覺得『測試』以及『驗證』的重要性可能會越來越重要，並且這是 : 之後每個不同的公司不同的產品不同的team出現差異化的地方，之後的測試驗收手段可能 : 會被視為重要資產而被高度保護，並且每個不同domain的測試方法會越來越專業化複雜度 : 越來越高。 : 就像現在大家會看到許多公司都會分享他們是如何做出最新的產品以及如何使用最新的技 : 巧，但是我從2023開始幾乎沒看到有人分享更高級的測試驗收工程技巧。我們的產品級測 : 試驗證手法自從playwright mcp後就沒有什麼工程技巧上的重大突破了，如果要達成夢想 : 中的最終目標我感覺現在『測試』的速度落後開發的速度很多。 : 我記得幾年前我看過一個例子： : 一間公司分享他們如何運用prompt engineering做出一個超級智慧的客服機器人並且顧客 : 滿意度達到9成多。他們大方分享他們最後使用的1000多行的強大prompt出來，但是那份 : prompt高度客製化，如果你要使用他們的工程經驗來實作你自己的prompt在你的產品上就 : 會發現他們在生產迭代prompt時的『測試驗收』這一步驟輕描淡寫的用一句： : 『我們每次迭代後會用我們準備好的測試集來評分』來描述卻沒有進一步的解釋，但這一 : 步才是整個工程的關鍵。 : 如何準備你的測試集？需要多少筆資料才夠？需要收集多少錯誤處理的情況？如何評分？ : 如何決定迭代策略？沒有解決這些問題的話就算你手上有那份1000行的精美prompt也沒 : 辦法複製出同樣高品質的客服機器人在你的domain上。 : 如果你曾經『完全用AI』去生產你們產品『全部的測試』，你就會發現目前AI在這部分完 : 全不行，他常常產出一些莫名其妙的test case或是不存在的scenario（因為transformer : 天生的機制就是會一直接話下去），需要人類去介入做review。在我看來我們在『測試』 : 這個領域還需要許多工程技巧的進步去追上生產程式碼進步的速度。 : 當然你也可以主張最後這個部分隨著模型能力提升後AI也可以取代/超越人類，但是我也 : 想提一個我一直認為的觀點： : 只要是給人使用的產品，那最終只有人類可以定義它的價值，以及被產品滿足 : 這部分我覺得是AI無法取代的 : — : [未來什麼事情是重要的？] : 首先，我覺得CS知識本身還是很重要，因為最終AI寫出的code組成的program還是奠基在 : computer science上，所以為了達成前面提到的最終目標，紮實的CS功力是不可缺的。 : AI工程技巧也同樣重要，就像前面所說的，如果你還是只能用手敲鍵盤寫code的話，那你 : 會追不上未來產品需要迭代的速度。所以『使用AI的知識以及使用AI工程技巧產生code』 : 也是軟體工程師的必備技能 : 除此之外最近也有個詞被反覆提及：品味。 : 在coding這個level來說的話，品味指的是：你知道當下應該採取什麼是最好的選擇、你知 : 道為什麼採取A策略而不是B策略可以更好地達成你的目標...等等，簡單來說是要有能判斷 : code好壞的能力（這實在好難用文字說明...） : End : — : [推薦閱讀的參考資料] : 1.程式碼全讓 AI 寫，工程師只看測試就夠了嗎？ : https://www.youtube.com/watch?v=_yKtlczRFKk

: 這是一個更極端的策略：黑箱開發。意思是把你的codebase當作一個黑箱，只專注在他 : 能提供什麼功能上，把codebase當作拋棄式的東西。當你覺得繼續使用現有的codebase成 : 本太高的話就可以直接拋棄他再重新產生一個。 : 雖然我不推崇將codebase當作黑箱，我覺得工程師還是要對codebase有一定的掌握度，但 : 是這個影片所敘述的開發流程還是有許多值得參考的地方。 : 2."Software Fundamentals Matter More Than Ever" — Matt Pocock : https://www.youtube.com/watch?v=v4F1gFy-hqg

: 這個影片中主講者分享了軟體工程跟AI工程要如何結合，我覺得從12:30開始關於『Good : Codebase Are Easy To Test』這部分非常有啟發性 : 3.How Anthropic’s product team moves faster than anyone else | Cat Wu (Head : of Product, Claude Code) : https://www.youtube.com/watch?v=PplmzlgE0kg

: 這應該是最近最熱門的影片之一了，Claude Code的Head of Product Cat Wu的一個訪談 : 影片。其中談到對於未來軟體的想像以及產品團隊如何運作，推薦完整看完。 : 4.Andrej Karpathy: From Vibe Coding to Agentic Engineering : https://www.youtube.com/watch?v=96jN2OCOfLs

: 最近最熱門的影片之二，我覺得整個演講對於過去現在以及未來的軟體工程都有一個清晰 : 的描述，推薦完整看完。 : 5.【漫士】AI时代，我们真的会失业吗？怎么办？ : https://www.youtube.com/watch?v=vOIkUSYfUMo

: 這部影片的作者從數學系博士的角度出發解釋了目前AI的原理以及局限性，如果你不是那 : 麼清楚現在的AI底層是什麼的話推薦看看，對於未來的描述也蠻有啟發性的（尤其是創意 : 的部分）。 : --- : 最後謝謝你看到最後 :D -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.228.92.214 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1777897102.A.031.html