Mẹo sống của Agent Coding Tôi cảm thấy hơi có lỗi khi sử dụng cái này, nhưng kệ thôi. Khi tôi yêu cầu các agent thực hiện một vòng so sánh/sửa đổi lớn, điều này thường xảy ra khi tôi có một kế hoạch markdown lớn và đã nhận được phản hồi chi tiết từ GPT Pro trong ứng dụng web, và sau đó tôi đã cho GPT Pro xem phản hồi từ cùng một prompt đã được hiển thị cho Opus4.5, Gemini3 với DeepThink, và Grok4 Heavy (tất cả đều sử dụng ứng dụng web), ngay cả Codex với GPT 5.2 cao cũng sẽ bỏ lỡ một số thứ trong lần đầu tiên khi nó cố gắng tích hợp tất cả các sửa đổi. Nếu bạn bảo nó tìm "tất cả" các vấn đề, vì nó không biết có bao nhiêu vấn đề nó đã bỏ lỡ, nó có xu hướng chỉ tiếp tục cho đến khi nó tìm thấy rất nhiều vấn đề. Nếu bạn bảo nó tiếp tục cho đến khi nó tìm thấy ít nhất 20 vấn đề, nó thường sẽ quay lại sau khi đã tìm thấy 23 vấn đề/sự không khớp. Điều này tất nhiên giả định rằng có VẤN ĐỀ, nhưng chúng thường luôn có khi các kế hoạch có hơn 5k dòng và các sửa đổi có hơn 2k dòng. Dù sao, giải pháp là nói dối với chúng và cho chúng một con số lớn, và sau đó chúng sẽ tiếp tục làm cho đến khi đã phát hiện ra tất cả: "Làm lại điều này, và thực sự hãy cẩn thận: bạn có thể kiểm tra lại kế hoạch và so sánh nó với tất cả phản hồi mà tôi đã đưa cho bạn không? Tôi chắc chắn rằng bạn đã bỏ lỡ hoặc làm sai ít nhất 80 yếu tố trong phản hồi phức tạp đó"

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.

