2026年7月4日星期六

AI 並沒有改變台灣企業重視成本的文化，它只是讓企業有了更強的成本控制工具

最近一年，幾乎所有軟體公司都開始導入 AI。

從 ChatGPT、GitHub Copilot、Cursor，到各種 AI Agent，工程師的開發效率確實提升了不少。

但是，我觀察到一個現象：

AI 並沒有改變台灣企業重視成本的文化，它只是讓企業有了更強的成本控制工具。

AI 提升的是生產力，不一定是薪資

很多人期待：

AI 能讓工程師更有價值，因此薪資也會提高。

但現實往往不是如此。

如果一位工程師以前一週完成 5 個功能，現在透過 AI 可以完成 8 個。

理論上，公司獲得了更多產值。

然而，在許多企業的思維裡，這並不代表工程師應該加薪，而是代表：

KPI 可以提高。
工作量可以增加。
團隊規模可以縮小。

換句話說，AI 提升的是生產力，但生產力是否轉化為薪資，取決於企業如何分配這些成果，而不是 AI 本身。

AI 改變的是企業的成本模型

對許多企業而言，AI 最直接的價值並不是「打造下一個創新產品」。

而是：

少請一個人。
延後招募。
用現有人力完成更多工作。
降低外包成本。
縮短開發時程。

如果以前需要：

3 位 Junior
2 位 Senior

現在可能變成：

1 位 Junior
1 位 Mid-Level
2 位會使用 AI 的 Senior

總人數減少，但工作總量沒有減少。

AI 在這裡扮演的是槓桿，而不是福利。

AI 很快就會變成新的基準線

幾年前，如果一位工程師一週完成三個功能，大家會認為效率很好。

今天，公司可能會問：

「不是有 ChatGPT 嗎？怎麼還只完成三個？」

AI 並沒有讓大家更輕鬆。

反而讓原本的高效率，逐漸變成新的最低標準。

當所有人都擁有 AI 工具時，AI 不再是競爭優勢，而是基本配備。

就像 Git、Docker、CI/CD 一樣。

沒有人會因為會用 Git 而獲得加薪。

未來，也不會有人因為會使用 ChatGPT 而自動獲得更高待遇。

技術門檻正在下降，但商業門檻沒有

AI 可以快速產生：

CRUD 程式碼
API
SQL
Vue 元件
Laravel Controller
單元測試

因此，許多原本需要幾年才能累積的開發能力，現在透過 AI 就能完成七、八成。

但是，公司真正需要解決的問題並沒有改變：

系統架構如何設計？
資料一致性如何維護？
高併發如何處理？
權限模型如何規劃？
如何降低長期維護成本？
如何讓系統支撐未來三到五年的成長？

這些問題仍然需要經驗、判斷與責任。

AI 可以提供建議，但最終仍需要有人承擔決策。

真正被放大的，是能力差距

AI 不會平均提升每一位工程師。

它更像是一個放大器。

會使用 AI 的人，可以更快完成工作。

懂得驗證 AI、修正 AI、整合 AI 的人，可以把效率再往上推。

但如果只是照單全收 AI 的輸出，而缺乏判斷能力，反而可能產生更多技術債。

因此，真正拉開差距的，不是「有沒有使用 AI」。

而是：

是否知道 AI 什麼時候是對的。
是否知道 AI 什麼時候是錯的。
是否有能力做最後的技術決策。

工程師真正需要思考的是什麼？

如果 AI 已經成為每位工程師都能使用的工具。

那麼，真正的競爭力就不再只是：

我會不會寫程式？

而是：

我能不能利用 AI，解決別人解決不了的問題？

包括：

系統架構能力
跨團隊協作能力
商業理解能力
技術決策能力
AI Workflow 設計能力
系統整合能力

這些能力，才是真正難以被複製的部分。

結語

AI 的出現，確實改變了軟體開發的方式。

但它沒有改變企業追求效率與控制成本的本質。

對許多台灣企業而言，AI 首先是一種提升生產力、降低成本的工具，而不是重新定義人才價值的起點。

因此，對工程師來說，真正值得投資的，不只是學會使用 AI，而是培養那些 AI 難以取代的能力：判斷、整合、架構設計，以及把技術轉化為商業價值的能力。

因為工具會普及，效率會被追平，但能做出正確決策的人，始終是最稀缺的資源。

很多台灣企業談 AI，第一個想到的不是創新，而是降本增效。

這並不是因為企業有錯，而是市場競爭的結果。

在利潤有限、競爭激烈的環境下，企業最容易衡量的指標永遠是成本。

