Codex Subagents 實作：三個場景讓你開發效率翻倍

用 Codex Subagents 解決日常程式設計中最煩的那幾件事

改個小 bug 要看半天程式碼，寫完一個模組沒人幫你 review，文件永遠落後……這些事你一個人扛，效率自然上不去。把 Codex Subagents 想成「叫了幾個專職同事同時幫你幹活」——你說一聲，他們各自領任務、並行推進，做完回報給你。

場景一：改 bug 不再靠矇

痛點

收到一個報錯，不知道從哪入手。一個檔案看完，發現問題在另一個檔案；跳過去，又發現依賴第三個檔案。繞了一圈，還沒搞清楚根本原因。

怎麼做

1. 把完整報錯資訊直接貼給 Codex，不用自己先分析

2. 讓一個 agent 專門追程式碼呼叫鏈——唯讀、不改程式碼，找出真實執行路徑

3. 同時讓另一個 agent 對照文件，確認涉及的 API 用法是否正確

4. 等兩者都完成後，再讓 Codex 基於這兩份結論寫修復方案

直接複製這個 prompt：

我遇到了这个报错：[粘贴报错信息]

请同时：
1. 用 explorer 追踪报错的完整调用链，找出根本原因，只分析不修改代码
2. 确认涉及的 API 用法是否正确

等两者都完成后，给我一个最小改动的修复方案，并说明为什么这样改。

這比「直接問 Codex 怎麼修」好在哪裡：explorer 看到的是真實執行路徑，而不是 AI 根據程式碼結構猜測的路徑。猜測可能對，但真實路徑一定對。

小貼士：報錯資訊要盡量完整，包括 stack trace 和觸發操作的上下文。資訊越全，呼叫鏈分析越準。

場景二：提交前的自查 checklist

痛點

每次 git push 之前都要自己過一遍，容易漏——漏了補測試、忘了更新文件、安全問題沒發現。靠人工過，越趕越容易出紕漏。

怎麼做

1. 一個 agent 檢查程式碼邏輯和邊界情況

2. 一個 agent 檢查是否有對應的測試，缺什麼

3. 一個 agent 檢查註解和關鍵函式的文件是否同步更新

三件事並行，不用你一項一項地問，一次出結果。

直接複製這個 prompt：

我准备提交这次修改，请在我 push 前帮我做一次快速自查。

同时检查以下三点：
1. 代码逻辑：有没有边界情况没处理、有没有明显的 bug
2. 测试覆盖：新增/修改的逻辑有没有对应的测试用例，缺哪些
3. 文档同步：涉及到的函数、接口注释是否还准确，有没有过时的说明

每项输出一个简短清单，critical 的问题标红（用 [!] 标注），其余按严重程度排列。

用完一次就會形成肌肉記憶：提交前跑一遍這個 prompt，比自己過 diff 穩得多，也比等 code review 打回來省時間。

場景三：讀懂陌生程式碼庫

痛點

接手別人的專案，或者引入一個新開源庫，完全不知道從哪開始看。README 可能過時，註解可能缺失，只能硬著頭皮從入口檔案一行行往下啃。

怎麼做

1. 讓一個 agent 生成整體架構說明：模組劃分、入口檔案、核心資料流、關鍵依賴

2. 讓另一個 agent 找出「最危險」的地方：複雜邏輯、缺測試、註解混亂的程式碼

3. 兩者並行，5 分鐘拿到一份可以直接用的「接手報告」

直接複製這個 prompt：

请帮我快速了解这个代码库，同时做两件事：

1. 生成一份项目地图：主要模块、入口文件、核心数据流、关键依赖，用简洁的中文描述，不超过500字
2. 找出"危险区域"：逻辑复杂但缺少注释、没有测试覆盖、或者有明显坏味道的代码，列出文件路径和简短说明

我是第一次接触这个项目，输出要让我能在10分钟内搞清楚该从哪里开始。

「專案地圖」和「危險區域」缺一不可：只看架構，你不知道哪裡容易踩坑；只看危險區域，你沒有全域概念。兩份報告放在一起，接手效率直接上來。

小貼士：如果程式碼庫很大，可以先指定一個子目錄或核心模組，讓 agent 範圍聚焦，輸出會更精準。

注意一件事

上面三個場景，agent 做的都是「探索和分析」——唯讀程式碼，不做修改，出不了大問題。如果你想讓 agent 直接改程式碼，先從小範圍、單檔案開始，確認它真正理解了你的意圖再逐步放權，不要一上來就把整個模組都交出去。