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