活動開場

今天很榮幸邀請保哥來分享 AI 跟 Spec-Driven Development。我相信大家如果用 AI 寫 code 的話，這是最近的顯學。但是怎麼使用，然後各種心法，我覺得都可以互相交流。

我是布丁，我是 Happy Design 社群的 Organizer，以及我同時是 MeetAndy AI 這家公司的共同創辦人。Happy Design 是一個從 2005 年開始的 Community，今天應該還是有一些新朋友。

這個名字取不好，這個 AI 寫程式名字取不好，然後將來要改就很困難。所以我一開始是 Designer，所以社群名字叫 Happy Designer。然後後來就不當 Designer 了，然後社群名字取了就很難改，所以就一直叫到現在這樣。

參加的人可能是工程師、設計師、Founder 各種不同的夥伴，期待是這邊都有一個場合可以讓大家更好的交流。

我們今年非常感謝 AIC 跟美國在臺協會、美國創新中心跟我們合辦的線上活動，以及很感謝泰妤軟體贊助我們今年的活動，提供我們各種的錄影、線上的 YouTube 影片的產製等等的軟體。

活動錄影說明

像今天我有跟保哥討論過，如果沒有問題的話，我們活動結束後錄影檔應該會立即公開在 YouTube 上面，讓大家更多人可以看得到。然後保哥就說，你為什麼只開 100 人？我說這個限額是殘酷的。我覺得有限額的時候，大家會比較容易更好的做交流。

今天很有趣，因為我們通常來的人，比方說工程師、PM、Founder、設計師。當然因為今天是認真寫 code 的分享，所以工程師占了將近 60%。我想這是跟之前比較不一樣的狀況。當然還有 Product 的人，然後你知道我們活動的 12%、13% 是 Founder。

活動流程介紹

今天的話，主要就是保哥會分享大概 30 到 40 分鐘的 Spec-Driven Development，接著的話，我們是 Q&A 的討論。Slido 已經放在聊天群組這邊，大家可以先提問，然後這個我們到時候可以 Vote，然後做討論。

我們的活動很多人都已經參加過，但是再跟大家講一下，感謝保哥以及每個講者來精心的準備。所以當他來開場的時候，記得大家一定要鼓掌歡呼。

互動說明

如果講者有 Live Demo，如果成功的話，可以用放煙火、愛心等等的方法來鼓勵講者。Live Demo 是非常困難的事情，我相信所有人可能都有一些經驗，所以如果失敗的時候，記得也是鼓掌，這是非常不容易的事。

因為我們一直都有在徵求講者，如果你來做我們的 Happy Together 活動的講者的時候，最重要的事情是你要來分享說，如果我三個月前知道這件事情就好了，然後我就可以幫助別人，或者說有什麼樣的方法可以幫我省時間，然後可以更好協助其他人。

但是我們今天講者保哥就是身經百戰，所以這些東西對他來說都不重要，都是虛名。剛剛我們已經播了，連自己的開場的 Solo 都已經做好歌單。

下次活動預告

另外的話是我們 11 月 7 號會有下一場活動，活動通知會再發給大家，再歡迎大家報名。保哥接下來就直接交給你囉。

Spec-Driven Development 分享開始

好，我 Share 螢幕你看到嗎？有，這邊有。好，OK，那我就開始今天簡短的分享。

大家好，我是 Wiw 保哥。那今天來跟大家分享一下關於我在 SDD 方面的一些研究。那它是規格驅動開發，我把它定位成是一個 AI 時代的軟體開發新典範，那非常有趣。

那今天三十分鐘大概沒辦法 live demo 啦，但是我有截一些圖，讓大家感受一下，導入 SDD 之後大概的感覺。

個人簡介

這個是我的個人的簡介。稍等一下，我把我的那個 LINE 也關掉一下。就是說這是我的 Blog，然後我有開很多課在這裡，然後我的粉絲團，粉絲專頁，有興趣可以 follow 一下。

SDD 的由來

那一開始我想先跟大家講一下，這個 SDD 的由來到底是為了什麼，就是陳世馬為王的困境呢？講的是我們長久以來，就是嘗試過各種方法。因為我們知道做中大型的專案，一定要寫規格，因為不是隨有一個人做嘛。就是還是很多案子不是一條龍的方式在實作。

所以像我們公司就 5~10 個人，15~20 個人都有。所以大型專案如果要讓整個團隊很順利的往前進，那規格就真的非常重要。

規格與程式碼的脫節問題

但我們都知道就是，最終最終規格跟我們實際上在寫的那些 code，最終都會脫節。而且這個脫節的問題非常嚴重，而且還真的解決不了。就是所有人都試過了，這件事就是解決不了。

那我們大部分的情況就是，專案一開頭對不對，很多人要一起做，我們要寫第一份規格。但是說實在的，沒有人可以把規格一次寫對，這太困難了。而且有誰是寫規格的專業呢？老實說不是 user 對吧，也不是工程師對吧，是 PM 嗎？好像也不是。

那到底誰是寫規格的專家呢？那你可能會說寫規格，那不就是應該懂需求的來寫嗎？是沒錯。但是你的東西最終是要交給製作團隊打造出來，對不對。所以如果你沒有足夠的專業知識，或者是相關領域的知識融合在一起，這份規格就是不可能寫完整，它是不可能有完美的狀況。

第一份規格的挑戰

所以一個很務實的情況就是說，我們一般在做案子的時候，會有第一份規格出來，不管它完不完美，但這就是一個唯一我們可以參考的真相，對不對，一開頭。

那我們開始做了之後呢，才發現缺東缺西的很多東西做不出來，這個規格的價值感就會大幅的降低 ok。那到最後就變成是，好我們透過大量的互動，開會去把這份規格給完善。

但很多時候呢，就是大家會各做各的，不見得會去完善這一份，所謂的這個我們奉為這個聖經，或者是一個憲法的這樣的一個規格，規格書。而是大家就是在修修改改過程中，把一個專案給做完 ok。

規格文件與程式碼不一致

所以通常我們做到最後面，就沒有人會去看最開始的那份規格，雖然它有參考的價值，但是在很多實作細節，基本上跟規格脫節的情況之下，這個規格就只能變成是一個大目標。

我可以那個，傑哥叫我幫他錄一個這樣子 ok。所以我們常常規格文件跟程式碼不一致，然後長久下來，維護成本也會大幅增加。所以這是一個很很很很嚴重的問題，但是說實在沒有什麼人可以解決。

所以需求在變更的時候，我們經常就是直接去改扣，ok。然後改扣的那個人，並不會跟懂需求的這個人講，他改了什麼，他只會說，你測測看我改好了，對吧。

各位給我一個表情，如果你覺得好笑，給我一個笑臉，因為業界就是這樣。所以這個技術在基本上就是會不斷的累積，這樣瞭解嗎？好，所以這是個困境。

SDD 的轉變

所以 SDD 的出現就變成是，他設法做了一些轉變。以前，這個程式碼是唯一的真相，對吧，single source of truth，對不對。這個唯一真相是程式碼，因為只有程式碼不會騙人，規格還會騙人文件會騙人，但是程式碼不會嘛，對不對。