因此，當 AI 出現後，管理層最先想到的往往不是：

「我們可以做出哪些以前做不到的新產品？」

而是：

能不能少請一個人？
能不能把原本五人的工作交給三個人完成？
能不能縮短開發時程？
能不能降低外包成本？
能不能提高每位工程師的產出？

這就是「降本增效」的思維。

AI 在這樣的環境裡，首先是一項成本控制工具，其次才是創新工具。

因此，許多工程師感受到的，不是工作變輕鬆，而是工作要求變高；不是薪資因 AI 而同步成長，而是 AI 成為新的基本能力，企業期待用同樣甚至更少的人力完成更多工作。

這不是 AI 的問題，而是企業如何運用 AI 的問題。

補充說明：當公司不成長時，薪資本質上就是零和分配

需要補充一個更現實的底層前提：

當一家公司本身沒有營收成長、沒有新市場擴張、也沒有產品價格重估空間時，薪資調整本質上就會變成一種內部分配問題，而不是價值成長問題。

在這種結構下：

薪資不是「創造出來的」，而是「重新分配的」
加薪不代表價值增加，而是代表其他地方的資源被壓縮
人力成本提升，會直接擠壓公司利潤或其他預算

因此在多數成本導向企業中，即使導入 AI 提升了生產力，企業的第一反應通常仍然是：

用同樣的人做更多事，而不是用更多錢回饋同樣的人。

這不是管理思維的好或壞，而是商業結構的自然結果。

另一個更現實的結論

如果從個體角度看，這會導致一個很直接的現象：

薪資成長通常不取決於公司變得更好，而取決於個體是否離開原本的定價市場。

換句話說：

在單一公司內，你是在「等待分配」
在整個市場中，你是在「參與定價」

當公司沒有新增利潤時，薪資上升空間自然有限，這時候個體能做的選擇，通常只剩下：

接受內部分配邏輯（穩定但封頂）
或進入不同市場重新定價（但伴隨風險與變動）

2026年6月24日星期三

從同步阻塞到事件驅動：一次外部 API 抽獎系統的架構重構實戰

在這次系統重構中，我們面對了一個非常典型但容易被低估的問題：註冊流程中同步呼叫外部抽獎 API，導致整個 PHP-FPM 在高延遲情境下被拖垮。

表面上這只是一個「註冊後拿 QRCode」的流程，但在實際運行環境中，它是一個高度耦合、強依賴外部系統的同步鏈路。

一、原始架構：看似簡單，但隱含風險

原始流程如下：


使用者註冊
  → Laravel Controller
  → 呼叫 MIRA 抽獎 API（HTTP blocking）
  → 取得 QRCode
  → 回傳前端

這種設計在低流量下沒有問題，但它有一個致命特性：

HTTP request thread 被外部 API 的延遲完全綁死

二、真正的問題不是效能，而是失敗模式

這個架構的問題不在平均效能，而在「尾端延遲與不穩定性」。

當外部 API 出現以下情況：

回應時間從 50ms 上升到 500ms+
間歇性 timeout
網路抖動
瞬間流量壓力

Laravel PHP-FPM 會發生：

worker 被長時間占用 → thread pool 被耗盡 → 502 / 504 cascade failure

這種問題的特徵是：

平常完全正常
一旦出問題就是系統級崩潰

三、重構目標

這次重構的核心目標不是「加速」，而是：

將不可控的外部依賴從 request lifecycle 中移除

具體目標如下：

API 回應時間 < 50ms
外部 API 延遲不影響使用者體驗
系統具備削峰能力（burst traffic handling）
支援失敗重試與最終一致性

四、新架構：事件驅動 + Queue 解耦

重構後的流程如下：


使用者註冊
  → 寫入 User / Redemption（pending）
  → dispatch Queue Job
  → 立即回傳前端

Queue Worker
  → 呼叫 MIRA API
  → 更新 Redemption 狀態

前端
  → polling / status query
  → 完成後顯示 QRCode

五、核心設計轉變

1. 從「同步結果」變成「狀態機」

系統從：


request → response（必須立即得到 QRCode）

轉為：


pending → processing → completed / failed

這代表一個重要轉變：

系統從即時一致性，轉向最終一致性（eventual consistency）

2. Controller 不再做任何外部 I/O

重構後 Controller 僅負責：

DB 寫入
狀態初始化
Queue dispatch

完全移除：

HTTP external call
long latency operation
external dependency blocking

3. Queue 成為系統的「緩衝層」

Queue 的角色不只是 background job，而是：

