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. ...