Khi con người vẫn cần ngồi trước bàn phím, hướng dẫn từng dòng cho các tác nhân, kỹ năng cốt lõi là viết prompt. Hiện nay, các tác nhân đã có thể nhận một mục tiêu và tự thực hiện, kỹ năng cốt lõi mới là kỹ thuật vòng lặp.

Tác giả bài viết: CyrilXBT

Bài dịch, nguồn: ME News

Tháng 6 năm 2026, trong vòng một tuần, ba người đã độc lập đưa ra cùng một kết luận.

Developer Peter Steinberger của OpenClaw đã công khai cho biết mọi người nên ngừng việc viết trực tiếp các prompt cho các tác nhân lập trình, thay vào đó hãy thiết kế các hệ thống vòng lặp có thể tự động gửi lệnh đến các tác nhân này.

Gần như cùng lúc, Boris Cherny, người phụ trách Anthropic Claude Code, cũng cho biết anh ấy đã ngừng nhập trực tiếp các lời nhắc vào Claude. Hiện tại, anh ấy đang chạy một chuỗi vòng lặp tự động gọi Claude và xác định bước tiếp theo cần làm, và công việc thực sự của anh ấy là viết và thiết kế các vòng lặp này.

Vài ngày sau, kỹ sư Google Addy Osmani đã tổng hợp hệ thống thực hành này và đặt một cái tên:

Loop Engineering, vòng lặp kỹ thuật.

Họ không phải là người sáng tạo ra cách làm việc này một cách vô cớ, mà chỉ là đặt tên cho một sự thay đổi đã âm thầm diễn ra.

Vì trước đó, các công cụ nền tảng đã vượt qua một ngưỡng quan trọng: các tác nhân lập trình đã bắt đầu có thể hoàn thành các nhiệm vụ thực sự mà không cần sự giám sát; chi phí tự động lập lịch đã giảm đủ thấp để việc chạy lặp lại một nhiệm vụ theo lịch trình không còn显得 lãng phí; chi phí cho mỗi lần chạy tác nhân cũng đã giảm xuống một mức mới – thay vì dành nhiều thời gian suy nghĩ kỹ lưỡng một lần, hãy để tác nhân thử năm lần, chi phí có thể còn thấp hơn.

Đây chính là lý do tồn tại của lộ trình này.

Khi con người vẫn cần ngồi trước bàn phím, hướng dẫn từng dòng cho các tác nhân, kỹ năng cốt lõi là viết prompt. Hiện nay, các tác nhân đã có thể nhận một mục tiêu và tự thực hiện, kỹ năng cốt lõi mới là kỹ thuật vòng lặp.

Dưới đây là toàn bộ lộ trình 20 bước từ người vận hành lời nhắc đến nhà thiết kế hệ thống. Phải tuân thủ thứ tự tiến hành, vì trong lộ trình này, mối quan hệ thứ tự giữa các bước thường quan trọng hơn bất kỳ bước nào riêng lẻ.

Kỹ thuật lặp lại không phải là một kỹ năng đơn lẻ có thể “nắm vững” hay “không nắm vững”, mà là một chồng kỹ năng được xếp chồng lên nhau. Mỗi tầng đều phụ thuộc vào nền tảng phía dưới có đủ vững chắc hay không.

Ví dụ: việc xây dựng bộ kích hoạt lịch tự động ở bước 14 ngay trước khi thiết lập điều kiện dừng thực sự ở bước 10 sẽ chỉ tạo ra một hệ thống có thể tự động lãng phí tiền bạc khi không có người giám sát. Trước đây, nó ít nhất chỉ lãng phí tài nguyên khi bạn đang nhìn vào màn hình, giờ đây nó có thể tự động liên tục tiêu tiền.

Tương tự, nếu bạn xây dựng lớp bộ nhớ bền vững ở Bước 11 trước khi hoàn thành cơ chế xác minh đáng tin cậy ở Bước 6 và Bước 7, bạn có thể ghi nhớ cẩn thận những kinh nghiệm được tổng hợp bởi một “người đánh giá” quá lỏng lẻo, liên tục cho phép các kết quả sai lệch xảy ra.

Điều này không chỉ không giúp hệ thống tiến bộ, mà còn khiến những kinh nghiệm sai lệch tích lũy ngày càng nhiều, khiến lớp ghi nhớ chuyển từ “không hữu ích tạm thời” thành “có hại chủ động”.

Vì vậy, việc bỏ qua một số bước không chỉ đơn thuần là không triển khai một tính năng nào đó. Vấn đề nghiêm trọng hơn là bạn đang xây dựng những khả năng cao cấp trông đầy hứa hẹn trên một nền tảng hoàn toàn không thể hỗ trợ chúng, và thường phải đến khi hệ thống đã được mở rộng và gây ra hậu quả thực tế thì mới phát hiện ra vấn đề.

Bước đầu tiên thực sự không liên quan đến bất kỳ công nghệ nào.

