從 Pull Request 到 Prompt Request：一個單人開發者的 AI 工作流革命

本文整理自 The Pragmatic Engineer Podcast 2026 年 1 月 28 日播出的單集，訪談 PSPDFKit 創辦人 Peter Steinberger。

{{< youtube 8lF7HmQ_RgY >}}

{{< spotify "episode/5Ie6QtG7V0KLK4BZBtiT7j" >}}

---

一天 600 Commits，而且不是 slop

Peter Steinberger 說他有一天提交了 600 個 commits。當主持人 Gergely Orosz 追問「這不是 slop 嗎？」的時候，Peter 笑著說：「有人做過 code review，說這些居然不是 slop。對，裡面有很多技巧。」

這個數字聽起來很誇張。但當你聽完他的工作流程，你會發現這不是什麼噱頭，而是一種完全不同的開發範式。

Peter 說他現在同時跑 5 到 10 個 AI agent。他會設計一個 feature，確認大方向之後，把任務丟給 Codex（他偏好的 AI 工具），然後切到下一個專案繼續設計。當這邊還在「cooking」的時候，他已經在另一個專案上做決策了。40 分鐘後，第一個任務完成，他回來驗收、微調，然後再丟下一個任務。

他把這個過程比喻成《星海爭霸》：「你有主基地，也有側翼基地提供資源。你要一直在不同基地之間切換。」

這不是傳統意義上的「寫程式」。這比較像在管理一個團隊——只是你的團隊成員是 AI。

不叫 Vibe Coding，叫 Agenting Engineering

Peter 明確表示他不喜歡「Vibe Coding」這個詞。「這個詞現在幾乎變成一種 slur（貶義詞）了。」

他給自己的工作方式取了一個名字：Agenting Engineering，帶星號。（那個星號代表「凌晨三點以後就變成 Vibe Coding 了」。）

為什麼這個區分重要？因為 Vibe Coding 給人的印象是「隨便亂試」，但 Peter 做的事情完全不是這樣。他強調，因為 AI 把「寫 code」這件事自動化了，他反而需要花更多心力在思考上。「我的腦力消耗比以前更大，因為我不是管理一個員工，我是同時管理五到十個員工，每個都在做不同的事。」

他依然維持在 flow state（心流狀態），但這個 flow 的性質不一樣了。以前的 flow 是在 code 層面——你在想怎麼把這個函數寫好。現在的 flow 是在系統層面——你在想怎麼設計這個架構，怎麼把任務拆解給 AI，怎麼驗證輸出。

這是一種「更高一層」的工程——你不再是工人，你是工頭。

Pull Request 是 Prompt Request

Peter 說了一句話讓我印象很深：「我現在看 Pull Request，其實更想看的是 prompt。那才是高訊號的東西。」

傳統的 code review 流程，我們會仔細看 diff，看這個人改了什麼、為什麼這樣改。但在 AI 輔助開發的時代，code 本身變得沒那麼重要了——因為 AI 可以輕易地重寫一遍。真正重要的是：這個人是怎麼引導 AI 到達這個結果的？

Peter 說他現在收到 PR，通常會先問對方：「可以把 prompt 也附上嗎？」因為這樣他能更快理解對方的思路。如果 prompt 夠好，他可能直接拿這個 prompt，用他自己的 agent 重新實作一遍，然後「weave in」（編織進）他的 codebase。

對，他用的詞是「weave in」，不是「merge」。因為他幾乎不會直接 merge 別人的 code。他會用別人的 prompt 當作起點，讓 AI 重新寫一個更符合他架構的版本。

這個工作流程徹底顛覆了傳統的 PR 審核模式。PR 不再是「這段 code 能不能用」，而是「這個思路值不值得採納」。

不看 Code，靠的是什麼？

你可能會問：不看 code 怎麼知道品質好不好？

Peter 的答案是：靠 Closing the Loop（我在前一篇文章詳細談過這個概念）。簡單來說，他設計系統的方式，讓 AI 可以自己跑測試、自己驗證輸出。如果測試通過、lint 通過、功能正常，他就信任這個結果。

這不代表他完全不看 code。他會看架構——這個 module 放在對的位置嗎？這個 API 設計合理嗎？但他不會逐行 review。「很多 code 真的就是無聊的 plumbing。資料從這個格式轉成那個格式，存進資料庫，再用另一個格式吐出來。這些東西，AI 寫得比我好，我幹嘛自己寫？」

他把自己的角色定位成「architect」和「builder」。設計系統是他的事，實作細節是 AI 的事。

CI 也變了

既然工作流程變了，周邊的工具鏈自然也跟著變。

Peter 說他現在不太 care 傳統的 CI（持續整合）。「為什麼我要 push 上去，等 10 分鐘，等 CI 跑完？我本地就可以跑啊。」

他有一個他稱之為「GATE」的流程——就是本地跑 lint、build、test 的全套驗證。有趣的是，這個詞是 AI 自己發明的。「AI 會問我：Should I run full GATE? 我也不知道這個詞哪來的，但它用得很順手，我就跟著用了。」

這個小細節其實透露了一個更深的轉變：當你跟 AI 密切協作久了，你們會發展出一套共同的語言。這不是你在「使用工具」，這比較像你在「跟同事合作」。

我的觀察：這是不是太激進了？

聽完 Peter 的工作流程，我有兩個感覺。

第一個感覺是：這太激進了，大部分人做不到。Peter 是一個有 15 年經驗、曾經把一家公司做到獨角獸等級的資深開發者。他對系統架構的理解，讓他可以放心把實作交給 AI，因為他知道怎麼設計一個「AI 不容易搞砸」的系統。但對經驗不足的人來說，這種工作方式可能會變成災難——你不知道 AI 在你看不到的地方挖了什麼坑。

第二個感覺是：但這可能就是未來。Peter 不是在做 prototype 或 side project。Clawdbot 是一個真的有人在用的產品，Discord 社群一週內從 100 顆星暴漲到 3,300 顆星。這不是玩具，這是真槍實彈的開發。如果這種工作流程能產出這樣的結果，那「傳統」的開發流程遲早會受到挑戰。

Peter 自己也承認，這種方式不適合所有人。他說有些工程師真的很熱愛「解決困難問題」的過程——想演算法、想最佳化、想那些 tricky 的細節。這些人用 AI 會很痛苦，因為 AI 正在搶走他們最愛的部分。

但如果你是那種「我比較在乎產品有沒有 ship」的人，這種工作流程可能會讓你如魚得水。

結語：你比較像工人還是工頭？

聽完這集 podcast，我一直在想一個問題：我比較像工人還是工頭？

傳統的軟體開發，工程師某種程度上是「知識型工人」。你有專業技能，你產出 code，你的價值在於你的 coding 能力。但 AI 正在把「coding」這件事商品化。當 coding 的成本趨近於零，你的價值就必須往上遷移——往設計、往架構、往產品思維。

Peter 的工作流程，本質上就是這個遷移的極端版本。他不寫 code 了，他設計系統、管理 agent、做產品決策。他的「產出」不是 code，是一個能正確運作的產品。

這不代表每個人都要變成這樣。但至少，這讓我們看到一個可能的未來——一個「寫 code」本身不再是稀缺能力的未來。

在那個未來，你想當工人還是工頭？