Điều gì tạo nên một tài liệu kế hoạch markdown tốt cho một dự án phát triển phần mềm? Sự khác biệt giữa một kế hoạch tốt và một kế hoạch tuyệt vời là gì? Tôi luôn nói đi nói lại về việc tôi dành hơn 85% thời gian và năng lượng của mình cho các giai đoạn lập kế hoạch. Vậy điều đó thực sự bao gồm những gì? Thật khó để giải thích một cách trừu tượng; bạn cần một ví dụ cụ thể để thực sự minh họa những sắc thái. Vì vậy, tôi nghĩ tôi sẽ chia sẻ một ví dụ tốt từ hôm nay. Điều này cũng giải quyết một câu hỏi gần đây mà tôi đã nhận được về cách tiếp cận của tôi. Mọi người dường như có ấn tượng rằng bạn phải làm mọi thứ trong dự án của mình trong một lần. Và trong cách tiếp cận của tôi, điều đó đúng, nhưng chỉ cho phiên bản 1! Nếu bạn quyết định muốn thêm các tính năng mới hoặc thay đổi cách mọi thứ hoạt động, bạn có thể làm điều đó một cách rõ ràng khi bạn có một phiên bản v1 hoạt động. Và cách bạn làm điều đó là giống như cách bạn tạo ra v1, bằng cách tạo một kế hoạch markdown siêu chi tiết trước và sau đó biến nó thành các bead. Vì vậy, tôi sẽ đưa ra một ví dụ từ Cass, chương trình Tìm kiếm Phiên của Đại lý Lập trình của tôi, là một chương trình Rust khá phức tạp tự động phát hiện, phân tích, lưu trữ và lập chỉ mục tất cả các nhật ký phiên trước đó của bạn từ hầu hết mọi đại lý lập trình có mặt. Nó cung cấp khả năng "tìm kiếm khi bạn gõ" dưới 50ms trên tất cả các nhật ký đó và có nhiều tính năng khác thú vị. Tôi đã quyết định rằng tôi muốn thêm một tính năng cho Cass tương tự như một tính năng mà tôi đã có trong MCP Agent Mail và trong beads_viewer (bv): khả năng xuất thiết lập của bạn dưới dạng một trang web tĩnh có thể được phục vụ bằng GitHub Pages. Bạn có thể xem một ví dụ cho bv cho dự án này, đó là kết quả cuối cùng của quá trình lập kế hoạch mà tôi sẽ mô tả trong bài viết này: Chức năng này giúp việc tạo và triển khai trang web xuất ra rất nhanh và dễ dàng bằng cách sử dụng tiện ích gh. Trang web thường bao gồm một tệp sqlite và một đống typescript và wasm chạy hoàn toàn trong trình duyệt, nhưng với hiệu suất rất tốt và nhiều tính năng và kiểu dáng đẹp, mà bạn có thể quan sát trong ví dụ vừa nêu. Bây giờ, việc chia sẻ các tin nhắn MCP Agent Mail hoặc một đống beads là một chuyện, nhưng chia sẻ một đống nhật ký phiên của đại lý lập trình là một chuyện rất khác; những thứ này thường đầy thông tin nhạy cảm, khóa API, lời chửi rủa (ít nhất là của tôi!), và các tài liệu khác mà bạn chắc chắn không muốn công khai ra thế giới. Nhưng GitHub Pages, dù đẹp đến đâu, chỉ hoạt động cho các repo công khai (btw, các công cụ của tôi cũng hỗ trợ Cloudflare pages, nhưng GH Pages thì tốt hơn và dễ hơn cho trường hợp sử dụng này). Vậy làm thế nào để xử lý những vấn đề này? Câu trả lời là mã hóa: người dùng trước tiên chọn các đại lý lập trình nào để bao gồm, các thư mục dự án, khoảng thời gian, v.v. và một gói được tạo ra (lưu ý rằng gói này ở định dạng chuẩn mà Cass chuyển đổi tất cả các tin nhắn của đại lý lập trình từ các định dạng gốc của chúng) và sau đó người dùng cung cấp một mật khẩu để sử dụng cho việc mã hóa gói đó. Vì vậy, ý tưởng là mặc dù repo và trang web là công khai, mọi người trừ bạn và những người bạn cho biết mật khẩu sẽ chỉ thấy một trường mật khẩu và sẽ không thể đọc bất kỳ tin nhắn nào. Khi mật khẩu được nhập, nó sẽ mở khóa một giao diện người dùng đẹp, phản hồi cho phép bạn dễ dàng tìm kiếm qua các tin nhắn gần như nhanh chóng và hiệu quả như Cass. Và nếu bạn thực sự không có gì để giấu, bạn có thể bỏ qua mật khẩu và làm cho mọi thứ thực sự công khai. Dù sao, đây là một tính năng mới siêu phức tạp để thêm vào vì nhiều lý do. Chỉ riêng wizard xuất khẩu đã cực kỳ phức tạp. Nhưng các yêu cầu bổ sung xung quanh mã hóa và bảo mật khiến điều này khó thực hiện đúng. Dù sao, tôi đã yêu cầu Claude Code với Opus 4.5 trước tiên nghiên cứu tất cả mã liên quan từ dự án bv của tôi để triển khai tính năng này, và sau đó giải thích cách mà tính năng tương ứng trong Cass sẽ phải khác biệt. Nó sau đó đã tạo cho tôi một bản kế hoạch ban đầu. Tôi đã yêu cầu CC kiểm tra lại mã bv một lần nữa để có thêm thông tin và hiểu biết về cách tính năng được triển khai trong bv và sau đó sử dụng những hiểu biết đó để mở rộng và cải thiện tài liệu kế hoạch tại chỗ. Cuối cùng, tôi đã chuyển kế hoạch sang ChatGPT Pro trong trình duyệt với GPT 5.2 với Lý luận Mở rộng cùng với phần mở đầu của lời nhắc này: "Hãy 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 cao 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:" Sau đó, tôi đã dán các đầu ra vào Claude Code như thế này: OK, bây giờ hãy tích hợp những sửa đổi này vào kế hoạch markdown tại chỗ; hãy sử dụng ultrathink và cẩn thận. Cuối cùng, bạn có thể cho tôi biết những thay đổi nào bạn hoàn toàn đồng ý, những thay đổi nào bạn đồng ý một phần, và những thay đổi nào bạn không đồng ý: ```[Văn bản đã dán #1 +995 dòng]``` Sau đó, tôi đã lặp lại quy trình này thêm 2 lần nữa. Đây không phải là một quá trình nhanh chóng: lần xem xét cuối cùng, mà bạn có thể thấy một ảnh chụp màn hình bên dưới, đã mất 27 phút để hoàn thành: Bạn có thể thấy kế hoạch markdown cuối cùng dài ~3,500 dòng ở đây: Nhưng điều thú vị hơn là xem các sửa đổi trong GitHub, nơi bạn có thể thấy những cải tiến lớn được thực hiện từ v2 đến v3, và cách mà những cải tiến thực sự tiếp tục cho đến cuối: Điều này đã mất tổng cộng khoảng 3 giờ. Tôi nghi ngờ đây là lý do tại sao hầu hết mọi người dường như không muốn thực hiện mức độ lập kế hoạch này. Nó cảm giác như bạn không làm được nhiều vì không có mã nào được viết, nhưng nếu bạn làm đúng và sau đó khởi động đủ đại lý trong đàn của bạn với Agent Mail, Beads, và bv, thì mã sẽ được viết một cách nhanh chóng đến mức nó bù đắp cho phần chậm này. Và điều gì còn hơn nữa, mã sẽ thực sự tốt. Quay lại câu chuyện, tôi đã sẵn sàng để biến kế hoạch thành các bead. Tôi đã giải thích quy trình đó trong một bài viết gần đây khác, nhưng bản chất của nó là sử dụng lời nhắc này với Claude Code: "OK vì vậy bây giờ hãy đọc TẤT CẢ của PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md; hãy lấy TẤT CẢ những điều đó và mở rộng nó và sử dụng nó để tạo ra một bộ 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ả bối cảnh liên quan, lý do/biện minh, cân nhắc, v.v.-- bất cứ điều gì chúng ta muốn "tương lai của chúng ta" 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 ta không bao giờ cần tham khảo lại tài liệu kế hoạch markdown gốc. 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. Sử dụng ultrathink." Sau đó, tôi chỉ thực hiện vòng lặp sau vòng lặp của lời nhắc theo dõi này trong Claude Code: "Đọc lại AGENTS dot md để nó vẫn tươi trong tâm trí bạn. Sau đó đọc TẤT CẢ của PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md . Sử dụng ultrathink. Kiểm tra từng bead 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 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 ta bắt đầu triển khai những điều này! ĐỪNG ĐƠN GIẢN HÓA QUÁ! ĐỪNG MẤT BẤT KỲ TÍNH NĂNG HOẶC CHỨC NĂNG NÀO! Cũng hãy chắc chắn 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ú 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 triển khai. Điều quan trọng là TẤT CẢ mọi thứ từ kế hoạch markdown phải được nhúng vào các bead để chúng tôi không bao giờ cần tham khảo lại kế hoạch markdown và chúng tôi không mất bất kỳ bối cảnh, ý tưởng hoặc hiểu biết quan trọng nào về các tính năng mới đã lên kế hoạch và lý do tại sao chúng tôi đang thực hiện chúng." Sau khoảng 8 hoặc 9 vòng, cuối cùng nó đạt đến trạng thái ổn định. Sau đó, tôi đã yêu cầu Codex với GPT 5.2 nỗ lực lý luận cao thực hiện một vòng cuối cùng sử dụng cùng một lời nhắc. Kết quả cuối cùng có thể được thấy tại liên kết được chia sẻ ở trên. Và đó, bạn bè, là những gì một kế hoạch tốt trông như thế nào. Và cũng là những gì một bộ bead tốt dựa trên một kế hoạch trông như thế nào. Những bead đó được đánh bóng và chi tiết đến mức bạn có thể cơ học thả một đàn đại lý lớn để thực hiện nó bằng cách sử dụng Agent Mail, Beads, và bv, và nó sẽ ra ngoài gần như hoàn hảo mà không gặp nhiều rắc rối. Tôi quá mệt để bắt đầu làm công việc triển khai đó tối nay, nhưng tôi sẽ làm vào ngày mai và sau đó sẽ chia sẻ tính năng mới, mà tôi nghĩ người dùng Cass sẽ rất thích.

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... 𖤐⁶⁶⁶𓃶