Я включив мініатюрну версію цього запиту сюди, бо серія «Мої улюблені підказки» має бути компактними, компактними, самодостатніми самородками. Але сьогодні я перетворив це на справді божевільну систему. Це не має значення, якщо ви створюєте ще одну CRUD-програму в React або список завдань, але якщо ви робите щось досить складне в Rust чи Golang, або щось із складними даними, цей підхід майже лякає своїми можливостями. Це процес із двох раундів. Ось перший раунд: --- Спочатку дуже уважно прочитайте ВСІ файли 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, локальність кешу) - коротке замикання та дострокове завершення - інтернування рядків для повторюваних значень - Амортизований аналіз, міркування Враховуючи ці загальні рекомендації, де це застосовно: ПЕРЕВІРКИ ЗАСТОСУВАННЯ DP: - Перекриваючі підпроблеми? → запам'ятовувати за допомогою ключа стабільного стану - Оптимальне розділення/пакетування? → префіксні суми + інтервал DP - Граф залежності з повторюваним обходом? → топологічний однопроходний DP ПЕРЕВІРКИ ОПУКЛОЇ ОПТИМІЗАЦІЇ: - Грубий форсинг точного розподілу/розкладу? → LP / мінімальний витратний потік з детермінованим рівним розривом - Неперервне підгонювання параметрів з явними втратами? → регуляризовані найменші квадрати / QP - Великий розкладаючий опуклий об'єктив? → ADMM / проксимальні методи Також зверніть увагу, що якщо ви знаєте добре написані сторонні бібліотеки, які добре підійдуть, ми можемо включити їх у проєкт). ВИМОГИ ДО МЕТОДОЛОГІЇ: A) Спочатку базовий етап: запустіть тестовий набір і репрезентативне навантаження; Записуйте затримку, пропускну здатність і пікову пам'ять p50/p95/p99 за допомогою точних команд. B) Профіль перед пропозицією: Захоплення CPU + виділення + профілі введення/виведення; Визначте топ-3–5 гарячих точок за відсотками часу перед тим, як пропонувати зміни. C) Оракул еквівалентності: Визначте явні золоті виходи + інваріанти. Для великих вхідних просторів додайте тести на основі властивостей або метаморфічних тестів. D) Доказ ізоморфізму за зміну: Кожен запропонований диференціал повинен містити короткий ескіз доказів, що пояснює, чому вихідні результати не можуть змінюватися (включно з порядком, розв'язкою нічиєї, поведінкою з плаваючою комою та насінням випадковості). E) Матриця можливостей: Ранжуйте кандидатів за (Вплив × впевненість) / Зусилля перед впровадженням; Зосередьтеся лише на предметах, які можуть суттєво переміщати p95+ або пропускну здатність. F) Мінімальні відмінності: один важіль продуктивності на зміну. Жодних непов'язаних рефакторів. Додайте рекомендації щодо відкату, якщо існує ризик. G) Регресійні захисні рамки: Додайте пороги бенчмарків або засіб моніторингу, щоб запобігти майбутнім регресіям. Використовуйте Ultrathink. --- Це можна запустити один раз у Claude Code з Opus 4.5 і один раз у Codex з GPT 5.2 Codex (я почав використовувати лише High, бо Extra High для мене занадто повільний, якщо я не збираюся лягати спати). Після того, як вони закінчать, вдарте кожного по 5 швидких раундів ось такого: "Чудово. Перегляньте все ще раз на предмет очевидних упущень, упущень, концептуальних помилок, помилок тощо. Використовуйте ультраthink» Потім нехай вони зберігають результати ось так: "Добре, залиш усе це як 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. Потім ретельно перевірте кожну намистину — ви впевнені, що це має сенс? Чи це оптимально? Чи можемо ми щось змінити, щоб система працювала краще для користувачів? Ми хочемо комплексний і детальний набір намистин для всього цього з накладеними завданнями, підзавданнями та структурою залежностей, а також детальними коментарями, щоб усе було повністю самодостатнім і самодокументуваним (включаючи релевантний бекграунд, міркування/обґрунтування, міркування тощо — все, що ми хотіли б, щоб наше «майбутнє я» знало про цілі, наміри, процес мислення і те, як це служить загальним цілям проєкту). Намистини мають бути настільки деталізованими, щоб нам ніколи не довелося звертатися до оригінального документа плану розмітки. Чи точно він відображає ВЕСЬ файл плану знижки у повному вигляді? Якщо потрібні зміни, тоді перегляньте намистини або створіть нові, або закрийте недійсні чи непридатні. Набагато простіше і швидше працювати у «плановому просторі» до того, як ми почнемо впроваджувати ці речі! НЕ СПРОЩУЙТЕ ВСЕ! НЕ ВТРАЧАЙТЕ ЖОДНИХ ФУНКЦІЙ ЧИ ФУНКЦІОНАЛЬНОСТІ! Також переконайтеся, що до цих бісерів ми додаємо комплексні юніт-тести та скрипти e2e з чудовим і детальним логуванням, щоб бути впевненими, що все працює ідеально після впровадження. Пам'ятайте, що використовуйте ЛИШЕ інструмент 'bd' для створення та модифікації намистин і додавання залежностей до намистин.» Потім кілька раундів: "Перевір кожну намистину дуже уважно — ти впевнений, що це має сенс? Чи це оптимально? Чи можемо ми щось змінити, щоб система працювала краще для користувачів? Якщо так, оновіть намистини. Набагато простіше і швидше працювати у «плановому просторі» до того, як ми почнемо впроваджувати ці речі! НЕ СПРОЩУЙТЕ ВСЕ! НЕ ВТРАЧАЙТЕ ЖОДНИХ ФУНКЦІЙ ЧИ ФУНКЦІОНАЛЬНОСТІ! Також переконайтеся, що в бісери ми включаємо комплексні юніт-тести та скрипти e2e з чудовим і детальним логуванням, щоб бути впевненими, що все працює ідеально після впровадження. Використовуй Ultrathink.» Потім відпустіть рій, щоб усе це реалізувалося. Тоді готуйтеся до РАУНДУ 2.