WSL 使用說明：基本指令

WSL（Windows Subsystem for Linux）讓 Windows 可以執行 Linux 終端機、套件與開發工具。本文先介紹日常基本操作，再說明如何將 WSL 2 發行版安裝到 D:\wsl，並自訂環境名稱。

文中的 dev、test 都是通用示範環境名稱，請依自己的環境替換。本文操作指令在 Windows PowerShell 執行。尚未安裝 WSL 的讀者，可以先閱讀第 3、4 節完成安裝，再回來練習。

1. Windows 端常用 WSL 指令

以下在 Windows PowerShell 執行。先用 wsl -l -v 查看已安裝環境，再將範例的 dev 換成清單中的名稱。使用 wsl -d dev 進入 Linux，輸入 exit 返回 PowerShell。

完整指令	簡寫	用途
wsl --help	—	查看支援參數
wsl --version	wsl -v	查看 WSL 程式與核心版本
wsl --status	—	查看預設環境等狀態
wsl --list	wsl -l	列出已安裝的發行版名稱
wsl --list --verbose	wsl -l -v	列出已安裝發行版的名稱、狀態與 WSL 版本
wsl --list --online	wsl -l -o	查詢可以安裝的發行版（distro）
wsl --list --running	wsl -l --running	列出正在執行的環境；--running 沒有簡寫
wsl --list --quiet	wsl -l -q	只輸出已安裝發行版的名稱
wsl --distribution dev	wsl -d dev	進入 dev
wsl --distribution dev --cd '~'	wsl -d dev --cd '~'	從 Linux 家目錄開始；--cd 沒有簡寫
wsl --distribution dev --user root	wsl -d dev -u root	使用 root 進入 dev
wsl --set-default dev	wsl -s dev	設定直接輸入 wsl 時使用 dev
wsl --terminate dev	wsl -t dev	停止 dev 與其中的程序
wsl --shutdown	—	停止所有環境及 WSL 2 虛擬機
wsl --update	—	更新 WSL 本身

「—」表示沒有對應的短參數。簡寫與完整寫法可以混用，例如 wsl -l --running。

簡寫對照：-l 是 --list、-o 是 --online、-q 是 --quiet、-d 是 --distribution、-u 是 --user、-s 是 --set-default、-t 是 --terminate。

-v 的意思取決於使用位置： wsl -v 對應 wsl --version，查看 WSL 程式版本；wsl -l -v 中的 -v 對應 --verbose，顯示發行版的詳細清單。--version 2 在安裝或匯入命令中用來指定 WSL 2，應保留完整參數，不能直接替換成 -v 2。

清單的星號表示預設發行版。VERSION 2 是 WSL 2 架構，不是 Ubuntu 版本，也不是 wsl --version 顯示的程式版本。參考：Microsoft WSL 管理指令。

2. 理解環境名稱、儲存位置與 Linux 使用者

項目	範例	用途
Linux 發行版	Ubuntu-24.04	選擇安裝哪種 Linux
WSL 註冊名稱	dev、test	Windows 啟動與管理環境時使用
儲存位置	D:\wsl\dev	Linux 虛擬磁碟所在目錄
Linux 使用者	demo	Linux 內的登入帳號

wsl -d dev 的 dev 是 WSL 註冊名稱，不是使用者。同一種 Ubuntu 可以建立成不同名稱的環境，各自保存套件與專案。

WSL 2 使用輕量虛擬機，各發行版通常以 ext4.vhdx 保存 Linux 檔案系統。Linux 家目錄中的專案、資料庫和套件，都會占用該磁碟檔案。移到 D 槽主要解決 Linux 資料的容量問題；WSL 程式、Windows 元件、暫存與預設 swap 仍可能使用 C 槽。

3. 首次啟用 WSL

尚未安裝 WSL 時，以系統管理員身分開啟 PowerShell：

# 只啟用 WSL，不先安裝預設 Ubuntu
wsl --install --no-distribution

依提示重新啟動 Windows，再執行：

wsl --update
wsl --version
wsl --set-default-version 2

已能使用 WSL 就跳過首次啟用。設定預設版本只影響新環境，不會轉換既有發行版。

請先執行 wsl --help，確認目前版本支援本文使用的參數。若缺少 --name、--location 等參數，請先更新 WSL；搬移與預設使用者設定也應依目前版本的 help 確認。

參考：Microsoft WSL 基本指令。

4. 安裝到 D:\wsl，並自訂名稱

以下在 Windows PowerShell 執行。

先查詢可安裝的發行版，使用清單中的 NAME：

wsl --list --online
# 等效簡寫：wsl -l -o

將 Ubuntu 安裝為 dev，放在 D:\wsl\dev：

mkdir 'D:\wsl'
wsl --install -d Ubuntu-24.04 --name dev --location 'D:\wsl\dev' --version 2

參數	說明
--distribution Ubuntu-24.04，簡寫 -d Ubuntu-24.04	要安裝的 Linux 發行版，依線上清單為準
–name dev	自訂 WSL 名稱為 dev
–location ‘D:\wsl\dev’	指定儲存位置
–version 2	使用 WSL 2

取名字用 --name，指定位置用 --location。 不必先裝到 C 槽，再搬到 D 槽。

首次啟動依提示建立 Linux 使用者與密碼。輸入密碼時不顯示字元是正常的，Linux 帳密獨立於 Windows。若沒有自動啟動，可執行：

wsl -d dev

--location 見 Microsoft 安裝參數；--name 請依目前版本的 wsl --help 確認；Microsoft WSL 專案也有同時指定名稱與位置的範例。

建議每個環境使用獨立目錄，例如 D:\wsl\dev 與 D:\wsl\test。名稱必須未被使用，目標目錄應是新的或空的目錄，不能與既有環境共用磁碟檔案。名稱與目錄不必相同。

安裝指令中的 -d 是 --distribution 的簡寫。–install、–name、–location 沒有短參數；若要安裝後不自動啟動，可加上 --no-launch，簡寫為 -n。

確認結果：

wsl -l -v
Get-ChildItem -LiteralPath 'D:\wsl\dev' -Force

清單應出現 dev、版本為 2，目錄通常會有 ext4.vhdx。也可以唯讀查詢目前 Windows 使用者的名稱與實際位置：

Get-ChildItem 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss' |
    Get-ItemProperty |
    Select-Object DistributionName, BasePath

不需要手動修改登錄。

5. 已經裝在 C 槽，如何搬到 D 槽？

本節的 --export、–import、–unregister、–manage 與 --move 保留完整寫法，沒有對應的短參數。範例中的 wsl --terminate Ubuntu 可寫成 wsl -t Ubuntu，wsl -d Ubuntu 則是 wsl --distribution Ubuntu 的簡寫。

保留名稱：使用 --move

先確認 help 的 --manage 區段支援 --move。以下將 Ubuntu 移到新的 D:\wsl\ubuntu：

# 先儲存工作，停止會寫入環境的程式
wsl --terminate Ubuntu

# 建議先備份，確認 D 槽容量足夠
mkdir 'D:\wsl-backups'
wsl --export Ubuntu 'D:\wsl-backups\ubuntu-before-move.tar'

# 上一步成功後才繼續，使用未被占用的目標位置
wsl --manage Ubuntu --move 'D:\wsl\ubuntu'
wsl -d Ubuntu

搬移後仍叫 Ubuntu。用登錄查詢核對 BasePath，並確認專案、帳號與服務正常。搬移參數以目前版本的 help 為準。

同時換名字與位置：匯出再匯入

需要改名或不支援 --move 時，可以建立新環境。以下把 Ubuntu 複製為 ubuntu-dev，先保留舊環境：

mkdir 'D:\wsl-backups'
mkdir 'D:\wsl\ubuntu-dev'

# 先儲存工作、停止服務
wsl --terminate Ubuntu
wsl --export Ubuntu 'D:\wsl-backups\ubuntu.tar'

