Chuyển đến nội dung chính
Hướng dẫn AI

Hướng dẫn Solo to Team: Cài đặt gói kỹ năng cộng tác, một người điều phối nhiều trợ lý AI

Hướng dẫn này chỉ bạn cách cài đặt gói kỹ năng Solo to Team, tìm hiểu bốn kỹ năng cốt lõi và hoàn thành quy trình cộng tác “phân công, nhận việc, thu hồi, kiểm tra, ra quyết định” qua một nhiệm vụ nhỏ, đồng thời giải thích cấu hình đa máy chủ, giới hạn tự động hóa và cách sử dụng nâng cao.

Hướng dẫn Solo to Team: Cài gói kỹ năng cộng tác, điều phối nhiều trợ lý AI

Giới thiệu dự án

Solo to Team · Một người thành một đội, với tên kho lưu trữ là solo-to-team-skills, là một bộ kỹ năng cộng tác bằng tiếng Trung dành cho kịch bản “một người kiểm soát tổng thể, nhiều trợ lý AI hoạt động lâu dài”. Bộ kỹ năng này không chịu trách nhiệm tự động lập đội cho AI, mà cung cấp một phương pháp có thể lặp lại, giúp bạn giao nhiệm vụ, theo dõi tiến độ, kiểm tra bằng chứng, sau đó để con người đưa ra phán đoán cuối cùng.

Trạng thái hiện tại của dự án là v0.9-draft và vẫn sẽ tiếp tục được chỉnh sửa. Dự án đã được sử dụng thực tế trong phạm vi giới hạn và hoàn tất xác minh trên Codex, WorkBuddy, DeepSeek Harness, Cursor, CodeBuddy, Kimi Work, 千问办公 và các host khác; Grok Bot cần cấu hình thủ công. Claude Code đã có cấu trúc plugin, nhưng chưa được đưa vào danh sách hỗ trợ ban đầu.

“Được hỗ trợ” có nghĩa là phương thức cài đặt và gọi được chỉ định đã có ghi nhận hoạt động thành công; không có nghĩa mọi nhiệm vụ đều có thể hoàn thành ổn định, cũng không có nghĩa cả bốn kỹ năng đã được xác minh lần lượt trên mọi host.

Dự án giải quyết vấn đề gì

Khi cộng tác với nhiều trợ lý AI, điều dễ mất kiểm soát thực sự thường không phải là năng lực của mô hình mà là quy trình: sau khi giao nhiệm vụ không ai xác nhận, người thực hiện nói “đã hoàn thành” nhưng không có bằng chứng, nghiệm thu bị đánh đồng với việc đã nhận kết quả, hoặc hướng dẫn thao tác chỉ có tác giả mới hiểu.

Solo to Team sắp xếp quá trình cộng tác thành một tuyến chính:

Nêu mục tiêu → Phân công → Bàn giao → Đối chiếu → Phán đoán

  • Nêu mục tiêu: Xác định rõ cần làm gì, kết quả được đặt ở đâu, thời hạn giao là khi nào và thế nào được xem là hoàn thành.
  • Phân công: Trước khi giao việc, đăng ký “đang chờ nhận”, ghi rõ người thực hiện, người tiếp nhận và người kiểm tra khi đến hạn.
  • Bàn giao: Ghi riêng “đã nhận việc” và “đã nhận kết quả”, tránh nhầm việc nhận được tin nhắn với việc đã hoàn thành.
  • Đối chiếu: Kiểm tra bằng chứng hợp lệ tương ứng với phiên bản hiện tại; những phần đã sửa đổi hoặc từng thất bại phải được xác minh lại.
  • Phán đoán: Con người quyết định cho phép, trả lại hay thay đổi hướng đi.

Bốn kỹ năng cốt lõi

dispatch-accept-verify

Tên hiển thị là “Việc đã giao phải được nhận lại”, phụ trách phân công và bàn giao. Kỹ năng này yêu cầu đăng ký “đang chờ nhận” trước khi giao nhiệm vụ, đồng thời ghi riêng việc nhận nhiệm vụ, nhận kết quả và hoàn tất nghiệm thu. Chỉ sau khi nghiệm thu hoàn tất hoặc được ủy quyền hủy, nhiệm vụ mới có thể được xóa khỏi danh sách chưa hoàn thành.

