GitHub Copilot Enterprise: Hướng dẫn về Spaces và Usage Metrics API

GitHub Copilot Enterprise là gì?

GitHub Copilot Enterprise nằm ở cấp cao nhất trong hệ phân cấp gói Copilot của GitHub.

So với GitHub Copilot Business hoặc Pro+, Enterprise tập trung mạnh vào khả năng quản trị, ngữ cảnh tổ chức, và đo lường. Nó được thiết kế cho các công ty vận hành môi trường kỹ thuật lớn thay vì nhà phát triển cá nhân hoặc đội nhỏ.

Hai khả năng quan trọng nhất trong thực tế:

1. Ngữ cảnh tùy chỉnh cấp tổ chức thông qua Spaces
2. Telemetry trên toàn tổ chức thông qua Usage Metrics API

Hai tính năng này chuyển Copilot từ “tự động hoàn thành thông minh” thành một nền tảng AI kỹ thuật nội bộ.

Những công ty tận dụng tốt nhất GitHub Copilot Enterprise coi nó như một thành phần hạ tầng nội bộ chủ chốt. Họ cấu hình ngữ cảnh tổ chức cẩn thận, đo lường mức độ áp dụng liên tục, và điều chỉnh chính sách dựa trên dữ liệu sử dụng chứ không phải giả định.

Để có cái nhìn rộng hơn về hệ sinh thái GitHub, tôi khuyên bạn đọc hướng dẫn Giới thiệu về các sản phẩm GitHub của chúng tôi.

Enterprise khác gì so với Business và Pro+

GitHub Copilot Enterprise mở rộng gói Business với các tính năng bổ sung như:

• Chỉ số sử dụng ở cấp tổ chức
• Mở rộng kiểm soát quản trị
• Thừa kế chính sách trên toàn doanh nghiệp
• Hạn ngạch yêu cầu cao cấp lớn hơn (1.000 so với 300 ở tầng Business)
• Quyền truy cập và quản lý mô hình bổ sung

Enterprise yêu cầu GitHub Enterprise Cloud ngoài đăng ký Copilot Enterprise. Điều này làm phát sinh chi phí bổ sung theo người dùng, nên hãy đảm bảo tổ chức của bạn thực sự cần quản trị, telemetry, và quản lý cấp doanh nghiệp.

Lưu ý: Người đăng ký Business truy cập Usage Metrics API ở cấp tổ chức (/orgs/{org}/…). Người đăng ký Enterprise còn truy cập báo cáo tổng hợp cấp doanh nghiệp (/enterprises/{enterprise}/…) bao quát tất cả tổ chức trong một chế độ xem.

GitHub Copilot Enterprise dành cho ai

GitHub Copilot Enterprise hướng tới các tổ chức đã vận hành môi trường GitHub trưởng thành.

Khách hàng Enterprise điển hình gồm:

• Tổ chức kỹ thuật quy mô lớn
• Ngành được quản lý chặt chẽ
• Nhóm kỹ thuật nền tảng đa đội
• Công ty có tiêu chuẩn phát triển nội bộ
• Tổ chức cần quản trị tập trung

Lưu ý rằng điều này không tự động cải thiện hiệu năng của Copilot. Tôi cho rằng khác biệt này quan trọng vì nhiều đội ban đầu mua quá mức. Họ mặc định Enterprise đồng nghĩa với “Copilot tốt hơn”, trong khi thực tế Enterprise chủ yếu bổ sung công cụ quản trị và đo lường.

Copilot Spaces: Ngữ cảnh tùy chỉnh cho tổ chức của bạn

Copilot Spaces giải quyết một trong những điểm yếu lớn nhất của các trợ lý mã hóa AI tổng quát.

Mặc định, Copilot hiểu tương đối tốt tri thức lập trình công khai. Nó không tự động hiểu API nội bộ, quyết định kiến trúc, quy ước mã hóa, quy trình triển khai, hay tài liệu onboarding của bạn.

Spaces cung cấp ngữ cảnh đã được tuyển chọn của tổ chức để Copilot tham chiếu trong hội thoại và hỗ trợ mã hóa.

Về thực tiễn, Spaces giúp Copilot trả lời các câu hỏi như:

