在你用一大堆代理在新項目上燒掉大量代幣之前，老木工的格言「量兩次，切一次！」值得修訂為「檢查你的珠子 N 次，實施一次」，其中 N 基本上是你能忍受的次數。 我發現，即使是微妙的改進，當你連續多次運行 Opus 4.5 時，仍然會不斷獲得更多的改進（請注意，以下提示僅在你已經使用我最近在我的工作流程的長篇文章中提供的另一個提示將初始 markdown 計劃轉換為珠子後使用）： 「重新閱讀 AGENTS dot md，以便它仍然在你腦海中清晰。仔細檢查每個珠子——你確定它有意義嗎？它是最佳的嗎？我們能改變什麼來讓系統對用戶更有效嗎？如果可以，請修訂珠子。在我們開始實施這些東西之前，在「計劃空間」中操作要容易得多和快得多！ 不要過於簡化事情！不要失去任何功能或特性！ 此外，確保在這些珠子中，我們包括全面的單元測試和 e2e 測試腳本，並提供詳細的日誌，以便我們可以確保在實施後一切正常運行。記住僅使用 `bd` 工具來創建和修改珠子，並將依賴項添加到珠子中。使用 ultrathink。" 我以前只在開始實施之前運行一到兩次，但我最近嘗試了運行 6 次以上，並且不斷進行有用的改進。 如果在珠子的增量改進方面開始平穩，你可以嘗試開始一個全新的 CC 會話，並以以下方式開始： 「首先仔細閱讀所有 AGENTS dot md 文件和 README dot md 文件，並理解兩者的所有內容！然後使用你的代碼調查代理模式來充分理解代碼、技術架構和項目的目的。使用 ultrathink。" 然後跟進與上面顯示的相同提示，但以以下方式開頭： 「我們最近將一個 markdown 計劃文件轉換為一堆新的珠子。我希望你非常仔細地使用 `bd` 和 `bv` 來審查和分析這些。」 你的 markdown 計劃越複雜和精緻，這種技術就越相關。如果你有一個小的、微不足道的計劃和一個非常簡單的項目，這顯然是過度的。但在這種情況下，你可能會發現每一輪的增量收益/變化很少，因此應該很明顯何時該停止。 只需記住：計劃代幣比實施代幣少得多且便宜。即使是一個非常大、複雜的 markdown 計劃也比幾個實質性的代碼文件短，更不用說整個項目了。 而且，當推理一個非常詳細且具體的計劃時，模型會更聰明，這個計劃仍然足夠小，可以輕鬆適應它們的上下文窗口（這實際上是我對計劃的強烈關注的關鍵見解，為什麼我在那部分花了 80% 以上的時間）。 如果你在網頁應用中依賴 GPT Pro 進行擴展推理進行初步計劃，正如我強烈建議的那樣（也就是說，創建和改進你的 markdown 計劃，最終將其轉換為珠子），你基本上可以在 Pro 計劃中以自助餐的方式獲得這些，因此充分利用它！ 在處理容易適應其上下文窗口的輸入時，沒有其他模型可以觸及網頁上的 Pro。這真的是獨一無二的。 ...