evidence-before-done

Tên hiển thị là “Trước khi bàn giao phải có bằng chứng”, phụ trách đối chiếu. Kỹ năng này nhấn mạnh rằng kết luận hoàn thành phải dựa trên bằng chứng tương ứng với phiên bản hiện tại, chẳng hạn như mở và kiểm tra kết quả, tính toán lại, chạy lệnh hoặc thực hiện lại toàn bộ quy trình ban đầu.

beginner-ops-writing

Tên hiển thị là “Hướng dẫn thao tác cho người mới”, dùng để viết các bước mà bất kỳ ai không biết bối cảnh cũng có thể làm theo. Các nguyên tắc cốt lõi gồm mỗi lần chỉ viết một bước, đối tượng được chỉ rõ duy nhất và nêu rõ cần nhìn thấy gì sau khi hoàn thành. Những hành động bắt buộc chính người dùng thực hiện như đăng nhập, thanh toán, xóa hoặc gửi chính thức chỉ nên viết “vui lòng tự thực hiện”, không được thiết kế cách làm thay.

ops-case-notes

Tên hiển thị là “Ghi chép vận hành đã khử nhận dạng”, bao gồm hai trường hợp đã khử nhận dạng từ quá trình vận hành thực tế, ghi lại vấn đề thực tế, cách sửa, kết quả và những giới hạn vẫn chưa được giải quyết. Kỹ năng này phù hợp để tham khảo khi xem xét lại quy trình sau khi phát hiện lỗ hổng.

Chuẩn bị trước khi bắt đầu

Trước tiên, hãy tải xuống hoặc nhân bản kho lưu trữ, đồng thời đảm bảo thư mục skills/ tồn tại trên máy cục bộ. Thư mục này phải chứa bốn thư mục con kỹ năng, mỗi thư mục có một tệp SKILL.md.

git clone YOUR_REPOSITORY_URL
cd solo-to-team-skills

Địa chỉ nhân bản cần được thay bằng địa chỉ kho lưu trữ chính thức sau khi dự án được công khai. Nếu lấy dự án bằng cách tải tệp nén, bạn cũng có thể giải nén và sử dụng trực tiếp.

Khi cài đặt, hãy tuân thủ các nguyên tắc sau:

  • Sao chép toàn bộ thư mục skills/tên-kỹ-năng/, không chỉ sao chép SKILL.md.
  • dispatch-accept-verify còn phụ thuộc vào các mẫu trong thư mục của nó; chỉ sao chép nội dung chính sẽ làm mất mẫu dòng đăng ký.
  • Khuyến nghị cài đặt đồng thời dispatch-accept-verify và evidence-before-done.
  • evidence-before-done cũng có thể được sử dụng độc lập.
  • beginner-ops-writing và ops-case-notes là các phần bổ trợ tùy chọn; không cài đặt cũng không ảnh hưởng đến quy trình giao và nhận chính.

Chọn host và cài đặt

Codex

Phương thức đã được xác minh trên Codex sử dụng .agents/plugins/marketplace.json đi kèm kho lưu trữ. Trước tiên hãy cài đặt và đăng nhập Codex CLI, sau đó thực hiện trong thư mục gốc của dự án:

cd /path/to/solo-to-team-skills
codex plugin marketplace add "$(pwd)"
codex plugin add solo-to-team-skills@solo-to-team-skills

Nếu lệnh trả về trạng thái khác 0, hãy dừng lại và xác nhận thư mục hiện tại có phải là thư mục gốc của gói chứa .agents/plugins/marketplace.json hay không. Sau khi cài đặt, hãy mở phiên mới hoặc sử dụng codex exec để gọi kỹ năng.

codex exec -s workspace-write --skip-git-repo-check -C "$(pwd)" '请使用技能 dispatch-accept-verify,写一行待收登记到 T044_dispatch_line.md'

Nếu cần gỡ cài đặt, hãy thực hiện:

codex plugin remove solo-to-team-skills@solo-to-team-skills
codex plugin marketplace remove solo-to-team-skills

Cursor

Sao chép toàn bộ thư mục kỹ năng cần dùng vào thư mục kỹ năng của người dùng:

mkdir -p ~/.cursor/skills/
cp -R skills/dispatch-accept-verify ~/.cursor/skills/
cp -R skills/evidence-before-done ~/.cursor/skills/

Sau đó gọi theo tên kỹ năng trong Cursor Agent. Bạn cũng có thể sử dụng dạng CLI cursor agent --print. Khi chạy không tương tác trên workspace mới, host có thể yêu cầu dùng --trust; tham số này có nghĩa là tin cậy workspace, không phải tắt cơ chế bảo mật.

WorkBuddy và CodeBuddy

Hai tên sản phẩm này gần giống nhau nhưng không phải cùng một host, vì vậy không được dùng chung thư mục cài đặt.

  • WorkBuddy: Sao chép vào ~/.workbuddy/skills/ hoặc .workbuddy/skills/ trong dự án; cũng có thể tải lên giao diện thư mục kỹ năng hoặc tệp zip có chứa SKILL.md.
  • CodeBuddy: Sao chép vào ~/.codebuddy/skills/ hoặc .codebuddy/skills/ trong dự án, sau đó gọi theo tên trong giao diện hoặc CLI.

Có thể tham khảo tài liệu WorkBuddy Skills và tài liệu CodeBuddy Skills chính thức.

DeepSeek Harness

Sao chép toàn bộ kỹ năng vào .dsh/skills/ của dự án, ~/.dsh/skills/ trong thư mục người dùng hoặc .agents/skills/, sau đó mở lại hoặc làm mới Harness. Dự án nêu rõ rằng dsh plugin add không phải cách cài đặt nội dung của các kỹ năng này.

Trước khi sử dụng, bạn cần tự chuẩn bị tài khoản hoặc API DeepSeek; dự án này không cung cấp khóa. Cơ chế cụ thể có thể tham khảo tài liệu DeepSeek Harness Skills.

Kimi Work

README đã xác minh thực tế phiên bản máy tính của Kimi Work, không phải Kimi Code CLI. Trong môi trường xác minh macOS, thư mục kỹ năng là:

~/Library/Application Support/kimi-desktop/daimon-share/daimon/skills/

Sau khi sao chép xong, nhập / trong giao diện Kimi Work để chọn kỹ năng. Đường dẫn này bắt nguồn từ thực tiễn cộng đồng; phía chính thức có thể còn cung cấp cách cài đặt bằng zip, Markdown, liên kết hoặc cửa hàng. Hãy căn cứ vào hướng dẫn hiện tại trên trang Kimi Skills chính thức.

千问办公 QwenWork

Sao chép thư mục kỹ năng vào:

~/.qwenworkcn/skills/

Sau đó sử dụng / trên ứng dụng máy tính để chọn kỹ năng hoặc gọi đích danh trong cuộc trò chuyện. 千问办公 và 通义灵码 không phải cùng một sản phẩm, không nên áp dụng chung một thư mục cài đặt. Có thể tham khảo tài liệu QwenWork Skills.

Grok Bot

Grok Bot không cài đặt bằng thư mục cục bộ. Mở SKILL.md của một kỹ năng, yêu cầu trong cuộc trò chuyện lưu nội dung này thành kỹ năng riêng tư, đồng thời sử dụng name và description ở đầu tệp. Cần lưu riêng từng kỹ năng trong bốn kỹ năng.

Khi lưu dispatch-accept-verify, bạn cũng phải dán mẫu dòng đăng ký của kỹ năng đó vào kỹ năng riêng tư. Phương thức này chỉ dành cho Grok Bot có khả năng lưu kỹ năng riêng tư, không có nghĩa các sản phẩm Grok khác có thể dùng cùng cấu hình.

Claude Code