Bạn phải thừa nhận rằng, trong luồng công việc hiện tại, yếu tố hạn chế hiệu suất thường không còn là khả năng của mô hình, mà là chính bạn vẫn đang bị kẹt trong vòng lặp.

Mỗi khi bạn ngồi trước máy tính chờ mô hình trả lời, đọc kết quả, rồi nhập lệnh tiếp theo, bạn trở thành khâu chậm nhất trong toàn bộ hệ thống.

Mô hình có thể thực hiện, xác minh và thử lại, và tốc độ của những thao tác này nhanh hơn nhiều so với việc con người từng bước giám sát nó hoàn thành nhiệm vụ.

Bước này không có từ khóa hướng dẫn nào; nó là một quyết định nhận thức.

Trước khi bạn thực sự chấp nhận điều này, tất cả các bước tiếp theo sẽ trông giống như những công việc thừa thãi không cần thiết, thay vì ý nghĩa thực sự của chúng—loại bỏ điểm nghẽn hiệu suất lớn nhất trong hệ thống.

Khi mô hình đưa ra đầu ra không chính xác, phản ứng tự nhiên nhất của mọi người thường là thêm một quy tắc vào lời nhắc ban đầu.

Sau vài tháng, cách làm này sẽ tạo ra một bức tường cao gồm các quy tắc: dày đặc nội dung, mâu thuẫn lẫn nhau, dài đến mức mô hình không thể xử lý đồng thời tất cả các yêu cầu trong bộ nhớ làm việc.

Cuối cùng, mô hình thường chỉ có thể thực hiện khớp mẫu dựa trên các nội dung mới xuất hiện hoặc trông nổi bật nhất, đồng thời vô tình bỏ qua các quy tắc khác.

Circular engineering has completely transformed this approach.

Khi có vấn đề phát sinh, bạn không còn chỉ thêm một yêu cầu mới vào lời nhắc, mà còn bổ sung một thành phần mới cho hệ thống, ví dụ:

• Thêm một bước xác minh độc lập;
• Thêm một tệp bộ nhớ;
• Thêm một bộ kích hoạt theo lịch trình;
• Thêm một giai đoạn đánh giá có cấu trúc.

As the capabilities of external systems continue to improve, prompts themselves should become shorter, not longer.

Dù nhiệm vụ cụ thể thuộc lĩnh vực nào, mỗi lần lặp trong chu trình đều có thể chia thành năm hành động cơ bản:

Nhận diện, chuyển giao, xác minh, lưu trữ bền vững, lập lịch.

Phát hiện

Hãy xác định rõ nhiệm vụ thực sự cần hoàn thành là gì.

Giao nhận

Assign the task to the model, agent, or tool responsible for execution.

Xác minh

Kiểm tra xem kết quả có chính xác theo tiêu chuẩn thực tế hay không.

Tính bền vững (Persistence)

Ghi lại những gì đã xảy ra trong lần chạy này, những điều đã học được, để tránh mất kinh nghiệm trong lần chạy tiếp theo.

Lịch trình

Dec định thời điểm nào hệ thống này sẽ chạy lại.

Hầu hết quy trình làm việc hiện tại của mọi người chỉ rõ ràng bao gồm hai hành động đầu tiên: nhận diện nhiệm vụ và chuyển giao nhiệm vụ, và thường được thực hiện thủ công trong cửa sổ trò chuyện.

Ba hành động khác hoặc hoàn toàn không tồn tại, hoặc bị ẩn trong chính bộ não của con người.

Trung tâm của chu trình kỹ thuật là làm rõ năm hành động này và cố gắng tự động hóa chúng.

Trước khi bắt đầu xây dựng hệ thống, hãy chọn một nhiệm vụ mà bạn đã thực hiện lặp đi lặp lại và có thể mô tả rõ ràng các tiêu chuẩn chất lượng.

Đừng chọn những câu hỏi khó nhất, cũng đừng chọn những nhiệm vụ sáng tạo hoàn toàn không có tiền lệ.

Nhiệm vụ ứng cử đầu tiên phải đáp ứng ba điều kiện:

1. Bạn cần thực hiện nó lặp đi lặp lại;
2. Nó có những tiêu chuẩn rõ ràng có thể ghi lại;
3. Nó có một trạng thái “hoàn thành” dễ nhận biết.

Nói cách khác, một đồng nghiệp sau khi xem kết quả nên có thể nhanh chóng xác định liệu nhiệm vụ này đã được thực hiện đúng hay chưa.

Giới hạn này quan trọng hơn những gì bề ngoài trông thấy.

Nếu một nhiệm vụ không có tiêu chuẩn hoàn thành rõ ràng, thì không thể xây dựng được các bước xác minh thực sự. Một vòng lặp không có cơ chế xác minh đáng tin cậy không phải là một vòng lặp thực sự, mà chỉ là một lần đoán mò không có sự giám sát.

Đây là bước đa số mọi người dễ bỏ qua nhất, nhưng lại là bước then chốt quyết định liệu hệ thống có hoạt động bình thường hay không.

