Cloudflare ứng dụng AI để tự động hóa và thực thi tiêu chuẩn kỹ thuật

Trong bốn tháng qua, AI đánh giá mã nguồn của chúng tôi đã gắn cờ gần một phần tư triệu sai lệch so với các tiêu chuẩn kỹ thuật của Cloudflare (mà chúng tôi gọi là “vi phạm” trong bài viết này) và chặn 16.000 yêu cầu hợp nhất (merge). Tác nhân (agent) đánh giá đặc tả kỹ thuật của chúng tôi đã thẩm định gần 600 thiết kế kỹ thuật dựa trên cùng các tiêu chuẩn đó trước khi quá trình triển khai bắt đầu. Cả hai hệ thống đều lấy dữ liệu từ Cloudflare Codex, một nguồn hướng dẫn kỹ thuật dùng chung được xây dựng cho cả con người và các tác nhân AI. Bài viết này giải thích lý do tại sao chúng tôi xây dựng Codex, cách nó hỗ trợ vòng đời kỹ thuật và những dự định tiếp theo của chúng tôi.

Trước khi có Codex (được chúng tôi giới thiệu ngắn gọn trong một bài viết trước về ngăn xếp kỹ thuật AI của mình), hướng dẫn dành cho nhà phát triển tại Cloudflare nằm rải rác ở nhiều nơi: tài liệu chính thức, tệp trong kho lưu trữ (repository), các luồng trò chuyện và kiến thức tích lũy của từng kỹ sư. Các kỹ sư thường dành quá nhiều thời gian để tìm kiếm hướng dẫn thay vì tập trung giải quyết vấn đề họ đang đối mặt. Ngay cả khi tìm thấy câu trả lời, họ cũng không phải lúc nào cũng biết liệu nó có còn cập nhật, có thẩm quyền hay phù hợp với tình huống của họ hay không.

Khi Cloudflare phát triển, mô hình đó ngày càng khó duy trì. Không kỹ sư nào có thể đọc hết mọi tiêu chuẩn, và người đánh giá cũng không thể kiểm tra đáng tin cậy mọi yêu cầu. Kiến thức nội bộ trở nên khó khôi phục khi nhân sự luân chuyển giữa các nhóm, và những hướng dẫn không được hiển thị hoặc thực thi nhất quán đã dẫn đến sự sai lệch giữa các dự án.

Chúng tôi đã tái cấu trúc kho kiến thức này thành Cloudflare Codex: một tập hợp các tiêu chuẩn kỹ thuật được quản lý mà các tác nhân AI có thể truy xuất và áp dụng ngay tại thời điểm làm việc. Giờ đây, cùng một hướng dẫn có thể cung cấp thông tin cho việc đánh giá mã nguồn, đánh giá thiết kế kỹ thuật, đánh giá báo cáo sự cố và nhiều trường hợp sử dụng khác, trong khi các kỹ sư tập trung thời gian và khả năng phán đoán của mình vào các kết quả được tìm thấy.

Tổ chức và quy trình làm việc của Codex

Một mô hình quản trị Codex chuyên biệt chia Codex thành các lĩnh vực riêng biệt bao gồm các mảng kỹ thuật mà chúng tôi quan tâm. Các lĩnh vực này bao gồm các vấn đề về kiến trúc (ví dụ: frontend và control plane), các mối quan tâm xuyên suốt (bảo mật và độ tin cậy), các ngôn ngữ cụ thể (TypeScript và Rust) và một số lĩnh vực khác. Mỗi lĩnh vực được dẫn dắt bởi một chủ sở hữu chịu trách nhiệm về nội dung, tính nhất quán và chất lượng tổng thể của các tài liệu mà họ giám sát.

