2026年7月26日 星期日

當工程師的價值不再只是寫 Code,公司還看得見你的貢獻嗎?

 最近跟 AI、軟體開發流程轉變相關的討論越來越多。

很多人關注的是:

  • AI 會不會取代工程師?
  • 未來還需不需要寫 Code?
  • 工程師應該學什麼新技能?

但有一個更現實的問題,可能很多工程師每天都正在面對:

當你的工作價值不再只是「寫多少 Code」,公司是否還有能力看見你的貢獻?


傳統工程價值:時間與產出

很多公司的管理方式,仍然建立在一個簡單模型:

投入時間
    ↓
完成需求
    ↓
交付功能

因此工程師的價值容易被衡量為:

  • 花多少工時
  • 完成多少 Ticket
  • 寫多少功能
  • 解多少 Bug

這種方式對明確需求非常有效。

例如:

  • 新增一個 API
  • 修改一個頁面
  • 增加一個欄位

這些工作確實可以透過時間估算。

但問題在於:

軟體工程真正困難的地方,往往不是把功能做出來。


高價值工程工作,很多時候看不到立即產出

一個工程師花三天整理:

  • 共用 Service
  • 權限架構
  • 多語系處理
  • API 規範
  • 資料驗證流程

表面上看:

三天沒有新增功能。

甚至可能有人會問:

為什麼這個需求花了三天,畫面還沒有完成?

但實際上,這三天可能避免未來十個、二十個功能重複踩坑。

這類工作創造的是:

  • 降低未來維護成本
  • 減少重複開發
  • 降低錯誤風險
  • 提升團隊整體開發速度

只是這些價值通常不會立即出現在畫面上。


越有效率,有時反而越難被看見

這也是很多資深工程師會遇到的矛盾。

假設:

工程師 A:

花 10 天完成一個功能

工程師 B:

花 3 天建立共用架構,並完成同樣功能

短期看:

B 好像「少花時間」。

但長期看:

B 建立的能力可能讓後續 20 個功能都變快。

問題是,如果公司只看:

需求 → 工時 → 完成

那 B 創造的價值很容易被忽略。


工程師與管理者看到的是不同尺度

工程師思考的是:

現在的設計
        ↓
半年後、一年後的維護成本

管理者通常關注的是:

目前專案
        ↓
交付時間與成本

兩邊其實沒有誰對誰錯。

只是看的時間尺度不同。

真正困難的是:

如何把長期價值轉換成短期可以理解的資訊。


AI 會讓這個落差更加明顯

以前工程師的效率差異,可能來自:

  • 熟悉 Framework
  • Coding 速度
  • 累積經驗

但 AI 出現後:

很多工程師都能快速產生 Code。

未來差距會逐漸變成:

  • 誰能定義正確問題
  • 誰能設計合理架構
  • 誰能判斷 AI 產出的品質
  • 誰能控制系統風險

也就是:

未來工程師的價值,不只是「產生程式碼」。

而是:

確保產出的系統正確、可靠、可維護。


但公司不一定會自動改變衡量方式

這是很多工程師真正困擾的地方。

你可能開始投入:

  • 架構改善
  • 技術債整理
  • 共用元件建立
  • 開發流程優化

但績效評估仍然是:

  • 完成幾個需求
  • 花多少時間
  • 解多少工單

於是產生一個矛盾:

越有經驗,越能提前避免問題,但越難被工時計算。


工程師需要學會「呈現價值」

不要只說:

我完成了多語系架構。

改成:

建立共用多語系架構,讓後續新增功能可以沿用標準流程,降低重複開發與維護成本。

不要只說:

我整理了權限系統。

改成:

統一權限管理流程,降低新增角色時的設定錯誤風險。

不要只說:

我新增 Audit Log。

改成:

建立操作追蹤能力,讓資料異動可以被追溯,降低問題排查成本。

同一件事情,用不同語言描述,價值感完全不同。


未來工程師需要增加的一項能力:技術溝通

很多工程師很重視:

  • 程式品質
  • 架構設計
  • 效能最佳化

但忽略另一件事情:

讓非工程背景的人理解你的價值。

企業不是只購買 Code。

企業真正需要的是:

  • 降低風險
  • 提升效率
  • 建立可持續發展的系統

而 Code,只是實現這些目標的工具。


結語:工程師不只是寫 Code 的人

很多工程師擔心:

AI 讓寫 Code 變便宜,那工程師還有價值嗎?

但真正的問題可能不是:

誰寫 Code 比較快?