Trước khi viết bất kỳ hướng dẫn nào cho tác nhân, hãy viết bằng ngôn ngữ rõ ràng, tự nhiên: kết quả đúng đắn nên trông như thế nào.

Bạn cần những tiêu chuẩn cụ thể, có thể kiểm tra được, chứ không phải những phán đoán chất lượng mơ hồ như “cảm thấy tốt” hay “trông chuyên nghiệp”.

Có thể sử dụng mẫu sau:

Tên nhiệm vụ: [Tên nhiệm vụ]

Hoàn thành định nghĩa (Definition of Done, DoD):

• [Tiêu chuẩn cụ thể, có thể kiểm tra được 1]
• [Tiêu chuẩn cụ thể, có thể kiểm tra được 2]
• [Tiêu chuẩn cụ thể, có thể kiểm tra được 3]

Even if the final output appears complete and carefully polished, this task cannot be considered completed if any of the above items is missing.

Nếu bạn không thể điền mẫu này cho nhiệm vụ hiện tại đã chọn, hãy quay lại Bước 4 và chọn một nhiệm vụ khác phù hợp hơn để xây dựng vòng lặp.

Đây là quyết định kiến trúc quan trọng nhất trong tất cả các hệ thống vòng lặp.

The role responsible for generating results must be separated from the role responsible for reviewing results.

Lý do là khi mô hình kiểm tra ngay đầu ra của chính nó sau khi tạo nội dung, nó thường có xu hướng biện hộ cho câu trả lời vừa tạo ra thay vì thực sự xem xét một cách phê phán các vấn đề trong đó.

Trong một chu trình hợp lý, ít nhất phải tồn tại hai vai trò độc lập:

Người xây dựng

Người xây dựng có không gian sáng tạo nhất định, chịu trách nhiệm tạo ra phiên bản đầu tiên.

Người đánh giá

Người đánh giá nhận đầu ra từ người xây dựng và định nghĩa hoàn thành đã xác định ở Bước 5, sau đó dựa trên các tiêu chuẩn này để xác định liệu kết quả có đạt yêu cầu hay không.

Lý tưởng nhất, người đánh giá cũng nên có thể truy cập các bằng chứng độc lập mà người xây dựng không thể truy cập, ví dụ:

• Bộ kiểm thử;
• Tài liệu gốc;
• Dữ liệu thời gian thực;
• Cơ sở dữ liệu uy tín;
• Original task brief.

Như vậy, phán quyết của người đánh giá mới có thể dựa trên bằng chứng thực tế, thay vì lặp lại ý kiến chủ quan theo cùng cách suy nghĩ với người xây dựng.

Nếu người đánh giá chỉ có thể nhìn thấy đầu ra của người xây dựng, thì họ chỉ có thể đánh giá xem kết quả có “dường như nhất quán” hay không.

Nó không thể xác định liệu kết quả có thực sự chính xác hay không.

Do đó, người đánh giá phải có cơ sở khách quan để xác minh, tức là Ground Truth. Tùy theo ngữ cảnh cụ thể, có thể hiểu nó là “sự thật chuẩn”, “dữ liệu thực tế” hoặc “cơ sở uy tín”.

For different tasks, the objective criteria also vary.

Nhiệm vụ lập trình

The objective basis is the test suite and the actual output results after the code runs.

Nhiệm vụ sản xuất nội dung

Cơ sở khách quan là tài liệu gốc và bản tóm tắt nội dung. Người đánh giá cần so sánh tài liệu gốc với bản nháp được tạo ra song song.

Nhiệm vụ nghiên cứu

The objective basis is the original documents, papers, datasets, or authoritative sources explicitly required for the task.

Nếu bạn không thể nêu rõ ràng những tiêu chí mà người đánh giá cần dựa vào để kiểm tra, thì chu trình của bạn vẫn chưa có cơ chế xác minh thực sự, bất kể cách diễn đạt của người đánh giá nghe có vẻ tự tin đến đâu.

Đầu ra của người xây dựng và kết luận của người đánh giá đều phải tuân theo cấu trúc được định nghĩa rõ ràng, chứ không chỉ là ngôn ngữ tự nhiên trôi chảy.

Nếu không, người quản lý ở bước tiếp theo sẽ không có thông tin ổn định và đáng tin cậy để đưa ra quyết định và định tuyến.

Người xây dựng có thể sử dụng định dạng đầu ra sau:

Đầu ra của người xây dựng:

• Nội dung cuối cùng được giao;
• Mức độ tin tưởng vào kết quả;
• Known uncertainties.

Người đánh giá có thể sử dụng định dạng đầu ra sau:

Kết luận đánh giá:

• PASS: Thành công;
• FAIL：Thất bại；
• CẦN SỬA ĐỔI:
• Các vấn đề cụ thể được phát hiện;
• Các tiêu chuẩn khách quan hoặc bằng chứng gốc được sử dụng để kiểm tra lần này.

Trước khi kết nối với lịch trình tự động và thử lại tự động, hãy tự chạy thủ công một lần đầy đủ quy trình “Người xây dựng—Người đánh giá”.

