用 AI 驅動的產品勝出：Conor Spicer，OpenAI Solutions Engineer

🧑‍🏫 這支是 OpenAI 的解決方案工程師 Conor Spicer，用一家虛構的 Blossom Bank 示範 Codex 怎麼幫金融業又快又安全地做出新功能。Demo 從寫程式、填監管申報，一路做到檢查資安漏洞。就算你不是工程師，也能看出現在 AI 工具的工作模式：人負責下指令和把關，AI 負責動手。

• 00:07 Codex 是 OpenAI 的 AI coding agent，不只能 autocomplete，還能自動化整個軟體開發週期與開發者的許多任務
  ↳ AI coding agent 是會自己動手寫程式、執行任務的 AI 助理。autocomplete 是打字時幫你補下一段。Codex 能做的遠不只這樣，開發流程裡寫、改、測試等很多工作它都能接手。
• 00:07 可以交代 Codex 一件工作，讓它讀 code base 後連續執行好幾個小時，甚至一整天，直到完成
  ↳ code base 就是一個產品的全部程式碼。你交代任務後，Codex 會先讀懂這些程式碼，再自己連續做好幾小時甚至一整天，你不用一步步盯著下指令。
• 00:37 今年二月推出 Codex desktop app，任何人都能用自然語言產生程式碼、完成各種任務
  ↳ desktop app 是裝在電腦上的應用程式。重點是門檻變低：不會寫程式的人，也能用平常講話的方式描述需求，讓 Codex 產生程式碼或處理任務。
• 00:37 講者認為 Codex app 是金融服務業中技術與半技術團隊的理想使用介面
  ↳ 技術團隊指工程師，半技術團隊像分析師、產品經理，懂一點但不寫大型程式。講者認為這個 app 兩種人都好上手，很適合金融業。
• 01:08 Codex app 推出第一週下載量就突破一百萬，之後持續成長
  ↳ 第一週就破百萬下載，代表很多人一推出就搶著試，而且之後還在增加，不是一陣熱潮就退燒。
• 01:08 OpenAI 內部工程師預設使用 Codex，現在一週的出貨量等於以前一個月
  ↳ 出貨指把做好的功能正式推出給使用者。OpenAI 自家工程師平常就預設用 Codex，他們說現在一週做完的量，等於以前一個月。
• 01:08 每位工程師的 PR 數量增加 50%，不必等比例增加人力就能提高程式碼與產品產出
  ↳ PR 是工程師完成一段程式碼後提交、等同事審查的單位。每人 PR 多了一半，代表不用照比例多請人，產出就能變多。
• 01:39 Codex 完全沒有取代工程師，而是改變他們的工作流程，讓他們更有效率
  ↳ 講者強調工程師沒被取代，變的是做事方法：少花時間親手打程式，多花時間指揮 AI、檢查它的成果。
• 01:39 金融業應用例子：重構並遷移 legacy COBOL 系統、自動化法規報告、產出 audit-ready 文件、快速為借貸、交易、支付產品做原型
  ↳ legacy COBOL 系統是銀行沿用多年、用老語言寫的核心系統，Codex 能幫忙改寫搬遷。它也能自動做法規報告（regulatory reporting）、產出隨時經得起稽核的文件，還能快速做出金融產品的試作版。
• 02:09 Demo 情境 Blossom Bank：消費金融產品很強，但面臨競爭者威脅，必須快速推出客戶要求的新功能
  ↳ Blossom Bank 是為了示範虛構的銀行。設定是它原本消費金融很強，但對手逼近，必須趕快把客戶要的新功能做出來。
• 02:09 客戶反覆要求 predictive budgeting：不只看已花多少，而是要預測未來支出、提前規劃
  ↳ predictive budgeting 是預測式預算。一般記帳 app 只告訴你這個月花了多少，這個功能要預估你接下來會花多少，讓你提早規劃。
• 02:39 這類功能以前要花很長時間，並需要多個團隊協調，所以 Blossom Bank 轉向 Codex
  ↳ 這種功能牽涉資料、畫面、後台計算好幾組人，以前光協調就要很久，所以銀行想用 Codex 縮短時間。