而是:

誰能讓系統長期穩定運作?

當 AI 越來越強,單純產出程式碼的價值可能下降。

但:

  • 系統設計能力
  • 問題分析能力
  • 風險控制能力
  • 技術決策能力

反而會更加重要。

工程師真正需要提升的,不只是寫更多 Code。

而是成為那個:

能判斷該寫什麼、不該寫什麼,並且讓 AI 安全產生價值的人。

同時,也要開始練習用對方聽得懂的語言,把長期價值說清楚。

因為在組織裡:

沒有被理解的價值,很容易等同於不存在。


為什麼公司一直用工時衡量工程師?

先承認一件事:

公司用工時衡量工程師,不一定是因為管理者不懂技術。

而是因為工時有三個很實際的優點:

  • 容易估算成本
  • 容易安排資源
  • 容易追蹤專案進度

如果今天客戶問:「這個功能多久完成?」 老闆不可能回答:「等我們把架構整理好。」

所以工時本身沒有錯。 錯的是,當工時變成唯一的價值指標。

AI 時代,工時開始失去代表性

以前,工程師花八小時完成一個功能,大家會認為:八小時,就是這個功能的成本。

現在,AI 可以讓同一個功能兩小時完成。

那問題來了:

如果公司還是認為「花越多時間,代表價值越高」,是不是代表效率越高的人,反而越吃虧?

這就是 AI 時代開始出現的矛盾。

真正有價值的工作,很多是在「避免事情發生」

我們很少稱讚一個系統:「今天沒有當機。」 很少稱讚一位工程師:「今天沒有發生權限漏洞。」 很少有人注意:「今年沒有因為資料結構設計錯誤而重寫系統。」

因為避免問題,本來就不容易被看見。

但是成熟的工程師,很多時間都花在:

  • 避免 Bug
  • 避免資安漏洞
  • 避免技術債
  • 避免未來重工
  • 避免部署失敗

這些事情成功的結果就是:什麼事都沒有發生。

而「沒有發生」,最難證明價值。

AI 不會讓這個問題消失,只會放大它

AI 可以更快寫出程式,但 AI 沒辦法保證:

  • 這個架構五年後還能維護
  • 這個 Migration 不會影響舊資料
  • 這個權限模型沒有安全漏洞
  • 這個設計不會讓團隊之後一直付出維護成本

所以未來真正值錢的,不一定是寫了多少 Code,而是避免了多少錯誤決策。

可惜的是,這種價值很難寫進工時表。

我想讓管理者思考一個問題

如果有兩位工程師:

A 工程師 每個功能都花 5 天完成。 三年後系統充滿技術債。

B 工程師 花 7 天建立共用架構。 後續每個功能都只需要 2 天。

如果只看第一個功能,A 的績效可能比較好。 如果看三年,答案可能完全相反。

那麼,我們到底是在衡量「投入多少時間」,還是在衡量「創造多少價值」?

結語

AI 正在改變工程師的工作方式,但如果企業衡量工程價值的方法沒有一起改變,那真正被低估的,不是工程師,而是那些原本可以被創造出來的長期價值。

我如何用 AI 開發 Laravel 專案:從 Prompt Driven Development 到 Spec Driven Development

最近 OpenAI 一連串產品與模型方向的調整,透露出一個很明顯的趨勢:

ChatGPT 正從「回答問題的 AI」逐漸走向「能理解目標、操作工具、協助完成工作的 AI Agent」。

這代表工程師與 AI 的合作方式,也正在改變。

過去我們使用 AI 大多是:

text
需求
 ↓
撰寫 Prompt
 ↓
AI 產生 Code
 ↓
人工 Review

但未來更接近:

text
需求
 ↓
AI 分析專案上下文
 ↓
提出修改計畫
 ↓
建立 Patch
 ↓
執行測試
 ↓
人類確認與決策

差異不只是「AI 會不會寫 Code」。 真正的改變是:工程師的價值,正在從「產生程式碼」轉向「設計系統、管理複雜度、驗證結果」。

一、未來更重要的工程能力,不是打字速度

AI 可以快速產生大量程式碼,但以下能力仍然需要工程師判斷。

1. 問題定義與範圍控制

很多軟體問題,真正困難的地方不是實作,而是:

  • 需求到底要解決什麼?
  • 哪些事情不應該做?
  • 哪些舊邏輯不能破壞?
  • 什麼才算完成?

如果需求本身模糊,AI 只會更快產生錯誤答案。 所以未來工程師最重要的能力之一,是把模糊需求轉換成清楚規格。

