我在这里包含了这个提示的微型版本，因为“我最喜欢的提示”系列应该是紧凑的、简短的、自包含的内容。 但今天我将其转变为一个真正疯狂的系统。无论你是在 React 中制作另一个 CRUD 程序还是一个 TODO 列表，这都不相关，但如果你在 Rust 或 Golang 中做一些相当复杂的事情，或者涉及复杂数据的事情，这种方法几乎令人恐惧，因为它能做的事情。 这是一个两轮的过程。以下是第一轮： --- 首先仔细阅读所有的 AGENTS.md 文件和 README.md 文件，理解它们的所有内容！然后使用你的代码调查代理模式来充分理解代码、技术架构和项目的目的。 然后，一旦你在所有这些方面做了极其彻底和细致的工作，并深刻理解了整个现有系统及其功能、目的、实现方式以及所有部分如何相互连接，我需要你超强度地调查、研究和思考这些问题，涉及到这个项目： 核心系统中是否存在其他严重的低效？代码库中是否有 1) 变更实际上会在整体延迟/响应性和吞吐量方面产生影响的地方；2) 使我们的变更在功能上可证明同构，以便我们可以确定在给定相同输入的情况下不会改变结果输出；3) 你是否对算法或数据结构有明显更好方法的清晰愿景（请注意，对于这一点，你可以在思考中包括不太知名的数据结构和更深奥/复杂/数学的算法，以及重新构造问题的方法，以便暴露出另一种范式，例如下面列出的列表（注意：在提出任何优化之前，建立基线指标（p50/p95/p99 延迟、吞吐量、峰值内存）并捕获 CPU/分配/I/O 配置文件，以识别实际热点）： - N+1 查询/获取模式消除 - 零拷贝 / 缓冲区重用 / 散点-聚集 I/O - 序列化格式成本（解析/编码开销） - 有界队列 + 背压（防止内存膨胀和尾延迟） - 分片 / 条纹锁以减少争用 - 记忆化与缓存失效策略 - 动态编程技术 - 凸优化理论 - 惰性求值 / 延迟计算 - 迭代器/生成器模式以避免物化大型集合 - 流处理/分块处理以适应内存限制的工作 - 预计算和查找表 - 基于索引的查找与线性扫描识别 - 二分查找（在数据和答案空间上） - 双指针和滑动窗口技术 - 前缀和 / 累积聚合 - 拓扑排序和 DAG 感知的依赖图 - 循环检测 - 动态连通性的并查集 - 图遍历（BFS/DFS）与提前终止 - Dijkstra / A* 加权最短路径 - 优先队列 / 堆 - 前缀操作的 Trie - 概率性成员资格的布隆过滤器 - 范围查询的区间/线段树 - 空间索引（k-d 树、四叉树、R 树） - 持久/不可变数据结构 - 写时复制语义 - 对象/连接池 - 缓存驱逐策略选择（LRU/LFU/ARC） - 批量感知算法选择 - 异步 I/O 批处理和合并 - 高争用场景的无锁结构 - 递归并行性的工作窃取 - 内存布局优化（SoA vs AoS，缓存局部性） - 短路和提前终止 - 字符串内部化以处理重复值 - 摊销分析推理 考虑到这些一般指南在适用时： 动态规划适用性检查： - 重叠子问题？→ 使用稳定状态键进行记忆化 - 最优分区/批处理？→ 前缀和 + 区间动态规划 - 依赖图有重复遍历？→ 单遍拓扑动态规划 凸优化检查： - 强行精确分配/调度？→ LP / 最小成本流与确定性平局打破 - 具有显式损失的连续参数拟合？→ 正则化最小二乘法 / 二次规划 - 大的可分解凸目标？→ 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。然后仔细检查每个细节——你确定它有意义吗？它是最优的吗？我们是否可以更改任何内容以使系统对用户更好？我们希望为所有这些提供一个全面和细致的细节集合，包含任务、子任务和依赖结构，并附有详细评论，以便整个内容完全自包含和自文档化（包括相关背景、推理/理由、考虑因素等——任何我们希望我们的“未来自我”知道的关于目标和意图、思考过程以及它如何服务于项目的总体目标的内容）。这些细节应该如此详细，以至于我们不需要回顾原始的 markdown 计划文档。它是否准确反映了所有 markdown 计划文件的内容？如果需要更改，则修订细节或创建新的细节，或关闭无效或不适用的细节。在我们开始实施这些内容之前，在“计划空间”中操作要容易得多且更快！不要过于简化事情！不要失去任何特性或功能！此外，确保作为这些细节的一部分，我们包括全面的单元测试和端到端测试脚本，并附有良好的详细日志，以便我们可以确保在实施后所有内容都正常工作。记住只使用 `bd` 工具来创建和修改细节，并将依赖项添加到细节中。” 然后进行几轮： “仔细检查每个细节——你确定它有意义吗？它是最优的吗？我们是否可以更改任何内容以使系统对用户更好？如果是，请修订细节。在我们开始实施这些内容之前，在“计划空间”中操作要容易得多且更快！不要过于简化事情！不要失去任何特性或功能！此外，确保作为细节的一部分，我们包括全面的单元测试和端到端测试脚本，并附有良好的详细日志，以便我们可以确保在实施后所有内容都正常工作。使用 ultrathink。” 然后让团队全力实施所有内容。然后准备好进行第二轮。