Kỹ thuật Vòng lặp (Loop Engineering) - Từ Prompting đến Looping

Tôi quyết định dành bài viết này để hướng dẫn bạn cách tạo ra một tác nhân có thể lập trình của riêng mình, một tác nhân sẽ tự động làm việc cho bạn, để bạn không cần phải bật máy tính mỗi sáng và liên tục ra lệnh cho nó.

Nó sẽ tự động thức dậy, tự tìm kiếm nhiệm vụ, tự xác định vấn đề, và lưu trữ cũng như trình bày kết quả trên bàn làm việc để bạn xem xét.

Lời nói đầu

Ý tưởng về Loop không đến một cách ngẫu nhiên - trong một tuần duy nhất của tháng 6 năm 2026, ba chuyên gia trong ngành gần như đồng thời bày tỏ cùng một suy nghĩ: đã đến lúc bắt đầu phát triển cấp độ này.

Một tuần sau, Andrew Ng đã đặt cuộc trò chuyện này vào bối cảnh rộng hơn của "Xây dựng Sản phẩm từ 0 đến 1", mang đến một bức tranh toàn diện hơn.

Bài viết này bắt đầu từ câu chuyện đó và sau đó hướng dẫn bạn xây dựng một vòng lặp tối thiểu nhưng hoàn chỉnh từ đầu: 5 bước di chuyển, 6 phần, một cánh cửa nói "không", và một cánh cửa dành cho con người - tất cả đều chạy trên máy của bạn và có thể tái sử dụng cho bất kỳ dự án phần mềm nào.

Nguồn: HuaShu Orange Book, Loop Engineering: Đừng Hỏi Tôi Nó Là Gì Nữa (v260615, tháng 6 năm 2026)

Tuần mà 3 người đã châm ngòi

Tháng 6 năm 2026: ba người, không ai phối hợp với ai, đã nói gần như cùng một điều trong vòng vài ngày.

Peter Steinberger, người tạo ra OpenClaw, đã đăng hai dòng trên X và đạt 8,9 triệu lượt xem:

https://x.com/steipete/status/2063697162748260627

Bài đăng đó thực sự là nơi cuộc thảo luận bắt đầu. Nó không phải là một tuyên ngôn hay một bài luận dài, chỉ là hai dòng đặt tên cho một thứ mà mọi người đang âm thầm thực hiện.

Boris Cherny: Tôi không còn nhắc nhở Claude nữa, tôi có các vòng lặp đang chạy. Chính chúng là những thứ đang nhắc nhở Claude và tìm ra việc cần làm.

Addy Osmani: Kỹ thuật vòng lặp (Loop engineering) là việc thay thế chính bạn với tư cách là người nhắc nhở tác nhân. Bạn thiết kế hệ thống làm việc đó thay vì bạn.

Thực hành đã có trước khi có tên gọi hàng tháng trời, mọi người đều đã viết các vòng lặp, nhưng chưa ai đặt tên cho nó cả.

Vì vậy, các vòng lặp hiện là một phần quan trọng trong cách chúng ta cho phép các tác nhân AI làm việc lặp đi lặp lại trong dài hạn để tạo ra phần mềm.

Andrew Ng đã sắp xếp ba vòng lặp từ trong ra ngoài dựa trên thang thời gian của chúng: vòng lặp trong cùng là nhanh nhất và vòng lặp ngoài cùng là chậm nhất. Hơn nữa, đầu vào của vòng lặp ngoài cùng đến từ đầu ra của vòng lặp trong cùng:

Vòng lặp

Ai điều hành

Độ dài chu kỳ

Đầu ra cho lớp bên ngoài

Vòng lặp viết mã tác nhân (Agentic coding loop)

bản thân tác nhân

giây - phút

một phiên bản chạy được

Vòng lặp phản hồi của nhà phát triển (Developer feedback loop)

con người + tác nhân

hàng chục phút - hàng giờ

một tầm nhìn và đặc tả sản phẩm rõ ràng hơn

Vòng lặp phản hồi bên ngoài (External feedback loop)

người dùng + nhóm

giờ - tuần

dữ liệu thực tế giúp phát triển tầm nhìn

Andrew Ng đã cho chúng ta bản đồ theo thời gian: ba vòng lặp chạy ở các tốc độ khác nhau. Addy Osmani đã vẽ một bản đồ thứ hai theo mức độ trừu tượng: prompt -> context -> harness -> loop.

Kỹ thuật vòng lặp (Loop engineering) nằm ở trên cùng và thêm ba động từ mà harness không có. Nó chạy theo bộ hẹn giờ, tạo ra các trình trợ giúp, và tự nuôi sống chính nó - đầu ra của hôm nay trở thành đầu vào của ngày mai. Điều cuối cùng đó là thứ làm cho nó trở thành một vòng lặp, chứ không phải cùng một tác vụ chạy N lần.

Trực giác quan trọng nhất: cùng một lỗi có chi phí khác nhau ở mỗi lớp:

Lớp

Nó quan tâm đến điều gì

Câu hỏi cốt lõi

Kỹ thuật Prompt (Prompt eng.)

viết một prompt

nói gì với mô hình

Kỹ thuật Ngữ cảnh (Context eng.)

những gì được tải trong cửa sổ

lấy gì, tóm tắt gì, xóa gì