absorbing burst traffic + isolating external instability

它讓系統具備：

削峰能力
重試能力
故障隔離能力

4. 前端改為狀態驅動（Polling）

由於結果變為非同步，前端轉為：


POST /register
  → 200 OK (pending)

GET /redemption/status
  → completed → render QRCode

UI 的本質從：

「拿結果」

變成：

「觀察狀態變化」

六、可靠性設計：三層防護機制

為了確保不重複發券與系統穩定性，架構引入三層保護：

1. DB 層：唯一性約束


user_id UNIQUE

確保一個使用者只會產生一筆 redemption。

2. 狀態鎖：Optimistic Lock


UPDATE ... WHERE status = 'pending'

避免多個 worker 同時處理同一筆任務，防止 race condition。

3. 外部 API：Idempotency Key

使用：


redemption_id → request_id

確保：

retry 不會重複扣庫存
timeout 不會造成重複發券

七、失敗模式的轉變

原本系統失敗模式：


MIRA 慢 → request 卡住 → PHP worker 滿 → 全站 502

新系統失敗模式：


MIRA 慢 → queue backlog → 使用者等待變長，但系統不崩潰

八、Queue 設計與系統治理

1. Retry 策略

exponential backoff
retry limit
jitter 避免 thundering herd

2. Dead Letter Queue（DLQ）

避免無限失敗任務卡住系統。

3. Reconciliation Job

定期掃描：


WHERE status = 'processing'
AND updated_at < NOW() - INTERVAL 5 MINUTE

避免 worker crash 導致狀態卡死。

九、Polling 的定位

Polling 在這個架構中不是最佳解，而是：

最穩定的 baseline solution

它的角色是：

簡單
可控
不依賴長連線基礎設施

未來可進一步升級為：

SSE（中階）
WebSocket（高互動）

但本質取捨是：

push 是連線成本，polling 是請求成本

十、這次重構的本質

這次架構改造不是效能優化，而是系統設計哲學的轉換：

從「同步獲取結果」
→ 轉為「非同步狀態演進」

結論

當系統開始依賴外部 API 時，真正重要的不是速度，而是：

是否可以隔離
是否可以重試
是否可以削峰
是否不會拖垮核心服務

這次重構的核心成果是：

將一個脆弱的同步鏈路，改造成可容錯的事件驅動系統

2026年6月18日星期四

Vibe Coding 之後：為什麼 AI 時代真正重要的是 SDD（Spec-Driven Development）

生成式 AI 的出現，徹底改變了軟體開發方式。

從 GitHub Copilot、Cursor、Gemini、Claude Code 到 OpenAI Codex，現在的工程師只需要輸入自然語言，就能在幾分鐘內產生大量程式碼。

於是近兩年開始流行一個詞：

Vibe Coding

簡單來說，就是想到什麼需求，就直接交給 AI 實作。

流程看起來非常簡單：

想法
 ↓
AI
 ↓
程式碼
 ↓
上線

這種方式讓開發效率大幅提升，也讓許多非工程背景的人第一次能夠獨立完成產品原型（MVP）。

但當專案開始成長、功能開始增加、團隊開始協作時，問題也逐漸浮現。

而且問題往往不在程式碼本身。

Vibe Coding 最大的問題不是程式碼品質

許多人認為 AI 開發最大的風險是：

程式碼品質不佳
重複程式碼過多
架構混亂
AI 幻覺（Hallucination）

這些問題確實存在。

但我認為它們都只是結果。

真正的根本原因其實是：

AI 沒有商業邊界（Business Boundary）。

AI 可以理解需求文字。

但它不理解：

哪些功能現在需要做
哪些功能未來再做
哪些功能根本不需要做

例如你告訴 AI：

我要一個 CMS 系統。

AI 很可能開始建立：

使用者管理
權限管理
文章系統
分類系統
標籤系統
SEO 系統
API
Dashboard
Activity Log

最後產生數百個檔案。

但實際商業需求可能只是：

希望飯店官網首頁內容可以透過後台修改。

這時候問題不是 AI 寫錯程式。

而是 AI 做了太多不需要的事情。

結果變成：

真正需求：3 天

AI 實作範圍：3 週

這種現象其實就是：

商業需求錯位（Business Misalignment）

而這也是許多 AI 專案後期開始失控的原因。

為什麼傳統軟體開發需要規格書？

很多人認為規格書是傳統軟體開發留下來的包袱。

但規格書存在的真正目的從來不是為了寫給主管看。

而是為了建立邊界。

