讓工程師失業的 N + 1 道陰影

先從現場提問看 AI 開發現況

分享一開始，高見龍用即時互動工具詢問現場：是否把程式交給 AI 寫、是否還會看程式碼，以及是否擔心被取代。提問帶著玩笑，但也直接點出現況：不少人已經把 AI 寫程式當成日常，而「叫 AI 看」不等於人類真的完成審查。對於工程師是否會被取代，現場看起來則是擔心與自信各占一半。

這套互動系統名為 echo，是高見龍為了改善課堂上大家不太開口回應而做的工具。它讓使用者不必舉手，也能即時按鈕回饋或留言提問。系統大約花一個多星期完成、約有五六萬行程式碼；高見龍說自己幾乎沒有逐行認真看程式碼，但該做的測試與紀律仍有做到。

「我一行 Code 都沒有認真的看……但是該做的一些紀律，例如說該寫的測試，都有做。」
— 高見龍

AI 加速 SDLC，但沒有取代整條開發鏈

回顧去年「讓工程師失業的 N + 1 道陰影」的觀察，高見龍認為工程師的求職空間受到壓縮，以及 AI 產出程式碼比例提高，趨勢仍在延續。但 AI 加進來後，整個 SDLC 並沒有本質上的大改變：需求、規劃、實作、測試、驗收與維運都還在，只是其中不少環節被加速了。

他也提醒，不要把 Vibe coding 理解成完全不懂程式的人隨便玩一玩。提出這個概念的人本身是高手，高手的「隨便看」和一般人的隨便看不是同一件事。與其追逐不停冒出的新名詞，不如抓住更實際的問題：當 AI 能力愈來愈強，人類要怎麼控制它，讓它照著目標做事。

高見龍把這件事連到 2026 年上半年常被討論的 harness。雖然每個人對 harness 的定義不盡相同，但核心都在於建立控制方式。過去他曾採取「AI 寫 code、自己做 Code Review」的模式，實際做下來非常累；當程式碼規模快速成長，單靠一個人逐段盯 code 並不可持續。

SDLCVibe codingharnessAI 協作可信任程式碼Code Review

程式碼愈便宜，可信任性愈昂貴

高見龍分享自己做活動系統的經驗：專案程式碼已累積到三十多萬行，實際可用於活動驗票，後續也持續改版。這讓他感受到，一個人加上 AI 的確能把整套系統做出來；但早期 AI 不夠受控時，需要不斷確認它做得對不對，整個過程其實相當辛苦。

「程式碼的產生越來越廉價越來越便宜，但是那個可信任程式碼卻越來越貴。」
— 高見龍

這個判斷是他從反覆與 AI 協作中累積出來的信心，而不是 AI 偶爾答對一次就立刻相信。當程式碼持續放大，一個人很難靠人工管理所有細節，因此他從 2026 年 1 月開始尋找更可控的方法，最後把重點放到 SDD。

SDD 的三個層次：先有規格，再談自動化

高見龍所說的 SDD，是先寫規格、再寫測試，接著讓 AI 依規格實作。它和 TDD 在先定義預期這點上有相似之處，但關鍵不在於背誦一套新流程，而是先把要做什麼交代清楚。

• 第一層是先寫規格：至少要讓 AI 先建立可執行的規格，再依規格做事。
• 第二層是 Spec-as-source：規格、文件與實作必須對得起來，不能只在開工前生成一份文件後就放著過期。
• 第三層是理想狀態：只寫規格檔就自動產出程式碼。目前因為不確定性太多，高見龍認為還不太可行，就算有效果也不一定好。

他特別拿 README 提醒大家：許多 side project 一開始 README 寫得很完整，但隨著實作演進，文件很容易和系統脫節。這正是 SDD 最容易失敗的地方。只使用 Spectra 或 OpenSpec 跑過流程，不代表真的完成 SDD；如果變更後沒有回頭更新規格，最後只是多了一套看似正式、其實不可信的文件。

SDDTDDSpec-as-sourceREADME規格飄移規格與實作同步

把流程做輕：提案、實作、歸檔

規格沒有唯一格式，可以是文字檔或 MD 檔；重點是交給另一個 AI 或另一位接手者時，能正確理解。高見龍先替自己整理出簡化流程：先產生提案，再實作，完成後把規格歸檔備查。這套最初版本只用約 45 行 prompt，直接丟進 Claude 或 codex，就能產生簡單的 SDD 效果，不需要額外 skill 或套件。

