Có một khoảnh khắc cụ thể phân biệt giữa người dùng AI một cách ngẫu hứng và người thực sự vận hành nó như một hệ thống.
Đó là khoảnh khắc họ không còn là người bắt lỗi nữa.
Hiện tại, với hầu hết mọi người, vòng lặp trông như thế này. Nhờ Claude làm điều gì đó. Đọc đầu ra. Nhận thấy có gì đó sai. Chỉ ra lỗi. Nhận phiên bản đã sửa. Đọc lại. Phát hiện lỗi khác. Lại chỉ ra. Bạn là lớp xác minh, thủ công, mỗi lần, cho mọi tác vụ.
Một vòng lặp tự sửa lỗi loại bỏ bạn khỏi vị trí đó hoàn toàn. Hệ thống tạo ra, tự kiểm tra công việc của mình dựa trên một tiêu chuẩn thực tế, bắt những gì nó làm sai, sửa chúng, và chỉ sau đó mới hiển thị kết quả cho bạn. Vào thời điểm bạn nhìn thấy đầu ra, những lỗi hiển nhiên đã được bắt và xử lý. Những gì còn lại cho bạn là phán đoán về những thứ thực sự cần con người, chứ không phải là đọc hiệu đính bản nháp đầu tiên của máy móc.
Đây là bản dựng hoàn chỉnh. Kết thúc bài viết, bạn sẽ có kiến trúc chính xác, các prompt chính xác và các chế độ lỗi chính xác để kiểm tra trước khi bạn tin tưởng giao phó bất cứ điều gì quan trọng cho hệ thống này.
Tại Sao Điều Này Không Giống Với Chỉ Việc Hỏi Lại Hai Lần
Phản ứng đầu tiên hiển nhiên là chỉ cần yêu cầu mô hình tự kiểm tra lại công việc của nó trong cùng một cuộc trò chuyện. "Hãy xem lại những gì bạn vừa viết và sửa bất kỳ lỗi nào." Điều này có ích một chút. Nhưng nó không xây dựng được một vòng lặp tự sửa lỗi thực sự, và hiểu được tại sao lại là nền tảng của tất cả những gì tiếp theo.
Một mô hình tự xem xét đầu ra của chính nó trong cùng một ngữ cảnh, với cùng một lý luận đã tạo ra lỗi ban đầu, có xu hướng bảo vệ công việc của mình hơn là thực sự xem xét kỹ lưỡng nó. Đây không phải là một khiếm khuyết đặc thù của bất kỳ mô hình cụ thể nào. Đó là một vấn đề cấu trúc. Cùng một quá trình đã tạo ra một câu trả lời nghe có vẻ hợp lý nhưng sai không có khả năng nhận ra nó sai, bởi vì từ bên trong, câu trả lời vẫn nghe có vẻ hợp lý. Hỏi "bạn có chắc không?" thường tạo ra sự trấn an hơn là một sự kiểm tra lại thực sự.
Giải pháp không phải là hỏi hay hơn. Mà là kiến trúc. Một vòng lặp tự sửa lỗi thực sự tách biệt công việc tạo ra câu trả lời khỏi công việc đánh giá nó, sử dụng một quá trình khác, một prompt khác, và lý tưởng nhất là một khuôn khổ tham chiếu hoàn toàn khác, để sự đánh giá không bị nhiễm bẩn bởi cùng những điểm mù đã tạo ra lỗi.
Ba Vai Trò Mà Mọi Vòng Lặp Tự Sửa Lỗi Cần
Mọi hệ thống tự sửa lỗi hoạt động, bất kể nhiệm vụ cụ thể là gì, đều thu gọn thành ba vai trò riêng biệt. Hiểu rõ các vai trò này quan trọng hơn bất kỳ prompt cụ thể nào bên dưới, bởi vì một khi bạn đã thấy chúng, bạn có thể xây dựng một vòng lặp cho hầu hết mọi tác vụ bằng cách điền vào các chi tiết cụ thể.
Người Xây Dựng (Builder). Tạo ra đầu ra thực tế. Viết mã, soạn thảo nội dung, thực hiện nghiên cứu, thực thi tác vụ. Vai trò này nên được cho nhiều không gian sáng tạo nhất và ít ràng buộc nhất, bởi vì công việc của nó là tạo ra một nỗ lực đầu tiên, chứ không phải một nỗ lực hoàn hảo.
Người Phán Xét (Judge). Không xây dựng bất cứ thứ gì. Công việc duy nhất của nó là đánh giá đầu ra của Người Xây Dựng dựa trên một tiêu chuẩn cụ thể, được viết ra, chứ không phải là một cảm nhận mơ hồ về chất lượng. Mã có vượt qua bài kiểm tra của nó không. Bản nháp có phù hợp với yêu cầu không. Nghiên cứu có thực sự trả lời câu hỏi được đặt ra không. Người Phán Xét lý tưởng nhất nên có quyền truy cập vào thứ mà Người Xây Dựng không có, tài liệu nguồn gốc, bộ kiểm thử, tài liệu yêu cầu thực tế, để nó có sự thật cơ sở độc lập để kiểm tra thay vì chỉ đọc lại cùng một đầu ra và hình thành một ý kiến mới.
Người Quản Lý (Manager). Đọc phán quyết của Người Phán Xét và quyết định điều gì xảy ra tiếp theo. Gửi lại cho Người Xây Dựng với phản hồi cụ thể. Chuyển lên cho con người xử lý. Đánh dấu tác vụ đã hoàn thành. Đây cũng là nơi điều kiện dừng của bạn sống, quy tắc ngăn vòng lặp chạy mãi mãi khi một thứ gì đó không thể tự động sửa được.
Nguyên tắc thiết kế quan trọng xuyên suốt cả ba vai trò: xác minh cần tham chiếu đến một thứ gì đó bên ngoài lý luận của chính Người Xây Dựng. Một bộ kiểm thử. Một tài liệu nguồn gốc. Một danh sách kiểm tra được viết ra. Một cuộc gọi AI thứ hai với một cách tiếp cận thực sự khác. Bất cứ thứ gì không chỉ đơn giản là "cùng một mô hình, được hỏi lại, trong cùng một hơi thở."
Xây Dựng Các Bước Bàn Giao
Công việc kỹ thuật thực tế trong một vòng lặp tự sửa lỗi không phải là những prompt thông minh cho mỗi vai trò. Đó là cấu trúc của những gì truyền giữa chúng, và đây là phần mà hầu hết mọi người xây dựng vòng lặp đầu tiên của họ bỏ qua hoàn toàn, sau đó tự hỏi tại sao hệ thống hoạt động thất thường.
Một bước bàn giao cần ba thuộc tính để hoạt động đáng tin cậy. Một định dạng xác định, để vai trò nhận không phải phân tích văn xuôi lỏng lẻo và đoán xem điều gì quan trọng. Một trình kích hoạt xác định, để Người Xây Dựng không phải là người quyết định khi nào nó hoàn thành. Và một đường dẫn thất bại xác định, để khi một thứ gì đó không diễn ra suôn sẻ, có một bước tiếp theo được chỉ định thay vì hệ thống im lặng hỏng hóc hoặc lặp vô hạn.
Trong thực tế, điều này có nghĩa là Người Xây Dựng nên xuất ra một thứ gì đó có cấu trúc, không chỉ là văn bản hội thoại. Một sản phẩm bàn giao rõ ràng cộng với một tuyên bố rõ ràng về những gì nó không chắc chắn. Người Phán Xét sau đó đánh giá đầu ra có cấu trúc đó dựa trên một tiêu chuẩn được viết ra và trả về phán quyết có cấu trúc của riêng nó, không phải một đoạn văn xuôi nước đôi, mà là một kết quả rõ ràng: đạt, không đạt, hoặc cần sửa đổi, kèm theo lý do cụ thể. Người Quản Lý đọc phán quyết có cấu trúc đó, không phải nội dung thô, và quyết định hành động tiếp theo dựa trên các quy tắc được thiết lập từ trước, chứ không phải bằng cách ứng biến một phán đoán tại chỗ.
Đây là một cấu trúc mẫu hoạt động hiệu quả trong hầu hết các tác vụ, cho dù công việc cơ bản là viết lách, mã hóa hay nghiên cứu:
1ĐỊNH DẠNG ĐẦU RA CỦA NGƯỜI XÂY DỰNG2Sản phẩm bàn giao: [đầu ra thực tế]3Mức độ tự tin: [cao / trung bình / thấp]4Những điểm không chắc chắn đã biết: [bất cứ điều gì bạn không chắc chắn, được nêu rõ ràng]5Các giả định đã đưa ra: [bất cứ điều gì bạn giả định mà không được yêu cầu]67ĐỊNH DẠNG PHÁN QUYẾT CỦA NGƯỜI PHÁN XÉT8Phán quyết: [ĐẠT / KHÔNG ĐẠT / CẦN SỬA ĐỔI]9Đã kiểm tra dựa trên: [tiêu chuẩn cụ thể được sử dụng, ví dụ: bản yêu cầu gốc,10bộ kiểm thử, tài liệu nguồn]11Các vấn đề cụ thể được tìm thấy: [các vấn đề chính xác, không phải ấn tượng chung]12Mức độ tự tin trong phán quyết này: [cao / trung bình / thấp]1314HÀNH ĐỘNG CỦA NGƯỜI QUẢN LÝ15Nếu ĐẠT: đánh dấu hoàn thành, gửi cho người dùng.16Nếu KHÔNG ĐẠT hoặc CẦN SỬA ĐỔI: gửi lại cho Người Xây Dựng kèm theo17các vấn đề cụ thể của Người Phán Xét. Tăng bộ đếm sửa đổi.18Nếu bộ đếm sửa đổi vượt quá [N]: dừng vòng lặp, chuyển lên cho con người19với đầy đủ lịch sử những gì đã thử và tại sao nó thất bại.
Điều này trông có vẻ có cấu trúc hơn một cuộc trò chuyện qua lại thông thường, và đúng là như vậy. Chi phí ban đầu đó là thứ mang lại cho bạn một hệ thống hoạt động theo cùng một cách ở lần chạy thứ trăm như lần chạy đầu tiên, thay vì trôi dạt một cách khó lường khi ngữ cảnh tích tụ.
Người Phán Xét Cần Sự Thật Cơ Sở, Không Chỉ Là Một Ý Kiến
Đây là nguyên tắc quan trọng nhất trong toàn bộ hệ thống, và nó đáng để có một phần riêng vì việc hiểu sai nó sẽ âm thầm phá hỏng mọi thứ khác.
Một Người Phán Xét chỉ nhìn thấy đầu ra của Người Xây Dựng, không có tham chiếu độc lập để kiểm tra, chỉ có thể đánh giá tính nhất quán nội bộ, liệu đầu ra có vẻ mạch lạc và được định dạng tốt hay không. Nó không thể đánh giá tính đúng đắn, liệu đầu ra có thực sự khớp với những gì được yêu cầu hay thực sự giải quyết được vấn đề thực tế hay không. Một câu trả lời sai một cách tự tin, được định dạng tốt và nhất quán nội bộ, sẽ vượt qua một Người Phán Xét không có sự thật cơ sở mọi lúc.
Đối với các tác vụ mã hóa, sự thật cơ sở là bộ kiểm thử, đầu ra thực tế của việc chạy mã, kết quả lint, trạng thái build. Không phải "mã này trông có ổn không," mà là "nó có thực sự vượt qua khi được thực thi không."
Đối với các tác vụ nội dung, sự thật cơ sở là tài liệu nguồn gốc và bản yêu cầu gốc, đặt cạnh bản nháp. Không phải "bản này đọc có hay không," mà là "mọi tuyên bố cụ thể trong bản nháp này có bắt nguồn từ một thứ gì đó thực sự trong nguồn không, và bài viết có thực sự đáp ứng mọi yêu cầu trong bản yêu cầu không."
Đối với các tác vụ nghiên cứu, sự thật cơ sở là các kết quả tìm kiếm thực tế và các tài liệu nguồn mà nghiên cứu được cho là dựa trên. Không phải "bản tóm tắt này nghe có vẻ đáng tin cậy không," mà là "mọi tuyên bố có thể được truy xuất đến một nguồn cụ thể không, và các nguồn đã được tìm kiếm có thực sự là những nguồn có liên quan không."
Nếu bạn không thể nói rõ sự thật cơ sở của Người Phán Xét là gì cho tác vụ cụ thể của mình, bạn chưa có một vòng lặp tự sửa lỗi. Bạn có một vòng lặp diễn đạt lại, nơi lỗi sai tự tin của Người Xây Dựng được Người Phán Xét diễn đạt lại một cách tự tin thay vì thực sự bị bắt.
Điều Kiện Dừng Không Phải Là Tùy Chọn
Cách phổ biến nhất để một vòng lặp tự sửa lỗi trở thành một mớ hỗn độn tốn kém, mất kiểm soát là sự vắng mặt của một điều kiện dừng rõ ràng, cứng nhắc. Nếu không có nó, Người Xây Dựng và Người Phán Xét có thể lặp vô hạn, mỗi lần sửa đổi lại kích hoạt một lần đánh giá khác, mỗi lần đánh giá lại kích hoạt một lần sửa đổi khác, trong khi chi phí leo thang và không ai nhận ra cho đến khi hóa đơn đến.
Một điều kiện dừng thực sự cần ba thành phần, và cả ba nên được thực thi như logic rõ ràng, không để lại cho sự phán đoán của mô hình tại thời điểm đó.
Một số lần lặp tối đa. Một giới hạn cứng về số chu kỳ sửa đổi, sau đó Người Quản Lý buộc phải chuyển lên cho con người bất kể Người Phán Xét đã hài lòng hay chưa.
Một ngưỡng chất lượng thực sự có thể đo lường được, không phải là tham vọng. "Đủ tốt" như một chỉ dẫn bên trong prompt không phải là một điều kiện dừng, bởi vì nó là một gợi ý mà mô hình có thể và cuối cùng sẽ bỏ qua dưới áp lực thích hợp. Một thanh cụ thể, có thể kiểm tra, tất cả mười một trường hợp kiểm thử đều vượt qua, hoặc bản nháp khớp với tất cả năm yêu cầu trong bản yêu cầu, là một điều kiện dừng, bởi vì nó có thể được xác minh một cách máy móc thay vì được đánh giá chủ quan mỗi lần.
Một giới hạn chi phí hoặc thời gian. Một ngân sách tuyệt đối mà tác vụ không thể vượt quá bất kể nó đang ở trạng thái nào khi giới hạn đó được chạm tới. Đây là lan can bảo vệ bạn cụ thể khỏi kịch bản tồi tệ nhất, một tác vụ thực sự không thể giải quyết lặp cho đến khi ai đó nhận thấy hóa đơn.
ĐIỀU KIỆN DỪNG
Số lần sửa đổi tối đa: 3. Ở lần phán quyết thất bại thứ 3, dừng lại và chuyển lên
cho con người với đầy đủ lịch sử sửa đổi đính kèm, không tự động thử
chu kỳ thứ 4.
Ngưỡng chất lượng: tất cả các mục trong danh sách kiểm tra của Người Phán Xét phải hiển thị ĐẠT,
không phải "hầu như đạt" hoặc "gần đúng."
Giới hạn ngân sách: nếu tác vụ này đã tiêu thụ hơn [X] token hoặc
[Y] phút, dừng ngay lập tức bất kể trạng thái hiện tại và báo cáo
những gì đã hoàn thành so với những gì còn lại.
Hãy viết những điều này vào logic thực tế của Người Quản Lý, không phải vào một chỉ dẫn mềm bên trong một prompt dài hơn mà mô hình có thể tự thuyết phục để bỏ qua dưới áp lực.
Một Ví Dụ Cụ Thể: Sản Xuất Nội Dung Tự Sửa Lỗi
Để làm cho điều này cụ thể, đây là cách chính xác ba vai trò và điều kiện dừng kết hợp với nhau cho một tác vụ phổ biến, thực tế: biến một tài liệu nguồn thành một phần nội dung hoàn chỉnh mà không cần con người đọc hiệu đính thủ công từng bản nháp.
Người Xây Dựng nhận tài liệu nguồn và bản yêu cầu, và tạo ra một bản nháp. Đầu ra của nó bao gồm bản nháp, cộng với một tuyên bố về mức độ tự tin rõ ràng và một danh sách bất cứ điều gì nó không chắc chắn trong khi viết, một con số cụ thể mà nó không hoàn toàn chắc chắn có trong nguồn, một tuyên bố mà nó suy luận chứ không phải tìm thấy được nêu trực tiếp.
Người Phán Xét nhận bản nháp và nguồn gốc đặt cạnh nhau, không bao giờ nhận bản nháp một cách riêng lẻ. Nó kiểm tra ba điều cụ thể, mỗi điều có đạt hoặc không đạt riêng. Mọi tuyên bố thực tế trong bản nháp có bắt nguồn từ một thứ gì đó thực sự có trong nguồn không. Bản nháp có đáp ứng mọi yêu cầu cụ thể trong bản yêu cầu, độ dài, giọng điệu, các phần bắt buộc không. Lập luận cốt lõi hoặc điểm nhấn có thực sự hiện diện và không bị pha loãng bởi nội dung phụ không. Người Phán Xét trả về một phán quyết có cấu trúc với kết quả đạt hoặc không đạt cho từng mục trong ba mục kiểm tra một cách riêng biệt, bởi vì việc gộp chúng vào một điểm số tổng thể sẽ che giấu chính xác khía cạnh nào đã thất bại.
Người Quản Lý đọc phán quyết có cấu trúc đó. Một kết quả đạt sạch sẽ trên cả ba mục sẽ gửi bản nháp đến hàng đợi đầu ra cuối cùng. Một sự thất bại ở khía cạnh kiểm tra thực tế sẽ gửi nó lại cho Người Xây Dựng với tuyên bố chưa được xác minh cụ thể được gắn cờ trực tiếp, không phải một chỉ dẫn mơ hồ để "kiểm tra lại độ chính xác." Một sự thất bại về tuân thủ bản yêu cầu sẽ gửi nó lại với yêu cầu còn thiếu cụ thể được nêu tên. Sau ba chu kỳ thất bại trên cùng một kiểm tra cụ thể, Người Quản Lý dừng lặp hoàn toàn và chuyển lên cho con người với lịch sử đầy đủ về những gì đã thử, thay vì tiếp tục thử lại một vấn đề mà hệ thống đã chứng minh là không thể tự giải quyết.
Đây là một hệ thống nhỏ. Ba vai trò, một định dạng bàn giao có cấu trúc, một điều kiện dừng rõ ràng. Đó cũng là một hệ thống mà bạn thực sự có thể chạy mà không cần giám sát và tin tưởng vào đầu ra của nó, bởi vì mọi chế độ lỗi đều có một đường dẫn xác định thay vì một đường dẫn không xác định.
Kiểm Tra Vòng Lặp Trước Khi Bạn Tin Tưởng Nó
Trước khi bạn dựa vào bất kỳ hệ thống tự sửa lỗi nào cho một việc thực sự quan trọng, hãy cố tình chạy nó qua các bài kiểm tra căng thẳng cụ thể này. Hầu hết các vòng lặp thất bại trong sử dụng thực tế sẽ thất bại ngay lập tức ở một trong các bài kiểm tra này, nếu có ai đó bận tâm kiểm tra trước.
Bài kiểm tra tác vụ không thể giải quyết. Cố tình giao cho Người Xây Dựng một tác vụ mà nó không thể hoàn thành theo tiêu chuẩn của Người Phán Xét. Người Quản Lý có chạm đúng giới hạn lặp và chuyển lên cho con người không, hay nó quay vòng vô hạn, đốt chi phí cho một tác vụ sẽ không bao giờ thành công?
Bài kiểm tra sai một cách tự tin. Cung cấp cho Người Phán Xét một đầu ra mà bạn đã biết là sai một cách tinh vi, một thứ đọc tốt nhưng chứa một lỗi thực tế hoặc logic cụ thể. Người Phán Xét, với tham chiếu sự thật cơ sở của nó, có bắt được nó một cách chính xác không? Nếu Người Phán Xét thông qua một thứ mà bạn biết là bị hỏng, thì tham chiếu sự thật cơ sở của bạn không thực sự được kiểm tra, hoặc việc kiểm tra quá nông.
Bài kiểm tra điểm mù cùng mô hình. Nếu Người Xây Dựng và Người Phán Xét của bạn chạy trên cùng một mô hình cơ bản, điều này đáng để kiểm tra trực tiếp. Cung cấp cho Người Phán Xét một đầu ra có chứa chính xác loại lỗi mà mô hình đó thường mắc phải. Nếu Người Phán Xét cho nó vượt qua, bạn đã xây dựng một vòng lặp chia sẻ các điểm mù của nó giữa các vai trò, điều này phá hủy toàn bộ mục đích của việc tách chúng ra. Hãy cân nhắc sử dụng một mô hình thực sự khác, hoặc ít nhất là một cách tiếp cận prompt khác biệt có ý nghĩa, cho vai trò Người Phán Xét cụ thể.
Bài kiểm tra chi phí vượt kiểm soát. Tính toán đường dẫn trường hợp xấu nhất thông qua hệ thống của bạn, số lần sửa đổi tối đa, các cuộc gọi mô hình đắt nhất liên quan, độ dài nội dung hợp lý dài nhất và tính toán xem điều đó thực sự tốn bao nhiêu đô la và thời gian thực tế. Nếu con số đó làm bạn lo lắng nếu nó xuất hiện trên một hóa đơn thực tế, thì các điều kiện dừng của bạn vẫn chưa đủ chặt.
Chạy bốn bài kiểm tra này trước khi tin tưởng một vòng lặp tự sửa lỗi với bất cứ điều gì thực tế sẽ bắt được phần lớn các lỗi mà nếu không sẽ xuất hiện lần đầu tiên trước mặt khách hàng, sếp, hoặc bảng sao kê ngân hàng của chính bạn.
Những Sai Lầm Phổ Biến Âm Thầm Phá Vỡ Một Thiết Kế Tốt
Ngay cả với kiến trúc ba vai trò phù hợp, một số ít sai lầm triển khai cụ thể xuất hiện lặp đi lặp lại trong các lĩnh vực hoàn toàn khác nhau, và biết trước chúng sẽ giúp bạn không phải tự mình khám phá lại từng cái một một cách khó khăn.
Để Người Phán Xét chỉ thấy đầu ra của Người Xây Dựng, không có tham chiếu độc lập. Đây là sai lầm phổ biến nhất, và nó âm thầm biến hệ thống của bạn từ một kiểm tra tính đúng đắn thành một kiểm tra tính mạch lạc. Một Người Phán Xét không có gì để so sánh chỉ có thể nói với bạn rằng đầu ra trông nhất quán nội bộ, không bao giờ biết nó có thực sự đúng hay không.
Cung cấp cho mọi vai trò cùng một mô hình chỉ với một khác biệt nhỏ về prompt được xếp lớp lên trên. Nếu Người Phán Xét đang chạy cùng một mô hình cơ bản với Người Xây Dựng, chỉ với một prompt khác bảo nó "hãy phê bình," nó thường kế thừa chính xác các điểm mù giống như Người Xây Dựng, bởi vì về cơ bản nó là cùng một quá trình lý luận đội một chiếc mũ khác. Khi ngân sách cho phép, một mô hình thực sự khác cho vai trò Người Phán Xét tạo ra sự độc lập thực sự thay vì sự độc lập mang tính kịch nghệ.
Đối xử với Người Quản Lý như một đường truyền đơn giản thay vì cung cấp cho nó bộ nhớ thực sự về các lần thử trước đó. Một Người Quản Lý không có khả năng hiển thị về những gì đã được thử trong tác vụ cụ thể này sẽ vui vẻ gửi cùng một phản hồi thất bại trở lại cho Người Xây Dựng lần thứ hai và thứ ba, tạo ra cùng một kết quả thất bại giống hệt nhau mỗi lần, bởi vì không có gì trong hệ thống nhớ rằng cách tiếp cận chính xác này đã thất bại một lần.
Bỏ qua bốn bài kiểm tra căng thẳng vì hệ thống hoạt động tốt trong một lần chạy thử nghiệm mà mọi người đều theo dõi chặt chẽ. Một hệ thống hoạt động chính xác trong khi bạn đang theo dõi nó chặt chẽ và một hệ thống hoạt động chính xác trong khi chạy không giám sát là những tuyên bố khác nhau. Chỉ cái thứ hai mới là điểm thực sự của việc xây dựng một vòng lặp tự sửa lỗi. Nếu bạn chưa cố tình kiểm tra các chế độ lỗi, bạn không thực sự biết tuyên bố nào là đúng cho hệ thống của mình.
Viết điều kiện dừng như một chỉ dẫn mềm thay vì logic cứng. "Dừng khi nó đủ tốt" bên trong một prompt không phải là một điều kiện dừng, nó là một gợi ý mà mô hình có thể và cuối cùng sẽ tự thuyết phục để vượt qua dưới áp lực thích hợp. Một bộ đếm lặp cứng mà Người Quản Lý kiểm tra một cách máy móc trước khi cho phép một chu kỳ khác là một điều kiện dừng. Sự khác biệt giữa hai điều này có ý nghĩa rất lớn lần đầu tiên một tác vụ hóa ra thực sự không thể giải quyết được.
Một Ví Dụ Cụ Thể Thứ Hai: Mã Tự Sửa Lỗi
Cùng một bộ khung trông khác nhưng tuân theo cùng một logic khi tác vụ là mã thay vì nội dung, và việc xem xét cả hai cạnh nhau sẽ làm rõ có bao nhiêu thứ thực sự thay đổi giữa các lĩnh vực.
Người Xây Dựng ở đây là một tác nhân mã hóa làm việc thông qua một tác vụ được xác định: sửa lỗi, một tính năng, một tái cấu trúc. Đầu ra có cấu trúc của nó không chỉ là diff mã, mà còn là đầu ra lệnh thực tế từ việc cố gắng chạy nó, kết quả kiểm thử, kết quả lint, trạng thái build, được đóng gói vào bước bàn giao. Một Người Xây Dựng tạo ra mã nhưng không bao giờ thực sự thực thi nó không thực sự thực hiện đúng vai trò Người Xây Dựng, bởi vì mã khả thi về mặt cú pháp nhưng thất bại trong bộ kiểm thử của chính nó còn tệ hơn là không có mã nào, vì nó trông có vẻ hoàn thành mà không thực sự hoàn thành.
Người Phán Xét kiểm tra ba điều cụ thể, có thể xác minh được. Thay đổi có vượt qua bộ kiểm thử hiện có mà không có các bài kiểm thử tự bị sửa đổi không, vì một Người Xây Dựng âm thầm chỉnh sửa một bài kiểm thử để làm cho nó vượt qua là một lỗi cụ thể và đáng ngạc nhiên là phổ biến, đáng để kiểm tra trực tiếp. Phân tích tĩnh và lint có sạch sẽ không. Diff có thực sự giải quyết tác vụ được giao không, không phải một vấn đề liên quan nhưng khác mà Người Xây Dựng quyết định là thú vị hơn để giải quyết trên đường đi. Mỗi mục này có kết quả đạt hoặc không đạt rõ ràng trong phán quyết có cấu trúc.
Người Quản Lý định tuyến dựa trên kiểm tra cụ thể nào đã thất bại. Một bộ kiểm thử thất bại sẽ được gửi lại cho Người Xây Dựng với đầu ra kiểm thử thất bại chính xác được đính kèm trực tiếp, không phải một chỉ dẫn chung chung để "sửa các bài kiểm thử." Một sự không khớp về phạm vi, nơi diff đã giải quyết một vấn đề khác với vấn đề được giao, sẽ được chuyển lên ngay lập tức cho con người thay vì lặp, bởi vì đó là một lỗi phán đoán về bản chất thực sự của tác vụ, không phải là một khiếm khuyết cơ học mà Người Xây Dựng có thể đơn giản tự mình lặp để thoát khỏi.
Lưu ý rằng bộ khung cơ bản ở đây, Người Xây Dựng tạo ra và gửi kèm bằng chứng, Người Phán Xét kiểm tra dựa trên các tiêu chí cụ thể được đặt tên với phán quyết theo từng mục, Người Quản Lý định tuyến dựa trên chính xác kiểm tra nào thất bại, giống hệt với ví dụ sản xuất nội dung ở trên. Đây là bài học thực tế đáng mang theo khi thấy hai lĩnh vực khác nhau cạnh nhau. Một khi bạn có bộ khung chính xác, việc áp dụng nó cho một loại tác vụ mới chủ yếu là vấn đề viết một danh sách kiểm tra mới, cụ thể cho Người Phán Xét, chứ không phải thiết kế lại toàn bộ kiến trúc từ các nguyên tắc đầu tiên mỗi lần.
Mở Rộng Quy Mô Nhiều Vòng Lặp Đồng Thời
Một khi một vòng lặp tự sửa lỗi đơn lẻ thực sự đáng tin cậy, câu hỏi thực sự tiếp theo là làm thế nào để chạy nhiều vòng lặp cùng một lúc mà không làm cho hệ thống trở nên không thể quản lý được, vì đây chính là nơi hầu hết các nỗ lực thứ hai của mọi người để mở rộng quy mô đi sai hướng.
Sự cám dỗ là khởi động nhiều vòng lặp đồng thời ngay khi vòng lặp đầu tiên hoạt động, giải quyết năm tác vụ khác nhau song song vì kiến trúc về mặt kỹ thuật hỗ trợ nó. Hãy chống lại điều này lâu hơn mức cần thiết. Mỗi vòng lặp đồng thời bổ sung là một nơi khác mà điều kiện dừng có thể thất bại một cách âm thầm, một nơi khác mà chi phí có thể tăng lên không được chú ý, một nơi khác mà tham chiếu sự thật cơ sở của Người Phán Xét có thể sai một cách tinh vi theo cách chỉ xuất hiện dưới khối lượng thực tế thay vì trong một lần chạy thử nghiệm duy nhất.
Con đường mở rộng quy mô an toàn hơn là mở rộng tuần tự với một ngưỡng tin cậy thực sự ở mỗi bước. Có một vòng lặp chạy đủ đáng tin cậy để bạn đã ngừng kiểm tra chặt chẽ đầu ra của nó, có nghĩa là nó liên tục vượt qua các cuộc kiểm tra ngẫu nhiên thủ công của bạn trong một khoảng thời gian thực, không chỉ là một lần chạy thử nghiệm thành công duy nhất. Chỉ sau đó mới thêm một vòng lặp thứ hai cho một tác vụ khác. Theo dõi tỷ lệ thất bại thực tế của mỗi vòng lặp theo thời gian, không chỉ là liệu nó có vẻ hoạt động trong các lần chạy mà bạn tình cờ quan sát được hay không.
Khi bạn chạy nhiều vòng lặp đồng thời, hãy xem xét nghiêm túc một bảng điều khiển chi phí chia sẻ trên tất cả chúng, không phải theo dõi từng vòng lặp một cách riêng lẻ. Một vòng lặp đơn lẻ với ngân sách hợp lý cho mỗi tác vụ trông hoàn toàn ổn khi xem xét riêng lẻ. Mười vòng lặp, mỗi vòng trong ngân sách, vẫn có thể cộng lại thành một tổng số thực sự đáng báo động mà không ai nhận ra cho đến khi hóa đơn tổng hợp đến, chính xác bởi vì việc theo dõi từng vòng lặp riêng lẻ trông có vẻ ổn.
Thói quen duy nhất ngăn chặn các vấn đề mở rộng quy mô trước khi chúng bắt đầu: ghi nhật ký mọi kích hoạt điều kiện dừng trên mọi vòng lặp, không chỉ các lần hoàn thành thành công. Một vòng lặp chạm đến giới hạn lặp tối đa và chuyển lên cho con người đang làm chính xác những gì nó được cho là phải làm, nhưng nếu một vòng lặp cụ thể liên tục chạm đến giới hạn đó trong khi những vòng khác hiếm khi làm vậy, đó là một tín hiệu cho thấy tiêu chuẩn của Người Phán Xét cho tác vụ cụ thể đó hoặc bị hiệu chỉnh sai, quá khắt khe để thực sự vượt qua, hoặc đang kiểm tra dựa trên sự thật cơ sở sai hoàn toàn. Mô hình đó là vô hình nếu bạn chỉ theo dõi các thành công và coi mọi lần chuyển lên như một sự kiện riêng lẻ, không đáng chú ý thay vì một điểm dữ liệu về thiết kế của vòng lặp cụ thể đó.
Bắt Đầu Từ Đâu Trong Tuần Này
Đừng cố gắng xây dựng một hệ thống tự sửa lỗi hoàn toàn tổng quát trong lần thử đầu tiên. Hãy chọn một tác vụ cụ thể, hẹp, được xác định rõ ràng mà bạn đã làm thường xuyên, một thứ có một tiêu chuẩn rõ ràng mà bạn có thể viết ra nếu được yêu cầu, và xây dựng vòng lặp ba vai trò xung quanh tác vụ đơn lẻ đó trước.
Viết danh sách kiểm tra của Người Phán Xét ra một cách rõ ràng trước khi bạn viết một dòng nào trong prompt của Người Xây Dựng. Tiêu chuẩn mà bạn đang kiểm tra dựa trên nên định hình những gì bạn yêu cầu Người Xây Dựng tạo ra, không phải ngược lại. Nếu bạn chưa thể viết danh sách kiểm tra, bạn chưa biết "đúng" có nghĩa là gì cho tác vụ này đủ rõ để tự động hóa việc kiểm tra nó, và điều đó đáng để khám phá trước khi bạn xây dựng bất cứ thứ gì.
Chạy bốn bài kiểm tra căng thẳng ở trên trước khi bạn tin tưởng giao vòng lặp cho bất cứ điều gì thực sự quan trọng, không phải sau khi một thứ gì đó đã sai trước mặt ai đó. Thêm điều kiện dừng như logic cứng, thực tế ngay từ phiên bản đầu tiên, không phải như một suy nghĩ lại sau khi bạn đã bị một vòng lặp chạy trốn đốt cháy một lần.
Một khi một vòng lặp thực sự đáng tin cậy, chạy không giám sát, bắt được các lỗi thực tế, dừng lại sạch sẽ khi nó nên, vòng lặp thứ hai sẽ nhanh hơn nhiều. Không phải vì các prompt chuyển trực tiếp, chúng thường cần được viết lại cho tác vụ mới, mà bởi vì bạn đã hiểu hình dạng thực sự của vấn đề. Tách biệt việc xây dựng khỏi việc phán xét. Cung cấp cho việc phán xét một thứ gì đó thực tế để kiểm tra dựa trên. Viết điều kiện dừng như logic, không phải hy vọng.
Hình dạng đó là toàn bộ kỷ luật. Mọi thứ khác chỉ là áp dụng nó cho bất kỳ tác vụ nào trước mặt bạn.
Theo dõi @cyrilXBT để có các mẫu vòng lặp chính xác và thiết lập Người Xây Dựng-Người Phán Xét-Người Quản Lý đằng sau mọi thứ trong bài viết này.
