iT邦幫忙

2026 iThome 鐵人賽

DAY 2
0

昨天確定了這 30 天要完成的目標:使用 ChatGPT 和 Codex,一路做出一個可以送進 Pull Request 的 Issue Tracker。

但在真正開始以前,有一個問題一定要先回答:

ChatGPT 也會寫程式,Codex 也能跟我對話,那它們到底差在哪裡?

如果只看文字輸出,兩者有時候確實很像。我可以在 ChatGPT 貼上一段錯誤訊息,也可以在 Codex 詢問某個觀念,它們都能給出解釋或程式碼。

但真正的差異不只是「誰比較會寫程式」,而是它們在工作時取得了哪些上下文、擁有哪些工具,以及最後能交付什麼結果。

先說結論

我目前會用這個方式理解兩者:

  • ChatGPT 適合和我一起想清楚問題
  • Codex 適合進入專案,把已經說清楚的工作完成

但這也不是絕對分工。現在 ChatGPT 與 Codex 的能力可以出現在同一個桌面應用程式中,ChatGPT 也能使用檔案與工具完成工作,所以我覺得比起用產品名稱劃出一條死線,更實用的判斷方式是:我現在需要的是「探索」,還是「執行」。因為 Chat 模式適合提問、理解概念、發想和比較方案,Codex 則可以理解程式庫、開發與測試功能、修正 Bug、Review 變更並準備交付。

ChatGPT:先把腦中的想法說清楚

假設今天只有一句需求:

我要替 Issue Tracker 加上「新增任務」功能。

這時候馬上開始寫程式,通常還太早。

例如,我們還不知道:

  • 任務標題是否必填?
  • 標題最多可以輸入幾個字?
  • 新任務的預設狀態是什麼?
  • 建立成功後要清空表單嗎?
  • API 失敗時畫面要如何回應?
  • 重複標題是否允許?

在這個階段,比較需要一個可以陪我追問、整理與比較方案的對話夥伴,而不是立刻修改專案。

我可以先把下面這段 Prompt 交給 ChatGPT:

我要替一個給個人開發者使用的 Issue Tracker 加上「新增任務」功能。

請幫我分析這句需求中仍然模糊的地方,列出:
1. 需要向產品負責人確認的問題
2. 可以先提出的驗收條件草稿
3. 可能遇到的使用者操作與錯誤情境

目前只做需求分析,不要產生程式碼,也不要自行決定尚未提供的產品規則。

這段 prompt 的回覆

這個 Prompt 可以幫助我發現我還沒有想到的問題。

Codex:帶著 repository 的上下文工作

接著,我把相同的需求帶到 Codex,但多要求它先閱讀目前的專案:

請閱讀目前 repository 中和 Issue Tracker 有關的文件,分析「新增任務」功能。

請列出:
1. 現有文件已經確定的需求
2. 文件之間是否有不一致
3. 實作前仍需要確認的問題
4. 預計會影響的檔案或模組

目前只做分析,不要修改任何檔案。每項結論都附上檔案路徑作為依據。

目前還沒有到建立專案的階段,所以就不放 prompt 的回覆了。

Codex 可以直接讀取這個系列目前建立的檔案,因此它不是只看「新增任務」四個字來回答。這就是 coding agent 的價值之一:它可以把回答建立在 repository 的真實狀態上。

同一個需求,差別在「證據」

把這兩次結果放在一起,可以看到最大的差別不一定是文字品質,而是回答依據。

比較項目 ChatGPT 對話 Codex 專案工作
主要上下文 對話中提供的需求 對話、repository、專案規範與工具輸出
適合的工作 發想、解釋、需求釐清、比較方案 專案導覽、實作、測試、除錯與 Review
能否直接確認現有檔案 未提供或未連接時不能 可以在授權範圍內讀取
能否修改專案 一般對話不會直接修改本地 repository 可以在授權範圍內編輯檔案
能否執行驗證 通常只能建議驗證方式 可以執行指令並回報結果
典型交付物 需求草稿、解釋、方案與 Prompt 可審查的 diff、測試結果與修改摘要

哪些工作先交給 ChatGPT?

當我還在處理以下問題時,會先從 ChatGPT 開始:

  • 我還不能清楚描述問題
  • 需求有多種可能方向
  • 我需要補充背景知識
  • 我想比較幾種技術或產品方案
  • 我需要把散亂想法整理成規格
  • 我還沒準備讓 AI 修改任何檔案

例如:「新增任務時,使用 Modal、獨立頁面還是行內表單比較適合?」這是一個需要討論使用情境與取捨的問題,先探索通常比直接動手更有價值。

哪些工作交給 Codex?

當任務已經進入 repository,並且需要實際證據時,我會使用 Codex:

  • 找出某項功能目前由哪些檔案負責
  • 根據 Issue 提出實作計畫
  • 修改限定範圍內的程式
  • 重現並修正 Bug
  • 新增或執行測試
  • 檢查未提交的 diff
  • 根據實際變更整理 PR 說明

例如:「依照已確認的驗收條件實作新增任務,完成後執行相關測試並摘要 diff。」這已經是一個有明確目標、範圍與驗證方式的執行任務。

最常用的方式:兩者接力

實際工作時,我最期待的流程不是二選一,而是接力:

在 ChatGPT 探索想法
→ 釐清需求與限制
→ 整理成可執行的 Issue
→ 交給 Codex 閱讀 repository
→ 提出計畫並修改程式
→ 執行測試與檢查 diff
→ 回到人類進行最後 Review

以新增任務功能為例,ChatGPT 可以幫我發現「空白標題」「錯誤提示」「建立後的畫面狀態」等需求缺口;需求確認後,Codex 再依照 repository 的實際架構完成修改和驗證。

AI 可以執行,但決定仍由人負責

不論使用 ChatGPT 還是 Codex,以下決定都不能只因為 AI 說「建議這樣做」就直接接受:

  • 產品真正要解決的問題
  • 哪些需求應該進入本次範圍
  • 技術風險是否可以接受
  • 測試是否足以證明行為正確
  • 程式是否符合團隊的維護方式
  • 變更最後是否可以合併

AI 可以提出選項、執行工作並整理證據,但工程師仍需要理解結果,並對最後的決定負責。

今日小結

對這個系列來說,我會採用一個簡單的分工:

還在想清楚問題時,先和 ChatGPT 討論;要進入 repository 執行與驗證時,再交給 Codex。

但不論使用哪一個工具,都要確認它看到了什麼、做了什麼,以及我們要用什麼證據判斷結果。


上一篇
Day 01|從 Prompt 到 Pull Request:這 30 天我們要完成什麼?
下一篇
# Day 03|為什麼「幫我寫一個網站」不是好 Prompt?
系列文
從 Prompt 到 Pull Request:30 天玩懂 ChatGPT & Codex4
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言