# 匯出成功後才繼續
wsl --import ubuntu-dev 'D:\wsl\ubuntu-dev' 'D:\wsl-backups\ubuntu.tar' --version 2
wsl -l -v
wsl -d ubuntu-dev

語法：

wsl --import <自訂名稱> <安裝位置> <備份檔案> --version 2

第一個參數決定名字，第二個決定位置。這是建立新的註冊環境，不是原地改名。舊環境、備份與新環境會同時占用空間；保留舊環境時，C 槽空間尚未釋放。

參考：Microsoft 匯入 Linux 發行版。

驗證後才移除舊環境

先確認新環境的專案、資料庫、使用者、權限與服務正常，並保留可還原備份。如果確定要移除舊 Ubuntu，才執行：

# 危險：永久刪除 Ubuntu 的 Linux 資料、套件與設定
wsl --unregister Ubuntu

unregister 不只是刪除清單上的名稱，也不是重新啟動指令。

6. 設定 WSL 預設使用者

匯入的環境可能預設以 root 啟動。如果該環境已有一般使用者，例如 demo，較新版本可用 WSL 管理指令指定預設帳號：

wsl --manage ubuntu-dev --set-default-user demo
wsl --terminate ubuntu-dev
wsl -d ubuntu-dev

--set-default-user 沒有短參數；範例中的 --terminate 可簡寫為 -t，-d 則是 --distribution。demo 必須是環境內已存在的帳號；這個指令只設定預設使用者，不會建立帳號。請先用 wsl --help 確認版本支援此參數。

7. 避免 C 槽變大，也要留意 swap

發行版與 swap 的位置分開設定。如果也要把 WSL 2 的 swap 放到 D 槽，在 PowerShell 執行：

mkdir 'D:\wsl-swap'
notepad "$env:USERPROFILE\.wslconfig"

加入或合併下列設定。已有 [wsl2] 時修改原區段：

[wsl2]
swap=4GB
swapFile=D:\\wsl-swap\\swap.vhdx

INI 路徑使用雙反斜線。4GB 是範例，依需求調整。儲存工作後執行：

wsl --shutdown

下次啟動套用設定。Windows 家目錄的 .wslconfig 對所有 WSL 2 環境生效；Linux 的 /etc/wsl.conf 只影響該發行版。參考：Microsoft .wslconfig 設定。

刪除環境內的資料後，VHDX 不一定立刻縮小。磁碟空間回收方式應依 WSL 版本確認，先備份再處理。參考：Microsoft WSL 磁碟空間管理。

Docker Desktop 自己管理的資料磁碟也需要另外確認位置，一般發行版搬移不代表 Docker Desktop 資料跟著搬移。

8. 常用操作速查

# 查看已安裝環境（--list --verbose 的簡寫）
wsl -l -v

# 進入指定環境（--distribution 的簡寫）
wsl -d dev

# 停止指定環境（--terminate 的簡寫）
wsl -t dev

# 新安裝：指定名稱與 D 槽位置
wsl --install -d Ubuntu-24.04 --name dev --location 'D:\wsl\dev' --version 2

先學會列出、進入與停止環境，再依用途規劃名稱與儲存位置，就能管理多個 Linux 開發環境。

在純 Linux 環境用 Playwright CLI 與 AI agent 測試網站

沒有桌面的 Linux 也能讓 AI agent 操作網站並截圖。本文以 Playwright CLI 搭配 Antigravity CLI（AGY）、Claude Code 或 Codex，驗證 agent 剛完成的 Angular 功能。以下假設 agent 已安裝並登入，Angular 專案也已存在。

1. Playwright CLI 是什麼？

Playwright CLI 是給 coding agent 使用的瀏覽器命令列工具。它預設以 headless 模式啟動瀏覽器，因此本文的範例不需要桌面或 DISPLAY。

它的基本工作方式是：

1. open 開啟網站，snapshot 取得元素及其參照編號（例如 e8）。
2. Agent 依快照用 fill、click、check 等指令操作，再檢查結果。
3. screenshot 保存畫面，供 agent 對照需求回報結果。

CLI 負責操作瀏覽器；skill 是教 agent 使用 CLI 的本地說明文件。本文示範即時驗證；若要把測試提交到版本庫、日後重跑，需另寫 Playwright Test 測試檔，並用 npx playwright test 執行。

2. 在 Linux 安裝 CLI，並提供給 AGY、Claude Code、Codex

以下命令都在 Linux 終端機 執行。先準備 Node.js 20 以上、npm，以及可執行 shell 命令的 AGY、Claude Code 或 Codex。確認版本：

node --version
npm --version

先安裝 Playwright CLI：

npm install -g @playwright/cli@latest

沒有瀏覽器：選擇 Chromium 安裝方式

若只跑 headless，安裝 Chromium headless shell 即可。它本身就是瀏覽器程式，無須另外安裝完整 Chromium：

playwright-cli install-browser chromium --with-deps --only-shell

在要測試的專案中建立 .playwright/cli.config.json，只指定 browserName；不要指定 channel：

cd /path/to/your-project
mkdir -p .playwright
printf '%s\n' '{"browser":{"browserName":"chromium"}}' > .playwright/cli.config.json
playwright-cli open https://demo.playwright.dev/todomvc/
playwright-cli close

這樣的 open 會使用 headless shell。不要加 --browser=chromium；該選項會改用完整版 Chrome for Testing。下方安裝專案 skill 時，也須跳過自動下載完整版 Chromium。Playwright 的 headless shell 說明

若要使用 open --browser=chromium，需安裝完整版 Chromium。下列指令會下載 Chrome for Testing 與 headless shell：

playwright-cli install-browser chromium --with-deps

兩種安裝指令都應以平常執行 open 的 Linux 使用者執行。--with-deps 安裝系統套件時可能要求管理員權限；不要在整條指令前加 sudo，以免瀏覽器下載到 root 的快取。

已有 Chrome 或 Edge：使用本機瀏覽器

已有 Chrome 或 Edge 時，只需安裝 CLI。它們本身支援 headless，無須再下載 Chromium 或 headless shell。啟動時指定瀏覽器：

playwright-cli open https://example.com --browser=chrome
playwright-cli close
# 或
playwright-cli open https://example.com --browser=msedge
playwright-cli close

install-browser <名稱> 與 open --browser=<名稱> 的差別：

名稱	install-browser	open --browser=...
chromium	下載完整版 Chrome for Testing 與 headless shell 到 Playwright 快取；加 --only-shell 則只下載 shell	使用完整版 Chrome for Testing；只裝 shell 時須用上方不指定 channel 的設定檔
firefox	下載 Playwright 修改過的 Firefox 到快取	使用 Playwright 管理的 Firefox
webkit	下載 Playwright 管理的 WebKit 到快取	使用 Playwright 管理的 WebKit
chrome	安裝正式版 Chrome 到系統位置，可能覆蓋原有安裝	使用本機 Chrome
msedge	安裝正式版 Edge 到系統位置，可能覆蓋原有安裝	使用本機 Edge

沒有設定檔，也未指定 --browser 時，open 預設使用本機 Chrome。CLI 預設以 headless 模式執行；headless 仍需要瀏覽器程式。參見 Playwright 瀏覽器說明與 CLI 安裝文件。

只有在有桌面環境且要顯示瀏覽器視窗時，才在 open 加上 --headed。

Playwright CLI 通常會為自動化工作建立獨立的瀏覽器使用者資料，不會直接沿用你日常瀏覽器的分頁或登入狀態。

接著選擇 skill 的適用範圍。CLI 程式已由前面的 npm install -g 安裝。

安裝到單一專案

