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 是否能持續理解並操作完整開發專案。

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

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