成熟的軟體開發流程通常長這樣：

需求分析
 ↓
規格定義
 ↓
系統設計
 ↓
開發實作
 ↓
Code Review
 ↓
測試驗證
 ↓
部署上線

這個流程的價值在於：

有明確需求範圍
有設計依據
有驗證標準
有維護文件

然而在 AI 時代，許多團隊逐漸變成：

想法
 ↓
AI
 ↓
上線

中間所有工程管理環節全部消失。

短期看起來很快。

長期卻容易造成：

技術債累積
功能重疊
文件缺失
團隊無法接手
維護成本上升

SDD 是什麼？

SDD（Spec-Driven Development）中文通常翻譯為：

規格驅動開發

它的核心概念非常簡單：

先定義規格，再讓 AI 實作。

流程變成：

需求
 ↓
Spec
 ↓
設計
 ↓
實作
 ↓
驗證

很多人看到這裡會問：

這不就是以前的規格書嗎？

其實不完全一樣。

傳統規格書與 SDD 的差異

過去的規格書主要是給人類閱讀。

而 SDD 的規格，則同時服務人類與 AI。

傳統規格書	SDD
人類閱讀	人類 + AI 閱讀
偏文件管理	偏執行驅動
更新成本高	可持續同步
容易過期	持續演化
開發參考	開發依據

如果用一句話來形容：

PRD 是給工程師看的，而 Spec 是給 AI 執行的。

這也是 AI 時代最大的改變。

規格不再只是文件。

而是直接驅動開發。

OpenSpec：AI 與人類之間的契約層

目前常見的 SDD 工具有：

Spec Kit
OpenSpec
PRD First Workflow
AI Contract First

其中我認為最容易上手的是 OpenSpec。

很多人以為 OpenSpec 是文件工具。

其實更精確地說：

OpenSpec 是 AI 與人類之間的契約層（Contract Layer）。

在傳統開發中：

Product Owner
      ↓
工程師
      ↓
程式碼

而在 AI 開發中：

Product Owner
      ↓
Spec
      ↓
AI
      ↓
程式碼

Spec 成為了人與 AI 溝通的介面。

因此 OpenSpec 的真正價值不是產生文件。

而是幫 AI 建立需求邊界。

OpenSpec 的基本流程

OpenSpec 的工作流程非常接近真實軟體開發。

1. Explore

探索需求與問題。

/opsx-explore

例如：

/opsx-explore 認證系統越來越複雜，想重構

AI 先協助分析問題，而不是直接修改程式。

2. Propose

建立提案。

/opsx-propose add-user-auth

產生：

changes/
└── add-user-auth/
    ├── proposal.md
    ├── design.md
    └── tasks.md

此時需求被正式定義。

3. Apply

開始實作。

/opsx-apply

AI 根據規格逐步完成工作。

而不是自由發揮。

4. Verify

驗證結果。

/opsx-verify

確認：

是否符合需求
是否存在風險
是否遺漏規格

5. Archive

完成後歸檔。

/opsx-archive

同步更新規格與專案知識。

AI 的角色正在改變

這也是我認為 SDD 最重要的一點。

過去大家把 AI 當成：

Code Generator

需求進去。

程式碼出來。

但這種模式很容易造成失控。

未來 AI 更適合扮演：

Spec Executor

規格進去。

程式碼出來。

看似只有一個字的差異。

但本質完全不同。

因為：

Code Generator
→ AI 自己決定怎麼做

Spec Executor
→ AI 根據規格執行

而這正是 SDD 的核心價值。

SDD 不只提升 AI 品質，也提升團隊協作能力

很多人認為 SDD 只是為了提升 AI 生成品質。

其實更大的價值在團隊協作。

當每個功能都有：

proposal
design
tasks
archive

半年後接手專案的人可以清楚知道：

為什麼要做這個功能
當初的設計理由
修改過哪些規格
哪些方案被否決

而不是只能透過：

git blame
git log

猜測歷史決策。

這對團隊維護與知識傳承非常重要。

不只後端，前端更需要需求邊界

很多人以為這種問題只存在於後端。

其實前端更常發生。

例如：

需求：

建立一個產品介紹頁。

Vibe Coding：

建立 Design System
建立 CMS
建立 Dashboard
建立 API Layer
建立 Auth
建立 i18n

結果：

200 個檔案
只用到 3 個元件

而真正需求可能只是：

一個 Landing Page

這種過度設計在 React、Next.js、Vue、Astro 生態系中非常常見。

因此需求邊界其實是所有技術棧共同面對的問題。