在要測試的專案目錄執行 playwright-cli install --skills=...。它會建立 .playwright/，若專案是 Git 版本庫，還會把 .playwright-cli/ 加入 .gitignore。沒有設定檔時，它會優先使用本機 Chrome、其次 Edge；兩者都沒有則下載完整版 Chromium，並建立設定檔。快照等輸出存於 .playwright-cli/，可能含登入資訊，不要提交。下列指令安裝的是 skill，不是 agent 本身。

使用的 agent	在專案目錄執行	skill 位置
AGY（Antigravity CLI）	playwright-cli install --skills=agents	.agents/skills/playwright-cli/
Claude Code	playwright-cli install --skills=claude	.claude/skills/playwright-cli/
Codex	playwright-cli install --skills=agents	.agents/skills/playwright-cli/

三種 agent 都要使用時，執行：

cd /path/to/your-project
playwright-cli install --skills=agents
playwright-cli install --skills=claude

只裝 headless shell 時，用以下命令取代上面的兩條，避免 install --skills 再下載完整版 Chromium：

cd /path/to/your-project
PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 playwright-cli install --skills=agents
PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 playwright-cli install --skills=claude

安裝到目前使用者的所有專案

-g 把 skill 裝到使用者家目錄，不初始化專案，也不下載瀏覽器或建立設定檔：

playwright-cli install --skills=claude -g  # ~/.claude/skills/playwright-cli/
playwright-cli install --skills=agents -g  # ~/.agents/skills/playwright-cli/

若使用前面安裝的 Chromium，可在家目錄建立設定檔，讓所有專案的 open 預設使用它。完整版 Chromium 的設定：

mkdir -p ~/.playwright
echo '{ "browser": { "browserName": "chromium", "launchOptions": { "channel": "chromium" } } }' > ~/.playwright/cli.config.json

只裝 headless shell 時，省略 channel：

mkdir -p ~/.playwright
printf '%s\n' '{"browser":{"browserName":"chromium"}}' > ~/.playwright/cli.config.json

若同時有專案與全域設定檔，兩者應選用同一種 Chromium 安裝方式；只裝 headless shell 時，兩處都不可指定 channel。

Codex 會讀取 ~/.agents/skills。AGY CLI 的全域 skill 路徑不同：它讀取 ~/.gemini/antigravity-cli/skills，因此把已安裝的完整 skill 資料夾複製過去：

mkdir -p "$HOME/.gemini/antigravity-cli/skills"
cp -a "$HOME/.agents/skills/playwright-cli" "$HOME/.gemini/antigravity-cli/skills/"

若只用 AGY CLI，仍先執行 playwright-cli install --skills=agents -g 作為複製來源。更新 skill 後，也要重新複製到 AGY CLI 的目錄。全域路徑依 Antigravity 官方文件與 OpenAI Docs。

從專案目錄啟動或重新啟動 agent，載入新 skill：AGY 用 agy、Claude Code 用 claude、Codex 用 codex。AGY 可輸入 /skills 確認 skill 已載入。

用 TodoMVC 確認 CLI 可以開啟頁面：

playwright-cli open https://demo.playwright.dev/todomvc/
playwright-cli snapshot
playwright-cli close

此處的 open 使用上方的專案或全域設定。若選擇本機 Edge 且未建立設定檔，在 open 後加上 --browser=msedge。

open 應回傳網址、標題與快照檔路徑。snapshot 會列出元素，例如：

- generic [ref=e6]:
  - heading "todos" [level=1] [ref=e7]
  - textbox "What needs to be done?" [active] [ref=e8]

textbox ... [ref=e8] 是輸入框，可用 playwright-cli fill e8 "買牛奶" 操作。參照編號會隨頁面改變，操作前要讀取當下的快照。

啟動失敗時，檢查所選瀏覽器是否已安裝、設定檔是否指向相同瀏覽器，以及 Linux 發行版或容器映像是否符合 Playwright 系統需求。

3. Angular 開發完成後，怎麼要求 agent 驗證？

在 agent 完成 Angular 功能後，接著要求它依原需求操作實際網站。以下 prompt 可直接接在 AGY、Claude Code 或 Codex 的開發對話後；採專案安裝時，須從安裝 skill 的專案目錄啟動 agent。

請用 playwright-cli 在實際運行的網站上驗證這次開發的功能，
不要只憑程式碼或編譯成功就判定通過。

- 從這次的原始需求整理驗收流程，只測本次相關功能。
- 關鍵畫面截圖存到 artifacts/playwright-validation/。
- 因缺少帳號、資料或服務而無法驗證的項目，標為「未驗證」並說明原因。

最後用表格回報：流程、預期結果、實際結果、通過／失敗／未驗證、截圖路徑。

驗證標準來自原始需求，結果來自實際瀏覽器操作。skill 已說明快照、元素操作、截圖、console 與網路請求的指令。若功能需要登入或修改資料，應先提供測試環境、帳號和可操作的資料範圍。

前一節的 TodoMVC 只檢查安裝是否可用；Angular 功能仍須依需求驗證。

參考資料

• Playwright CLI：技術介紹與命令
• Playwright CLI：安裝、skill 與 Linux 瀏覽器依賴
• Google Codelab：Antigravity CLI 使用專案 skill
• Antigravity 官方文件：CLI skill 的全域位置
• OpenAI Docs：Codex 讀取 skill 的位置

Jev 到底是什麼？一個不聊天、只做決定的 AI

Jev 是最近 AI 社群相當熱門的話題。它主打不生成文字、直接輸出判斷結果，不只在發布後快速獲得開發者採用，也引發了不少關於「是否會取代 LLM（Large Language Model）」甚至「是否是下一代 Transformer」的討論。因此，我整理了目前公開的資料，希望透過這篇文章和同學分享 Jev 的運作方式、適用場景，以及它真正可能帶來的影響。

現在的 AI 應用，經常使用大型語言模型處理分類、評分、路由與風險判斷。即使程式最後只需要一個 true、一個分類結果或一個分數，模型仍得先逐字生成文字，再由程式解析成 JSON（JavaScript Object Notation）或其他結構化資料。

這套做法雖然方便，卻也帶來額外的延遲、成本與格式錯誤。TypeSafe AI 推出的 Jev，正是針對這類「需要理解語言，但不需要生成語言」的工作而設計。

簡單來說，Jev 不是另一個更小、更快的 ChatGPT，而是一個直接輸出有型別答案與機率的 decision model。它比較像是 LLM／Agent 技術堆疊中的新元件，而不是 LLM 的取代者。

---

1. Jev 的起源

Jev 是 TypeSafe AI 在 2026 年 9 月 15 日推出的第一個公開模型。TypeSafe 把這類模型命名為 System One Model。公司創辦人 Diogo Almeida 過去在 OpenAI 參與過 InstructGPT、RLHF（Reinforcement Learning from Human Feedback）與後來 ChatGPT 所使用的相關方法研究；他表示自己這幾年一直在思考一個問題：模型已經很會「跟人類講話」，為什麼真正進入軟體自動化的程度仍然有限。(TypeSafe AI)

TypeSafe 經過約兩年的 stealth development 後，選擇往跟聊天模型不同的方向走：

不再把「產生一串人類喜歡的文字」當作模型的主要輸出，而是讓模型直接產生程式可以消費的 decision

「System One」這個名字來自 Daniel Kahneman《快思慢想》裡的 System 1，也就是快速、直覺式判斷。至於 Jev，則來自經濟學家 William Stanley Jevons。TypeSafe 特別提到 Jevons paradox：蒸汽機效率提高之後，煤炭反而被使用得更多；他們認為 AI intelligence 的單位成本如果大幅下降，也可能帶來更多原本不值得使用 AI 的應用。(TypeSafe AI)

這個名稱暗示了 TypeSafe 對 Jev 的期待：

不是讓一次 AI 呼叫變得更厲害，而是讓 AI 便宜到可以到處呼叫

重點不只是提高單次呼叫的能力，而是降低每次判斷的成本，讓更多應用可以頻繁使用 AI。

---

2. Jev 為什麼受到關注