2. 系統設計與技術取捨

AI 可以提出很多方案,但「哪個方案適合現在的系統?」仍然需要工程判斷。

例如:

  • 要不要抽 Service Layer?
  • 要不要增加 Repository?
  • JSON 欄位是否需要正規化?
  • 權限是否應該拆分?
  • 這次需求是否值得增加抽象層?

這些不是 Code Generator 可以單純決定的事情。

3. 驗證 AI,而不是相信 AI

最大的風險不是 AI 不會寫,而是 AI 寫出看起來合理,但實際有問題的 Code。

常見例子:

  • Migration 可以執行,但破壞資料相容性
  • Policy 通過測試,但權限邊界錯誤
  • API 回傳正常,但多語系 fallback 有漏洞
  • Refactor 後功能正常,但未來維護成本增加

因此,Code Review、Testing、Audit Log、Rollback 機制的重要性只會提高。

二、工程師應該建立新的 AI 協作習慣

1. Think Before Code

不要收到需求後直接說「幫我寫這個 Feature」。

更好的流程是先要求 AI:

  • 分析現有架構
  • 找出影響範圍
  • 提出修改方案
  • 列出風險

確認方向後,再開始 Coding。

2. 從 Prompt Engineering 走向 Spec Engineering

很多人研究「怎麼寫更好的 Prompt」,但未來更重要的是「怎麼寫更好的 Spec」。

好的 Spec 應該包含:

  • 背景與目的
  • 功能範圍
  • 非目標項目
  • 資料結構
  • API 定義
  • 權限規則
  • 測試條件
  • 已知限制

AI 的能力越強,規格品質的重要性越高。

3. 把 AI 當 Junior Engineer

AI 很像一位能力很強,但不了解公司文化與歷史的新進工程師。

你不能只說「幫我完成這個功能」,然後期待完美結果。

更好的方式是:

text
先分析
↓
提出計畫
↓
等待確認
↓
修改
↓
測試
↓
回報結果

這也是為什麼未來 Permission Control、Change Log、Audit Trail、Approval Flow 會越來越重要。

三、Laravel / 後端工程師可以怎麼準備?

如果你的工作主要是 Laravel、Filament、CMS、API 系統,可以開始練習:

不要: 幫我建立一個 User Resource

改成: 請先分析目前 User、Role、Permission 架構,確認影響範圍,提出 Filament Resource 修改計畫,列出 Migration、Model、Policy、Test 需要調整的地方。

不要: 幫我重構這段 Code

改成: 請先分析這段程式是否符合 SRP、KISS、DRY、Clean Architecture,再提出最小修改方案。

這樣 AI 才會從「Code Generator」變成「工程協作者」。

四、未來工程師競爭力會重新排序

以前:

text
Coding 速度
+ 熟悉 Framework
+ 累積 Code 量

可能代表較高效率。

但未來:

text
需求分析能力
+ 系統設計能力
+ AI 協作能力
+ 驗證與風險控制能力

會越來越重要。

因為當所有工程師都能使用 AI 產生 Code 時,差距就不會存在於「誰寫得快」,而是在:

  • 誰知道該寫什麼
  • 誰知道哪些不能寫
  • 誰能判斷 AI 的結果是否可靠

結語

AI Agent 時代真正改變的,不是工程師不用寫 Code,而是工程師不應該只停留在寫 Code。

未來更有價值的工程師,會是那些:

  • 能把需求變成規格的人
  • 能設計系統邊界的人
  • 能管理 AI 工作流程的人
  • 能承擔最後品質責任的人

AI 不會取代工程師。 但使用 AI 的工程師,會逐漸取代不會使用 AI 的工程師。

而最重要的起點就是:

AI 是 Junior Engineer,不是神諭機。

2026年7月17日 星期五

Kilo 與 Google 開發工具:AI 自動化開發的現在與未來

AI Coding 正在進入 Agentic Development 時代

傳統 AI 編碼工具主要聚焦於程式碼補全與即時建議,能有效減少重複輸入,但開發者仍需親自負責架構設計、任務拆解、測試撰寫與流程管理。

Agent Workflow 讓 AI 能執行多步驟操作,包括讀取專案檔案、運行終端指令、進行驗證,並根據結果迭代。Agentic Development(代理式開發)則代表更進一步的演進:AI 代理成為開發流程的主動參與者,具備規劃、分解任務、平行執行與自我驗證的能力。開發者轉向更高階的工作——定義願景、設定規則與審核最終成果。

