Sự chuyển dịch từ Chat sang Backlog
Ba tháng trước, việc quản lý tác vụ của tôi chỉ gói gọn trong một cửa sổ chat. Nếu tôi đóng tab đó lại, kế hoạch cũng tan biến.
Giờ đây, nó là một backlog trên Postgres. Ba tác nhân AI khác nhau—Claude Code, Codex và Grok—lấy công việc từ đó. Chúng đóng dấu thông tin người thực hiện (attribution) và đóng tác vụ dựa trên lịch sử git.
Tôi không hề có ý định xây dựng một hệ thống quản lý dự án. Tôi chỉ đơn giản là liên tục vấp phải những rào cản. Mỗi khi tôi vá xong một vấn đề, một vấn đề mới lại xuất hiện.
Khối lượng công việc của tôi rất lớn. Tôi vận hành một nền tảng dữ liệu cá nhân tên là Nexus. Tôi quản lý khoảng 100 repository. Trong một giai đoạn, tôi đã xuất bản 557.000 dòng code chỉ trong 35 ngày. Khối lượng đó đã phá vỡ mọi phương pháp lập kế hoạch mà tôi từng thử.
Dưới đây là cách hệ thống của tôi tiến hóa:
Phase 1: Conversational Planning Kế hoạch nằm trong lịch sử chat. Tôi thường suy nghĩ thành tiếng, nảy ra một ý tưởng hay và bắt đầu xây dựng.
- Vấn đề: Các kế hoạch tan biến khi cuộc hội thoại kết thúc. Bạn không thể ưu tiên chúng hoặc bàn giao cho bất kỳ ai khác.
Phase 2: Per-Repo TODO Files Tôi bắt đầu sử dụng các tệp TODO.md trong mọi repository. Tôi ngừng sử dụng các danh sách kiểm tra (checklist) đơn giản. Thay vào đó, tôi viết các đặc tả (specs) nhỏ. Mỗi mục bao gồm:
- Trạng thái và ngày tháng.
- Một tác nhân kích hoạt (tại sao việc này trở nên khẩn cấp).
- Các bước đã quyết định trước (kế hoạch).
- Các rủi ro đã biết.
- Vấn đề: Với 100 repo, tôi không có cái nhìn tổng thể. Tôi không thể thấy tất cả những gì mình cần làm ở cùng một nơi.
Phase 3: The Operator Backlog (OB) Tôi chuyển các tác vụ vào một cơ sở dữ liệu Postgres. Điều này tạo ra một hàng đợi toàn cục. Tôi đã thêm một cổng phê duyệt. Một tác vụ chỉ thực sự tồn tại sau khi tôi xem xét nó. Điều này ngăn chặn AI đưa những thứ rác rưởi vào backlog. Tôi sử dụng các luồng trạng thái (status lanes):
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- Vấn đề: Tôi trở thành nút thắt cổ chai. Tôi không thể giải quyết các luồng công việc đủ nhanh.
Phase 4: Multi-Agent Execution Backlog hiện là một hàng đợi dùng chung cho nhiều tác nhân AI.
- Chúng sử dụng cơ chế thuê (leases) để không làm việc trên cùng một tác vụ.
- Chúng sử dụng attribution để tôi biết ai đã làm gì.
- Chúng có thể bàn giao công việc. Một tác nhân có thể thấy một tác vụ là bất khả thi và tạo ra một điều kiện tiên quyết (prerequisite). Một tác nhân thứ hai sau đó có thể tiếp nhận điều kiện tiên quyết đó và hoàn thành tác vụ ban đầu.
Bài học rất đơn giản: Bạn không cần đến Giai đoạn 4 để thành công.
Nếu bạn muốn học hỏi một điều, hãy học theo định dạng của Giai đoạn 2. Hãy viết các tác vụ của bạn kèm theo trạng thái, tác nhân kích hoạt, các bước đã quyết định trước và các rủi ro. Nó không tốn kém gì nhưng sẽ thay đổi mọi thứ.
Quy tắc quan trọng nhất là đây: Luôn lập kế hoạch dựa trên sự thật. Đừng bao giờ lập kế hoạch dựa trên một phỏng đoán hay một bản tóm tắt. Một kế hoạch hoàn hảo được xây dựng trên dữ liệu lỗi thời sẽ thất bại nhanh chóng chẳng kém gì việc không có kế hoạch nào cả.
Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi