Meta PM 不寫程式照樣出貨：Zevi Arnovitz 的 AI 開發工作流完整拆解

本文整理自 Lenny’s Podcast 訪談 Meta 產品經理 Zevi Arnovitz 的內容。

一個完全不懂程式的 PM

Zevi Arnovitz 是 Meta 的產品經理，在此之前他在 Wix 工作。他的背景完全沒有技術成分——高中念音樂，以色列服役時也不在技術單位。

但現在，他獨立開發了一個叫 Study Mate 的產品，讓學生上傳學習資料後自動生成互動測驗。這個產品已經在賺錢了。

一切的轉折點發生在 2024 年底。當時他和太太在日本旅行，看到一支 YouTube 影片——有人用 Bolt 或 Lovable 這類工具，純靠 AI 就把 App 做出來了。

他形容那個瞬間：「感覺就像有人走過來跟我說：『欸，有個新技術你可以試試。對了，你現在有超能力了。』」

回家後行李都沒拆，他就衝到電腦前開始做。

從「害怕看程式碼」到建立完整工作流

Zevi 說他一開始對程式碼是恐懼的：「對非技術背景的人來說，程式碼是世界上最可怕的東西。」

他的策略是漸進式曝光療法：

1. 第一階段：在 ChatGPT 建立一個「CTO 專案」，把 AI 當成技術共同創辦人對話
2. 第二階段：畢業到 Bolt、Lovable 這類視覺化開發工具
3. 第三階段：進入 Cursor，先用 lite mode
4. 最終階段：Cursor + Claude Code，完全掌控

他現在的主力工具組合是 Cursor + Claude Code，並建立了一套完整的 slash command 工作流。

完整 7 步驟：像帶團隊一樣指揮 AI

Zevi 把開發流程拆成 7 個步驟。每個步驟都是一句「快捷指令」，打進去 AI 就知道該做什麼。

你可以把它想成：你是專案經理，AI 是你的工程團隊。這 7 個步驟就是你管理團隊的 SOP。

步驟 1：隨手記下靈感

指令：/create-issue（建立待辦事項）

做 A 功能做到一半，突然想到「欸，B 功能也可以這樣改」——這時候不用停下來，直接跟 AI 說，它會幫你記成一張待辦卡片，存進專案管理工具。

就像跟助理說：「這個先記著，等等再處理。」

步驟 2：搞清楚要做什麼

指令：/exploration-phase（探索階段）

等你準備好要做某個功能，先讓 AI「做功課」。它會去讀相關的程式碼，理解現在系統長什麼樣，然後問你一堆問題：

• 這個功能的範圍是什麼？
• 介面要長怎樣？
• 有什麼特殊情況要處理？

Zevi 說這個階段他會花很多時間來回討論：「這是『隨便做做』和『認真做產品』最大的差別。」

步驟 3：列出執行計畫

指令：/create-plan（建立計畫）

討論完之後，讓 AI 把剛才聊的整理成一份計畫書：

• 重點摘要
• 我們決定怎麼做、為什麼這樣決定
• 要做的事情清單

這份計畫書的好處是，你可以拿給不同的 AI 來執行。比如讓擅長設計的 AI 做畫面，讓擅長邏輯的 AI 做後台。

步驟 4：開工

指令：/execute（執行）

把計畫丟給 AI，讓它開始寫程式。

在 Podcast 錄製現場，Zevi 示範了一次——一個完整功能，幾分鐘就寫完了。

步驟 5：自己檢查一遍

指令：/review（審查）

讓 AI 回頭看自己剛寫的東西，找出可能的問題。

步驟 6：找其他 AI 來「會診」

指令：/peer-review（同儕審查）

這是 Zevi 最得意的設計。

他會同時開三個不同的 AI，讓它們各自審查同一份程式碼。然後把三份審查報告彙整起來，交給主要的 AI 做最終判斷：哪些是真的問題要修，哪些是誤會。