Đọc kỹ các nhận xét do người đánh giá đưa ra và tự hỏi bản thân:

• Bạn có đồng ý với kết luận của nó không?
• Has it ever let through a result you knew was wrong?
• Has it incorrectly negated a previously qualified result?

Nếu người đánh giá phê duyệt một kết quả mà bạn biết là sai, hoặc từ chối một kết quả thực tế không có vấn đề, hãy sửa đổi cơ sở khách quan hoặc hoàn thiện tiêu chuẩn trước khi tiếp tục xây dựng hệ thống.

Tự động hóa một bước xác minh sai lầm chỉ khiến hệ thống tạo ra các kết quả sai lệch nhanh hơn.

Để làm cho năm bước trên cụ thể hơn, chúng ta có thể quan sát một nhiệm vụ phổ biến: chuyển đổi một tài liệu gốc thành một bài viết hoàn chỉnh.

Bước 5: Hoàn thành định nghĩa

Tiêu chuẩn hoàn thành nhiệm vụ này có thể là:

• Mỗi sự kiện trong bản nháp đều có thể truy xuất trở lại nội dung rõ ràng trong tài liệu gốc;
• Bản nháp đáp ứng tất cả các yêu cầu cụ thể trong bản tin, bao gồm độ dài, giọng điệu và cấu trúc;
• Core argument of the original text is clearly preserved without being diluted by meaningless filler content.

Bước 6: Người xây dựng tạo bản nháp

Người xây dựng nhận tài liệu gốc và bản tóm tắt nội dung, tạo ra một bản nháp.

Đồng thời, nó cũng cần liệt kê rõ những sự không chắc chắn tồn tại trong quá trình viết, ví dụ:

• Một con số nào đó có thực sự xuất hiện trong tài liệu gốc hay không;
• Kết luận này được nêu rõ trong văn bản gốc, hay do mô hình tự suy luận?
• Một sự thật có thiếu nguồn đáng tin cậy hay không.

Bước 7: Người đánh giá kiểm tra so với bản gốc

Người đánh giá đồng thời nhận bản nháp và tài liệu gốc, thay vì chỉ nhận bản nháp.

Nó cần kiểm tra riêng lẻ ba tiêu chí trong định nghĩa và đưa ra kết luận đạt hoặc không đạt cho từng tiêu chí, thay vì gộp tất cả các chiều thành một điểm tổng hợp mơ hồ.

Việc gộp ba tiêu chuẩn khác nhau thành một đánh giá tổng thể sẽ che giấu được chính xác chiều nào gặp vấn đề. Đây là nguyên nhân phổ biến nhất khiến nhiều chu trình từng hoạt động tốt dần mất đi giá trị phản hồi.

Bước 8: Giao tiếp có cấu trúc

Kết luận của người đánh giá nên là một đối tượng có cấu trúc, chứ không phải một đoạn văn ngôn ngữ tự nhiên với nhiều cách diễn đạt giữ lại.

Nó cần xuất ra ba kết quả rõ ràng là đạt hoặc không đạt, đồng thời cung cấp lý do cụ thể cho từng mục không đạt.

Bước 9: Xác minh thủ công cơ chế đánh giá

Trước khi hệ thống chạy tự động, hãy thực hiện thủ công một quy trình đầy đủ để giúp bạn phát hiện xem người đánh giá có quá lỏng lẻo hay quá nghiêm ngặt hay không.

Người đánh giá quá lỏng lẻo có thể vì bài viết viết trôi chảy mà bỏ qua những dữ liệu được bịa đặt.

Người đánh giá quá khắt khe có thể từ chối một bài viết đạt tiêu chuẩn do sở thích cá nhân chưa từng được ghi trong bản tin.

Cả hai vấn đề này đều rất phổ biến khi thiết lập lần đầu tiên.

Việc phát hiện chúng sau khi hệ thống chạy tự động 50 lần sẽ tốn kém hơn nhiều so với việc giải quyết vấn đề khi kiểm tra thủ công lần đầu tiên.

Manager chịu trách nhiệm đọc các đánh giá của người thẩm định và đưa ra quyết định về bước tiếp theo.

Các điều kiện dừng cũng nên được tích hợp trong trình quản lý và phải được viết dưới dạng logic cứng rõ ràng, chứ không phải là một hướng dẫn mềm mà mô hình có thể tự diễn giải để vượt qua.

Ví dụ:

Điều kiện dừng:

• Số lần chỉnh sửa tối đa: 3 lần;
• Khi đánh giá lần thứ 3 vẫn thất bại, hãy gửi toàn bộ lịch sử cho con người xử lý và không được khởi động lần sửa đổi thứ 4;
• Tiêu chuẩn chất lượng: Mỗi mục trong định nghĩa phải hiển thị PASS;
• Giới hạn ngân sách: Nếu chi phí nhiệm vụ vượt quá X hoặc thời gian chạy vượt quá Y, nhiệm vụ phải được dừng ngay lập tức, bất kể trạng thái hiện tại.

