開發者用 AI：程式設計代理、費用與安全交接

做法

1. 1交給它之前，先寫好或指出用來檢查的依據：那個失敗的測試，或指令及其預期輸出。
2. 2用本頁的提示詞交代任務，包括它可以修改哪些檔案、不可以修改哪些。
3. 3讓它自己執行檢查，並貼上最終輸出。
4. 4像審查同事的 pull request 一樣審查 diff；檢查通過是審查的開始，而不是結束。

內建功能

• ChatGPT · Codex
• Claude · Claude Code

可複製的提示詞

任務：[修改內容]。
完成的標準：[測試或指令] 通過並輸出 [預期輸出]。結束前執行一次，並貼上結果。
你可以修改：[路徑]。不要修改：[路徑]、相依套件或測試。
如果你無法讓它通過，就停下來說明原因，不要繞過檢查。

容易出錯的地方

• 代理有時會用放寬測試的方式讓測試通過。禁止它修改測試，並在 diff 中留意這種情況。
• 一個檢查涵蓋不了的任務，就大到不適合一次交出去。把它拆開。

做法

1. 1選一個離你的程式碼最近的：Codex Cloud、GitHub 上的 Copilot 雲端代理，或網頁版的 Claude Code。
2. 2確認它的環境能安裝你的相依套件並執行你的測試；少了這些，代理就只是在猜。
3. 3送出小而獨立的任務，每一項都附上自己的檢查，就像上一項任務那樣。
4. 4先讓自動審查工具讀過每個 pull request，再自己審查。

內建功能

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

可複製的提示詞

在這個程式碼庫中：[任務]。
背景：[程式碼中的位置、相關 issue]。
完成的標準：[測試或指令] 在你的環境中通過；把它的輸出放進 pull request 說明。
pull request 的修改行數要少於 [行數] 行。如果需要更多，就停下來，提出拆分的方式。

容易出錯的地方

• 需要機密或服務、而你又沒有設定好的測試，會被略過或失敗。少了這些的綠燈結果，證明不了什麼。
• 多個代理處理相關的程式碼，產出的 pull request 會互相衝突。讓平行的任務各自待在不同的範圍。

做法

1. 1把你的建置、測試和 lint 指令放進代理每次工作階段開始時都會讀取的指示檔案；各代理的文件都會寫明這個檔案的名稱。
2. 2在 Claude Code 中加入 hooks，在每次編輯後執行格式化工具和測試，讓代理看到失敗並自行修正。
3. 3讓機器人審查每個 pull request：在 Codex 中開啟「Automatic review」，或把 Copilot 指定為審查者。
4. 4代理同一個錯誤犯了兩次，就把它變成一個測試，或指示檔案中的一條規則。

內建功能

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

可複製的提示詞

讀取這個程式碼庫，並為程式設計代理撰寫指示檔案：
1. 安裝、建置、測試、lint 和格式化的確切指令。
2. 用 10 行以內說明專案結構。
3. 新人在這裡常弄錯的慣例，各附一個例子。
4. 代理在這裡絕對不能做的事，例如修改 migration 或編輯自動產生的檔案。
只列出你成功執行過的指令；其餘的標為「未驗證」。

容易出錯的地方

• 指示檔案裡的指令如果已經失效，等於在教代理忽略這個檔案。設定變更時，重新執行一遍這些指令。
• 審查機器人也會自信滿滿地犯錯。把它們的留言當成建議就好。

做法

1. 1列出你最常貼進對話的內容，例如 issue、錯誤日誌、文件或資料庫結構描述。先連接這些。
2. 2為每一項加入官方的 MCP 伺服器，並使用只能讀取的權杖。在 Gemini CLI 中，一個擴充功能可以把 MCP 伺服器和它的設定打包在一起。
3. 3給它一個需要用到這些連接的任務，並確認它呼叫的是正確的那一個。
4. 4每隔幾週，移除你不再使用的伺服器。

內建功能

