懂工作流程的人可以參與系統開發，但能做的是定義需求、拆解任務與驗收成果，不是取代工程紀律。AI 讓「把需求寫成程式」變便宜，卻沒有讓「想清楚要做什麼、判斷先後、確認做對了」變便宜，後者正是產品經理、需求分析師與各部門領域專家本來就在做的事。這篇文章整理這個轉變的邏輯，並說明哪些事即使有 AI 也不能省。文中提到的實際案例，已另外寫成獨立文章，這裡只放連結，不重複敘述。
AI 把開發中的哪一段變便宜了，哪一段沒有？
AI 讓把需求寫成程式碼變便宜，沒有讓定義需求、判斷優先順序與驗收成果變便宜；後者正是懂工作流程的人原本就在做的事。
過去，企業想開發系統，必須先取得技術能力：找工程師、組團隊、外包，或長期培養。能不能做出產品，常取決於有沒有足夠的技術人力。書稿的觀察是，當 AI 能完成大量程式撰寫與功能建置，技術實作不再是最稀缺的資源，成功的產品改為需要另一組能力：清楚定義需求、判斷優先順序、設計流程，以及驗收成果。
換句話說，差距從「誰有工程師」移到「誰能把想法定義清楚並負責結果」。這是書稿透過訪談提出的論點，不是統計結果。
Vibe Coding、AI 輔助開發與代理式工程，差在哪裡？
Vibe Coding 由 AI 主導、人不看程式碼；AI 輔助開發由工程師主導並審查 AI 的產出；代理式工程由 AI 實作、人負責規格、測試與驗收。
下表是書稿對三種做法的整理，是本文採用的定義，不是業界統一的標準。
| 項目 | Vibe Coding | AI 輔助開發 | 代理式工程（Agentic Engineering） |
|---|---|---|---|
| 誰是主要執行者 | AI | 工程師 | AI |
| 人的角色 | 描述想要的結果，不緊盯程式碼 | 參與、審查並修正 AI 生成的程式碼 | 規劃、監督、定義目標與檢查結果 |
| 需要的基礎 | 清楚表達需求 | 基本的程式語言知識 | 規格、測試、品質控管與可維護性的工程紀律 |
| 較適合 | 原型、個人專案與小型產品 | 由工程師負責的專案 | 需要穩定、可維護、可擴充的產品 |
書稿把代理式工程的作法歸納為四件事：先寫設計文件或規格（規格驅動）、先建立測試案例並讓 AI 修改到通過為止（測試驅動）、把專案規則整理成 CLAUDE.md 這類檔案提供給 AI（上下文工程），以及把 AI 會重複執行的任務拆成清楚、可驗證的固定步驟（任務拆解與流程指揮）。
上圖畫出兩種人面對錯誤時的不同反應：有工程背景的人會自己介入修正，沒有的人只能要求 AI 重新嘗試。這也說明了為什麼沒有工程背景的人，更需要預先建立規格與驗收方式，因為出錯時他們沒有別的辦法。
為什麼做過 PM 或需求分析的人，在訪談中特別快上手？
作者在訪談中觀察到，做過產品經理或專案經理的人較快掌握代理式工程，因為他們長期在需求端與工程端之間轉譯，習慣定義問題、拆解任務與驗收。
這是作者對十多位受訪者的觀察，不是統計結果，也不代表只有這類人才做得到。書稿列出這群人原本具備的能力：
- 知道前端與後端的基本分工
- 理解資料庫與雲端服務的概念
- 熟悉除錯流程與開發節奏
- 能撰寫產品規格文件（PRD）
- 能拆解需求並定義驗收標準
- 能規劃使用者流程與操作情境
- 能評估功能的優先順序與商業價值
- 能設計最小可行產品並快速驗證假設
書稿指出，這些能力的本質不是技術能力，而是問題定義、結構化思考，以及驗收與品質判斷。另一個原因是，PM 本來就習慣「管理工程師」：在不懂全部技術細節時，仍能判斷方向對不對、追問回報合不合理，這與和 AI 協作所需的能力高度相似。
下表是書稿對傳統開發與代理式工程的角色比較。
| 比較項目 | 傳統開發模式 | 代理式工程 |
|---|---|---|
| 程式產出者 | 人類工程師逐行手工編寫 | AI 代理，為主要執行者與實作者 |
| 人類核心職責 | 邏輯實作、語法糾錯、細節優化 | 定義目標、規劃架構、監督品質 |
| 關鍵能力要求 | 程式語言語法、API 熟練度 | 工程紀律、流程編排、問題定義 |
| 品質確保方式 | 人工程式碼審查與手動測試 | 規格驅動與自動化驗證 |
上圖是書稿對這個轉變的示意：過去每個任務都要交給專業人員才能實現，現在各角色都能先用 AI 驗證自己的想法。要注意的是，這裡的「驗證創意」是原型層級的驗證，不是正式上線。
代理式工程需要哪六項核心能力？
代理式工程的核心是管理 AI 的能力：目標定義與問題拆解、多步驟流程設計、工具整合、AI 流程指揮、驗收與品質控管，以及系統架構的整體視野。
| 能力 | 內容 |
|---|---|
| 目標定義與問題拆解 | 願景設定、目標定義、任務拆解與品質控管 |
| 規劃與多步驟流程設計 | 把大型任務拆成小步驟、設計 AI 的執行順序、建立檢查點 |
| 工具整合與 API 串接 | API 串接概念、工具調度能力、多系統整合 |
| AI 流程指揮與協作 | 設計工作流程、管理 AI 任務順序、控制輸入輸出、建立回饋迴圈 |
| 驗收與品質控管 | 測試機制、提示詞版本管理、部署控管、失敗回復機制 |
| 系統架構與整體視野 | 系統設計概念、架構判斷能力、可維護性思維 |
依我的判讀，前四項偏向流程設計，後兩項偏向工程判斷。懂工作流程的人通常從前面幾項切入，越往後面，越需要工程人員協助。這是我的整理，不是書稿的分類。
沒有工程背景，哪些事不能省？
懂流程的人可以定義、拆解與驗收，但測試、權限與資安仍要有人負責；官方文件也要求給 AI 一個可執行的檢查，無法驗證就不要上線。
Anthropic 的 Claude Code 官方文件指出，AI 會在工作「看起來完成」時停下，若沒有它能自己執行的檢查，使用者就成了唯一的驗證迴圈；文件的建議是一律提供驗證方式，例如測試、指令稿或畫面截圖，無法驗證就不要上線（Anthropic，Claude Code Best practices）。
雲端安全聯盟 AI 安全倡議的研究筆記則指出，現有的 AI 風險管理框架缺少針對非資訊背景、自行開發與部署 AI 應用者的專屬指引，並主張建立分級治理（Cloud Security Alliance，2026 年 6 月）。這是該機構的研究觀點。
| 領域專家可以做的 | 仍需要工程或資安人員的 |
|---|---|
| 定義需求與使用情境 | 權限設計與資料存取控管 |
| 拆解任務、寫規格與驗收條件 | 自動化測試與程式碼審查 |
| 用 AI 做出可操作的原型 | 系統整合、部署與長期維護 |
| 判斷結果是否符合實務規則 | 資安與法規合規 |
想讓團隊的領域專家參與開發，可以怎麼開始？
先選一個規則清楚的小需求，由領域專家寫規格與驗收條件，用 AI 做出原型，再交 IT 審查權限與資料；每一步都要指定負責的人。
下面的步驟是我的整理建議，不是書稿的方法，也尚未經過大規模驗證。
- 選題： 選每天重複遇到、規則清楚、出錯後能由人攔截的需求，避免一開始就碰高風險決策或敏感資料。
- 寫驗收條件： 在請 AI 動手前，先寫下「怎樣算做對」，包括輸入、輸出與幾個例子。
- 做原型： 讓專家用 AI 做出可操作的版本，找同事試用並收集回饋。
- 交接審查： 原型確認方向後，交給 IT 或工程人員審查權限、資料存放與測試，再決定是否正式使用。
- 指定責任人： 原型階段由誰維護、正式上線後由誰負責，事先寫清楚。
不同背景的實際做法，可以參考以下案例：法律背景者用 Lovable 做合約系統、需求分析師做塔羅占星網站、社工先做原型再交 IT 整合。
常見問題
沒有工程背景的人，可以參與公司的系統開發嗎？
可以參與定義需求、拆解任務、做原型與驗收，但權限、資安、測試與長期維護仍需要工程或資安人員負責。分清楚誰負責什麼，比誰能寫程式更重要。
Vibe Coding 和代理式工程有什麼不同？
Vibe Coding 重視用自然語言描述想要的結果，不緊盯程式碼；代理式工程則由 AI 實作，但人要先寫規格、建立測試並驗收，強調工程紀律。依書稿的整理，前者適合原型，後者適合需要穩定維護的產品。
為什麼產品經理或需求分析師比較容易上手？
因為他們長期在需求端與工程端之間轉譯，習慣定義問題、拆解任務與驗收，這與和 AI 協作所需的能力相近。這是作者對受訪者的觀察，不是統計結論。
領域專家做的原型，可以直接上線嗎？
不建議。原型適合驗證功能是否符合實務需求；涉及資料與權限的系統，上線前要由工程或資安人員審查。
公司想讓員工用 AI 做工具，要先準備什麼？
先指定可以做的範圍與不能碰的資料、明確誰負責審查與維護，並從低風險的小需求開始。
資料來源與說明
本文的論點整理自我在撰寫書稿期間，對十多位具有 Vibe Coding 或 AI 寫程式經驗者的訪談與觀察；「PM 較快上手」為作者的訪談觀察，非統計結果。三種開發方式的定義、代理式工程的六項能力，為書稿的整理，不是業界統一標準。官方資料引自下列頁面。
參考資料
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
- Cloud Security Alliance AI Safety Initiative，〈The Vibe Coding Governance Gap（研究筆記）〉，2026 年 6 月 2 日，存取日期：2026 年 10 月 19 日。
延伸閱讀
- 程式寫得更快，專案為什麼仍然很慢？從等待與交接找瓶頸：從流程角度看，為什麼寫程式變快不等於專案變快。
- 中小企業導入 AI 從哪裡開始？從工作流程找出真正值得做的專案：決定第一個專案的評估方法。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19