AI 時代，重新思考軟體工程的價值

前言

AI 寫程式變便宜了，這件事大家都知道。但我這陣子一直在想一個問題：當「寫」這個動作的成本壓低到接近零，軟體工程剩下的價值會跑到哪裡去？

AI 導入之後，現在常見的狀況是這樣：產出量明顯變多，但能不能轉成商業價值反而變得更不確定。開發端 PR review 變得更累、品質指標往下走；另一邊，內容做了不少，AI Overviews 上線之後流量曲線整個變形，傳統 SEO 的玩法開始失靈。

把這兩件事擺在一起看，其實是同一個訊號。AI 同時改寫了「產品怎麼被做出來」跟「產品怎麼被找到」這兩個環節，而工程的價值正在從「能不能寫出來」，轉移到「寫出對的東西、並且讓對的人找到它」。

這篇想整理一個自己這陣子在用的思考框架，把工程價值拆成內部跟外部兩個面向。內部用 AI 賦能的 DevSecOps 顧好品質與速度，外部用 GEO（生成式引擎優化）與體驗優化把流量轉成營收。兩邊各自跑得起來之後還能互相餵養，這套節奏大概就是 AI 時代工程師真正能累積的籌碼。

內部：工程價值從「寫得快」移到「寫得對」

當 AI 把寫程式碼這件事的成本壓得很低，工程師的核心價值就不再是「能不能把東西做出來」，而是「能不能把東西做得對、做得穩」。判斷哪些 AI 建議該收下、哪些要打回票，反而變成新的核心能力。

往內看，這層新的工程價值大致落在四件事上：把 AI 當效率槓桿、把重複的品質檢查交給 AI、用自動化把整套開發管理工具串成一條流水線，最後讓系統本身變成 agent 代理人，主動處理運維層的對帳、審核與分析。下面分別說明。

效率：把 AI 當槓桿，盯緊真正的成效

用 AI 寫程式已經是日常了，數據也很漂亮：八成以上的開發者天天在用，四成的程式碼出自 AI；導入比較深的團隊，完成的任務多了兩成，合併的 PR 數量甚至翻了快一倍。

但「把 AI 當槓桿」跟「整包丟給 AI」是兩回事。整包丟出去，是期待它替你寫完一切；當槓桿，則是只交出該交的那部分，那些重複、無聊、誰來寫都差不多的活，像是樣板程式、把同一套寫法複製到很多檔案、照 spec 先生出第一版。這些交給 AI，我自己留下真正需要動腦的：架構怎麼設計、邊界怎麼抓、這功能到底要解決誰的問題。

而且槓桿真正的重點，不在「省了多少時間」，而在「省下來的時間拿去做什麼」。如果只是更快寫完一個方向本來就錯的功能，那省下來的時間，不過是讓你更早撞牆而已。所以我會把它花在想清楚兩件事：為什麼現在做這個、做完怎麼知道它有沒有用。這也呼應了我之前聊 AI 開發趨勢時的結論，當 AI 把「寫」變便宜，真正稀缺的就變成判斷力。

品質：重複的檢查交給 AI，人守住關鍵判斷

同一份報告的另一面是：近 48% 的 AI 生成程式碼帶有安全漏洞，PR 審核時間不減反增達 91%。這個落差其實不難理解，AI 寫的量暴增，但每一行還是得人 review，而且 reviewer 還得額外留意 AI 容易犯的習慣性錯誤，例如沒驗證輸入就直接組 SQL、把敏感資料寫進 log、漏掉錯誤處理路徑。

我自己在維護這個 blog 的內容生成 pipeline 時也有類似的觀察。AI 寫的程式邏輯乍看都很合理，但像是 prompt injection 的邊界、暫存檔案沒清掉、API key 在錯誤訊息裡被一起印出來這類細節，幾乎都得回頭再補一輪。

反過來說，重複性高的檢查工作其實才是 AI 最該接手的，例如測試案例生成、安全掃描、靜態分析、依賴漏洞檢查。這些事人來做又無聊又容易跳行，交給 AI 反而更穩。具體可以分成三層防線：

IDE 內即時掃描：在開發者寫程式碼（或接受 AI 建議）的當下，工具就能即時偵測漏洞並提供修復建議，而不是等到 PR 階段才爆出一堆問題
AI 驅動的自動化測試：讓 AI 自動生成測試案例，特別是針對邊界條件和安全場景，補上人工容易遺漏的盲區
CI/CD Pipeline 整合安全掃描：每次提交自動執行靜態分析、依賴漏洞檢查、容器映像掃描

