Chuyển tới nội dung chính

Cách xây plugin Cowork từ đầu (Hướng dẫn 2026)

· 6 phút để đọc
Claude Dev
Claude Dev
Claude Dev

Nếu bạn muốn Cowork thật sự làm việc giúp mình, plugin chính là đòn bẩy lớn nhất.

Tính đến 2026-02-28, lộ trình chính thức đã khá rõ:

  • Anthropic giới thiệu Cowork vào 2026-01-14
  • Công bố tạo/chia sẻ plugin tùy chỉnh vào 2026-01-20
  • Cập nhật plugin directory cho doanh nghiệp vào 2026-02-24
  • Cập nhật tài liệu trợ giúp plugin vào 2026-02-25

Bài này kết hợp luồng chính thức với kinh nghiệm thực tế từ cộng đồng để bạn xây plugin đầu tiên từ con số 0.

Plugin Cowork nên làm gì trước tiên?​

Plugin đầu tiên tốt nhất nên giải quyết một nhiệm vụ hẹp và lặp lại.

Ý tưởng chưa tốt:

  • “Làm toàn bộ chiến lược marketing cho tôi”

Ý tưởng tốt hơn:

  • “Biến ghi chú họp thành action items hàng tuần có owner và deadline”
  • “Tóm tắt log sự cố và xuất bảng phân loại rủi ro”
  • “Đánh giá hồ sơ ứng viên và trả về scorecard có cấu trúc”

Trước khi build, hãy viết hợp đồng 1 dòng:

Input: bạn đưa vào gì.
Output: plugin phải trả về gì mỗi lần.

Nếu chưa viết rõ được dòng này, prompt sẽ rất dễ trôi.

Bước 1) Tạo khung plugin trong Cowork​

Trong Cowork, vào khu vực plugin và tạo plugin mới.

Theo tài liệu/hỗ trợ chính thức, bạn thường có thể:

  • Tạo từ đầu trong UI Cowork
  • Import từ file local
  • Cài từ plugin directory (plugin có sẵn)

Với lần đầu, hãy chọn tạo từ đầu để hiểu từng thiết lập.

Bước 2) Tên và mô tả: độ chính xác kích hoạt bắt đầu từ đây​

Nhiều builder trong cộng đồng cho biết việc plugin có được chọn đúng hay không phụ thuộc lớn vào tên và mô tả.

Mẫu nên dùng:

  • Tên: vai trò cụ thể (Incident Triage Reporter)
  • Mô tả: trigger + phạm vi (Dùng khi người dùng muốn phân loại sự cố từ log thô thành mức độ nghiêm trọng, owner và bước tiếp theo.)

Tránh mô tả mơ hồ như “general assistant plugin”.

Vì sao quan trọng:

  • Cowork phải quyết định khi nào plugin của bạn phù hợp
  • Mô tả mơ hồ gây gọi sai plugin hoặc không gọi

Bước 3) Viết prompt contract chặt chẽ​

Hướng dẫn plugin nên giống runbook sản xuất.

Cấu trúc tối thiểu nên có:

  1. Vai trò và mục tiêu
  2. Input bắt buộc
  3. Định dạng output (phần cố định/bảng/cấu trúc kiểu JSON)
  4. Quy tắc quyết định và ưu tiên
  5. Biên an toàn và cách xử lý khi không chắc chắn

Ví dụ skeleton:

You are Incident Triage Reporter.

Goal:
- Convert raw incident notes into a priority triage report.

Required inputs:
- incident_log
- service_name
- report_time

Output format:
- Severity: P0/P1/P2/P3
- Impact summary (max 3 bullets)
- Suspected root cause
- Immediate next action
- Owner recommendation

Rules:
- If evidence is weak, state uncertainty explicitly.
- Never invent metrics not present in input.
- Ask one clarifying question if critical context is missing.

Bài học cộng đồng: prompt ngắn và có ràng buộc thường ổn định hơn prompt dài kiểu “làm mọi thứ”.

Bước 4) Thiết kế cho output dễ dự đoán, không phải output “sáng tạo”​

Nếu plugin nằm trong workflow, tính nhất quán quan trọng hơn văn phong.

Checklist thực tế:

  • Đồng đội có thể đọc nhanh output trong 10 giây không?
  • Automation phía sau có parse được không?
  • Format có ổn định qua 5 input rất khác nhau không?

Nếu chưa, hãy siết chặt hướng dẫn và thu hẹp phạm vi.

Bước 5) Test edge case thật trước khi chia sẻ​

Đừng chỉ test dữ liệu đẹp.

Tối thiểu chạy 5 nhóm test:

  1. Input sạch và đầy đủ
  2. Thiếu trường quan trọng
  3. Dữ liệu mâu thuẫn
  4. Input dài/nhiễu
  5. Input nằm ngoài phạm vi plugin

Hành vi mong đợi cho #5: từ chối rõ ràng + gợi ý hướng xử lý khác.

Bước 6) Chia sẻ an toàn trong workspace​

Lộ trình plugin cho team trong tài liệu chính thức nhấn mạnh chia sẻ có kiểm soát và quản trị workspace.

Trước khi publish nội bộ:

  • Thêm mục “Khi nào dùng / Khi nào không dùng”
  • Thêm ví dụ input/output
  • Gán owner và kỳ vọng bảo trì
  • Version prompt (v0.1, v0.2...) kèm changelog ngắn

Điều này tránh tình trạng plugin trở thành “hộp đen” sau vài tuần.

Bước 7) Lặp lại dựa trên tín hiệu sử dụng thật​

Sau khi phát hành, xem lại log sử dụng hàng tuần:

  • Chất lượng kích hoạt (được gọi đúng lúc không?)
  • Tỷ lệ sửa output (người dùng phải sửa lại bao nhiêu)
  • Mẫu lỗi (thiếu ngữ cảnh, giả định sai)

Mỗi vòng chỉ chỉnh một biến:

  • Câu chữ mô tả
  • Một quy tắc trong prompt
  • Schema output

Chỉnh nhỏ có kiểm soát thường tốt hơn viết lại toàn bộ.

Nên tin nguồn nào hơn: official hay community?​

Thứ tự ưu tiên nên là:

  1. Tài liệu sản phẩm + hỗ trợ Cowork chính thức (hành vi tính năng, quyền, rollout)
  2. Tutorial/reference plugin chính thức (format và chi tiết triển khai)
  3. Ví dụ cộng đồng (tốt cho edge case và mẹo thực dụng)

Nguồn cộng đồng rất hữu ích, nhưng có thể cũ nhanh khi Cowork cập nhật liên tục.

Kết luận​

Plugin Cowork đầu tiên của bạn nên “đơn giản, hẹp phạm vi, và đáng tin cậy”.

Nếu làm đúng 3 điểm này:

  • mô tả trigger rõ ràng
  • hợp đồng output chặt chẽ
  • test case có kỷ luật

…bạn sẽ có hiệu quả rõ rệt sớm, và plugin thứ hai sẽ dễ hơn rất nhiều.

Nguồn tham khảo (kiểm tra ngày 2026-02-28)​

Official​

Community​