這大家都知道事實，如果你是工程師，你也相信這個真理，是吧。然後但是 SDD 開發呢，卻把這整件事顛倒過來。我覺得也不能叫顛倒，這才是正道，你懂嗎？

規格作為真相來源

所以規格本來就是真相的來源，而且這個規格理論上，它是一個共通的語言，所有人都看得懂，設計師也看得懂，工程師也看得懂，PM 也看得懂，所有人都看得懂的一份，用自然語言描述的規格，本來就是整個案子的核心。

只是沒有人有辦法很好的用一個更好的工具...

AI 時代的 SDD

而且只要你改完規格程式碼，都可以自動生成。這整件事如果可以全自動，來各位給我一個表情，你覺得這是一個什麼樣的世界？對吧？

如果這整件事都這麼的完美，老實說...這個導入的過程中，老實說我們也才導入幾個禮拜。我們公司也才導入幾個禮拜，但是成效已經非常卓越了。

AI 技術的成熟

所以現在的 AI 還包括前幾天才推出的 Cloud 4.5 的 SONNET，真的是寫 code 跟寫文件的鐵人，就真的很強。那 GPT-5 的 Codec 是用來寫 code 的，但是 GPT-5 本身的 reasoning level 如果設定很 high 的話，它其實是一個非常好的 brainstorming 跟 spec 的 generator。

就是很棒，現在就是一個相當完美的狀態。不是說不會出錯，並不是這麼說，它也不是一個靈丹。但是如果它可以大幅的，例如說 80% 解決我們實務上面臨的這些問題，老實說這就是一個非常非常值得投資的技術。

SDD 的定義

所以到底什麼是 SDD 呢？它講的就是我們用規格來主導一切，然後設法自動化。那為什麼以前不做這件事呢？我就說以前沒有 AI，OK？

以前沒有那麼強大的 AI 技術，這種深層式 AI 技術，可以幫我們去理解自然語言，以前很難做到，而且效果不好。但這幾年，這兩三年來，大家都是有目共睹的，它真的可以講人話，而且它還可以推理。

雖然它不是真的那麼的到位，還是有一點點的幻覺，但是透過提示工程，透過我們對於 AI 的理解，我們可以把一些，至少簡單的話它都聽得懂，對吧？

複雜模糊的需求，人類都會有幻覺的，何況是 AI 呢？我都常講喔，這人類的幻覺其實比 AI 還嚴重。

AI 幻覺的看法

(觀眾留言) AI 不是有幻覺嗎？你不會怕嗎？我就覺得蠻有趣的，我們人一輩子從小到大，接受到上一代給的幻覺不知道有多少，各位不是都活得好好的嗎？

所以我們其實人類是不怕幻覺的，因為人類就是一個最大的幻覺來源。所以我一直都覺得，AI 已經很棒了，它可以幫我們解決很多問題，這就夠了。

我一點都不 care，也一點都不擔心任何幻覺的問題，因為人本來就可以自動正確化，AI 未來也可以，現在也可以，但是就是沒那麼強，所以過一兩年我覺得真的是不得了。

規格成為執行性資產

所以當我們的規格透過 AI 可以成為一個執行性的資產，什麼叫執行性？這個執行性資產的意思就是說，這份規格可以是一個直接生成後面所有步驟的真相來源。

我用自然語言描述完一個需求，它可以把後面的步驟全部自動化跑完，包括連 code 都生出來，包括連自動化測試都跑完，變成一個直接可以運作的系統。

那我等一下給你幾個時間好了，好不好？好，常常有這種意外。我覺得主持人應該可以關掉自動解麥的功能。

典範轉移

好，那這個演化規格取代手動程式碼更新，其實是一個典範轉移。老實說，我不認為大部分的工程師可以接受這件事情 OK。那原因是因為它實在是太創新了，創新到可能會 shock 到很多人。

但是如果你是 senior developer，或者是你在業界工作個五年、十年以上的，我覺得你會欣然接受這種新的型態，因為它並不會取代我們的工作，真的不會，我是覺得還蠻放心的。

它不會因為 AI 很強，強到工程師未來都失業，我覺得倒不至於。但是 junior 會失業，或者是找不到工作，這是肯定的，我必須說。

自動化流程的重要性

所以，未來我們有問題發生，基本上回頭改規格，然後透過自動化的程序。那你要知道，我們透過 CI/CD，或者是做這種自動化的 SDD 開發，最重要的就是它整個 flow，整個 process，必須要把這個 automation 的 percentage...

自動化測試的重要性

到了那個時代,到了那個時間點,我們的測試的覆蓋率也非常滿的時候,不得了耶各位,不得了。我們不是拿人去測試,OK?

就是這個過程中,系統跟軟體系統在發展的過程中,如果自動化測試涵蓋率可以從 80%、90% 到 100% 的時候,AI 真的可以自主作業,這整個系統是不需要人為護理的。

錯誤修復與規格維護

可以被實現,絕對是有可能的。那麼除錯及修復規格這件事情也是很重要,就是我們常常做一件事情都有一個意圖。

這些案子可能維護了十幾年。改版,通常就是一句話:「我只有 code,其他都沒有。」「你可能要看我們的舊 code 去翻寫。」

我們從 code 裡面其實是看不出意圖的,我只看得出邏輯。看不出意圖,我就很難做出百分之百正確的事情。人類去分析判斷也沒有辦法做正確。這個問題實在是解決不了。

有 code 真的是它的價值感沒有那麼高,雖然它是唯一的真相,但那是不得已的真相。因為沒有規格,那怎麼辦呢？

導入 SDD 的好處

所以如果你現在導入 SDD 的話,開始用規格來主導一切,然後讓程式碼變成自動生成,未來五年、十年後要改版,就變成是一個輕而易舉的事情。

來,給我一個表情,是不是很棒？至少給個讚吧！所以這就是 SDD 的真正由來。SDD 的導入之後,會造成最明顯的權力反轉。

因為以前大家都覺得程式碼是唯一真相,現在就變成是規格,所以整件事就會倒過來。程式碼盡量用 AI 生成,但是我們也知道有侷限性,它不太可能做到百分之百。

所以這個時候我們還是會人工介入,讓整個 SDD 的流程可以做到我們 workflow 的九成,那就已經是非常巨笑了。那麼你如果有九成的工作不用做,只做一成的工作的話,我想大家應該也是滿意的啦！我的想法是這樣,我不追求一百分。

規格的重要性

所以規格會變成我們一個非常重要的資產,然後規格也會不斷地迭代。我覺得規格迭代也是一個很有趣的事情,就是我們很多客戶也接受敏捷,然後我們公司敏捷也跑了很多年,至少十年以上。

規格迭代的挑戰

工程師最討厭迭代,尤其是規格迭代。為什麼呢？我好不容易照著這份規格設計出一個架構,結果做完才跟我講不是這樣,我要改我的架構,我要扣要重寫,我的 test code 要重寫。

那我當初就不要 TDD 就好了,為什麼要叫我寫那麼多？是不是這種感覺？對不對？所以其實大家心裡是痛恨規格迭代的,為什麼呢？

因為規格改了,我後面有一大堆工作要做,誰想要改規格？所以如果今天你是工程師,公司有個 PM 去面對客戶,你不用面對客戶,PM 回來跟你講說,不好意思,規格有一些改變,你不會給 PM 什麼好臉色,對吧？

那 PM 也很無辜啊,又不是他要改的。那工程師有時候就會在氣頭上就說,那還不是你沒有訪談出來才造成的,反正就是吵不完啦,就是這樣啦。

規格變更後的影響

所以到時候連 code 都不用寫的時候,改規格就不會有人抱怨啊,是吧？所有人專注於規格的更新跟迭代,想辦法把它做好。

然後工程師的任務不是寫 code,OK？是什麼呢？是把這份規格需要搭配的這些 AI 資源,包括所有的 prompt,對不對？包括所有的 rules,包括所有的里程架構,跟你要採用的這些技術,把它定義下來。

這是工程師才能做的事,OK？他不會沒工作,只是工作內容變了,OK？所以 SDD 的導入就是有這點差異,所以大家其實不會沒事做,而是工作變了。

你不會再感受到寫 code 的樂趣,OK？或者是痛苦,因為有些人覺得是好玩,有些人覺得不好玩。所以,但是你開始會感受不到寫 code 的快樂,但是你可以享受到快速打造一個軟體產品的樂趣。

所以,小,就是會有一點不一樣,OK？

SDD 工作流程

那我們基本上 SDD 的工作流程的第一步,就是從想法到規格。所以我們想法啟動一開始絕對是模糊的、不完整的,我們可以透過 AI 來幫我們補完整個想法,OK？

等一下我會做一些示範給你看,我有截一些圖啦,比較快來展示一下。AI 很重要,OK？它可以主動識別人想不到的點,OK？它可以補完缺漏跟邊界的情況,這很重要。

因為人想不到太多邊界的東西,你沒有那麼大量的腦力,你根本就比不過 AI,OK？然後 AI 可以反問你問題,OK？它還可以充當各個領域的專家,幫助你 critical thinking。

這我已經體驗過很久了,所以這真的很棒。我有很多卡關的一些 side project,卡了兩三年這種,我這幾個月全部都解掉了,那感覺真的是很棒,你知道嗎？

就是我不知道我錯在哪裡,但是我就寫不出來,然後我叫 AI 問我問題,竟然問到我都通了,這個感覺真的很棒。

因為這只有工程師比較有感受,我不知道其他領域的設計師有沒有這種感覺,有的話給個讚一下,因為我是真的感受特別深刻。

規格細緻化

接下來就是規格會越來越寫越細,因為你要知道,人類都是伸手牌,沒有人想自己寫東西。我自己寫部落格寫了 18 年,我知道寫文字是很累的一件事,寫規格自然也是。

而且如果你是 PM 負責寫規格,你就會知道一件事,PM 壓力很大,因為規格寫錯會被罵的。這個工程師,你背後如果一堆工程師或者是設計師,所有人都看著你規格辦事的時候,那個壓力真的很大。

所以我會覺得規格的細緻化這件事情,應該是大家一起進行,而不是一個人的責任。但是有很多時候企業的組織結構跟文化,就是不太支持這件事情,所以就會變得有點弔詭。

你知道,工程師不負責訂定規格這件事情,我也覺得很弔詭,因為很多事情明明只有工程師知道,卻要讓非工程師去想他要做什麼。

然後在軟體業界會區分什麼 SA、SD、PG、Testing,就分得很細,那都已經是二十幾年前流行的事情了。這幾年已經不太強調這件事,至少在我們公司不強調這件事。

我們公司根本沒有 SA 跟 SD 的區別。SA、SD 跟 PG 根本就是同一個概念,對我來講是一個人全部都要會做的事情。

只是如果你不會 SA,在我們公司至少還可以忍受這種狀況,就是我找一個會談,你比較不會講話,你會寫扣,我就讓一個能溝通的人去講。這還 OK,還可以接受,但是本質上你身為軟體工程師,這些能力本來你就都要學會。

這是我的想法,也許有人不同的想法。

PRD 產出

最後我們就可以產出一個比較結構化的 PRD,叫做 Product Requirement Description,去描述整個產品的需求。這是我們的第一步,第一步非常重要。我們會大量的透過 AI 來輔助人類完成這個工作。

那我截了一些圖,大家看一下。這是我用 SDD 在開發一個警制遊戲的過程所做的事情。第一件事呢,我就告訴他我的 PRD。

實際案例展示

輸入「幫我設計一個景緻遊戲」。各位瞭解意思嗎？瞭解的給個表情符號一下。我們對細節要求不同,如果我是專業軟體工程師,我要打造出來的是專業的、100% match user requirement 的一套軟體。

我寫的 PRD 必須要精細到每個細節,這是我的要求。對於大部分的 Vycoder,不會寫 Code 的 Vycoder,他對細節沒有要求,所以對他來講,他就是一句話就能做完的事情,做出來的東西是不是他要的,他也不知道。

他沒有要求,所以大家的水平是不太一樣的。想法、出發點其實是不一樣的。我們今天要走 SDD,這是專業工程師的 Vibe Coding,並不是給一般人的,所以還是有點不太一樣。

那我講的一般人,也並不是說你不是工程師就是一般人,這也不是我的意思喔。如果你在公司是做 PM 或是做企劃的,這份 PRD 很重要,你還是要了解客戶需求,你要做出精細的規格跟 PRD,你才有辦法做出真正客戶要的東西,對吧？或者是打造出你們公司自己要的產品。

AI 分析與規格生成

好,接下來 AI 就開始幫我分析這份規格,然後開始幫我寫一份規格書。我使用的框架是用 GitHub 的 SpecKit,這 SpecKit 有很多 template,這是很棒的 template,它就拿我的畫去 merge 它的 template,然後開始寫。

寫完之後它就說功能規格創建完成,是吧？然後它幫我建了一個分支,然後建了一個 spec,然後這個 spec 裡面就包含了我的 PRD 的所有內容,然後把 functional requirement...

Critical Thinking 問題

就是透過 Critical Thinking 的技巧,找出了五個需要澄清的問題,然後他一個一個問我。這真的很酷,我跟你講這真的很酷。

因為我們寫好的一份 PRD,我們也一定是看過才丟給他的,但是我們看不出問題,是吧？所以丟進去的時候,他幫我找到了五個問題,而且一次找五個,你可以一直問他,一直問。

他就反問你,初始版本要用哪一種,就是 AI 的這個表現要是哪一種難度,你只要回答 A B C D E 就可以了。他給你選項,他都幫你選好了,很棒。

然後你選完之後,你就打個 A,打個 A 之後,他就說,嗯好,你選了 A,然後他幫你把 Spec 更新。都不用我們去改喔,各位。

用魔法戰勝魔法,不要親手去改規格文件。你只要告訴他你的意圖就好了,這就是我所謂的意圖導向的開發。你告訴他你的意圖,然後他幫你把 Spec 更新。

