Từ Gems đến Skills: Gemini biến tùy chỉnh thành quy trình có thể tái sử dụng

Minh họa biên tập nguyên bản. Hình thể hiện ý tưởng về chỉ dẫn có thể tái sử dụng, không phải ảnh chụp Gemini hay kiến trúc nội bộ của sản phẩm.

Cá nhân hóa đang trở thành một trong những khía cạnh thú vị nhất của AI tiêu dùng. Trợ lý hữu ích không chỉ biết nhiều điều; nó còn nhớ cách một người muốn tiếp cận công việc lặp lại. Bản tin nghiên cứu, rà soát biên tập và bàn giao dự án cần những tiêu chuẩn khác nhau. Lặp lại các tiêu chuẩn ấy trong mọi cuộc trò chuyện thật phiền phức, còn để chúng ngầm hiểu thì tạo ra kết quả thiếu nhất quán.

Quá trình Google chuyển từ Gems sang Skills phản ánh vấn đề đó. Thay vì xem mỗi trợ lý tùy chỉnh là một đích đến hoàn toàn riêng biệt, chỉ dẫn có thể tái sử dụng trở thành một phần của cuộc trò chuyện đang diễn ra. Thay đổi này trông nhỏ ở cấp giao diện nhưng có ý nghĩa lớn hơn với cách mọi người tổ chức quy trình làm việc. Nó cũng tạo ra công việc chuyển đổi: một bộ chỉ dẫn quen thuộc không tự động trở thành skill được định nghĩa rõ, có thể mang sang nơi khác và kiểm thử được.

Hãy hiểu đợt triển khai là một lịch trình, không phải công tắc áp dụng cho tất cả

Thông báo của Google Workspace lên lịch bắt đầu triển khai ứng dụng Gemini từ ngày 13 tháng 10 năm 2026, dự kiến hoàn tất theo từng giai đoạn vào giữa tháng 11. Thông báo mô tả riêng đợt triển khai Workspace và các mốc chuyển đổi sau đó dành cho tài khoản được quản lý. Ngày bắt đầu triển khai không đảm bảo một tài khoản cụ thể đã có các tùy chọn điều khiển. Bài viết này được nghiên cứu ngày 12 tháng 10 và lên lịch xuất bản sau đó; chúng tôi chưa xác minh tính năng đã được kích hoạt trong mọi tài khoản hay tổ chức. Thông báo Google Workspace

Trang trợ giúp của Google lên lịch chuyển Gems sang Skills bắt đầu vào tháng 11 năm 2026 với tài khoản cá nhân, tháng 3 năm 2027 với tài khoản Workspace doanh nghiệp, tổ chức và phi lợi nhuận, và tháng 6 năm 2027 với tài khoản Workspace giáo dục. Các mốc chuyển đổi này tách biệt với đợt triển khai tính năng Skills. Hãy kiểm tra hướng dẫn cho loại tài khoản của bạn và hỏi quản trị viên về khả năng sử dụng trên tài khoản được quản lý. Trợ giúp về chuyển đổi từ Gems sang Skills

Trước khi chuyển đổi, hãy lưu một bản dễ đọc gồm tên, chỉ dẫn và tệp tham khảo của mỗi Gem. Nhờ vậy, bạn có thể giữ nguyên mục đích và so sánh quy trình mới khi Skills khả dụng cho tài khoản của mình.

Thông báo và trang trợ giúp là những ảnh chụp tại một thời điểm của dịch vụ đang thay đổi. Ngày có thể đổi, giao diện có thể được cập nhật và cài đặt quản trị viên có thể ảnh hưởng đến quyền truy cập. Vì vậy, kế hoạch chuyển đổi hợp lý giữ một bản sao cấu hình ban đầu và chờ tính năng liên quan khả dụng. Kế hoạch không dựa vào dự đoán rằng mọi người dùng đều thấy cùng một màn hình vào cùng một buổi sáng.

Chúng tôi chưa thực hiện chuyển tài khoản cho bài viết này hoặc đo mức tăng năng suất nhờ tính năng mới. Các ví dụ dưới đây là phương pháp chuẩn bị và rà soát được đề xuất. Chúng nhằm giúp độc giả không làm mất ý định đằng sau một tùy chỉnh, chứ không chứng nhận giao diện hay tài khoản cụ thể đã hoàn tất chuyển đổi.

