我認為很多想要開發新軟體專案的人,往往在開始的過程中會遇到困難,因為從一個空的代碼庫開始似乎是如此令人生畏。 所以我想快速介紹一下我最新的工作流程,這大大降低了開始所需的努力和時間。 最重要的部分是要有一個好的想法,或者說出一個如果真的能正常運作並且能夠很好地完成其目標的話,對很多人來說會實際有用的東西。 我無法真正幫助你這部分,但常見的建議是解決自己的需求和痛點,這是一個非常好的開始方式。我發現自己不斷在思考專案的想法。 無論如何,下一步是非正式地寫下這個想法,就像你可能會在快速的電子郵件中告訴一位親密的朋友一樣。 你不需要把這變成一個正式的計劃,只需以最快的方式傳達基本想法及其功能,並具體說明你知道想要使用的技術堆棧或庫的任何部分。 附上的截圖顯示了我幾天前隨意想到的一個想法的例子。我花了大約10到15分鐘寫下來。它不需要很長,並且可以引用其他來源以保持簡潔。 這個初步描述然後成為GPT-5 Pro的提示。這通常需要至少15或20分鐘來運行(有趣的是,這比寫提示所需的時間還要長)。你可以嘗試其他模型,但它們的效果會差很多。 然後我經常將相同的提示給Grok4 Heavy或Opus4.1,並將這些想法反饋給GPT-5 Pro,鼓勵Pro採納它在其他提案中看到的任何好想法。如果那些計劃中真的有聰明的東西,GPT-5 Pro會識別並納入它。 然後我會要求Pro根據其第一次回應創建一個詳細的、細緻的markdown計劃文檔,並將其保存為新創建的專案文件夾中的一個文件。 然後我經常會在這個基礎上進行幾次迭代,開始一個新的Pro對話,在網頁應用中給出整個markdown計劃文件,告訴它以各種方式增強計劃,使其更可靠、穩健、高效、直觀、用戶友好,以及其他好的形容詞。 我會鼓勵Pro對最新的文檔、博客、教程等進行徹底的網絡研究,以尋找更好的庫或做事的方法。 然後我會將它提出的修訂粘貼到codex中,並要求codex將修訂整合到現有的markdown計劃文檔中。 經過2到3輪這樣的過程後,事情會穩定下來,你會得到一個非常好的、詳細的計劃。這是所有事情的關鍵,因為當事情仍在計劃階段時,調整和改進它們要容易得多,因為你還沒有任何代碼。量兩次,切一次,等等。 這裡有一個鏈接,指向從這個想法的初始提示中產生的計劃文檔: 在這個階段,我開始添加一個AGENTS dot md文件;我從一個現有的文件開始,並要求Pro(在最新計劃文檔寫成的同一會話中)為這個新專案和技術堆棧進行自定義,同時保留任何通用的內容。 如果有一些至關重要的庫,我有時也會創建一個專門的最佳實踐指南(例如,如果你正在製作MCP伺服器,我會生成一個專門針對fastmcp庫的最佳實踐指南,但我也會詳細說明如何結構化專案,等等。) 在這個階段,我會在單一會話中要求codex開始構建專案結構,創建文件夾和空的佔位符文件,製作.gitignore文件,等等。 在這裡,我的過程與典型方法有著顯著的不同。我首先使用Steve Yegge的beads專案,告訴codex將計劃文檔轉換為一堆任務和子任務,使用beads。 然後我使用tmux創建一堆codex會話,最多8個同時進行(我認為超過這個數量也會運行得很好)…
這是我關於使用 tmux 關閉自動化循環的主題鏈接:
Jeffrey Emanuel
Jeffrey Emanuel11月8日 10:27
我剛剛發現如何利用一些 tmux 的魔法,進一步自動化我的代理工作流程。 現在我正在使用我的 mcp 代理郵件專案,讓一群代理互相交流,討論實施計畫(同時也利用 beads 專案進行任務管理),我仍然需要通過在 codex 中排隊一堆消息來“餵養”這些代理,以保持他們忙碌。 這涉及到逐一通過各個 tmux 窗格(每個 codex 實例一個)並粘貼一些預設消息,或者按幾次上箭頭來重用過去的消息,例如: “選擇下一個你現在可以有效使用的 beads,並立即開始編碼;通過代理郵件告訴其他代理你在做什麼。” 這樣做感覺有點傻且低效,儘管給每個代理足夠的指示讓他們忙碌超過一小時並不需要太長時間。 但現在我意識到,我可以自動在每個相關的 tmux 窗格中排隊一堆消息,只需將這段代碼複製並粘貼到 tmux 會話外的控制台中(這在 zsh 中已測試並正常運行): --- PANES=(${(f)"$(tmux list-panes -a -F '#S:#I.#P' | tail -n +3 | head -n -2)"}) for pane in $PANES; do tmux send-keys -t $pane -l '選擇下一個你現在可以有效使用的 beads,並立即開始編碼;通過代理郵件告訴其他代理你在做什麼。' sleep 0.1 tmux send-keys -t $pane Enter for i in {1..4}; do tmux send-keys -t $pane -l '繼續努力,做有用的工作!並保持溝通!' sleep 0.1 tmux send-keys -t $pane Enter done tmux send-keys -t $pane -l '很好,現在我希望你仔細閱讀你剛剛寫的所有新代碼和你剛剛修改的其他現有代碼,帶著“新鮮的眼光”仔細尋找任何明顯的錯誤、問題、困惑等。' sleep 0.1 tmux send-keys -t $pane Enter tmux send-keys -t $pane -l '務必檢查你的代理郵件,並在需要時及時回覆任何消息;然後仔細按照計畫進行,系統地完成所有剩餘的未完成任務,並在計畫文件中、通過 beads 和代理郵件消息中持續記錄你的進展。不要陷入“溝通煉獄”,讓事情無法進行;主動開始需要完成的任務,但在這樣做時告知你的同事代理,並在計畫文件中記錄下來。當你真的不確定該做什麼時,選擇下一個你可以有效工作的 beads,並開始。' sleep 0.1 tmux send-keys -t $pane Enter tmux send-keys -t $pane -l '好吧,你現在能否將注意力轉向審查你同事代理寫的代碼,檢查任何問題、錯誤、缺陷、效率低下、安全問題、可靠性問題等,並仔細診斷其根本原因,然後在必要時修復或修訂它們?不要僅限於最新的提交,擴大範圍,深入挖掘!' sleep 0.1 tmux send-keys -t $pane Enter done --- 這段腳本: 獲取窗格:查找所有 tmux 窗格,排除前兩個和最後兩個 向每個選定的窗格發送 8 條消息: “選擇下一個 beads...” - 告訴代理開始處理下一個任務 “繼續努力...” × 4 - 重複鼓勵繼續工作 “仔細閱讀...” - 指示進行新代碼審查 “檢查代理郵件...” - 關於協調、避免溝通癱瘓、保持生產力的長消息 “審查同事代理寫的代碼...” - 對錯誤/問題進行同儕代碼審查 每條消息都以字面意義發送(-l 標誌),並在 Enter 之前有 0.1 秒的延遲,以確保 Codex CLI 正確處理它們。
11.2K