然後他就問第二個問題,那我們就回答第二個問題,重新開始這個按鈕什麼時候該秀呢？是要永遠可見呢？還是結束後才能按？那我就選 A。那五個問題我都回答完之後,他就說,這五個問題都幫你釐清喔。

規格迭代流程

流程其實是需要迭代的,跟敏捷一樣、跟 Scrum 一樣,它其實是 SDD 的工作流程走完之後還會從頭開始。但是這個迭代的過程,慢慢的我們就是要去想辦法把它給自動化,那這個自動化就需要一些技巧了。

好,第二步呢就自動化,對吧？所以我們可以用 AI 去生成所謂的實作計劃 ok,實作計劃。那接下來呢,就是 AI 在動作,他根據我的 spec,開始產生所有的開發計劃 ok。

他分析我現在所有的內容,然後產生相應的研究報告 ok。data model 定義,咕我們的這個 domain model 有哪些啊,然後定義 contract,例如說如果你有 API。

遊戲案例展示

做這個...我不是拿那個警字遊戲當示範嗎？所以這邊有 Game State、Game logic,都是一份一份的文件、規格文件,有沒有看到？

然後電腦 AI 要用什麼樣的...咕...這個程度跟...跟這個等級,還有什麼演算法來跟人類對戰,有沒有？這些東西都是 AI 幫我寫好的,都不是我寫的,ok？

這...這只是...咕...這個開發計劃齊。然後開發計劃全部寫完之後呢,你就擁有了所有這些文件,研究、報告,OK？我們這個資料模型的設計,有沒有？

咕...有多少 Entity,這個工程師比較瞭解齊。然後...咕...這是執行過程我的截圖,讓大家感受一下齊,就是...咕...SDD 在執行的過程中,我們基本上都是讓 AI 在做事,ok？

然後它隨隨便便都可以寫幾百到上千行,重點是...幾乎不會出錯。我講的錯是...咕...就是很誇張的錯,你說它不理解我,寫出一個不是我要的,這不叫錯 ok？

這也不叫幻覺,因為你沒跟它講嘛,對不對？那再來呢,它就繼續跑,你看這個是...咕...喔!這個是...咕...這個...我們已經在實作了齁,實作跑完了,它連所有的 TDD 單元測試的程式碼,全部都幫我寫完,而且它會盡可能...咕...盡一切可能,把所有自動化的 Test Case 全部跑完 ok？

而且實作的過程跑...咕...產生了 1329 行 ok？而且常常都是上千行就是了齁。然後它會幫我...一次喔,就是...就是一個 Prong 下去之後它就幫我產生幾十個檔案,然後幾千行的 Code,然後包含所有 TDD 的 Test Case,不但寫完,還測完。

然後到最後這個是...最後的結果,Polish 的階段。這個 Polish 的階段呢,基本上就是所有核心模組都做完了,然後測試覆蓋率幾乎都是百分之百 ok？

因為這個是我給它的要求,ok？我...我要求它測試涵蓋率要百分之百,盡量。它可能做不到也沒關係,但是...咕...它都會幫我們盡量的做到。有些東西沒辦法測試嘛,各位瞭解嗎？

好,那...再往下,咕...這個是...專案完成了。咕...我跟你講,這從頭到尾...咕...大概...五...大概五個 Prong 吧。如果...這五個 Prong 如果再加上...嗯...他們一開始要反問我那五個關鍵問題,對不對？

再加五個吧,所以就是大概十個 Prong,可以把整個專案做完。各位,這什麼 Feel 啊？來,一樣,再給個表情符號,這什麼 Feel 啊？你不覺得這很過癮嗎？

好...ok,所以...這個流程完之後呢,接下來的第三步驟就是持續進化 ok？我們會根據營運的數據,因為你產品最後是上線嘛,對不對？

上線就會有數據嘛,那數據的話就是可以開始有一些 feedback。那這些 feedback 怎麼進到你的 spec？一樣,有 automation 的方法。你要自己去想,這...這整件事...這...這...這...這...這...這...這...只有你知道,是吧？

然後持續地去讓規格越來越完美,ok？然後我們的 code 呢,永遠都是貼近我們的 spec ok？把人工開發寫 code 的這個工作重越降越低,這...這變成是一個手段,就是我們要盡可能達成這個目標。

我們才有辦法讓我們的規格跟我們最後產生出來的 source code 是一致的。那我們每個規格層級的變更呢,基本上任何變更都從規格開始,所以就是這個概念就必須要貫徹到整個專案。

Legacy 系統案例

好,那這是一個在 GitHub 上面看到的一個實例啦,它是一個聊天系統把它 SDD 化之後的效率差異。但我覺得它有點過度的理想化啦,就是 SDD 只要 15 分鐘,傳統方式這個 12 小時,這我是覺得有點 over 了啦。

那我覺得 over 的點呢,倒不是因為這個時間少到不可思議,而是光是 AI 等它執行完的時間就超過 15 分鐘了。所以這個 15 分鐘大概是人類的 15 分鐘,產 code 都不算時間。

那些你跑去喝咖啡不上班的時候都不能算是那個工作時間,是吧。但是小,你就比較一下其實真的是有差,我跟你講會用跟不會用真的是差非常多。

那個一個人,一個會用 AI 跟不會用 AI 的人,真的是差別巨大你知道,不管是開發還是寫規格都是一樣的。

Template-Driven AI

好,所以我們整個關鍵基本上就是要模板驅動,就是 Template-Driven 的 AI。所以 GitHub 的 SpecKit 基本上就是一個 Template-Driven 的實現,就是它有大量的 Template。

好,那他有制定了一個所謂的憲法的架構,基本上就是告訴 AI 要做什麼啦,就是把這些事情就是想辦法寫清楚,就是跟這個兩性關係交往是一樣的意思。

憲法就是這個概念,反正我就跟你講,我不準怎樣怎樣怎樣,我一定要怎樣怎樣怎樣,不準侵犯。所以我的 AI 從第一階段到最後一個階段的所有的整個 workflow,全部都會 follow 這份憲法。

然後他有一些 rule,這裡每一條 rule 拆開我都可以講很久,就是這每一條都有很多內涵在裡面,都還蠻重要的。

為什麼是現在

所以為什麼是現在呢？當然就是 AI 嘛,這還用說。以前做不到是因為沒有 AI 可以幫我們想東西,現在可以。過去規格是靜態的,然後跟程式碼會脫節,現在就不一樣。

什麼東西都要 AI 賦能,全部都要自動化。所以時機點剛好到了,OK。

SDD 帶來的改變

好,最後一頁,基本上就是要跟大家講,SDD 帶來的就是可以給予整個團隊全新的開發能量,將意圖無損,意圖無損,這件事很重要。

傳承,變成一種最佳的實作,Best Practice,OK,讓規格主導一切。然後 AI 加規格太重要了,沒有 AI 基本上也不會有很好的規格,因為沒有人會想去頻繁的更新規格,然後被罵,對吧。

那最後就是,程式碼微網這件事,會改變,肯定會改變。當然你公司只有導入 SDD 才會改變,你只要沒有導入 SDD,永遠就是工程師說了算,永遠就是程式碼說了算,對吧。

