GitHub Copilot ra mắt quy trình làm việc toàn diện: Từ ý tưởng đến triển khai trong một công cụ duy nhất

Nếu bạn đang cảm thấy choáng ngợp bởi AI vào lúc này, bạn không hề đơn độc.

Dường như mỗi ngày đều xuất hiện một công cụ mới, MCP mới, mô hình mới, kỹ năng mới, quy trình làm việc mới, tính năng mới, hay một bài đăng trên mạng xã hội kiểu như: “Này nhìn xem! Tôi đã hoàn toàn làm chủ AI chỉ với một câu lệnh kỳ lạ này.”

Tôi… không tin bạn.

Tôi làm việc với AI mỗi ngày, và điều tôi nhận ra là “ít hơn lại là nhiều hơn”. Không phải việc tôi cài đặt, cấu hình hay lừa các agent làm điều gì đó mới tạo ra sự khác biệt thực sự. Những thứ đó thú vị đấy, nhưng cuối cùng thì chúng chỉ giống như những mánh lới quảng cáo.

Tôi thấy hiệu suất công việc của mình tăng lên đáng kể nhờ vào cách tôi sử dụng “harness” (bộ khung điều khiển) và mức độ hiểu biết của tôi về nó.

Vì vậy, trong bài viết này, tôi sẽ chia sẻ với bạn một quy trình làm việc đơn giản mà bạn có thể sử dụng để cải thiện đáng kể hiệu quả làm việc với AI chỉ bằng cách tận dụng các tính năng sẵn có của GitHub Copilot. Không có câu lệnh kỳ lạ nào cả. Không có kỹ năng bí mật nào mà mọi người đều biết. Chỉ cần cái harness đó thôi. Harness là tất cả những gì bạn cần—hầu như là vậy.

1. Chọn một công cụ, bất kỳ công cụ nào

Điều này quá rõ ràng phải không? Hãy chọn một công cụ! Thật dễ dàng!

Nhưng ngay cả trong hệ sinh thái GitHub Copilot, cũng có rất nhiều lựa chọn. Chúng bao gồm CLI, ứng dụng GitHub Copilot mới, VS Code, Visual Studio và JetBrains, chỉ kể tên một vài cái tên tiêu biểu.

Tin tốt là các trải nghiệm này đang dần được tập trung hóa trên cùng một harness. Chi tiết có thể khác nhau tùy theo công cụ, nhưng quy trình cốt lõi thì nhất quán. Học cách dùng harness một lần, sử dụng ở mọi nơi.

Mặc dù vậy, tôi tin rằng việc học cách sử dụng harness là chìa khóa, và cách tốt nhất để học nó là tiếp cận nó gần nhất có thể. Vì vậy, nếu bạn mới bắt đầu, tôi khuyên bạn nên bắt đầu với GitHub Copilot CLI. Đó là giao diện dòng lệnh, nghĩa là chỉ toàn văn bản. Không có nhiều giao diện người dùng (UI) để học. Bạn nhập câu lệnh. Agent thực hiện công việc. Nhưng sự tương tác này trực tiếp hơn, tức thì hơn và thành thật mà nói, rất thỏa mãn.

Để minh họa, tôi sẽ sử dụng ứng dụng GitHub Copilot mới. Nhưng harness mà ứng dụng đó sử dụng chính xác là thứ bạn sẽ dùng nếu bạn đang sử dụng GitHub Copilot CLI, Visual Studio Code và nhiều nơi khác mà bạn có thể tìm thấy GitHub Copilot.

2. Bật chế độ YOLO

Chế độ YOLO còn được gọi là “Allow All” (Cho phép tất cả). Chế độ này cho phép agent thực thi bất kỳ lệnh nào mà không cần hỏi xin quyền. Điều này có thể khác nhau tùy thuộc vào công cụ bạn đang sử dụng, nhưng với hầu hết các công cụ, đó chỉ đơn giản là lệnh /allow-all trong khung chat. Nếu không, agent sẽ dừng lại và chờ bạn phê duyệt mỗi khi nó cần thực hiện bất kỳ công việc nào.

Các agent cần sự tự chủ để bạn thấy được sự gia tăng năng suất. Nếu bạn phải phê duyệt mọi thứ mà agent làm, thì thà bạn tự làm còn nhanh hơn. Hơn nữa, đó là một trải nghiệm người dùng tồi tệ. Chẳng ai muốn bị mắc kẹt ở bàn làm việc chỉ để nhấn nút “Phê duyệt” cả ngày. Và việc nhấn “Phê duyệt” liên tục chỉ khiến bạn hình thành thói quen không thèm đọc những gì mình đang phê duyệt, điều này làm mất đi mục đích ban đầu.

Tuy nhiên, bạn vẫn cần phải cẩn trọng với các agent. Những điều tồi tệ có thể xảy ra với những người tốt. Khi sử dụng chế độ YOLO, bạn không nên chạy agent trên máy cục bộ của mình. Điều này đặc biệt quan trọng khi bạn sử dụng chúng tại nơi làm việc—dữ liệu trên hệ thống của tổ chức là riêng tư và những sai lầm có thể gây ra hậu quả đắt giá.

May mắn thay, có rất nhiều tùy chọn để chạy các agent trong môi trường sandbox. Một cách dễ dàng để bắt đầu là sử dụng GitHub Codespaces hoặc các development container.