未來工程師最重要的能力可能不是寫程式

AI 正在快速降低程式碼生產成本。

未來工程師的價值，可能不再是：

寫更多程式

而是：

定義需求
+
建立規格
+
架構設計
+
AI 協作

程式碼本身會越來越容易產生。

但商業邏輯、領域知識與系統邊界仍然需要人類決策。

因此未來的工程師角色可能變成：

Junior
→ 撰寫程式

AI
→ 執行規格

Senior
→ 定義規格與架構

結語

Vibe Coding 並沒有錯。

它讓更多人能夠快速將想法變成產品。

但當專案規模開始成長時，

真正重要的已經不是：

如何讓 AI 寫更多程式。

而是：

如何讓 AI 在正確的邊界內寫程式。

這也是 SDD（Spec-Driven Development）存在的價值。

AI 不缺寫程式能力。

缺的是需求邊界。

而未來工程師最重要的能力，也許不再是程式碼產生者，而是規格定義者。

2026年6月13日星期六

VS Code AI 已進入 Agent 時代：豆包、MiMo 與現代 AI Coding 工具演進解析

前言

近年 VS Code 的 AI 開發工具快速演進，已從早期的「程式碼補全工具」逐步轉變為能夠理解整個專案並執行任務的 Agent 系統。

傳統 AI 工具僅能提供單段程式碼建議，但新一代工具已具備：

專案檔案搜尋能力
多檔案修改能力
自動規劃與任務拆解能力
Terminal 指令執行能力

此類能力使 AI 不再只是輔助工具，而逐漸成為開發流程中的「虛擬工程成員」。

一、VS Code AI 工具的兩種世代

1. Chat 型 AI（第一代）

代表工具：

GitHub Copilot Chat（早期模式）
基礎 LLM 外掛
部分 MiMo VS Code Extension

特徵如下：

以對話方式提供程式碼建議
無法直接操作專案檔案
無法理解整體架構
無法執行任務流程

此類工具本質仍屬於：

程式碼輔助生成工具（Code Assistant）

2. Agent 型 AI（第二代）

代表工具：

豆包 MarsCode
Cline
Claude Code
Codex CLI
Roo Code（已停止原 VS Code 擴充套件維護，轉向新產品 Roomote；社群多數使用其開源分支 Cline 延續使用）

特徵如下：

可掃描整個專案
支援跨檔案修改
可執行 Terminal 指令
具備任務拆解能力
可進行自動化工作流程

此類工具本質為：

自動化程式開發代理（AI Software Engineer）

二、豆包 MarsCode 的實際能力定位

以 VS Code 中的豆包（MarsCode）為例，其能力已超越傳統 Chat 型 AI，接近 Agent 架構。

主要能力包含：

1. 專案索引與檔案搜尋

可分析整個 Workspace，建立專案結構理解。

2. 程式碼理解與推理

可根據上下文理解函式呼叫與依賴關係。

3. 多檔案修改能力

可同步修改 Controller、Service、Model 等多層架構。

4. 任務執行能力（部分情境）

可輔助執行測試或 CLI 指令。

三、MiMo VS Code 外掛的定位

MiMo 在 VS Code 中的整合方式屬於「Chat + IDE 插件型態」。

主要功能包含：

側邊欄對話介面
API Key 設定整合
程式碼問答與生成
基礎 Debug 支援

但其能力仍主要集中於：

單點程式碼輔助，而非完整任務執行

相較於 Agent 型工具，其差異在於：

無完整任務規劃能力
無跨檔案自動修改流程
無持續性專案記憶機制（依實作而定）

四、Agent 型工具與 Chat 型工具差異比較

能力	Chat 型 AI	Agent 型 AI
程式碼生成	✔	✔
理解單檔內容	✔	✔
專案結構理解	✘	✔
多檔案修改	✘	✔
Terminal 執行	✘	✔
任務拆解	✘	✔
自動完成工作流程	✘	✔

五、實務應用差異（以 Laravel 專案為例）

以新增 Filament Resource 並整合多語系 SEO 為例：

Chat 型 AI 行為：

提供單一 Resource 範例
提供 SEO 欄位設計建議
開發者需自行整合至專案

Agent 型 AI 行為：

掃描既有 Resource 結構
分析專案架構（Service / Model / Action）
自動生成 Migration
自動建立 Resource
更新 Validation 與 Translation
檢查一致性

六、AI 開發工具的核心轉變：從模型到上下文

現代 AI Coding 工具的關鍵不再是模型本身，而是：

Context Engineering（上下文工程）

核心問題轉變為：

