Tôi đã bao gồm phiên bản thu nhỏ của lời nhắc này ở đây vì loạt "Những Lời Nhắc Yêu Thích Của Tôi" được thiết kế để ngắn gọn, dễ hiểu và tự chứa. Nhưng hôm nay tôi đã biến điều này thành một hệ thống thực sự điên rồ. Nó không liên quan nếu bạn đang tạo một chương trình CRUD khác trong React hoặc một danh sách TODO, nhưng nếu bạn đang làm điều gì đó khá phức tạp trong Rust hoặc Golang, hoặc điều gì đó liên quan đến dữ liệu phức tạp, cách tiếp cận này gần như đáng sợ về những gì nó có thể làm. Đó là một quy trình 2 vòng. Đây là Vòng 1: --- Đầu tiên hãy đọc TẤT CẢ các tệp AGENTS dot md và README dot md một cách cực kỳ cẩn thận và hiểu TẤT CẢ cả hai! Sau đó, hãy sử dụng chế độ đại lý điều tra mã của bạn để hiểu rõ mã, kiến trúc kỹ thuật và mục đích của dự án. Sau đó, khi bạn đã thực hiện một công việc cực kỳ kỹ lưỡng và tỉ mỉ trong tất cả những điều đó và hiểu sâu sắc toàn bộ hệ thống hiện có và những gì nó làm, mục đích của nó, và cách nó được triển khai và cách tất cả các phần kết nối với nhau, tôi cần bạn điều tra và nghiên cứu một cách cực kỳ kỹ lưỡng và suy ngẫm về những câu hỏi này liên quan đến dự án này: Có bất kỳ sự không hiệu quả nào khác trong hệ thống cốt lõi không? Những nơi trong mã nguồn mà 1) thay đổi thực sự sẽ làm thay đổi đáng kể về độ trễ/đáp ứng và thông lượng; 2) sao cho những thay đổi của chúng tôi sẽ được chứng minh là đồng nhất về mặt chức năng để chúng tôi biết chắc chắn rằng nó sẽ không thay đổi các đầu ra kết quả khi có cùng đầu vào; 3) nơi bạn có một tầm nhìn rõ ràng về một cách tiếp cận rõ ràng hơn về mặt thuật toán hoặc cấu trúc dữ liệu (lưu ý rằng đối với điều này, bạn có thể bao gồm trong suy nghĩ của mình các cấu trúc dữ liệu ít được biết đến hơn và các thuật toán phức tạp/tinh vi/toán học cũng như các cách để tái cấu trúc vấn đề để một mô hình khác được lộ ra, chẳng hạn như danh sách được hiển thị bên dưới (Lưu ý: Trước khi đề xuất bất kỳ tối ưu hóa nào, hãy thiết lập các chỉ số cơ bản (độ trễ p50/p95/p99, thông lượng, bộ nhớ tối đa) và ghi lại các hồ sơ CPU/phân bổ/I/O để xác định các điểm nóng thực tế): - Loại bỏ mẫu truy vấn/fetch N+1 - không sao chép / tái sử dụng bộ đệm / I/O phân tán-tập hợp - chi phí định dạng tuần tự (chi phí phân tích/mã hóa) - hàng đợi giới hạn + áp lực ngược (ngăn chặn sự bùng nổ bộ nhớ và độ trễ đuôi) - phân mảnh / khóa sọc để giảm sự tranh chấp - ghi nhớ với các chiến lược vô hiệu hóa bộ nhớ đệm - kỹ thuật lập trình động - lý thuyết tối ưu hóa lồi - đánh giá lười biếng / tính toán hoãn lại - mẫu trình lặp/generator để tránh tạo ra các bộ sưu tập lớn - xử lý luồng/khối cho công việc giới hạn bộ nhớ - tính toán trước và bảng tra cứu - tra cứu dựa trên chỉ mục so với quét tuyến tính - tìm kiếm nhị phân (trên dữ liệu và trên không gian câu trả lời) - kỹ thuật hai con trỏ và cửa sổ trượt - tổng tiền tố / tổng tích lũy - sắp xếp topo và nhận thức DAG cho đồ thị phụ thuộc - phát hiện chu trình - union-find cho kết nối động - duyệt đồ thị (BFS/DFS) với việc dừng sớm - Dijkstra's / A* cho các đường đi ngắn nhất có trọng số - hàng đợi ưu tiên / đống - tries cho các phép toán tiền tố - bộ lọc bloom cho thành viên xác suất - cây khoảng/đoạn cho các truy vấn khoảng - lập chỉ mục không gian (cây k-d, cây quad, cây R) - cấu trúc dữ liệu bền vững/không thay đổi - ngữ nghĩa sao chép-khi-viết - nhóm đối tượng/kết nối - lựa chọn chính sách loại bỏ bộ nhớ đệm (LRU/LFU/ARC) - lựa chọn thuật toán nhận thức theo lô - gộp và đồng bộ hóa I/O không đồng bộ - cấu trúc không khóa cho các tình huống tranh chấp cao - ăn cắp công việc cho tính song song đệ quy - tối ưu hóa bố trí bộ nhớ (SoA so với AoS, tính địa phương của bộ nhớ đệm) - ngắt sớm và dừng sớm - nội bộ chuỗi cho các giá trị lặp lại - lý luận phân tích trung bình taking into consideration these general guides where applicable: KIỂM TRA TÍNH THÍCH HỢP DP: - Các vấn đề con chồng chéo? → ghi nhớ với khóa trạng thái ổn định - Phân chia/tập hợp tối ưu? → tổng tiền tố + DP khoảng - Đồ thị phụ thuộc với việc duyệt lại? → DP topo một lần KIỂM TRA TỐI ƯU HÓA LỒI: - Tìm kiếm phân bổ/lịch trình chính xác? → LP / dòng chảy chi phí tối thiểu với việc phá vỡ quyết định xác định - Khớp tham số liên tục với tổn thất rõ ràng? → bình phương tối thiểu có điều kiện / QP - Mục tiêu lồi lớn có thể phân tách? → ADMM / phương pháp gần nhất Cũng lưu ý rằng nếu có các thư viện bên thứ ba được viết tốt mà bạn biết sẽ hoạt động tốt, chúng tôi có thể bao gồm chúng trong dự án). YÊU CẦU PHƯƠNG PHÁP: A) Cơ bản trước: Chạy bộ thử nghiệm và một khối lượng công việc đại diện; ghi lại độ trễ p50/p95/p99, thông lượng và bộ nhớ tối đa với các lệnh chính xác. B) Phân tích trước khi đề xuất: Ghi lại hồ sơ CPU + phân bổ + I/O; xác định 3–5 điểm nóng hàng đầu theo % thời gian trước khi đề xuất thay đổi. C) Oracle tương đương: Định nghĩa các đầu ra vàng + bất biến rõ ràng. Đối với các không gian đầu vào lớn, thêm các bài kiểm tra dựa trên thuộc tính hoặc biến hình. D) Chứng minh đồng nhất cho mỗi thay đổi: Mỗi sự khác biệt được đề xuất phải bao gồm một phác thảo chứng minh ngắn giải thích tại sao các đầu ra không thể thay đổi (bao gồm thứ tự, phá vỡ quyết định, hành vi số thực và hạt giống RNG). E) Ma trận cơ hội: Xếp hạng các ứng viên theo (Tác động × Sự tự tin) / Nỗ lực trước khi thực hiện; chỉ tập trung vào các mục có khả năng làm thay đổi p95+ hoặc thông lượng một cách có ý nghĩa. F) Sự khác biệt tối thiểu: Một cần điều chỉnh hiệu suất cho mỗi thay đổi. Không có tái cấu trúc không liên quan. Bao gồm hướng dẫn hoàn nguyên nếu có bất kỳ rủi ro nào. G) Rào cản hồi quy: Thêm ngưỡng benchmark hoặc móc theo dõi để ngăn chặn các hồi quy trong tương lai. Sử dụng ultrathink. --- Bạn có thể chạy điều đó một lần trong Claude Code với Opus 4.5 và một lần trong Codex với GPT 5.2 Codex (tôi đã bắt đầu chỉ sử dụng High vì Extra High chỉ quá chậm đối với tôi trừ khi tôi sắp đi ngủ). Sau khi họ hoàn thành, hãy cho họ mỗi cái như 5 vòng nhanh của cái này: "Tuyệt vời. Xem lại mọi thứ một lần nữa để tìm bất kỳ sự bỏ sót, thiếu sót hoặc sai lầm nào, lỗi khái niệm, sai lầm, v.v. Sử dụng ultrathink" Sau đó, hãy để họ lưu các đầu ra như thế này: "OK, lưu tất cả những điều đó dưới dạng PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, lưu tất cả những điều đó dưới dạng PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Sau đó trong Claude Code, làm: "So sánh những gì bạn đã làm với PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md và lấy những yếu tố tốt nhất từ đó và kết hợp chúng vào kế hoạch của bạn để có một kế hoạch tốt nhất của cả hai thế giới bằng cách chỉnh sửa tệp kế hoạch gốc của bạn tại chỗ." Sau đó cái này: Đọc lại AGENTS dot md để nó vẫn tươi mới trong tâm trí bạn. Bây giờ đọc TẤT CẢ của PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Sau đó kiểm tra từng bead một cách cực kỳ cẩn thận-- bạn có chắc nó có ý nghĩa không? Nó có tối ưu không? Chúng ta có thể thay đổi điều gì để làm cho hệ thống hoạt động tốt hơn cho người dùng? Chúng tôi muốn một tập hợp bead toàn diện và chi tiết cho tất cả điều này với các nhiệm vụ, nhiệm vụ con và cấu trúc phụ thuộc được chồng lên nhau, với các bình luận chi tiết để toàn bộ điều này hoàn toàn tự chứa và tự tài liệu (bao gồm cả nền tảng liên quan, lý do/biện minh, cân nhắc, v.v.-- bất cứ điều gì chúng tôi muốn "tương lai của chúng tôi" biết về các mục tiêu và ý định và quy trình suy nghĩ và cách nó phục vụ cho các mục tiêu tổng thể của dự án.). Các bead nên chi tiết đến mức chúng tôi không bao giờ cần tham khảo lại tài liệu kế hoạch markdown gốc. Nó có phản ánh chính xác TẤT CẢ các tệp kế hoạch markdown một cách toàn diện không? Nếu có sự thay đổi cần thiết thì hãy sửa đổi các bead hoặc tạo ra những bead mới hoặc đóng các bead không hợp lệ hoặc không áp dụng. Thật dễ dàng và nhanh chóng hơn để hoạt động trong "không gian kế hoạch" trước khi chúng tôi bắt đầu thực hiện những điều này! KHÔNG ĐƠN GIẢN HÓA MỌI THỨ! KHÔNG ĐƯỢC MẤT BẤT KỲ TÍNH NĂNG HOẶC CHỨC NĂNG NÀO! Ngoài ra, hãy đảm bảo rằng như một phần của các bead này, chúng tôi bao gồm các bài kiểm tra đơn vị toàn diện và các kịch bản kiểm tra e2e với ghi chép chi tiết tuyệt vời để chúng tôi có thể chắc chắn rằng mọi thứ hoạt động hoàn hảo sau khi thực hiện. Hãy nhớ chỉ sử dụng công cụ `bd` để tạo và sửa đổi các bead và để thêm các phụ thuộc vào các bead." Sau đó là một vài vòng: "Kiểm tra từng bead một cách cực kỳ cẩn thận-- bạn có chắc nó có ý nghĩa không? Nó có tối ưu không? Chúng ta có thể thay đổi điều gì để làm cho hệ thống hoạt động tốt hơn cho người dùng? Nếu có, hãy sửa đổi các bead. Thật dễ dàng và nhanh chóng hơn để hoạt động trong "không gian kế hoạch" trước khi chúng tôi bắt đầu thực hiện những điều này! KHÔNG ĐƠN GIẢN HÓA MỌI THỨ! KHÔNG ĐƯỢC MẤT BẤT KỲ TÍNH NĂNG HOẶC CHỨC NĂNG NÀO! Ngoài ra, hãy đảm bảo rằng như một phần của các bead, chúng tôi bao gồm các bài kiểm tra đơn vị toàn diện và các kịch bản kiểm tra e2e với ghi chép chi tiết tuyệt vời để chúng tôi có thể chắc chắn rằng mọi thứ hoạt động hoàn hảo sau khi thực hiện. Sử dụng ultrathink." Sau đó để đàn ong thực hiện tất cả. Sau đó chuẩn bị cho VÒNG 2.