Các tiêu chuẩn Codex sử dụng định dạng Request for Comments (RFC). Các yêu cầu sử dụng các từ khóa SHOULD (nên) và MUST (phải) được định nghĩa bởi RFC 2119. Chúng tôi cũng yêu cầu một tiêu đề phần đầu (front matter) để chứa siêu dữ liệu như lĩnh vực và trạng thái RFC. Bất kỳ nhân viên Cloudflare nào có mối quan tâm chính và năng lực chuyên môn đều có thể đề xuất một RFC thông qua yêu cầu hợp nhất (merge request) tuân theo cấu trúc quy định. Đề xuất sau đó sẽ trải qua nhiều vòng phản hồi từ một nhóm người đánh giá ngày càng mở rộng. Sau khi chủ sở hữu lĩnh vực phê duyệt lần cuối, RFC sẽ trở thành một phần của Codex và được xuất bản lên một trang web nội bộ chạy bằng Astro.

Các RFC đã phê duyệt có thể được sử dụng bởi các máy khách (client) và tác nhân Codex, từ đó có thể bắt đầu gắn cờ các vi phạm Codex trong mã nguồn, cấu hình hoặc tài liệu ngay lập tức. Tuy nhiên, chúng chỉ chặn dựa trên các tuyên bố của Codex sau khi một RFC chuyển từ trạng thái đã phê duyệt sang trạng thái thực thi trong vòng đời. Bước thúc đẩy riêng biệt này giúp các nhóm có thời gian tiếp nhận các yêu cầu mới và giải quyết các trường hợp cần thêm công sức để thực thi.

Sơ đồ sau đây minh họa các bước trong quy trình làm việc của Codex:

Một quy trình đơn giản có thể dừng lại ở đây và đưa toàn bộ Codex vào một mô hình ngôn ngữ lớn (LLM) như hiện trạng. Tuy nhiên, với số lượng RFC ngày càng tăng mà chúng tôi hiện có (hơn 60 và vẫn đang tiếp tục), khối lượng dữ liệu này sẽ gây áp lực lớn lên cửa sổ ngữ cảnh (context window) và ảnh hưởng tiêu cực đến kết quả của LLM. Để giúp hướng dẫn các mô hình đến các RFC phù hợp nhất, chúng tôi sử dụng một tác nhân chuyên biệt để tự động trích xuất và nén các tuyên bố SHOULD và MUST thành một cấu trúc JSON chuyên dụng, đồng thời làm giàu nó bằng siêu dữ liệu hỗ trợ việc khám phá lười (lazy discovery) và tiết lộ lũy tiến (progressive disclosure). Đoạn trích rút gọn sau đây cho thấy kết quả đối với RFC về các dịch vụ control plane của chúng tôi:

Mỗi tuyên bố nhận được một định danh slug ổn định, không thay đổi trong quá trình trích xuất ngay cả khi RFC của nó được cập nhật. Định danh này cho phép chúng tôi theo dõi cùng một tuyên bố trên các hệ thống khác nhau theo thời gian, điều này rất cần thiết cho việc giám sát, phân tích và xử lý ngoại lệ.

Ban đầu, chúng tôi trích xuất các tuyên bố thành một tệp Markdown khác, ngắn gọn hơn thay vì JSON. Theo thời gian, chúng tôi chuyển sang định dạng có cấu trúc phong phú hơn để các tác nhân có thể lọc nội dung chúng cần chính xác hơn. Chúng tôi dự định đưa thêm siêu dữ liệu để phạm vi hóa chặt chẽ hơn nữa, chẳng hạn như các chỉ báo về giai đoạn trong vòng đời phát triển phần mềm (SDLC) mà một tuyên bố áp dụng (ví dụ: thiết kế, triển khai, runtime).

Người dùng Codex

Một số hệ thống đã sử dụng Codex trong công việc kỹ thuật hàng ngày. Ba tác nhân cho thấy cách Codex hoạt động trong thực tế: AI đánh giá mã nguồn, đánh giá đặc tả kỹ thuật và đánh giá báo cáo sự cố của chúng tôi.

AI đánh giá mã nguồn

Tác nhân AI đánh giá mã nguồn của chúng tôi, được đề cập trong một bài đăng trên blog riêng, đánh giá các yêu cầu hợp nhất trên nhiều khía cạnh, bao gồm cả sự tuân thủ Codex.

