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 開發流程的工程師有幫助。

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

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 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 適合大量產生測試案例，但「哪些測試真正重要」永遠由人類判斷

結論

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

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

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

給團隊的務實建議：

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

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

從資深全端工程師轉型 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 對應能力	價值層級提升
寫 API	Tool Schema 與能力接口設計	Commodity → Product
狀態管理	Agent Memory 與狀態機	Product → Leverage
系統設計 / CI/CD	Workflow 控制與 Evaluation Loop	Leverage 核心
Logging / Monitoring	Agent 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 真正變成可信任的工作系統。

台灣低薪工程師的惡性循環：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 就會從威脅轉為強大的杠杆。市場不會主動拯救任何人，但結構性的理解，能幫助我們做出更精準的選擇。

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

🚀 AI 在軟體開發中的真實角色：把「寫 code 的問題」變成「審 code 的問題」

近年媒體不斷高喊「AI 即將取代程式員」，彷彿只要會用 Claude 或 Cursor，就能大幅提升生產力甚至完全取代人類開發者。但作為第一線開發者，我們必須保有清醒認知：AI 並沒有讓軟體工程變簡單，它只是把「寫 code 的問題」變成「審 code 的問題」。

AI 是強大的生產力工具，但遠非全能。它最擅長產生「看起來正確」的程式碼，卻在隱藏錯誤、系統性思考與長期維護上暴露出明顯局限。本文從 AI 本質限制出發，分析錯誤根源，最後說明頂尖開發者如何重新定位自己，打造有效的 AI 協作系統。

I. AI 的本質限制（Why it fails）

AI 在實際開發中存在幾個結構性弱點，這些限制不會因為模型參數增加而輕易消失：

1. 嚴重的上下文與記憶限制 AI 難以完整掌握大型專案的檔案依賴、歷史決策與團隊慣例，極易產生幻覺或前後矛盾。
2. 邊界條件與複雜邏輯處理薄弱 在並發、複雜業務規則、效能優化與邊緣案例上，錯誤率顯著上升。
3. 缺乏真正的商業理解與判斷力 AI 無法真正理解使用者痛點、公司戰略、長期維護成本與業務影響。
4. 大型系統整合與架構能力不足 跨模組、跨系統的整合仍是 AI 的明顯弱點。
5. 沒有責任感與最終把關能力 AI 不會為結果負責，最終的穩定性、安全性與可維護性，永遠落在開發者身上。

這些限制意味著：AI 目前最適合處理 Commodity 層的線性任務，而在 Product 與 Leverage 層的系統性工作上，仍高度依賴人類。

II. 為什麼這些錯誤這麼常發生？（Root Causes）

這些錯誤並非偶然，而是由 AI 的運作機制所必然導致：

• 上下文窗口限制：即使是 2026 年的最新模型，處理超大型 codebase 時仍會遺漏關鍵資訊。
• 訓練資料偏誤：大多數訓練資料來自公開程式碼，對於特定產業、內部系統或最新實務的理解相對薄弱。
• 過度自信的回答風格：AI 傾向以確定語氣輸出，即便不確定也很少主動標註風險。
• 缺少真正責任感：AI 沒有後續維護壓力，因此不會主動考慮長期可維護性與技術債。

結果就是常見的程式碼錯誤類型：幻覺（Hallucination）、安全性漏洞、邊界條件缺失、效能問題、與專案不一致，以及隱形錯誤。

III. 工程師的重新定位：從執行者到系統審計師與 Harness 設計者

因此，問題的核心不在於 AI 能不能寫 code，而在於人類如何重新設計協作方式。

認清限制後，真正具競爭力的開發者不會與 AI 競爭「誰寫得快」，而是轉向更高價值的位置——系統審計師、架構把關者，以及 Harness Engineering 的設計者。我把 AI 視為「高效率但需要嚴格監督的資深工程師」，自己則負責最終把關與系統設計。

核心實戰框架：AI Engineering Workflow

以下是我在實務中長期驗證的 AI 協作系統，而非單純的個人 SOP：

1. Context Engineering：給予充足、結構化的上下文（專案背景、既有程式碼、業務規則、非功能需求）。
2. 分步生成與迭代：不一次要求完整實作，而是逐步拆解任務。
3. Cross-model Validation：將相同需求丟給 Claude、GPT-4o、Gemini、Grok 等不同模型，比較輸出差異，找出各自盲點。
4. 嚴格 Code Review + 測試：人工審核、撰寫單元測試與整合測試。
5. 逐步整合與持續觀測：在真實環境中驗證，並建立可觀測機制。
6. Harness 機制設計：對於重複性任務，逐步打造包含 Memory、Tools 與 Workflow 的 Harness，讓 AI 能在受控環境中穩定運作。

這套框架把 AI 的速度優勢與人類的判斷力結合，既能快速原型與實驗，也能確保最終交付的穩定性、可維護性與商業價值。

結論：AI 時代真正的競爭力