• “Chúng ta cấu trúc trình xử lý API nội bộ như thế nào?”
• “Nhóm nền tảng của chúng ta khuyến nghị thư viện xác thực nào?”
• “Microservice này nên dùng quy trình triển khai nào?”
• “Nhóm backend của chúng ta theo quy ước đặt tên nào?”

Những gì Spaces hỗ trợ

Spaces hỗ trợ phạm vi nội dung tổ chức rộng hơn hệ thống Knowledge Bases cũ.

Các loại nội dung được hỗ trợ gồm:

• Tệp mã
• Tài liệu Markdown
• Tệp JSON
• Tệp tải lên
• Hình ảnh
• GitHub Issues
• Pull request

Mỗi loại nội dung đóng góp khác nhau.

Tệp mã giúp Copilot hiểu các mẫu triển khai. Tệp Markdown cung cấp diễn giải kiến trúc và hướng dẫn onboarding. Pull request phơi bày thảo luận review và quyết định kỹ thuật lịch sử. Sự kết hợp đó giúp Copilot nhận thức tốt hơn về thực hành phát triển của tổ chức bạn.

Một điểm tinh tế nhưng quan trọng là Spaces không chỉ đơn thuần là cơ sở dữ liệu vector gắn vào GitHub. Chúng bao gồm kiểm soát chia sẻ và quy trình quản trị tổ chức được thiết kế cho môi trường doanh nghiệp.

Kết thúc vòng đời Knowledge Bases

GitHub đã kết thúc tính năng Copilot Knowledge Bases cũ vào ngày 1 tháng 11, 2025.

Spaces thay thế Knowledge Bases với:

• Hỗ trợ nội dung rộng hơn
• Kiểm soát chia sẻ tốt hơn
• Cải thiện quản trị
• Quản lý linh hoạt hơn ở cấp tổ chức

Bạn vẫn sẽ thấy tài liệu và bài viết blog lỗi thời đề cập tới Knowledge Bases. Hãy cẩn thận khi theo các hướng dẫn cũ vì nhiều endpoint và quy trình đã thay đổi trong giai đoạn chuyển tiếp 2025–2026.

Tạo và cấu hình Copilot Spaces

Về góc độ quản trị, Copilot Spaces khá đơn giản để tạo. Thách thức nằm ở việc quản lý hàng chục hoặc hàng trăm space trên nhiều đội.

Cấu trúc bạn chọn từ sớm thường sẽ gắn chặt. Tôi từng thấy các tổ chức vô tình tạo “sự lan rộng tài liệu” trong Spaces vì không ai thiết lập quy tắc sở hữu ngay từ đầu.

Bất kỳ ai cũng có thể tạo Copilot Space, nên hãy thử tạo một cái trong repo cá nhân của bạn. Các bước này tương tự ở cấp Enterprise, chỉ khác một vài trang.

Thiết lập một Space

Tạo một Space thường theo quy trình sau:

1. Đi tới trang Copilot Spaces trong khu vực quản trị Enterprise
2. Tạo một Space mới

3. Chọn repository và nguồn nội dung, bao gồm MCP và các công cụ hữu ích khác

4. Việc thêm nguồn có thể được thực hiện bằng cách nhấp nút “+ Add sources” ở phía bên phải

5. Bạn có thể chọn chia sẻ space hoặc thiết lập cài đặt chia sẻ ở bước này

6. Xác minh Copilot có thể tham chiếu nội dung trong các tương tác chat

Lưu ý cho người dùng doanh nghiệp: quản trị viên có thể tắt chia sẻ Spaces cá nhân. Vì vậy nếu bạn dùng tài khoản riêng, điều đó có thể ảnh hưởng đến khả năng chia sẻ Copilot Space không dùng repository của doanh nghiệp.

Sau khi thiết lập, quản trị viên nên kiểm thử Space bằng các lời nhắc thực tế.

Ví dụ:

How does our authentication middleware handle token refresh logic?

Hoặc:

Show me an example of how our backend services structure database migrations.

Nếu Copilot không trả lời chính xác, vấn đề thường là một trong các nguyên nhân sau:

• Thiếu repository
• Chất lượng tài liệu kém
• Phân quyền không đúng
• Chưa đủ thời gian lập chỉ mục

Chia sẻ và kiểm soát truy cập

Spaces hỗ trợ hai mô hình hiển thị chính:

