Builders Unscripted 第 3 集：Alchemy 產品負責人 Matias Castello（第 1/2 段）

🧑‍🏫 這支是 OpenAI 的訪談節目，來賓是加密貨幣基礎設施公司 Alchemy 的產品負責人 Matias。他不是工程師，但靠 AI 工具 Codex 在公司和下班後都做出大量成果。影片示範非工程師也能讓 AI 在你睡覺、出門時持續幫你做事，並說明怎麼安排才不會失控。

• 00:13 Matias 做過消費性產品，早期在 Facebook 做開發者平台，現任 crypto 領域 Alchemy 的產品負責人。他不是工程師出身，卻比很多工程師做出更多東西
  ↳ Matias 不是工程師，做過消費性產品，早期在 Facebook 做給開發者用的平台，現在是加密貨幣領域公司 Alchemy 的產品負責人。他親手做出的東西，卻比很多工程師還多。
• 00:44 他說關鍵是對很多事情有興趣、長期不斷嘗試，並隨著模型變強而越做越好
  ↳ 他說秘訣不是天分，而是好奇心廣、長期持續動手試。AI 模型每變強一次，他能做的事就多一些，時間一長，差距就拉開了。
• 01:14 Alchemy 第一次用 AI 大約在一年前，是 Codex in Slack，用來從 Slack 小幅修改開發者文件（developer docs）
  ↳ Alchemy 第一次導入 AI 約在一年前，用的是 Codex in Slack。Codex 是 OpenAI 會寫程式的 AI，接進工作聊天工具 Slack 後，就能直接叫它小改給開發者看的說明文件。
• 01:14 以前改文件要在本機跑網站，流程繁瑣。現在只要在公司 Slack 的 docs channel 加入 Codex，直接叫它改。主持人說 OpenAI 內部也這樣做
  ↳ 以前就算只改一個錯字，也得在自己電腦把整個文件網站跑起來才能改，很麻煩。現在在 Slack 文件頻道直接叫 Codex 改就好，OpenAI 內部也是這樣用。
• 01:47 更大的轉折是 code review：一次小事故源自數月前的大型 migration，內部 postmortem 找出 race condition 並修好
  ↳ 轉折發生在 code review（程式上線前的檢查）。一次小事故追到幾個月前的大型 migration（大規模改寫系統），事後檢討（postmortem）查出是 race condition：兩個動作同時跑，先後錯了就出包。
• 01:47 有同事提議事後回頭跑 Codex code review，看它能不能抓到這個 bug，結果真的抓到了。他們又這樣試了幾次
  ↳ 同事提議拿當時的程式碼讓 Codex 補做一次檢查，看它抓不抓得到這個 bug。結果真的抓到了，他們又拿別的案例試了幾次。
• 02:21 大家開始好奇。Matias 認為這是模型能力的轉折點，團隊採用這類工具的條件也大多到位了
  ↳ 這件事讓大家開始認真看待 AI。Matias 認為模型能力在這裡跨過一個門檻，團隊要採用這類工具需要的條件，也差不多都齊了。
• 02:21 幾天後，他看到一位工程師把 Codex review 當隊友：在 PR comment 下 @Codex review，處理它提出的意見，再 review，如此反覆
  ↳ 幾天後他看到有工程師把 Codex 當隊友：在 PR（提交程式修改、請人審查的申請）留言 @Codex review，改完它挑的問題，再請它看，一輪一輪來回。
• 02:52 大家逐漸跨過一個心理門檻：過去認為 LLM 不夠好，幫不上大型複雜、要服務大量使用者的專業 codebase
  ↳ 以前大家認為 LLM（大型語言模型，ChatGPT 這類 AI 的核心）只能寫小東西，碰不了大公司那種複雜、服務大量用戶的程式碼。這個成見開始鬆動。
• 03:22 主持人說很多公司都是在 code review 發現許多事故其實能被 Codex 自動抓到，也有公司像 Alchemy 一樣回放過去的事故
  ↳ 主持人說這不是個案。很多公司都是在 code review 時發現，不少事故其實 Codex 能自動抓到。也有公司像 Alchemy 一樣，拿過去的事故回頭測試。