所以大家好好思考一下,SDD 要怎麼導入到你們的團隊。好,這個是我的粉絲團,有興趣追蹤一下,我每天都會分享很多技術跟新知。

然後我有整理一些連結,簡報我晚一點會分享。然後有興趣你們都可以看,然後我這個月中,也有打算開這堂課 SDD,有興趣可以來。

特別優惠

那麼我有特別為大家...HAPPY DESIGNER 限額 100 份,就是今天的所有人,中間沒有空白,有興趣你們就拿去用。好,那我今天分享到這邊,接下來是 Q&A 時間。

Q&A 時段

謝謝保哥。好,那 Q&A 我覺得 Q&A 裡面已經有很多很有趣的東西了,然後這個我需要大家幫我拍張照片,讓我呼叫,要有用到這個有用這個,有用 APP 的人才可以照。

我按一下這個 ZOOM 的 Group Photo 功能這樣子。小,然後他會要求大家拍照這樣子。好,再麻煩大家。

好,然後保哥你可以先關掉螢幕的分享嗎？然後我可以分享那個 Slido 的部分這樣子。好的,感謝。

第一個問題:學生的建議

然後目前 Cloud Code 看起來是最大宗啦,然後這個另外的話就是 OpenAI Codes。你知道這個很好笑,就是大家才想說,好,Codes 看起來好棒,我們要換到,我們要從 Cloud Code 換到 Codes,然後 Cloud Code 又更新了這樣。

那這邊有很多這個問題,這個八卦的最後再聊,我們先聊正經的。第一個是,保哥第一個是有,應該是學生問說,正在大學念資工的學生,面對軟體開發的 AI 化,保哥可以給予什麼學習跟求職上的建議這樣？

就是你帶嘛,然後我一個一個回答是吧。小,我來選。哇,大學念資工喔。因為大學念資工一定會碰到一些程式,對吧。

那軟體開發 AI 化這件事,我覺得有一件事基本上,我覺得應該是肯定的,就是你不要拿雞蛋碰石頭,OK。人類是寫 Code 絕對寫不夠 AI,所以 Coding 這件事的價值感會大幅降低,這是必然發生的未來,OK。

而且差不多也已經發生了,所以如果你要去跟人家拼寫 Code 的速度,這一點都沒有意義,對不對。所以如果你能夠更加著重在基本功的建立,就是人的觀念還是最重要的。

所以有一些基礎的知識,我舉一個比較基本的,例如說你做 Web 你至少要了解 HTTP 怎麼運作的吧,你有哪些 header 這個可以用,request 跟 response 是什麼。

就是這種大家以前不是很重視,就是隨重視怎麼寫 Code 跟用框架的人,未來會非常的弱勢。所以如果你是讀資工,然後要看你未來的發展方向。

如果你要走 Web,像我是走 Web 的嘛,所以我會對 Web 的基礎知識,多花一些時間在學習這方面。然後 Coding 的部分,基本上你要多做 side project。

手感與記憶

怎麼說呢,我跟你講我年輕的時候是怎麼練功的,我年輕的時候練功就是大量寫 Code,我寫到手腕都肌腱發炎,我是寫到這種程度。就是我很熱愛寫程式,寫到我肌腱發炎受傷。

黃哥你今年幾歲？我 48。我以為你要說我今年 25。當我五年前寫 Code,小,我寫 Code 快 30 年了。所以我以前的練功方式,就是大量的用手感來輔助我記憶,手感輔助記憶。

但這件事在未來幾乎不會發生,而且你就算做我 20 年前做的這件事情,對你也沒有太大幫助,為什麼呢？因為以前沒有 AI,所以寫 Code 的速度對我來講,是一種成就的來源。

那以後你怎麼寫都寫不過 AI 的時候,你寫 Code 怎麼會有成就感呢？各位同不同意,給個表情符號。所以如果你現在還在讀資工,還在學習軟體開發,軟體工程程式設計,我勸你多花一點時間,學一些很基礎的東西,OK。

然後未來你要親自動手寫 Code 的機會變少,所以你才更應該大量的做更多的 side project,而且是 workable,真的可以運作有效有用,而且越多人用越好的開源專案,我建議你去做這件事情。

所以做這件事也不需要你親自寫 Code,但是因為你大量的實作,會培養很多經驗,那個經驗別人涵不走,而且是一個非常寶貴的資產。大概先回答到這邊。

保哥我有一個不一樣的觀點,就是我發現不寫 Code 的時候,那個你說的手感,我是手工藝人,然後我覺得手感其實會...

寫 Code 的記憶深度

我同意,我同意就是,就是那個這件事情,但是對於新人來說,就是對於這個要學習,要學習 Coding 的人,學習 Coding 這個邏輯的人,我覺得少這件事情感覺上是差很多的。

咕,這件事我想通了。喔,來,多講一點。是,咕,我也曾經想過我的手感會不會有一天就消失了這樣。那,咕,因為我寫 Code 的手感一直都很好,但是我,咕,這最近幾乎都沒有動手寫 Code。

我一直,我一直也會跟大家一樣有個擔心是,我以後會不會不會寫 Code,我就只剩出一張嘴了。咕,但是我發現,咕,我比以前更會表達需求。這什麼意思呢？

因為我們只要跟 AI 講需求,Code 都能精準到位的寫完、寫好,甚至連測試都幫我寫完。如果我一直可以達成目標,為什麼我不一開始就達成目標呢？

咕,講得有點奇怪。以前不是有個故事這樣說嗎？有一個人到這個什麼南美洲去玩,然後看到一個漁夫,每天就是無所事事,每天釣魚好像都很開心,沒有壓力的樣子。

問他為什麼你不去賺錢這樣子,各位聽過這個故事吧？然後他就說,他就反問那個遊客,你為什麼要拼命賺錢？他就說他退休的時候要能夠遊山玩水,環遊世界然後到處釣魚這樣子。

然後他就回他說,他不是現在就在做這些事嗎？我發現這個故事很有趣的點就是,在 AI 時代好像也是這麼一回事。

如果你寫 Code 的目的,最終是打造出一個可以運作,然後可以賣錢的產品,那你講講話就可以做到,為什麼一定要寫 Code 呢？

那話說回來,我說我想通的點在這裡,就是我寫一輪 Code,大概可以比我看十輪 Code Review,就是我讀一份 Code 得到的那個想法跟心得,讀喔,用眼睛看,一定不會那麼的深刻。

跟我寫文章一樣,我寫文章跟我看別人文章,那個記憶程度絕對是不同的。但是量變會帶來質變,所以如果我看一輪 Code 兩輪 Code,沒有辦法把這門記憶學起來,那我就看個十輪跟二十輪。

我發現最後我還是記得起來耶,這就是很有趣的地方。以前我要靠寫 Code 可以加深我的記憶,我十年都不會忘記。但是我現在寫一輪兩輪,我看一輪兩輪我會忘記。

但是我看十輪二十輪的時候,我發現我竟然自然而然就記起來了,我沒有刻意去記憶跟背誦。

