Trước khi bạn tiêu tốn nhiều token với một đàn đại lý lớn cho một dự án mới, câu châm ngôn trong nghề mộc cũ "Đo hai lần, cắt một lần!" đáng được xem xét lại thành "Kiểm tra các hạt của bạn N lần, thực hiện một lần," trong đó N về cơ bản là nhiều như bạn có thể chịu đựng. Tôi đã nhận thấy rằng bạn tiếp tục nhận được nhiều cải tiến hơn, ngay cả khi chúng rất tinh tế, càng nhiều lần bạn chạy điều này liên tiếp với Opus 4.5 (lưu ý rằng lời nhắc sau đây chỉ dành cho việc sử dụng SAU khi bạn đã biến kế hoạch markdown ban đầu của mình thành các hạt bằng cách sử dụng lời nhắc khác mà tôi đã đưa ra gần đây trong bài viết rất dài gần đây của tôi về quy trình làm việc của tôi): "Đọc lại AGENTS dot md để nó vẫn còn tươi mới trong tâm trí bạn. Kiểm tra từng hạt một cách siêu 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 không? Nếu có, hãy sửa đổi các hạt. 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 ta 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 những hạt này, chúng ta 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 ta 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 hạt và thêm các phụ thuộc vào các hạt. Sử dụng ultrathink." Tôi đã từng chỉ chạy điều đó một hoặc hai lần trước khi bắt đầu thực hiện, nhưng gần đây tôi đã thử nghiệm với việc chạy nó 6+ lần, và nó liên tục tạo ra những cải tiến hữu ích. Nếu nó bắt đầu phẳng trong việc cải tiến từng phần cho các hạt, bạn có thể thử bắt đầu một phiên CC hoàn toàn mới, bắt đầu với: "Đầu tiên đọc TẤT CẢ các tệp AGENTS dot md và README dot md một cách siêu cẩn thận và hiểu TẤT CẢ cả hai! Sau đó sử dụng chế độ đại lý điều tra mã của bạn để hiểu hoàn toàn mã, kiến trúc kỹ thuật và mục đích của dự án. Sử dụng ultrathink." Và sau đó theo dõi với cùng một lời nhắc như đã hiển thị ở trên, nhưng được mở đầu bằng: "Chúng tôi gần đây đã biến một tệp kế hoạch markdown thành một đống hạt mới. Tôi muốn bạn xem xét và phân tích chúng một cách rất cẩn thận bằng cách sử dụng `bd` và `bv`." Càng phức tạp và tinh vi kế hoạch markdown của bạn, kỹ thuật này càng có liên quan. Nếu bạn có một kế hoạch nhỏ, tầm thường và một dự án rất đơn giản, điều này rõ ràng là thừa thãi. Nhưng trong trường hợp đó, bạn sẽ có thể thấy ít sự thay đổi/cải tiến từng phần với mỗi vòng, vì vậy nó sẽ khá rõ ràng khi nào là thời điểm dừng lại. Chỉ cần nhớ: token lập kế hoạch ít hơn và rẻ hơn nhiều so với token thực hiện. Ngay cả một kế hoạch markdown rất lớn và phức tạp cũng ngắn hơn một vài tệp mã có nội dung, chưa nói đến một dự án hoàn chỉnh. Và các mô hình thông minh hơn nhiều khi lý luận về một kế hoạch rất chi tiết và đầy đủ nhưng vẫn đủ nhỏ để dễ dàng vừa vặn trong cửa sổ ngữ cảnh của chúng (đây thực sự là cái nhìn sâu sắc chính đằng sau sự tập trung ám ảnh của tôi vào việc lập kế hoạch và lý do tôi đã dành hơn 80% thời gian của mình cho phần đó). Và nếu bạn dựa vào GPT Pro với Lý luận Mở rộng trong ứng dụng web cho việc lập kế hoạch ban đầu như tôi mạnh mẽ khuyến nghị (tức là, để tạo và cải thiện kế hoạch markdown của bạn mà bạn cuối cùng biến thành các hạt), bạn về cơ bản nhận được những điều đó trên cơ sở ăn uống không giới hạn với một kế hoạch Pro, vì vậy hãy tận dụng tối đa điều đó! Không mô hình nào có thể chạm tới Pro trên web khi nó xử lý đầu vào dễ dàng vừa vặn trong cửa sổ ngữ cảnh của nó. Nó thực sự là độc nhất. Bây giờ, bạn vẫn có thể nhận được nhiều lợi ích bổ sung bằng cách kết hợp những ý tưởng thông minh từ Gemini3 trong ứng dụng web với Deep Think được kích hoạt, hoặc từ Grok4 Heavy, hoặc Opus 4.5 trong ứng dụng web, nhưng bạn vẫn muốn sử dụng GPT Pro trên web như là trọng tài cuối cùng về những gì nên lấy từ mô hình nào và cách tốt nhất để tích hợp nó. Và vì bài viết này vẫn có thể dài hơn nữa, tôi sẽ để lại cho bạn lời nhắc của tôi để tích hợp những kế hoạch cạnh tranh đó thành một kế hoạch markdown "tốt nhất của tất cả các thế giới" duy nhất: "Tôi đã yêu cầu 3 LLM cạnh tranh làm cùng một việc và họ đã đưa ra những kế hoạch khá khác nhau mà bạn có thể đọc bên dưới. Tôi muốn bạn PHẢI phân tích rất cẩn thận các kế hoạch của họ với một tâm trí cởi mở và trung thực về mặt trí tuệ về những gì họ đã làm tốt hơn kế hoạch của bạn. Sau đó, tôi muốn bạn đưa ra những sửa đổi tốt nhất có thể cho kế hoạch của bạn (bạn chỉ cần cập nhật tài liệu hiện tại của mình cho kế hoạch ban đầu với các sửa đổi) mà khéo léo và tài tình kết hợp "tốt nhất của tất cả các thế giới" để tạo ra một phiên bản lai thực sự, tối ưu, vượt trội của kế hoạch đạt được các mục tiêu đã nêu của chúng ta và sẽ hoạt động tốt nhất trong thực tế để giải quyết các vấn đề mà chúng ta đang đối mặt và các mục tiêu tổng thể của chúng ta trong khi đảm bảo sự thành công cực kỳ của doanh nghiệp càng tốt càng tốt; bạn nên cung cấp cho tôi một loạt các thay đổi theo kiểu git-diff cho kế hoạch ban đầu của bạn để biến nó thành kế hoạch mới, được cải thiện, dài hơn và chi tiết hơn tích hợp những điều tốt nhất từ tất cả các kế hoạch với mọi ý tưởng tốt được bao gồm (bạn không cần phải đề cập đến ý tưởng nào đến từ mô hình nào trong kế hoạch đã sửa đổi cuối cùng):" (Chúa ơi, một lời nhắc nữa cho vui; tôi sử dụng cái này để cải thiện một kế hoạch markdown hiện có một cách lặp đi lặp lại): "Xem xét cẩn thận toàn bộ kế hoạch này cho tôi và đưa ra những sửa đổi tốt nhất của bạn về kiến trúc tốt hơn, các tính năng mới, các tính năng đã thay đổi, v.v. để làm cho nó tốt hơn, đáng tin cậy/hơn, hiệu suất hơn, hấp dẫn/hữu ích hơn, v.v. Đối với mỗi thay đổi đề xuất, hãy cho tôi phân tích chi tiết và lý do/biện minh cho việc tại sao nó sẽ làm cho dự án tốt hơn cùng với sự thay đổi theo kiểu git-diff so với kế hoạch gốc được hiển thị bên dưới:"

Mức độ tham gia satan ở đây... 𖤐⁶⁶⁶𓃶

<giọng Mario> "Bây giờ thì đó là một phiên thật tuyệt!" ~20 triệu token đầu vào. ~3.5 triệu token đầu ra. ~2.6 triệu token lý luận. ~1.15 TỶ lần đọc token đã lưu.