• 03:22 主持人舉例：Datadog 在一月表示，超過五分之一的事故原本可以靠 Codex 避免
  ↳ 主持人舉 Datadog 為例：這家公司一月時表示，超過五分之一的事故原本可以靠 Codex 避免。
• 03:22 主持人個人推測，以 GPT 5.5 現在的能力，這個比例可能輕易過半，甚至十分之九
  ↳ 這一點是主持人的個人猜測，不是統計數據：以 GPT 5.5 現在的能力，這個比例可能輕鬆過半，甚至到九成。
• 03:52 Matias 現在工作上大量用 Codex 做 PM 類任務，例如寫文件。他們在內部建立了許多 skills，讓 PM 工作更容易、更好、更快
  ↳ 工作上 Matias 大量用 Codex 做 PM 的事，例如寫文件。團隊做了很多 skills，也就是寫好的固定做法說明，讓 AI 每次都照同一套標準完成某類工作。
• 04:23 這些 skills 包含寫 PRD、分析客戶回饋等，團隊成員也會重複使用
  ↳ 例如寫 PRD（產品需求文件，說明要做什麼、為什麼做），或整理分析客戶回饋。做好一次之後，團隊其他人都能拿來重複用。
• 04:23 公司有一個跨部門共享的 skills repo：同樣的工作能做得更快更好，不是 PM 的人也能做這些事
  ↳ 公司有一個跨部門共用的 skills repo（集中存放檔案的地方）。同樣的工作能做得更快更好，不是 PM 的人也能照著做出這類工作。
• 04:23 主持人認為開發者不只是人類，也包括使用平台與基礎設施的 agent，要確保 Codex 這類工具能快速整合 OpenAI API 或 Alchemy 的基礎設施
  ↳ 主持人認為「開發者」不只是人，也包括會自己使用平台的 AI agent（能自行完成多步驟任務的 AI）。平台要讓 Codex 這類工具能很快接上來用。
• 04:54 Alchemy 首先是基礎設施公司，產品很技術。內部開發者的工作方式已經改變，這點大家都很清楚
  ↳ Alchemy 本質上是基礎設施公司，產品很技術。公司內部工程師的工作方式已經因為 AI 改變了，這點大家心知肚明。
• 05:25 身為開發者平台，他們也得改變打造工具的方式。現在他們假設 100% 的開發者都在 AI 協助下寫軟體，平台要跟著演進
  ↳ 所以他們做給外部開發者的工具也得跟著改。現在他們的前提是：所有開發者都是邊用 AI 邊寫程式，平台要照這個前提設計。
• 05:25 另一個較新興的方向：開發者有時是自主 agent，需要的工具不同。它們必須能自己註冊、整合，並用區塊鏈執行任務
  ↳ 另一個新方向是 autonomous agent（不用人盯著、自己做事的 AI）也成了使用者。它要能自己註冊、自己串接，再用區塊鏈完成任務，需要的工具跟人不一樣。
• 05:55 人類開發者與自主 agent 兩種需求長期可能會匯流，但目前仍相當不同。他的工作就是想清楚兩邊各要做什麼
  ↳ 長遠來看，人和 AI 這兩種使用者的需求可能會合流，但現在還差很多。他的工作就是分清楚兩邊各需要什麼、該先做什麼。
• 06:25 6、7 年前沒有 AI 時，典型創業流程是：先做原型 → 募資 → 雇小團隊 → 再做真正的產品
  ↳ 六七年前還沒有 AI 時，創業的標準路線是：自己先做個粗略原型，拿去募資，有了錢再雇小團隊，才開始做真正的產品。
• 06:56 他當年自己做原型，基本上是到處複製貼上程式碼直到能動。募資後雇 3～4 位工程師做第一版 MVP，花了不少錢、好幾個人，也花了好幾個月
  ↳ 他當年的原型是到處複製貼上程式碼，拼到能動為止。募資後雇了三四位工程師做第一版 MVP（只含核心功能的最小可用版本），花了錢、人力，也花了好幾個月。
• 06:56 他猜今天用 AI、自己一個人重做當年那個 app 的第一版，應該不到一週
  ↳ 他估計今天自己一個人加上 AI，重做那個 app 的第一版應該不用一週。以前要一個團隊做好幾個月的事，現在一個人一週就能完成。
