Kỹ Thuật Vòng Lặp: Lộ Trình 20 Bước Từ Người Viết Prompt Đến Kỹ Sư Thiết Kế Hệ Thống
Vào tháng 6 năm 2026, ba người độc lập đã cùng đến một ý tưởng trong vòng một tuần.
Peter Steinberger, người xây dựng OpenClaw, công khai nói rằng bạn nên ngừng viết prompt cho các agent lập trình và bắt đầu thiết kế các vòng lặp có thể tự động viết prompt thay bạn. Cùng lúc đó, Boris Cherny, người dẫn dắt Claude Code tại Anthropic, cho biết anh ấy không còn viết prompt trực tiếp cho Claude nữa, thay vào đó anh ấy có các vòng lặp tự động viết prompt cho Claude và quyết định việc cần làm - công việc thực sự của anh ấy là viết các vòng lặp. Vài ngày sau, Addy Osmani, một kỹ sư tại Google, đã viết về khái niệm này và đặt tên cho nó: kỹ thuật vòng lặp (loop engineering).
Không ai trong số họ phát minh ra phương pháp này từ con số không. Họ chỉ đặt tên cho một thứ đã và đang diễn ra, bởi vì các công cụ bên dưới nó đã âm thầm vượt qua một ngưỡng quan trọng. Các agent lập trình đã trở nên đủ đáng tin cậy để hoàn thành một tác vụ thực sự mà không cần giám sát. Chi phí lập lịch đã trở nên đủ rẻ để chạy một tác vụ lặp đi lặp lại theo thời gian, không còn bị coi là lãng phí. Chi phí cho một lần chạy agent đã giảm đủ thấp để thử nghiệm năm lần còn rẻ hơn là suy nghĩ kỹ một lần.
Ngưỡng đó là lý do lộ trình này tồn tại. Kỹ thuật viết prompt là kỹ năng khi con người cần ngồi trước bàn phím và chỉ đạo agent từng dòng một. Kỹ thuật vòng lặp là kỹ năng bây giờ, khi agent có thể được giao một mục tiêu và để tự chạy. Đây là lộ trình hoàn chỉnh 20 bước từ kỹ thuật này sang kỹ thuật kia, theo đúng thứ tự, bởi vì thứ tự quan trọng hơn bất kỳ bước riêng lẻ nào.
Đây là lý do tại sao thứ tự cụ thể lại quan trọng, trước khi đi vào các bước. Kỹ thuật vòng lặp không phải là một kỹ năng đơn lẻ mà bạn có hoặc không có. Nó là một chồng lớp, nơi mỗi lớp phụ thuộc vào lớp bên dưới thực sự vững chắc. Xây dựng một bộ kích hoạt lập lịch, bước 14, trước khi bạn có một điều kiện dừng thực sự, bước 10, chỉ có nghĩa là bạn đã tự động hóa một hệ thống mà giờ đây có thể lãng phí tiền ngay cả khi không có ai giám sát, thay vì chỉ khi bạn đang theo dõi. Xây dựng bộ nhớ, bước 11, trước khi bạn có xác thực thực sự, các bước 6 và 7, có nghĩa là bạn đang cẩn thận ghi lại những bài học kinh nghiệm từ một Judge có thể đang đóng dấu chấp nhận cho đầu ra tồi, khiến cho lớp bộ nhớ trở nên có hại thay vì chỉ vô dụng. Nhảy cóc trong danh sách này không chỉ có nghĩa là bỏ lỡ một tính năng. Nó có nghĩa là xây dựng những phần trông có vẻ thú vị trên một nền tảng không thể thực sự hỗ trợ chúng, và chỉ phát hiện ra điều đó khi mọi thứ đã sai ở quy mô lớn.
Giai Đoạn Một: Sự Chuyển Dịch Tư Duy (Bước 1 đến 4)
Bước 1: Chấp Nhận Rằng Bạn Mới Là Nút Thắt Cổ Chai, Không Phải Model
Bước thực sự đầu tiên không phải là kỹ thuật. Đó là thừa nhận rằng yếu tố giới hạn trong quy trình làm việc hiện tại của bạn không phải là khả năng của model, mà chính là sự hiện diện của bạn trong vòng lặp. Mỗi lần bạn ngồi chờ phản hồi, đọc nó, rồi gõ lệnh tiếp theo, bạn là phần chậm nhất của hệ thống với một khoảng cách rất lớn. Model có thể hành động, xác minh và thử lại nhanh hơn nhiều so với khả năng bạn giám sát nó.
Bước này không có prompt đi kèm. Đó là một quyết định. Cho đến khi bạn thực sự tin vào điều này, mọi bước tiếp theo sẽ có cảm giác như công việc không cần thiết thay vì bản chất thực sự của nó: loại bỏ nút thắt cổ chai thực sự.
Bước 2: Ngừng Nhầm Lẫn Giữa Prompt Dài Hơn Với Hệ Thống Tốt Hơn
Bản năng khi có điều gì đó sai là thêm một hướng dẫn khác vào cùng một prompt. Qua nhiều tháng, điều này tạo ra một prompt là một bức tường dày đặc, mâu thuẫn với chính nó, đến nỗi model không thể giữ tất cả trong bộ nhớ làm việc cùng một lúc, vì vậy nó chỉ khớp mẫu với phần nào có vẻ gần đây nhất và âm thầm bỏ qua phần còn lại.
Kỹ thuật vòng lặp thay thế hoàn toàn bản năng này. Thay vì thêm một quy tắc khác vào một prompt, bạn thêm một thành phần khác vào hệ thống. Một bước xác minh. Một file bộ nhớ. Một bộ kích hoạt theo lịch trình. Bản thân prompt nên ngắn hơn theo thời gian khi hệ thống xung quanh nó trở nên mạnh mẽ hơn, chứ không phải ngược lại.
Bước 3: Học Cách Nhìn Mọi Tác Vụ Như Năm Bước Di Chuyển
Bất kỳ lượt nào của một vòng lặp, bất kể lĩnh vực cụ thể, đều được phân tích thành năm bước di chuyển. Discovery (Khám phá), tìm ra điều thực sự cần xảy ra. Handoff (Bàn giao), chuyển tác vụ cho bộ phận sẽ thực thi nó. Verification (Xác minh), kiểm tra kết quả dựa trên một thứ gì đó thực tế. Persistence (Lưu trữ), ghi lại những gì đã xảy ra để không bị mất. Scheduling (Lập lịch), quyết định khi nào việc này 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ỉ có hai bước di chuyển rõ ràng, Discovery và Handoff, được thực hiện thủ công, trong một cửa sổ chat. Ba bước còn lại hoặc không tồn tại hoặc xảy ra vô hình trong đầu của người đó. Kỹ thuật vòng lặp là thực hành làm cho cả năm bước di chuyển trở nên rõ ràng và tự động.
Bước 4: Xác Định Tác Vụ Ứng Cử Viên Thực Sự Đầu Tiên Của Bạn
Trước khi xây dựng bất cứ thứ gì, hãy chọn một tác vụ bạn đã làm lặp đi lặp lại, với một tiêu chuẩn bạn có thể viết ra nếu được yêu cầu. Không phải vấn đề khó nhất của bạn. Không phải một thứ gì đó hoàn toàn mới lạ. Một tác vụ với một định nghĩa hoàn thành thực sự, có thể nhận biết được, một thứ mà đồng nghiệp có thể nhìn vào và ngay lập tức đồng ý là đã hoàn thành đúng hay chưa. Ràng buộc này quan trọng hơn vẻ bề ngoài của nó. Một tác vụ không có định nghĩa hoàn thành rõ ràng thì không thể xây dựng bước ba, Verification, cho nó, và một vòng lặp không có xác minh thực sự không phải là một vòng lặp, nó chỉ là một phỏng đoán không có người giám sát.
Giai Đoạn Hai: Xây Dựng Vòng Lặp Đầu Tiên (Bước 5 đến 9)
Bước 5: Viết Định Nghĩa Hoàn Thành Trước Khi Viết Bất Kỳ Prompt Nào
Đây là bước mà hầu hết mọi người bỏ qua và là bước quyết định liệu mọi thứ sau nó có hoạt động hay không. Trước khi bạn viết một hướng dẫn duy nhất cho agent, hãy viết ra, bằng ngôn ngữ đơn giản, chính xác kết quả đúng trông như thế nào. Các tiêu chí cụ thể, có thể kiểm tra, không phải một cảm giác mơ hồ về chất lượng.
ĐỊNH NGHĨA HOÀN THÀNH cho [tên tác vụ]:
- [Tiêu chí cụ thể, có thể kiểm tra 1]
- [Tiêu chí cụ thể, có thể kiểm tra 2]
- [Tiêu chí cụ thể, có thể kiểm tra 3] Tác vụ này KHÔNG hoàn thành nếu bất kỳ điều nào ở trên bị thiếu, ngay cả khi đầu ra trông hoàn chỉnh và trau chuốt.
Nếu bạn không thể điền thông tin này cho tác vụ đã chọn, hãy quay lại bước 4 và chọn một tác vụ khác.
Bước 6: Tách Biệt Builder Khỏi Judge
Quyết định kiến trúc quan trọng nhất trong bất kỳ vòng lặp nào. Vai trò tạo ra công việc và vai trò kiểm tra công việc phải được tách biệt, bởi vì một model xem xét lại đầu ra của chính nó trong cùng một luồng đã tạo ra nó có xu hướng bảo vệ đầu ra đó thay vì thực sự xem xét nó một cách nghiêm túc.
Builder có quyền tự do sáng tạo và tạo ra một bản thử đầu tiên. Judge nhận đầu ra của Builder cộng với định nghĩa hoàn thành từ bước 5, và không có gì khác cần phải thuyết phục. Lý tưởng nhất là Judge cũng có quyền truy cập vào một thứ mà Builder không có: một bộ kiểm thử, tài liệu nguồn gốc, dữ liệu trực tiếp, để phán quyết của nó đến từ bằng chứng thực sự, không chỉ là một ý kiến thứ hai được hình thành theo cùng cách như ý kiến đầu tiên.
Bước 7: Cung Cấp Cho Judge Sự Thật Cơ Bản, Không Chỉ Là Một Ý Kiến
Một Judge chỉ nhìn thấy đầu ra của Builder có thể cho bạn biết liệu nó có mạch lạc hay không. Nó không thể cho bạn biết liệu nó có thực sự đúng hay không. Đối với tác vụ lập trình, sự thật cơ bản là bộ kiểm thử và đầu ra thực thi thực tế. Đối với tác vụ nội dung, đó là tài liệu nguồn gốc và brief, được đặt cạnh bản nháp. Đối với tác vụ nghiên cứu, đó là các tài liệu thực tế được cho là sẽ được sử dụng.
Nếu bạn không thể đặt tên cho sự thật cơ bản cụ thể mà Judge của bạn sẽ kiểm tra dựa trên đó, vòng lặp của bạn chưa có xác minh thực sự, bất kể ngôn ngữ của Judge nghe có vẻ tự tin đến đâu.
Bước 8: Viết Định Dạng Bàn Giao Trước Khi Viết Prompt Bàn Giao
Đầu ra của Builder và phán quyết của Judge đều cần một cấu trúc xác định, không phải văn xuôi tự do, nếu không Manager trong bước tiếp theo sẽ không có gì đáng tin cậy để định tuyến.
ĐẦU RA CỦA BUILDER: sản phẩm bàn giao + độ tin cậy + những điều chưa chắc chắn đã biết
PHÁN QUYẾT CỦA JUDGE: ĐẠT / KHÔNG ĐẠT / CẦN SỬA ĐỔI + các vấn đề cụ thể được tìm thấy + sự thật cơ bản nào đã được kiểm tra dựa trên
Bước 9: Chạy Thủ Công Một Lần, Toàn Bộ Quy Trình, Trước Khi Tự Động Hóa Bất Cứ Thứ Gì
Trước khi bạn kết nối lập lịch hoặc tự động thử lại, hãy tự chạy toàn bộ chuỗi Builder-rồi-Judge một lần bằng tay. Đọc phán quyết của Judge một cách phê phán. Bạn có đồng ý với nó không? Nếu Judge đã thông qua một thứ bạn biết là sai, hoặc không đạt một thứ thực sự ổn, hãy sửa chữa sự thật cơ bản hoặc các tiêu chí trước khi tiếp tục. Tự động hóa một bước xác minh bị hỏng chỉ tạo ra kết quả hỏng nhanh hơn.
Một Ví Dụ Cụ Thể Qua Các Bước 5 Đến 9
Để làm cho năm bước cuối cùng trở nên cụ thể, đây là cách chúng hoạt động trên một tác vụ thực tế, phổ biến: biến một tài liệu nguồn thô thành một piece nội dung hoàn chỉnh.
Định nghĩa hoàn thành, từ bước 5: mọi tuyên bố thực tế trong bản nháp đều truy xuất đến một thứ gì đó thực sự có trong tài liệu nguồn. Bản nháp đáp ứng mọi yêu cầu cụ thể trong brief: độ dài, giọng điệu, cấu trúc yêu cầu. Lập luận cốt lõi tồn tại rõ ràng, không bị pha loãng bởi nội dung nhồi nhét.
Builder, từ bước 6, nhận nguồn và brief và tạo ra một bản nháp, cùng với một tuyên bố rõ ràng về những gì nó không chắc chắn khi viết: một con số nó không hoàn toàn chắc chắn có trong nguồn, một tuyên bố nó suy luận chứ không phải tìm thấy được nói thẳng ra.
Judge, từ bước 7, nhận bản nháp và nguồn gốc được đặt cạnh nhau, không bao giờ chỉ bản nháp một mình, và kiểm tra từng tiêu chí trong ba tiêu chí của định nghĩa hoàn thành một cách riêng biệt, trả về kết quả đạt hoặc không đạt cho từng mục riêng lẻ thay vì một điểm tổng thể hỗn hợp. Gộp ba kiểm tra riêng biệt thành một phán quyết duy nhất sẽ che giấu chính xác khía cạnh nào thực sự thất bại, đây là cách phổ biến nhất mà một vòng lặp đang hoạt động âm thầm ngừng đưa ra phản hồi hữu ích.
Định dạng bàn giao, từ bước 8, có nghĩa là phán quyết của Judge đến như một đối tượng có cấu trúc, không phải một đoạn văn xuôi có bảo lưu: ba kết quả đạt hoặc không đạt rõ ràng với một lý do cụ thể đính kèm cho bất kỳ sự thất bại nào.
Chạy thủ công một lần, theo bước 9, trước khi tự động hóa bất cứ thứ gì, là thứ bắt được trường hợp Judge của bạn quá dễ dãi, thông qua một bản nháp có số liệu bịa đặt vì phong cách viết trau chuốt, hoặc quá nghiêm ngặt, không đạt một bản nháp vì sở thích phong cách chưa bao giờ thực sự có trong brief. Cả hai chế độ thất bại đều phổ biến trong lần thử đầu tiên, và cả hai đều rẻ hơn nhiều để bắt thủ công một lần hơn là phát hiện ra sau khi vòng lặp đã chạy năm mươi lần mà không có người giám sát.
Giai Đoạn Ba: Thêm Các Mảnh Còn Thiếu Của Vòng Lặp (Bước 10 đến 14)
Bước 10: Xây Dựng Manager Và Điều Kiện Dừng Của Nó
Manager đọc phán quyết của Judge và quyết định điều gì xảy ra tiếp theo. Đây cũng là nơi điều kiện dừng của vòng lặp tồn tại, và nó phải được viết dưới dạng logic cứng, không phải một hướng dẫn mềm mà model có thể thuyết phục vượt qua.
ĐIỀU KIỆN DỪNG:
Số lần sửa đổi tối đa: 3. Ở lần phán quyết không đạt thứ 3, hãy chuyển lên cho con người với toàn bộ lịch sử, không cố gắng chu kỳ thứ 4.
Ngưỡng chất lượng: mọi mục trong định nghĩa hoàn thành phải hiển thị ĐẠT.
Trần ngân sách: nếu tác vụ này vượt quá [X] chi phí hoặc [Y] thời gian, hãy 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. Nó là một trách nhiệm pháp lý đang chờ ngày mà tác vụ hóa ra thực sự không thể giải quyết được. Lý do cụ thể tại sao một hướng dẫn mềm thất bại ở đây đáng để hiểu, không chỉ chấp nhận. "Dừng khi nó đủ tốt" bên trong một prompt là một gợi ý, và một model dưới đủ áp lực, đã thất bại nhiều lần sửa đổi, thường sẽ thuyết phục bản thân nó rằng nỗ lực hiện tại là đủ gần để vượt qua, chính xác là vì nó muốn tạo ra một giải pháp thỏa mãn cho tác vụ. Một bộ đếm lặp cứng được kiểm tra một cách cơ học bởi mã, hoặc bởi một quy tắc rõ ràng mà Manager không thể lý luận để vượt qua, không có chế độ thất bại đó.
Bước 11: Thêm Bộ Nhớ, Để Vòng Lặp Nhớ Qua Các Lần Chạy
Một vòng lặp bắt đầu từ con số không mỗi lần nó chạy không có ký ức về những gì nó đã học lần trước. Thêm một lớp bộ nhớ đơn giản: một file cho mỗi bài học thực sự mới, với một bản tóm tắt một dòng ở đầu, ghi lại những gì đã được học hoặc sửa chữa và tại sao nó quan trọng. Quan trọng là, chỉ ghi lại những gì chưa được ghi lại ở nơi khác, bộ nhớ trùng lặp là nhiễu, không phải kiến thức.
Kỷ luật làm cho bước này thực sự hoạt động lâu dài là sự kiềm chế tại thời điểm ghi. Bản năng là ghi lại mọi thứ đã xảy ra trong một phiên, điều này tạo ra chính xác vấn đề bảng điểm phình to mà lộ trình này đã cảnh báo ở bước 2, chỉ được chuyển vào một thư mục bộ nhớ thay vì một prompt. Một bài học đáng để viết ra là một thứ sẽ tốn thời gian thực để khám phá lại nếu bị lãng quên, không phải một bản ghi về công việc thường ngày đã thành công như mong đợi.
Bước 12: Thêm Một Lần Hợp Nhất Theo Lịch Trình
Bộ nhớ một mình cuối cùng tạo ra vấn đề tương tự như một prompt phình to: hàng chục file, nhiều file nói các phiên bản hơi khác nhau của cùng một thứ. Theo một lịch trình định kỳ, một tuần một lần là hợp lý, hãy xem xét các file bộ nhớ, hợp nhất các bản sao thành các bài học duy nhất, sắc nét hơn, và xóa bất cứ thứ gì đã được chứng minh là sai. Mục tiêu là ít file hơn với mật độ cao hơn mỗi file, không phải một đống ngày càng lớn.
Bước này là bước mà hầu hết mọi người bỏ qua hoàn toàn, bởi vì nó không tạo ra khả năng mới có thể nhìn thấy được, nó chỉ ngăn chặn một vấn đề trong tương lai. Sự vô hình đó chính xác là lý do tại sao nó cần được lên lịch rõ ràng thay vì để xảy ra bất cứ khi nào ai đó nhận thấy thư mục bộ nhớ đã trở nên cồng kềnh, điều này trong thực tế có nghĩa là nó không bao giờ xảy ra cho đến khi hiệu suất của vòng lặp đã bắt đầu suy giảm dưới sức nặng của các bài học mâu thuẫn, nửa liên quan cạnh tranh cho cùng một cửa sổ ngữ cảnh.
Bước 13: Thêm Bước Truy Xuất
Khi bắt đầu bất kỳ lần chạy mới nào, hãy yêu cầu vòng lặp quét các bản tóm tắt một dòng trong bộ nhớ, xác định những bài học nào thực sự liên quan đến tác vụ hiện tại, và chỉ tải những bài học đó. Hướng dẫn rõ ràng nó nói khi không có gì trong bộ nhớ phù hợp, thay vì ép một bài học trong quá khứ không liên quan vào một tình huống mới chỉ vì bộ nhớ tồn tại.
Bước 14: Thêm Một Bộ Kích Hoạt Lập Lịch
Quyết định khi nào vòng lặp này chạy mà không cần bạn bắt đầu nó thủ công. Một cron job. Một file watcher. Một bộ kích hoạt dựa trên lịch định kỳ. Đây là bước biến một hệ thống bạn chạy theo yêu cầu thành một hệ thống chạy trong khi bạn ngủ, và nó thường là bước dễ nhất trong toàn bộ danh sách này, và là bước mà hầu hết mọi người không bao giờ bận tâm thực hiện ngay cả sau khi xây dựng mọi thứ khác.
Giai Đoạn Bốn: Mở Rộng Và Củng Cố (Bước 15 đến 18)
Bước 15: Kiểm Tra Ứng Suất Vòng Lặp Trước Khi Tin Tưởng Nó
Trước khi dựa vào vòng lặp này cho bất cứ điều gì thực sự, hãy cố tình kiểm tra nó đối với bốn chế độ thất bại.
- Đưa cho nó một phiên bản thực sự không thể giải quyết của tác vụ và xác nhận Manager thực sự dừng lại thay vì lặp vô hạn, bởi vì một vòng lặp chỉ được kiểm tra trên các tác vụ nó có thể hoàn thành chưa bao giờ thực sự chứng minh được nó biết cách thất bại một cách duyên dáng.
- Đưa cho Judge một đầu ra 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 lô-gic cụ thể mà bạn đã cố tình cài đặt, và xác nhận nó thực sự bắt được lỗ hổng thay vì thông qua một thứ nghe có vẻ hợp lý.
- Nếu Builder và Judge chia sẻ cùng một model cơ bản, hãy đưa cho Judge một sai lầm mà model đó đặc trưng mắc phải và xem liệu nó có bỏ qua sai lầm đó không, bởi vì một Judge chia sẻ điểm mù của Builder phá hủy toàn bộ mục đích của việc tách biệt từ bước 6.
- Tính toán chi phí tồi tệ nhất của vòng lặp chạy đến giới hạn sửa đổi tối đa của nó, sử dụng các cuộc gọi model đắt nhất và đầu ra dài nhất hợp lý của bạn, và quyết định trung thực liệu con số đó, xuất hiện trên một hóa đơn thực tế, có làm bạn lo lắng hay không.
Chạy bốn bài kiểm tra này trước khi tin tưởng một vòng lặp với bất cứ điều gì quan trọng sẽ bắt được phần lớn các thất bạ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, thay vì trong một bài kiểm tra có kiểm soát mà bạn đã cố tình chạy.
Bước 16: Định Tuyến Tác Vụ Đến Đúng Model, Không Phải Cùng Một Model Mỗi Lần
Khi một vòng lặp hoạt động, hãy chống lại thói quen chạy mọi phần của nó trên một model yêu thích duy nhất của bạn. Vai trò Builder thường được hưởng lợi từ model mạnh nhất của bạn, vì nó đang thực hiện lý luận khó khăn thực sự và một model yếu hơn ở đây tạo ra một bản nháp đầu tiên tồi tệ hơn, tốn nhiều chu kỳ sửa đổi hơn để sửa chữa so với chi phí để tạo ra tốt ngay từ đầu.
Vai trò Judge, kiểm tra dựa trên một tiêu chuẩn viết cụ thể, thường hoạt động đáng tin cậy không kém trên một model nhỏ hơn, rẻ hơn, nhanh hơn, vì nó không được yêu cầu phải sáng tạo, chỉ nhất quán, và một model nhỏ hơn kiểm tra dựa trên một danh sách kiểm tra cực kỳ cụ thể thường sánh ngang với một model lớn hơn với một phần nhỏ chi phí và độ trễ.
Vai trò Manager, định tuyến dựa trên các quy tắc bạn đã viết ra, hầu như không bao giờ cần model đắt nhất của bạn, vì công việc của nó là thực thi logic bạn đã chỉ định, không phải lý luận mở, và nó chạy ít nhất một lần cho mỗi lần lặp bất kể Builder và Judge hoạt động như thế nào, điều này làm cho chi phí cho mỗi cuộc gọi của nó quan trọng hơn khả năng thô của nó.
Cách tiếp cận phân tầng này, model đắt tiền cho xây dựng, model rẻ và nhất quán cho việc đánh giá các kiểm tra thường quy, model rẻ cho định tuyến, thường là nơi tiết kiệm chi phí thực sự trong một vòng lặp đến từ đâu. Hầu hết mọi người cho rằng kiểm soát chi phí có nghĩa là ít vòng lặp hơn hoặc ít sửa đổi hơn. Nó thực sự đến từ việc khớp chi phí model với độ khó thực tế của từng vai trò cụ thể bên trong vòng lặp bạn đã xây dựng.
Bước 17: Mở Rộng Sang Vòng Lặp Thứ Hai, Không Phải Năm Vòng Cùng Một Lúc
Sự cám dỗ khi vòng lặp đầu tiên hoạt động là xây dựng thêm vài vòng nữa ngay lập tức, 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ợ điều đó. Hãy chống lại điều này lâu hơn bạn cảm thấy thoải mái. Có được một vòng lặp hoạt động đủ đáng tin cậy để bạn thực sự đã 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 bài kiểm tra điểm mấu chốt thủ công của chính bạn trong một khoảng thời gian thực, không chỉ một bản demo thành công duy nhất mà mọi người tình cờ theo dõi chặt chẽ. Chỉ sau đó mới bắt đầu vòng lặp thứ hai, trên một tác vụ khác, lý tưởng là một tác vụ ánh xạ đến một thứ gì đó hoàn toàn khác với tác vụ đầu tiên, để bạn đang kiểm tra xem bộ khung cơ bản có khái quát hóa được không chứ không chỉ là điều chỉnh thêm cùng một tác vụ.
Bước 18: Tạo Một Góc Nhìn Chung Trên Tất Cả Các Vòng Lặp Đang Chạy
Khi bạn có nhiều hơn một vòng lặp đang chạy, hãy theo dõi một góc nhìn chung về chi phí và các trình kích hoạt điều kiện dừng trên tất cả chúng, không phải từng vòng lặp riêng lẻ. Một vòng lặp duy nhất với ngân sách hợp lý cho mỗi tác vụ trông hoàn toàn ổn một mình. Mười vòng lặp mỗi vòng trong ngân sách vẫn có thể tổng cộng thành một tổng số đáng báo động mà không ai nhận thấy cho đến khi hóa đơn tổng hợp đến, chính xác là vì việc theo dõi từng vòng lặp riêng lẻ trông ổn trong sự cô lập.
Ghi lại mọi trình kích hoạt điều kiện dừng cụ thể, không chỉ các lần hoàn thành thành công. Một vòng lặp liên tục đạt đến trần sửa đổi của nó, trong khi những vòng khác hiếm khi làm vậy, đang cho bạn biết tiêu chuẩn của Judge của nó bị hiệu chỉnh sai, quá nghiêm ngặt để thực sự vượt qua, hoặc đang kiểm tra dựa trên sự thật cơ bản sai hoàn toàn, không phải rằng tác vụ cơ bản chỉ đơn giản là khó. 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 sự leo thang là 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ụ thể của vòng lặp đó.
Giai Đoạn Năm: Trở Thành Một Kỹ Sư Thiết Kế Hệ Thống (Bước 19 và 20)
Bước 19: Ngừng Đo Lường Bản Thân Bằng Số Prompt Đã Viết
Dấu hiệu rõ ràng nhất cho thấy sự chuyển dịch đã thực sự xảy ra là một sự thay đổi trong những gì bạn chú ý hàng ngày. Một người viết prompt theo dõi họ đã viết bao nhiêu prompt tốt. Một kỹ sư thiết kế hệ thống theo dõi có bao nhiêu vòng lặp đang chạy, mỗi vòng lặp đáng tin cậy như thế nào, và bao nhiêu thời gian của chính họ đã được trả lại bởi các hệ thống không còn cần giám sát. Nếu bạn vẫn đang đo lường năng suất của chính mình bằng số prompt đã gõ, sự chuyển dịch tư duy từ bước một vẫn chưa thực sự hoàn tất, bất kể bạn đã xây dựng được bao nhiêu vòng lặp về mặt kỹ thuật.
Bước 20: Dạy Cho Người Khác Năm Bước Di Chuyển
Bước cuối cùng không còn thực sự là về hệ thống của riêng bạn nữa. Đó là xác nhận bạn đã thực sự nội hóa sự chuyển dịch bằng cách giải thích nó cho người khác mà không cần dùng đến biệt ngữ. Discovery (Khám phá), Handoff (Bàn giao), Verification (Xác minh), Persistence (Lưu trữ), Scheduling (Lập lịch). Nếu bạn có thể hướng dẫn người khác xây dựng vòng lặp đầu tiên của riêng họ chỉ sử dụng năm bước di chuyển đó và các bước trên, bạn đã thực hiện sự chuyển đổi thực sự mà lộ trình này mô tả. Bạn không còn là người bên trong vòng lặp, gõ lệnh tiếp theo. Bạn là người đã thiết kế nó, đứng bên ngoài, nhìn nó chạy.
Bốn Chi Phí Âm Thầm Tích Lũy Nếu Bạn Bỏ Qua Các Bước
Đáng để kết thúc bằng một lời cảnh báo, vì bỏ qua các bước trong lộ trình này không thất bại ầm ĩ, nó thất bại âm thầm, theo những cách chỉ xuất hiện nhiều sau đó.
Nợ xác minh tích lũy khi bạn bỏ qua các bước 6 và 7, xây dựng các vòng lặp không có Judge thực sự hoặc không có sự thật cơ bản thực sự. Vòng lặp trông như đang hoạt động vì đầu ra trông ổn, cho đến khi một sai lầm lặng lẽ nhân lên qua hàng chục lần chạy trước khi bất kỳ ai nhận thấy.
Sự mục nát về hiểu biết xảy ra khi bạn bỏ qua bước 20, chạy các vòng lặp bạn đã xây dựng một lần nhưng không còn có thể giải thích hoặc gỡ lỗi nếu chúng bị hỏng, bởi vì bạn chưa bao giờ phải nội hóa lý do tại sao mỗi phần tồn tại.
Sự đầu hàng về nhận thức xảy ra khi bước 1 không bao giờ thực sự thấm nhuần, khi bạn tiếp tục kiểm tra thủ công mọi đầu ra theo thói quen rất lâu sau khi hệ thống xác minh đã tự chứng minh, phá hủy toàn bộ mục đích của việc xây dựng hệ thống ngay từ đầu.
Sự bùng nổ token là những gì xảy ra khi bạn bỏ qua bước 10, chạy các vòng lặp không có điều kiện dừng thực sự, chỉ phát hiện ra chi phí thực tế khi hóa đơn đến.
Mọi chi phí trong số này đều có thể tránh được, và mọi chi phí đều được tránh bởi cùng một kỷ luật. Xây dựng các bước theo thứ tự. Đừng bỏ qua những bước có vẻ không hào nhoáng. Các bước nhàm chán, định nghĩa hoàn thành, điều kiện dừng, sự thật cơ bản, mới là những thứ thực sự làm công việc. Các phần nghe có vẻ thú vị, prompt thông minh, sơ đồ kiến trúc phức tạp, quan trọng ít hơn nhiều so với việc hệ thống bạn xây dựng có thực sự biết khi nào nó đúng, khi nào nó sai, và khi nào nên dừng lại.
Đó là toàn bộ sự khác biệt giữa một người viết prompt và một kỹ sư thiết kế hệ thống. Không phải sự thông minh. Mà là kỷ luật đối với những phần nhàm chán để xây dựng và dễ dàng bỏ qua.
Theo dõi @cyrilXBT để biết các mẫu vòng lặp chính xác và thiết lập Builder-Judge-Manager đằng sau mọi bước trong lộ trình này.