Một skill nên mô tả công việc có thể lặp lại

Google mô tả Skills là chỉ dẫn có thể tái sử dụng trong nhiều cuộc trò chuyện, được chọn rõ ràng hoặc áp dụng khi phù hợp, và có thể kết hợp cho công việc phức tạp hơn. Hướng dẫn tạo hỗ trợ tệp SKILL.md ở thư mục gốc cùng tài liệu tham khảo tùy chọn; tập lệnh cần truy cập Internet không được hỗ trợ và tệp tham khảo phải được tải lên cùng Skill. Vì vậy, Skill là một gói chỉ dẫn và tài liệu tham khảo, không phải chương trình không giới hạn để vận hành website. Tạo và quản lý Skills cho ứng dụng Gemini

Sai lầm dễ mắc nhất là biến mọi câu lệnh dài thành skill. Độ dài không phải đặc điểm quyết định. Skill hữu ích có công việc dễ nhận biết, đầu vào rõ ràng, tiêu chuẩn đầu ra và điều kiện không được hành động. Nếu thiếu các yếu tố đó, việc tái sử dụng tự động có thể lặp lại sự mơ hồ thay vì tiết kiệm thời gian.

Hãy xét tùy chỉnh “bản tin nghiên cứu” giả định. Nó không nên chỉ nói “hãy thật kỹ lưỡng”. Nó có thể yêu cầu câu hỏi nghiên cứu, ngày chốt thông tin, liên kết đến nguồn sơ cấp và phân biệt phát hiện đã xác nhận với diễn giải. Nó có thể cấm bịa nguồn khi không có bằng chứng. Các yêu cầu ấy giúp dễ rà soát đầu ra và dễ nhận diện tác vụ.

Giờ hãy xét một tùy chỉnh riêng về “phong cách biên tập”. Nó có thể quy định đoạn văn ngắn, ngôn ngữ giản dị và tiêu đề nhất quán. Tách riêng phần này khỏi yêu cầu bằng chứng có thể làm việc tái sử dụng linh hoạt hơn. Người dùng có thể áp dụng cùng tiêu chuẩn bằng chứng cho điều tra kỹ thuật và bản tin, đồng thời chọn phong cách viết khác nhau. Đó là sức hấp dẫn của việc kết hợp, miễn là các chỉ dẫn không mâu thuẫn với nhau.

Kiểm kê ý định trước khi sao chép nội dung

Trước khi chuyển Gem, hãy ghi lại những gì nó làm tốt. Bạn dùng nó cho những tác vụ nào? Thường cung cấp thông tin gì? Phần nào của đầu ra bạn luôn phải sửa? Tệp tham khảo nào thiết yếu, tệp nào được thêm từ nhiều tháng trước cho một tác vụ nhất thời? Bản kiểm kê này giá trị hơn việc giữ nguyên câu lệnh mà độ phức tạp tình cờ của nó không ai hiểu.

Hãy tách quy tắc bền vững khỏi ngữ cảnh tạm thời. “Phân biệt tuyên bố của công ty với phép đo độc lập” là quy tắc nghiên cứu bền vững. “Chúng ta ra mắt vào thứ Năm tuần tới” là ngữ cảnh tạm thời và có thể sai ngay khi lịch thay đổi. Chỉ dẫn có thể tái sử dụng không nên lặng lẽ mang thông tin cũ vào tác vụ mới chỉ vì chúng từng hữu ích.

Kiểm tra thông tin riêng tư bị nhúng trong ví dụ. Tên khách hàng thật, địa chỉ nội bộ hay kế hoạch kinh doanh chưa công bố có thể đã lọt vào câu lệnh ban đầu như một mẫu tiện dụng. Chúng không nhất thiết thuộc về cấu hình có thể tái sử dụng. Hãy thay chi tiết không cần thiết bằng ví dụ trung tính và giữ tài liệu nhạy cảm cần thiết trong đúng tài khoản và cơ chế kiểm soát truy cập.

Bản kiểm kê cũng nên xác định những giả định chưa từng được viết ra. Có thể đồng nghiệp luôn kiểm tra số liệu cuối cùng, hoặc bạn luôn cung cấp tài liệu nguồn trước khi bắt đầu. Nếu quy trình mới giúp skill xuất hiện trong nhiều cuộc trò chuyện, những giả định ấy có thể không còn đúng. Hãy chuyển chúng thành yêu cầu rõ ràng thay vì hy vọng ngữ cảnh xung quanh vẫn giữ nguyên.

