我認為許多想要開發新軟體專案的人在專案啟動之初常常會遇到困難，因為從零開始創建一個空白的程式碼庫似乎令人望而生畏。 因此，我想快速介紹我最新的工作流程，它大大降低了入門所需的精力和時間門檻。 最重要的部分是要有一個好主意，或者要製作一個如果真的能正常運作並很好地完成其想要做的事情，就能對很多人真正有用的東西。 這部分我幫不上什麼忙，不過從解決自身（非小眾）痛點入手是個很好的方法，這的確是個不錯的起點。我發現自己總是會冒出很多專案創意。 總之，下一步是用非正式的方式把想法寫下來，就像你給好朋友發一封簡短的電子郵件一樣。 你不需要把它變成一個正式的計劃，只需要用最快的方式傳達基本思路和它的作用，並具體說明你知道要使用的技術棧或庫的任何部分。 附件截圖展示了我幾天前偶然想到的一個想法的範例。我大概花了10到15分鐘就寫完了。文章不需要很長，可以引用其他資料來保持簡潔。 這段初步描述會成為 GPT-5 Pro 的提示。運行過程通常至少需要 15 到 20 分鐘（有趣的是，比編寫提示所需的時間還要長）。您可以嘗試其他模型，但它們的效果會差很多。 我通常會把同樣的提示交給 Grok4 Heavy 或 Opus4.1 進行測試，並將測試結果回饋給 GPT-5 Pro，鼓勵 Pro 採納其他提案中任何有價值的想法。如果這些方案中確實包含一些巧妙的設計，GPT-5 Pro 就會辨識並加以整合。 然後我會讓 Pro 根據其第一個回應建立一個詳細的、細粒度的 markdown 計劃文檔，並將其儲存為一個新建立的專案資料夾中的文件。 然後我通常會反覆修改幾次，在 Web 應用程式中發起一個新的 Pro 對話，提供完整的 markdown 計劃文件，並告訴它以各種方式增強該計劃，使其更可靠、更健壯、性能更佳、更直觀、更用戶友好，以及其他好的形容詞。 我會鼓勵 Pro 對最新的文檔、部落格、教學等進行詳盡的網路研究，以找到更好的程式庫或實作方法。 然後我會將提出的修改意見貼到 Codex 中，並要求 Codex 將這些修改意見整合到現有的 Markdown 計畫文件中。 經過兩三輪這樣的反覆推敲，事情就會穩定下來，最後形成一個非常完善的計畫。這才是關鍵所在，因為在規劃階段，由於還沒有寫任何程式碼，調整和改進起來要容易得多。俗話說，三思而後行。 以下是根據最初的想法而產生的最終計劃文件的連結： https://t.co/mXHOZH9b2p 此時，我開始新增 AGENTS dot md 檔案；我從現有的一個檔案開始，並要求 Pro（在編寫最新計畫文件的同一會話中）針對這個新專案和技術堆疊對其進行自訂，同時保留任何通用內容。 如果有一些至關重要的程式庫，我有時也會建立專門的最佳實務指南（例如，如果您正在建立 MCP 伺服器，我會產生一個專門針對 fastmcp 庫的最佳實務指南，其中還會詳細說明如何建置專案等等）。 此時，我要求 codex 在一次會話中開始建立專案結構，建立資料夾和空白佔位符文件，建立 .gitignore 文件等。 我的流程與典型方法截然不同。我首先使用 Steve Yegge 的 Beads 項目，並指示 Codex 使用 Beads 將計劃文件轉換為一系列任務和子任務。 然後我使用 tmux 創建了一堆 Codex 會話，一次最多可以創建 8 個（我認為數量更多應該也沒問題）…
然後我啟動我的 mcp 代理郵件項目，告訴他們註冊郵件並向其他代理介紹自己，完整閱讀 AGENTS dot md 和計劃文檔（按名稱引用此文件），並在初始郵件中查看 beads 任務。 之後，只是循環播放同樣的預設訊息，我告訴他們選擇一個任務並開始做，鼓勵他們反覆完成幾次，然後檢查他們的工作，然後查看他們的經紀人郵件並回覆任何需要回复的訊息，以及與他們的其他經紀人溝通他們的工作進展。 我昨天錄製了一個 23 分鐘的視頻，展示了這篇文章中示例項目的這一部分是如何工作的，視頻裡把這一切都解釋得很清楚了： https://t.co/KedUEzSRRG 錄完之後，我琢磨出如何自動化最後這部分操作，這樣我就可以用 tmux 廣播命令，自動將大量訊息排入隊列發送給所有客服人員，讓他們忙上好幾個小時。我會在下面附上那篇文章的連結。 這就是基本流程。如果你按照這個流程來做，你可以在幾天內創建出極其複雜且功能強大的軟體，可能只需要一兩個小時的實際“人工時間”，但卻需要大量的代理工時（類似於人工工時）。 當自主代理不使用 gpt-5-codex 指令進行工作時，其每小時的工作量可能相當於人類的 10 到 20 小時。它們的思考和打字速度真的很快！
這是我關於使用 tmux 實現自動化閉環的帖子連結：
以下是 MCP Agent Mail 專案的鏈接，正是這個專案讓這一切成為可能： https://t.co/aXsf08Pms7