第二個問題:API 費用控制

我們來講第二個好了,我覺得接著來講第二個,就是那個什麼,就是有人用 Vive Coding,然後上線了服務嘛,然後最後發現說這個他被這個 Gemini Code,就因為 Gemini API,然後就被 Code 這個費用付了一萬塊嘛。

那保哥你這邊有什麼其他的,這個多的想法想要分享一下嗎？這個不是問題吧？他說真實想法,我覺得這個其實可以扣回我們剛剛在講的,就是說那如果不知,這個我覺得這邊會有一個,我先講我的想法,因為我其實有分享。

我覺得這是一個知識的 Gap,OK,有,我有看到你那個貼文。知識的 Gap 就是,其實我寫了規格嘛,你知道對他來說,他講說他要這個功能,然後真的也做出了一個 API 的 Phone 的頁面,然後只是裡面其實操作跟他的想像不一樣,這是一個知識的落差。

小,然後那以我來說就是說,我覺得理想上就是我們想要這樣子,然後 AI 應該真的照著做,那實際上這邊有一個我想的跟 AI 做出來的差異,以及說如果我不瞭解程式,我只用 Swag 開發,我不瞭解程式,那事實上我沒有辦法去 Review 嘛。

嗯,我,咕,我跟你講,昨天,昨天有一個,咕,數位媒體的記者採訪我,他,他也問了我一樣的問題。他問我說對於這個,咕,情,情大姐事件...

知識 Gap 的問題

他唯一的問題就只有他太嫩而已,所以我們不覺得他有什麼問題啦。就是他開課教的印象又不是工程師,結果下面全部都工程師在罵他。嗯,我也覺得。

小,所以我覺得是還好,然後他的例子出來反而讓大家知道了,喔,真的會這樣。那其實這件事我三個月前直播就講過了,所以我們覺得沒有什麼正不正確的問題。

真正正確的問題就是,咕,我講說 Vibe Coding,如果你是非工程師也可以 Vibe Coding,工程師也可以 Vibe Coding,我每天都在 Vibe Coding,我現在的 code 根本就不是我寫的,全部都是聊出來的。

不然就是我可能會寫一份很長的 spec,幾百行的 prompt,然後一口氣全部生出來,我現在都這樣寫,你說我這樣不叫 Vibe Coding 嗎？算嘛對不對？

所以,咕,大家不要把 Vibe Coding 這件事汙名化,因為很多人就是把它汙名化了,因為一個事件而把這件事弄到都臭掉了,我都覺得沒有必要啦。

所以,咕,大家純粹對細節的要求不同而已,我的看法一直都是這樣。不過我覺得就是 side project 上線,然後你就可以很快學到新東西。欸,沒錯。

小,如果不上線,看起來都很棒。哈哈哈哈,沒錯。上線第一天就炸了。沒錯。

第三個問題:AI 生成內容的 Review

欸,那個,這邊有一個,很多 AI 生成的內容,不管是 code 還是 doc,生成的人可以很快產出一些東西,但很多時候累的是 review 的人,怎麼樣在速度跟這個確定品質之間平衡？

我覺得這滿棒的。這很棒,這題問得很好,而且我也有答案,就是,咕,這句話,欸,我稍微酸一下,但是我的目的不是酸啦,我只是讓大家覺得好笑而已,就是先聲明一下。

我覺得你那個 camera 要打開來酸才有效果。哈哈哈哈,我的 webcam 有一點問題,打不開。

你寫完 code 你還是要 review 你寫的 code 啊,你最好寫的時候都很清楚啦,也不是吧對不對。現在 AI 很快地把東西產出來了,你本來就該看,而不是說產生一堆東西我看得很累,那這不是本末倒置嗎？

大家同意嗎？來給我一個表情符號一下。你聽我講完對不對,如果覺得不錯給個愛心,給個讚鼓個掌一下。欸,有人給個怒欸,這好像有人不同意是不是,還是按錯？

就是這樣嘛,所以不是你累的問題,而是你本來就該做這件事。那 AI 做得快,你可以看慢一點啊,如果你因為 AI 產得快...

第四個問題:Legacy Project 的 SDD 應用

在 Legacy Project 中使用 SDD,請問有什麼起手式或經驗分享？

這個舊專案或是沒有規格的專案就不能 SDD,原因是因為範圍的問題。就是我們都知道即便是舊的系統,Legacy 的系統,其實還是會分 Module 的,不太可能真的就是五萬行的 Code 一個檔案全部寫完。

當然我有看過很誇張的,可能是五千行 Code,一個 ASP 檔這種,也有看過。但是你說 Legacy Project 不能用 SDD 嗎？當然是可以啊。

我們如果已經拆了十個二十個 Module,或者是你一個專案已經拆了十個不同的 Project,我們一個 Project 一份 Spec,從頭寫,叫 AI 寫,重新把這整個循環,把 SDD 的 Flow 建起來,一樣是可以做到的,對不對？

所以我們其實可以對部分的範圍開始做,會比較輕鬆。那如果你今天要對一個 Legacy 的系統做改版、重構、重建,現在的 AI 還沒有這麼大的能力可以讀你三十萬行的 Code,然後解決你十五年來的技術債。

那麼,對我來講,如果是 million lines of code,如果是這麼大量的 code 的話,現在要用 AI 來對這麼大量的 code 去做一次性的改變,這個不太可能,做不太到。Context window 也沒那麼大。

但是我現在針對我幾千行的 side project,是可以做到一次全部改完,而且還全對,這就是 Cloud 4.5 收內的結果。

起手式建議

各位網友要給我們實驗看看,我們可以做做看。那,咕,我們覺得能夠做一定程度的切割,然後,咕,如果本來就有模組化那當然是最好,如果本來沒有模組化的話,我也不太相信。

因為我們看過,我看過很多企業的 code,老舊的 code,就是不太可能沒有模組啦,就算沒有模組也會分頁面,就是它可能是頁數很多,但每頁不會很多。

那我們一頁一頁改,其實很多問題還是可以解決。所以,咕,你要對 legacy 的 system 去做升級或改版,咕,應該還是有方法,只是每個案子需求都有點不太一樣。

第五個問題:Constitution MD 的規模

好。欸,保哥那個,咕,這個我覺得可以跳過,因為這個應該是還沒有,因為我們今天在講的是 spec key 嘛。嗯。這個應該是他可以直接這樣...

這個應該是第五關,但的確這個還常發生。這是 Mark。這個我們很好奇耶,保哥你有什麼方法嗎？

不是啊,AI 寫 test case 就是為了通過才寫的,那它不 mark 它要幹嘛勒？這你也不能要避免它,你的 code 就是爛到要 mark 嘛,所以。

不是,我們實際,我們啦,我們公司自己實際發生的狀況是 AI 寫 test case,然後說 test case 寫好了,然後就看它裡面滿滿 mark,然後 mark 這個整個 library。沒錯。

然後所以你整個 test case 只有在測試 mark,但你這邊有什麼？我跟你講,這個有趣的地方就是,如果你被要求不允許動到原本的 source code,然後要把單元測試寫完,你自己寫 code 也是一大堆大量的 mark,而且花你大量的時間。

