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 quản trị, ngữ cảnh tổ chức và khả năng đo lường. Sản phẩm này được thiết kế cho các công ty vận hành môi trường kỹ thuật quy mô lớn hơn là cho nhà phát triển cá nhân hoặc nhóm nhỏ.

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

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

Hai tính năng đó đưa Copilot từ “tự động hoàn thành thông minh” trở thành một nền tảng AI kỹ thuật nội bộ thực thụ.

Những công ty tận dụng được nhiều giá trị nhất từ GitHub Copilot Enterprise xem nó như một thành phần trọng yếu của hạ tầng nội bộ. Họ cấu hình ngữ cảnh tổ chức cẩn trọng, đ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 thay vì giả định.

Để có cái nhìn rộng hơn về hệ sinh thái của GitHub, tôi khuyến nghị đọ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ị
• Kế thừa chính sách trên toàn doanh nghiệp
• Phân bổ yêu cầu cao cấp lớn hơn (1.000 so với 300 ở tầng Business)
• Truy cập và quản lý mô hình bổ sung

Enterprise yêu cầu GitHub Enterprise Cloud bên cạnh chính đăng ký Copilot Enterprise. Điều này làm tăng chi phí mỗi người dùng, vì vậy hãy đảm bảo tổ chức của bạn thực sự cần quản trị, telemetry và quản trị 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 truy cập thêm 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 nhắm đến 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 bao gồm:

• Các tổ chức kỹ thuật lớn
• Ngành nghề được quản lý chặt chẽ
• Nhóm kỹ thuật nền tảng đa nhóm
• Công ty có tiêu chuẩn phát triển nội bộ
• Tổ chức yêu cầu 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 nghĩ khác biệt này quan trọng vì nhiều nhóm ban đầu mua vượt nhu cầu. Họ cho rằng 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 dùng chung.

Mặc định, Copilot hiểu khá tốt kiến 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 viết mã, quy trình triển khai hay tài liệu onboard của bạn.

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

Trên thực tế, Spaces giúp Copilot trả lời các câu hỏi như:

• “Nội bộ chúng ta cấu trúc bộ xử lý API 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 đời cũ.

Các loại nội dung được hỗ trợ bao 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 theo cách khác nhau.

Tệp mã giúp Copilot hiểu các mẫu triển khai. Tệp Markdown cung cấp giải thích kiến trúc và hướng dẫn onboard. Pull request phơi bày thảo luận review và các quyết định kỹ thuật trong quá khứ. 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ới 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 đã ngừng tính năng Copilot Knowledge Bases cũ vào ngày 1 tháng 11 năm 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ý cấp tổ chức linh hoạt hơn

Bạn vẫn có thể thấy tài liệu và bài blog lỗi thời nhắc đến Knowledge Bases. Hãy cẩn trọng khi làm theo 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ề mặt 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 nhóm.

Cấu trúc bạn chọn ban đầu thường sẽ gắn bó lâu dài. Tôi từng thấy các tổ chức vô tình tạo ra “sự bùng phát 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, vì vậy hãy thử tạo một cái trong repo cá nhân của chúng ta. 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 đến trang Copilot Spaces trong khu vực quản trị Enterprise
2. Tạo 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. Thêm nguồn nội dung bằng cách nhấp nút “+ Add sources” ở 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 trò chuyện

Lưu ý cho người dùng doanh nghiệp: quản trị viên của bạn có thể tắt việc chia sẻ Spaces cá nhân. Vì vậy, nếu bạn đang dùng tài khoản riêng, điều này có thể ảnh hưởng đến khả năng chia sẻ Copilot Space không sử 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 prompt 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 thể 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 cấp tổ chức

Thành viên của một enterprise có thể để các space cá nhân của họ được quản lý bởi cài đặt enterprise tổng. 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 các nhóm thử nghiệm hoặc sáng kiến nội bộ nhạy cảm. Spaces cấp tổ chức phù hợp với tiêu chuẩn kỹ thuật, tài liệu onboard hoặc khung làm việc 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 nhiễu và khó để Copilot sử dụng hiệu quả.

Tổ chức Spaces theo nhóm hoặc theo miền

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

Các mẫu phổ biến gồm mỗi nhóm một space, mỗi mảng sản phẩm một space hoặc các space tiêu chuẩn dùng chung. Mỗi mẫu có phạm vi khác nhau và về cơ bản dùng phần cài đặt Space theo cách khác nhau.