• Spaces cá nhân
• Spaces toàn tổ chức

Thành viên của một enterprise có thể có các space cá nhân được quản lý bởi cài đặt enterprise lớn hơn. Quản trị viên enterprise cũng có thể quản lý tập trung các chính sách xem trước và khả dụng tính năng. 

Spaces riêng tư phù hợp với đội ngũ thử nghiệm hoặc sáng kiến nội bộ nhạy cảm. Spaces toàn tổ chức phù hợp cho tiêu chuẩn kỹ thuật, tài liệu onboarding, hoặc các framework dùng chung toàn công ty.

Một sai lầm thường gặp là tập trung hóa quá mức. Một Space khổng lồ cho toàn công ty có thể trở nên ồn ào và khó để Copilot sử dụng hiệu quả.

Tổ chức Spaces theo đội hoặc theo miền nghiệp vụ

Không có cấu trúc tổ chức nào đúng cho mọi trường hợp.

Mẫu phổ biến gồm một space cho mỗi đội, một space cho mỗi khu vực sản phẩm, hoặc các space chuẩn dùng chung. Mỗi mẫu có phạm vi khác nhau và cơ bản là dùng cùng cài đặt theo cách khác.

Một Space cho mỗi đội

Hữu ích khi các nhóm kỹ thuật hoạt động tương đối độc lập.

Ví dụ:

• Kỹ thuật nền tảng
• Kỹ thuật dữ liệu
• Phát triển di động

Một Space cho mỗi khu vực sản phẩm

Hữu ích cho tổ chức cấu trúc xoay quanh sản phẩm hơn là phòng ban.

Ví dụ:

• Thanh toán
• Phân tích
• Hạ tầng
• Nền tảng khách hàng

Space tiêu chuẩn dùng chung

Nhiều tổ chức duy trì một Space dùng chung riêng cho:

• Hướng dẫn bảo mật
• Quy ước mã hóa
• Quy trình triển khai
• Tiêu chuẩn kiến trúc

Trong thực tế, cách tiếp cận lai thường hiệu quả nhất. Mỗi đội có thể có space riêng, đồng thời các space chuẩn lớn hơn được chia sẻ giữa các đội.

Copilot Usage Metrics API

Spaces giải quyết bài toán ngữ cảnh. Usage Metrics API giải quyết bài toán đo lường. Nó thay thế một số hệ thống telemetry cũ mà GitHub đã loại bỏ trong quá trình hợp nhất API năm 2026. 

Không có đo lường rõ ràng, các tổ chức sẽ nhanh chóng mất tầm nhìn về việc áp dụng Copilot có thành công hay không. Ban lãnh đạo muốn bằng chứng rằng khoản đầu tư này cải thiện quy trình làm việc của nhà phát triển chứ không chỉ thêm một mục phí đăng ký.

Bảng điều khiển đã đạt mức khả dụng chung vào tháng 2 năm 2026 và có thể truy cập qua tài khoản enterprise của bạn → AI Controls → Copilot → Metrics → Copilot usage metrics trong thẻ Insights.

Ví dụ bảng điều khiển Copilot Usage Metrics từ github.blog

API đo những gì

Usage Metrics API cung cấp nhiều hạng mục telemetry vận hành.

Các chỉ số phổ biến gồm:

• Người dùng hoạt động
• Dòng mã được gợi ý so với dòng mã được chấp nhận
• Mẫu sử dụng IDE
• Việc sử dụng mô hình
• Tương tác với agent
• Phân tách theo ngôn ngữ

Điều này cho tổ chức bức tranh tinh tế hơn nhiều so với số ghế đơn thuần.

Một đội có 100 ghế được phân bổ nhưng chỉ 15 người dùng hoạt động có hồ sơ áp dụng rất khác so với đội có mức sử dụng hàng ngày ổn định và tỷ lệ chấp nhận cao.

Giai đoạn chuyển API năm 2026

GitHub đã loại bỏ nhiều API telemetry trước đó (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) trong giai đoạn 2025–2026, và dừng hẳn vào tháng 4 năm 2026.

Bao gồm:

• Legacy Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

Các endpoint Usage Metrics mới, khả dụng từ tháng 2 năm 2026, đã hợp nhất các hệ thống báo cáo đó vào một mô hình thống nhất hơn, bao gồm cả việc version hóa API khi có thay đổi phá vỡ tương thích.