Jev 受到關注的第一個原因，是創辦人的背景與官方公布的效能數據。

TypeSafe 官方公開的 workflow benchmark 宣稱，在適合 Jev 的 System One 工作上，最高可以達到：

• 約 193.6 倍速度
• 約 444.6 倍成本效率
• latency 約 70–500 ms
• input US$0.042 / 1M tokens
• output 不另外計費

不過這些主要仍是 TypeSafe 自己的 benchmark，而且官方自己也承認 workflow 是他們團隊製作、speedup 屬於較漂亮的一側，因此目前不能直接解讀成「比 Frontier LLM 強 200 倍」(TypeSafe AI)

第二個原因，是開發者已經開始實際使用它。

Vercel 在 Jev 上架 AI Gateway 後公布，上線後 24 小時內，接近 13% 的付費團隊已經使用過 Jev，成為 Vercel AI Gateway 歷來 adoption 最快的新模型；Vercel、OpenRouter 都在發布後幾天內迅速接入。TechCrunch 也報導，TypeSafe 的 API（Application Programming Interface）一度因為流量太大而撐不住。(Vercel)

因此，Jev 的熱度不只來自新穎的技術概念，也來自發布後迅速出現的實際採用。工程師已經開始嘗試把它放進 Agent、router、guardrail 與 classifier 等工作流程，這比單純的模型宣傳更值得關注。

---

3. Jev 如何運作

要理解 Jev，首先需要更精確地釐清它的輸入與輸出形式。

Jev 的介面基本上是：

state
+
questions
↓
Jev
↓
typed decisions + probabilities

使用者先提供一份狀態，例如：

Customer:
"I was charged twice. Fix this immediately or I'm cancelling my account."

接著不是要求它回答一段 JSON，而是直接定義需要判斷的問題：

問題類型：Choice
category:
- billing
- technical
- sales

問題類型：Score
urgency:
- low
- medium
- high

問題類型：Noul
should_escalate?

Jev 會直接輸出類似以下的結果：

category = billing
P = 0.98

urgency = high
confidence = 0.91

should_escalate = 0.94

這組結果表示，Jev 判斷這是一筆帳務問題，並將緊急程度評為 high；同時，它認為這張 ticket 應該升級處理的機率是 94%。應用程式可以根據這些結果，把 ticket 自動路由到帳務團隊，並在 should_escalate 超過預先設定的門檻時轉交人工優先處理。至於是否真的升級，仍由系統設定的規則與門檻決定，而不是 Jev 自行執行後續動作。

Jev 現在主要提供三種 primitive：

類型	用途
Choice	從預先定義的候選項目中選擇
Score	依照預先定義的 scale 評分
Noul	判斷某件事為 True 的機率

而且同一份 state 的多個問題可以平行評估，不用像 autoregressive LLM 一樣：

token1 → token2 → token3 → token4 → ...

逐字產生完整回答。(TypeSafe AI)

---

4. Jev 並沒有拋棄 Transformer

TechCrunch 採訪裡直接把 Jev 描述為：

transformer-based model

所以現在沒有證據支持：

Jev 是 Transformer 之後的下一個架構革命

比較準確的說法是：

Transformer
       │
       ├── LLM
       │     └── autoregressive text generation
       │
       └── Jev
             └── probabilistic typed decisions

TypeSafe 說自己做了新的：

• model architecture
• parallel sampler
• training method

但 Jev 的完整 architecture、parameter count、詳細技術論文，目前都沒有公開。(TypeSafe AI)

因此，把 Jev 描述為下一代 Transformer 並不準確：

Jev 是下一個 Transformer

更準確的說法是：

Jev 真正挑戰的不是 Transformer，而是「所有 AI 任務都應該做成文字生成」這個假設

它改變的是模型處理任務與輸出結果的方式，而不是完全捨棄 Transformer。

---

5. RLCD：讓信心分數具有統計意義

除了輸出方式不同，TypeSafe 還提出一套名為：

RLCD（Reinforcement Learning for Calibrated Decisions）

的訓練方式，簡稱 RLCD。

目前 LLM 常見的概念是：

RLHF
→ 哪個回答人類比較喜歡

RLVR（Reinforcement Learning with Verifiable Rewards）
→ 哪個答案可以被驗證為正確

RLCD
→ 模型給出的 probability 是否反映它真正的正確率

例如一個真正 calibrated 的模型：

所有模型回答「90% 有把握」的題目
→ 長期統計應該真的大約 90% 是對的

這件事對 automation 很重要。

因為一般 LLM 很容易：

Confidence: 98%

但這個 98% 未必真的代表任何統計意義。

Jev 的設計則希望程式可以直接根據機率採取行動：

if ($result->probability > 0.95) {
    autoApprove();
} else {
    sendToHuman();
}

這也是 Jev 跟一般「叫 GPT（Generative Pre-trained Transformer）回 JSON」最大的概念差異之一。(TypeSafe AI)

---

6. 「不會 hallucinate」的真正意思

官方使用了這樣的說法：

Zero hallucinations

但這裡的 hallucination 有明確的範圍。

Jev 真正保證的是：

它不會 hallucinate 出 schema 之外的 output

例如：

Choice:
A
B
C

它不會突然回答：

D

也不會：