Một vòng lặp không có điều kiện dừng thực sự không phải là một hệ thống, mà là một khoản nợ đang chờ phơi bày rủi ro.

Tại sao các lệnh mềm như “dừng lại khi kết quả đủ tốt” lại không đáng tin cậy?

Vì đây chỉ là một lời khuyên.

Khi mô hình đã được sửa đổi nhiều lần liên tiếp nhưng vẫn không vượt qua, để mang lại một kết thúc trông có vẻ hài lòng cho nhiệm vụ, nó rất có thể tự thuyết phục bản thân rằng “bản này đã đủ gần với tiêu chuẩn”, từ đó tự hạ thấp ngưỡng đánh giá.

In contrast, issues like these do not occur with iterations mechanically checked by code or explicit rules that the manager cannot bypass through reasoning.

Nếu một chu trình khởi động lại từ đầu mỗi lần chạy, nó sẽ không nhớ những gì đã học được từ lần chạy trước.

Do đó, cần thêm một lớp lưu trữ đơn giản.

Có thể tạo một tệp cho mỗi trải nghiệm mới thực sự và tóm tắt bằng một câu ở đầu tệp:

• Bạn đã học được gì;
• Đã sửa gì;
• Tại sao kinh nghiệm này lại quan trọng.

Nguyên tắc chính là: chỉ ghi lại những kiến thức mới chưa được lưu ở nơi khác.

Ký ức lặp lại không phải là tri thức, mà là tiếng ồn.

Để cơ chế lưu trữ lâu dài hoạt động hiệu quả trong dài hạn, phải giữ sự kiềm chế khi ghi dữ liệu.

Người ta dễ có xu hướng ghi lại tất cả các chi tiết hoạt động, nhưng điều này chỉ tái hiện vấn đề “prompt quá dài” được đề cập ở Bước 2, chỉ lần này, đối tượng phình to không còn là prompt mà là thư mục bộ nhớ.

Những kinh nghiệm thực sự đáng ghi lại là những thứ mà nếu quên đi, bạn sẽ phải tốn rất nhiều thời gian để phát hiện lại, chứ không phải những bản ghi thông thường về một lần vận hành diễn ra suôn sẻ như dự kiến.

Chỉ đơn thuần tăng cơ chế lưu trữ lâu dài cuối cùng cũng sẽ tạo ra các vấn đề tương tự như prompt quá dài.

Theo thời gian, hệ thống sẽ tích lũy hàng chục tệp tin, trong đó nhiều nội dung chỉ là cách diễn đạt khác nhau một chút về cùng một vấn đề.

Do đó, nên tổ chức lại tệp bộ nhớ theo chu kỳ cố định. Thực hiện hàng tuần thường là tần suất hợp lý.

Quá trình sắp xếp bao gồm:

• Kiểm tra bộ nhớ hiện có;
• Gộp nội dung trùng lặp;
• Nén nhiều kinh nghiệm tương tự thành một nguyên tắc rõ ràng hơn;
• Remove content that has been proven incorrect or outdated.

Mục tiêu không phải là tích lũy ngày càng nhiều tài liệu, mà là nắm giữ ít tài liệu hơn nhưng có mật độ thông tin cao hơn.

Nhiều người sẽ bỏ qua bước này hoàn toàn vì nó không mang lại khả năng mới rõ ràng ngay lập tức, mà chỉ nhằm phòng ngừa các vấn đề trong tương lai.

But precisely because it lacks immediate feedback, it should be explicitly scheduled rather than waiting until someone discovers that the memory folder has become difficult to manage.

Trong thực tế, những nhiệm vụ kiểu “sau này rảnh sẽ dọn dẹp” thường sẽ không bao giờ xảy ra, cho đến khi hiệu suất hệ thống bắt đầu suy giảm do sự cạnh tranh của rất nhiều ký ức mâu thuẫn, lỗi thời và bán liên quan trong cửa sổ ngữ cảnh.

Mỗi khi bắt đầu một nhiệm vụ mới, hãy cho vòng lặp quét trước một câu tóm tắt trong tệp bộ nhớ để xác định những kinh nghiệm nào liên quan thực sự đến nhiệm vụ hiện tại, và chỉ tải những nội dung liên quan đó.

Đồng thời, cần yêu cầu rõ ràng hệ thống: nếu không có ký ức hiện có nào phù hợp với nhiệm vụ hiện tại, hãy trực tiếp thông báo rằng không có kinh nghiệm phù hợp.

Đừng vì hệ thống ghi nhớ đã tồn tại mà ép buộc áp dụng kinh nghiệm quá khứ vào một vấn đề mới hoàn toàn khác biệt.

Tiếp theo, cần xác định thời điểm bộ vòng lặp này tự động chạy mà không cần khởi động bằng tay.

Các cách kích hoạt có thể bao gồm:

• Công việc định thời Cron;
• File change listener;
• Bộ kích hoạt theo chu kỳ dựa trên lịch;
• Được kích hoạt khi có sự thay đổi trong sự kiện hoặc trạng thái bên ngoài.

Bước này sẽ biến một hệ thống chỉ có thể được khởi động thủ công thành một hệ thống có thể tiếp tục chạy khi bạn đang ngủ.

Thật讽刺 khi bước này thường là bước dễ thực hiện nhất trong toàn bộ danh sách, nhưng lại là bước nhiều người vẫn trì hoãn, ngay cả khi họ đã hoàn thành các thành phần khác.

Trước khi sử dụng vòng lặp cho bất kỳ nhiệm vụ quan trọng nào, cần chủ động kiểm tra bốn mô hình lỗi.

Kiểm tra một: Nhiệm vụ không thể hoàn thành

Cho hệ thống một nhiệm vụ thực sự không thể giải quyết, xác minh rằng trình quản lý có thể thoát theo điều kiện dừng, thay vì lặp vô hạn.

Nếu một chu trình chỉ được kiểm thử trên những nhiệm vụ có thể hoàn thành thành công, thì nó chưa bao giờ chứng minh được khả năng thất bại một cách thanh lịch.

Kiểm tra hai: Kết quả trông hợp lý nhưng thực tế là sai

Cung cấp cho người đánh giá một đầu ra mà bạn chắc chắn có sai sót nhỏ.

Kết quả này nên đọc rất trôi chảy, nhưng chứa một sai sót về sự thật hoặc logic mà bạn cố ý đưa vào.

Hãy quan sát xem người đánh giá có thể phát hiện ra vấn đề hay không, thay vì chỉ phê duyệt vì nội dung nghe có vẻ hợp lý.

Kiểm tra 3: Người xây dựng và người đánh giá chia sẻ điểm mù của mô hình

Nếu người xây dựng và người đánh giá sử dụng cùng một mô hình nền tảng, có thể cố ý thêm một lỗi điển hình mà mô hình đó thường mắc phải, để quan sát xem người đánh giá có bỏ qua nó hay không.

Nếu người đánh giá và người xây dựng có cùng những điểm mù, thì sự phân tách vai trò được thiết kế ở Bước 6 sẽ mất đi ý nghĩa.

Kiểm tra bốn: Tính chi phí vận hành trong trường hợp xấu nhất

Tính toán chi phí tối đa mà chu trình này tiêu tốn trong trường hợp xấu nhất, dựa trên số lần chỉnh sửa tối đa, sử dụng mô hình đắt nhất và đầu ra dài nhất trong phạm vi hợp lý.

Sau đó hãy hỏi bản thân một cách trung thực:

Would you feel uneasy if this number appeared on a real bill?

Hoàn thành bốn bài kiểm tra này trước khi xử lý các nhiệm vụ quan trọng trong chu kỳ tin tưởng sẽ giúp phát hiện sớm phần lớn các vấn đề tiềm ẩn.

Nếu không, những vấn đề này rất có thể sẽ lần đầu tiên xuất hiện trước mặt khách hàng hoặc quản lý, hoặc trực tiếp thể hiện trên hóa đơn của bạn, thay vì xuất hiện trong một bài kiểm tra mà bạn chủ động kiểm soát.

Khi chu trình có thể chạy ổn định, đừng để tất cả các vai trò sử dụng cùng một mô hình bạn yêu thích.

Các vai trò khác nhau trong chu trình có yêu cầu khác nhau đối với năng lực của mô hình.

Người xây dựng

Các nhà phát triển thường nên sử dụng mô hình mạnh nhất.

Vì nó đảm nhận công việc suy luận phức tạp và tạo nội dung chính. Nếu sử dụng mô hình không đủ mạnh ở đây, chất lượng phiên bản đầu tiên sẽ giảm xuống, và có thể cần nhiều vòng chỉnh sửa hơn sau đó.

Cuối cùng, chi phí dành để sửa chữa bản nháp chất lượng thấp có thể cao hơn chi phí sử dụng mô hình mạnh hơn ngay từ đầu.

Reviewer

Người đánh giá có nhiệm vụ kiểm tra theo các tiêu chí rõ ràng, thường không đòi hỏi khả năng sáng tạo cao.

Khi tiêu chuẩn đủ cụ thể, một mô hình nhỏ hơn, chi phí thấp hơn và nhanh hơn thường cũng có thể hoàn thành nhiệm vụ đánh giá một cách đáng tin cậy.

Một mô hình nhỏ nếu hoạt động dựa trên danh sách kiểm tra cực kỳ rõ ràng, độ ổn định của nó có thể gần bằng mô hình lớn, nhưng chi phí và độ trễ đều thấp hơn đáng kể.

Manager

Bộ quản lý chỉ định tuyến theo các quy tắc đã được lập trình sẵn và hầu như không bao giờ cần sử dụng mô hình đắt nhất.

Nhiệm vụ của nó là thực thi các logic đã được định nghĩa sẵn, chứ không phải thực hiện suy luận mở.

