從 DX 到 AX：設計 AI agent 讀得懂、改得動、驗得過的前端工程環境

這篇整理自 2026 年 6 月在前端讀書會的分享，投影片是公開的。

為什麼想分享這個主題

AI 加入軟體開發之後，方法論一直在變，問題的重心也慢慢從「怎麼問」移到「整個環境」：

階段	核心問題	工程師的角色
Prompt Engineering	怎麼問，AI 才答得好？	提問者
Context Engineering	AI 需要哪些背景，才不會亂猜？	脈絡設計者
Harness Engineering	AI 需要哪些工具、權限和驗證？	工作環境設計者
Agent Experience	整個工程環境適不適合 agent 工作？	協作系統設計者

用騎馬來比喻：prompt 是韁繩，context 是地圖，harness 是馬鞍和安全裝備，AX 則是整套騎乘系統。我們不能只期待 AI 變得更聰明，也要準備好一套能駕馭它的馬鞍。

我們遇到的協作問題

AI 常常不是不會寫 code，而是：

找不到正確的 component
猜錯 API 或 GraphQL schema
為了修一個 bug，改壞共用的 hook
自己刻一套 UI，沒有用 design system
用 as any 或 @ts-ignore 假裝解決型別錯誤
沒跑測試，就說「完成了」
修改範圍失控，review 的成本變得很高

Cursor 的 agent 使用建議把 agent harness 拆成三個部分：instructions、tools 和 model。agent 表現不好，不一定是模型不夠強，也可能是指示和工具沒準備好。

什麼是 AX

AX（Agent Experience）是一種工程環境的設計，目的是讓 AI agent 能可靠地理解、修改和驗證系統。

這不是把 AI 擬人化，而是承認 agent 已經是開發流程裡的一個角色。就像 UX 照顧使用者、DX 照顧工程師，AX 照顧的是 agent：

	對象	設計目標
UX	使用者	讓使用者完成任務
DX	工程師	讓工程師有效地開發、測試、交付
AX	AI agent	讓 agent 理解任務、執行修改、接收回饋、遵守邊界

從 agent 的定義推出 AX 的重點

Anthropic 在〈Effective context engineering for AI agents〉裡，把 agent 定義成：

LLMs autonomously using tools in a loop.

拆開來看，每個關鍵字都對應到一件我們能設計的事：

LLMs：模型靠 context 運作，需要正確的脈絡才不會亂猜。
tools：agent 靠工具和外界互動，要給它對的工具，也要劃好安全邊界。
loop：agent 在迴圈裡反覆推進，每一圈都要能驗證，常做的流程也要能重複使用。

最關鍵的是 autonomously：agent 會自己決定下一步。所以我們的工作不是盯著它的每一步，而是先把脈絡、工具、邊界和驗證準備好，讓每一圈都跑在對的軌道上。

這次分享把前端專案的 AX 整理成五個原則：

Context：讓 agent 理解系統
Workflow：先探索、再規劃、再實作
Verification：讓 agent 知道自己有沒有做對
Guardrails：讓 agent 在安全的邊界內工作
Skills：把常做的任務變成可以重複使用的流程

AX 不只是開發者體驗

最早提出 AX 的是 Netlify 的 Mathias Biilmann。他在 2026 年初的〈One Year of AX〉裡提到，AX 一開始被當成「新的 DX」，但它會像 UX 一樣，變成每個產品都要考慮的事。他把 AX 分成四個面向：

Access：agent 能不能存取你的產品？有哪些權限？需不需要人類在中間確認？
Context：模型懂不懂你的產品？你提供的資訊能不能讓它建立正確的理解？
Tools：你有沒有替 agent 做工具，例如 MCP server、CLI、API？
Orchestration：你的產品能不能反過來觸發 agent，替它傳遞 context、提供 sandbox？

Biilmann 談的是產品怎麼面對 agent，這篇談的範圍比較小：前端專案的工程環境，怎麼讓 agent 寫 code 時更可靠。

原則一：Context，讓 agent 理解系統，而不是猜

重點不是把所有文件都丟給 agent，而是讓它在需要的時候，拿到正確、精簡、好維護的專案脈絡。

前端專案可以提供的 context：

專案架構
route、component、hook、API 的慣例
GraphQL 和 codegen 的規則
design system 的用法
npm scripts 各自做什麼
哪些是產生出來的檔案，不能直接改
常見任務的流程
禁止的行為