• 02:39 Demo 分兩部分：在 Codex app 裡寫程式，以及在 GitHub 裡審查程式碼，確保可以安全出貨
  ↳ GitHub 是工程師存放程式碼、互相審查的平台。Demo 分兩段：先在 Codex app 把功能寫出來，再到 GitHub 檢查程式碼，確認安全才推出。
• 03:10 Codex app 由 GPT-5 模型驅動
  ↳ GPT-5 是 OpenAI 的 AI 模型，也就是 Codex 背後負責理解需求、寫程式的「大腦」。
• 03:43 在 dev 環境執行消費者 app 的模擬，目標是把回顧歷史的 weekly spend 改成預測性的 forecasting 工具
  ↳ dev environment 是開發用的測試環境，和客戶真正在用的版本分開，改壞了也不影響客戶。目標是把「回顧每週花了多少」改成「預測之後會花多少」。
• 03:43 工程師常被拉去緊急會議找資料，可以請 Codex 依 code base、文件與其他工具的 context 幫忙整理
  ↳ 工程師常被臨時叫去開會、被問數字或狀況。這時可以請 Codex 根據程式碼、文件和其他工具裡的資料，幫你整理出答案。
• 04:13 Codex 會跨 observability tools 和 code base 整理摘要；以前要跨團隊協調，現在開會當下就能即時執行
  ↳ observability tools 是監看系統運作的工具，例如錯誤紀錄、效能數據。Codex 能把這些和程式碼一起整理成摘要，以前要問好幾組人，現在開會當場就能查。
• 04:43 除了 ad hoc 使用，也要把最佳做法推廣到團隊，讓它們固定執行，不必每次靠個人決定
  ↳ ad hoc 指需要時才臨時叫它做。講者提醒不能只靠個人偶爾用，要把好用的做法變成團隊的固定流程，定期自動執行。
• 04:43 Codex 提供許多團隊採用的 template solutions，也能自建 automations
  ↳ template solutions 是現成範本，很多團隊直接套用。automations 是自動化，設定一次就會照排程自己跑，也可以自己設計。
• 05:13 Automation 範例：每週工程摘要，在週初整理好本週建了什麼、出了什麼、有哪些阻礙團隊的問題
  ↳ 舉個例子：設定每週自動產生一份摘要，週一開工就整理好本週做了什麼、推出了什麼、有哪些卡住團隊的問題。
• 05:13 功能範圍定義放在 SharePoint，不必切換多個 app，直接請 Codex 用 connector 去找
  ↳ SharePoint 是微軟的企業文件共享平台。connector 是讓 Codex 連進其他工具的接口，它可以自己去翻出規格文件，你不用開好幾個 app 找。
• 05:44 同樣可以從 Jira、Notion，甚至 email（例如別人寄來的更新規格）拉入 context
  ↳ Jira 是追蹤工作進度的工具，Notion 是筆記文件工具。這些地方的資料，甚至別人用 email 寄來的新版規格，都能拉給 Codex 當背景資料。
• 06:15 可以看到 Codex 工作過程的串流，不必手動點選搜尋，但仍能檢視它怎麼運作
  ↳ 你可以即時看到 Codex 正在做什麼、查了哪些東西。搜尋不用自己動手，但每一步都看得到，不是黑箱。
• 06:15 取得檔案後，Codex 會檢查 code base 並立即產生 plan；可在 app 內打開 plan，在改程式前先確認做法
  ↳ 拿到規格後，Codex 會先看程式碼，提出一份 plan，也就是打算怎麼改的計畫。你可以先打開來看，同意了再讓它動手，避免改錯方向。
• 06:46 核准 plan 時可附加其他任務，例如執行 tests，檢查寫出的程式碼是否符合既有標準
  ↳ tests 是自動檢查程式是否正常的測試。批准計畫時可以順便交代它跑測試，確認新程式碼符合團隊原本的寫法和標準。
• 06:46 Codex 開始檢查檔案，並在所有前端與後端服務實作這個功能
  ↳ 前端是使用者看到的畫面，後端是背後處理資料的系統。Codex 會自己把兩邊相關的地方都改好，讓新功能完整可用。
