我在这里包含了这个提示的微型版本，因为“我最喜欢的提示”系列应该是紧凑的、简短的、自包含的内容。 但今天我将其转变为一个真正疯狂的系统。无论你是在 React 中制作另一个 CRUD 程序还是一个 TODO 列表，这都不相关，但如果你在 Rust 或 Golang 中做一些相当复杂的事情，或者涉及复杂数据的事情，这种方法几乎令人恐惧，因为它能做的事情。 这是一个两轮的过程。以下是第一轮： --- 首先仔细阅读所有的 AGENTS.md 文件和 README.md 文件，理解它们的所有内容！然后使用你的代码调查代理模式来充分理解代码、技术架构和项目的目的。 然后，一旦你在所有这些方面做了极其彻底和细致的工作，并深刻理解了整个现有系统及其功能、目的、实现方式以及所有部分如何相互连接，我需要你超强度地调查、研究和思考这些问题，涉及到这个项目： 核心系统中是否存在其他严重的低效？代码库中是否有 1) 变更实际上会在整体延迟/响应性和吞吐量方面产生影响的地方；2) 使我们的变更在功能上可证明同构，以便我们可以确定在给定相同输入的情况下不会改变结果输出；3) 你是否对算法或数据结构有明显更好方法的清晰愿景（请注意，对于这一点，你可以在思考中包括不太知名的数据结构和更深奥/复杂/数学的算法，以及重新构造问题的方法，以便暴露出另一种范式，例如下面列出的列表（注意：在提出任何优化之前，建立基线指标（p50/p95/p99 延迟、吞吐量、峰值内存）并捕获 CPU/分配/I/O 配置文件，以识别实际热点）： - N+1 查询/获取模式消除 - 零拷贝 / 缓冲区重用 / 散点-聚集 I/O - 序列化格式成本（解析/编码开销） - 有界队列 + 背压（防止内存膨胀和尾延迟） - 分片 / 条纹锁以减少争用 - 记忆化与缓存失效策略 - 动态编程技术 - 凸优化理论 - 惰性求值 / 延迟计算 - 迭代器/生成器模式以避免物化大型集合 - 流处理/分块处理以适应内存限制的工作 - 预计算和查找表 - 基于索引的查找与线性扫描识别 - 二分查找（在数据和答案空间上） - 双指针和滑动窗口技术 - 前缀和 / 累积聚合...