• 07:26 主持人分享：他當年的產品約 15 位工程師做了大約一年半，才達到交付給許多客戶的 V1 里程碑
  ↳ 主持人也分享：他當年的產品約 15 位工程師做了一年半左右，才做到能交給許多客戶使用的第一版。
• 07:56 兩人認為現在大概是當 founder 最好的時機，有任何想法都有工具能直接試
  ↳ 兩人都覺得現在可能是創業最好的時機。有想法時不用先找錢、找人，可以直接用工具做出來試。
• 07:56 Matias 業餘幾乎一天一個專案，但曾一直焦慮自己做得不夠，現在大致走出來了
  ↳ Matias 下班後幾乎一天做一個專案，但他曾一直焦慮，覺得自己做得不夠多。這種壓力他現在大致已經放下了。
• 08:27 他曾因出門而內疚，覺得該一直用這項技術做東西。他不喜歡這種取捨，所以打造一套設定，讓自己少待在電腦前，讓 Codex 連續工作數小時
  ↳ 他以前出門玩會內疚，覺得應該一直用 AI 做東西。他不想二選一，於是設計了一套流程，讓自己離開電腦時，Codex 還能連續做好幾小時。
• 08:58 流程一：描述新點子，讓 Codex 擬計畫、實作、測試，完成後通知他。到這個程度，要讓 Codex 工作好幾小時很容易
  ↳ 第一種流程：他描述新點子，Codex 自己擬計畫、寫程式、測試，做完再通知他。設定到這個程度後，讓 Codex 自己跑幾個小時很容易。
• 08:58 流程二：針對既有產品，讓 Codex 研究該做哪些新功能。它會看競品、看其他點子，並推敲他的目標與個人偏好
  ↳ 第二種流程：針對已經在做的產品，叫 Codex 研究下一步該加什麼功能。它會看競爭對手、找其他點子，並揣摩他的目標和個人喜好。
• 09:28 他寫了一組 skills，讓 Codex 以模組化方式實作點子：用 feature flag 包起來，在主 app 裡做成實驗
  ↳ 他寫了一組 skills，讓 Codex 把每個點子獨立做好，包成 feature flag（功能開關，可以隨時打開或關掉某個功能），放進主 app 當實驗。
• 09:28 睡前叫 Codex 研究某個 app，想出並實作前十名功能，早上醒來就有十個可開關的 feature flag
  ↳ 實際例子：睡前叫 Codex 研究某個 app，挑出最值得做的十個功能並做出來。早上起床，就有十個功能開關等他一個個打開試。
• 10:00 目的是讓自己不再是產生新點子的瓶頸，同時保留決定哪些功能留下的控制權
  ↳ 用意是讓自己不再卡在「想點子、做出來」這一步，由 AI 大量產出。但哪些功能留下，最後還是由他決定。
• 10:00 他有所謂的「Codex moments」：午休時用個人筆電派工作給 Codex，週末出門吃晚餐、喝酒前或睡前也會派一批工作
  ↳ 他有所謂的「Codex 時刻」：午休時用私人筆電派工作給 Codex。週末出門吃飯喝酒前、睡前，也先派一批出去，人不在時它照樣做。
• 10:33 他認為用這種方式投入經營，能完成的事多到驚人
  ↳ 他的感想是：像這樣持續經營、把零碎時間都拿來派工作，累積下來能完成的事多到驚人。
• 10:33 Demo：他的 linear 裡有 12 個同時進行中的專案，但不是一次全做
  ↳ Demo 開始。他在 Linear（一種管理專案和待辦任務的工具）裡有 12 個同時進行的專案，但不是一次全部一起做。
• 10:33 範例專案：一個 mac app（後來也做了 iOS 版），用 Codex App server 幫他在電腦前寫出更好的文字。最初是為工作而做
  ↳ 範例是他自己做的 mac app，後來也做了 iPhone 版，用途是幫他在電腦前把文字寫得更好。一開始是為了工作需要而做的。
• 11:06 用全域快捷鍵（他設 command shift spacebar）叫出小視窗。它用 Codex App Server，在設定中背後使用他的 GPT subscription
  ↳ 按全域快捷鍵（任何畫面都能用，他設 Command+Shift+空白鍵）就能叫出小視窗。背後接 Codex App Server，讓自製 app 能呼叫 Codex，用的是他自己的 GPT 訂閱。