Mỗi nhóm một Space

Hữu ích khi các nhóm kỹ thuật vận hành 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ỗi mảng sản phẩm một Space

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 viết mã
• Quy trình triển khai
• Tiêu chuẩn kiến trúc

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

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 đợt hợp nhất API năm 2026. 

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

Bảng điều khiển đạt trạng thái sẵn sà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 lường 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
• Số dòng mã được đề xuất so với số dòng mã được chấp nhận
• Mẫu sử dụng IDE
• 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 một bức tranh tinh tế hơn nhiều so với chỉ đếm chỗ ngồi.

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

Chuyển đổi 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 chuyển tiếp 2025–2026, và hoàn tất vào tháng 4 năm 2026.

Bao gồm:

• Metrics API cũ
• Feature Engagement APIs
• Direct Data Access APIs

Các endpoint Usage Metrics mới, có từ tháng 2 năm 2026, đã hợp nhất các hệ thống báo cáo đó thành một mô hình thống nhất hơn, đồng thời phiên bản hóa API trong trường hợp có thay đổi phá vỡ tương thích.

Điều này quan trọng vì nhiều bài blog và ví dụ GitHub cũ vẫn tham chiếu các endpoint đã ngừng hỗ trợ. Bất cứ khi nào làm việc với Usage Metrics API, hãy luôn kiểm tra tài liệu so với 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 bàn về cách sử dụng thực tế.

Xác thực và quyền

Các endpoint GitHub Copilot Usage Metrics thường yêu cầu bạn thiết lập một số quyền cho Personal Access Token (PAT). Có thể dùng PAT cổ điển hoặc PAT 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 truy cập chi tiết, bạn cần đảm bảo đang dùng GitHub app user access token hoặc installation access token với quyền Enterprise Copilot metrics enterprise permissions (read).

Thông thường, ưu tiên dùng token 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 một ngày cấp tổ chức

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ó sẵn từ ngày 10/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 về các báo cáo sử dụng. Bạn cần đảm bảo chèn YOUR_TOKEN cho bearer auth và chọn một DAY cho ngày cụ thể của báo cáo theo đị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à có thời hạn, nghĩa là chúng sẽ hết hạn không lâu sau khi lấy. 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 28 ngày cấp tổ chức

Báo cáo 28 ngày giúp nhận diện 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ả báo cáo 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 cho bạn cái nhìn tổng quan ở mức cao về người dùng trong một tổ chức cụ thể, nhóm của họ và thẻ nhóm. 

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. Điều này có nghĩa bạn có thể hiểu cá nhân đang 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 nhận diện:

• Người dùng hoạt động cao
• Những nhóm 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úng chỉ trỏ tới API khác.

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

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 28 ngày cấp người dùng

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 một ngày cấp user-teams

Cũng có endpoint user-teams-1-day, ánh xạ mỗi người dùng tới các nhóm mà họ là thành viên. 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 nhóm.

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ỏ đến 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
}]

Những chỉ số này có giá trị nhất như tín hiệu áp dụng ở cấp nhóm. 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.

Để biết đầy đủ các chỉ số tiềm năng bạn có thể thấy, hãy truy ccập tài liệu dữ liệu usage metrics của GitHub để có các chỉ số đo lường cập nhật 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 nhóm 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 trình bày 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ó tính hành động, tốt hơn là tạo một quy trình tự động.

Những nhóm tận dụng Copilot Enterprise tốt nhất thường xây dựng pipeline báo cáo gọn nhẹ, kết hợp telemetry sử dụng với các 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 gồm:

• Tăng trưởng người dùng hoạt động
• Xu hướng tỷ lệ chấp nhận
• Mã được đề xuất 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 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 nhóm và quy trình, đó chính là lý do Usage Metrics API tồn tại. Nhóm hạ tầng backend có thể tương tác với Copilot khác với nhóm frontend làm prototype.

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

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

1. Lên 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 stack quan trọng ít hơn tính nhất quán.

Ngay cả quy trình đơn giản dùng script Python theo lịch và xuất CSV cũng có thể mang lại 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 / Spreadsheet

  ↓

Power BI / Tableau / Looker

Kết luận

GitHub Copilot Enterprise thực chất là xây dựng hạ tầng sẵn sàng cho mã hóa bằ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 liệ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 việ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 cho rằng năng suất tăng

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

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