Kho lưu trữ đã cung cấp .claude-plugin/plugin.json và cấu trúc marketplace, nhưng hiện vẫn ở trạng thái “đã chuẩn bị cấu trúc, đang bổ sung quy trình xác minh”, nên chưa thể xem là được hỗ trợ ngay từ đầu. Nếu tự thử nghiệm, hãy căn cứ vào phương thức cài đặt hiện tại trong tài liệu plugin chính thức của Claude Code.

Lần chạy đầu tiên: bắt đầu từ nhiệm vụ nhỏ

Đừng giao ngay một dự án phức tạp cho nhiều trợ lý. Trước tiên hãy chọn một nhiệm vụ nhỏ có kết quả dễ kiểm tra, chẳng hạn như sắp xếp biên bản cuộc họp dựa trên dữ liệu đầu vào được cung cấp. Dự án có ví dụ chính trong examples/ và tài liệu hướng dẫn đầy đủ tại examples/walkthrough-meeting-notes/, dùng để luyện tập quy trình “dữ liệu đầu vào được cung cấp, tạo kết quả, kiểm tra bằng chứng, con người nghiệm thu, trả lại để sửa đổi”.

Bước một: Viết rõ mục tiêu

Nêu cho trợ lý nội dung nhiệm vụ, vị trí kết quả, thời hạn giao và tiêu chuẩn hoàn thành. Có thể sử dụng cấu trúc lời nhắc sau:

请使用 dispatch-accept-verify 管理这项任务。
任务:根据给定输入整理会议记录。
成果位置:指定的工作区文件。
交付时间:约定时间。
完成标准:内容与输入一致,必要字段齐全,并可由我打开检查。
请先生成一行“待收”登记。

Bước hai: Đăng ký “đang chờ nhận”

Trước khi giao việc, hãy tạo dòng đăng ký, ít nhất phải nêu rõ trạng thái nhiệm vụ, ai đang thực hiện, ai chịu trách nhiệm tiếp nhận, ai kiểm tra khi đến hạn, kết quả được đặt ở đâu và giao khi nào. Khuyến nghị sao chép trực tiếp templates/task-register-line.md trong kho lưu trữ, không tự đoán các trường đầy đủ.

Bước ba: Ghi riêng việc nhận nhiệm vụ và nhận kết quả

Sau khi trợ lý thực thi xác nhận nhận nhiệm vụ, ghi nhận “đã nhận việc”. Chỉ sau khi tệp kết quả thực sự được trả về mới ghi nhận “đã nhận kết quả”. Hai trạng thái này không thể gộp làm một, vì “có người đồng ý thực hiện” không có nghĩa là “kết quả đã được bàn giao”.

Bước bốn: Đối chiếu bằng bằng chứng

Gọi evidence-before-done, yêu cầu trợ lý cung cấp bằng chứng tương ứng với phiên bản hiện tại để hỗ trợ kết luận hoàn thành.

Hãy dùng evidence-before-done để đối chiếu kết quả hiện tại.
Mở tệp cuối cùng và kiểm tra từng mục theo yêu cầu ban đầu.
Nếu có phần nào đã sửa đổi hoặc từng thất bại, hãy kiểm tra lại.
Hãy liệt kê bằng chứng, các mục chưa đáp ứng và kết luận đề xuất, đừng trực tiếp thay tôi phê duyệt.

Bằng chứng có thể đến từ việc kiểm tra nội dung sau khi mở tệp, đầu ra của lệnh, kết quả tính toán lại hoặc thực hiện lại toàn bộ thao tác ban đầu. Nếu kết quả bị sửa đổi sau khi kiểm tra, các phần bị ảnh hưởng phải được kiểm tra lại; những phần không thay đổi có thể sử dụng lại kết quả kiểm tra lần trước.

Bước năm: Con người nghiệm thu

Dựa trên bằng chứng để quyết định phê duyệt, trả lại hoặc thay đổi hướng đi. Chỉ sau khi con người xác nhận nghiệm thu đạt yêu cầu mới ghi nhận “đã nghiệm thu”. Nếu không đáp ứng yêu cầu, cần ghi rõ lý do trả lại, yêu cầu trợ lý thực thi sửa đổi, rồi thu thập bằng chứng lần nữa.