• 07:18 工程方式改變：不再自己打程式碼，而是下 prompt、檢視 agent 的建構過程，完成前還能 steer 改方向
  ↳ prompt 是你給 AI 的指令。工程師的工作變成下指令、看 AI 怎麼做。steer 是中途有新想法時直接插話，讓它調整方向，不用等做完再重來。
• 07:18 完成後可檢視寫出的程式碼與 Codex 提供的 context 和摘要，建立自己對程式碼的理解
  ↳ 寫完之後，工程師要看程式碼和 Codex 附的說明摘要，自己弄懂改了什麼。AI 寫的東西，人還是要看懂才能負責。
• 07:18 新功能已實作成原型，可立即分享給其他人、開始蒐集回饋
  ↳ 原型是可以實際操作的試作版。做好就能馬上給同事或主管試用、收意見，不必等全部完成才給人看。
• 07:49 最後 commit 並 push 新程式碼，等待 review
  ↳ commit 是把這次修改存成一個版本。push 是把它上傳到共用的地方，例如 GitHub，讓別人可以審查。
• 07:49 面對監管與 legacy portal 的阻力：老舊入口網站可能沒有 API，卻要向 regulator 提交消費者 app 的變更摘要
  ↳ regulator 是金融主管機關。legacy portal 是舊的申報網站。API 是讓程式直接和系統交換資料的接口，沒有 API，就只能靠人手動一格一格填。
• 08:20 這類工作以前會拖慢改版速度，整理需求要花很多時間
  ↳ 每次 app 改版都要整理申報資料，光找資料、對格式就很花時間，產品更新的腳步因此被拖慢。
• 08:20 用 Codex 的 skill 搭配 browser automation 工具：理解表單需求，搜尋程式碼找出相關資訊、文件與證據，再填寫 portal
  ↳ skill 是教 Codex 做某類工作的固定做法，browser automation 讓它能自己操作瀏覽器。它先看懂表單要什麼，再從程式碼和文件找出證據，最後幫你填好。
• 08:50 Codex 會驗證內容並存成草稿，不會直接按送出；它會整理變更摘要讓人檢查，由人自己按 submit，讓人保持 in the loop
  ↳ in the loop 指人全程參與、握有最後決定權。Codex 填完只存草稿，並整理變更摘要給人看，按下送出的一定是人自己。
• 09:21 原本要花數小時的任務，縮短到幾分鐘或更短
  ↳ 像填申報這種以前要花好幾個小時的事，現在幾分鐘內就能完成。
• 09:21 在 GitHub 上，自動測試已跑過、人類 reviewer 也已核准，Codex 還能嵌入流程做自動化 review
  ↳ 這時 GitHub 上的自動測試已經通過，同事也審查同意了，Codex 還能在流程裡再加一道自動審查關卡。
• 09:51 Codex 抓到人類 reviewer 漏掉的資安問題：敏感欄位可能處理不當，還能直接交給 Codex 實作修正
  ↳ Codex 抓到同事沒注意到的資安漏洞：敏感欄位（像個資、帳戶資料）的處理可能有問題。你還可以直接叫它把問題修好。
• 09:51 重點一：Codex 能大幅加速開發流程，以及開發者與工程師的其他工作
  ↳ 第一個結論：不管是寫程式，還是工程師手邊的其他雜事，Codex 都能讓速度明顯變快。
• 10:22 重點二：Codex 不只出更多程式碼，還能透過 production-ready 的 contextual code review 確保安全；速度加上安全是它受歡迎的原因
  ↳ contextual code review 是看懂前後脈絡的程式審查，production-ready 指能直接用在正式上線的流程。第二個結論是它又快又安全，所以受歡迎。
• 10:22 講者也承認，大量新程式碼與要學的新工具會對組織造成壓力
  ↳ 講者也坦白說：程式碼一下子暴增，大家又得學新工具，對公司是一種壓力，不是裝了就沒事。
• 10:22 因此講者團隊專注協助客戶的工程團隊 scaffold 新流程，讓程式碼量擴大時也能應付
  ↳ scaffold 原意是鷹架，這裡指幫團隊搭好新工作流程的基本架構。講者團隊就在協助客戶這樣做，讓程式碼變多時，審查和管理也跟得上。

Demo 中，Codex 用 browser automation 填寫監管 portal 後，最後怎麼處理？