不過，單一 prompt 的效果有限，可能漏步驟，也可能每次輸出不一致；每次都重新處理 prompt 也不方便。因此他觀察到既有的 SDD 工具，例如 Spectra 與 OpenSpec。前者文件非常完整，但文件太多時反而看不完；後者相對輕量、他也比較喜歡，但對新手而言，要開終端機下指令仍是門檻。

為此，他自己做了名為 Spectra 的 GUI 工具，提供 SDD prompt、skill 與圖形介面，重點是讓使用者看得到提案、設計與任務的狀態，任務完成時也會標記。工具一開始只是做給自己用，後來逐步發展為第二版；畫面中的部分按鈕純粹是上課展示用途，並非每個都有實際功能。

人類必須在迴圈裡：PMuse 與 ingest

高見龍參考 OpenSpec 的流程，但刻意補上它沒有強調的停點。一般流程可能是提出 proposal 後就直接 apply；但如果人類沒有閱讀 AI 寫出的提案與規格，整件事就只是跑流程。因此，他在自己的設計中加入 PMuse：AI 走到提案與規格確認處必須停下，由人類看過、確認沒問題後，才繼續實作與歸檔。

「你跟 AI 討論規格，叫 AI 幫你寫提案，然後就叫 AI 幫你做；如果你不看，你做在幹嘛？」
— 高見龍

這正是 human in the loop 的實務意義：人不是每一步都親手輸入，而是在真正需要判斷的地方保有停止、確認與放行的權力。使用者筆記也特別點出，規格比以往更需要被 review；因為 AI 若依錯誤或過期的規格高效率執行，只會更快地把偏差放大。

另一個關鍵設計是 ingest。假設原先規格寫的是右下角藍色按鈕，做到一半改成紫色，若只改程式碼就直接歸檔，規格便和實作脫鉤。ingest 會回頭整理剛剛做過的改動，寫回原本的 spec 或 README，再讓流程繼續。它的目的就是避免規格飄移，維持程式碼與文件的同步。

human in the loopPMuseingest規格 review規格飄移README

規格也是整理過的 context，可跨 AI 接力

在高見龍眼中，spec 不只是文件，也是整理過的 context。它可以交給不同 agent 執行：例如由較適合規劃的模型產生規格，再交給另一個模型實作；也可以讓能力較強的模型先把規格交代清楚，再讓成本較低的 Worker 去完成工作。實際上要選哪個模型，仍要依任務與專案測試，不同情境可能有不同答案。

規格的一項隱藏好處是跨 AI 重現性。當某個 Agent 在半夜出現 502、500 或點數用完，不必就此中斷；另一家 AI 可以讀取目前規格，知道做到哪裡、從哪裡接手。高見龍認為，現階段不太可能把兩家 AI 的內部 context 直接互傳，但以可讀的 spec 作為交接點，是更務實的作法。

少看逐行程式碼，不等於放棄審查

有人質疑 SDD 很花 token，高見龍的回答很直接：若能解決問題，就該花。他也回應「不看 AI 程式碼」的說法，提醒不能只看標題。例如 Uncle Bob 所說的不看 AI source code，背後仍有單元測試與其他基礎建設做支撐，並不是讓 AI 無限制自由發揮。

他的做法是把閱讀重心部分轉向 spec。當規格正確，主流 Agent 多數情況能一次完成，或小修後就能通過；若 AI 做錯，他也會回頭檢查是不是自己一開始講錯了。不過，這不代表所有功能都可以同等對待：跟金錢有關、出錯會造成重大後果的流程，仍必須仔細看，也必須補上測試；相對低風險的聯絡頁面，審查強度則可以不同。

高見龍強調，AI 時代的開發者紀律應該比以前更嚴格。AI 不能直接操作他的 IDE；即使它提出操作 Git 的要求，也要先取得他的允許。每次 AI 完成修改後，他會先看 git diff，確認改了哪些檔案與區塊。過去他就遇過 AI 聲稱修掉 CSRF token 問題，實際上卻只是刪掉一行程式；幸好透過 git diff 及時發現。

「我也許不看完整的 Code，但是我大概可以知道在改什麼東西。」
— 高見龍

• 重要功能與高風險流程要提高審查與測試強度，尤其是金流與可能造成重大後果的功能。
• 每次變更先看 git diff，確認 AI 是否修改了不該碰的設定檔、專案內容或流程。
• 不把 AI 當成完美工具，也不把「不逐行看 code」誤解為完全放任。
• AI 會有幻覺，但人類也會誤判；實務重點是建立可驗證的流程，而不是期待任何一方百分之百不犯錯。