Giữ một bản tham khảo có thể mang sang nơi khác

Danh sách kiểm tra chuyển đổi nguyên bản, minh họa cách so sánh thực tế chứ không phải giao diện Gemini.

Bản sao có thể mang sang nơi khác giúp bạn có thứ để kiểm tra khi giao diện thay đổi. Hãy giữ tên, mục đích, chỉ dẫn, danh sách tệp tham khảo và một vài tác vụ mẫu ở định dạng thông thường, dễ đọc. Cách này bảo toàn ý nghĩa của tùy chỉnh khi cơ chế nhập khác nhau, nhưng không đảm bảo có thể nhập chỉ bằng một cú nhấp vào mọi sản phẩm.

Với tệp tham khảo, hãy ghi lý do mỗi tệp được đưa vào và lần gần nhất nó được rà soát. Tài liệu chính sách có thể có thẩm quyền trong một tổ chức nhưng không liên quan ở nơi khác. Hướng dẫn phong cách có thể lỗi thời. Bảng dữ liệu có thể chứa thông tin không được chia sẻ bên ngoài nhóm. Chỉ tên tệp hiếm khi thể hiện đủ những ràng buộc đó.

Hãy giữ cấu hình ban đầu trong khi đánh giá bản dự kiến. Chuyển đổi có thể giữ nguyên câu chữ nhưng vẫn thay đổi hành vi vì mô hình, công cụ hoặc ngữ cảnh trò chuyện xung quanh khác nhau. Bản tham khảo để quay lui giúp phân biệt vấn đề chỉ dẫn với thay đổi nền tảng. Nó cũng ngăn việc viết lại vội vàng trở thành phiên bản duy nhất còn lại.

Đừng nhầm khả năng mang theo với quyền phân phối không hạn chế. Cấu hình có thể chứa tài liệu tham khảo được cấp phép hoặc thông tin riêng tư. Việc nó nằm gọn trong tệp văn bản không có nghĩa là nên công bố hay gửi cho dịch vụ khác. Hãy xem lại nội dung và đích đến trước khi chia sẻ skill với đồng nghiệp hoặc nhập skill từ tác giả không quen biết.

Mẫu nhỏ dễ rà soát hơn câu lệnh khổng lồ

Mẫu nghiên cứu ngắn này làm rõ các yêu cầu của quy trình. Hãy điều chỉnh cho công việc của bạn và kiểm tra yêu cầu định dạng hiện hành của Google trước khi nhập.

---
name: source-linked-research
description: Soạn bản tin nghiên cứu tách biệt bằng chứng với diễn giải.
---

# Đầu vào
- Câu hỏi nghiên cứu và đối tượng dự kiến.
- Ngày chốt thông tin và nguồn được phê duyệt hoặc phạm vi tìm kiếm.

# Phương pháp
- Ưu tiên nguồn sơ cấp cho các tuyên bố thực tế về sản phẩm.
- Gắn nhãn riêng thông báo, phép đo và phân tích cá nhân.
- Đánh dấu bằng chứng còn thiếu thay vì bịa sự kiện hoặc trích dẫn.

# Đầu ra
- Phát hiện chính, liên kết hỗ trợ và câu hỏi chưa được giải quyết.
- Không gửi ra ngoài hoặc công bố nếu chưa có phê duyệt riêng.

Giá trị không nằm ở câu chữ cụ thể. Mà ở chỗ hợp đồng được thể hiện rõ. Người đọc có thể nhận ra đầu vào, kiểm tra quy tắc xử lý bằng chứng thiếu và thấy việc xuất bản là một hành động riêng. Người biên tập sau này có thể đổi một yêu cầu mà không cần gỡ rối cả trang chỉ dẫn về nhân cách không liên quan.

Khi có thể, hãy chọn Skill dự định dùng cho công việc quan trọng và kiểm tra xem kết quả có làm theo hay không. Tính năng tự nhận biết mức độ liên quan tiện lợi, nhưng có thể khiến các chỉ dẫn đang được áp dụng khó nhận ra hơn.

