GitNexus：讓 Codex 修改程式前先理解 Call Chain 與 Impact Analysis
前言
AI已經很會寫程式，但在大型專案中，真正的問題通常不是「不會寫」， 而是「不了解整個專案的上下文」。
例如:修改一個 API，Codex 需要知道 Endpoint 在哪裡、呼叫了哪些 Service、 Repository 是否共用、DTO 是否被前端使用，以及修改後可能影響哪些功能。
GitNexus 的目的，就是將 Repository 建立成 Code Knowledge Graph， 讓 Codex 在修改程式前，先查詢 Call Chain、相依關係與 Impact Analysis。
GitNexus 解決的問題
GitNexus 的價值不是多一個搜尋工具，而是讓 Codex 先理解程式關係。
適用情境
- 大型 .NET 專案
- API Contract 調整
- Service 或 Repository 重構
- Bug 影響範圍分析
- 舊系統理解與維護
- 跨模組修改
安裝
npm install -g gitnexus@latest
-- 設定Codex MCP
codex mcp add gitnexus -- npx -y gitnexus@latest mcp
進入專案建立索引：
gitnexus analyze
第一次分析後，GitNexus 會建立 Code Knowledge Graph， 修改專案 AGENTS.md及建立skills，讓 Codex 依照專案規則工作。
本機檢視已分析過的 repo
npx gitnexus@latest serve
http://localhost:4747/
Prompt 範例
根據AGENTS.md的內容，它也會自行透過MCP 找index來找到所需的檔案。也可以依提示請它工作:
請先用 GitNexus 找出此 API 從 Endpoint 到 Database 的完整流程，
再整理修改步驟，不要直接修改程式。請使用 GitNexus impact 分析這個 method 修改後會影響哪些呼叫端，
不要直接改程式。修改前請先使用 GitNexus 查詢此功能的 call chain、被誰呼叫、
會影響哪些檔案，整理影響範圍後再提出修改方案。
AGENTS.md 建議
除了GitNexus產生的規則。
建議在 AGENTS.md 中加上一些最重要的工作規則即：
## GitNexus 使用規則
1. 修改 Controller、Service、Repository、DTO、Entity 前，先查 GitNexus Context / Impact。
2. 不得只依賴單一檔案或純文字搜尋判斷。
3. 修改前列出受影響檔案、Call Chain 與資料流。
4. 若索引過舊，先執行 gitnexus analyze。
5. 修改後執行必要的 build / test。.gitignore 建議
通常不建議將 GitNexus 索引資料提交進 Repository。
.gitnexus/結論
GitNexus 真正改變的不是搜尋方式，而是 AI 修改程式的工作流程。
它讓 Codex 在修改前先理解 Call Chain、相依關係與影響範圍， 特別適合大型 .NET 專案、舊系統維護、API Contract 調整與重構情境。
如果已經開始使用 Codex 協助開發，建議將「修改前先查 GitNexus Context / Impact」 寫入 AGENTS.md，讓 AI 的修改流程更穩定，也更接近真實工程團隊的開發習慣。
相關參考
https://vocus.cc/article/69d49b6afd89780001425a4f
https://github.com/abhigyanpatwari/GitNexus
