Codex 開發的轉變:從 pair programming 到管理 agents 團隊

最近在測試 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 快速生成,程式碼價值快速貶值,真正產生價值的東西就浮現出來了,就是那些專案的背景、限制、決策、優先順序,還有驗收標準。 ...

March 3, 2026 · 1 分鐘 · Jimmy