AI 大幅降低了產生程式碼的門檻，但「做出正確、穩定、有商業價值且可長期維護的軟體」的難度並沒有降低。它反而對工程師的審核能力、系統思維與工具駕馭能力提出了更高要求。

在 AI 時代，真正的競爭力不在於「產出能力」，而在於「驗證與控制能力」。能夠設計 AI 協作系統的人，才真正具備從 Commodity 層走向 Leverage 層的結構性優勢。

保持理性認知，建立嚴謹的 AI Engineering Workflow，並持續精進 Harness Engineering 能力，這才是開發者在這個時代最堅固的護城河。

馴服 AI Agent：在中大型專案中建立「永不幻覺」的開發協議

在 AI Agent 已全面進入 production workflow 的開發環境中（如 Antigravity、Cursor Agent mode），真正的瓶頸不再是生成能力，而是上下文污染與系統一致性。AI-native 開發的核心，不是提升 AI 能力，而是設計 AI 的認知邊界（cognitive boundaries）。當專案使用 Astro 5 + Vue 3 + Laravel 12 + Filament v3 這樣複雜的全端技術棧時，AI 極易因記憶漂移而虛構 API 格式、破壞商業邏輯或使用錯誤套件語法。

Prompt Engineering 的時代已經結束。解決方案是建立一套結構化的 AI System Design Stack，讓 AI 從「容易幻覺的助手」轉變為「遵守明確邊界的可靠執行官」。

AI System Design Stack：三層控制架構

1. Execution Boundary Layer（行為控制層）—— Agent Runtime Governance

這一層定義「AI 能知道什麼、不能做什麼」，是防幻覺的基礎。

建立 AI Execution Control Plane（原 .antigravity 升級版）：

text

.ai-control-plane/
├── core/                  # 技術邊界
│   └── TECH_STACK.md
├── contracts/             # 介面合約
│   └── API_CONTRACT.md
├── domain/                # 商業規則
│   └── BUSINESS_LOGIC.md
├── guardrails/            # 禁止與防護
│   └── FORBIDDEN_PATTERNS.md
└── scoring/               # 評分機制
    └── SCORING_SYSTEM.md

核心文件範例：

• TECH_STACK.md：嚴格鎖定版本與禁止語法
• BUSINESS_LOGIC.md：使用字典 + Mermaid 流程圖定義訂單狀態機、權限規則等

實戰指令模板：

• Reference Discovery：要求 AI 先閱讀所有規則文件並找出相似參考
• Plan First：強制先輸出執行計畫，確認後才產生程式碼

2. Efficiency Layer（效率控制層）—— AI Development Efficiency Model (AIDEM)

AIDEM 定義了如何在 Context、Contract、Execution、Model 四個層面控制 AI 系統，最大化輸入/輸出比（I/O Ratio）。

Layer	Purpose	核心機制	預估節省
Context	輸入控制	.ai-control-planeignore + 精準 Pinning	20-40%
Contract	規則控制	模組化 Markdown + 精煉指令	10-25%
Execution	行為控制	Plan First + Diff Mode + One-Shot	15-30%
Model	算力分配	模型路由 + Clear History	30-50%

綜合應用可降低 40%~70% Token 消耗，讓中大型專案的 AI 開發從「燒錢」變成「可控」。

3. Schema Layer（資料控制層）—— Contract-first Architecture

AI 系統最大問題不是邏輯錯誤，而是 schema ambiguity（結構不確定性）。

spatie/laravel-data 正是 Schema Layer 的實戰參考實現。它提供單一真理來源（SSOT），讓 Model → DTO → API → 前端 TypeScript 形成嚴格一致的合約鏈。

PHP

#[TypeScript]
class OrderData extends Data
{
    public function __construct(
        public string $order_no,
        public int $amount_cents,  // 分為單位
        // ...
    ) {}
}

Controller 簡化為一行，AI 只需閱讀一個檔案即可完全理解輸出結構。搭配 laravel-typescript-transformer，前後端型別自動同步，大幅壓縮幻覺空間。

這是 Schema-level Control 的具體落地：AI 需要的是確定性，而不是模型自由度。

從 Prompt-Driven 到 Boundary-Driven

在 AI-native 開發時代，系統的穩定性不再主要來自 code quality，而是來自schema consistency（資料一致性） 與 execution boundary design（執行邊界設計）。

• Execution Boundary Layer 解決行為一致性
• Schema Layer 解決資料一致性
• Efficiency Layer 確保可規模化

三層結合，構成真正可控、可觀測、可維護的 AI 開發系統。這也正是全端工程師從 Commodity 層 升級到 Leverage 層 的結構性路徑。

立即行動：

1. 建立 .ai-control-plane/ 並填入核心規則文件
2. 導入 spatie/laravel-data + TypeScript Transformer
3. 在最容易出錯的模組先建立 BUSINESS_LOGIC.md，並套用 AIDEM 流程

Prompt 時代已過，Boundary-Driven 時代才剛開始。當 AI 再次出現幻覺時，別急著在聊天視窗糾正它——去完善你的認知邊界設計。這才是生產級、規模化 AI 輔助開發的正確心法。