Điều này quan trọng vì nhiều bài viết blog và ví dụ trên GitHub cũ vẫn tham chiếu endpoint đã ngừng dùng. Bất cứ khi nào làm việc với Usage Metrics API, hãy luôn xác minh tài liệu theo tham chiếu API mới nhất của GitHub trước khi xây dựng tự động hóa xung quanh nó.

Truy vấn Usage Metrics API

Giờ khi đã hiểu mục đích của usage metrics API, hãy nói về cách chúng ta thực sự sử dụng nó trong thực tế.

Xác thực và phân quyền

Các endpoint GitHub Copilot Usage Metrics thường yêu cầu bạn thiết lập một vài quyền cho Personal Access Token (PAT). Điều này có thể thực hiện qua PAT cổ điển hoặc PAT phân quyền chi tiết.

• Với PAT cổ điển, bạn cần quản trị viên enterprise cấp các quyền: manage_billing:copilot và read:org. 

• Với token phân quyền chi tiết, bạn cần đảm bảo dùng GitHub app user access token hoặc installation access token với bộ quyền Enterprise Copilot metrics enterprise permissions (read).

Thông thường, ưu tiên dùng token phân quyền chi tiết vì chúng giảm phơi bày quyền không cần thiết.

Endpoint cấp tổ chức

Hai báo cáo cấp tổ chức phổ biến nhất là:

• organization-1-day

• organization-28-day

Báo cáo cấp tổ chức một ngày

Báo cáo một ngày phù hợp cho giám sát vận hành và phân tích xu hướng ngắn hạn. Dữ liệu lịch sử có từ ngày 10 tháng 10, 2025, và có thể truy cập trong tối đa một năm kể từ ngày hiện tại.

Lệnh curl dưới đây sẽ gọi API báo cáo một ngày và trả về phản hồi JSON với liên kết tải xuống báo cáo sử dụng. Bạn cần đảm bảo bao gồm YOUR_TOKEN cho bearer auth và chọn một DAY cho ngày cụ thể bạn muốn ở định dạng YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

Các URL trong download_links được ký và giới hạn thời gian, nghĩa là chúng sẽ hết hạn ngay sau khi truy xuất. Quy trình của bạn phải lấy URL tải xuống và lập tức kéo tệp trong cùng một lượt chạy; bạn không thể lưu các URL này để dùng sau.

Phản hồi bạn nhận có thể chỉ chứa download_links và report_day, nhưng đây là schema đầy đủ có thể có:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

Báo cáo cấp tổ chức 28 ngày

Báo cáo 28 ngày giúp xác định các mẫu áp dụng rộng hơn và thay đổi sử dụng dài hạn. Các lệnh rất giống nhau, chỉ thay đổi nhỏ để dùng API 28 ngày.

Yêu cầu ví dụ:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Bạn sẽ nhận phản hồi tương tự, ngoại trừ sẽ có response_start_day và response_end_day.

Cấu trúc báo cáo cấp tổ chức

Các báo cáo JSON cho cả một ngày và 28 ngày cấp tổ chức có thể trông như sau:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Như bạn thấy, điều này cung cấp cái nhìn tổng quan cấp cao về người dùng trong một tổ chức cụ thể, đội của họ và thẻ đội của họ. 

Endpoint cấp người dùng

Báo cáo cấp người dùng cung cấp khả năng quan sát mức độ áp dụng chi tiết hơn. Nghĩa là bạn có thể hiểu cá nhân sử dụng Copilot như thế nào ở mức rất cao.

Các endpoint phổ biến gồm:

• users-1-day

• users-28-day

• user-teams-1-day

Các báo cáo này giúp quản trị viên xác định:

• Người dùng hoạt động cao
• Đội có mức áp dụng thấp
• Cơ hội đào tạo
• Xu hướng sử dụng cấp phòng ban

Các yêu cầu này rất giống với báo cáo một ngày và 28 ngày cấp tổ chức; chỉ khác là trỏ đến API khác.

Báo cáo cấp người dùng một ngày

Ví dụ gọi API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

Báo cáo cấp người dùng 28 ngày

Ví dụ gọi API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Báo cáo cấp user-teams một ngày