現在 AI 幫你寫完一堆 mark,只能證明你的 code 本來的 quality 就不好,所以才會有一大堆的 mark 嘛。所以,就是你原本的技術債,不太可能因為 AI 的出現,技術債就不見了。

就你原本的架構問題,還有相依問題,你在 AI 的年代...

第六個問題:測試案例的產出階段

是用了 SpecHeat,然後發現測試有看到通過很多,小,大家也好奇通過什麼測試。欸不過我覺得後面講就是說,在實踐上用 Plan 或 Task,哪個階段會加上這個測試案例的產出這樣？

咕...是 Implement 那個階段。就是最後一步才會開始寫 code 嘛,那寫 code 的時候就會連同 TDD 就是一起生出來了這樣。所以它不是 Plan 也不是 Task,而是在 Implement 的那個那個 phase。

才會產生所有的 Task code。但是你要知道,它產 code 其實要有依據嘛,所以依據就是整個 STD 流程前面產生的那一堆 Modem 文件。

那一堆 Modem 文件就是有辦法讓最後 Implement 那一段,就是非常順利地把所有 code 給寫完。

第七個問題:知識 Gap 與 AI Compiler

Oh, sorry,我剛剛按到一個。啊,你多按到一個。咕,剛剛那個是這個,咕,有一個 Podcast 講到說 AI compiler 的概念。如果 AI 足夠穩定,Codebase 可能不需要存 code,只要存 spec。

沒說錯,沒說錯,他沒說錯,這可能明年就會達到,明年就可能做到了。其實那個啊,這個 Cloud Sonnet 4.5 就出了那個 Imager 嘛,就是你可以直接對談,然後他即時生介面跟生 Code。沒錯,沒錯,穩定性很高,對吧?

這個有機會喔,這個有機會,而且我覺得很實在。我覺得缺點是這個不是 one on one mapping 嘛,就是你知道這個 spec 可以生出多個不同的。咕咕,實作。Yeah,對啊。

確實。所以每次跑的結果都不一樣。對。哦,這個蠻有趣的,就是用 SSD 開發功能開發到一半的時候,可能工程師或 AI 做了調整,這時候要把調整更新回 spec,怎麼樣雙向更新？你這有經驗嗎？

規格迭代的實務做法

嗯,我們也遇到了這個問題,小,那我們一個專案的開發分階段嘛,對不對？所以,如果我們要分段開發,我們一定是會把每一段做完,然後再到下一段,那我前一段做完了,我就不會再去改它了。

其實跟我們跑敏捷的概念其實是一樣的,就是我們跑每一個 sprint,完成之後那個 sprint 有什麼問題,下一個 sprint 再來改,那我不可能去改上一個 sprint 的東西。

上一個 sprint 沒做完的東西會移到下一個 sprint 去做,所以你把這樣的概念用在 SSD 一樣是行得通,所以我覺得如果你公司本來就導入敏捷的話,SSD 應該會走得蠻順的。

那保哥我好奇你像這些規格你現在是...

規格變更的實務處理

那就是你不要這份規格了,你就直接改 code 了嘛,是不是？那看起來是 AI 或工程師,就是可能我猜啦,就是 Wi-Fi 的 code,就是寫好 spec 叫 AI 寫 code 嘛,然後可能他就寫 code。

根據我剛剛分享的內容,你應該可以知道說,這種迭代是就是盡可能的不直接寫 code,所以你有東西要改,即便是小東西,理論上是回去改 spec,然後重新產生 plan,重新 implement,應該是這樣的一個流程。

然後如果你覺得改 code 方便,那當然工程師一定會這麼想。所以這是一種習慣的改變,而且有時候自己改 code 比較快,叫 AI 改就是很慢,對吧？

所以這是一種取捨,所以如果你的規格已經夠 solid,我就說我不求 100 分,OK？你真的做到你自己改比較快的時候,我們覺得 spec 一樣留一點點後來再來更新,我覺得也是可以接受的。

但是這就會有規格債,以前叫技術債嘛,對不對？規格債,累積久了你遲早有一天要換。如果你要走 SDD 的話,最好就紮實一點,什麼事情都從規格開始改起。

所以你的做法是回去重寫 spec,然後再重新產生 plan？No,這個叫做規格迭代,不叫重寫。重寫太誇張了,對吧？你產生好那麼多開發計劃,那麼多的規格,那麼多的執行任務,結果為了改一個小功能要全部重產一輪,然後跟之前還不一樣,這怎麼說得過去呢？

那我的意思是說你會先去改 spec,然後再重新生一次 code,而不是寫完 code 再去調規格,意思是這樣嗎？小,沒錯,建議是這樣。那這件事老實說不見得很花時間,為什麼呢？

因為不會,這樣說好了,SDD 開始導入的時候一定會有超級多的問題,像這種問題你就解決不了,但是我就不知道怎麼樣,我就是有答案。

所以我就說這件事會很像你對於專案開發建制是否有經驗,有經驗的人就知道如何謀明的行事。

實際案例分享

我舉個例子,我們公司的同事前幾天有來問我一個問題,他說 spec-it 產生出來的東西不是他要的,但他又不敢改,然後他就把一個不是他要的東西產生出不是他很要的 code。

我就說,蛤？What？這就是蓋房子的時候造圖施工,雖然覺得不合理,但這是圖畫的。小,沒錯,所以我就跟他講,你把它刪掉不就好了嗎？小,就是這樣,你為什麼要重產呢？刪掉就好了。

所以很多東西就只是一個觀念,稍微轉一下,有人點你一下,但是這個是需要有經驗的人來點你,你比較好理解。所以這就是為什麼我想開課的原因,因為這東西有時候不講你就是想不到。

最後兩個問題

保哥,現在我們已經超五分鐘了,最後我們回答再兩個問題好不好？可以啊,可以啊。好,感謝感謝。

第一個是,前幾天看到保哥提到透過 AI 重構還債的時機已到,可不可以方便分享怎麼樣對老舊的 code 重構,我覺得大家對這種事情都非常感興趣。

沒錯,老舊的 code,老話一句,你要先了解原始需求跟它的意圖,你重構才有辦法驗證,對不對？

那麼,對我來講,如果是 million lines of code,如果是這麼大量的 code 的話,現在要用 AI 來對這麼大量的 code 去做一次性的改變,這個不太可能,做不太到。

你要測一個既有的邏輯,你要改寫它,對不對？在不動現有的介面下,去透過單元測試去保護一個方法不被改壞,對不對？

如果你要做這件事,那如果你今天要做舊系統翻寫,程式架構、框架、連程式語言都不一樣的情況之下,這件事根本就達成不了。所以先寫測試反而沒有什麼用,反而有點浪費時間。

所以對我來講,先把規格建起來,再去做後面的動作,把規格當成唯一的真相。

規格生成的方法

(主持人：因為 AI 會讀扣啊,超強的好不好？叫 AI 讀扣,然後再反思,然後再 critical thinking,然後再反問你問題,中文一定會瞭解的,沒有想像中這麼困難,只是需要花時間。)

