我在這裡包含了這個提示的迷你版本，因為「我最喜歡的提示」系列應該是簡潔、易於消化、自成一體的精華。 但今天我將這個轉變為一個真正瘋狂的系統。無論你是在 React 中製作另一個 CRUD 程式還是待辦事項清單，這都不重要，但如果你在 Rust 或 Golang 中做一些相當複雜的事情，或者涉及複雜數據的事情，這種方法幾乎令人毛骨悚然，因為它能做到的事情。 這是一個兩輪的過程。這是第一輪： --- 首先仔細閱讀所有的 AGENTS.md 文件和 README.md 文件，並理解它們的所有內容！然後使用你的代碼調查代理模式來充分理解代碼、技術架構和項目的目的。 然後，一旦你對所有這些做了極其徹底和細緻的工作，並深刻理解了整個現有系統及其功能、目的，以及它是如何實現的，所有部分是如何相互連接的，我需要你超級深入地調查、研究和思考這些問題，這些問題與這個項目有關： 核心系統中是否存在其他明顯的低效？代碼庫中是否有 1) 變更實際上會在整體延遲/響應性和吞吐量方面有所改進的地方；2) 使我們的變更在功能上可證明同構，以便我們確信在相同輸入下不會改變結果輸出；3) 你是否對算法或數據結構有明確的更好方法的願景（注意，對於這一點，你可以在思考中包括不太知名的數據結構和更深奧/複雜/數學的算法，以及重新構建問題的方法，以便暴露出另一種範式，例如下面顯示的列表（注意：在提出任何優化之前，建立基準指標（p50/p95/p99 延遲、吞吐量、峰值內存）並捕獲 CPU/分配/I/O 配置文件以識別實際熱點）： - N+1 查詢/獲取模式消除 - 零拷貝/緩衝區重用/散佈-聚集 I/O - 序列化格式成本（解析/編碼開銷） - 有界隊列 + 反壓（防止內存膨脹和尾延遲） - 分片/條帶鎖以減少競爭 - 記憶化與緩存失效策略 - 動態規劃技術 - 凸優化理論 - 懶惰評估/延遲計算 - 迭代器/生成器模式以避免實現大型集合 - 流式/分塊處理以進行內存受限的工作 - 預計算和查找表 - 基於索引的查找與線性掃描識別 - 二分查找（在數據和答案空間上） - 雙指針和滑動窗口技術 - 前綴和/累積聚合 - 拓撲排序和 DAG 感知的依賴圖 - 循環檢測 - 聯合查找以實現動態連通性 - 圖遍歷（BFS/DFS）及早終止 - Dijkstra's / A* 用於加權最短路徑 - 優先隊列/堆 - 前綴操作的 trie - 濾波器用於概率性成員資格 - 區間/段樹用於範圍查詢 - 空間索引（k-d 樹、四叉樹、R 樹） - 持久/不可變數據結構 - 拷貝時寫語義 - 對象/連接池 - 緩存驅逐策略選擇（LRU/LFU/ARC） - 批量感知算法選擇 - 異步 I/O 批量處理和合併 - 高競爭場景的無鎖結構 - 針對遞歸並行性的工作竊取 - 內存佈局優化（SoA 與 AoS，緩存局部性） - 短路和提前終止 - 字符串內部化以處理重複值 - 平均分析推理 考慮到這些一般指南（如適用）： DP 適用性檢查： - 重疊子問題？→ 使用穩定狀態鍵進行記憶化 - 最佳分區/批處理？→ 前綴和 + 區間 DP - 依賴圖有重複遍歷？→ 單遍拓撲 DP 凸優化檢查： - 硬幹確切的分配/調度？→ LP / 最小成本流與確定性平局打破 - 具有明確損失的連續參數擬合？→ 正則化最小二乘法 / QP - 大的可分解凸目標？→ ADMM / 近端方法 還要注意，如果你知道有寫得好的第三方庫可以很好地工作，我們可以將它們納入項目中。 方法論要求： A) 基準優先：運行測試套件和代表性工作負載；記錄 p50/p95/p99 延遲、吞吐量和峰值內存，並使用確切命令。 B) 提出建議前進行分析：捕獲 CPU + 分配 + I/O 配置文件；在建議變更之前，按 % 時間識別前 3-5 個熱點。 C) 等價預言機：定義明確的金色輸出 + 不變性。對於大型輸入空間，添加基於屬性或變形測試。 D) 每次變更的同構證明：每個提議的差異必須包括一個簡短的證明草圖，解釋為什麼輸出不能改變（包括排序、平局打破、浮點行為和隨機數生成器種子）。 E) 機會矩陣：在實施之前按（影響 × 信心）/ 努力對候選者進行排名；僅專注於可能顯著改變 p95+ 或吞吐量的項目。 F) 最小差異：每次變更一個性能杠杆。沒有不相關的重構。如果存在任何風險，請包括回滾指導。 G) 回歸防護：添加基準閾值或監控鉤，以防止未來的回歸。 使用 ultrathink。 --- 你可以在 Claude Code 中運行一次 Opus 4.5，並在 Codex 中運行一次 GPT 5.2 Codex（我開始只使用 High，因為 Extra High 對我來說太慢，除非我快要上床睡覺）。 在它們完成後，給它們每個大約 5 輪這個： 「很好。再次檢查所有內容，看看是否有明顯的疏漏、遺漏或錯誤、概念錯誤、失誤等。使用 ultrathink」 然後讓它們將輸出保存為這樣： 「好的，將所有內容保存為 PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md」 「好的，將所有內容保存為 PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md」 然後在 Claude Code 中，執行： 「將你所做的與 PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md 進行比較，並從中提取最佳元素，將它們編織到你的計劃中，以便通過在原始計劃文件中進行編輯來獲得混合的最佳方案。」 然後這樣： 重新閱讀 AGENTS.md，以便它仍然在你的腦海中清晰。現在閱讀所有的 PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md。然後仔細檢查每個 bead——你確定它有意義嗎？它是最佳的嗎？我們能否改變任何東西以使系統對用戶更好？我們希望對所有這些有一個全面和細緻的 bead 集合，包含任務、子任務和依賴結構，並附有詳細的註釋，以便整個東西完全自包含和自文檔化（包括相關背景、推理/理由、考量等——任何我們希望「未來的自己」知道的目標、意圖和思考過程，以及它如何服務於項目的整體目標）。這些 beads 應該詳細到我們不需要回顧原始的 markdown 計劃文檔。它是否準確反映了所有的 markdown 計劃文件的內容？如果需要變更，則修訂 beads 或創建新的 beads，或關閉無效或不適用的 beads。在我們開始實施這些事情之前，在「計劃空間」中操作要容易得多且更快！不要過於簡化事情！不要失去任何功能或功能性！此外，確保作為這些 beads 的一部分，我們包括全面的單元測試和 e2e 測試腳本，並附有詳細的日誌，以便我們可以確保在實施後一切正常運行。記住僅使用 `bd` 工具來創建和修改 beads，並將依賴項添加到 beads 中。」 然後幾輪： 「仔細檢查每個 bead——你確定它有意義嗎？它是最佳的嗎？我們能否改變任何東西以使系統對用戶更好？如果是，請修訂 beads。在我們開始實施這些事情之前，在「計劃空間」中操作要容易得多且更快！不要過於簡化事情！不要失去任何功能或功能性！此外，確保作為這些 beads 的一部分，我們包括全面的單元測試和 e2e 測試腳本，並附有詳細的日誌，以便我們可以確保在實施後一切正常運行。使用 ultrathink。」 然後讓群體開始實施所有這些。然後準備好進入第二輪。