根據目前公開的官方文件與開發社群共識,這一轉變能幫助團隊處理更複雜的專案,並提升整體開發效率。

Kilo Code 是什麼?

Kilo Code 是一款開源 AI Coding Agent,可在 VS Code、JetBrains IDE、CLI、Cloud 與 Slack 等多種環境中運行。它強調模型中立性、代理協調能力與透明度。

主要特性(依官方網站描述):

  • Model Agnostic:支援數百種模型,包含 Google Gemini 系列、OpenAI、Anthropic 等。透過 BYOK(Bring Your Own Key)方式直接連接供應商 API,無額外加價。
  • Multi Agent 與 Parallel Agents:支援同時運行多個代理,可在不同工作區獨立作業。
  • Multi Mode:內建 Architect(架構規劃)、Code(實作)、Debug(除錯)、Ask(查詢)、Orchestrator(協調)等模式,並允許自訂。
  • 平台支援:VS Code 擴充、JetBrains 外掛、CLI(終端介面)、Cloud Agents 與 GitHub 整合。
  • MCP(Model Context Protocol):用於擴充代理工具能力。
  • AGENTS.md 支援:這是逐漸在多個 Agent 工具中形成共識的專案規範方式,Kilo 也提供良好支援。
  • 其他功能:Sessions 跨裝置同步、自動化程式碼審核等。Browser Automation 等進階功能則視代理權限與工具設定而定。

與其他工具定位差異: 相較於 Cursor(強調流暢 IDE 體驗)、Claude Code(聚焦特定模型的強大推理)或終端導向的 CLI 工具,Kilo 在跨平台代理編排與開源彈性上提供更多選擇,特別適合需要靈活整合多種模型與工具的開發團隊。

Google AI 開發工具生態

Google 持續投入 Agentic 開發工具,主要圍繞 Gemini 模型與相關平台展開。

  • Gemini 系列模型:包含 Gemini Flash 系列(適合高效率、低成本工作負載)與 Gemini Pro 系列(適合需要較強推理能力的大型或複雜任務)。
  • Gemini API:提供程式化介面,讓開發者將模型與代理能力整合至自有系統。
  • Google AI Studio:適合快速原型開發,可從自然語言描述生成應用初步架構,並與 Firebase 等服務整合。
  • Antigravity:Google 推動 Agent Workflow 的重要平台之一,包含桌面應用、CLI 與 SDK 等形式,支援代理協調與驗證機制。根據公開資訊,它是 Google 在 Agent-first 開發方向上的重點投入。
  • 相關 CLI 工具:Gemini CLI 已逐步朝向更整合的 Agent 體驗演進(具體以官方最新公告為準)。

角色分工(依官方定位):

  • Prototype:AI Studio 適合快速驗證想法。
  • Production 與 Agent Workflow:Antigravity 等平台提供更完整的代理管理與企業級支援。

Kilo + Google 開發工具為什麼是好的組合?

Kilo 的開放架構與 Google 的 Gemini 模型可形成互補:

  • Gemini Flash / Pro 系列在上下文處理與推理上具備優勢,Kilo 則能有效載入專案全貌與 AGENTS.md 規範。
  • Kilo 的 Multi Mode 與 Parallel Agents 可發揮模型在規劃、Debug、Refactor 與測試上的能力。
  • BYOK 模式讓開發者能按官方費率使用 Gemini,搭配 Kilo 的 Auto Model 等機制優化成本。
  • Git 相關工作流(如 Commit 與 PR)可在 Kilo 中結合 Gemini 推理完成。

此組合特別適合希望同時享有模型效能與工具彈性的團隊。

新增章節:為什麼 Kilo 比 Cursor 更適合大型專案?

許多工程師在評估工具時,會將 Cursor 與 Kilo 放在一起比較。兩者定位有明顯差異:

面向Cursor(典型)Kilo(典型)對大型專案的影響
核心定位AI 幫你寫程式AI 幫你完成專案Kilo 更強調端到端
Agent 模式單 Agent 為主Multi Agent + Orchestrator大型專案易平行處理
開發流程Prompt 驅動 + ChatSpec + Rule Driven Workflow更易維持一致性
模型選擇較集中數百種模型 + BYOK成本與效能更靈活
平台整合強 IDE 體驗IDE + CLI + Cloud + GitHub跨團隊、跨裝置優勢
規則系統有限支援AGENTS.md + 完整 Rules大型團隊規範管理佳