“Đã nhận kết quả” không phải là “đã nghiệm thu”. Chỉ khi bằng chứng phù hợp với kết quả hiện tại và con người đưa ra quyết định phê duyệt thì nhiệm vụ mới thực sự hoàn thành.

Thứ tự học đề xuất cho người mới bắt đầu

  1. Trước tiên đọc ví dụ chính trong examples/.
  2. Làm theo examples/walkthrough-meeting-notes/ để hoàn thành một nhiệm vụ nhỏ có bao gồm việc trả lại để sửa đổi.
  3. Chỉ học một mẫu: templates/task-register-line.md.
  4. Trước tiên dùng sổ tay hoặc bảng tính để luyện tập “chờ nhận → đã nhận việc → đã nhận kết quả → đã nghiệm thu”.
  5. Sau khi quen với phương pháp, hãy cài đặt kỹ năng vào một máy chủ Agent được hỗ trợ và gọi theo tên.

Bản thân phương pháp này không phụ thuộc vào năng lực lập trình phức tạp. Chỉ cần có thể viết rõ nhiệm vụ, sắp xếp người thực hiện và kiểm tra kết quả là có thể bắt đầu từ một bản ghi dùng chung.

Cách sử dụng nâng cao

Kết nối các trường đăng ký vào bảng hiện có

Nếu bạn đã sử dụng hệ thống nhiệm vụ, bảng tính điện tử hoặc bảng dự án, có thể kết nối các trường của dòng đăng ký vào quy trình hiện có. Điều quan trọng không phải là dùng công cụ nào, mà là bảo đảm các nhiệm vụ đang chờ nhận dễ dàng được nhìn thấy, đồng thời tách riêng các trạng thái nhận việc, nhận kết quả và hoàn tất nghiệm thu.

Phân định rõ trách nhiệm cho nhiều trợ lý

Gói kỹ năng cung cấp quy trình và cách viết; máy chủ chịu trách nhiệm mở phiên, chạy lệnh, đọc và ghi tệp, cùng các khả năng nhắc theo lịch hoặc gửi tin nhắn giữa các trợ lý nếu có. Con người chịu trách nhiệm đặt mục tiêu, quyết định mức độ ưu tiên, phê duyệt các hành động nguy hiểm và đưa ra phán đoán cuối cùng.

Khi xây dựng quy trình, có thể lần lượt kiểm tra:

  • Máy chủ có thể đồng thời mở nhiều phiên hoặc trợ lý con hay không.
  • Máy chủ có thể gửi tin nhắn giữa các trợ lý hay không.
  • Máy chủ có khả năng nhắc theo lịch hoặc đánh thức hay không.
  • Nếu không có nhắc tự động, ai sẽ kiểm tra thủ công đúng giờ.
  • Ai sẽ trực tiếp xác nhận nghiệm thu cuối cùng và các hành động nguy hiểm.

Chỉ kiểm tra lại phần bị ảnh hưởng

Sau khi kết quả được sửa đổi, không nhất thiết phải làm lại toàn bộ kiểm tra một cách không phân biệt. Có thể sử dụng lại bằng chứng của vòng trước đối với những phần không thay đổi, nhưng mọi phần đã sửa đổi, từng thất bại hoặc bị ảnh hưởng bởi sửa đổi đều phải được kiểm tra lại. Cách này giúp giảm công việc lặp lại mà vẫn duy trì độ tin cậy.

Dùng beginner-ops-writing để viết các bước thủ công

Với những khâu bắt buộc con người thực hiện như đăng nhập, thanh toán hoặc xác nhận chính chủ, có thể gọi beginner-ops-writing để chia nhỏ các bước, mỗi lần một hành động, đồng thời ghi rõ đối tượng thao tác và kết quả mong đợi. Khi liên quan đến hành động nguy hiểm, chỉ nhắc “vui lòng tự mình thực hiện”, không yêu cầu trợ lý tìm cách vượt qua ủy quyền của con người.

Dùng ops-case-notes để tổng kết