這些資訊通常放在 AGENTS.md 或 CLAUDE.md 這類檔案裡，agent 每次工作都會讀到。Claude Code 的建議是保持簡短、定期修剪，不要讓用不到的資訊淹沒真正重要的部分。

AGENTS.md 該寫什麼

不該寫	應該寫
你是一位資深工程師	怎麼啟動專案
請寫乾淨的 code	怎麼跑 typecheck、lint、test、build
請深呼吸，一步一步思考	哪些檔案不能改
很長的 coding style guide	改了 GraphQL 之後要跑 codegen
很少遇到的 edge case 大全	UI 優先用既有的 design system
	不准用 `@ts-ignore`、`as any` 繞過錯誤
	完成後要回報驗證結果

左邊那些話對 agent 沒有幫助，它本來就會盡量寫好 code；長篇的規範和少見的情況則會佔掉 context。右邊是 agent 從 code 裡看不出來，又一定要知道的事。

Context 不是越多越好

〈Evaluating AGENTS.md〉這篇研究測試了 repository 層級的 context file 對 coding agent 的影響。結果發現，不管是 LLM 產生的還是開發者寫的，提供 context file 都沒有明顯提高任務成功率，推論成本卻平均增加超過 20%。

Context engineering 的重點不是多，而是準。一份好的 context file 應該回答：

agent 常在哪裡犯錯？
哪些規則沒辦法從 code 推斷出來？
完成任務前，一定要跑哪些指令？
哪些檔案或操作的風險比較高？

原則二：Workflow，先探索、再規劃、再實作

不要一拿到需求就叫 AI 直接改 code。把「決定要怎麼做」和「動手做」拆開，讓人類在成本最低的規劃階段介入。

agent 的工作流程：探索、規劃、實作、驗證、審查，人類在規劃和審查兩個階段介入 人類在規劃和審查兩個階段介入，其他階段交給 agent

Cursor 的 Plan Mode 就是這樣設計的：agent 先研究 codebase、提出需要釐清的問題，產出一份附上檔案路徑和程式碼位置的計畫，等人類同意後才開始實作。Claude Code 也有類似的 plan mode。

實作計畫是新的 review 對象

在 agent 的工作流程裡，PR 不再是唯一需要 review 的東西，agent 實作前產出的計畫也應該被 review。這時候發現方向錯了，只要改計畫；等 PR 出來才發現，就要整個重做。

一份好的實作計畫應該包含：

預計修改和新增哪些檔案
每個檔案為什麼要改
影響範圍
有哪些假設和不確定的地方
怎麼驗證
哪些風險需要人類確認

原則三：Verification，讓 agent 知道自己有沒有做對

沒有回饋迴圈的 AI coding 很危險。對人類來說，測試是品質保證；對 agent 來說，測試是它的感官，是它唯一能知道自己有沒有做對的方式。

Claude Code 的建議裡特別強調，要給 agent 一個驗證自己成果的方法，例如測試、build 的結果、lint，甚至是截圖比對。沒有可以執行的檢查，agent 很容易停在「看起來完成了」。

前端專案可以提供這些驗證訊號：

訊號	能幫 agent 發現什麼
TypeScript typecheck	props、API、型別錯誤
ESLint	不符合慣例的寫法、潛在錯誤
Unit test	function 和 hook 的邏輯
GraphQL codegen	query、mutation 有沒有對上 schema
Storybook	component 的各種狀態和使用範例
Playwright、E2E	真實的使用流程
Visual regression	畫面差異
Build	正式環境才會出現的整合問題

這些檢查最好都能用一個指令跑完。agent 改完、執行、讀錯誤訊息、再修正，這個迴圈越短越好。

前端案例：把 UI 脈絡交給 agent

前端最常見的問題之一，是 AI 看到需求後自己做一套 UI，沒有用既有的 design system。現在有兩種 MCP server 可以處理這件事。

Storybook MCP

Storybook MCP 把 component 的 metadata、stories、文件和測試提供給 agent。Storybook 官方用 UI 生成任務做了比較，使用 MCP 提供的文件後：

component 的使用正確度提升 12.8%
完成時間快 2.76 倍
token 用量少 27%

這是 Storybook 官方的 benchmark，不代表每個專案都會有一樣的效果，但方向很清楚：agent 知道有哪些 component 可以用，就比較不會自己重做。

Figma MCP