git diffIDEGitCSRF tokenunit test風險導向審查開發者紀律

規格進版控，讓每次變更都有來由

對於 spec 是否該進版控，高見龍的立場很明確：若要走 SDD，它就是規格與文件，就應該一起進來。雖然程式碼可能只改十行、規格卻多出數百行，看起來增加了負擔；但規格記錄了為什麼做、要做什麼、以及不做什麼，這些正是只看程式碼很難完整還原的脈絡。

他的習慣是每次變更都建立 proposal.md：先與 AI 討論，再寫提案、交給 AI 實作、驗收，最後歸檔。程式碼、proposal 與任務會一起保留在同一包變更中；寫 PR 時，也可以直接利用 proposal.md 的內容整理說明。這讓規格不再是孤立文件，而是變更紀錄與審查依據的一部分。

既有系統別一次逆向，從變更處慢慢包覆

面對 legacy 系統，常見想法是直接叫 AI 從原始碼自動生成 spec。高見龍認為技術上可以生成，但最大問題是：你怎麼知道它對不對？AI 能讀懂程式碼正在做什麼，也就是 WHAT，卻不一定知道當初為什麼這樣做，也就是 WHY。尤其原作者不在、歷史決策沒有留下來時，生成出來的規格可能有部分錯誤，而且很難知道錯在哪裡。

比較穩健的方法是 spec on change。高見龍以絞殺榕包覆樹木來比喻：不要妄想一次替整個 legacy 系統產生完整規格，而是在每次碰到某段程式、準備變更時，為那一小塊補上 spec。隨著變更累積，規格會逐步包覆系統；沒被包到的地方，至少代表目前還沒有動到。這種方式生成的規格，是在實際開發與人類確認中逐步建立，相對更有把握。

版控proposal.mdPRlegacy逆向工程WHATWHYspec on change

工程師角色轉向：從寫 code 到交代問題

高見龍展示自己近期做的終端機工具：可保留對話、快速回到特定專案與工作內容。這套終端機同樣是用 SDD 做出來，專案已接近六十萬行程式碼，沒有親手寫一行 Code；自動化測試約有八千到九千個，每次 commit 都會完整跑過流程。這個案例不是要宣告人工完全退出，而是具體呈現 AI 能把實作能力放大到什麼程度。

他形容工作節奏已經改變：以前是自己知道要做什麼，現在則是要交代 AI 做什麼，以及不做什麼。這個轉換要求工程師更會定義問題、切分範圍、寫清楚規格、辨識風險，也要負責最後的驗證。鍵盤輸入工作減少，但判斷與控制沒有消失，反而成了更核心的能力。

他把心境轉變整理成「工程師的 AI 悲傷 6 階段」：從一開始覺得 AI 生成的東西不能用、進而憤怒，再到認為核心工作仍只有自己能做；接著感受到 AI 的能力可能讓自己失去存在價值，最後轉為理解，只要能問對問題、交代對需求，就能獲得答案，並開始教別人如何用 AI。企業訓練現場中，他也觀察到不同人正處於不同階段。

「AI 它沒有拿走我樂趣，它拿走我鍵盤。」
— 高見龍

對高見龍而言，AI 幫忙打字、寫程式，反而讓過去因為技術、時間或人力不足而無法實現的 idea 有機會落地。可以同時開多個終端機、開多個 tab，讓不同工作往前推進；自己做的 echo 之類的小工具，就是這種新的創作樂趣。當天 echo 雖然在超過百人的情境下有些效能壓力，但仍成為分享內容最直接的實驗場。

重點回顧

• AI 大幅降低程式碼產生成本，但不會自動解決可信任性、需求釐清與風險控制問題。
• SDD 的核心是先寫規格；真正成熟的做法，還要讓規格、程式碼與文件持續同步。
• 不要把 SDD 當成產生文件後照流程點過去。PMuse 與人類審查，是避免錯誤規格被快速放大的必要關卡。
• ingest 用來把實作中的調整寫回 spec，避免 README、規格與實作脫鉤。
• spec 可作為跨 AI 的共同交接層，讓不同 Agent 在服務失敗、額度用盡或任務切換時接力工作。
• 不逐行讀完整程式碼，不代表不審查；用 git diff、測試與風險分級，聚焦看 AI 改了什麼、重要流程是否可靠。
• legacy 導入 SDD 不必一次到位，採取 spec on change，從每次實際變更逐步建立可信規格。
• 工程師的價值正從大量手寫程式，轉向定義問題、交代邊界、設計驗證與對結果負責。