AI 是否理解專案架構
是否具備長期記憶能力
是否能跨檔案維持一致性
是否能依規範生成程式碼

因此工具競爭焦點已從模型能力轉向：

專案理解能力與工作流整合能力

七、開發工具選擇趨勢

目前主流工具大致可分為三類：

1. Copilot 類（補全型）

適合輕量開發
以提示與補全為主

2. IDE Agent 類（半自動）

Roo Code（社群分支使用為主）
Cline
豆包 MarsCode

適合日常開發與中型專案

3. CLI Agent 類（全自動）

Claude Code
Codex CLI
MiMo Code（新興）

適合大型重構與自動化任務

八、結論

VS Code AI 工具已進入明確的 Agent 化階段。

豆包、Cline 等工具已不再只是程式碼輔助工具，而是能夠實際參與專案開發流程的自動化代理。

MiMo VS Code 外掛則仍屬於過渡型產品，其真正值得關注的方向在於 Agent 化的 MiMo Code 生態。

未來 AI Coding 的競爭重點將不再是模型能力，而是：

AI 是否能持續理解並操作完整開發專案。

2026年6月7日星期日

AI 時代工程師面試攻略：資深工程師如何駕馭 AI，而不是被 AI 取代

近兩年，幾乎每一場技術面試都會被問到這個問題：

「你平常怎麼使用 AI 開發？」

很多工程師的回答還停留在：「我每天用 Cursor」、「70% 程式碼是 AI 寫的」、「我 Prompt 寫得很好」。這些答案現在已經毫無鑑別度，因為大家都在用 AI。

技術主管真正想聽的，不是你用了哪些工具，而是你如何駕馭 AI，以及當 AI 出錯時，你是否有能力發現並守住系統底線。

以下內容全部來自我實際開發 多租戶 SaaS、租貸/金融流程、狀態機與金流系統，以及 legacy 重構、高壓 deadline 專案的真實經驗。

一、AI 在複雜系統中有明確的天花板

在簡單 CRUD 專案中，AI 看起來幾乎無所不能。但在真正的 Production 系統（尤其是 SaaS + Multi-tenant + Financial Domain）中，它會明顯失效：

1. Multi-tenant 邊界問題（AI 最常犯錯）

Background job 沒有帶 tenant context
Cache key 未做 tenant 隔離
ORM Global Scope 被 bypass
Eager Loading 導致跨租戶資料外洩

這不是語法問題，而是系統邊界設計問題。

2. 金流 / 租貸狀態機複雜度 典型租貸流程：

text

申請 → 審核 → 撥款 → 還款 → 違約 → 追償

AI 常見問題：

State transition 缺少 invariant 檢查
Retry 沒有 idempotency key
缺少 compensation / rollback 流程
Event ordering 無法保證

AI 寫出來的東西「看起來合理」，但放到 Production 會出大事。

3. 系統一致性與分散式問題

Eventual consistency 的 race condition
Queue 重試導致 double execution
Transaction boundary 不明確
Partial failure 的恢復策略缺失

這些都是 architecture 層級 的問題，而非單純 coding。

二、我的核心定位：AI 是能力很強的 Junior Engineer

我把 AI 明確定位為「能力很強，但缺乏 domain context 的 Junior Engineer」。因此我的開發方式不是「讓 AI 寫 code」，而是我先設好約束，AI 在約束內全力加速。

三、實務開發流程（面試時可直接分享）

Step 1：人類先定義 Domain Boundary（最重要） 獨立完成：

Tenant isolation strategy
Domain model（Loan、Repayment、Ledger、Risk）
State machine 與不可逆轉規則
Consistency boundary（Transaction vs Event）

這一步 AI 完全不參與。

Step 2：設計系統 Invariant（防 AI 犯錯的關鍵） 明確定義系統安全規則，例如：

同一筆 loan 不可重複撥款
Tenant 資料不可跨 query 污染
Ledger 必須 double-entry 平衡
所有 event 必須 idempotent

Step 3：AI 加速 Implementation 讓 AI 負責：

CRUD API
Service layer boilerplate
Migration / Schema
Validation / DTO
Unit Test 初稿
重構建議

實際效果：開發效率提升約 2～3 倍。

Step 4：人工嚴格 Review（Architecture Review） 重點檢查：

Tenant boundary 是否被破壞
State machine 是否 drift
Idempotency / Compensation 是否完整
Failure scenario 是否涵蓋
Async job 是否安全

Step 5：Production 驗證 Integration Test、Sandbox Replay、Shadow Traffic、Feature Flag 逐步 rollout（AI 幾乎不參與）。