• 11:06 他通常用說的而不是打字，因為做什麼都快很多。一年前同事還笑他戴耳機像客服人員，現在很多人也戴類似耳機
  ↳ 他習慣用講的，不打字，因為做什麼都快很多。一年前同事還笑他戴耳機像客服人員，現在很多人也戴類似的耳機。
• 11:36 示範：口述一句要發在 Slack、不太通順的訊息，按 command return，因為選了 professional mode，會改寫得更專業
  ↳ 示範：他口述一句要發在 Slack、講得不太順的話，按 Command+Return。因為選了 professional（專業）模式，這句話就被改寫成正式通順的訊息。
• 12:06 這個 app 背後用 Codex Server 與 GPT 5.5，有 model picker。5.5 剛推出，他就加進去了
  ↳ 這個 app 背後用 Codex Server 搭配 GPT 5.5，還有 model picker（選擇要用哪個模型的選單）。GPT 5.5 一推出，他就馬上加進去了。
• 12:06 後來他把同樣的設定放進 iOS app，做成 keyboard extension，可以快速改寫文字
  ↳ 之後他把同樣的功能放進 iPhone，做成 keyboard extension（可以替換的自訂鍵盤），打字時就能直接叫它改寫。
• 12:37 他知道有人用 Codex app server 做其他寫程式介面。他則是用在非寫程式用途，因為想讓推論透過自己的 ChatGPT 帳號進行
  ↳ 有人用 Codex app server 做寫程式的介面，他則拿來做非寫程式的用途。原因是他想讓 AI 的運算都走自己的 ChatGPT 帳號。
• 12:37 linear 上某個專案有 159 個已完成的 issue，另有一些在 review 或進行中。他一個都沒建立或寫過，全部由 Codex 產生
  ↳ 他在 Linear 上某個專案已有 159 個完成的 issue（待辦任務單），另有一些在審查或進行中。這些任務單一張都不是他寫的，全部由 Codex 產生。
• 13:08 做法：透過自己寫的 skills 跟 Codex 談需求，產生計畫並拆成 milestones（例如 foundation、preferences 與各功能），再建立任務並執行
  ↳ 做法是用他寫的 skills 跟 Codex 聊需求，產出計畫並拆成 milestones（階段目標，例如打基礎、使用者設定、各項功能），再建成任務一個個執行。
• 13:08 Codex 依據他建立的 agent’s .md 檔，用合理的方式處理任務。這個檔案總結了他喜歡的工作方式
  ↳ Codex 會照他寫的 agents.md 檔案做事。這個檔案寫著他偏好的工作方式，像給新同事的工作守則，所以 AI 處理任務的方式會合他的意。
• 13:42 他花很多時間寫這個單一檔案。有新專案或新點子時，用它初始化專案，再用 skill 建計畫，之後只要告訴 Codex「build the plan」
  ↳ 他花很多時間磨這一個檔案。有新點子時，先用它建立新專案，再用 skill 產出計畫，之後只要跟 Codex 說「build the plan（照計畫做）」就好。
• 13:42 主持人整理：linear 是介面，用來管 backlog 與 release milestones。Codex 不只寫 issue，也會自己領取 issue 並完成
  ↳ 主持人整理：Linear 是操作介面，用來管 backlog（待辦清單）和各版本的上線階段。Codex 不只會開任務單，還會自己領任務、把它做完。
• 14:15 他同時委派專案管理（設定專案、milestones、任務）與任務執行。他負責發起專案，並提供點子與足夠的偏好資訊
  ↳ 換句話說，「管專案」（建專案、定階段、開任務）和「做事」他都交給 AI 了。他只負責起頭，並提供足夠的點子和個人偏好。
• 14:45 他認為用 LLM 寫程式最大的落差在於：產出讓你意外、不如預期時，通常是因為它必須做一個或多個假設，而且假設的方式跟你不同
  ↳ 他認為 AI 寫程式最大的落差在這裡：結果不如預期，通常是因為它不得不自己做一些假設，而它猜的方向跟你想的不一樣。

根據 Matias 的說法，Alchemy 第一次使用 Codex 是用來做什麼？