• Gemini CLI · Extensions

可複製的提示詞

在修改任何東西之前：讀取追蹤系統中的 issue [編號]，在日誌中找到錯誤，並查閱 [函式庫] 的文件。
說明每一項告訴了你什麼，以及你認為出問題的是哪個檔案。
不要寫入任何已連接的工具。

容易出錯的地方

• 網頁、issue 或文件中可能藏有專門用來操控代理的文字。不要給會讀取外部內容的工具寫入權限。
• 寫在設定檔裡的權杖會外洩。使用用戶端的機密儲存功能或環境變數，絕對不要放進程式碼庫。

做法

1. 1先確認你已經付費的項目：ChatGPT 方案包含 Codex，Claude 的付費方案包含 Claude Code。
2. 2在代理會顯示用量的地方，記下幾次典型工作階段的 token 用量。
3. 3用本站的 API 價格頁面計算這些用量的費用，並和訂閱比較。
4. 4自動化和 CI 要使用設有支出上限的 API 金鑰，以免一個失控的迴圈讓帳單暴增。

內建功能

• ChatGPT · Codex
• Claude · Claude Code

可複製的提示詞

以下是我 [次數] 次典型工作階段的用量：[輸入和輸出 token 數]。我每週大約工作 [天數] 天。
依照這些價格估算我按 token 計費的每月費用：[從 API 價格頁面貼上]。
把它和每月 [價格] 的訂閱比較。列出計算過程，讓我可以核對。

容易出錯的地方

• 訂閱也有用量限制。任務做到一半碰到上限會浪費時間；除了價格，也要確認限制。
• 影響帳單最大的是模型。用你實際使用的模型來比較。

做法

1. 1在程式碼庫中執行 /init：它會分析程式碼庫，寫出一份入門用的 CLAUDE.md，或針對你現有的那份提出改進建議。
2. 2團隊規則，例如建置和測試指令、程式碼規範，放在 ./CLAUDE.md 並提交。你個人的偏好，要套用到所有專案的放在 ~/.claude/CLAUDE.md，只用於這個專案的則放在 CLAUDE.local.md。
3. 3較長的文件用指向的方式，不要整份貼進去：@path/to/file 會在啟動時匯入另一個檔案。
4. 4每當 Claude 同一件事錯了兩次，就加上那一行原本能防止錯誤的說明。

可複製的提示詞

讀取這個程式碼庫，並改進 CLAUDE.md。控制在 60 行以內：
1. 建置、測試和 lint 的確切指令。
2. 用幾行說明專案結構。
3. 新人在這裡常弄錯的慣例。
4. 絕對不能編輯的檔案和資料夾。
刪除任何已經不正確的內容。把你沒有執行過的指令標為「未驗證」。

容易出錯的地方

• CLAUDE.md 裡的所有內容每次工作階段都會載入，並占用上下文。把細節移到它匯入的檔案中。
• 已經不正確的指示比沒有指示更糟。設定變更時，重新檢查這些指令。

官方文件寫道： Claude Code docs: How Claude remembers your project

做法

1. 1按 Shift+Tab，直到狀態列顯示「plan mode on」，或在提示詞開頭加上 /plan。
2. 2描述要做的修改，以及哪些地方不能改。Claude 仍然可能執行指令來探索，但在規劃期間不會編輯檔案。
3. 3像讀設計說明一樣讀這份計畫：有沒有改錯檔案、漏掉情況、修改範圍太大。要求它修改，直到計畫正確為止，然後再核准。
4. 4開始下一個不相關的任務之前，用 /clear 重新開始。

可複製的提示詞

/plan 修改 [對象]，以達成 [目標]。限制：[不能改變的部分]。
列出你會動到的檔案、修改的順序、證明每個步驟正確的測試，以及任何你不確定的地方。在我核准之前，不要編輯任何東西。

容易出錯的地方

• 計畫動到的檔案比你預期的多，就是警訊。核准之前先問原因。
• 規劃模式仍會執行指令來探索。它並不會讓一個陌生的程式碼庫變得可以安全執行。

