Ngày 25/9/2026, GitHub đăng bài hướng dẫn cách tạo canvas trong GitHub Copilot app. Canvas, còn gọi là canvas extension, là một giao diện do bạn và agent cùng sở hữu và cùng dùng. Nó có thể là bảng kanban, bảng phân loại issue, danh sách kiểm tra phát hành, dashboard, biểu mẫu, thậm chí một bảng tính. Thay vì phải uốn công việc vào bộ màn hình cố định của công cụ, bạn mô tả cách mình làm việc bằng tiếng Anh thường rồi để agent dựng giao diện cho đúng.
Với người làm phần mềm ở Việt Nam, điểm đáng quan tâm là ngưỡng vào nghề rất thấp. Bạn không phải viết code giao diện hay căn chỉnh bố cục bằng tay, chỉ cần mô tả công việc đủ rõ. Những nhóm nhỏ vốn quen sống trong nhiều công cụ rời rạc có thể gom bảng việc, danh sách kiểm tra và vài thao tác lặp lại vào một chỗ, ngay trong phiên làm việc với agent.
Canvas trong GitHub Copilot app là gì
GitHub định nghĩa canvas là một giao diện tùy biến mà bạn và agent chia sẻ. Khác với chat chỉ trả về câu trả lời, canvas là một mặt phẳng sống: agent thao tác trên đó khi làm việc, còn bạn dùng nút, thẻ, bộ lọc và các điều khiển khác để thay đổi. GitHub so sánh nó với một tấm bảng trắng dùng chung đang được cập nhật liên tục.
Vì canvas là hai chiều, trạng thái chung thay đổi ngay khi một bên thao tác. Khi bạn bấm nút, sửa một trường hay kéo một thẻ, agent thấy thay đổi đó mà không cần bước gửi hay đồng bộ riêng. Ngược lại, bạn có thể yêu cầu agent dùng chính các khả năng của canvas để thêm ghi chú phát hành hay chuyển một thẻ, rồi nhìn kết quả hiện lên trong giao diện. Nói cách khác, hai bên cùng lái công việc thay vì ra lệnh rồi ngồi chờ.
Điểm cần phân biệt là canvas không phải một trang quản lý dự án đầy đủ tính năng như các công cụ chuyên dụng. Nó là bề mặt làm việc sinh ra theo đúng quy trình bạn mô tả, nằm ngay trong phiên agent. Vì vậy nó hợp với việc theo dõi và điều phối công việc đang làm hơn là thay thế toàn bộ hệ thống quản lý của công ty.
Ba thứ bắt buộc có trong câu mô tả
Theo hướng dẫn của GitHub, câu mô tả nên phủ đủ ba ý: quy trình mà canvas phục vụ, những gì bạn cần làm được trên giao diện, và những gì agent được phép làm. Thiếu một trong ba, kết quả thường lệch: giao diện đẹp nhưng không dùng được cho công việc thật.
GitHub đưa một ví dụ cụ thể. Bạn gõ lệnh tạo canvas, rồi mô tả một bảng ghi chú phát hành để theo dõi các hạng mục tính năng đã xong trong nhiều phiên làm việc của GitHub Copilot app, kèm điều khiển để duyệt và sắp xếp các mục, đồng thời cho phép agent thêm và cập nhật chúng. Câu mô tả này nêu rõ quy trình, việc của bạn và việc của agent.
Một mẹo nhỏ: hãy viết như đang giao việc cho một đồng nghiệp mới, tập trung vào đầu việc chứ đừng tả màu sắc hay bố cục. Agent cần hiểu luồng công việc hơn là thẩm mỹ. Nếu câu mô tả càng cụ thể về dữ liệu cần nhìn thấy, kết quả lần đầu càng sát nhu cầu và bạn càng ít phải sửa lại.
Các bước tạo một canvas
1. Mở một phiên agent trong GitHub Copilot app
Bạn bắt đầu trong GitHub Copilot app, tại một phiên làm việc với agent. Đây là nơi canvas sẽ được sinh ra và gắn vào công việc hiện tại.
2. Gọi skill /create-canvas và mô tả
Gõ lệnh tạo canvas trong phiên, sau đó mô tả thứ bạn muốn bằng tiếng Anh thường. Không cần viết code hay thiết kế trước. Ba ý ở mục trên là phần thân của câu mô tả, nên viết theo đúng thứ tự đó để agent dễ hiểu.
3. Chờ agent dựng giao diện ở panel phải
Agent dựng giao diện và mở nó ở panel bên phải, không cần bạn tạo tệp hay căn layout. Một câu mô tả biến thành một công cụ dùng được ngay trong phiên đang mở.
4. Tinh chỉnh cho khớp cách làm việc
Bản đầu tiên chỉ là điểm khởi đầu. Bạn có thể yêu cầu agent thêm cột hoặc bộ lọc, kéo danh sách pull request đang mở vào, hay biến cả canvas thành danh sách kiểm tra cho ngày làm việc. Agent sẽ sửa canvas theo yêu cầu. GitHub lưu ý không có menu bố cục cố định, nếu mô tả được quy trình thì nhiều khả năng dựng được thành canvas.
5. Lưu thành extension để dùng lại
Sau khi tạo, canvas được lưu dưới dạng một extension. Bạn có thể giữ nó cùng dự án để cả nhóm dùng, hoặc lưu thành extension cá nhân chỉ cho riêng mình. Cách này giúp biến một lần mô tả thành công cụ tái sử dụng cho các việc lặp lại về sau.
Cách bạn và agent cùng sửa một canvas
Điểm mạnh nhất của canvas nằm ở chỗ cả hai bên làm việc song song. Khi bạn thao tác trên giao diện, trạng thái chung đổi ngay và agent nhìn thấy cùng lúc. Bạn cũng có thể nhờ agent làm thay bằng chính các năng lực của canvas, ví dụ thêm một ghi chú phát hành hay chuyển một thẻ, rồi thấy thay đổi hiện ra.
Cách làm này phù hợp với những việc có nhiều mục nhỏ cần cập nhật liên tục: theo dõi tiến độ, phân loại issue, hay ghi lại việc đã xong trong ngày. Thay vì gõ lệnh rồi chờ phản hồi, bạn điều hướng công việc cùng agent trên một mặt phẳng chung, cả hai cùng thấy một trạng thái. Đây cũng là lý do GitHub mô tả canvas như một bảng trắng dùng chung chứ không phải một bảng báo cáo tĩnh.
Vài kiểu canvas hữu ích cho nhóm nhỏ
Với nhóm phát triển vài người, một canvas dạng danh sách kiểm tra phát hành giúp gom các bước trước khi đẩy bản mới: kiểm tra thử, viết ghi chú, xác nhận phiên bản. Một canvas dạng bảng phân loại issue giúp bạn kéo thả các issue đang chờ vào đúng nhóm mà không phải mở từng trang.
Nếu làm việc một mình, canvas dạng bảng theo dõi công việc trong ngày hoặc bảng ghi chú các hạng mục tính năng đã xong cũng đủ hữu ích. Điểm chung là các việc này đều có nhiều mục nhỏ, thay đổi liên tục, và bạn muốn agent cập nhật thay mình thay vì gõ lại từng dòng.
Lỗi hay gặp khi mới dùng canvas
Lỗi phổ biến nhất là mô tả quá chung chung, ví dụ chỉ nói cần một bảng theo dõi. Canvas sẽ ra một bảng trống, không có cột, không có quy tắc, và bạn phải sửa nhiều lần. Hãy nêu rõ dữ liệu nào cần xem, bạn muốn đổi gì trực tiếp, và agent được phép cập nhật gì.
Lỗi thứ hai là quên vai trò của agent. Nếu câu mô tả chỉ nói bạn cần thấy gì mà không nói agent được làm gì, canvas sẽ thành một giao diện tĩnh và mất đi phần cộng tác. Lỗi thứ ba là tham lam, muốn dồn quá nhiều quy trình vào một canvas duy nhất, khiến giao diện rối và khó dùng. Nên bắt đầu nhỏ, chạy thử một việc, rồi mở rộng.
Ngoài ra, nếu chưa biết bắt đầu từ đâu, cộng đồng đã chia sẻ các canvas extension dựng sẵn qua Awesome Copilot, gồm công cụ ghi chú phát hành, bảng kanban và quy trình phân loại issue. Bạn có thể cài một cái gần giống nhu cầu rồi nhờ agent chỉnh lại, thay vì dựng từ số không.
Canvas so với các lựa chọn khác
Nếu bạn đã dùng GitHub Copilot, canvas là phần mở rộng tự nhiên trong chính ứng dụng, không phải mua thêm công cụ quản lý dự án. Với người quen làm việc trong GitHub, lợi thế là canvas nằm ngay cạnh nơi issue và pull request đang sống.
Nếu bạn muốn một editor AI có giao diện tùy biến mạnh hơn, Cursor là lựa chọn đáng so. Cursor mạnh ở việc sửa mã trực tiếp trong dự án, còn canvas của GitHub Copilot tập trung vào bề mặt làm việc dùng chung giữa người và agent. Hai thứ giải quyết hai bài toán khác nhau, nên nhiều nhóm dùng song song thay vì chọn một.
Nên làm gì bây giờ
Nếu bạn đang dùng GitHub Copilot app, hãy mở một phiên, gõ lệnh tạo canvas và thử mô tả một bảng đơn giản cho việc đang làm. Bắt đầu từ một danh sách kiểm tra nhỏ, sau đó mở rộng dần khi đã quen cách mô tả. Nếu chưa dùng, đọc hướng dẫn chính thức trước khi quyết định có phù hợp với quy trình của nhóm hay không.
Nội dung và cách dùng canvas có thể được GitHub cập nhật thêm, nên bạn nên kiểm tra lại ở bài hướng dẫn chính thức của GitHub và tài liệu về canvas extension trước khi đưa vào quy trình chung. Xem thêm bài về GitHub Copilot trên TopỨngDụng để nắm các tính năng khác.