結論:Cursor 在日常快速編碼上體驗優秀,而 Kilo 在大型專案的架構一致性、多代理協作與規則驅動開發上提供更多支援。兩者可依專案規模與團隊習慣選擇或結合使用。

Agent Workflow 範例(Laravel + Vue 專案)

需求:為電商後台新增訂單管理功能。



此流程可在 Kilo Orchestrator Mode 中啟動,開發者主要負責審核 Spec 與最終成果。

Spec Driven Development

單純的 Prompt 在複雜專案中容易導致不一致或遺漏。Spec Driven Development 強調先產生結構化的規格文件,再讓代理依據 Spec 執行。

Kilo 透過 AGENTS.md 與 Rules 系統支援此做法;Google Antigravity 等平台也有類似機制(如 Hooks 與專案規則)。Spec 比 Prompt 更易驗證與維護,是大型專案的重要實踐。

Rule System

推薦專案結構

text
.project-root/
├── AGENTS.md
├── .kilo/
│   └── rules/
│       ├── coding-style.md
│       ├── api-standards.md
│       └── testing.md
└── .specs/

Laravel 規則範例(coding-style.md 片段):

Markdown
## Laravel 開發規範
- 遵循 Repository Pattern
- Service Layer 負責業務邏輯
- 使用 Form Request 作為 DTO
- API 回應統一使用 Resource 類別
- Git Commit Message 遵循 Conventional Commits

Rule System 對大型團隊特別重要,能確保程式碼風格、架構決策與安全規範的一致性,減少審核負擔並加速新人融入。

與其他工具比較

(已依回饋調整為更保守描述)

工具開源多模型支援Agent 能力Multi AgentRule SystemBYOKGitHub 整合MCPCLIIDE 支援適合情境
Kilo完整支援VS Code / JetBrains大型專案、靈活代理編排
Cursor有限有限有限支援Cursor IDE快速日常開發
Claude Code有限有限部分支援 (CLAUDE.md 等)有限多平台強推理單任務
Antigravity (Google)部分Gemini 為主是 (Hooks 等)桌面 / CLIGoogle 生態 Production

真實案例與社群反饋

官方目前尚未公布具體採用統計或企業案例。社群討論(GitHub、Reddit 等)顯示,開發者常用 Kilo 處理端到端功能開發與規則驅動工作流。Google Antigravity 則在官方展示中強調複雜代理任務。建議直接參考官方 Blog 獲取最新 Showcase。

2026 趨勢

  • Agent First Development:平台從輔助工具轉向代理指揮中心。
  • Multi Agent Collaboration:平行子代理與人類審核的混合模式。
  • Rule / Spec Driven 開發:成為大型專案標準。
  • Self-improving 與 Auto Review 機制逐漸成熟。
  • 跨平台無縫體驗(IDE + CLI + Cloud)。

如何開始使用

  1. 安裝 Kilo:前往 Kilo 官方網站 下載 VS Code 擴充或執行 CLI 安裝指令。
  2. 設定模型:加入 Google Gemini API Key(或其他供應商),利用 BYOK 功能。
  3. 建立 Rules:在專案根目錄新增 AGENTS.md 與 .kilo/rules/ 目錄。
  4. 產生 Spec:使用 Architect Mode 讓代理協助建立規格文件。
  5. 執行第一個 Workflow:在 Orchestrator Mode 描述高階需求,觀察代理執行並進行審核。

FAQ

  • Kilo 是否一定要使用 Gemini? 不需要。它支援 Claude、OpenAI、Ollama、本地模型、DeepSeek、Qwen 以及 OpenRouter 等,這是 Kilo 的重要優勢之一。
  • 安全性如何確保? 建議使用 Sandbox 模式、明確權限設定,並人工審核重要變更。
  • 適合大型團隊嗎? 是的,Rules 系統與 Cloud Agents 有助於標準化與協作。

參考資料(優先官方來源):

  • Kilo 官方網站 與 文件
  • Kilo GitHub 儲存庫(包含 AGENTS.md 相關討論)
  • Google AI 官方文件、Google Developers Blog 與 Antigravity 相關公告
  • 其他工具比較參考各官方網站公開資訊

SEO Title(5 組)

  1. Kilo 與 Google 開發工具:Agentic Development 實務指南
  2. Kilo Code + Gemini:大型專案 AI 自動化開發完整解析
  3. Spec Driven Development 與 Kilo Rules 系統實戰
  4. 2026 AI Coding 趨勢:Kilo vs Cursor 定位比較
  5. 從 AGENTS.md 到 Multi Agent:Kilo 與 Google Antigravity 應用