官方文件寫道： Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

做法

1. 1開啟 /permissions，查看每一條規則以及它來自哪個設定檔。
2. 2把團隊的規則放在 .claude/settings.json 並提交。個人規則放在 ~/.claude/settings.json 或 .claude/settings.local.json。
3. 3規則的檢查順序是先 deny，再 ask，最後 allow，所以一條 deny 規則會蓋過任何 allow。
4. 4用 Shift+Tab 切換模式：acceptEdits 會核准工作目錄中的檔案編輯。bypassPermissions 會關閉確認提示和安全檢查；官方文件說只能在沒有網路連線的隔離容器或虛擬機器中使用。

可複製的提示詞

看看你在這次工作階段中執行過的指令。為 .claude/settings.json 提出權限規則：允許我們每天使用的唯讀和測試指令，拒絕任何會讀取機密或刪除專案以外內容的操作，其餘一律設為詢問。每條規則用一行說明。

容易出錯的地方

• 一條符合任何指令的 allow 規則，等於沒有確認提示。只允許明確的指令。
• .claude/settings.json 裡的規則一旦提交，就會套用到整個團隊。像審查程式碼一樣審查它們。

官方文件寫道： Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

做法

1. 1在不相關的任務之間，/clear 會以空白的上下文開始一段新對話。
2. 2在長任務中，指定重點的 /compact，例如「/compact 保留計畫和失敗的測試」，會摘要先前的內容。
3. 3把大範圍的搜尋交給子代理：每個子代理都在自己的上下文視窗中執行，所以只有它的答案會回到你的工作階段。
4. 4Claude Code 在接近上限時也會自動壓縮；在適當的時機自己壓縮，就能保留你選擇的內容。

內建功能

• Claude Code · Subagents

可複製的提示詞

/compact 保留：目標、計畫、目前為止修改過的檔案，以及仍然失敗的測試。捨棄探索過程。

容易出錯的地方

• /clear 會忘掉整段對話。任何之後還會用到的內容，都要先寫進 CLAUDE.md。
• 你從子代理那裡拿回來的只有它的答案。請它提供檔案路徑和行號，而不只是結論。

官方文件寫道： Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

做法

1. 1用 claude --worktree <name>（或 -w）開始每個工作階段。它會在 .claude/worktrees/<name>/ 下建立一個 git worktree，使用分支 worktree-<name>。
2. 2依照官方文件的建議，把 .claude/worktrees/ 加進 .gitignore。
3. 3每個工作階段只給一項附有自己檢查的任務，這樣你就能一個一個審查。
4. 4像處理其他 pull request 一樣，審查並合併每個分支。

可複製的提示詞

你正在分支 worktree-[名稱] 上的 worktree 中工作。任務：[一項修改]。完成的標準：[測試或指令] 通過。只在這個分支上提交；不要合併或 rebase 其他分支。

容易出錯的地方

• 每個 worktree 都是獨立的資料夾，所以相依套件和建置輸出不會共用。每個都要各自安裝。
• 兩項任務如果動到相同的檔案，不管有沒有用 worktree，合併時還是會衝突。

官方文件寫道： Claude Code docs: Run parallel sessions with worktrees

做法

1. 1在空白的輸入框中按兩次 Esc，或輸入 /rewind（/checkpoint 和 /undo 也可以）。
2. 2選擇出錯之前的時間點，還原對話、程式碼，或兩者都還原。
3. 3了解它的限制：被 rm、mv 或 cp 等 shell 指令改動的檔案不會還原，在 Claude Code 之外或其他工作階段中所做的編輯也不會。
4. 4有風險的步驟之前先提交。檢查點是用來在工作階段內快速復原的，不能取代 git。

可複製的提示詞

開始之前，先提交目前的狀態，提交訊息寫「[任務] 前的檢查點」。接著執行 [任務]。執行任何會刪除或移動檔案的指令之前，先問我。