Khi xảy ra bỏ sót việc nhận, bỏ sót nghiệm thu hoặc lặp lại cùng một sai lầm, hãy tra cứu ops-case-notes. Khi ghi chép tổng kết, nên giữ lại thông tin ở cấp độ phương pháp: vấn đề thực tế, cách sửa đã áp dụng, kết quả thực tế và các hạn chế vẫn chưa được giải quyết; đồng thời loại bỏ thông tin liên hệ cá nhân, thông tin xác thực, đường dẫn nội bộ và thông tin máy.

Ranh giới tự động hóa bắt buộc phải biết

hooks: {} trong danh sách plugin của gói này có nghĩa là gói không cung cấp khả năng tự động đánh thức. Cài đặt kỹ năng chỉ có nghĩa là trợ lý có thể làm việc theo phương pháp này, không có nghĩa hệ thống sẽ tự động phân công, nhắc việc theo lịch, truyền tin giữa các phiên hoặc tự động gửi biên nhận.

  • Khi máy chủ có khả năng lập lịch, có thể dùng khả năng của máy chủ để kiểm tra đúng thời điểm.
  • Khi máy chủ không có khả năng lập lịch, con người cần kiểm tra đúng giờ.
  • Thông báo giữa các trợ lý, trò chuyện nhóm và việc đọc ghi tệp dùng chung phụ thuộc vào máy chủ.
  • Các hành động như chi tiền, đăng nhập, xác nhận thanh toán, gửi chính thức và xóa phải được con người phê duyệt.
  • Quyết định cuối cùng về việc nhận, trả lại hoặc thay đổi hướng đi luôn do con người đưa ra.

Khoảng mười phút được README đề cập chỉ là một trong các mục tiêu thiết kế, không được viết thành một bảo đảm đã được xác minh. Phép đo Cursor CLI hiện có được thực hiện trong điều kiện máy chủ đã cài đặt và đăng nhập, kho lưu trữ đã được lấy về, lời nhắc đã được chuẩn bị trước; thời gian từ lúc sao chép kỹ năng đến khi xuất ra dòng đăng ký khoảng 29.6 giây. Con số này không đại diện cho tổng thời gian người dùng mới cần để cài đặt máy chủ từ đầu và hoàn thành toàn bộ nhiệm vụ.

Cách xác định cài đặt đã thực sự thành công

Dự án đưa ra hai tiêu chuẩn cứng:

  1. Có thể cài đặt và gọi: Hoàn tất việc lấy về, cài đặt hoặc cấu hình, có thể gọi theo tên kỹ năng và tạo ra dòng đăng ký có thể kiểm tra.
  2. Có thể hoàn thành một nhiệm vụ nhỏ thực tế: Đi từ mục tiêu, phân công và bàn giao đến đối chiếu bằng chứng và phán đoán của con người, để lại kết quả thực tế, bằng chứng và kết luận nghiệm thu.

Hiện tại, tám máy chủ đều có một bản ghi nghiệm thu cho nhiệm vụ giới hạn, nhưng điều này không cấu thành bằng chứng về tính ổn định và cũng không chứng minh mọi nhiệm vụ đều có thể hoàn thành. Dự án chưa xác nhận bằng thí nghiệm đối chứng rằng tỷ lệ lỗi của cả đội đã giảm hoặc số lần nhắc việc đã giảm, vì vậy khi sử dụng vẫn cần duy trì sự giám sát của con người.

Kết luận

Giá trị của Solo to Team không nằm ở việc tạo ra một đội AI hoàn toàn tự động, mà ở việc cung cấp một phương pháp cộng tác rõ ràng, có thể kiểm tra và chuyển đổi. Trước tiên hãy cài đặt dispatch-accept-verify và evidence-before-done, luyện tập với một nhiệm vụ nhỏ theo trình tự “chờ nhận, nhận việc, nhận kết quả, đối chiếu bằng chứng, con người nghiệm thu”, rồi từng bước kết nối nhiều trợ lý và bảng hiện có. Dù sử dụng máy chủ nào, cũng nên tuân thủ cùng một nguyên tắc: trợ lý chịu trách nhiệm thực thi và cung cấp bằng chứng; con người chịu trách nhiệm về mục tiêu, ủy quyền và phán đoán cuối cùng.