3. Bắt đầu với một bản mẫu (prototype)

Một trong những điều kỳ diệu nhất của AI là bạn có thể dễ dàng tạo bản mẫu cho bất cứ thứ gì ngay từ đầu. Trước đây, điều này không hề dễ dàng. Tạo bản mẫu từng là một giai đoạn đầy đủ của dự án và thường là một thứ gì đó xa xỉ. Bây giờ, bạn có thể tạo ra một bản mẫu chỉ với một câu lệnh.

Hãy xem qua một vài ví dụ.

Giả sử chúng ta muốn xây dựng một thành phần web chọn ngày (date picker). Nghe có vẻ đơn giản, nhưng thực tế lại khá phức tạp. Hãy nghĩ về tất cả những thứ khác nhau mà bạn có thể muốn làm với nó.

Hãy bắt đầu với một bản mẫu đơn giản và tạo ra vài biến thể. Tôi thường bắt đầu với thứ gì đó như thế này:

Trong trường hợp này, AI đã tạo ra một loạt các bố cục khác nhau, nhưng một trong số đó là bản mô phỏng bắt đầu bằng chế độ xem theo năm. Điều đó thật thú vị. Tôi muốn bộ chọn ngày của mình cho phép người dùng thu nhỏ để xem theo năm, sau đó vào tháng, và cuối cùng là ngày. Đây là những thứ bạn không cân nhắc cho đến khi nhìn thấy chúng.

Là con người, chúng ta xử lý các mô hình giàu cảm giác như hình ảnh, hình khối và bố cục hữu hình nhanh hơn nhiều so với văn bản dày đặc. Việc tạo ra các bản mẫu ít tốn công sức ngay từ đầu giúp các khái niệm phức tạp trở nên trực quan ngay lập tức.

Và điều này cũng áp dụng cho các tác vụ không liên quan đến hình ảnh.

Ví dụ, nếu tôi muốn thêm một API endpoint mới, tôi vẫn sẽ tạo một bản mẫu trực quan để hiểu các yêu cầu và ràng buộc trước khi bắt tay vào triển khai.

Vì ứng dụng GitHub Copilot hỗ trợ sơ đồ Mermaid, agent sẽ hiển thị kết quả này dưới dạng Markdown, vạch ra năm cách khác nhau để chúng ta có thể triển khai API endpoint này.

Khi làm việc với các agent, rất dễ quên rằng mọi thứ đều có những sắc thái riêng. Việc tạo bản mẫu giúp khám phá những sắc thái đó ngay từ đầu, để bạn tránh lãng phí thời gian và token quý giá vào việc làm lại.

Tôi khuyên bạn nên sử dụng mô hình cỡ trung bình, chẳng hạn như GPT 5.6 Terra hoặc Claude Sonnet, với mức độ suy luận trung bình cho hầu hết các công việc. Tôi cũng khuyên bạn nên gắn bó với bất kỳ mô hình nào bạn đã chọn trong suốt quá trình thực hiện tính năng, sửa lỗi hoặc cải tiến cụ thể đó. Tính năng prompt caching sẽ giúp bạn tiết kiệm token. Miễn là bạn không chuyển sang mô hình hoặc mức độ suy luận khác, các cuộc trò chuyện trước đó của bạn vẫn được lưu trong bộ nhớ đệm với mô hình đó, giúp bạn được giảm giá cho các yêu cầu trong tương lai.

4. Lập kế hoạch một cách bài bản

Bây giờ bạn đã biết mình thực sự muốn gì so với những gì bạn nghĩ ban đầu, đã đến lúc lập kế hoạch triển khai.

Hãy chuyển sang chế độ plan (kế hoạch) trong GitHub Copilot mà không cần bắt đầu một phiên làm việc mới.

“/plan Xây dựng một thành phần web chọn ngày. Tôi muốn người dùng có thể phóng to và thu nhỏ giữa các năm, tháng và ngày.”

Đó là một câu lệnh khá mơ hồ, và bạn có thể sẽ có nhiều ngữ cảnh hơn cho mô hình so với tôi ở đây, nhưng đây chỉ là một ví dụ minh họa. Nếu bạn không có thêm ngữ cảnh, cũng không sao. Đó chính xác là mục đích của bước này.

Về lý thuyết, bạn có thể khiến một mô hình thực hiện mọi thứ chỉ trong một lần nếu bạn soạn thảo câu lệnh hoàn hảo với ngữ cảnh hoàn hảo theo thứ tự hoàn hảo. Về lý thuyết là vậy.

Nhưng không ai trong chúng ta có thể làm được điều đó. Tuy nhiên, việc lập kế hoạch giúp bạn tiến gần hơn đến lý tưởng đó bằng cách đặt ra tất cả những câu hỏi mà bạn sẽ phải tự trả lời nếu tự tay xây dựng nó:

Danh sách này cứ kéo dài mãi. Bạn không thể nào nghĩ ra hết tất cả các trường hợp biên (edge cases), nhưng mô hình có thể giúp bạn xác định được nhiều trong số đó.

Bạn có thể làm cho chế độ plan trở nên quyết liệt hơn nữa trong việc đặt ra số lượng câu hỏi và các trường hợp biên bằng cách cài đặt kỹ năng “grill-me” từ Matt Pocock.