Hãy dùng cùng một nhóm đầu vào nhỏ trước và sau khi chuyển đổi: một trường hợp thông thường, một đầu vào thiếu thông tin và một trường hợp biên từng cần chỉnh sửa. So sánh nội dung chứ không chỉ định dạng: phiên bản mới có giữ lại điều kiện, tránh bịa chi tiết và duy trì giới hạn với hành động bên ngoài không? Với nghiên cứu, kiểm tra các liên kết quan trọng; với biên tập, kiểm tra ý nghĩa; với bàn giao, xác nhận trách nhiệm và câu hỏi chưa giải quyết vẫn còn nguyên.

Ghi lại ngày, loại tài khoản và phiên bản cấu hình để phân biệt thay đổi chỉ dẫn với thay đổi nguồn tư liệu hoặc nền tảng. Với mục đích cá nhân, một danh sách ngắn và vài ví dụ đã lưu có thể phát hiện lỗi rõ ràng; quy trình có hệ quả lớn trong tổ chức có thể cần rà soát chính thức hơn. Dù ở mức nào, hãy kiểm tra hành vi mong muốn, không chỉ việc nhập thành công.

Tránh mã hóa bí mật, token xác thực hoặc chỉ dẫn công cụ không giới hạn trong tệp skill. Chỉ dẫn có thể tái sử dụng nên mô tả công việc, không đóng vai trò kho thông tin xác thực. Nếu tác vụ cần truy cập thông tin riêng tư, quyền đó thuộc về cơ chế kiểm soát tài khoản và quyền hạn phù hợp của nền tảng. Sự tiện lợi không nên khiến tài liệu nhạy cảm trở nên vô hình bên trong cấu hình.

Kết hợp các skill cũng có thể kết hợp xung đột

Việc kết hợp hấp dẫn vì tác vụ thực tế có nhiều khía cạnh. Một báo cáo có thể cần tiêu chuẩn nghiên cứu, văn phong nội bộ và phần giải thích phù hợp với đối tượng. Nhưng các chỉ dẫn có thể xung đột: một cái đòi hỏi câu trả lời ngắn, cái khác yêu cầu kiểm toán toàn diện; một cái khuyến khích kiến nghị dứt khoát, cái khác yêu cầu làm nổi bật bất định chưa được giải quyết. Quy trình hữu ích nhận ra xung đột thay vì đưa ra một thỏa hiệp tùy tiện.

Hãy bắt đầu với hai skill bổ trợ nhau trước khi thêm nhiều hơn. Kiểm tra xem tiêu chuẩn bằng chứng có được giữ nguyên qua chỉ dẫn phong cách không và đầu ra có còn phù hợp với đối tượng không. Nếu kết quả thay đổi bất ngờ, hãy kiểm thử riêng từng skill. Nếu không, lỗi khó quy cho nguyên nhân nào và người dùng có thể phản ứng bằng cách thêm ngày càng nhiều chỉ dẫn vào một đống ngày càng lớn.

Kích hoạt tường minh có thể hữu ích trong lúc đánh giá. Tự động chọn theo mức độ liên quan rất tiện khi hoạt động tốt, nhưng có thể khiến chỉ dẫn được áp dụng kém rõ ràng hơn. Với tác vụ quan trọng, hãy ghi lại skill dự định dùng và kiểm tra kết quả có tuân theo nó không. Đây là khuyến nghị rà soát, không phải tuyên bố rằng giao diện cụ thể cung cấp nhật ký chỉ dẫn đầy đủ.

Hãy giữ phạm vi đủ hẹp để skill không áp dụng vào công việc không liên quan. Quy tắc “nghiên cứu tài chính” không nên âm thầm định hình cuộc trò chuyện viết sáng tác. Mẫu hỗ trợ khách hàng không nên biến câu hỏi cá nhân thành phiếu yêu cầu trang trọng. Cá nhân hóa tốt cũng bao gồm việc nhận biết lúc nào tùy chỉnh không liên quan.

Dùng tác vụ so sánh trước khi bỏ quy trình cũ

Một lần rà soát chuyển đổi thực tế dùng cùng một tập đầu vào nhỏ trước và sau thay đổi. Hãy gồm một trường hợp thông thường, một đầu vào thiếu thông tin và một tình huống biên trước đây cần chỉnh sửa. So sánh nội dung, không chỉ định dạng. Phiên bản mới có giữ các điều kiện cần thiết không? Có bịa chi tiết còn thiếu không? Có duy trì ranh giới quanh hành động bên ngoài không?

