Các tác nhân AI viết mã có thể tạo ra giao diện người dùng (UI) rất nhanh chóng, nhưng điều khó hơn là sự hiểu biết sâu sắc về thiết kế. Chúng có thể sao chép phong cách, khớp các mẫu và tuân theo quy ước của sản phẩm của bạn. Tuy nhiên, điều chúng chưa thể làm là hiểu lý do tại sao những mẫu đó tồn tại. Mã chỉ cho các tác nhân thấy những gì đã được triển khai, chứ không phải lý do tại sao một thành phần, cụm từ hay tương tác lại trở thành tiêu chuẩn. Lý do đó nằm trong các buổi đánh giá thiết kế, bình luận PR, các cuộc thảo luận trên Slack và với những người trực tiếp tham gia. Đối với một tác nhân AI, ngữ cảnh không nằm trong codebase thì không tồn tại. Vercel là một nhóm làm việc theo hướng "agent-native". Chúng tôi coi các quyết định sản phẩm đã được chấp nhận như mã nguồn, lưu trữ chúng trong kho lưu trữ, xem xét các thay đổi dựa trên chúng và cung cấp chúng cho mọi tác nhân đang làm việc.
Hệ Thống "Product-Design" của Vercel 🚀
Cách chúng tôi thực hiện điều này là thông qua product-design. Đây là một hệ thống gồm ba phần:
1. Kỹ năng tác nhân (Agent skill): Cung cấp cho các tác nhân AI ngữ cảnh đằng sau các quyết định đòi hỏi sự đánh giá về sản phẩm hoặc codebase. 2. Linters: Thực thi các quy tắc rõ ràng một cách tự động. 3. Vòng lặp đánh giá (Review loop): Thu thập bằng chứng từ Slack, Figma và GitHub, sau đó chuẩn bị các cập nhật hướng dẫn để xem xét.
Bất kỳ nhóm nào cũng có thể xây dựng cấu trúc tương tự dựa trên các tiêu chuẩn riêng của mình.
Bên Trong Kỹ Năng "Product-Design"
Kỹ năng này nằm trong kho lưu trữ cùng với mã mà nó quản lý. Dưới đây là một cái nhìn đơn giản về cấu trúc của nó:
* AGENTS.md ở cấp độ kho lưu trữ cho biết khi nào các tác nhân AI cần tải kỹ năng này. AGENTS.md cục bộ của kỹ năng xác định thứ tự tải, xác thực và quản trị. SKILL.md sở hữu quy trình làm việc trong thời gian chạy. * references/: Lưu trữ các quyết định về đánh giá sản phẩm, chất lượng giao diện, khả năng phục hồi, nội dung văn bản, tên sản phẩm chuẩn hóa, mẫu tương tác và các quyết định cụ thể theo từng bề mặt. * exemplars/: Tài liệu hóa các quyết định đáng lặp lại từ các pull request đã triển khai, cùng với những lỗi cần tránh. coverage-gaps.md liệt kê các khu vực mà chúng tôi chưa có tiêu chuẩn. * copywriting-eval/: Kiểm tra hành vi của nội dung văn bản và ngôn ngữ giao diện. Nó không đánh giá quy trình làm việc thiết kế sản phẩm rộng hơn.
SKILL.md giải quyết chế độ yêu cầu trước: hình dạng, triển khai, xem xét, sao chép hoặc tăng cường. Điều này giúp các cuộc kiểm tra không trở thành chỉnh sửa và các lần sao chép không mở rộng thành thiết kế lại. Nó bỏ qua các công việc chỉ liên quan đến backend, telemetry, lỗi console, các tệp được tạo và các bài kiểm tra không có tác động đến UI đã được triển khai. Kỹ năng này định tuyến đến các nguồn chuẩn thay vì sao chép chúng. API thành phần, quy tắc hệ thống thiết kế, tiêu chí trợ năng và hướng dẫn tương tác vẫn giữ nguyên với chủ sở hữu của chúng.
Sử Dụng Linters Để Phản Hồi Nhanh Hơn ⚡
Chúng tôi ưu tiên các kiểm tra mang tính xác định khi linter có thể thực thi một quy tắc một cách đáng tin cậy. Linters nhanh và rẻ để chạy, vì vậy các nhà phát triển và tác nhân AI nhận được phản hồi ngay khi họ làm việc thay vì phải chờ một buổi đánh giá sau này.
Mã có thể đếm hai hoặc ba tùy chọn tĩnh, vì vậy linter có thể đề xuất các nút radio. Việc đặt tên đúng đối tượng và hậu quả cho một hành động hủy diệt đòi hỏi ngữ cảnh sản phẩm, vì vậy kỹ năng này sẽ xử lý nó.
Các ví dụ trong codebase bao gồm các quy tắc:
* Ngăn chặn modal lồng nhau, vốn gây phá vỡ quản lý tiêu điểm, điều hướng bằng bàn phím và phân lớp. * Đề xuất nút radio thay vì select cho hai hoặc ba tùy chọn tĩnh, để mọi lựa chọn đều hiển thị. * Yêu cầu tên dễ tiếp cận cho các nút biểu tượng và điều khiển biểu mẫu, đồng thời từ chối các vòng lấy nét tùy chỉnh bỏ qua các token lấy nét dùng chung. * Ngăn className ghi đè màu sắc, bán kính hoặc bóng đổ của một thành phần hệ thống thiết kế, nhưng vẫn cho phép các lớp bố cục. * Yêu cầu Modal.Body để nội dung dài cuộn đúng cách và tiêu đề cùng chân trang có thể giữ nguyên vị trí. * Thay thế các bóng đổ thô bằng các lớp Material theo chủ đề và từ chối các đường viền trùng lặp với xử lý tích hợp của Material. * Gắn cờ khoảng cách tùy ý nằm ngoài lưới 4px và đề xuất một tiện ích tiêu chuẩn khi có.
Mỗi quy tắc giải thích tại sao mẫu đó là một vấn đề và đề xuất một cách khắc phục cụ thể. Một số quy tắc tự động sửa các thay đổi an toàn, chẳng hạn như thay thế tên tiện ích Tailwind đã ngừng sử dụng.
Kiểm Tra Hướng Dẫn Bằng "Evals" 🎯
Các quy tắc của linter mang tính xác định, nhưng hành vi của tác nhân có thể thay đổi, vì vậy chúng tôi kiểm tra kỹ năng trên các giao diện mà nó chưa từng thấy trước đây. Một tác nhân chỉnh sửa trạng thái ban đầu, sau đó một người đánh giá sẽ kiểm tra kết quả dựa trên một rubric. Các "evals" đến từ các ví dụ đã được triển khai và ghi lại trong kỹ năng. Chúng tôi cũng chạy các thử nghiệm mà không có kỹ năng để đo lường xem nó có thay đổi hành vi của tác nhân hay không. Chúng tôi chấm điểm tính đúng đắn của quy tắc riêng biệt với mức độ tương đồng với kết quả đã được triển khai. Mã đã triển khai có thể chứa một lỗi mà tác nhân nên cải thiện thay vì sao chép.
Duy Trì Hướng Dẫn Luôn Cập Nhật 🔄
Các tiêu chuẩn sản phẩm thay đổi khi các thành phần, tên gọi, quy trình làm việc và trạng thái lỗi thay đổi, và mọi bản cập nhật đều cần bằng chứng và đánh giá của con người. Quy trình thu thập bằng chứng hàng tuần của chúng tôi tập hợp phản hồi thiết kế có thể cải thiện product-design. Nó tìm kiếm các cuộc hội thoại Slack và lưu giữ các liên kết đến tệp Figma, pull request, bình luận đánh giá và bản xem trước làm bằng chứng. Khi bằng chứng không đầy đủ, nó ghi lại mã hoặc commit cần thiết để xác minh.
Quy trình làm việc tách biệt việc thu thập với việc đánh giá:
1. Người thu thập (Collector): Thu thập tin nhắn, liên kết và ngữ cảnh liên quan mà không đề xuất quy tắc. 2. Người đánh giá (Judge): Tập hợp bằng chứng, xác minh nguồn và ghi lại các câu hỏi mở. 3. Công việc (Job): Tạo một gói xem xét với các ứng viên, chủ đề bị từ chối, yêu cầu theo dõi và các khoảng trống về phạm vi.
Hoạt động tự động hóa kết thúc với gói xem xét. Một người sẽ quyết định liệu một ứng viên có trở thành hướng dẫn tác nhân, quy tắc linter, một ví dụ, một eval, hay không có thay đổi nào. Các thay đổi được chấp nhận sẽ được đưa vào tệp liên quan hẹp nhất và vượt qua các kiểm tra liên quan trước khi được hợp nhất.
Cách Xây Dựng "Product-Design" Cho Codebase Của Bạn 🛠️
Thiết lập của Vercel phản ánh sản phẩm, thành phần và lịch sử xem xét của riêng họ, nhưng các nhóm khác có thể điều chỉnh cấu trúc này theo tiêu chuẩn của riêng mình. Dưới đây là cách bạn có thể bắt đầu:
1. Bắt đầu với các quyết định lặp lại
Chọn một bề mặt sản phẩm nơi cùng một bình luận đánh giá liên tục xuất hiện: các hành động hủy diệt, trạng thái lỗi, biểu mẫu cài đặt, trạng thái trống hoặc điều hướng. Thu thập các ví dụ từ mã đã triển khai và các đánh giá thực tế, đồng thời ghi lại quyết định, lý do quan trọng, các trường hợp ngoại lệ và nguồn gốc. Tránh bắt đầu với các tính từ chung chung như rõ ràng, trau chuốt hoặc trực quan. Các tác nhân cần các quyết định có thể quan sát được. Ví dụ, Các hành động hủy diệt sử dụng Động từ + Danh từ là có thể sử dụng được. Các nút nên rõ ràng thì không.
2. Thêm một trình kích hoạt rõ ràng và ranh giới vững chắc
Cho các tác nhân biết khi nào cần tải kỹ năng trong các hướng dẫn kho lưu trữ liên tục, và định nghĩa các tệp và bề mặt mà nó bao gồm cùng với các khu vực nó phải bỏ qua. Trong các đánh giá riêng biệt của Next.js, các tác nhân đã không gọi được một kỹ năng có sẵn trong 56% trường hợp. Hãy kiểm tra trình kích hoạt riêng biệt với hướng dẫn, vì việc không tải được kỹ năng và không tuân theo quy tắc là các vấn đề khác nhau. Yêu cầu tác nhân báo cáo bề mặt và tài liệu tham khảo nào đã được tải, sau đó xác minh rằng các phát hiện của nó trích dẫn các nguồn đó.
3. Tách biệt định tuyến, quy tắc và bằng chứng
Sử dụng một điểm vào ngắn để xác định bề mặt và tải các tài liệu tham khảo tập trung. Sắp xếp các chi tiết xung quanh các bề mặt và quyết định mà các nhà đánh giá đã thảo luận: biểu mẫu, modal, điều hướng, từ vựng sản phẩm, trạng thái quy trình làm việc và các mẫu đa bề mặt. Đặt ID ổn định cho các quy tắc và liên kết chúng với các ví dụ và nguồn. Ghi lại các ví dụ đã triển khai với cả các quyết định hữu ích và các lỗi đã biết, đồng thời giữ cho các hướng dẫn còn thiếu hiển thị trong danh sách khoảng trống về phạm vi.
4. Sử dụng mã cho các quy tắc rõ ràng
Nếu một linter có thể xác định một vấn đề một cách đáng tin cậy, hãy thực thi quy tắc đó ở đó. Sử dụng hướng dẫn tác nhân khi quyết định cần ngữ cảnh sản phẩm hoặc codebase. Giữ các tiêu chuẩn mới, lựa chọn chính sách và các quyết định sản phẩm chưa được giải quyết với con người. Xây dựng các thiết bị huấn luyện từ các ví dụ đã ghi lại và các phần dữ liệu giữ lại từ các giao diện mà các chỉnh sửa dự kiến của chúng không xuất hiện trong kỹ năng. Kiểm tra việc truy xuất và áp dụng riêng biệt, vì việc tác nhân đã tải kỹ năng hay chưa và việc nó đã tuân theo quy tắc hay chưa là những câu hỏi khác nhau.
5. Phân công quyền sở hữu và một vòng lặp cập nhật
Xem xét bằng chứng mới thường xuyên, nhưng yêu cầu sự chấp thuận của con người trước khi thay đổi hướng dẫn hoặc kiểm tra. Lưu giữ một nhật ký quyết định ghi lại những gì đã thay đổi, tại sao và nguồn nào đã hỗ trợ nó. Coi các quy tắc mới như các thay đổi sản phẩm, xem xét và kiểm tra từng quy tắc, và loại bỏ những quy tắc không còn hữu ích.
Lời kết: Phần khó nhất là chọn bề mặt đầu tiên để bắt đầu. Mọi nhóm đều có những quyết định đáng để mã hóa. Câu hỏi là liệu chúng tồn tại trong đầu ai đó hay ở một nơi mà các tác nhân AI có thể tìm thấy chúng. Nếu bạn xây dựng thứ gì đó bằng cách sử dụng mẫu này hoặc có câu hỏi về cách Vercel thiết lập, hãy cho chúng tôi biết!