Ngoài ra, bất kể hiệu suất của người xây dựng và người đánh giá ra sao, trình quản lý sẽ được chạy ít nhất một lần trong mỗi vòng lặp, do đó, chi phí cho mỗi lần gọi của nó đặc biệt đáng chú ý.

Cấu hình phân tầng hợp lý thường là:

• Mô hình mạnh chịu trách nhiệm xây dựng;
• Các mô hình rẻ và ổn định chịu trách nhiệm đánh giá thường xuyên;
• Các mô hình hoặc chương trình quy tắc chi phí thấp chịu trách nhiệm định tuyến và quản lý.

Việc tối ưu chi phí đáng kể trong hệ thống vòng lặp thường đến từ sự khớp vai trò mô hình này.

Nhiều người cho rằng kiểm soát chi phí có nghĩa là giảm số vòng lặp hoặc số lần chỉnh sửa. Thực tế, phương pháp hiệu quả hơn là điều chỉnh chi phí mô hình phù hợp với mức độ khó thực tế của từng vai trò trong vòng lặp.

Sau khi vòng lặp đầu tiên thành công, mọi người dễ dàng muốn ngay lập tức xây dựng nhiều vòng lặp cùng lúc, xử lý song song năm nhiệm vụ khác nhau.

Even though the current architecture already supports this expansion, you should restrain this impulse.

Bạn nên để vòng lặp đầu tiên chạy ổn định trong đủ lâu để thực sự không còn cần kiểm tra kỹ từng đầu ra của nó.

Điều này không có nghĩa là một lần trình diễn mà mọi người đều chăm chú xem đã thành công ngay lập tức, mà là nó vẫn có thể liên tục vượt qua các cuộc kiểm tra ngẫu nhiên bằng tay sau một thời gian vận hành thực tế.

Chỉ khi đạt đến trạng thái này, mới nên bắt đầu xây dựng chu kỳ thứ hai.

Vòng lặp thứ hai nên xử lý một nhiệm vụ rõ ràng khác với vòng lặp đầu tiên.

Chỉ như vậy mới có thể xác minh được liệu kiến trúc nền tảng có thực sự mang tính phổ quát hay chỉ đơn thuần là được tinh chỉnh ngày càng tinh vi hơn cho cùng một nhiệm vụ.

Sau khi chạy đồng thời nhiều vòng lặp, bạn cần thiết lập một giao diện giám sát tập trung để theo dõi tổng thể chi phí và tình trạng kích hoạt điều kiện dừng của tất cả các vòng lặp, thay vì chỉ xem từng vòng lặp riêng lẻ.

Riêng lẻ, một ngân sách nhiệm vụ tuần hoàn có thể hoàn toàn hợp lý.

Tuy nhiên, nếu cả mười chu kỳ đều hoạt động trong phạm vi ngân sách của chúng, tổng chi phí vẫn có thể đạt đến một mức độ khiến bạn bất ngờ.

Do dữ liệu độc lập của mỗi chu kỳ trông rất bình thường, rủi ro này thường chỉ được phát hiện khi hóa đơn tổng hợp xuất hiện.

Ngoài các nhiệm vụ đã hoàn thành thành công, cần ghi lại chi tiết từng lần điều kiện dừng được kích hoạt.

Nếu một chu kỳ thường xuyên chạm đến số lần sửa đổi tối đa, trong khi các chu kỳ khác hiếm khi xảy ra tình trạng này, tín hiệu mà nó truyền tải có thể không phải là “nhiệm vụ này đặc biệt khó khăn”, mà là:

• Tiêu chí đánh giá được thiết lập không hợp lý;
• Người đánh giá quá khắt khe, khiến bất kỳ kết quả nào cũng không thể vượt qua;
• Hệ thống đã kiểm tra các cơ sở khách quan sai lệch;
• Việc hoàn thành định nghĩa bản thân có vấn đề.

Nếu chỉ theo dõi các kết quả thành công và coi mỗi lần nâng cấp thủ công là những sự kiện ngẫu nhiên không liên quan đến nhau, thì mô hình này ở cấp độ thiết kế sẽ không được phát hiện.

Tiêu chuẩn rõ ràng nhất để xác định liệu sự thay đổi tư duy đã thực sự hoàn thành hay chưa là các chỉ số bạn quan tâm hàng ngày đã thay đổi.

Người điều khiển prompt quan tâm đến:

• Hôm nay đã viết được bao nhiêu lời nhắc hiệu quả?
• Prompt nào hiệu quả nhất;
• Làm thế nào để viết các hướng dẫn một cách tinh vi hơn.

Người thiết kế hệ thống quan tâm đến:

• Hiện có bao nhiêu chu trình đang chạy;
• Độ tin cậy của mỗi chu kỳ là bao nhiêu;
• Hệ thống đã giải phóng bao nhiêu thời gian;
• Những công việc nào đã không còn cần sự giám sát bằng tay.