容易出錯的地方

• rewind 救不回被指令刪掉的檔案。只有 git 可以。
• 你在這段期間手動做的編輯也不會被記錄。rewind 之前先把它們提交。

官方文件寫道： Claude Code docs: Checkpointing · Claude Code docs: Commands

做法

1. 1claude -p "..." 以非互動模式執行。--output-format json 或 stream-json 會產生指令碼可以解析的輸出。
2. 2成功時結束狀態為 0，失敗時為非 0，所以 CI 可以據此分支處理。
3. 3在 CI 中加上 --bare，讓執行不依賴本機設定。
4. 4針對 pull request，/install-github-app 會設定 Claude Code GitHub Actions（僅限 github.com 上的程式碼庫）；之後在 pull request 或 issue 留言中提及 @claude 即可。

可複製的提示詞

claude -p "閱讀與 main 之間的 diff。列出每一個會新增相依套件、涉及身分驗證或修改資料庫 migration 的變更，以 JSON 格式輸出：{\"files\": [], \"reason\": \"\"}。如果沒有，就回傳空清單。" --output-format json

容易出錯的地方

• 指令碼會以你給它的權限執行。只給 CI 它最少需要的權限。
• /install-github-app 只適用於 github.com 上的程式碼庫。

官方文件寫道： Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

做法

1. 1在 CLI 中執行 /init，在目前的資料夾寫出一份入門用的 AGENTS.md。
2. 2個人的指引放在 ~/.codex/AGENTS.md，專案規則放在程式碼庫中。子資料夾可以有自己的檔案；離 Codex 工作位置越近的檔案越優先。
3. 3讓這些檔案保持簡短：它們的總大小有上限，預設為 32 KiB。
4. 4加上一個「## Code Review Rules」區段：Codex 在 GitHub 上的審查會遵循它。

可複製的提示詞

讀取這個程式碼庫，並撰寫 AGENTS.md：
1. 安裝、建置、測試和 lint 的確切指令。
2. 用幾行說明專案結構。
3. 新人在這裡常弄錯的慣例。
4. 一個「## Code Review Rules」區段，寫明審查者一定要標出的問題。
只列出你成功執行過的指令；其餘的標為「未驗證」。

容易出錯的地方

• 檔案太長反而對你不利：總大小預設上限為 32 KiB。
• 子資料夾的檔案如果和根目錄的檔案矛盾卻沒有說明，會讓人和 Codex 一樣困惑。寫明它覆寫了哪些內容。

官方文件寫道： Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

做法

1. 1在 CLI 中，/permissions 可以切換模式，/status 則會顯示目前生效的核准政策和可寫入的資料夾。
2. 2「Ask for approval」是建議的預設模式，會在工作區內編輯和執行指令，要超出工作區之前會先暫停。
3. 3「Approve for me」使用同樣的沙箱，但核准請求會交給自動審查，而不是交給你。
4. 4「Full access」會移除檔案系統和網路的限制。官方文件對此附有警告；只在可以隨時丟棄的環境中使用。

可複製的提示詞

開始之前，先執行 /status，告訴我核准政策和可寫入的資料夾。接著執行 [任務]。任何需要網路或會寫入這個程式碼庫以外位置的指令，執行前都要先問我。

容易出錯的地方

• 使用「Approve for me」時，沒有人會閱讀每個請求。只在錯誤動作很容易復原的地方使用。
• 「Full access」適用於整台機器，而不只是程式碼庫。

官方文件寫道： Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

做法

1. 1codex exec "..." 以非互動模式執行，預設使用唯讀沙箱。
2. 2需要編輯檔案時加上 --sandbox workspace-write；--full-auto 已經棄用。
3. 3--json 會輸出 JSON Lines 格式的事件串流，供需要掌握每個步驟的指令碼使用。
4. 4在 GitHub Actions 中，openai/codex-action@v1 會替你執行 codex exec。

可複製的提示詞