Đối với mỗi lần đánh giá, tác nhân sẽ truy xuất các RFC và phân tích các tuyên bố Codex. Nó chỉ tải toàn bộ nội dung RFC khi mô hình hoặc điều phối viên cần thêm ngữ cảnh. Trong hầu hết các trường hợp, các tuyên bố cung cấp đủ thông tin để giải thích một vi phạm được báo cáo.

Sự khác biệt giữa SHOULD và MUST, cùng với trạng thái của RFC, quyết định cách người đánh giá phản hồi. Các phát hiện từ RFC đã phê duyệt là những khuyến nghị không mang tính chặn. Khi một RFC được thực thi, một yêu cầu MUST không được đáp ứng sẽ khiến người đánh giá từ chối phê duyệt hoặc chặn yêu cầu hợp nhất, tùy thuộc vào mức độ nghiêm trọng.

Kể từ khi Codex ra đời đầu năm nay, AI đánh giá mã nguồn đã gắn cờ gần 230.000 vi phạm. Trong số đó, gần 16.000 vi phạm khiến yêu cầu bị từ chối phê duyệt (tức là chúng đề cập đến các tuyên bố MUST trên các RFC đã được thực thi).

Các giải pháp thay thế cho đánh giá mã nguồn

Một lần chạy AI đánh giá mã nguồn thường mất vài phút để hoàn thành do khung điều phối và việc thực thi của các tác nhân phụ. Mặc dù thời gian chờ đợi thường xứng đáng với chi phí (hoặc token), các kỹ sư vẫn phàn nàn về sự chậm trễ và các vòng lặp bổ sung liên quan đến việc khắc phục các phát hiện. Chúng tôi đã xem xét cách cải thiện trải nghiệm và đưa ra hai tùy chọn bổ sung:

Chúng tôi tin rằng các công cụ linter sẽ hữu ích cho hầu hết mọi nhà phát triển và cơ sở mã nguồn, trong khi CLI vẫn là một lựa chọn thay thế cho các kỹ sư ưa thích nó.

Đánh giá đặc tả kỹ thuật (Spec reviewer)

Các kỹ sư tại Cloudflare thường xuyên viết tài liệu thiết kế và đặc tả kỹ thuật (gọi tắt là specs) trước khi triển khai. Một phần đáng kể của Codex liên quan đến thiết kế, kiến trúc và các chủ đề khác liên quan đến đánh giá kỹ thuật. Để phát hiện các lỗi kiến trúc trước khi quá trình triển khai bắt đầu, chúng tôi đã xây dựng spec reviewer, một tác nhân phát hiện các đặc tả và đánh giá chúng dựa trên các yêu cầu Codex liên quan.

Spec reviewer hoạt động trên Developer Platform: nó chạy dưới dạng một Cloudflare Worker, lưu trữ kết quả và trạng thái trong D1, định tuyến các yêu cầu mô hình thông qua AI Gateway và khởi động việc quét các đặc tả mới thông qua Cron Trigger. Nó bắt đầu bằng cách lọc Codex theo các lĩnh vực và phần liên quan đến đặc tả (ví dụ: các tính năng ngôn ngữ và các RFC tập trung vào triển khai sẽ bị bỏ qua). Một số lời nhắc hướng dẫn (guiding prompts) chỉ dẫn mô hình cách thực hiện đánh giá và định hình kết quả. Các phát hiện được xếp hạng dựa trên mức độ nghiêm trọng (chịu ảnh hưởng bởi các từ khóa SHOULD và MUST) và bao gồm các lời khuyên về chất lượng chung và kiến trúc. Khi hoàn tất quá trình đánh giá, một ghi chú sẽ được để lại trên tài liệu đặc tả, liên kết đến một bảng điều khiển tùy chỉnh nơi có thể kiểm tra chi tiết đánh giá.

Kể từ đầu tháng 5 năm 2026, gần 600 đặc tả mở duy nhất đã được đánh giá. Bao gồm cả các lần chạy lại được kích hoạt theo yêu cầu hoặc do thay đổi đặc tả, chúng tôi đã theo dõi hơn 3.200 lần đánh giá cho đến nay. Phần lớn các phát hiện có mức độ nghiêm trọng “chính” (65%) hoặc “phụ” (29%), với các phát hiện “nghiêm trọng” chỉ chiếm thiểu số (6%).

Hình ảnh sau đây cho thấy giao diện của spec reviewer trông như thế nào:

Chúng tôi dự định tích hợp spec reviewer chặt chẽ hơn bằng cách đăng nhận xét trực tiếp trên các tài liệu đặc tả, nhúng các cuộc hội thoại giữa người và tác nhân có thể ảnh hưởng đến đánh giá, và gắn cờ các đề xuất có tác động cao để con người đánh giá thêm.

Đánh giá báo cáo sự cố

Đánh giá báo cáo sự cố áp dụng cách tiếp cận tương tự cho các báo cáo sự cố (còn được gọi là postmortems). Ngoài việc kiểm tra xem mỗi báo cáo có đầy đủ hay không, nó còn đánh giá liệu báo cáo có giải thích rõ ràng những gì đã xảy ra, xác định các yếu tố góp phần, ghi lại giải pháp và đề xuất các hành động tiếp theo có ý nghĩa hay không. Những kỳ vọng này được định nghĩa trong một RFC Codex chuyên biệt.

Đánh giá báo cáo sự cố sử dụng các khối xây dựng Developer Platform giống như spec reviewer. Kiến trúc dùng chung này đang trở thành một mô hình phổ biến cho các tác nhân Codex của chúng tôi.

Kể từ tháng 5 năm 2026, người đánh giá đã thẩm định hơn 200 báo cáo sự cố và xác định các lỗ hổng như thiếu các mục hành động tiếp theo, dòng thời gian không đầy đủ và thiếu các tín hiệu phát hiện. Trong số các báo cáo đó, 93% bao gồm các sự cố có tác động thấp, chỉ mang tính nội bộ hoặc được khai báo trước. Đối với các sự cố có mức độ nghiêm trọng cao, chúng tôi đã bắt buộc sử dụng người đánh giá như một phần của quy trình đánh giá trung tâm toàn diện, và các báo cáo sẽ không được coi là hoàn chỉnh cho đến khi tất cả các phát hiện đã được giải quyết.

Công việc trong tương lai

Codex đã hỗ trợ các tác nhân đánh giá mã nguồn, thiết kế kỹ thuật và báo cáo sự cố. Chúng tôi dự định mở rộng mô hình đó trong suốt SDLC, cho phép các tác nhân hiển thị các vấn đề một cách nhất quán trong thiết kế, triển khai và vận hành. Mục tiêu dài hạn là các tác nhân không chỉ xác định vấn đề mà còn đề xuất các bản sửa lỗi với mức độ tự chủ ngày càng cao, trong khi các kỹ sư vẫn chịu trách nhiệm xem xét và phê duyệt các thay đổi đó.

Chúng tôi cũng đang mở rộng Codex ra ngoài lĩnh vực kỹ thuật. Các nhóm sản phẩm, bảo mật, tuân thủ và tin cậy & an toàn đang bắt đầu thêm các tiêu chuẩn của riêng họ, cho phép các tác nhân đánh giá công việc dựa trên các cân nhắc vượt ra ngoài phạm vi thiết kế và triển khai đơn thuần.

Trên một số quy trình kỹ thuật, các tác nhân dựa trên Codex đã giúp chúng tôi phát hiện vấn đề sớm hơn và áp dụng các tiêu chuẩn nhất quán hơn. Chúng tôi nhận thấy AI hữu ích nhất khi nó mang lại hướng dẫn đúng đắn cho các kỹ sư ngay tại thời điểm làm việc, và dự định tiếp tục mở rộng cách tiếp cận này trên toàn bộ Cloudflare.

Nếu bạn quan tâm đến việc xây dựng các hệ thống như thế này, các đội ngũ kỹ thuật của chúng tôi đang tuyển dụng.