SEO Description(5 組)

  1. 專業技術文章,深入探討 Kilo Code 與 Google Gemini、Antigravity 的整合,包含 Workflow 範例、Rules 實務與大型專案比較。
  2. 中高階工程師必讀:Agentic Development 時代的工具選擇與最佳實踐。
  3. 提供 Mermaid 流程圖、Laravel 範例與保守客觀分析的 Kilo + Google 開發指南。
  4. 了解 Kilo Multi Agent 優勢、Spec Driven 方法與 2026 開發趨勢。
  5. 適合技術部落格或公司內部分享的 AI 自動化開發長文。

Meta Keywords:Kilo Code, Agentic Development, Google Gemini, Antigravity, Rules System, AGENTS.md, Spec Driven Development, AI Coding Workflow

Slug:kilo-google-agentic-development-guide-2026

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 型 AIAgent 型 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 的正確性與風險控制。」

五、主管真正想評估什麼

  1. 你是否做過真正的複雜系統(multi-tenant + finance + state machine)
  2. 你是否有 System Thinking,而非僅限 function thinking
  3. 你是否敢為 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 的核心三要素:

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

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

層級SEO(傳統)GEO(生成式)
系統目標Index Ranking SystemLLM Retrieval Selection
資訊單位Page-levelChunk / Entity-level
優化目標Page-level OptimizationChunk / Entity-level Optimization
成功指標Search Engine RankingGrounded 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 適合大量產生測試案例,但「哪些測試真正重要」永遠由人類判斷

結論

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

在 AI 時代,軟體工程的核心不再是寫程式,而是定義與維持系統的約束邊界(Constraints)。

媒體看到的是 AI 寫 code 的速度,我們在 production 看到的是 AI 放大風險的速度。真正的資深工程師,不是 Prompt 寫得最好的人,而是最懂得在 deadline、legacy、團隊現實中,設計與守護系統約束邊界的人。

給團隊的務實建議:

  1. 建立輕量《AI 使用守則》,明確高風險場景的約束邊界。
  2. 區分探索模式(可放寬)與生產模式(必須嚴格)。
  3. 每季進行 AI 技術債回顧。
  4. 培養「對 AI 保持健康懷疑」的團隊文化。

在 AI 時代,資深工程師的價值不但沒有降低,反而更加重要。因為能駕馭 AI 並定義其邊界的人,和被 AI 帶著走的人,做出來的系統品質天差地遠

2026年5月25日 星期一

從資深全端工程師轉型 Harness Engineering:完整教學指南

在台灣工程師薪資三層結構中,大多數全端工程師仍深陷 Commodity 層——靠 CRUD、接單與工時換取薪水,面對案源減少與薪資停滯的壓力。此時,Harness Engineering 提供了一條清晰且務實的升層路徑:把你從「寫程式的人」,轉變為「設計 AI 工作系統的人」,穩步從 Commodity 層走向 Product 層,乃至 Leverage 層。

什麼是 Harness Engineering?

Harness Engineering 是一種 AI-native 的工程方法論。它專注設計與管理 AI Agent 的執行環境,讓 AI 不再只是偶爾使用的聊天工具,而是能被結構化控制的系統性生產力單位。

它的核心不在 Prompt,而在於打造一個讓 AI 穩定運作、可觀測、可自動修正的工作系統——這就是 Harness。 工程師的角色也因此完成本質轉變:從 Execution(執行者)進化為 System Design(系統設計者)。

這正是全端工程師最自然的轉型優勢。你過去寫 API、管狀態、規劃架構、處理錯誤的經驗,幾乎可以直接對應到 AI Agent 的系統設計。

核心觀念轉移:從「實作」到「設計規則」

傳統全端工程師每天在寫 API、管狀態、修 Bug。這些能力在 AI 時代並沒有消失,而是被重新抽象到更高層次:

傳統能力Harness 對應能力價值層級提升
寫 APITool Schema 與能力接口設計Commodity → Product
狀態管理Agent Memory 與狀態機Product → Leverage
系統設計 / CI/CDWorkflow 控制與 Evaluation LoopLeverage 核心
Logging / MonitoringAgent Observability決定系統成敗

關鍵轉變在於:工程不再是「我來把功能做出來」,而是「我來設計 AI 如何可靠地完成工作」。

Harness 系統的三大核心模組