(主持人：像這邊有一個朋友 comment,legacy project 的經驗是用 AI 先幫忙寫單一 module,是幫忙對單一 module 產生這個看程式碼跟 test case 產生 spec,這也是一招啊。)

反正一定要先有 spec,就算你要寫 test case,你也要有需求才能寫 test case。

(主持人：同意,所以像剛剛的話,起手式我們應該是先想辦法生出 spec 吧？)叫 AI 生或是你自己生都可以。

(主持人：這邊有一個對於 spec kit 的問題,就是 constitution MD 定義過規範,但是原本東西很大,怎麼辦？)

Token 消耗問題

消耗大量 token 一點都不是問題,我先說。我剛剛在分享的時候也有講過,你用了 SDD 就是會消耗大量 token,而且這本來就是你該花的錢。

所以,幾千行不多,破千行也沒有很多,還好。(主持人：我也覺得破千行沒有很多)我真的覺得沒有很多,因為千行才幾萬 token,頂多一兩萬 token 吧,其實沒有很多。

所以,重點不在於 token 數量,重點在於這份 constitution 合不合理,會不會前後矛盾,這才是重點。你寫了一個前後矛盾的 constitution,然後抱怨它怎麼都沒有按照憲章做事,那就是你的問題。

Constitution 的矛盾分析

咕...我很好奇說,欸,就是你做的,如果比較大的 project,然後會不會其實消耗 token 是一個問題啦,那另外一個問題會是說這個,欸,因為文文件太多的時候會導致它的這個產出效果結果不好。

產出什麼不好？因為我自己會遇過就是 AI 做一做它就自相矛盾了嘛。咕,所以要反思啊。那 Spake 在這方面是不是做得比較好？

咕,Spake 在這方面做得非常好。它有它有一個分析指令,是隨時可以幫你分析矛盾點。這已經是內建的功能。哦,酷。Yeah,非常酷。

但它自己寫出有矛盾的東西,它還可以自己發現,所以還蠻酷的。好,這個就跳過啦。好,跳過,跳過。

Wikipedia 式的討論機制

SDD 是否像 Wikipedia 一樣,讓所專案關鍵角色擔任大法官的角色,負責各張檢舉討論？你這邊有這樣做過嗎？

我,我不打算把事情複雜化成這樣。Yeah。反正,所有大小事都一樣嘛,就是,咕,複雜了你就想辦法切割嘛,把它變簡單,總是犯錯的機率會降低嘛。

AI Compiler 的概念

Oh, sorry,我剛剛按到一個。啊,你多按到一個。咕,剛剛那個是這個,咕,有一個 Podcast 講到說 AI compiler 的概念。如果 AI 足夠穩定,Codebase 可能不需要存 code,只要存 spec。

沒說錯,沒說錯,他沒說錯,這可能明年就會達到,明年就可能做到了。其實那個啊,這個 Cloud Sonnet 4.5 就出了那個 Imager 嘛,就是你可以直接對談,然後他即時生介面跟生 Code。

沒錯,沒錯,穩定性很高,對吧？這個有機會喔,這個有機會,而且我覺得很實在。我覺得缺點是這個不是 one on one mapping 嘛,就是你知道這個 spec 可以生出多個不同的。

咕咕,實作。Yeah,對啊。確實。所以每次跑的結果都不一樣。對。

最後一個問題:雙向更新

哦,這個蠻有趣的,就是用 SSD 開發功能開發到一半的時候,可能工程師或 AI 做了調整,這時候要把調整更新回 spec,怎麼樣雙向更新？你這有經驗嗎？

嗯,我們也遇到了這個問題,小,那我們一個專案的開發分階段嘛,對不對？所以,如果我們要分段開發,我們一定是會把每一段做完,然後再到下一段,那我前一段做完了,我就不會再去改它了。

上一個 sprint 沒做完的東西會移到下一個 sprint 去做,所以你把這樣的概念用在 SSD 一樣是行得通,所以我覺得如果你公司本來就導入敏捷的話,SSD 應該會走得蠻順的。

那保哥我好奇你像這些規格你現在是...那就是你不要這份規格了,你就直接改 code 了嘛,是不是？那看起來是 AI 或工程師,就是可能我猜啦,就是 Wi-Fi 的 code,就是寫好 spec 叫 AI 寫 code 嘛,然後可能他就寫 code。

根據我剛剛分享的內容,你應該可以知道說,這種迭代是就是盡可能的不直接寫 code,所以你有東西要改,即便是小東西,理論上是回去改 spec,然後重新產生 plan,重新 implement,應該是這樣的一個流程。

然後如果你覺得改 code 方便,那當然工程師一定會這麼想。所以這是一種習慣的改變,而且有時候自己改 code 比較快,叫 AI 改就是很慢,對吧？

所以這是一種取捨,所以如果你的規格已經夠 solid,我就說我不求 100 分,OK？你真的做到你自己改比較快的時候,我們覺得 spec 一樣留一點點後來再來更新,我覺得也是可以接受的。

但是這就會有規格債,以前叫技術債嘛,對不對？規格債,累積久了你遲早有一天要換。如果你要走 SDD 的話,最好就紮實一點,什麼事情都從規格開始改起。

所以你的做法是回去重寫 spec,然後再重新產生 plan？No,這個叫做規格迭代,不叫重寫。重寫太誇張了,對吧？你產生好那麼多開發計劃,那麼多的規格,那麼多的執行任務,結果為了改一個小功能要全部重產一輪,然後跟之前還不一樣,這怎麼說得過去呢？

那我的意思是說你會先去改 spec,然後再重新生一次 code,而不是寫完 code 再去調規格,意思是這樣嗎？小,沒錯,建議是這樣。那這件事老實說不見得很花時間,為什麼呢？

因為不會,這樣說好了,SDD 開始導入的時候一定會有超級多的問題,像這種問題你就解決不了,但是我就不知道怎麼樣,我就是有答案。

所以我就說這件事會很像你對於專案開發建制是否有經驗,有經驗的人就知道如何謀明的行事。我舉個例子,我們公司的同事前幾天有來問我一個問題,他說 spec-it 產生出來的東西不是他要的,但他又不敢改,然後他就把一個不是他要的東西產生出不是他很要的 code。

我就說,蛤？What？這就是蓋房子的時候造圖施工,雖然覺得不合理,但這是圖畫的。小,沒錯,所以我就跟他講,你把它刪掉不就好了嗎？小,就是這樣,你為什麼要重產呢？刪掉就好了。

所以很多東西就只是一個觀念,稍微轉一下,有人點你一下,但是這個是需要有經驗的人來點你,你比較好理解。所以這就是為什麼我想開課的原因,因為這東西有時候不講你就是想不到。

活動結束

好,那我們今天的分享就到這裡結束了。非常感謝保哥精彩的分享,也感謝所有參與者的熱烈討論。希望今天的內容對大家在 AI 時代的軟體開發有所啟發。

記得追蹤保哥的粉絲團和部落格,獲取更多 SDD 相關的技術分享。我們下次活動再見!