Với quy trình nghiên cứu, hãy kiểm tra mọi liên kết đóng vai trò then chốt trong một đầu ra mẫu. Với quy trình biên tập, hãy xem ý nghĩa dự định có còn nguyên sau khi viết lại không. Với bàn giao nội bộ, xác nhận trách nhiệm và câu hỏi chưa giải quyết không bị biến thành việc đã hoàn tất. Những kiểm tra này cần khớp với tác vụ thay vì dựa vào một điểm “chất lượng” chung chung duy nhất.

Ghi lại ngày, loại tài khoản và phiên bản cấu hình dùng để so sánh. Điều đó giúp điều tra thay đổi sau này dễ hơn. Nếu kết quả xấu đi sau một bản cập nhật, bạn có thể hỏi chỉ dẫn, tài liệu nguồn hay nền tảng đã thay đổi. Thiếu mốc tham chiếu thì mọi cuộc điều tra đều bắt đầu bằng ký ức không chắc chắn về cách mọi thứ từng hoạt động.

Việc này không đòi hỏi hệ thống đánh giá lớn cho mục đích cá nhân. Danh sách kiểm tra ngắn và vài ví dụ đã lưu có thể đủ để phát hiện hồi quy rõ ràng. Nhóm có quy trình hệ quả lớn hơn có thể cần rà soát chính thức hơn, nhưng nguyên tắc vẫn vậy: chuyển đổi hoàn tất khi hành vi dự kiến đã được kiểm tra, không chỉ vì một tệp đã được nhập.

Cá nhân hóa cũng cần người chịu trách nhiệm, bên cạnh sự tiện lợi

Quá trình chuyển đổi hướng tới một tương lai rộng hơn, nơi người dùng mang theo cách làm việc có thể tái sử dụng giữa các tác vụ thay vì lần nào cũng bắt đầu từ câu lệnh trống. Điều đó có thể có giá trị. Nó cũng có thể tạo ra một dạng phần mềm tích lũy mới: các bộ chỉ dẫn và tập hợp tài liệu tham khảo ảnh hưởng đến quyết định quan trọng dù không giống ứng dụng thông thường.

Ai đó cần sở hữu bộ sưu tập ấy. Ai cập nhật tệp tham khảo? Ai rà soát skill dùng chung sau khi chính sách thay đổi? Ai quyết định một chỉ dẫn nhập vào có phù hợp không? Những câu hỏi này dễ bị trì hoãn khi tùy chỉnh giống như viết câu lệnh tùy hứng. Chúng khó có thể bỏ qua khi cùng cấu hình được tái sử dụng trong công việc hằng ngày của cả nhóm.

Với cá nhân, trách nhiệm có thể khiêm tốn: giữ bản sao dễ đọc, loại bỏ giả định lỗi thời và xác minh đầu ra có hệ quả. Với tổ chức, việc này có thể cần cấu hình được phê duyệt, quy tắc truy cập và quy trình rà soát. Không cách nào nên xem cá nhân hóa là sự bảo đảm chính xác. Trợ lý quen thuộc vẫn có thể mắc lỗi chưa từng gặp.

Hãy chuyển quy trình, không chỉ chuyển tên

Khâu chuẩn bị hữu ích nhất là giữ lại công việc mà Gem của bạn đảm nhiệm và làm rõ các yêu cầu của nó. Giữ bản tham khảo, xác định các tệp nó phụ thuộc, tách quy tắc ổn định khỏi dữ kiện tạm thời và kiểm thử phiên bản dự kiến trên đầu vào tiêu biểu. Sau đó, dùng thông tin triển khai cho đúng tài khoản của bạn thay vì giả định có một hạn chót toàn cầu duy nhất.

Skills có thể giúp tùy chỉnh dễ tái sử dụng và kết hợp hơn. Lợi ích đến từ các quy tắc rõ ràng và việc rà soát cẩn thận, không phải từ chính từ “skill”. Khi công cụ AI trở nên cá nhân hóa hơn, cấu hình có giá trị là cấu hình bạn có thể hiểu, duy trì và xác minh. Chuyển giao sự hiểu biết ấy quan trọng hơn việc sao chép câu lệnh sang màn hình mới.

Tập trung các quyết định chuyển đổi của bạn vào một nơi

Với độc giả đang sắp xếp nghiên cứu, ghi chú cấu hình và quyết định rà soát, Telli.sh là một không gian tùy chọn. Tạo ghi chú rà soát.