一個成熟的 Harness,通常建立在三個相互協作的層級上:

  1. Memory(狀態層) 讓 AI 擁有持續性與長期上下文能力,包括短期 Context、向量資料庫長期記憶,以及任務狀態機。 重點不在記住多少,而在如何有效使用記憶
  2. Tools(能力層) 讓 AI 能安全地與真實世界互動——API 调用、程式執行、資料庫查詢等。 關鍵是把外部能力轉化為精心設計的接口,避免誤用。
  3. Workflow(控制層) 定義 AI 的思考與行動規則,常見模式包含 ReAct、Plan-and-Execute、Reflection 與 Multi-Agent 協作。 這裡決定了系統的智商與穩定度

Harness Engineer 的四項核心能力

真正區分高低階的,不是會不會用 LangGraph,而是能否設計好以下四件事:

  • 狀態設計:如何避免上下文污染?如何從中斷中恢復?
  • 工具抽象:如何讓 API 成為 AI 可安全使用的能力?
  • 流程控制:何時該反思、何時該修正?如何防止錯誤擴散?
  • 可觀測性:你必須清楚看見 AI 每一步在想什麼、為什麼這麼決定。

沒有可觀測性,就沒有 Harness。這句話幾乎是這個方法論的底線。

三階段轉型路徑(8–12 週可見成效)

Phase 1:Agent Awareness 先理解 AI 的行為模式,熟悉 ReAct、Plan、Reflection 等基本模式。每天用 Cursor + Claude 完成工作,並拆解失敗點。

Phase 2:System Construction 用 LangGraph 搭建完整 Harness,包含 Memory、Tool、Evaluator Loop。這階段你會開始感受到「機制大於提示」的威力。

Phase 3:Multi-Agent System Design 進入 Planner + Executor + Critic 的多 Agent 架構,處理更複雜、長期性的任務。這時你已真正站在 Leverage 層。

核心心法:決定你能走多遠

  1. 機制優於提示:AI 出錯時,別急著改 Prompt,而是問:「我要設計什麼機制,讓這個錯誤永遠不再發生?」
  2. 系統要薄:越簡潔、可控、可替換的 Harness,越可靠。過度工程化往往適得其反。
  3. Human-in-the-Loop:人類永遠要在關鍵決策點上,逐步把自動化程度拉高。
  4. 可觀測性至上:看不見的系統,就不是系統,只是黑盒。

從個人轉型到公司求生

對個人而言,Harness 可直接應用在 Code Review Agent、技術文章生成系統、個人第二大腦等實戰專案。

對接案公司來說,這更是翻身武器。傳統「賣時間」的 Commodity 模式已失效。Harness 能幫助你:

  • 內部降本 50% 以上(1–2 人支撐原本 4 人工作)
  • 快速產品化:打包「一鍵後台 Agent」「電商資料清洗 Agent」「SEO 內容生成 Agent」等模板對外販售
  • 服務升級:以「自有 Harness 縮短 60% 開發時間」作為差異化賣點,重新吸引願意付費的中小企業客戶

起步建議:先花 7 天建立公司內部最小可用 Harness(Company-Survival-Harness),跑通真實任務後再對外推廣。

結語:AI 時代的結構性升層

Harness Engineering 的本質,是把 AI 從「工具」變成「可控的生產系統」

它完美呼應了台灣工程師的薪資三層結構: 把 Commodity 層的線性工作交給 AI, 在 Product 層實現 ROI 導向的交付, 在 Leverage 層打造可重複、具乘數效應的系統。

AI 並未壓縮工程師的整體價值,而是壓縮了線性、可被商品化工作的空間。真正稀缺的,永遠是系統設計、流程控制與可觀測性設計的能力。

3 個月內,如果你能打造出屬於自己的 Harness 模板,就能在 AI 時代握有更強的議價力與收入主動權。

現在,就從你的第一個 LangGraph 專案開始。 把 AI 真正變成可信任的工作系統。

2026年5月16日 星期六

台灣低薪工程師的惡性循環:AI 如何加速「乖乖接單」文化下的困境

台灣工程師薪資分層:AI 時代的結構性重構

台灣科技業低薪現象早已不是新聞,但在 AI 時代卻變得更加清晰且刺眼。許多工程師月薪卡在 5-7 萬甚至更低,工作量與壓力未減,薪資成長卻近乎停滯。這不是單純的「個人不夠努力」,而是產業結構長期定價的結果。AI 並非造成低薪的元兇,而是加速了薪資市場的三層分化

三層市場結構與判定標準

台灣工程師的薪資分布,本質上是一種三層市場結構。三個層級的差異,不在職稱或公司,而在於「價值是否與輸出綁定」以及價值計算單位的不同。

以下是簡單的判定表:

層級價值來源薪資決定因素典型特徵
Commodity工時 / 任務完成市場供給價格CRUD、外包、接單型、高度標準化
Product產品成果 / ROI業務成長貢獻產品設計、系統規劃、用戶價值交付
Leverage系統影響力 / multiplier決策與槓桿效應AI Infra、架構師、Domain Expert、跨域整合

判定方式

  • 如果你的工作主要被衡量「完成了多少 ticket / 工時」,且容易被其他人或工具替換,你多半處在 Commodity 層。
  • 如果工作成果直接影響產品指標(留存、營收、效率提升),則進入 Product 層。
  • 如果你的決策或設計能放大整個系統的效能、降低大規模成本,或開創新可能性,即屬 Leverage 層。

一個人可以跨層(例如同時處理 Commodity 任務但主導 Leverage 專案),但長期薪資主要由你主要價值貢獻的層級決定。

AI 改變價值密度分布

AI 不是單純的「壓低薪資工具」,而是改變價值密度分布的結構性力量。

  • 過去:1 位工程師 ≈ 1 單位線性產出。
  • 現在:1 位工程師 + AI ≈ N 倍 Commodity 產出(boilerplate、測試、簡單功能)。

AI 並未壓縮工程師整體價值,而是壓縮「線性價值工作」的存在空間。它讓可標準化任務的邊際成本大幅下降,導致 Commodity 層需求減少、競爭加劇;同時,Product 層的迭代速度加快,Leverage 層的乘數效應則被大幅放大。高階人才搭配 AI 後,一個人的影響範圍能從原本的幾倍擴大到數十倍。

這解釋了為何我們同時看到「初階職缺遇缺不補」與「AI 相關高階人才薪資持續上漲」的並存現象。

結構決定上限,行為決定位置

產業結構(代工型態、內需導向、供給過剩)決定了整體價格上限,尤其是 Commodity 層。工程師的風險規避行為(接受低薪、不敢跳槽),主要是維持了這個結構,而非根本造成它。市場上仍有外商進入、技術變遷等力量,但對高度商品化的工作而言,這些力量目前還不足以徹底改變定價邏輯。

不是「乖乖文化」,而是「風險結構問題」

低流動性的真正原因在於現實的風險結構:

  • 高房貸與生活成本
  • 跳槽失敗的非線性損失(家庭、年資、保險)
  • 缺乏完善的安全網
  • 薪資資訊不透明

這是理性選擇,而非性格缺陷。它讓 Commodity 層的供給持續充沛,進一步穩固了該層的定價區間。

如何在結構中升層?

關鍵不在努力程度,而在於你目前的工作是否仍具有不可商品化的價值

具體路徑:

  • 把 AI 當杠杆:用它快速處理 Commodity 任務,釋放時間投資 Product/Leverage 能力。
  • 累積可量化的 Impact(ROI、成本節省、產品指標),而非僅描述工時。
  • 提升流動性與透明度:定期評估市場、參與社群。
  • 朝 Leverage 轉型:深化 AI 整合、系統架構、領域知識,或將專業變現(課程、SaaS、顧問)。

結語:結構定價的核心命題

台灣工程師的薪資分化,不是個人努力差異,而是產業結構對「可替代性工作」的重新定價結果。

AI 的出現沒有改變這個結構,只是加速了價值分布的極化:

  • 可標準化工作被快速商品化
  • 產品導向工作與 ROI 緊密綁定
  • 槓桿型能力持續放大影響力

因此,薪資差距的本質不再是「薪水談判問題」,而是你所處價值層級的問題

當你清楚自己在哪一層,並有意識地往上移動,AI 就會從威脅轉為強大的杠杆。市場不會主動拯救任何人,但結構性的理解,能幫助我們做出更精準的選擇。

你目前的工作,主要貢獻在哪一層?又準備如何移動?

當工程師的價值不再只是寫 Code,公司還看得見你的貢獻嗎?

 最近跟 AI、軟體開發流程轉變相關的討論越來越多。 很多人關注的是: AI 會不會取代工程師? 未來還需不需要寫 Code? 工程師應該學什麼新技能? 但有一個更現實的問題,可能很多工程師每天都正在面對: 當你的工作價值不再只是「寫多少 Code」,公司是...