四、面試推薦回答（建議直接背或微調）

當面試官問：「你平常怎麼使用 AI 開發？」可以這樣回答：

「我把 AI 視為 production development 的加速工具，但不是 system design 的決策者。在開發多租戶 SaaS 或租貸金融系統時，我會先自己定義 domain model、tenant isolation 邊界、state machine 與一致性規則，這些是系統正確性的核心。 AI 則專注在 implementation layer，例如 CRUD、API skeleton、migration、validation 與 unit test，能讓效率提升大約 2～3 倍。但 multi-tenant isolation、金流一致性、狀態機轉換與 retry/idempotency 等關鍵部分，我會全程主導設計與 review，因為這些錯誤在 production 是不可接受的。 AI 解決的是寫程式的效率，而工程師解決的是系統在 production 的正確性與風險控制。」

五、主管真正想評估什麼

你是否做過真正的複雜系統（multi-tenant + finance + state machine）
你是否有 System Thinking，而非僅限 function thinking
你是否敢為 Production 結果負責

六、結論：一句話總結

可以寫 code ≠ 工程師 可以用 AI ≠ 資深工程師 能定義 AI 不該碰的邊界、掌控複雜 domain 風險、並對 Production 結果負責 = 真正的工程能力

AI 時代，程式碼產出速度已經被快速拉平。未來企業真正需要的，是能駕馭 AI、守住系統底線、並為長期穩定負責的資深工程師。

這篇文章不僅是面試攻略，更是我在多租戶 SaaS 與金融系統實戰中的心得分享。希望對正在準備面試、或正在導入 AI 開發流程的工程師有幫助。

如果你有類似經驗，歡迎留言交流！也歡迎轉發給正在準備技術面試的朋友。

2026年6月6日星期六

AI 時代的資訊檢索演進：從 SEO Ranking 到 LLM Retrieval / GEO

以下內容來自實際內容策略、系統設計與 AI 工具應用經驗，並非理想化理論。

AI 放大的是資訊獲取速度，但內容的本質仍是「被理解與信任」。

從系統設計角度來看，SEO 與 GEO 本質上都是資訊檢索（Information Retrieval）問題，只是優化目標從「ranking function」轉移到「LLM context selection / grounding」。

從工程角度來看，這是一個 retrieval pipeline 的演進問題：從 keyword-based retrieval → semantic retrieval → LLM-based grounded generation。

這就是 SEO → GEO（Generative Engine Optimization） 的本質轉變。

一、AI 時代下 SEO 的本質沒有消失，只是被重新定義

傳統 SEO 常見的失效做法：

Keyword stuffing
內容農場式 SEO 文章
資訊密度低但格式正確的薄內容

這些內容在 AI 時代極易被跳過，因為 AI 的目標是資訊壓縮與合成，而非單純列出連結。

新 GEO 的核心三要素：

可理解性（Understandability） AI 是否能快速、準確抽取語意，而非只抓關鍵字。
可驗證性（Verifiability） 是否有明確來源、數據、引用與更新日期。
可信任性（Trust） 是否符合 E-E-A-T（Experience、Expertise、Authoritativeness、Trustworthiness）。

二、SEO → GEO 的工程視角轉變

層級	SEO（傳統）	GEO（生成式）
系統目標	Index Ranking System	LLM Retrieval Selection
資訊單位	Page-level	Chunk / Entity-level
優化目標	Page-level Optimization	Chunk / Entity-level Optimization
成功指標	Search Engine Ranking	Grounded Response Inclusion

GEO 真正優化的是 Retrieval + LLM Grounding：

SEO → 優化 Indexing
GEO → 優化 Retrieval（被找到）與 Summarization / Grounding（被正確合成）

三、實務中的 GEO 做法（非理想化版）

1. 內容結構化 使用清晰標題階層、表格、bullet points、Inverted Pyramid（結論前置），並加入 Schema Markup，讓 AI 更容易解析。

2. 強化 E-E-A-T 信號

展示作者真實經驗與背景
提供可驗證數據與第一手案例
定期更新並標註日期
獲得外部權威引用

3. 現實取捨 不是所有頁面都要全力 GEO，優先處理高價值、常被查詢的 Pillar Content。在 deadline 壓力下，先確保核心內容具強結構與信任信號。

結論

SEO 沒有被淘汰，而是從「排名優化」進化成「LLM 檢索與引用優化」。

本質上，GEO 的核心不是內容優化，而是降低 AI 在 retrieval 與 grounding 時的不確定性。