開發者寫程式碼 / 接受 AI 建議
        │
        ▼
┌──────────────────────┐
│  IDE 即時安全掃描      │ ← 第一道防線（寫的當下就抓）
│  SQL Injection        │
│  XSS 漏洞              │
│  → 即時修復建議        │
└──────────────────────┘
        │
        ▼
┌──────────────────────┐
│  AI 自動化測試生成     │ ← 第二道防線（邊界與安全場景）
└──────────────────────┘
        │
        ▼
┌──────────────────────┐
│  CI/CD 安全掃描       │ ← 第三道防線（上線前最終把關）
│  SAST / DAST / SCA   │
└──────────────────────┘
        │
        ▼
   安全地部署到 Production

自動化：把工具鏈接起來，讓判斷力浮上來

效率跟品質這兩件事其實會卡在同一個地方，就是工具鏈夠不夠順。如果安全掃描、測試生成、CI/CD、PR review 散落在不同地方，工程師每天還是會被工具切換跟手動 trigger 吃掉時間。

新一代的開發管理工具會把這些環節串起來，例如從 PR 自動觸發掃描、把 AI 生成的測試案例直接掛進 CI、把 review 中發現的 pattern 餵回給 IDE 提示，甚至讓 LLM 在 PR 上自動留下第一輪建議。這類自動化把重複工作壓到背景跑，工程師才有空間去做 AI 還做不來的事，例如判斷取捨、設計架構、跟使用者對齊。

運維：讓系統變成代理人，主動處理日常營運

當 AI 再往運維層走一步，系統就不再只是「被觸發的工具」，而是替你操作其他系統的代理人。我自己這個 blog 的部署腳本就是一個小型例子，整套流程從本機建置、分版本 tag、串流傳到 NAS、Blue-Green 啟動新容器、健康檢查、失敗自動回滾，到最後清理舊映像保留兩版供回滾，全部串成一個指令完成。我只負責按下「執行」，中間的決策（要不要回滾、舊版本該砍幾個、什麼時候算就緒）都是腳本自己做的，停機窗口壓在一兩秒之內。

把這個概念再往組織層推，企業內部很多運維工作其實都適合交給 AI agent：

對帳：定期比對訂單、金流、出貨三邊資料，自動標出不一致的紀錄並開工單，不用財會每天人工跑
審核：報表、PR、合約、發票這些文件先讓 AI 跑一輪預審，標出高風險或不合規的段落，人只做最後拍板
分析：每天自動跑營運數據、抓異常波動、把結論摘要送到 Slack 或信箱，不用每天有人手動拉報表再寫結論

這些事的共同特徵很明確：邏輯規則清楚、決策邊界已知、人類做起來又煩又容易跳行。把它們交給 agent 之後，人才有空間去看那些「規則之外」的東西，例如為什麼這個月對帳特別多異常？為什麼這份合約的風險點跟以往的形態都不一樣？這層判斷，才是工程跟營運真正貴的地方。

外部：工程價值從「能上線」移到「被找到、能轉化」

過去工程師的工作通常結束在「功能上線」，剩下的事交給行銷與業務。但在 AI 搜尋的世界裡，技術選型直接決定了你的內容能不能被 AI 引用，前端架構直接影響轉化率，連 schema 標記、頁面結構這種看似純技術的決定，都會牽動到營收。換句話說，「上線之後的事」也回到了工程師的價值版圖內。

往外看，這層價值同樣可以拆成三件事：怎麼把對的人引進來、每次接觸有沒有產生互動結果、最後能不能被體驗轉成訂單。

引流：把對的人帶進來

Google AI Overviews、ChatGPT Search、Perplexity，這些 AI 搜尋工具正在改變使用者獲取資訊的方式。使用者越來越常直接從 AI 生成的摘要中得到答案，傳統 SEO 的點擊率正在下降。新一輪引流的主軸從 SEO 走向 GEO（Generative Engine Optimization），核心邏輯是讓你的內容成為 AI 系統願意引用的權威來源。

引流端的工程價值，可以拆成兩條線：

技術 SEO：清楚的標題層級、FAQ schema、結構化資料、語意化的 HTML，AI 才容易解析跟引用
多模態內容：YouTube 影片不再只是附屬頻道，而是直接餵入 Google 搜尋體驗的多模態資料來源；Podcast 聽眾年增 25-35%，購買意圖指標也優於所有其他內容格式。影片、Podcast、逐字稿的標題與描述都要一起被優化

