我們分享了更多關於我們的工作方式：使用 Amp 開發 Amp、orbs、移除功能、不使用 PR。

而最常見的反應並非關於 AI 工作流程或本週流行的圖形工程技術。

而是這個：

「等等，你們不用 PR？你們直接推送到主分支？怎麼做到的？這樣不符合 SOC 2 規定吧。」

跳過 PR 是我們從第一個 commit 就做出的刻意選擇。這也是我們持續交付（ship continuously）的重要原因。

所以，當我們開始著手準備 SOC 2 時，我們直接將這個問題拋給了我們的稽核員：「你們需要 PR 才能做到這點……對吧？」

SOC 2 並不要求 PR。

它要求你思考你的風險。

這才是我們真正學到的。稽核員，以及 SOC 2 本身，比你想像的要靈活得多。我們的稽核員沒有要求我們提供 PR；他們詢問我們的變更流程是什麼，並與我們一起制定了一套適合我們流程的控制措施。

Trust Services Criteria 從未提及 git 或 PR。

他們要求的是變更必須經過授權、測試、批准和記錄——而 PR 只是達成這些目標的一種方式。

這一切都不是什麼高深的學問。

但這也不是刪除了一個步驟的標準流程。

這是一個刻意設計的系統，它能為稽核員提供與 PR 工作流程相同的東西。

而且，程式碼審查（code review）也不在清單上。

標準並未規定必須由第二個人審查 diff。

我們有 20 人，大多是工程師，每個人都非常熟悉程式碼。

人少且高度信任是我們的優勢，我們不會為了我們不需要的流程而犧牲它。

當寫程式碼的速度很快時，緩慢的流程反而成了你真正等待的東西。

但我們不會假裝一個有 2,000 人的公司應該讓每個人都直接推送到主分支。

真正能擴展的是思考你的風險，因為風險在公司內部也不是均勻分布的。

Amp 是面向客戶的生產軟體，我們以這種方式交付它。

同時，許多大公司的程式碼承擔的風險比這小得多，但每一項變更都必須經過相同的流程，這個流程是根據公司營運中最危險的系統來校準的。

而且你不必徹底改造整個公司來解決這個問題。

選擇一個系統並問：「我們的 PR 實際上在這裡管理著哪些風險？」

然後問問還有哪些其他方法可以管理它們。

答案不一定非得是 PR。