我在這裡包含了這個提示的迷你版本，因為「我最喜歡的提示」系列應該是簡潔、易於消化、自成一體的精華。 但今天我將這個轉變為一個真正瘋狂的系統。無論你是在 React 中製作另一個 CRUD 程式還是待辦事項清單，這都不重要，但如果你在 Rust 或 Golang 中做一些相當複雜的事情，或者涉及複雜數據的事情，這種方法幾乎令人毛骨悚然，因為它能做到的事情。 這是一個兩輪的過程。這是第一輪： --- 首先仔細閱讀所有的 AGENTS.md 文件和 README.md 文件，並理解它們的所有內容！然後使用你的代碼調查代理模式來充分理解代碼、技術架構和項目的目的。 然後，一旦你對所有這些做了極其徹底和細緻的工作，並深刻理解了整個現有系統及其功能、目的，以及它是如何實現的，所有部分是如何相互連接的，我需要你超級深入地調查、研究和思考這些問題，這些問題與這個項目有關： 核心系統中是否存在其他明顯的低效？代碼庫中是否有 1) 變更實際上會在整體延遲/響應性和吞吐量方面有所改進的地方；2) 使我們的變更在功能上可證明同構，以便我們確信在相同輸入下不會改變結果輸出；3) 你是否對算法或數據結構有明確的更好方法的願景（注意，對於這一點，你可以在思考中包括不太知名的數據結構和更深奧/複雜/數學的算法，以及重新構建問題的方法，以便暴露出另一種範式，例如下面顯示的列表（注意：在提出任何優化之前，建立基準指標（p50/p95/p99 延遲、吞吐量、峰值內存）並捕獲 CPU/分配/I/O 配置文件以識別實際熱點）： - N+1 查詢/獲取模式消除 - 零拷貝/緩衝區重用/散佈-聚集 I/O - 序列化格式成本（解析/編碼開銷） - 有界隊列 + 反壓（防止內存膨脹和尾延遲） - 分片/條帶鎖以減少競爭 - 記憶化與緩存失效策略 - 動態規劃技術 - 凸優化理論 - 懶惰評估/延遲計算 - 迭代器/生成器模式以避免實現大型集合 - 流式/分塊處理以進行內存受限的工作 - 預計算和查找表 - 基於索引的查找與線性掃描識別 - 二分查找（在數據和答案空間上） - 雙指針和滑動窗口技術 - 前綴和/累積聚合...