我自己跑這個 blog 的時候，每篇技術文章都會自動生成語音摘要、Podcast 對話、YouTube 短片，每個檔案也都帶結構化欄位。一開始這套自動化純粹是為了讓我通勤時可以聽自己寫過的內容複習，但後來慢慢觀察到一件事：多模態版本上線之後，AI Overviews 對這些文章的引用明顯比純文字版本更積極。這跟我原本以為「多模態主要是給人類消費」的直覺有落差，看起來 AI 搜尋更傾向引用那些「同一個主題在多個格式都有出現」的內容，可能是因為這對它而言是更強的權威訊號。

效率：流量進來之後，互動結果才是指標

引流不是終點，流量能不能轉成互動才是真正要看的事。流量再大，但停留時間短、跳出率高、沒人留言或訂閱，最後也沒辦法變成商業價值。我自己看互動效率時，通常會分成兩組訊號：

平台層的訊號：停留時長、滾動深度、Podcast 跟影片的完聽率，這些反映內容有沒有抓住人
社群層的訊號：訂閱、留言、轉發、收藏，這些反映內容值不值得被分享

兩組訊號要一起看。一篇文章流量很高但平台層全是 0，多半代表標題騙到點擊但內容沒接住；流量普通但社群層特別熱，反而是「值得多寫幾篇同方向」的訊號。這個訊號比表面流量更值得追蹤。

體驗：把流量變成訂單

最後一哩是體驗，全球結帳放棄率高達 70.22%，行動端轉化率僅 1.53%（桌面端 3.36% 的不到一半），但行動端卻佔了總流量的 68%。這代表大量的潛在營收正在流失，而流失的地方往往不是某個大問題，而是一連串的小摩擦。幾個高投報率的優化方向：

優化策略	預期效果	說明
一頁式結帳	降低 20% 放棄率	減少頁面跳轉，降低使用者流失
多元支付（Apple Pay 等）	提升 22.3% 轉化率	13% 消費者因找不到偏好支付方式而離開
行動端優化	最大優化空間	佔 68% 流量但轉化率僅桌面端一半
社群登入	降低註冊門檻	減少表單填寫，加速結帳流程

這些觀察和電商與實體門市差異中討論的邏輯是一致的，線上購物的每一個摩擦點都是流失點。

另一條值得試的線是 Social Commerce，社群商務預計 2026 年全球突破 1.6 兆美元，轉化數字也很驚人：

通路	平均轉化率	特點
傳統電商	2-3%	成熟但增長趨緩
TikTok Shop	4.7%	內容驅動，適合衝動消費場景
直播帶貨	高達 30%	即時互動 + 限時優惠，轉化率最高

最直接的觀察是：跨平台的轉化率落差大到不應該只壓在單一通路。每個通路的使用者意圖跟期待的體驗都不一樣，與其在傳統電商頁面硬塞所有客群，不如根據通路設計不同的著陸體驗，甚至連結帳流程都可以針對 TikTok 或 IG 的習慣分別優化。使用者體驗跟購買場景的設計，對轉化率的影響其實遠大於單純的流量規模。

結論

回頭看內部跟外部這兩條線，最有意思的不是它們各自跑得多快，而是兩邊的回饋會互相補。內部把開發效率穩住之後，外部觀察到的新需求就有機會在幾天內變成可上線的功能；而外部用 GEO 抓到的高意圖流量與行為數據，又會反過來指引內部該優先做什麼，避免工程資源被燒在沒人在意的功能上。少了任何一邊，另一邊都會慢慢失去動能。

如果要從現在的位置往這個方向移動，我自己會建議的順序大概是這樣：先把開發端的安全掃描從 PR 階段往前挪到 IDE，止血最快；接著挑幾篇既有的高流量文章補上結構化資料跟多模態版本（語音、影片），看看 AI 搜尋的引用有沒有變化；最後才動結帳流程，因為這一塊牽涉的部門最多，需要更完整的數據才比較好說服人。

回到一開始的那個問題，AI 把寫程式變便宜之後，軟體工程的價值跑到哪裡去了？我覺得答案就藏在這套內外引擎中間。它從鍵盤上的字數，轉移到了三件事：判斷什麼值得被做出來、確保做出來的東西品質夠穩、想辦法讓它被對的人找到並買單。能同時做到這三件事的團隊，會比別人早一步知道使用者要什麼，也比別人早一步把它做出來，這大概就是 AI 時代工程師真正的護城河。