最近在測試 Codex 怎麼拿來做 AI coding。用了一段時間之後，我覺得它跟之前用 antigravity 的感覺差很多。

之前用 antigravity 的時候，感覺比較接近 pair programming。Codex 則是刻意把 code 的複雜度隱藏起來，用起來的體驗比較像是在管理一個團隊。

站在管理的角度其實就是建立方向與流程，然後給下面的人發揮自己的專長。

開發者的角色變了

以前自己寫 code 的時候，很多技術決策都很直覺，通常就是選自己熟的、自己順手的。

現在主要執行的人慢慢變成 agent 之後，思考方式也跟著變了。人就變成要一直去想大方向跟想要的效果。

目前用 AI coding 一個大問題是怎麼保持對話裡面的重點，常常討論到一半遇到對話壓縮，新的對話 AI 就像被重置了一樣，很像換了一個人接手搞不清楚狀況。

這時候需要有個方式去把對話的重點記錄下來，然後在新的對話裡面把重點補回去。目前大部分 agents 都是靠記憶功能，但是不同公司的模型又沒辦法共用記憶，而且不同專案也不會想要他記憶互相污染，所以想說要有個跟著專案的文件來存這些東西。

建立管理 agents 的流程

想到可以來建立 knowledge base 跟 roadmap，而且這個東西人類也是可以看得懂，不是被高度壓縮結構化只有 agents 看得懂的咒語，一開始其實不知道具體要怎麼設計。那我就直接問 Codex 這個 Roadmap 怎麼做，然後讓他自己產生出他喜歡的形式。

建立 CI/CD 與測試流程也很像。我知道要做測試來確保系統的穩定，但是以前看書不太能真的理解測試案例要到什麼範圍，就叫 Codex 建議測試的粒度，然後再自己手動跑過一遍，從中慢慢了解測試在不同階段要做什麼。

所以很多流程細節，其實不是我先想出來的。比較像是我先知道目標，然後讓 Codex 去把方法長出來。

有了這些東西以後，它就像一個共同入口。你之後如果換 agent、換模型，或者同時有多個 agents 在協作，那這些背景、流程、決策、任務狀態都要有地方可以接續。

這很像新人 onboarding，要讓接手的人知道這個專案在幹嘛、之前做到哪裡、現在在做什麼、接下來要做什麼。

專案的本體被顯露出來

以前我們很容易覺得專案的本體是 code，畢竟 code 才是真正跑起來的東西，而且那是工程師才寫得出來的東西。

但現在 code 可以被 agent 快速生成，程式碼價值快速貶值，真正產生價值的東西就浮現出來了，就是那些專案的背景、限制、決策、優先順序，還有驗收標準。

所以我現在會覺得，knowledge base 幾乎就是整個專案的核心。再加上 roadmap、milestone、decision log、CI 跟測試，這些東西湊在一起，你就做出了一個可以讓專案一直往前走的飛輪。

流程建立起來之後的效果

當 roadmap 建起來之後，後面其實就可以一直問 Codex 下一步要做什麼，它就會沿著那條線繼續推。

新的一天通常要回想一下昨天做到哪，現在只要問一下 Codex 目前的進度跟下一步要做什麼，他就會快速回顧讓人可以進入狀況。

然後做到一半如果發現新的情境，或者想到新的方向，會先把這件事拉出來討論，看它跟主目標的關係，再記進 KB，然後放進 roadmap 排序。

因為很多想法可能不是現階段需要實現，但又怕忘記，這時可以跟他用整個戰略的角度去討論，他就可以幫忙規劃，在下一個 Phase 事情更明朗的時候可以怎麼塞進排程裡面，而不會變成隕石。

brownfield 更有感

如果只是從零開始做新專案，很多東西都還算乾淨，AI 通常也比較容易看起來很厲害。但真實世界更常見的情況，其實還是 brownfield。

就是已經有一個系統在那裡，有歷史決策，有舊架構，也有很多東西根本沒有被清楚記錄下來。

我最近也有跑一個這樣的重構專案。這個專案本來是上一版用 antigravity 跟 Claude 做出來的。

現在換成 Codex 來推，我第一步也是先把 roadmap 跟 knowledge base 建起來。叫他先大致上看過整個專案的結構，然後從他所理解的現況去補充我之前設計的意圖跟目標。

然後去定義目前系統的瓶頸在哪，需要重構的方向與想要達到的優化目標。請 Codex 分析一些可能可以增加效能的方向，不過哪些值得做，哪些不用試，哪些其實跟最終目標沒什麼關係，這些都還是要自己抓。

跟 vibe coding 的差別

vibe coding 容易讓人期待 one shot 就得到對的結果，最後就變成一種隨機抽卡遊戲。

但實際上，軟體開發通是一個探索研究的過程。比較像是把一個本來很抽象的問題，慢慢整理成越來越具體的規則，最後才變成電腦可以執行的東西。

一開始問題都是模糊的，很多需求是做到一半才變清楚，很多規則也是邊做邊發現。細節還是得靠持續迭代，慢慢把問題講清楚。

所以我現在的做法，比較像是我先定目標、定邊界，然後讓 Codex 去補骨架、提方案、往前推，最後再由我一直判斷下去。

回到人身上

用到現在，我最大的感受反而是，軟體工程的瓶頸一直都還是在人身上，只是現在這件事變得更明顯。

因為當 agent 可以很快地生成 code、整理文件、提出方案之後，剩下真正會卡住專案的東西，其實就是人的決策速度。

你要先去想像那個還沒做出來的產品，要把 roadmap 畫出來，要知道哪些事情值得做，也要跟得上 agents 生成出來的結果。

最後負責引導整個專案的，還是人。

所以用了 Codex 的體悟，已經不是單純覺得 AI 幫我把 code 寫更快，而是它把你往管理者那個位置推。然後當 agent 慢慢變成主要執行者之後，專案裡真正重要的東西，也會開始從 code 移到那套可以讓整個專案持續被接手、持續被推進的知識系統上面。