Nếu bạn vẫn đo lường năng suất của mình bằng số lượng lời nhắc đã nhập, thì sự thay đổi tư duy yêu cầu ở Bước 1 chưa thực sự được hoàn thành, bất kể đã xây dựng được bao nhiêu vòng lặp về mặt kỹ thuật.

Bước cuối cùng đã không còn hoàn toàn liên quan đến hệ thống của chính bạn.

It is used to verify whether you truly understand this method.

Bạn cần cố gắng giải thích năm hành động cơ bản cho một người khác mà không phụ thuộc vào các thuật ngữ phức tạp:

Nhận diện, chuyển giao, xác minh, lưu trữ bền vững, lập lịch.

Nếu bạn có thể chỉ dựa vào năm hành động này và các bước trước đó để hướng dẫn người khác xây dựng chu trình đầu tiên của họ, thì bạn đã hoàn thành sự chuyển đổi được mô tả trong lộ trình này.

Bạn không còn là người đứng bên trong vòng lặp, liên tục nhập lệnh tiếp theo nữa.

Bạn đã trở thành người đứng ngoài vòng lặp, thiết kế hệ thống và quan sát nó tự vận hành.

Sau khi bỏ qua các bước, bốn chi phí sẽ tích lũy âm thầm

At the end of the article, it is necessary to provide a warning.

Bỏ qua các bước trong bản lộ trình này thường không dẫn đến sự cố hệ thống ngay lập tức.

Sự thất bại của nó thường diễn ra lặng lẽ, thậm chí khó phát hiện trong một thời gian dài, cho đến khi vấn đề đã tích lũy đến mức nghiêm trọng.

Khi bạn bỏ qua bước 6 và bước 7, không thiết lập người đánh giá độc lập thực sự và không cung cấp cơ sở khách quan đáng tin cậy, việc xác minh nợ sẽ bắt đầu tích lũy.

Vòng lặp dường như vẫn đang hoạt động bình thường vì kết quả được tạo ra “nghe có vẻ ổn”.

Cho đến khi một lỗi tích lũy qua hàng chục lần chạy và cuối cùng bị phát hiện, bạn mới nhận ra rằng hệ thống từ đầu đã không thực sự xác định được kết quả có đúng hay không.

Việc bỏ qua bước 20 có thể dẫn đến suy giảm hiểu biết.

Bạn vẫn đang chạy vòng lặp mà bạn từng xây dựng, nhưng đã không còn giải thích rõ ràng tại sao từng thành phần lại tồn tại, cũng như không thể gỡ lỗi hiệu quả khi hệ thống gặp sự cố.

Lý do là vì bạn chưa thực sự thấm nhuần logic đằng sau kiến trúc này.

Sự đầu hàng nhận thức xảy ra nếu bước thứ nhất chưa bao giờ thực sự hoàn thành.

Ngay cả khi hệ thống xác minh đã được chứng minh độ tin cậy qua thời gian dài vận hành, bạn vẫn sẽ kiểm tra lại từng đầu ra một cách thủ công do thói quen.

Hành vi này trông có vẻ cẩn trọng, nhưng thực tế lại làm mất đi toàn bộ ý nghĩa của việc xây dựng hệ thống.

Nếu bỏ qua bước 10 và không thiết lập điều kiện dừng thực sự cho vòng lặp, chi phí tiêu thụ Token và gọi có thể mất kiểm soát.

Bạn thường không nhận ra vấn đề ngay khi hệ thống bắt đầu mất kiểm soát, mà chỉ phát hiện ra khi hóa đơn cuối cùng xuất hiện, lúc đó mới biết chu trình đã thực hiện rất nhiều lời gọi vô ích.

Tất cả các chi phí trên đều có thể tránh được.

Cách tránh chúng luôn là cùng một kỷ luật:

Xây dựng theo thứ tự, đừng bỏ qua những bước trông có vẻ không quá ấn tượng.

Những phần nhàm chán nhất thường mới là những phần thực sự phát huy tác dụng:

• Định nghĩa hoàn thành rõ ràng;
• Điều kiện dừng đáng tin cậy;
• Cơ sở khách quan có thể xác minh;
• Independent review mechanism.

So sánh với những phần nghe có vẻ hấp dẫn hơn—những lời nhắc khéo léo, các sơ đồ kiến trúc hệ thống phức tạp—lại không quan trọng bằng những gì mọi người tưởng tượng.

Điều thực sự quyết định chất lượng hệ thống là hệ thống bạn xây dựng có biết:

• Khi nào bạn là người đúng;
• Khi nào bạn đang sai;
• Khi nào phải dừng lại.

Đó là toàn bộ sự khác biệt giữa người vận hành prompt và người thiết kế hệ thống.

Sự khác biệt không nằm ở ai thông minh hơn, cũng không nằm ở ai có thể viết ra những lời nhắc đẹp mắt hơn.

Sự khác biệt thực sự nằm ở việc bạn có đủ kỷ luật để nghiêm túc xây dựng những phần nhàm chán, dễ bị bỏ qua, nhưng lại thực sự quyết định độ tin cậy của hệ thống hay không.