Cấu trúc cộng tác tôi tạo ra để làm các dự án dài hạn khi phải chuyển qua lại giữa nhiều mô hình AI

Trong cộng tác với AI, bộ nhớ không nên nằm trong chat mà phải nằm trong repository

Trong vài tháng gần đây, tôi thường xuyên phát triển khi luân phiên sử dụng nhiều mô hình AI như dòng GPT-5, Claude, Copilot, Gemini. Trước đây chỉ cần dùng một công cụ là đủ, nhưng giờ đây việc chọn mô hình phù hợp hơn tùy theo loại công việc đã trở thành một xu hướng tự nhiên.

Ví dụ, thiết kế cấu trúc thì các mô hình lớn như GPT-5.4 ổn định hơn; viết code thì đôi khi dòng Claude Sonnet / Opus chính xác hơn; còn với thiết kế frontend hoặc khám phá ý tưởng thì dùng các mô hình khác lại có lúc hiệu quả hơn. Hơn nữa, tốc độ cập nhật mô hình rất nhanh nên thay vì cố định vào một công cụ cụ thể, tôi liên tục thay đổi lựa chọn tùy theo tình huống.

Vấn đề bắt đầu từ đây.
Mỗi khi đổi mô hình, mỗi khi đổi session, AI hoàn toàn không nhớ gì về dự án. Kết quả là tôi phải lặp đi lặp lại cùng một phần giải thích. Dự án này là gì, hiện đã tiến tới đâu, những quyết định nào đã được đưa ra, cần giữ cấu trúc nào, điều gì không được làm — những ngữ cảnh cơ bản như vậy cứ phải truyền đạt lại liên tục.

Ban đầu chỉ hơi phiền, nhưng khi quy mô dự án lớn dần thì chi phí này tăng lên rõ rệt. Đặc biệt khi làm việc qua lại giữa nhiều mô hình, tôi có cảm giác thời gian dành để giải thích lại context còn nhiều hơn cả thời gian phát triển thực tế. Và rồi tôi tự nhiên đặt ra câu hỏi này.

"Trong cộng tác với AI, bộ nhớ nên nằm trong chat, hay chính dự án phải mang bộ nhớ đó?"

Vấn đề không thể giải quyết chỉ bằng Prompt Engineering

Người ta nói rất nhiều về Prompt Engineering như một cách để sử dụng AI tốt hơn. Nhưng khi làm dự án dài hạn, có một vấn đề còn quan trọng hơn prompt. Đó chính là vấn đề context không được duy trì.

Prompt là cách tạo ra một yêu cầu tốt cho một lần tương tác, còn dự án là quá trình nhiều công việc nối tiếp nhau. Để dự án vận hành ổn định, ít nhất các thông tin sau phải luôn được duy trì.

• Yêu cầu hiện tại
• Lịch sử các quyết định từ trước đến nay
• Kế hoạch công việc
• Các việc đã hoàn thành
• Lịch sử thay đổi
• Những việc sẽ làm tiếp theo

Nếu những thông tin này không được giữ lại, thì dù mô hình có tốt đến đâu nó vẫn sẽ lặp lại cùng những sai lầm. Vì vậy, thay vì chỉ tập trung vào việc viết prompt tốt hơn, tôi bắt đầu xây dựng một cách quản lý chính context đó. Cách tiếp cận này thường được gọi là Context Engineering, và tôi cũng bắt đầu áp dụng khái niệm này vào cộng tác ở cấp độ dự án sau khi gặp phải vấn đề tương tự.

Không phải chat, mà repository phải mang bộ nhớ

Điều đầu tiên tôi thay đổi là nơi lưu context. Trước đây mọi ngữ cảnh đều nằm trong chat, nhưng chat sẽ biến mất khi session kết thúc. Vì vậy tôi đã tạo ra một cấu trúc lưu context ngay trong thư mục gốc của dự án.

Tôi tạo một thư mục .cowork/ và ghi lại trạng thái dự án tại đó. Ví dụ như requirements, architecture decision record, danh sách task, lịch sử test, lịch sử release, session log.

Khi bắt đầu session, tôi luôn đi theo một luồng: đọc trạng thái hiện tại, lập kế hoạch, phê duyệt, thực thi rồi ghi lại kết quả. Cuộc trò chuyện thì chóng mất, nhưng tài liệu vẫn còn. Vì thế, dù đổi mô hình thì dự án vẫn tiếp tục được.

Quy tắc Plan → Approve → Execute