Kỹ thuật Harness (Harness eng.)

trang bị cho một lần chạy

công cụ nào, hành động nào, thế nào là hoàn thành

Kỹ thuật Vòng lặp (Loop eng.)

lên lịch trên harness

làm thế nào để nó tự chạy, hết vòng này đến vòng khác

Một vòng lặp được thiết kế để trở thành một cỗ máy làm cho "số lượt" trở nên lớn. Mọi quyết định từ đây trở đi - bộ đánh giá, cổng kiểm soát con người, giới hạn token, tệp trạng thái - đều tồn tại để rút ngắn khoảng cách giữa "lỗi xảy ra" và "ai đó nhìn thấy nó."

Điều gì xảy ra bên trong một lượt:

"Vòng lặp" thường bị hiểu sai là "quay vòng tại chỗ." Không phải vậy, mỗi lượt có 5 bước di chuyển cụ thể. Cắt bỏ bất kỳ bước nào và vòng lặp sẽ không chạy - hoặc nó chạy mà không đi đến đâu cả.

1. Xác minh (Verification) là bước di chuyển nói "không."
2. Lên lịch (Scheduling) là bước di chuyển đưa lượt này vào lượt tiếp theo.

Đó chính xác là phần làm cho nó trở thành một vòng lặp.

Ánh xạ tới dự án chúng ta sắp xây dựng: một vòng lặp phân loại buổi sáng (morning-triage loop) cho một nhóm nhỏ:

Hành động

Nó làm gì

Trong VÒNG LẶP PHÂN LOẠI (TRIAGE LOOP)

Khám phá (Discovery)

tìm ra lượt này nên làm gì

một kỹ năng đọc CI / issues / các commit gần đây

Bàn giao (Handoff)

phân phối nhiệm vụ và cách ly nó

mỗi phát hiện có một worktree riêng

Xác minh (Verification)

đưa một tác nhân khác vào để nói không

một tác nhân phụ thứ hai làm người đánh giá, kiểm tra các bài kiểm tra và kỹ năng

Lưu trữ (Persistence)

ghi trạng thái bên ngoài cuộc hội thoại

PR + Linear ticket + ./state/triage.md

Lên lịch (Scheduling)

để nó chạy hết lượt này đến lượt khác

GitHub Actions cron kích hoạt lúc 06:00

Mỗi bài học trong số 5 bài học dưới đây phát triển chính xác một bước di chuyển.

Năm bài học = một Vòng lặp hoàn chỉnh.

Và chúng ta bắt đầu với bài học đầu tiên: Khám phá (Discovery), bởi vì nếu Vòng lặp không thể quyết định hôm nay việc gì đáng làm, thì không có gì sau đó có ý nghĩa.

Bài học 1 Khám phá: viết một SKILL.md phân loại buổi sáng (morning-triage)

Các kỹ năng (Skills), không phải một bức tường prompt.

Hãy tưởng tượng, đó là 6 giờ sáng thứ Hai, Laptop của bạn đã tắt và GitHub Action thức dậy và kích hoạt claude --skill morning-triage: nó đọc gì, nó đánh giá điều gì là có thể hành động, nó ghi kết quả ở đâu - tất cả đều nằm bên trong SKILL.md mà bạn sắp viết.

Câu nói quan trọng của Osmani: tự động hóa nên kích hoạt một kỹ năng - kiến thức dự án đã được viết ra, có thể cập nhật, chứ không phải một bức tường prompt được dán vào một công việc định kỳ (cron job). Prompt bị dán vào đó sẽ chỉ mục nát ở đó, bởi vì không ai bao giờ quay lại cập nhật thứ bị chôn vùi bên trong một lịch trình.

Nhiệm vụ của bạn cho bài học này: viết một kỹ năng tại .claude/skills/morning-triage/SKILL.md, tự động đọc ba nguồn (CI / issues / commits), tự quyết định việc gì đáng làm, ghi kết quả vào ./state/triage.md - và có một phần Dừng (Stop) rõ ràng nêu rõ những gì vòng lặp KHÔNG được phép làm.

Đây là phần khởi đầu - hãy thay đổi ba thứ và nó sẽ là của bạn:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoked by daily automation
5---
6
7## Read   (đầu vào khám phá — hãy đổi thành các nguồn mà repo CỦA BẠN thực sự có)
8- CI runs that failed since the last run      # gh run list --status failure
9- issues opened in the last 24h               # gh issue list --search "created:>=…"
10- commits merged since yesterday              # git log --since=yesterday
11- the previous ./state/triage.md              # bàn giao "hôm qua → hôm nay"
12
13## Judge  (giới hạn trên — để vòng lặp tự chọn, đừng đưa cho nó một danh sách)
14For each candidate, decide:
15- is it actionable NOW, or noise?
16- does it block a release? → priority = P0
17- is it already being tracked? → skip
18Keep only what is worth a worktree TODAY.
19
20## Write  (lưu trữ — ghi nó vào markdown, không phải chat)
21Append to ./state/triage.md:
22| finding | source | priority | status |
23Commit the file so tomorrow can read it.
24
25## Handoff  (chuẩn bị cho Bài học 2)
26For each kept finding, emit a task line:
27  worktree=fix/<slug>
28  goal=<stop-condition>
29
30## Stop   (PHẦN DUY NHẤT không phải boilerplate — hãy suy nghĩ kỹ ở đây)
31Never merge. Never delete.
32Anything you're less than confident about → ./inbox/ for a human.
33NOT a PR.

Ba phần thực sự làm công việc chính ở đây:

Read: đây là đầu vào của Khám phá - liệt kê các nguồn cụ thể, xuống đến lệnh thực tế. Hãy nhớ, "đọc ngữ cảnh" không phải là một nguồn, nhưng gh run list --status failure là một nguồn.

Judge: đây là giới hạn trên của toàn bộ vòng lặp của bạn. Vòng lặp tự quyết định "có thể hành động so với nhiễu" - nó không nhận một danh sách từ bạn, bởi vì nếu bạn vẫn đưa cho nó một danh sách mỗi sáng, bạn đã tự động hóa việc thực hiện chứ không phải việc lựa chọn. Và việc lựa chọn thường là bước đắt đỏ hơn. Cho dù các nguồn của bạn có tốt đến đâu, nếu phần này chọn phải rác rưởi, thì bốn bước di chuyển còn lại chỉ là quay vòng vô ích.

Stop: phần duy nhất của tệp này không phải là boilerplate. Vòng lặp sẽ làm mọi thứ kỹ năng nói, và chỉ những gì kỹ năng nói. Nếu bạn không viết "không bao giờ merge" - một ngày nào đó nó sẽ merge cho bạn.

Hãy nêu rõ các ranh giới đỏ: không bao giờ merge, không bao giờ xóa, không bao giờ push lên nhánh main, bất cứ điều gì không chắc chắn sẽ vào ./inbox/ cho con người, chứ không phải vào một PR.

Một điều nữa đáng biết: cấu trúc kỹ năng tương tự này hoạt động ngoài việc phân loại buổi sáng: hãy đổi phần Read thành "nhật ký truy cập ngày hôm qua + issues mới + phiên bản triển khai hiện tại" và nó trở thành một vòng lặp kiểm tra sức khỏe trang web buổi tối. Thêm một dòng vào Judge - "đây có phải là sự thoái lui so với ngày hôm qua không?" - và nó phát triển khả năng so sánh qua các ngày.

Căn bệnh mà bài học này ngăn ngừa - Vòng lặp Mù (Blind Loop):

Thứ phổ biến nhất "trông giống vòng lặp nhưng thực ra không phải." Vòng lặp chạy, nhưng bạn vẫn đang giao việc mỗi sáng ("này, hãy xem ba lỗi này"). Đó là tự động hóa việc thực thi, chứ không phải tự động hóa việc khám phá.

Triệu chứng: vòng lặp không bao giờ làm bạn ngạc nhiên, bởi vì nó chỉ làm những gì bạn đã biết cần phải làm.

Cách khắc phục: đặt Judge bên trong kỹ năng và để nó tự chọn công việc hôm nay.

Trước khi tiếp tục, hãy trả lời ba câu hỏi này:

1/ Phần Stop của bạn có bao nhiêu dòng?

Nếu nó chỉ là "không bao giờ merge" - hãy thêm một dòng nữa: vòng lặp này còn không bao giờ nên làm gì khác cho bạn? (không bao giờ đóng issues / không bao giờ push lên main / không bao giờ nhận quá 3 phát hiện cùng một lúc..)

2/ Viết lại dòng đầu tiên của Read thành một lệnh thực sự chạy trong DỰ ÁN của bạn

**3/ Nếu kỹ năng này không thay đổi trong một năm - điều gì sẽ xảy ra?

**Bây giờ hãy so sánh: điều gì xảy ra với một bức tường prompt được dán trong một công việc định kỳ (cron job) trong một năm?

Bài học 2 Bàn giao: phân phát công việc và cách ly nó

Kỹ năng của Bài học 1 vừa chạy xong. ./state/triage.md hiện chứa 5 phát hiện có thể hành động. Suy nghĩ tự nhiên nhất tiếp theo - kích hoạt 5 tác nhân cùng một lúc, để tiến nhanh. Chính xác bước đó là cách bạn tạo ra một Vòng lặp Rối rắm (Tangled Loop): nhiều tác nhân chỉnh sửa cùng một tệp trong cùng một thư mục, và ngày merge biến thành công việc khảo cổ học.

Phương thuốc giải độc là một dòng: mỗi phát hiện có worktree riêng của nó.

git worktree là một cơ chế git tích hợp sẵn: một repo, nhiều thư mục làm việc độc lập, mỗi thư mục được checkout vào nhánh riêng của nó. git worktree add ../fix-auth fix/auth mở một không gian làm việc hoàn toàn cách ly tại ../fix-auth. Xây dựng, chỉnh sửa, kiểm thử - không gì chạm vào nhau. Một worktree cho mỗi phát hiện = các tác nhân bị cách ly về mặt vật lý.

Nhiệm vụ của bạn cho bài học này: viết một script đọc từng phát hiện từ ./state/triage.md, mở một worktree cách ly cho mỗi phát hiện (đặt tên là fix/<slug>), gửi một tác nhân để soạn thảo bản sửa lỗi bên trong nó - và đặt một giới hạn song song để nó không sinh sôi vô hạn.