Cũng có endpoint user-teams-1-day, ánh xạ mỗi người dùng tới các nhóm họ tham gia. Nó không chứa chỉ số sử dụng; mục đích là làm khóa nối khi bạn muốn tổng hợp dữ liệu theo người dùng theo đội.

Cấu trúc báo cáo cấp người dùng

Mức độ chi tiết trong các báo cáo này cao hơn nhiều, vì chúng trỏ tới dữ liệu sử dụng của một người dùng cụ thể:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Các chỉ số này có giá trị nhất như các tín hiệu áp dụng ở cấp đội. Tỷ lệ chấp nhận và số lần sử dụng là tín hiệu vận hành, không phải thước đo chất lượng nhà phát triển.

Để xem đầy đủ các chỉ số tiềm năng bạn có thể gặp, hãy truy cập tài liệu dữ liệu chỉ số sử dụng của GitHub để cập nhật mới nhất.

Các báo cáo cấp người dùng bao gồm dữ liệu tương tác CLI. Nếu đội của bạn dùng Copilot qua dòng lệnh, Hướng dẫn GitHub Copilot CLI của chúng tôi đề cập setup và các quy trình làm việc phổ biến.

Xây dựng quy trình báo cáo cho Copilot

Gọi API thủ công hữu ích cho thử nghiệm và hiểu schema. Để có thể hành động, tốt hơn là tạo một quy trình tự động.

Những đội tận dụng tốt nhất Copilot Enterprise thường xây dựng các pipeline báo cáo gọn nhẹ kết hợp telemetry sử dụng với chỉ số kỹ thuật nội bộ.

Chỉ số then chốt để chứng minh ROI

Không phải chỉ số Copilot nào cũng quan trọng như nhau. Những chỉ số hữu ích nhất thường bao gồm:

• Tăng trưởng người dùng hoạt động
• Xu hướng tỷ lệ chấp nhận
• Mã được gợi ý so với mã được giữ lại
• Cải thiện thời gian vòng đời PR
• Tần suất tương tác với IDE

GitHub đã công bố các benchmark như:

• Hoàn thành tác vụ nhanh hơn 55%
• Tỷ lệ giữ lại mã 88%

Những con số đó cho thấy cải thiện năng suất đáng kể. Kết quả của bạn sẽ khác nhau theo đội và quy trình, đó chính là lý do Usage Metrics API tồn tại. Một đội hạ tầng backend có thể tương tác với Copilot khác với một đội prototyping frontend.

Từ dữ liệu thô đến bảng điều khiển đội

Một quy trình báo cáo gọn nhẹ thường như sau:

1. Lập lịch gọi API
2. Lưu phản hồi vào cơ sở dữ liệu hoặc bảng tính
3. Chuyển đổi dữ liệu thành bảng báo cáo
4. Trực quan hóa chỉ số trong nền tảng BI hiện có

Bản thân công nghệ không quan trọng bằng tính nhất quán.

Ngay cả một quy trình đơn giản dùng script Python theo lịch và xuất CSV cũng có thể cung cấp khả năng quan sát vận hành hữu ích.

Kiến trúc ví dụ:

GitHub API

  ↓

Script Python theo lịch

  ↓

PostgreSQL / CSV / Bảng tính

 ↓

Power BI / Tableau / Looker

Lời kết

GitHub Copilot Enterprise thực chất là xây dựng hạ tầng của bạn cho mã sẵn sàng AI. Spaces cung cấp ngữ cảnh tổ chức giúp Copilot hữu ích hơn trong môi trường kỹ thuật thực tế. Usage Metrics API cung cấp telemetry cần thiết để hiểu việc áp dụng có thành công hay không.

Những tổ chức đạt kết quả mạnh mẽ nhất với Copilot Enterprise thường có mẫu số chung:

• Họ tuyển chọn ngữ cảnh nội bộ cẩn thận
• Họ theo dõi mức áp dụng liên tục
• Họ coi trọng quản trị Copilot
• Họ đo lường kết quả thay vì mặc định có tăng năng suất

Tư duy đó quan trọng hơn nhiều so với việc chỉ phân bổ ghế.

Nếu bạn muốn nâng cao kỹ năng về Copilot và AI, tôi khuyên bạn tham gia khóa học Software Development with GitHub Copilot hoặc lộ trình kỹ năng đầy đủ AI for Software Engineering.