OK, đây là Vòng 2 của Lời nhắc Tối ưu hóa Siêu thông minh. Bài viết này may mắn có thể ngắn hơn nhiều so với bài viết đã trích dẫn, vì toàn bộ quy trình sau lời nhắc ban đầu là giống hệt như Vòng 1, chỉ cần thay "1" bằng "2" trong các tên tệp. Đây là lời nhắc: --- Đầu tiên hãy đọc TẤT CẢ các tệp md AGENTS và README 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 đó, một 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ễ/tính phản hồi 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 dạng 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 những 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ế): - tối ưu hóa lồi (cải cách mang lại đảm bảo tối ưu toàn cầu) - tối ưu hóa phụ thuộc (tham lam cho phép xấp xỉ hằng số) - tổng quát bán trường (hợp nhất đường đi ngắn nhất, đóng băng truyền, luồng dữ liệu, phân tích) - nhận dạng cấu trúc matroid (tham lam là tối ưu được chứng minh) - đại số tuyến tính trên GF(2) (hệ thống XOR, vấn đề chuyển đổi, sửa lỗi) - giảm xuống 2-SAT (tính hợp lệ cấu hình, đồ thị suy diễn) - giảm xuống min-cost max-flow (phân công, lập lịch, phân bổ tài nguyên) - nhận dạng ghép cặp hai phía (Hungarian, Hopcroft-Karp) - DP như đường đi ngắn nhất trong DAG ngầm định (cho phép DP hàng đợi ưu tiên, tối ưu hóa kiểu Dijkstra) - mẹo bao lồi / cây Li Chao (O(n²) DP → O(n log n)) - tối ưu hóa Knuth / DP chia và chinh phục - giảm không gian Hirschberg (khi có thể áp dụng ngoài căn chỉnh) - FFT/NTT cho tích chập (nhân đa thức, tương quan chuỗi) - lũy thừa ma trận cho các chuỗi hồi quy tuyến tính - biến đổi Möbius / tích chập tập con - cấu trúc dữ liệu bền vững/không thay đổi (phiên bản, hoàn tác, thực thi suy đoán) - tự động hóa hậu tố / mảng hậu tố với LCP - phân rã nặng-nhẹ / phân rã tâm điểm - cây cắt liên kết (kết nối cây động) - hàng đợi/deque đơn điệu cho cực trị cửa sổ trượt - cây đoạn với phân phối lười biếng - cây sóng (xếp hạng/chọn/phân vị) - tìm kiếm hợp nhất với hoàn tác - Count-Min sketch, HyperLogLog (luồng/dưới tuyến tính) - băm nhạy cảm theo vị trí (NN xấp xỉ) - bộ lọc bloom / bộ lọc cuckoo - băm hoàn hảo tối thiểu - thác phân số - thuật toán Mo (phân tách truy vấn ngoại tuyến) - tìm kiếm tham số / tìm kiếm nhị phân trên câu trả lời - tìm kiếm hai chiều / gặp nhau ở giữa - thuật toán ngẫu nhiên với giới hạn kỳ vọng nghiêm ngặt - thuật toán xấp xỉ với đảm bảo có thể chứng minh - ăn cắp công việc cho tính song song đệ quy - cấu trúc dữ liệu không khóa / không chờ - thiết kế thuật toán không phụ thuộc vào bộ nhớ đệm - phân tích tích lũy (để nhận ra khi các thao tác "đắt" thực sự là rẻ) 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ộ kiểm tra 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 dạng 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ân tách, 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 triển khai; 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 tác 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ây giờ, tôi biết bạn đang nghĩ gì... cái quái gì là tất cả những thứ đó? Đó là lý do tại sao nó được gọi là lời nhắc Tối ưu hóa Siêu thông minh, được không? Các mô hình biên giới thông minh đến mức nếu bạn để chúng thiết kế mọi thứ, và thực hiện các phiên bản cơ bản hơn của lời nhắc tối ưu hóa (phiên bản ngắn mà tôi đã đưa ra như Lời nhắc 4 trong chuỗi "Những Lời nhắc Yêu thích của tôi"), họ biết cách thực hiện tất cả các thứ phỏng vấn leetcode tiêu chuẩn và sẽ sử dụng nó. Nhưng còn cấp độ tiếp theo, những thứ của Terry Tao thì sao? Bạn biết tôi đang nói về cái gì, những thứ TỐT. Chà, họ cũng biết điều đó. Và liệu nó có liên quan đến vấn đề của bạn không? Thành thật mà nói, có thể không. Nhưng nếu có, đó là cách bạn mở khóa CHẾ ĐỘ TURBO THỰC SỰ. Luôn chạy Vòng 1 trước Vòng 2, vì nó sẽ liên quan hơn 99% thời gian. Nhưng sau khi bạn tiếp tục thực hiện Vòng 1 vài lần và không có gì thay đổi, bạn có thể tiến tới Vòng 2. Dù sao, chỉ cần đảm bảo sau khi bạn làm tất cả những điều này, tạo kế hoạch cho CC và Codex, để CC kết hợp kế hoạch tốt nhất của cả hai thế giới, kiểm tra nó 5 lần để tìm lỗi, biến kế hoạch markdown cuối cùng thành hạt, tối ưu hóa các hạt một cách lặp đi lặp lại, và cuối cùng thực hiện các hạt với một đàn bot CC và Codex với một đống bài kiểm tra đơn vị và bài kiểm tra tích hợp e2e... khởi động một phiên Codex với GPT 5.2 Extra High và xếp hàng khoảng 20 cái này: "Tôi muốn bạn khám phá một cách ngẫu nhiên các tệp mã trong dự án này, chọn các tệp mã để điều tra sâu và hiểu và theo dõi chức năng và luồng thực thi của chúng qua các tệp mã liên quan mà chúng nhập hoặc mà chúng được nhập bởi. Khi bạn hiểu mục đích của mã trong bối cảnh lớn hơn của các quy trình làm việc, tôi muốn bạn thực hiện một kiểm tra cực kỳ cẩn thận, có phương pháp và phê bình với "đôi mắt tươi mới" để tìm bất kỳ lỗi rõ ràng, vấn đề, lỗi, sự cố, sai lầm ngớ ngẩn, v.v. và sau đó hệ thống và tỉ mỉ và thông minh sửa chữa chúng." -KẾT THÚC-