他對 AI 的指示是：「你是這個專案的負責人。其他部門的人看了你的東西，提出這些意見。但你比他們更了解來龍去脈——所以你要決定：是解釋給他們聽為什麼這樣沒問題，還是真的去修。」

他說 AI 有時候會變得很有個性：「這個問題已經被提三次了，我第三次跟你說，這是故意這樣設計的，不是 bug。」

步驟 7：更新說明文件

指令：/update-docs（更新文件）

最後，讓 AI 把這次學到的東西寫進專案文件裡。這樣下次開發時，AI 就有更多背景知識可以參考。

每個模型都是一種「人格」

Zevi 對不同 AI 模型有很生動的比喻：

Claude — 完美的 CTO

「她溝通能力很強，很聰明，不會只是順著你說。她很有主見，但同時又很願意協作。」

OpenAI Codex — 暗室裡的天才工程師

「就像那種穿帽 T、穿拖鞋、坐在暗房裡的頂尖 coder。你只有碰到最難的 bug 才會去找他。他會關上門兩小時，然後出來說『修好了』。你問他怎麼修的，他說『別擔心，反正修好了』。」

Gemini — 瘋狂的藝術家科學家

「設計能力超強，但你看他工作過程會嚇死。你說『重新設計 dashboard 頂部』，他的思考過程是『好，我先刪掉整個 dashboard』然後『啊不對，那是錯的，復原』然後『我可以改資料庫嗎？』——你心想天啊你只是在做 UI 重設計啊。但最後成品很漂亮。」

犯錯後的 Postmortem 是最大的成長槓桿

Zevi 強調，當 AI 犯錯時，不要只是修掉就算了。

他會問 Claude：「是什麼讓你犯這個錯？是 system prompt 的問題，還是工具設定的問題？」

然後更新相關的 prompt 或文件，讓這個錯誤不會再發生。

他說：「這大概是我學到最重要的事之一。不斷回頭檢視你的 prompt，理解哪裡不夠好，然後迭代。這是『還可以』和『真的會用 AI』的人之間最大的差別。」

在大公司能這樣做嗎？

Zevi 的建議是：

1. 先讓 codebase 變成 AI-native — 這需要技術團隊來做，加入大量的 markdown 文件說明各區塊怎麼運作
2. PM 不應該直接碰資料庫 migration 這種高風險操作 — 但獨立的 UI 專案可以
3. 做完後開 PR 給工程師做最後審查 — 不是取代工程師，是加速協作

他預測：「未來幾年，職稱會崩塌，職責會崩塌。每個人都會成為 builder。」

我的觀察

「讓 AI 互相 review」是分散式驗證的智慧

Zevi 的 peer-review 設計，表面上看是「讓不同模型找 bug」，但背後其實是一個很聰明的分散式驗證機制。

每個模型有不同的訓練資料、不同的偏見、不同的盲點。讓它們互相審查，就像找不同背景的工程師來 code review——你會得到更多元的視角，也更容易抓到單一視角會漏掉的問題。

而讓「主模型」當最終仲裁者，又保留了脈絡的一致性。這比單純「找最強的模型」或「人工逐行審查」都來得有效率。

這種「用 AI 審 AI」的做法，我認為會成為未來 AI 輔助開發的標準配備。

「AI 原生世代」的思維模式正在形成

Zevi 說了一句話讓我印象深刻：「每次碰到新挑戰或問題，我第一個想到的就是用 AI 來解決。」

他用接電話的比喻來說明世代差異：老一輩的人被問「怎麼接電話」，會做出拿起話筒的手勢；現在的小孩會直接做滑動手機的動作。

同樣的，他這個世代的工作者，面對問題的第一反應已經是「先問 AI」。這不是工具的選擇，而是思維模式的根本轉變。

這意味著：不是「會不會用 AI」的問題，而是「有沒有建立 AI-first 思維」的問題。後者是更深層的認知重組，也是更難彌補的差距。