Một trong những vấn đề tôi gặp thường xuyên nhất khi cộng tác với AI là mô hình tự sửa code ngay lập tức. Việc bỏ qua các quyết định trước đó, phá vỡ cấu trúc, hoặc thay đổi theo hướng khác với điều đã thống nhất cứ lặp đi lặp lại.

Vì vậy tôi đặt ra một quy tắc làm việc. Luôn tuân thủ thứ tự Plan → Approve → Execute. Trước tiên lập kế hoạch, con người kiểm tra, sau đó mới thực thi. Chỉ riêng quy tắc này cũng đã giúp giảm đáng kể lỗi phát sinh trong các dự án dài hạn.

Artifact is Memory

Nguyên tắc quan trọng nhất trong framework này có thể được tóm gọn bằng câu 'Artifact is Memory'. Bộ nhớ không nên nằm trong chat mà phải nằm trong các artifact của dự án.

Chỉ như vậy, dù mô hình thay đổi, session thay đổi, công cụ thay đổi hay IDE thay đổi, trạng thái dự án vẫn có thể được duy trì. Đặc biệt trong môi trường dùng đồng thời nhiều mô hình, nguyên tắc này quan trọng hơn nhiều so với tưởng tượng.

Các artifact ở đây không chỉ có nghĩa là những tài liệu được viết ra ngay từ đầu. Ngay cả trong các cuộc hội thoại qua lại với AI, vẫn liên tục xuất hiện những thông tin thực sự cần được lưu lại cho dự án, như tinh chỉnh yêu cầu, quyết định thiết kế, kế hoạch công việc, kết quả review. Vấn đề là nếu những nội dung đó chỉ nằm trong chat thì chúng rất dễ bị tiêu hao như context dùng một lần.

Vì vậy tôi coi trọng cách tự động phân loại và ghi lại những nội dung có ý nghĩa từ các cuộc trò chuyện với AI, rồi dùng lại chúng như artifact của dự án. Không phải chỉ tích lũy log hội thoại, mà là sắp xếp các nội dung cốt lõi sinh ra từ hội thoại thành những dạng như bản ghi quyết định, tài liệu yêu cầu, kế hoạch công việc, session log để giữ chúng ở trạng thái có thể tái sử dụng.

Làm như vậy, cuộc trò chuyện không còn chỉ là một giao diện tạm thời mà được chuyển thành nguyên liệu công việc giúp tiếp tục đẩy dự án tiến lên. Cuối cùng, điều cần được ghi nhớ không phải là bản thân cuộc trò chuyện, mà là các kết quả có cấu trúc được trích xuất từ cuộc trò chuyện đó.

Các vấn đề phát sinh khi làm việc qua lại giữa nhiều mô hình

Hiện nay gần như không còn trường hợp chỉ dùng một mô hình duy nhất. Vì mỗi mô hình có thế mạnh khác nhau nên tùy theo từng giai đoạn công việc mà sẽ dùng mô hình khác nhau, và các tác vụ như thiết kế, sửa code, review, phân tích ngữ cảnh sẽ được lặp lại qua nhiều session và nhiều mô hình.

Lúc này, nếu context chỉ nằm trong chat, thì mỗi lần đổi mô hình bạn lại phải giải thích lại dự án từ đầu. Vì thế tôi đã xây dựng một cấu trúc đặt context không phải trong chat mà bên trong repository.

Những gì tôi đã làm: cowork-context-framework

Tôi đã hệ thống hóa quá trình này thành một framework. Đây là một cấu trúc giúp lưu context trong dự án, khôi phục session, ghi lại quyết định, theo dõi công việc và tiếp tục làm việc ngay cả khi mô hình thay đổi.

• GitHub: https://github.com/lim8603/cowork-context-framework

Trước đây tôi đã dùng nó ở dạng template và áp dụng vào các dự án thực tế để kiểm chứng ở mức độ nhất định; dựa trên kinh nghiệm đó, tôi đã sắp xếp lại cấu trúc và nâng nó lên thành dạng framework. Tôi nghĩ đây là hình thức tối thiểu cần có cho một cấu trúc cộng tác khi làm dự án dài hạn với AI.

Tôi muốn biết liệu đã có ai thử cách tương tự chưa

• Những ai đã có kinh nghiệm dùng nhiều mô hình AI cùng lúc
• Những ai từng phải lặp đi lặp lại cùng một lời giải thích vì session bị ngắt
• Những ai từng xây dựng cấu trúc như agent / workflow / harness
• Những ai từng quản lý riêng project context

Nếu bạn có trải nghiệm tương tự, tôi rất muốn nghe ý kiến của bạn.