codex exec "讀取自標籤 [v1.2.0] 以來的變更。撰寫版本說明，分成「新增」、「變更」和「修正」三組：每項變更一行，用使用者看得懂的話來寫，不要附 commit 雜湊值。"

容易出錯的地方

• 較舊的指南仍在使用 --full-auto。它已經棄用；請改用 --sandbox workspace-write。
• 只需要讀取的工作就應該維持唯讀，在 CI 中也一樣。

官方文件寫道： Codex docs: Non-interactive mode · Codex docs: GitHub Action

做法

1. 1CLI 中的 /review 會審查你的工作樹。codex review 則在沒有聊天介面的情況下做同樣的事，比較的對象可以是基礎分支、某個 commit 或尚未提交的變更。
2. 2在 GitHub 上，於 pull request 留言 @codex review。
3. 3在 Codex 設定的「Personal preferences」中開啟自動審查；這樣就不需要留言了。
4. 4把團隊的規則寫在 AGENTS.md 的「## Code Review Rules」區段中。

內建功能

• Codex · Codex code review

可複製的提示詞

## Code Review Rules
- 標出任何涉及身分驗證或權限的變更。
- 標出無法回復的資料庫 migration。
- 標出新的相依套件，並說明是否真的需要。
- 忽略格式問題；linter 會處理。

容易出錯的地方

• GitHub 上的審查只會標出 P0 和 P1 問題。沒有留言不代表設計是對的。
• 審查是第二意見，不是測試執行。測試還是要保留。

官方文件寫道： Codex docs: CLI commands · Codex docs: GitHub integration

做法

1. 1建立一個環境，包含任務需要的程式碼庫、相依套件、工具和存取設定。新的環境會記錄一個安裝指令碼和一個啟動技能。
2. 2為每個環境設定網際網路存取：只允許套件管理工具、只允許指定的網域，或全部開放。
3. 3你可以從 ChatGPT 啟動任務，較長的工作可以從 IDE 擴充功能啟動，或在終端機中用 codex cloud exec 啟動；--attempts 1-4 可以要求多次嘗試以便比較。
4. 4Code Review 以及 GitHub 和 Linear 整合仍在舊版的 Codex Cloud（Legacy）上執行，OpenAI 計劃將其停用。

內建功能

• Codex · Codex Cloud

可複製的提示詞

codex cloud exec --attempts 3 "任務：[修改內容]。背景：[檔案]。完成的標準：[測試] 在這個環境中通過。diff 控制在 [行數] 行以內。"

容易出錯的地方

• 不受限制的網路存取會讓任務能連到任何網站，包括專門寫來操控它的網頁。只允許工作需要的部分。
• 如果缺少安裝指令碼，測試可能根本沒有執行。確認任務真的執行過測試。

官方文件寫道： Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

做法

1. 1在 ~/.codex/config.toml 中設定預設模型和推理強度（model 和 model_reasoning_effort）。CLI 和 IDE 擴充功能共用這個檔案。
2. 2把 profile 建立成獨立的檔案 ~/.codex/<name>.config.toml，並用 --profile <name> 啟動。
3. 3用 codex mcp add <name> -- <command> 新增 MCP 伺服器；每個伺服器都會成為一個 [mcp_servers.<name>] 表格，/mcp 則會列出目前啟用的伺服器。
4. 4/status 會顯示目前生效的設定，codex resume --last 則會接續這個資料夾中最近的工作階段。

可複製的提示詞

讀取 ~/.codex/config.toml 和這個專案的 .codex/config.toml。告訴我目前生效的模型、推理強度、沙箱和 MCP 伺服器，每一項來自哪個檔案，以及任何互相衝突的地方。

容易出錯的地方

• 專案設定只會在受信任的專案中載入。如果某個設定似乎被忽略了，先檢查這一點。
• profile 現在是獨立的檔案。把 [profiles.name] 寫在 config.toml 裡的指南已經過時了。

官方文件寫道： Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands