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 提升了生產力,企業的第一反應通常仍然是:

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

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


另一個更現實的結論

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

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

換句話說:

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

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

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

AI Review Flow:當 AI 寫 Code 的速度超過人類 Review 的速度

  AI Review Flow:當 AI 寫 Code 的速度超過人類 Review 的速度 不要讓 AI 只負責寫 Code,而是讓 AI 參與整個 Software Engineering 品質循環。 過去幾年,AI Coding 工具快速改變了軟體開發的方式。 以前,一個...