Figma MCP 讓 agent 讀得到設計檔的 variables、components 和 layout。搭配 Code Connect，可以把 Figma 上的 component 對應到 codebase 裡真實存在的 component。這樣 agent 不只知道畫面長什麼樣子，也知道該用哪個既有的 component，比較不會重新做一個 Button、Card 或 Modal。

重點不是讓 AI 看得懂設計圖，而是讓設計的脈絡對應到 codebase 的工程脈絡。

原則四：Guardrails，讓 agent 在安全的邊界內工作

Prompt 不是安全邊界。Docker 在〈AI Coding Agent Horror Stories〉裡整理了 agent 造成的各種事故，結論是：

Natural language directives are not security boundaries. Infrastructure is.

在 prompt 裡寫「不要刪除檔案」，agent 還是有可能刪除。比較可靠的邊界，要放在 agent 繞不過去的地方：

repo 裡的 instructions
指令的 permission allowlist
sandbox、devcontainer
CI 檢查
branch protection
CODEOWNERS
人類 review
hooks

前端專案可以這樣訂：

不可以	一定要
直接改產生出來的檔案	改了 TypeScript 後跑 typecheck
用 `@ts-ignore`	改了 GraphQL 後跑 codegen
用 `as any` 假裝解決型別問題	改了 UI 狀態後補 Storybook story
沒經過同意就新增 dependency	完成任務後附上驗證結果
隨意改 auth、權限、金流、部署相關的 code	有不確定的地方時，標出風險和假設
改 CI/CD 設定，除非任務明確要求

寫在 AGENTS.md 的規則，agent 可能會忘記或誤解；用 hook、CI 或權限設定擋下來的，就一定會被擋下來。重要的規則，兩邊都要有。

原則五：Skills，把常做的任務變成可以重複使用的流程

Rules 是每次對話都會載入的指示，skills 則是在相關任務出現時才載入，裡面可以包含特定領域的知識、工作流程或 script。常做的任務寫成 skill，agent 每次都會照同一套流程做，不用每次重新說明。

適合寫成 skill 的前端任務：

新增 GraphQL query 或 mutation
新增 Storybook story
新增 i18n key
重構 custom hook
修好失敗的測試
把舊頁面遷移到 Next.js
補上 loading、empty、error 狀態
調查正式環境的 bug

範例：補上 loading、empty、error 狀態

假設要替一個既有的 component 加上 loading、empty、error 三種狀態。

不好的做法是直接說「幫我加上 loading、empty、error state」。agent 會馬上開始改，改了哪些地方、品質如何，都很難掌握。

比較好的做法：

先找出相關的 component 和既有的寫法
先不要改 code
產出實作計畫
人類 review 計畫
開始修改
跑 typecheck、lint、test
補上 Storybook stories
輸出 PR 摘要和驗證結果

這個流程用到了前面所有的原則：先探索再規劃，人類在計畫階段介入，改完用可以執行的檢查驗證，最後用 Storybook 留下每種狀態的範例。這套流程本身也很適合寫成 skill。

一週內可以開始做的事

不需要一次改掉整個開發流程，可以先從這五件事開始：

寫一份最精簡的 AGENTS.md
整理 package scripts，讓 typecheck、lint、test 都能用一個指令跑
準備交代任務給 agent 時用的 prompt 範本
列出 agent 不能做的事
挑一個常做的任務，寫成 skill 或 checklist

目標不是讓 agent 全自動完成所有事，而是讓它少猜一點、少亂改一點、多驗證一點，改出來的東西也更容易 review。

工程師的價值會轉移

agent 寫 code 很快，但它不會自己知道：

這個需求值不值得做
這個使用者體驗合不合理
這個架構會不會造成長期的技術債
這個修改會不會影響權限、資料安全或商業邏輯
這個取捨符不符合團隊的方向

〈The Semi-Executable Stack〉這篇論文提到，軟體工程處理的對象，正在從可以執行的 code，擴大到 prompt、工具、工作流程、管控機制這些「半可執行」的產物。工程師的工作不會消失，而是多了一項：設計讓 agent 能穩定工作的環境。

結語

AI agent 能做到多好，不只取決於模型，也取決於工程環境提供了多少可以理解、可以執行、可以驗證的訊號。

好的 AX 也會讓人類的 DX 變好。agent 看不懂的地方，通常也是新人難上手、系統難維護、團隊知識沒有被記錄下來的地方。