在 AI 時代，贏家不是產出最多內容的人，而是能讓 AI 願意正確引用且放心 grounding 的人。

真正的核心競爭力，仍然是定義清晰、可驗證且值得信任的知識邊界。

AI 時代的軟體工程實務：資深工程師如何在不確定性中控制系統風險

以下內容來自實際 production 環境經驗（包含 legacy 系統維護、重構專案與 deadline 壓力場景），並非理想化流程。

近年媒體不斷報導「AI 即將取代工程師」「會寫 Prompt 就能開發系統」，讓許多人嚴重誤解 AI 在軟體工程中的角色。

AI 放大的是產出速度，但工程本質是約束設計與風險控制。

在 AI 時代，軟體工程的核心不再是寫程式，而是定義與維持系統的約束邊界（Constraints）。 這包括業務規則、技術限制、風險邊界與長期可維護性。AI 能快速產出程式，但無法替你建立這些約束——這正是資深工程師真正的價值所在。

一、AI 時代的能力分層：產出能力 ≠ 工程能力

AI 讓「寫 code」的門檻大幅降低，卻也製造了一個危險的錯覺——好像只要會用 AI，就能成為工程師。

但在生產環境中，AI 只強化了產出速度，並沒有強化以下核心工程能力：

系統設計能力（System Design）
風險判斷與邊界控制（Risk & Boundary）
資料一致性與正確性把關
長期維護與技術債管理

初級使用者與資深工程師的真正差異：

初級使用者：

把 AI 當成解題工具
直接接受 AI 輸出結果
事後用測試驗證

資深工程師：

先定義系統的約束邊界與風險
再讓 AI 在嚴格限制內加速產出
所有輸出都經過架構一致性與業務正確性檢查

核心結論：會用 AI → 可以寫 code 會控制 AI → 才是工程師能定義與維持 AI 的約束邊界 → 才是資深工程師

現在真正的競爭差異，不是誰寫 code 比較快，而是誰能確保 AI 產出的東西在 production 是安全的。

二、實務方法：如何在約束邊界下安全使用 AI

理解能力分層之後，以下是具體的落地做法。這些方法不是理想流程，而是考慮 deadline、legacy code、團隊成熟度差異後的 80/20 打法。

1. 需求拆解：知道什麼時候該偷懶

現實中不可能每次都完整拆解。重點是依風險分級建立約束：

高風險部分（金流、權限、資料一致性、審計）必須人類親自定義邊界與風險。
一般 CRUD：讓 AI 協助整理規格 + 產出反向測試案例。
Legacy 系統：用 AI 先分析呼叫鏈與資料流，再決定重構範圍。

關鍵在於知道什麼時候絕對不能妥協，這正是約束設計的起點。

2. 系統設計：先有人類框架，再讓 AI 滲透

設計永遠不能跳過，而是先由人類定義核心約束：

核心模組：寫簡短 ADR 或文字架構，明確定義邊界與限制。
次要功能或緊急修正：把既有架構風格與約束塞進 prompt，讓 AI 產生候選方案後人工調整。
Deadline 極限：先做「夠用設計」，但一定要排後續技術債。

AI 在此階段只能當設計助手。你必須持續餵上下文，避免 context drift。

3. AI 的日常定位：能力強但極度不可預測的 Junior

AI 是滲透在整個開發循環的加速器，而非單一步驟。它的最大問題是不可預測性：

Hallucination（幻覺）
Silent Failure（隱藏錯誤）
Overconfident Output（過度自信）

適合大量使用 AI 的場景（在明確約束下）： CRUD、boilerplate、DTO、validation、migration、單元測試生成、複雜 SQL、重構建議、legacy 轉現代骨架。

必須人類主導的場景（強約束）： 金流、權限模型、多租戶隔離、並發控制、高業務風險或法規邏輯。

4. 工程審查：把 AI 產出當「可能帶毒的草稿」

這一步最能體現維護約束邊界的能力：

檢查是否違反先前定義的架構約束
特別注意 silent failure 與 edge case
要求 AI 先自我列出「這段 code 可能出現的 5 個潛在問題」

定期進行「AI 技術債健診」，避免隱藏風險突破邊界。

5. 測試與驗證：壓力越大越不能省

AI 讓寫 code 變快，也讓 bug 出現更快。因此必須強化驗證約束：

核心路徑必須有 integration test
高風險功能強制 sandbox + shadow testing + feature flag
AI 適合大量產生測試案例，但「哪些測試真正重要」永遠由人類判斷

結論