# GitHub Copilot và triết lý: Tại sao khung chat không phải lúc nào cũng là giao diện tối ưu? - Nguồn: GitHub Blog - Thời gian phát hành: 2026-09-25 03:00 (giờ Việt Nam) - Điểm AI: 58/100 - Link AIHOT.vn: https://aihot.vn/items/0c3e89d74153f27c - Nguồn dữ liệu AI HOT: https://aihot.news/items/cmufyyizw05iarogvajm9z1jn - Link gốc: https://github.blog/ai-and-ml/github-copilot/when-chat-is-the-wrong-ui ## Tóm tắt AI Đội ngũ GitHub Copilot phân tích hạn chế của giao diện chat truyền thống và giới thiệu tính năng 'canvas' – môi trường làm việc chuyên biệt cho phép agent AI tương tác trực tiếp với ứng dụng, thay vì chỉ phản hồi qua văn bản. ## Thân bài Một lập trình viên phải làm gì khi họ cần thứ gì đó hữu hình hơn là một khung chat? Hãy dùng đến canvas. 24 tháng 9, 2026 6 phút - Chia sẻ: Chúng ta đã trải qua 176 năm trong cuộc thử nghiệm AI này. Khoan đã… mới chỉ có ba năm thôi sao? Bạn có chắc không? Đôi khi tôi nhớ về những chuyện đã xảy ra vào năm ngoái, nhưng cảm giác như đã từ rất lâu rồi. Liệu chuyện đó có thực sự xảy ra với tôi, hay đó là chuyện của bố tôi và ông ấy kể lại khi tôi còn nhỏ? Dù sao thì… chúng ta đã bước vào năm thứ ba của cuộc thử nghiệm AI này và bề mặt tương tác chính mà chúng ta có với các LLM vẫn là chat. Tôi khá chắc rằng chính [@pmarca](https://x.com/pmarca) là người đầu tiên đề xuất thành phần textarea trong đặc tả HTML. Và tôi chắc chắn về điều đó vì tôi đã hỏi AI về nó. Trong một khung textarea. Nhưng tôi muốn đề xuất với bạn rằng có lẽ, chỉ là có lẽ thôi, chat là một giao diện người dùng (UI) sai lầm. Chà, ít nhất là hầu hết thời gian. Học giả Steven Pinker đã nói như thế này… > Thật đáng tiếc khi lần triển khai AI quy mô lớn đầu tiên lại giống như một mánh lới quảng cáo—một chatbot góc nhìn thứ nhất. Nhưng AI có tiềm năng to lớn nếu nó được định hướng theo tác vụ. > — Steven Pinker, academic Và nếu một học giả nói điều đó rồi tôi viết lại thành một trích dẫn trong bài blog, thì bạn biết là nó đúng rồi đấy. Chat là cách chính để làm việc với AI vì đó là thứ đầu tiên mà mọi người cảm thấy phù hợp. Và chat hoạt động rất tốt như một giải pháp phổ quát đơn giản vì chúng ta không biết mọi người sẽ cố gắng làm gì với AI. Nhưng với tư cách là người dùng, bạn biết mình sẽ làm gì với nó, và tại thời điểm đó, chat thường là giao diện người dùng sai lầm. Thứ bạn cần, độc giả thân mến, là một loại giao diện người dùng có thể tùy chỉnh mà bạn có thể tạo ra từ hư không để làm việc với AI (hoặc chiến đấu với nó—tùy bạn) theo cách phù hợp với những gì bạn đang cố gắng thực hiện tại thời điểm đó. Có rất nhiều cách để thực hiện điều này, nhưng trong [ứng dụng GitHub Copilot](https://github.com/features/ai/github-app), nó được gọi là canvas. Một [canvas](https://docs.github.com/en/copilot/how-tos/github-copilot-app/working-with-canvas-extensions) là một ứng dụng full-stack nhỏ chạy bên trong ứng dụng GitHub Copilot mà không cần trình duyệt. Tác nhân (agent) có thể giao tiếp với phần máy chủ của ứng dụng đó và máy chủ có thể phản hồi lại. Vì vậy, kết quả bạn nhận được là một bề mặt có thể làm bất cứ điều gì một chương trình máy tính bình thường có thể làm, cộng với khả năng giao tiếp hai chiều với tác nhân GitHub Copilot. Nghe có vẻ hơi mơ hồ và tôi đã sử dụng từ "hai chiều" nghe như lấy ra từ một bài thuyết trình PowerPoint, vì vậy hãy xem khái niệm này trong thực tế và xem liệu chúng ta có thể giải quyết các vấn đề thực tế với canvas đầy quyền năng hay không. Chúng ta sẽ bắt đầu với một ví dụ đơn giản: sử dụng canvas để tạo một trò chơi Connect 4 nơi bạn có thể chơi với tác nhân bên trong ứng dụng GitHub Copilot. Hãy xem tôi TIÊU DIỆT GPT-5.6 Sol ở chế độ suy luận cao như thế nào… _Nội dung media · xem tại bài gốc_ OK. Nhưng tôi chắc chắn đã đánh bại GPT-5.6 Luna mà không cần suy luận… NGHE NÀY… CONNECT 4 LÀ MỘT TRÒ CHƠI KHÓ!! Việc xây dựng một canvas cũng đơn giản như việc yêu cầu nó… ``` Create a new canvas that uses the Connect 4 game to demonstrate the ability for the user to interact with the canvas for the canvas to talk to the agent and for the agent to control the canvas ``` Ứng dụng GitHub Copilot biết canvas là gì, vì vậy chúng ta không cần phải giải thích gì thêm nữa. Giờ đây, vì các canvas này thực sự là các ứng dụng full-stack chứ không chỉ là các trang web, chúng có thể gọi các API của bên thứ ba, vâng, nhưng chúng cũng có thể thực thi mã cục bộ trên máy của bạn. Ví dụ, đây là giao diện người dùng cho Winget có thể duyệt tìm các gói trên registry, cũng như quản lý các gói cục bộ của tôi, bao gồm cả cài đặt và gỡ cài đặt. _Nội dung media · xem tại bài gốc_ Không có AI ở đây, nhưng đó chính là điểm mấu chốt. Khi chat là giao diện chính, nó khuyến khích bạn sử dụng tác nhân để làm mọi thứ. Đây thường là sự lãng phí token thuần túy. Hầu như luôn tốt hơn nếu để tác nhân xây dựng một công cụ mà mọi tương tác trong tương lai đều miễn phí thay vì coi chính tác nhân đó là công cụ. Hãy ngừng yêu cầu GPT-5.6 Sol Max "stage và commit". (Tôi biết bạn làm vậy. Vì tôi cũng từng làm thế. Đừng làm tôi xấu hổ vì tốn token, cái tôi của tôi mỏng manh lắm.) Một ví dụ tuyệt vời khác là thay vì sử dụng chat để yêu cầu tác nhân thực hiện các thao tác với cơ sở dữ liệu SQLite của bạn, tại sao bạn không tạo một canvas và, bạn biết đấy, tự mình làm lấy. Ý tôi là, bạn thậm chí có thể có intellisense ở đây. Tại sao không? Đã là năm 2026, và AI là một chiếc hộp kỳ diệu chỉ làm bất cứ điều gì bạn muốn. _Nội dung media · xem tại bài gốc_ Chẳng phải điều đó rất dễ chịu sao? Thỉnh thoảng viết một chút SQL cũng hay mà. Tôi nói là thỉnh thoảng thôi. Thư giãn đi. Hoặc tại sao phải viết các bài blog Jekyll bằng Markdown thuần túy khi bạn có thể thực sự hồi sinh Windows Live Writer. _Nội dung media · xem tại bài gốc_ Ok, đây đều là những ví dụ thú vị và hữu ích ở mức độ nhẹ, nhưng giá trị của giao diện người dùng tùy chỉnh sẽ trở nên rõ ràng hơn nhiều khi bạn sử dụng nó để tự động hóa các quy trình phát triển của mình. Tôi sẽ không bảo bạn phải sống cuộc đời của mình như thế nào, nhưng quy trình làm việc của tôi với các tác nhân đại loại trông như thế này… _Bài gốc còn tiếp._ Xem tiếp tại: