Bạn có thể bắt đầu xây dựng các kỹ năng về mô hình ngôn ngữ lớn (LLM) trước khi nắm rõ toàn bộ bức tranh.

Bạn có thể bắt đầu xây dựng các kỹ năng LLM trước khi nắm rõ toàn bộ hình thái Bởi Barrett Sonntag Ngày 23/5/2026 0 Bình luận Lần đầu tiên bạn đối mặt với hàng trăm vi phạm nhỏ lặp đi lặp lại, tất cả đều có hình thái tương tự nhau, suy nghĩ tự nhiên là việc này nên được tự động hóa. Một quy tắc xác thực bị lỗi do thiếu thuộc tính, hoặc cùng một vài quy ước bị sai trong hàng chục mẫu, và công việc quá tẻ nhạt để làm thủ công và quá đa dạng để thực hiện bằng một regex duy nhất. Vì vậy, bộ não bạn tìm đến từ tự động hóa, và từ đó cố gắng lắp ráp một hệ thống. Xung lực đó là tốt. Vấn đề là nó có xu hướng phát triển trước khi có bất cứ điều gì hữu ích tồn tại. Bạn bắt đầu phác thảo một bộ giải quyết: nó nên quét kho lưu trữ hàng đêm, lập phiếu yêu cầu, phân loại theo mức độ nghiêm trọng, đề xuất sửa lỗi, chạy thử nghiệm, yêu cầu xem xét, hợp nhất các thay đổi rủi ro thấp và báo cáo lại. Đến khi bạn hoàn thành mô tả hình thái, bạn có một lộ trình nhưng không có kỹ năng. Đống công việc vẫn không thay đổi và phần thời gian trong ngày bạn thực sự sửa chữa mọi thứ vẫn còn đó, không bị động chạm. Tôi đã tham gia đủ các buổi họp bảng trắng để biết rằng bí quyết là bắt đầu nhỏ hơn nhiều so với những gì sơ đồ muốn bạn làm. Cụ thể, hãy bắt đầu với một hành vi hữu ích duy nhất, chạy nó trên công việc thực tế và để mọi thứ trở thành một kỹ năng thông qua sự tích lũy. Tự động hóa là một từ quá rộng Trước khi đi vào phần xây dựng, việc thừa nhận rằng từ tự động hóa che giấu một số điều khác nhau là rất hữu ích. Khi ai đó nói "chúng ta cần tự động hóa việc này", họ có thể muốn nói đến bất kỳ điều nào sau đây: một bản quét theo lịch trình, một đầu vào được kích hoạt, một bộ phân loại ưu tiên, một công cụ đề xuất sửa lỗi, một công cụ mở PR (Pull Request), một công cụ chạy thử nghiệm, một công cụ bình luận đánh giá, một công cụ tự động hợp nhất, một công cụ giám sát. Mỗi điều đó là một quyết định riêng biệt về việc ai hoặc cái gì được phép bắt đầu, đề xuất, phê duyệt và triển khai. Nói "tự động hóa" mà không chọn một trong những điểm đó là cách bạn kết thúc tranh cãi về một hệ thống thay vì xây dựng bất cứ điều gì. Đối với mục đích của chúng ta, việc đặt tên cho phần đó là đủ. Kỹ năng bạn sắp xây dựng không phải là toàn bộ quy trình; đó là một hành vi được đặt tên, nằm ở một điểm trong chuỗi đó, thực hiện một điều dễ hiểu. Một kỹ năng bắt đầu như một hành vi hữu ích duy nhất Hãy xem xét danh sách các vi phạm xác thực. Sự cám dỗ là viết một kỹ năng phát hiện, sửa chữa, xác minh và xử lý hàng loạt trên toàn bộ kho lưu trữ. Hãy kiềm chế điều đó một chút. Chọn hành vi nhỏ nhất có thể hữu ích cho bạn ngay hôm nay. Chẳng hạn: với một tệp mẫu duy nhất chứa một trong các vi phạm này, hãy tạo một chỉnh sửa được đề xuất đáp ứng quy tắc và giải thích lý do. Điều đó không hào nhoáng. Nó cũng không phải là bộ giải quyết. Nó là một công cụ đề xuất sửa lỗi cho một quy tắc trên một tệp. Nhưng nó đủ để được kiểm tra với một ví dụ thực tế, và nó đủ nhỏ để bạn có thể đọc đầu ra của nó và ngay lập tức biết liệu nó có làm đúng hay không. Kỹ năng trở nên hữu ích ngay khi bạn có thể chạy nó trên một tệp mà bạn thực sự phải sửa. Những gì đi vào kỹ năng ở giai đoạn này cũng nhỏ. Một mô tả ngắn gọn về quy tắc mà kỹ năng chịu trách nhiệm, được viết trong sổ đăng ký làm việc của mô hình. Một tuyên bố phạm vi cho biết loại tệp nào nó hoạt động. Một quy trình nói, đại khái: đọc tệp, tìm vi phạm, đề xuất chỉnh sửa tối thiểu đáp ứng quy tắc, trả về cả chỉnh sửa và lý do một dòng. Chỉ vậy thôi. Điều khó khăn nhất là kiềm chế việc bổ sung thêm tính năng ngay lập tức. Sẽ có lúc người dùng muốn công cụ xử lý một quy tắc liên quan, hoặc phát hiện vi phạm trên toàn bộ thư mục, hoặc mở một yêu cầu kéo (pull request). Hãy lưu lại những ý tưởng đó. Kỹ năng ở đây là không yêu cầu chúng ngay lập tức vì công cụ chưa được sử dụng. Việc sử dụng thực tế sẽ định hình kỹ năng. Những lần chạy thực tế đầu tiên là lúc thiết kế thực sự diễn ra. Người dùng hướng kỹ năng vào một tệp tin mà họ biết là có lỗi, đọc kết quả mà nó tạo ra, và nhận thấy khoảng cách giữa điều mong muốn và điều công cụ trả về. Có thể công cụ sửa lỗi vi phạm nhưng lại viết lại mã liền kề mà người dùng không muốn chạm vào. Có thể lời giải thích mà nó tạo ra lần đầu thì ổn, nhưng lần thứ hai lại dài hơn ba câu. Có thể nó tự tin giải quyết sai quy tắc vì một điều gì đó trong cách diễn đạt của người dùng đã ngụ ý một quy tắc liên quan. Đây không phải là lỗi của mô hình mà là những khoảng trống trong kỹ năng. Mỗi lỗi này cho người dùng biết một điều cụ thể: thắt chặt tuyên bố phạm vi để mô hình không đi lạc ra ngoài vi phạm, giới hạn định dạng đầu ra để lời giải thích không thể mở rộng thành một bài luận, thu hẹp định nghĩa quy tắc để mô hình ngừng giải quyết các quy tắc tương tự. Phiên bản tiếp theo của kỹ năng được định hình bởi những gì phiên bản trước đã làm sai trên các tệp tin thực tế. Điều này rất khác so với việc thiết kế nó trên bảng trắng. Đây cũng là nơi thói quen của mô hình trở nên rõ ràng. Nó sẽ vui vẻ tạo ra những công việc hợp lý nhưng thực tế không chính xác, đặc biệt khi tài liệu nguồn quá rộng rãi. Nó sẽ sửa những thứ mà người dùng không yêu cầu sửa, bởi vì ở đâu đó trong ngữ cảnh người dùng đã cho phép nó làm điều đó. Hãy coi đây là những tín hiệu, không phải là những lỗi tính cách. Mỗi tín hiệu là một gợi ý về câu nào trong kỹ năng nên được chỉnh sửa tiếp theo. Kỹ năng phát triển bằng cách tích lũy. Khi công cụ đề xuất sửa lỗi nhỏ đáng tin cậy trên các tệp tin đơn lẻ, người dùng có một nền tảng để mở rộng. Lớp tiếp theo là bất cứ điều gì mà việc sử dụng thực tế yêu cầu. Có thể bước tiếp theo rõ ràng là để kỹ năng quét một thư mục, liệt kê các tệp tin chứa vi phạm và đề xuất chỉnh sửa từng cái một. Có thể đó là tạo ra một danh sách kiểm tra Markdown ngắn gọn các tệp tin để người dùng tự kiểm tra, vì người dùng tin tưởng vào khả năng phát hiện nhưng chưa tin tưởng vào khả năng sửa lỗi. Có thể đó là một điều kiện dừng, như tạm dừng để xác nhận sau một loạt thay đổi nhỏ để người dùng có thể phát hiện sự sai lệch trước khi nó lan rộng khắp kho lưu trữ. Dù lớp tiếp theo là gì, nó được thêm vào vì công việc yêu cầu, không phải vì một sơ đồ đòi hỏi. Kỹ năng phát triển theo cách một công cụ mà người dùng thực sự sử dụng phát triển: một quy trình mới ở đây, một ranh giới mới ở đó, một định dạng đầu ra hóa ra hữu ích hơn định dạng ban đầu. Sau vài tuần như vậy, kỹ năng trông sẽ như thế này.