1# read state/triage.md, one worktree per finding
2# change: MAX_PARALLEL to what your machine / bill can handle
3MAX_PARALLEL=3
4
5# change: parsing to match your actual triage.md columns
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # the key line: physical isolation per agent
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # change: goal is the stop condition Lesson 3's evaluator will read
16  claude --worktree ../wt-$slug \
17    --goal "tests in tests/$slug pass and lint is clean" \
18    "draft a fix for: $finding" &
19done
20
21wait   # let all parallel agents finish
22
23# closing rule: agents never auto-merge — worktrees wait
24# for the human gate in Lesson 5
25echo "All worktrees ready for review:"
26git worktree list

Các quy tắc quan trọng ở đây: không bao giờ làm việc trên nhánh main.

Main là đường băng hạ cánh cho việc xem xét của con người - không phải bàn làm việc của các tác nhân. Tất cả các tác nhân sống trên các worktree fix/*.

Giới hạn tính song song: việc sinh sôi không giới hạn là cánh cửa dẫn đến sự bùng nổ token (Bài học 5 sẽ quay lại vấn đề này). Chọn MAX_PARALLEL dựa trên một câu hỏi trung thực: không phải "máy của tôi có thể chạy bao nhiêu" mà là "tôi thực sự có thể xem xét bao nhiêu PR."

Merge là một quyết định của con người: Stripe chạy hơn 1.000 PR mỗi tuần thông qua các vòng lặp như thế này, và con người vẫn xem xét từng cái một. Con người không rời khỏi quy trình - họ đã đổi bàn làm việc: từ viết mã sang xem xét mã.

Và một chi tiết từ trường hợp của Stripe đáng để học hỏi: họ đã sử dụng một mô hình nhỏ hơn với các cổng kiểm soát xác định chặt chẽ thay vì mô hình lớn nhất hiện có, một cách phản trực giác.

Bài học: một cổng xác minh chặt chẽ đánh bại sức mạnh mô hình thô cho công việc vòng lặp.

Căn bệnh mà bài học này ngăn ngừa - Vòng lặp Rối rắm (Tangled Loop):

Một vòng lặp tác nhân đơn trông hoàn toàn khỏe mạnh. Vấn đề chỉ xuất hiện vào ngày bạn chạy song song - năm tác nhân chạy, năm bản diff va chạm trong cùng một tệp, merge là hỗn loạn.

Cách khắc phục: mỗi nhiệm vụ có worktree riêng, không bao giờ chia sẻ một thư mục làm việc giữa các tác nhân.

Trước khi tiếp tục, hãy trả lời ba câu hỏi này:

**1/ Bạn đã đặt MAX_PARALLEL là số nào - và tại sao?

**(tiền? máy? hay "tôi có thể xem xét một cách trung thực bao nhiêu PR"?)

**2/ Nếu một worktree bị crash - tác nhân thoát mà không chạm vào gì

**Tệp trạng thái ngày mai nên ghi lại điều gì về nó?

**3/ Stripe đã sử dụng một mô hình nhỏ hơn + các cổng kiểm soát xác định chặt chẽ

**Thay vì mô hình lớn nhất, lựa chọn đó có ý nghĩa gì đối với VÒNG LẶP của bạn?

Bài học 3 Xác minh: lắp đặt một cánh cửa nói "không" (bài học nặng nhất)

Đây là bước di chuyển khó nhất trong kỹ thuật vòng lặp, và nó xứng đáng được nỗ lực nhiều hơn bất kỳ bài học nào khác.

Kỹ sư của Anthropic, Prithvi Rajasekaran, làm việc trên các ứng dụng tác nhân chạy dài, đã nhận thấy một điều: yêu cầu một tác nhân chấm điểm mã nó vừa viết, và nó gần như sẽ luôn tự khen ngợi bản thân - ngay cả khi một con người có thể nhìn thấy ngay rằng nó tầm thường.

Đây không phải là do mô hình ngu ngốc: việc tự chấm điểm bài tập của chính mình là sai về mặt cấu trúc. Vào thời điểm mã được hoàn thành, ngữ cảnh của tác nhân đã bị nhồi nhét với chuỗi tự biện minh về lý do tại sao nó viết mọi thứ theo cách này. Nhìn vào đầu ra của chính nó, nó không thấy kết quả - nó thấy lập luận cho kết quả.

Đặt điều đó bên trong một vòng lặp và nó khuếch đại thành một thảm họa: mọi lượt "cái này có đủ tốt không?" Được trả lời bởi tác nhân vừa viết ra nó. Mọi lượt đều tự gật đầu với chính nó. Nó chạy càng lâu, nó càng đi xa khỏi chất lượng thực sự. Đó là Vòng lặp Gật đầu (Nodding Loop) - và nó là căn bệnh đắt đỏ nhất trong danh sách.

Cách khắc phục của Rajasekaran, theo lời của chính ông:

"Việc điều chỉnh một bộ đánh giá độc lập để trở nên hoài nghi dễ quản lý hơn nhiều so với việc làm cho một bộ sinh trở nên phê phán công việc của chính nó."

Đây là một vấn đề về cấu trúc, không phải vấn đề về từ ngữ. Bạn không thể yêu cầu một tác giả bước ra khỏi suy nghĩ của chính họ, nhưng bạn có thể đưa vào một tác nhân khác, với các hướng dẫn hoàn toàn khác, nhìn vào mã từ con số không - không có chuỗi tự biện minh nào được đính kèm.

Sự tương tự đến từ GAN: một mạng xây dựng, một mạng tấn công: người tạo và người kiểm tra. Cùng một quy tắc ngân hàng cũ: người chuyển tiền và người phê duyệt nó phải là những người khác nhau.

Nhiệm vụ của bạn cho bài học này - viết hai thứ:

1) Một prompt hệ thống đánh giá tại .claude/agents/reviewer.md với năm phần: ROLE + ASSUME + CHECK + USE + VERDICT.

2) Một lệnh /goal khai báo điều kiện dừng của vòng lặp này - được đánh giá bởi một mô hình mới riêng biệt, không phải bởi bộ sinh.

1# .claude/agents/reviewer.md  (thay đổi 3 thứ)
2ROLE: Adversarial code reviewer.
3ASSUME: this code is BROKEN until proven otherwise.
4DO NOT praise. Find what fails.
5
6# change: order CHECK by your project's real failure modes,
7# runnable checks first
8CHECK, in order:
9  1. Does it run?  (execute, don't read)
10  2. Tests: run them, paste real output.
11  3. Edge cases the author skipped.
12  4. Does behavior match the ticket?
13
14# change: which MCP depends on what you're testing —
15# frontend → Playwright, API → curl/httpie
16USE Playwright MCP: open the page, click,
17screenshot, inspect the DOM.
18Judge behavior, not intent.
19
20VERDICT: PASS only if every check holds.
21         Otherwise REJECT + list each reason.

1# stop condition — judged by a fresh small model, NOT the generator
2# change: swap for the real verifiable condition of your finding
3/goal all tests in test/auth pass and the lint step is clean
4
5# careful: /goal and /loop are NOT the same thing
6#   /loop = rerun on interval (no stop judgment — dangerous)
7#   /goal = run until a fresh model judges the condition true

Hai tác nhân, lý tưởng nhất là hai mô hình: "cùng một mô hình, prompt khác nhau" thường bảo tồn cùng một điểm mù. Hãy đổi cả mô hình nếu bạn có thể.

Sự hoài nghi mặc định: điểm cơ sở của bộ đánh giá là GIẢ ĐỊNH BỊ HỎNG - sự tin tưởng phải được kiếm bằng cách vượt qua các kiểm tra, không được cấp theo mặc định.

Đánh giá hành vi, không phải ý định: "JSX này trông ổn" và "Tôi đã nhấp vào nút, trang đã điều hướng, đây là ảnh chụp màn hình" là hai vũ trụ khác nhau. Bộ đánh giá phải hành động - chạy các bài kiểm tra, nhấp vào trang, không chỉ đọc mã và cảm nhận.

Từ chối kèm lý do: một REJECT không có lý do được liệt kê không phải là một sự từ chối - bộ sinh không biết phải sửa cái gì.

Và bài kiểm tra axit: bộ đánh giá của bạn đã thực sự từ chối điều gì đó trong 5+ lượt gần đây chưa? Một vòng lặp chưa bao giờ nói "không" qua hàng trăm lượt là điều không thể về mặt thống kê trong bất kỳ khối lượng công việc thực tế nào. Vì vậy, nó chứng tỏ bộ đánh giá không hoạt động.

Căn bệnh mà bài học này ngăn ngừa - Vòng lặp Gật đầu (Nodding Loop):

Vòng lặp chạy, tác nhân viết mã, cùng một tác nhân nói "trông ổn." Mọi lượt đều tự phê duyệt, chồng chất các lỗi có vẻ hợp lý với tốc độ máy. Cách khắc phục: toàn bộ bài học này: tách biệt về mặt cấu trúc + hoài nghi mặc định + đánh giá bằng hành động + điều kiện dừng của bên thứ ba.

Trước khi tiếp tục, hãy trả lời ba câu hỏi này:

1/ Bộ đánh giá của bạn có phải là cùng một mô hình với một prompt khác, hay một mô hình khác? tại sao?

2/ Dịch "đánh giá hành vi, không phải ý định" thành một câu cụ thể

từ dự án của riêng bạn: "bộ đánh giá của tôi không đọc mã, nó chạy _____, và chỉ PASS khi nó thấy _____"

3/ Khả năng một mô hình mới "đủ gần" sẽ sai lầm PASS điều kiện /goal của bạn là bao nhiêu?

nếu chế độ lỗi đáng sợ nhất của bạn là X - hãy thêm một kiểm tra cho X vào điều kiện dừng ngay bây giờ

Bài học 4 Lưu trữ: làm cho công việc hôm nay tồn tại đến ngày mai

Bài học 3 đã kết thúc. Bộ đánh giá của bạn đã đánh giá ba phát hiện - hai PASS, một REJECT. Câu hỏi: ba phán quyết đó hiện đang sống ở đâu?

Nếu câu trả lời là "trong cửa sổ ngữ cảnh" - thì vào lúc 6 giờ sáng ngày mai, vòng lặp thức dậy với một ngữ cảnh bị xóa sạch và không nhớ gì cả. Nó phân loại lại từ đầu, vấp phải REJECT chưa được sửa của ngày hôm qua, có thể gán một tác nhân khác để sửa lại, có thể bỏ lỡ nó hoàn toàn, có thể rơi vào cùng một cái hố.

Đó là Vòng lặp Mất trí nhớ (Amnesiac Loop) - mỗi ngày bắt đầu từ cùng một ô vuông.

Phương thuốc giải độc trong một dòng: bộ nhớ là trạng thái được ghi vào đĩa, không phải ngữ cảnh. Một tệp markdown, một bảng Linear, một cơ sở dữ liệu - một khi nó đã được ghi lại, việc tác nhân quên mất nó không còn quan trọng nữa.

Hai thứ này liên tục bị nhầm lẫn, vì vậy hãy ghim rõ sự khác biệt:

NGỮ CẢNH (CONTEXT) = cửa sổ tác nhân thấy trong LƯỢT này -> bị xóa sau mỗi lần làm mới.

BỘ NHỚ (MEMORY) = trạng thái tồn tại qua các lượt và ngày -> được ghi vào đĩa (markdown / DB / board).

Một vòng lặp kết nối hôm nay -> ngày mai chỉ thông qua BỘ NHỚ.

Nhiệm vụ của bạn cho bài học này:

1. Tạo ./state/triage.md với ít nhất 4 cột (finding / source / priority / status) - Kỹ năng của Bài học 1 ghi nó, các worktree của Bài học 2 đọc nó.
2. Kết nối một bộ kết nối (MCP): phán quyết PASS tự động mở một PR, phán quyết REJECT tự động cập nhật ticket.
3. Xác minh vòng lặp ngày mai thực sự có thể đọc lại trạng thái của ngày hôm nay.

1# ./state/triage.md  (bộ nhớ của vòng lặp — thay đổi khi cần)
2
3| finding         | source       | priority | status     |
4|-----------------|--------------|----------|------------|
5| auth test flaky | CI #4821     | P0       | fixing     |
6| null deref      | issue 92     | P1       | PR open    |
7| stale dep       | commit a3f9c | P2       | inbox      |
8
9# extend columns as needed: last_seen, retry_count, assigned_to
10# this file MUST be committed to the repo —
11# otherwise tomorrow's cloud runner can't see it

1// .mcp/connectors.json — cắm vòng lặp vào thế giới bên ngoài
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← PHẢI là false. Cổng kiểm soát con người = Bài học 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "reason": "${verdict.reasons}" }
15  }
16}

Tại sao mỗi cột lại quan trọng: không có nguồn -> bạn không thể kiểm tra phát hiện đến từ đâu. không có mức độ ưu tiên -> bạn không thể sắp xếp công việc. không có trạng thái -> ngày mai không thể tiếp nhận công việc.

Và việc xác minh cho bài học này là việc duy nhất bạn không thể giả mạo: hãy đợi đến ngày mai. Thức dậy, kiểm tra - hộp thư đến (inbox) vẫn còn đó không? Các phát hiện chưa hoàn thành có còn giữ trạng thái của chúng không? Lần chạy lúc 6 giờ sáng có tiếp tục từ nơi hôm qua dừng lại thay vì bắt đầu lại không? Điều này bạn chỉ tìm ra bằng cách chạy nó, chứ không phải bằng cách suy luận về nó.

Một kỷ luật thầm lặng đi kèm với việc lưu trữ - hãy luôn đọc một mẫu.

Một khi việc lưu trữ hoạt động, một cái bẫy mở ra: vòng lặp gửi PR với tốc độ cao, bạn cảm thấy năng suất - và bản đồ tinh thần của bạn về cơ sở mã âm thầm trở nên lỗi thời. Quy tắc: không đọc mọi thứ (điều đó phản tác dụng của vòng lặp), nhưng hãy đọc một PR mẫu mỗi ngày và buộc bản thân giải thích vòng lặp đã thay đổi cái gì và tại sao.

Khoảnh khắc bạn không thể giải thích nó - bản đồ của bạn đã bị tụt hậu. Sửa nó vào một buổi sáng yên tĩnh tốn mười phút. Sửa nó trong một sự cố sản xuất tốn nhiều hơn thế.

Căn bệnh mà bài học này ngăn ngừa - Vòng lặp Mất trí nhớ (Amnesiac Loop):

Vòng lặp tìm thấy công việc tốt, làm nó, sau đó quên mất nó đã làm - bởi vì kết quả chỉ tồn tại trong một ngữ cảnh bị xóa. Lượt tiếp theo nó khám phá lại cùng một công việc, hoặc tệ hơn - làm lại nó và đè lên nỗ lực đầu tiên.

Triệu chứng: không có tiến triển tích lũy, mỗi ngày bắt đầu từ cùng một nơi. Cách khắc phục: tệp trạng thái trên đĩa.

Trước khi tiếp tục, hãy trả lời ba câu hỏi này:

1/ Dịch "bộ nhớ ≠ ngữ cảnh" thành một câu cụ thể

từ dự án của riêng bạn: "_____ của tôi là bộ nhớ, _____ của tôi là ngữ cảnh"

**2/ Vòng lặp ngày mai thức dậy - nó đọc CỘT nào của state.md

**đầu tiên để quyết định bước đi đầu tiên của nó? bạn đã đặt tên đúng cho cột đó chưa, hay bạn vừa chôn một quả mìn cho nó?

**3/ Kỷ luật: bạn sẽ đọc một PR mẫu của mình vào thời gian nào trong ngày?

**hãy đặt lời nhắc lịch ngay bây giờ - đây là một cam kết với chính bạn.

Bài học 5 Lên lịch: làm cho nó có thật, làm cho nó an toàn, giữ một cánh cửa mở

Các Bài học 1-4 đã được cài đặt, nhưng vòng lặp vẫn dừng lại ngay khi bạn ngừng nhấn nút. Bước di chuyển cuối cùng là một động từ: treo nó lên một bộ kích hoạt.

Nhưng phần nguy hiểm nhất của bài học này không phải là cài đặt cron sai. Mà là cài đặt cron đúng - bởi vì sau đó vòng lặp thực sự chạy một mình, và một lỗi có thể làm nó quay vòng suốt đêm, các trình trợ giúp sinh sôi các trình trợ giúp, cho đến khi bạn thức dậy với một hóa đơn mà bạn không nhận ra.

Vì vậy, bài học này thực sự làm ba việc: treo bộ kích hoạt, đặt các giới hạn, giữ một cánh cửa cho con người.

Đầu tiên - chọn bộ lập lịch của bạn:

1Cloud (GH Actions)   Desktop scheduled   /loop (in CC)
2runs where          cloud                your machine        your machine
3machine on?         not needed           needed              needed
4session open?       not needed           not needed          needed
5min interval        1 hour               1 minute            1 minute
6sees local files?   no                   yes                 yes

Câu hỏi quyết định: công việc này có thể rời khỏi laptop của bạn không?

1"check my local dev server every minute"
2   → must be local + /loop (cloud's 1-hour interval can't reach it)
3
4"scan GitHub issues at 3am and open PRs"
5   → must be cloud (your laptop is closed — the loop can't
6     be waiting on it)

Và sự tự lừa dối tinh vi nhất trong toàn bộ thực hành: coi một bộ hẹn giờ cục bộ là "chạy trong khi bạn ngủ." Không phải vậy. Nó là "chạy thêm vài lượt nữa trong khi tôi vẫn còn ở đây."

Nhiệm vụ của bạn trong bài học này:

1. Viết file .github/workflows/triage.yml với một bộ kích hoạt cron để chạy skill morning-triage.
2. Đặt ba giới hạn: ngân sách mỗi lần chạy, ngân sách hàng ngày, số lần thử lại tối đa.
3. Kết thúc workflow với quy tắc: PR không bao giờ tự động merge, bất cứ điều gì không chắc chắn sẽ được chuyển vào thư mục ./inbox/.

1# .github/workflows/triage.yml  (thay đổi 3 thứ)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # thay đổi: 06:00 theo múi giờ của bạn tính theo UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← giới hạn mỗi lần chạy · thay đổi
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← giới hạn hàng ngày · thay đổi
22          MAX_RETRIES: '3'          # ← giới hạn số lần thử lại · thay đổi
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: mở PR (KHÔNG BAO GIỜ tự động merge)
29        run: |
30          # PR tự động mở. việc merge vẫn do con người thực hiện.
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # không có lệnh `gh pr merge` ở đây — có chủ đích
35
36      - name: chuyển hướng những thứ không chắc chắn vào inbox
37        run: |
38          ls ./inbox/ && echo "các mục đang chờ con người xem xét"

Ba quy tắc giúp nó tồn tại sau sáu tháng:

Giới hạn trước khi triển khai: ba cấp độ - thời gian chờ mỗi lần chạy, ngân sách hàng ngày, số lần thử lại tối đa - được đặt trước lần chạy tự động đầu tiên, không phải sau hóa đơn đáng sợ đầu tiên. Giới hạn token không phải là để tiết kiệm tiền. Nó là một cái máy cắt mạch, biến rủi ro vô hạn thành rủi ro có giới hạn. Một vòng lặp không có giới hạn đã ủy quyền chi tiêu cho chính những lỗi của nó.

Về quy mô: Uber đã giới hạn các kỹ sư ở mức $1,500 mỗi người mỗi công cụ mỗi tháng sau khi đốt hết ngân sách AI trong bốn tháng. Giới hạn mỗi vòng lặp của bạn là phiên bản chi tiết của bài học đó.

Giữ một cánh cửa luôn mở: PR không tự động merge. Các mục không chắc chắn sẽ được chuyển vào inbox. Bạn đọc một mẫu mỗi ngày. Cánh cửa không tồn tại vì con người sẽ luôn bước qua nó, nó tồn tại vì sự tồn tại của cánh cửa giúp bạn luôn ở vị thế có thể bước qua. Hàn chết mọi cánh cửa, và đến ngày bạn cần vào, bạn đã đánh mất chìa khóa.

Xác minh rằng nó thực sự thức dậy. Chạy nó ít nhất 3 lần (các lần chạy thử cũng được tính). Lỗi phổ biến nhất: tỏa sáng vào ngày demo, chết vào thứ Năm. "Lần chạy cuối cùng là ngày nó được demo" là dấu hiệu chẩn đoán của một Vòng lặp Thủ công.

Hoạt động tương tự bên ngoài Claude Code - các khả năng không bị khóa bởi nhà cung cấp, chỉ được đổi tên:

1KHẢ NĂNG               Claude Code          Codex
2lên lịch               /loop · worker       Tab Automations
3chạy-đến-điều-kiện     /goal                automation rerun + judge
4cô lập song song       --worktree           background worktree
5tác nhân phụ           .claude/agents/      .codex/agents/
6kết nối bên ngoài      MCP + plugins        MCP connector
7skill tường minh       SKILL.md             $skill-name
8chạy khi máy tắt       Cloud Routines       cloud (đã lên kế hoạch)

Câu hỏi chưa bao giờ là "nhà cung cấp nào." Mà là "cả sáu khả năng đã được cài đặt chưa."

Căn bệnh mà bài học này ngăn ngừa - Vòng lặp Thủ công:

Bốn bước được xây dựng đẹp đẽ, không có cron. Nó không phải là một vòng lặp - nó là một script bạn chạy một lần rồi quên.

Khắc phục: gắn bất kỳ bộ kích hoạt nào không phụ thuộc vào việc bạn có nhớ hay không.

Trước khi triển khai, hãy trả lời ba câu hỏi này:

1/ Ba giới hạn của bạn là những con số chính xác nào?

Nếu một lỗi chạy suốt đêm - giới hạn nào sẽ phá vỡ cú ngã trước tiên? Nếu không có giới hạn nào làm được điều đó... Điều đó cho bạn biết điều gì?

2/ Cánh cửa con người của bạn trông như thế nào?

(Xem xét PR / inbox / mẫu hàng ngày / đối chiếu hàng tuần?) Viết nó ra = ký hợp đồng với chính bạn

3/ Câu hỏi kết thúc: Sáu tháng nữa, vòng lặp này sẽ khiến bạn mạnh mẽ hơn (hiểu biết, phán đoán, cảm nhận về hệ thống) - hay biến bạn thành người chăm sóc một cỗ máy mà bạn không thể đọc được? Kế hoạch của bạn để tránh điều thứ hai là gì?

4 khoản nợ và việc duy trì vai trò kỹ sư

Vòng lặp của bạn đã được xây dựng: nó thức dậy, tìm việc, tự phê bình, ghi nhớ và lên lịch cho ngày mai của chính nó.

Trong khi một vòng lặp chạy, bốn thứ âm thầm tích tụ - và đặc điểm chung của chúng là không có thứ nào trong số chúng kích hoạt báo động.

1NỢ XÁC MINH           đầu ra chưa được từ chối chất đống
2MỤC NÁT HIỂU BIẾT     codebase phát triển, bản đồ tinh thần của bạn thì không
3ĐẦU HÀNG NHẬN THỨC    "Tôi không còn cảm thấy muốn xem xét kỹ lưỡng nữa"
4BÙNG NỔ TOKEN          một lỗi chạy suốt đêm → bạn thấy nó như một hóa đơn

Chúng nuôi dưỡng lẫn nhau: đầu ra chưa được xác minh làm xói mòn sự hiểu biết của bạn -> sự hiểu biết bị xói mòn mời gọi sự đầu hàng -> sự đầu hàng cho phép vòng lặp chạy lâu hơn và tiêu nhiều hơn -> điều này tạo ra nhiều đầu ra chưa được xác minh hơn.

Kiểm tra vòng lặp mới của bạn với cả bốn điều trước lần chạy độc lập đầu tiên:

• Trình đánh giá của tôi thực sự từ chối - nó không phải là vật trang trí.
• Tôi đọc một PR mẫu mỗi ngày và có thể giải thích những gì đã thay đổi.
• Tôi duy trì thói quen nói "điều này sai".
• Các giới hạn của tôi đã được đặt TRƯỚC lần chạy đầu tiên, không phải sau hóa đơn đầu tiên.

Và đây là phần quyết định tất cả:

Cùng một vòng lặp, được xây dựng bởi hai người, có thể kết thúc ở những nơi đối lập. Một người sử dụng nó để di chuyển nhanh hơn trong khi vẫn đọc code và giữ định hướng - vòng lặp khuếch đại khả năng phán đoán mà họ đã có.

Người kia sử dụng chính xác cùng một vòng lặp với mục đích cụ thể là không bao giờ phải hiểu bất cứ điều gì nữa - sáu tháng sau, người đầu tiên sắc bén hơn, và người thứ hai là người chăm sóc một cỗ máy mà họ không thể đọc được.

Addy Osmani: "hãy xây dựng vòng lặp, nhưng hãy xây dựng nó như một người có ý định duy trì vai trò kỹ sư - không chỉ là người nhấn nút chạy."

Vòng lặp làm cho việc tạo ra gần như miễn phí, thứ còn lại khan hiếm là khả năng phán đoán: kế hoạch nào là đúng, dòng nào cần dừng lại, thứ gì chạy nhưng sai từ gốc rễ. Vòng lặp không làm mất giá trị khả năng phán đoán - nó loại bỏ mọi thứ không phải là khả năng phán đoán, và chỉ để lại thứ đó.

Một vòng lặp là một bộ khuếch đại trung thành:

Mang đến sự hiểu biết - nó khuếch đại sự hiểu biết.

Mang đến sự lười biếng - nó khuếch đại sự lười biếng.

Hãy quyết định điều bạn muốn được khuếch đại - trước khi bạn xây dựng nó.

Hãy theo dõi nhé!

Chúc bạn may mắn :)