{"answer":

JSON 寫到一半壞掉。

因為這種 output 根本不是它可以產生的東西。

但是：

A = 正確答案
B = 錯誤答案

Jev 完全有可能選 B。

Vercel 自己也特別提醒：

typed answer 並不代表 decision 是正確的

所以更精確的描述應該是：

Jev 可以消除 output-format hallucination，但不能消除 semantic error

因此，討論 Jev 時必須保留「格式正確」與「語意正確」之間的區別。(Vercel)

---

7. Jev 對 Agent 架構的影響

真正值得關注的是 Jev 可能如何改變 AI 系統的分工方式。

過去 Agent 常常長這樣：

                 ┌─ classify
                 ├─ routing
                 ├─ safety check
LLM ─────────────├─ priority
                 ├─ scoring
                 ├─ tool selection
                 └─ final response

也就是什麼東西都找 LLM。

Jev 出現後，比較合理的架構可能變成：

                    ┌─ Jev → classify
                    ├─ Jev → risk score
                    ├─ Jev → tool routing
User → LLM Planner ─┼─ Jev → output verify
                    ├─ Code → deterministic rules
                    │
                    └─ LLM → 真正需要生成文字 / 推理

這其實跟現在 Agent 發展方向非常合。

以 Codex、Claude Code 這類 agent 為例：

現在的做法

LLM
 ↓
我要 search？
 ↓
LLM
 ↓
我要 read file？
 ↓
LLM
 ↓
我要 run test？

理論上未來可以變成：

LLM
↓
制定 plan

Jev
↓
tool routing / retry / continue / stop

Jev
↓
risk evaluation

Code
↓
執行

LLM
↓
真的需要理解、修改、解釋時才進場

Vercel 現在列出的 Jev use case 就直接包含：

• 選下一個 tool / subagent
• 決定 continue / retry / ask user / stop
• risk / urgency scoring
• guardrail
• 驗證 LLM output (Vercel)

這應該才是它真正可能影響 Agent architecture 的地方。

---

8. Jev 不會取代 LLM

可以用以下方式區分三者適合處理的問題：

確定規則
│
├─ if / SQL（Structured Query Language）/ traditional code
│
模糊但答案範圍已知
│
├─ Jev / decision model
│
需要理解、規劃、推理、生成
│
└─ LLM

例如：

年齡 >= 18

根本不用 AI。

這張 ticket 是 billing / bug / feature request？

很適合 Jev。

分析這個 bug，找出 root cause 並修改 Laravel code

還是 LLM。

因此，與其把兩者視為競爭關係：

Jev vs LLM

更合適的理解是：

Jev 把我們現在錯用 LLM 做的一部分工作拿走

Jev 更可能接手目前由 LLM 處理、但其實只需要結構化判斷的工作。這可能成為 AI 系統架構的一項重要變化。

---

9. Jev 的使用方式

截至 2026 年 9 月 20 日，Jev 至少可以透過三種管道使用。

目前 Jev 僅提供雲端 API 形式的存取；即使透過官方 SDK、Vercel AI Gateway 或 OpenRouter 使用，底層仍是遠端 API 呼叫，目前尚未公開模型權重或提供本機部署方式。

TypeSafe 官方 API

官方提供 managed API，目前模型是 jev-1.13.0，也有 jev-latest 等 alias。官方已有 console，並提供 Python / TypeScript SDK（Software Development Kit）。TypeSafe 原本以 early access / waitlist 開放。(System One Models)

TypeSafe AI

Vercel AI Gateway

這目前可能是前端 / TypeScript 開發者最簡單的方式：

const result = await evaluate({
  model: 'typesafe-ai/jev',
  state,
  questions
})

Vercel AI SDK 7 已經加入 experimental evaluate API，專門對應這類 evaluation model。(Vercel)

Vercel Jev Model

OpenRouter

對原本就在使用 OpenRouter 的開發者而言，這會是相對方便的接入方式。

目前已有：

typesafe/jev-1.13

以及 latest alias：

~typesafe/jev-latest

價格目前是：

Input  $0.042 / 1M tokens
Output $0

OpenRouter 顯示 32K context。(OpenRouter)

OpenRouter TypeSafe

---

結語：不是每個 AI 任務都需要生成文字

Jev 最值得注意的地方，不只是減少逐 token 生成所需的時間與成本，而是重新拆開了長期被綁在一起的兩件事：理解語言與生成語言。

過去幾年我們把「理解語言」跟「生成語言」綁在一起了，Jev 問的是：如果程式只需要一個 decision，為什麼一定要先生成 language？

兩種處理流程的差異可以簡化為：

ChatGPT / LLM
unstructured input
↓
reason
↓
generate strings
↓
parse JSON
↓
decision


Jev
unstructured input
↓
decision

如果輸入是自然語言，但輸出只需要分類、評分、布林值或路由決策，Jev 這類 decision model 可能比通用 LLM 更適合；如果任務需要規劃、推理、程式修改或自然語言生成，LLM 仍然不可或缺。

因此，Jev 真正挑戰的不是 Transformer，也不是 LLM 本身，而是「所有 AI 任務都應該透過文字生成完成」這個假設。未來的 AI 系統可能不再依賴單一模型包辦所有工作，而是由程式碼處理確定規則、decision model 處理答案範圍已知的模糊判斷，再把真正需要推理與生成的任務交給 LLM。

AI Coding 的成本問題：與其追求最強模型，不如找到夠用的模型

AI Coding 發展到現在，大家已經不太需要討論「AI 能不能寫程式」，真正開始影響實際使用策略的問題，反而是成本。但要比較不同 Coding Model 的成本並不容易，單純比較每百萬 Token 的價格沒有太大意義，因為不同模型完成同一個任務時，使用的 Token 數量、執行時間、成功率與需要人工介入的程度都不同。真正有價值的比較方式，是讓不同模型執行同一個足夠複雜的工程任務，再比較最後的結果。

DHH 最近在 Lex Fridman Podcast 分享了一個很有意思的案例。他讓 AI 將 Python 的終端文字特效程式庫 TerminalTextEffects 重寫成 Rust。這不是單純要求產生一份功能類似的實作，而是需要維持原本的行為與輸出，並透過測試驗證相容性。後續他又讓不同模型嘗試相同任務，結果如下。

模型	結果	完成時間	成本
Fable	成功	約 45 分鐘	約 US$550
GPT-Sol	成功	約 1.5 小時	約 US$46
Grok 4.6	成功	約 1.5 小時	約 US$55
DeepSeek V4 Pro	成功	約 2.5～2.75 小時	約 US$23
GPT-Luna	失敗	—	—
DeepSeek V4 Flash	失敗	—	—

Fable 是其中最快完成任務的模型，大約 45 分鐘就完成，但成本接近 US$550。GPT-Sol 與 Grok 4.6 大約需要一倍的時間，成本卻只有 Fable 的十分之一左右。DeepSeek V4 Pro 更進一步把成本降低到約 US$23，代價則是執行時間增加到兩個半小時以上。

如果這是一個需要工程師坐在螢幕前等待結果的互動式任務，45 分鐘與兩個半小時的差異可能很重要。但如果它是一個可以非同步執行的 Agent Task，甚至是在 CI/CD Pipeline 裡面執行，時間的重要性就可能大幅降低。此時多花兩個小時換取二十倍以上的成本差異，很可能是一筆合理的交易。

Token 價格不是最重要的成本指標

這組測試還帶出另一個很重要的問題：GPT-Luna 與 DeepSeek V4 Flash 都屬於成本較低的模型，但最後沒有成功完成任務。因此只比較模型的 Input Token 與 Output Token 單價，其實很容易得到錯誤的結論。對工程工作而言，更值得關注的指標應該是：

Cost per Successful Task

假設模型 A 執行一次只需要 US$5，但成功率只有 30%，而模型 B 一次需要 US$30，卻幾乎可以穩定完成工作，那麼模型 B 很可能才是實際成本較低的選擇。而且這裡甚至還沒有把工程師的時間算進去。一個 Agent 執行兩個小時，中間完全不需要人工介入，最後產生可以直接 Review 的 Pull Request，與另一個只需要 30 分鐘，但工程師必須不斷修正方向、補 Context、重新執行的 Agent，兩者的實際成本完全不同。

因此更完整的成本模型至少應該包含：模型使用成本、成功率、執行時間與人工介入成本。這些因素加在一起，才比較接近真正的 AI Coding 成本。

Coding Model 可能存在能力門檻

這個案例也讓我重新思考「輕模型」與「高階模型」之間的差異。我們很容易把模型能力想像成線性的關係，例如最強模型是 100 分，中階模型 90 分，輕模型 80 分。如果只是一般的文字處理工作，這種理解可能還算合理，但 Agent Coding 不一定如此。

在長時間、多步驟的工程任務中，模型需要持續理解 Context、規劃下一步、修改程式、執行測試、分析錯誤，再根據結果修正自己的做法。其中任何一個環節持續出錯，都可能導致整個任務無法收斂。因此它比較像存在一道 能力門檻：模型只要超過這個門檻，就可能有能力自行完成整個任務；但如果低於這個門檻，結果不一定只是「慢一點」或「品質差一點」，而可能是根本做不完。

這也是為什麼便宜模型不一定真的便宜。如果一個模型的 Token 成本只有另一個模型的一半，但它無法完成任務，那麼它的 Cost per Successful Task 並不是另一個模型的一半，而是沒有意義。因此選擇 Coding Model 時，我現在更在意的問題不是：

哪一個模型最強？

而是：

哪一個模型是剛好跨過這個任務能力門檻的最低成本選擇？

最強模型不一定是最合理的預設模型

DHH 的測試中，Fable 的結果其實非常好。它最快完成任務，而且如果把這件事情交給一個不熟悉 Rust 的工程師自行研究、實作與驗證，US$550 未必算昂貴。所以這個案例並不能簡單解讀成「Fable 太貴，不值得使用」。

真正值得注意的是另一件事：Fable 值得 US$550，不代表每個任務都需要 Fable。如果 GPT-Sol 花約 US$46 也能完成相同任務，而我並不在乎多等待 45 分鐘，那麼在這個特定情境下，Sol 就可能是更合理的選擇。

這也是我自己使用 AI Coding 工具後越來越明顯的感受：很多工作並不需要最強模型。如果一個中階模型已經可以穩定、完整地完成任務，那麼繼續往上使用更昂貴的 Frontier Model，得到的可能只是速度提升或成功率從 95% 提升到 99%。這些提升當然有價值，但它們是否值得數倍甚至十倍的成本，取決於任務本身。高階模型真正有價值的地方，應該是用在那些只有它才能穩定跨過能力門檻的任務，而不是成為所有工作的固定預設。

Model Routing 不只是依照任務大小選模型

這個案例另外一個值得注意的地方，是後續模型執行任務時，並不是完全從零開始。前面的高階模型已經產生了相當完整的 Plan，後續模型可以基於既有規劃繼續執行。這讓 Model Routing 有了另一種可能。一般談到 Model Routing，最直覺的做法通常是：

簡單問題交給便宜模型，困難問題交給昂貴模型

但在 Coding Agent 裡，其實可以切得更細：同一個任務的不同階段，也可以使用不同模型。例如 Planning 階段需要理解大量 Context、辨識風險、建立 Architecture 與拆解工作，這個階段可以交給能力最強的模型。當 Plan 已經足夠清楚之後，大量 Implementation 工作可能不再需要同等級的推理能力，此時就可以交給成本較低的模型執行。完成之後，再使用另一個模型進行 Code Review 或 Security Review。一個可能的 Workflow 會變成：

• Planning → 高階模型
• Implementation → 中階模型
• Testing / Fix → 中階模型
• Code Review → 不同供應商的高階模型
• Security Review → 適合安全分析的模型
• Documentation → 輕模型

這比從 Session 開始到結束始終使用同一個 Frontier Model，更接近工程上的最佳化問題。如果一個昂貴模型最擅長的是理解複雜需求與建立正確的執行方向，就沒有必要繼續支付相同價格，讓它完成數百次相對機械性的 Code Modification。反過來說，如果 Planning 本身就是最容易讓 Agent 走錯方向的階段，也沒有必要為了節省 Token 成本，而讓能力不足的模型花大量時間自行探索。Model Routing 真正的價值，不只是「選便宜模型」，而是把昂貴模型的能力用在最值得花錢的地方。

找到模型的能力邊界，比追求單一最強模型更重要

要做好 Model Routing，前提是透過大量練習與實驗，逐漸找出每個模型的能力邊界；選對執行者，和選對任務一樣重要。我目前的分工是：Claude 專門處理純 Coding，Codex 用於 Coding、蒐集資訊與撰文，Gemini 則負責其餘各種雜事。

Gemini 的使用額度相對充裕，可以放心使用最新模型；Claude 和 Codex 我則以中階模型為主，分別使用 Sonnet 5 High 與 Terra Medium。這樣的配置下，每一家都能專注處理自己擅長的事情。即使我是使用最便宜的方案，Weekly Limit 也還沒有低於 70% 過。

網路上常見有人批評模型「很笨」。Context Engineering 是否做好，當然會影響結果，但另一個常被忽略的問題是：是否選對模型，也是否把任務交給了它具備的能力範圍。以我的經驗來說，Gemini 處理 Google 相關工作時，準確度「必定」高於另外兩家。這是經過多次實驗後得到的結論：同樣的 Prompt，無論是操作 Kubernetes 或 GCE，Gemini 幾乎都能一次到位；即使把 Gemini 的產出餵給 Claude 與 Codex，它們也會認為 Gemini 的考量更全面。

目前三大模型供應商確實沒有任何一家可以通吃所有工作。與其執著於單一模型的總體排名，更實際的做法是理解各自的長處、持續驗證它們的邊界，然後把合適的工作交給合適的模型。

AI Coding 開始變成工程最佳化問題

過去大家很習慣問：

現在最強的 Coding Model 是哪一個？

這個問題當然還是有意義，但隨著模型能力逐漸跨過許多日常工程任務的最低門檻，它的重要性可能會慢慢下降。接下來真正值得解決的問題可能會變成：

這個 Workflow 的每一個 Stage，應該 Route 到哪一個 Model？

而且長期來看，這甚至不應該由工程師手動決定。Agent Orchestrator 可以根據任務複雜度、Context 長度、歷史成功率、預估 Token 消耗、時間限制與模型價格，自動選擇最適合的模型。當模型執行失敗時，再升級到下一個能力等級，例如：

輕模型 → 中階模型 → Frontier Model

甚至 Planning 與 Review 可以直接使用 Frontier Model，而中間大量 Implementation 自動 Route 到成本較低的模型。到了這個階段，我們最佳化的就不再是單一 Prompt，也不只是單一模型，而是整個 AI Software Development Pipeline。

DHH 這次測試最值得注意的地方，因此不只是 Fable 花了 US$550，而 DeepSeek 只需要 US$23。它真正呈現的是一件更有意思的事情：

AI Coding 不需要永遠使用最強的模型，而是應該為每一個工作階段找到「能力足夠，而且成本最低」的模型

最強模型應該處理只有它能穩定完成的事情。剩下的工作，交給已經足夠好的模型。當 AI Coding 開始大量進入真正的工程流程後，我認為這會比單純追逐「目前 Coding Benchmark 第一名是誰」重要得多。

來源

• Lex Fridman Podcast #501 — DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux
• Lex Fridman Podcast #501 Transcript
• DHH — X
• omacom-io/ttfx — GitHub

模型變強後，初始 Markdown 的重點：從規則清單轉為可驗證的工作地圖

近來「重寫 initial Markdown」的討論，來自新一代模型在理解任務、規劃多步驟工作、使用工具與從錯誤中恢復方面的明顯進步。模型能承接更大的工作單位，也能依檔案、指令與文件自行補齊更多執行細節；人的工作重心因此逐漸從逐步指揮，轉向提供正確的專案脈絡、清楚的邊界與可驗證的成果定義。

早期的 coding agent 與模型較容易遺漏限制、選錯工具、過早宣告完成，或在長任務中失去進度。因此，團隊常將大量「第一步做什麼、第二步做什麼」、「永遠使用某種格式」和舊問題的補丁集中寫進 system prompt、AGENTS.md 或 CLAUDE.md。這些規則曾是提高穩定性的實用方法，但累積後會讓真正重要的專案知識、任務目標與驗收條件被埋在細節裡，也提高每次模型升級後重新校正的成本。

現在需要調整的原因，是把能力較強的模型放進更好的工作環境：initial Markdown 提供一份短而清楚的工作地圖，版本化文件提供可追溯的 source of truth，測試與檢查則提供成果證據。這種設計讓模型保有判斷與執行空間，同時讓專案的安全、品質與可維護性有明確依據。

1. 用短入口檔建立共同工作語言

讓 AGENTS.md、CLAUDE.md 或其他 initial Markdown 承擔四件事：說明專案目標、標出任務邊界、列出常用指令，以及指向重要文件。入口檔維持精煉，agent 才能在每次工作時抓住真正重要的訊號。

OpenAI 的實務做法是將短版 AGENTS.md 當作知識地圖，而不是百科全書；它連到架構、產品規格、執行計畫與品質文件。這種 progressive disclosure 讓 agent 先理解方向，再依任務載入所需細節。

2. 將專案知識做成可查找的 source of truth

把架構、資料模型、API contract、runbook、既有決策與產品規格放在 repo 內、可版本控制且可搜尋的文件。initial Markdown 只需告訴 agent：哪一種問題該讀哪一份資料，以及資料的權威來源在哪裡。

高品質 context 的目標不是「越少越好」，而是「用最少的高訊號資訊，完整描述預期行為」。因此，關鍵限制應保留在入口檔；細節則放在 agent 可即時找到的文件，而不是藏在聊天紀錄或人的記憶中。

3. 把完成標準寫成可驗證的證據

模型能規劃與執行，但專案對「完成」的定義需要明確提供。將驗收轉成可觀察、可重跑的證據：

• 單元測試、整合測試、E2E 與視覺比對
• lint、型別檢查、schema／API contract 驗證
• migration dry-run、release checklist 與 smoke test
• 實際執行的命令、結果，以及未驗證項目的風險說明

這些品質機制比 prompt 措辭更能跨模型沿用。OpenAI 以文件的連結、更新狀態與結構化程度建立機械檢查；Anthropic 的長任務實驗則以 feature list、進度檔、Git 與端到端測試，讓每一個 session 都能接續並驗證前一段工作。

4. 為自主工作提供清楚授權與安全界線

長時間任務要順暢，agent 需要知道哪些事已獲授權、哪些事需要等待確認。把授權寫成具體的工作契約：

類別	建議授權方式
任務範圍內、可復原的本機變更	直接執行，完成後附上 diff 與驗證結果。
發現的旁支問題	記錄在總結或 backlog，保留給後續獨立處理。
刪除資料、部署、改權限、對外發送、金錢操作	明列需取得確認的門檻與負責人。
多 session 工作	每次留下進度、決策、下一步、已驗證與待驗證項目。

這讓 agent 在低風險工作保持節奏，同時在高影響操作前留下足夠的人工控制點。

5. 以任務評測決定規則與 Effort

Effort、模型版本、工具可用性與任務類型都會影響成果。最可靠的做法是建立一組 5–10 個真實且代表性的任務，為每個任務記錄：

• 成功率與驗收結果
• 耗時與 token／費用
• 越界修改、回歸與人工介入次數
• 使用的模型、Effort、工具與 initial Markdown 版本

先保存現況作為 baseline；每次調整一組規則後，重跑相同任務。保留能穩定改善失敗模式的規則，並把可重用的專案知識移到 source of truth。安全、法規與資料保護要求則作為穩定的必要條件持續維護。

一份可直接採用的最小初始檔

# Agent working agreement

## Goal and scope
- 本次任務的功能範圍、允許修改的模組，以及不在範圍內的事項。

## Non-negotiables
- 對外發送、部署、刪除資料、改權限與金錢操作，依既定核准流程處理。
- 使用既有 migration、logging、error-handling 與測試慣例。

## Find the source of truth
- 架構：docs/architecture/index.md
- 資料契約：docs/contracts/
- 執行與驗收：docs/runbooks/verification.md
- 進行中的計畫：docs/exec-plans/active/

## Definition of done
- 完成需求範圍內的變更，並將旁支問題列入後續事項。
- 跑與變更相符的檢查，回報實際命令與結果。
- 清楚列出未驗證項目、原因與風險。

讓 agent 協助重作 initial Markdown

將 agent 納入 initial Markdown 的重作流程，能以目前的 repository、工具與評測結果產出更貼近專案的候選稿。Anthropic 公開提到會用 prompt improver 調整 CLAUDE.md；OpenAI 也以週期性的「doc-gardening」agent 掃描過時文件並提出修正。交付物採用可 review 的候選稿：保留團隊規範，將可發現的專案知識移到文件索引，把品質要求連到可執行檢查。

可直接交給 agent 的 prompt：

請審閱此 repository 的 AGENTS.md／CLAUDE.md 與相關文件，為新一代 coding agent
產生一份 initial Markdown 候選稿。

目標：讓入口檔成為短而高訊號的工作地圖；它必須保留專案事實、不可跨越的安全與
權限界線、常用指令、source-of-truth 索引，以及可驗證的 Definition of Done。

請依序完成：
1. 只讀分析目前 instructions、目錄結構、CI、測試、文件與近期變更。
2. 將每一條現有內容分類為：保留、合併、移至文件、轉為機械檢查、或淘汰；說明理由。
3. 將安全、法規、權限、對外操作與團隊既定規範列為不可自動刪除項目。
4. 產生 `AGENTS.proposed.md`，不要覆寫原檔，也不要修改程式或設定。
5. 提供與原檔的摘要 diff、需人工確認的決策，以及 5–10 個代表性任務的評測計畫。

完成條件：候選稿能指出各種任務的權威資料位置，定義相符的驗收方式，並將可機械化
的規則連到測試、lint、CI 或腳本。

審閱候選稿時，優先確認三件事：專案或組織要求是否完整保留、每個文件連結是否可到達、以及代表性任務的結果是否優於原版。通過後再以 commit 或 pull request 合併；後續可根據真實失敗與 review feedback 繼續迭代。

持續演進的工作方式

1. 以真實任務測試目前的 initial Markdown。
2. 透過 ablation（移除／還原）找出真正影響品質的規則。
3. 將穩定的專案知識版本化，並從入口檔提供清楚索引。
4. 將重複出現的品質問題轉為測試、lint、checklist 或工具契約。
5. 在模型、工具或權限機制改版後，重新跑代表性評測。

初始 Markdown 最終是一份讓 agent 能可靠工作的起點：它提供方向、邊界、知識入口與驗收標準；專案則以版本化文件與可執行檢查，持續累積可被下一代模型繼承的能力。

參考資料

• 影片：Fable 5.1 怎麼 prompt？5 件今天就該改的事
• OpenAI：Harness engineering: leveraging Codex in an agent-first world
• OpenAI：How OpenAI uses Codex
• Anthropic：Effective context engineering for AI agents
• Anthropic：Effective harnesses for long-running agents
• Anthropic：Claude Code Best Practices（/init、CLAUDE.md 與 prompt improver）

How to configure the MCP service for popular AI models

這篇整理 4 個終端型 AI 工具目前支援的 MCP 設定方式：

• Google Gemini CLI
• OpenAI Codex CLI
• Claude Code
• GitHub Copilot CLI

本文假設專案目錄是 /code/chan。

範例都以 minhlucvan/agent-browser-mcp 為例，目標設定如下：

{
  "mcp": {
    "servers": {
      "agent-browser": {
        "command": "npx",
        "args": ["agent-browser-mcp"]
      }
    }
  }
}

先決條件

• 已安裝 Node.js，讓 npx 可用
• 以下範例以 macOS/Linux 路徑表示

1. Google Gemini CLI

Gemini CLI 支援：

• 全域設定：~/.gemini/settings.json
• 專案設定：/code/chan/.gemini/settings.json
• 指令管理：gemini mcp add/remove/enable/disable/list

專案目錄設定

在專案根目錄建立或編輯 /code/chan/.gemini/settings.json：

{
  "mcpServers": {
    "agent-browser": {
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

全域設定

編輯 ~/.gemini/settings.json：

{
  "mcpServers": {
    "agent-browser": {
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

用指令安裝

安裝到目前專案：

gemini mcp add -s project agent-browser npx agent-browser-mcp

安裝到全域：

gemini mcp add -s user agent-browser npx agent-browser-mcp

不進 TUI 列出 MCP

列出目前可用的 MCP server：

gemini mcp list

用指令移除

移除專案設定：

gemini mcp remove -s project agent-browser

移除全域設定：

gemini mcp remove -s user agent-browser

如果只是暫時停用，也可以用：

gemini mcp disable agent-browser
gemini mcp enable agent-browser

2. OpenAI Codex CLI

Codex 支援：

• 全域設定：~/.codex/config.toml
• 專案設定：/code/chan/.codex/config.toml
• 指令管理：codex mcp add/remove/list/get/login/logout

要注意一點：目前 codex mcp add/remove 沒有 scope 參數，實務上比較適合管理全域設定。若你要做專案限定 MCP，直接編輯 /code/chan/.codex/config.toml 會比較明確。

專案目錄設定

在專案根目錄建立或編輯 /code/chan/.codex/config.toml：

[mcp_servers.agent-browser]
command = "npx"
args = ["agent-browser-mcp"]

全域設定

編輯 ~/.codex/config.toml：

[mcp_servers.agent-browser]
command = "npx"
args = ["agent-browser-mcp"]

用指令安裝

Codex CLI 目前最直接的做法是加到全域設定：

codex mcp add agent-browser -- npx agent-browser-mcp

不進 TUI 列出 MCP

列出目前已設定的 MCP server：

codex mcp list

用指令移除

codex mcp remove agent-browser

專案設定怎麼移除

如果你是手動寫在 /code/chan/.codex/config.toml，就把這段刪掉：

[mcp_servers.agent-browser]
command = "npx"
args = ["agent-browser-mcp"]

如果只是暫時不想用，也可以改成：

[mcp_servers.agent-browser]
command = "npx"
args = ["agent-browser-mcp"]
enabled = false

3. Claude Code

Claude Code 的 MCP scope 最完整，分成 3 種：

• local：只對你自己、只在目前專案有效，存在 ~/.claude.json（巢狀於 projects.{專案路徑}.mcpServers）
• project：專案共享，存在專案根目錄 /code/chan/.mcp.json
• user：全域，存在 ~/.claude.json（頂層 mcpServers）

如果你這篇文章要區分「專案目錄設定」和「全域設定」，最適合介紹的是：

• 專案設定：/code/chan/.mcp.json
• 全域設定：~/.claude.json

專案目錄設定

在專案根目錄建立 /code/chan/.mcp.json：

{
  "mcpServers": {
    "agent-browser": {
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

全域設定

編輯 ~/.claude.json，放在頂層 mcpServers：

{
  "mcpServers": {
    "agent-browser": {
      "type": "stdio",
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

用指令安裝

安裝成專案共享設定：

claude mcp add --transport stdio --scope project agent-browser -- npx agent-browser-mcp

安裝成全域設定：

claude mcp add --transport stdio --scope user agent-browser -- npx agent-browser-mcp

如果你想做「只在這個專案對你自己有效」，可以用：

claude mcp add --transport stdio --scope local agent-browser -- npx agent-browser-mcp

不進 TUI 列出 MCP

列出目前可用的 MCP server：

claude mcp list

用指令移除

claude mcp remove agent-browser

如果你先前是用 --scope user 或 --scope project 加的，移除時記得用同樣 scope：

claude mcp remove --scope user agent-browser
claude mcp remove --scope project agent-browser
claude mcp remove --scope local agent-browser

4. GitHub Copilot CLI

GitHub Copilot CLI 支援：

• 全域設定：~/.copilot/mcp-config.json
• 專案設定：/code/chan/.mcp.json 或 /code/chan/.github/mcp.json
• 指令管理：copilot mcp add/remove/list/get

要注意一點：目前 copilot mcp add/remove 是針對 user-level，也就是 ~/.copilot/mcp-config.json。專案層級通常要手動編輯 /code/chan/.mcp.json 或 /code/chan/.github/mcp.json。

專案目錄設定

可以在專案根目錄放 /code/chan/.mcp.json：

{
  "mcpServers": {
    "agent-browser": {
      "type": "local",
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

或放在 /code/chan/.github/mcp.json，作為 repository-level 共享設定：

{
  "mcpServers": {
    "agent-browser": {
      "type": "local",
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

全域設定

編輯 ~/.copilot/mcp-config.json：

{
  "mcpServers": {
    "agent-browser": {
      "type": "local",
      "command": "npx",
      "args": ["agent-browser-mcp"]
    }
  }
}

用指令安裝

Copilot CLI 的 mcp add 目前是寫入全域設定：

copilot mcp add agent-browser --type local -- npx agent-browser-mcp

不進 TUI 列出 MCP

列出目前已設定的 MCP server：

copilot mcp list

用指令移除

copilot mcp remove agent-browser

專案設定怎麼移除

如果是手動寫在 /code/chan/.mcp.json 或 /code/chan/.github/mcp.json，就把 agent-browser 那段刪掉即可。

四套工具差異總結

工具	全域設定	專案設定	可用指令安裝到專案？	可用指令移除？
Gemini CLI	~/.gemini/settings.json	/code/chan/.gemini/settings.json	可以，-s project	可以，gemini mcp remove -s project
OpenAI Codex CLI	~/.codex/config.toml	/code/chan/.codex/config.toml	官方文件偏向手動編輯專案設定	可以移除 CLI 加上的全域設定
Claude Code	~/.claude.json	/code/chan/.mcp.json	可以，--scope project	可以，claude mcp remove --scope project
GitHub Copilot CLI	~/.copilot/mcp-config.json	/code/chan/.mcp.json 或 /code/chan/.github/mcp.json	user-level 可以；project-level 建議手動編輯	可以移除 user-level；project-level 手動刪除

參考資料

• Gemini CLI configuration: https://github.com/google-gemini/gemini-cli/blob/main/docs/reference/configuration.md
• Gemini CLI MCP servers: https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md
• OpenAI Codex config basics: https://developers.openai.com/codex/config-basic
• OpenAI Codex MCP: https://developers.openai.com/codex/mcp
• Claude Code MCP: https://code.claude.com/docs/en/mcp
• GitHub Copilot CLI config directory: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-config-dir-reference
• GitHub Copilot CLI MCP docs: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
• GitHub Copilot CLI command reference: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

How I Actually Use Claude Code, Gemini, Codex, and Copilot Together

本來就有在用 Google Gemini、GitHub Copilot、OpenAI Codex，最近為了研究一些東西也入手了 Claude Code。

老實說，Claude Code 燒 token 跟鬼一樣，所以如果要拿來做 coding 或 code review，強烈建議把內建的 LSP 功能打開。

直接用 /plugin 安裝幾個常用插件：

• code-review
• context7
• skill-creator
• php-lsp
• pyright-lsp
• typescript-lsp

---

LSP 設定

要讓這些 LSP plugin 正常運作，你本機還是要有對應的 language server：

npm i -g intelephense pyright typescript typescript-language-server

這一段其實是關鍵。

因為 LSP 提供的是「結構化程式資訊」（symbol、type、reference），不是單純把整份 code 丟給模型讀。

簡單講就是：

• 沒有 LSP → 靠 token 硬吃整包 code
• 有 LSP → 精準抓需要的 context

這會直接影響兩件事：

• token 使用量
• 回答準確度

---

Claude Code 的優勢

目前「內建 LSP connector」這件事，是 Claude Code 跟其他模型最大的實用差異。

你會很明顯感覺到：

• context 更乾淨
• hallucination 比較少
• 大型專案比較撐得住

---

各家工具怎麼用（我的定位）

因為我自己有一套 agentic workflow，所以不太會去爭哪個模型最強，而是看它「適合做什麼」。

Claude Code

專門拿來 coding / deep code review

優點：

• LSP 整合完整
• 結構理解能力強

缺點：

• token 消耗偏高

---

Google Gemini

基本上是萬用工具人

• 跟 Google 生態整合很深
• UI 我自己最喜歡
• daily reset，沒有 weekly limit，用起來壓力小

我很多生活雜事都丟給它做。

另外裝了 code-review extension 之後，我實測：

👉 它的 /review 品質其實可以逼近 Claude Code（Sonnet）

---

OpenAI Codex

目前我的 coding 主力

有幾次經驗是：

• Claude Sonnet 解不出來
• 換 Opus 還是不行
• Codex 直接解掉

不確定是不是剛好遇到所謂「降智期」，但整體體驗真的很順。

另外它的 image-2 也蠻驚艷的。

---

GitHub Copilot

本質是「model switch + 強 context engineering」

重點不在模型本身，而是：

• IDE 整合超強
• context 處理很聰明

所以我只要回到 IDE workflow，就會開 Copilot。

---

我目前的使用方式

我不會只用一個模型，而是讓它們各自做擅長的事。

例如寫文章：

• 用 Gemini 查資料（準確、快）
• 用 Codex 發散（寫得很順）
• 用 Claude 收斂（結構整理、修正）

讓模型分工，其實比「找一個最強模型」還有效。

---

總結

我自己的結論很簡單：

沒有最強的模型，只有適不適合你 workflow 的工具

如果你願意花時間理解每個工具的設計哲學，再把它們組合起來用，體驗會差很多。