Я включил миниатюрную версию этого запроса здесь, потому что серия "Мои любимые запросы" должна быть компактной, лакомой, самодостаточной. Но сегодня я превратил это в поистине безумную систему. Это не имеет значения, если вы создаете другую программу CRUD на React или список дел, но если вы делаете что-то довольно сложное на Rust или Golang, или что-то, связанное со сложными данными, этот подход почти пугает тем, что он может сделать. Это процесс из 2 этапов. Вот Этап 1: --- Сначала внимательно прочитайте все файлы AGENTS dot md и README dot md и полностью поймите их! Затем используйте режим агента для расследования кода, чтобы полностью понять код, техническую архитектуру и цель проекта. Затем, как только вы выполните крайне тщательную и скрупулезную работу и глубоко поймете всю существующую систему и то, что она делает, ее цель, и как она реализована, и как все части соединяются друг с другом, мне нужно, чтобы вы гиперинтенсивно исследовали, изучали и размышляли над этими вопросами, касающимися этого проекта: Есть ли другие грубые неэффективности в основной системе? Места в кодовой базе, где 1) изменения действительно повлияют на общую задержку/отзывчивость и пропускную способность; 2) так, что наши изменения будут доказуемо изоморфными с точки зрения функциональности, чтобы мы точно знали, что это не изменит результирующие выходные данные при тех же входных данных; 3) где у вас есть четкое видение явно лучшего подхода с точки зрения алгоритмов или структур данных (обратите внимание, что для этого вы можете включить в свои размышления менее известные структуры данных и более эзотерические/софистицированные/математические алгоритмы, а также способы переформулировать проблему(ы), чтобы другой парадигма была раскрыта, как показано в списке ниже (Примечание: перед предложением любой оптимизации установите базовые метрики (p50/p95/p99 задержка, пропускная способность, пиковая память) и захватите профили CPU/выделения/I/O, чтобы выявить фактические горячие точки): - Устранение паттерна N+1 запросов/выборок - нулевое копирование / повторное использование буфера / разрозненный ввод-вывод - затраты на формат сериализации (накладные расходы на разбор/кодирование) - ограниченные очереди + обратное давление (предотвращение увеличения памяти и задержки в хвосте) - шардирование / полосатые блокировки для уменьшения конкуренции - мемоизация с стратегиями недействительности кэша - техники динамического программирования - теория выпуклой оптимизации - ленивое вычисление / отложенные вычисления - паттерны итераторов/генераторов, чтобы избежать материализации больших коллекций - потоковая/пакетная обработка для работы с ограниченной памятью - предварительное вычисление и таблицы поиска - индексированный поиск против линейного сканирования - бинарный поиск (по данным и по пространству ответов) - техники двух указателей и скользящего окна - префиксные суммы / кумулятивные агрегаты - топологическая сортировка и осведомленность о DAG для графиков зависимостей - обнаружение циклов - объединение-найти для динамической связности - обход графа (BFS/DFS) с ранним завершением - алгоритмы Дейкстры / A* для взвешенных кратчайших путей - приоритетные очереди / кучи - префиксы для операций - фильтры Блума для вероятностного членства - деревья интервалов/сегментов для диапазонных запросов - пространственная индексация (k-d деревья, квадродеревья, R-деревья) - постоянные/неизменяемые структуры данных - семантика копирования при записи - пул объектов/соединений - выбор политики вытеснения кэша (LRU/LFU/ARC) - выбор алгоритма с учетом пакетирования - асинхронное пакетирование ввода-вывода и объединение - структуры без блокировок для сценариев с высокой конкуренцией - кража работы для рекурсивного параллелизма - оптимизация компоновки памяти (SoA против AoS, локальность кэша) - короткое замыкание и раннее завершение - интернирование строк для повторяющихся значений - рассуждения о амортизированном анализе taking into consideration these general guides where applicable: ПРОВЕРКИ ПРИМЕНИМОСТИ DP: - Перекрывающиеся подзадачи? → мемоизировать с ключом стабильного состояния - Оптимальная разбивка/пакетирование? → префиксные суммы + интервал DP - Граф зависимостей с повторным обходом? → однопроходный топологический DP ПРОВЕРКИ ВЫПУКЛОЙ ОПТИМИЗАЦИИ: - Брутфорсинг точного распределения/расписания? → LP / минимальная стоимость потока с детерминированным разрешением ничьей - Непрерывная подгонка параметров с явной потерей? → регуляризованные наименьшие квадраты / QP - Большая разлагаемая выпуклая цель? → ADMM / проксимальные методы Также обратите внимание, что если есть хорошо написанные сторонние библиотеки, о которых вы знаете, что они будут хорошо работать, мы можем включить их в проект). ТРЕБОВАНИЯ К МЕТОДОЛОГИИ: A) Сначала базовая линия: Запустите тестовый набор и представительную нагрузку; запишите p50/p95/p99 задержку, пропускную способность и пиковую память с точными командами. B) Профилирование перед предложением: Захватите профили CPU + выделения + I/O; определите 3–5 горячих точек по % времени перед предложением изменений. C) Оракул эквивалентности: Определите явные золотые выходные данные + инварианты. Для больших пространств входных данных добавьте тесты на основе свойств или метаморфные тесты. D) Доказательство изоморфизма для каждого изменения: Каждое предложенное изменение должно включать краткий эскиз доказательства, объясняющий, почему выходные данные не могут измениться (включая порядок, разрешение ничьей, поведение с плавающей запятой и семена RNG). 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 dot md, чтобы это все еще было свежо в вашей памяти. Теперь прочитайте ВСЕ PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Затем проверьте каждую бусину очень внимательно-- вы уверены, что это имеет смысл? Это оптимально? Можем ли мы что-то изменить, чтобы система работала лучше для пользователей? Мы хотим получить комплексный и детализированный набор бусин для всего этого с задачами, подзадачами и структурой зависимостей, с подробными комментариями, чтобы все это было полностью самодостаточным и самодокументируемым (включая соответствующий фон, обоснование/оправдание, соображения и т. д.-- все, что мы хотели бы, чтобы наш "будущий я" знал о целях и намерениях и процессе мышления и как это служит общим целям проекта). Бусины должны быть настолько детализированными, что нам никогда не нужно будет обращаться к оригинальному документу плана в формате markdown. Отражает ли это точно ВСЕ содержимое файла плана в формате markdown комплексным образом? Если изменения оправданы, то пересмотрите бусины или создайте новые или закройте недействительные или неприменимые. Работать в "плановом пространстве" гораздо легче и быстрее, прежде чем мы начнем реализовывать эти вещи! НЕ УПРОЩАЙТЕ ВЕЩИ! НЕ УТЕРЯЙТЕ НИКАКИЕ ФУНКЦИИ ИЛИ ФУНКЦИОНАЛЬНОСТЬ! Также убедитесь, что в рамках этих бусин мы включаем комплексные модульные тесты и e2e тестовые скрипты с отличным, детализированным логированием, чтобы мы могли быть уверены, что все работает идеально после реализации. Помните, что нужно использовать только инструмент `bd` для создания и изменения бусин и добавления зависимостей к бусинам." Затем несколько раундов: "Проверьте каждую бусину очень внимательно-- вы уверены, что это имеет смысл? Это оптимально? Можем ли мы что-то изменить, чтобы система работала лучше для пользователей? Если да, пересмотрите бусины. Работать в "плановом пространстве" гораздо легче и быстрее, прежде чем мы начнем реализовывать эти вещи! НЕ УПРОЩАЙТЕ ВЕЩИ! НЕ УТЕРЯЙТЕ НИКАКИЕ ФУНКЦИИ ИЛИ ФУНКЦИОНАЛЬНОСТЬ! Также убедитесь, что в рамках бусин мы включаем комплексные модульные тесты и e2e тестовые скрипты с отличным, детализированным логированием, чтобы мы могли быть уверены, что все работает идеально после реализации. Используйте ultrathink." Затем дайте роям свободу, чтобы реализовать все это. Затем готовьтесь к ЭТАПУ 2.