Làm thế nào để giúp Claude tiếp tục thiết kế tốt hơn? Đây là cách xây vòng lặp để nó tự tốt lên

Nếu bạn hay dùng Claude để dựng giao diện, chắc bạn quen với cảm giác này: hỏi viết prompt, nó ra một màn hình, bạn nhìn qua thấy ổn, hỏi tiếp thì được thêm chút xíu, rồi mọi thứ chững lại. Bạn quay đi quay lại sửa tay từng chi tiết mà chất lượng vẫn không nhích lên bao nhiêu.

Bài viết gốc “How to make Claude keep designing better (ie. Agentic evaluation loops)” của Carmen Rincon (Yummy Labs) chỉ ra nguyên nhân: bạn đang dùng Claude như một cái máy in ra kết quả một lần (one-shot generator), còn thứ thực sự giúp nó tiến bộ là một vòng lặp đánh giá (eval loops) — nơi Claude thiết kế, một “giám khảo” độc lập chấm điểm theo tiêu chí cụ thể, những lỗi bị bắt được ghi lại thành quy tắc để không lặp lại, và điểm số cứ thế leo dần qua từng lần.

Làm thế nào để giúp Claude tiếp tục thiết kế tốt hơn? Đây là cách xây vòng lặp để nó tự tốt lên - 1

Vì sao “nhờ Claude tự kiểm tra lại” gần như vô dụng

Cách làm quen thuộc là: dựng xong màn hình, ngay trong đoạn hội thoại đó nhờ Claude xem lại. Cách này gần như không có tác dụng, và lý do rất đáng để hiểu rõ vì nó là nền tảng của cả bài viết.

Khi Claude dựng ra một thứ gì đó, nó cũng “mang” theo cả một mớ lý lẽ đã tự thuyết phục mình trong lúc làm: những lựa chọn đã chọn, những đánh đổi đã tự biện minh. Nhờ nó xem lại chính sản phẩm đó, nó không nhìn bằng con mắt mới mà nhìn qua lăng kính của mọi quyết định đã đưa ra trước đó. Nó có xu hướng bênh vực hơn là phán xét khách quan. Hiện tượng này có tên gọi hẳn hoi: self-preferential bias — thiên kiến khiến một mô hình AI có xu hướng thích, và đánh giá cao hơn, chính sản phẩm do nó tạo ra. Giống hệt việc bạn khó tự đọc soát lỗi chính tả bài viết của mình — mắt bạn đọc ra cái bạn định viết, chứ không phải cái thực sự nằm trên trang.

Số liệu thực tế từ tác giả bài gốc: Trên một dự án khách hàng thật, chính Claude tự chấm sản phẩm của nó 75/100. Sau đó, một nhóm giám khảo khác — không hề tham gia dựng màn hình đó — chấm mù (không biết điểm cũ) và ra 52/100. Chênh lệch 23 điểm, trên cùng một sản phẩm. Đây là con số cụ thể mà tác giả ghi lại từ một dự án cụ thể, không phải một benchmark chính thức, nhưng nó minh họa rất rõ vấn đề: tự chấm bài mình quá dễ dãi với chính mình.

Cách khắc phục nằm ở cấu trúc, không phải ở việc viết prompt hay hơn. Bạn cần một người chấm với ngữ cảnh mới (fresh context) — tức là mọi thứ trợ lý đang “nhìn thấy” trước mắt: cuộc hội thoại, các file, toàn bộ lý lẽ đã có từ trước. Ngữ cảnh mới là một tờ giấy trắng, chưa từng chứng kiến quá trình dựng sản phẩm diễn ra. Chỉ đưa cho người chấm này hai thứ — sản phẩm và bộ quy tắc — không cho biết ai đã làm ra nó, bạn sẽ có một điểm số thật lòng thay vì một lời bào chữa.

Làm thế nào để giúp Claude tiếp tục thiết kế tốt hơn? Đây là cách xây vòng lặp để nó tự tốt lên - 2

Bảng tiêu chí: đo “tốt” bằng cái gì

“Làm cho đẹp hơn” không phải thứ một hệ thống có thể hành động theo. Một rubric (bảng tiêu chí chấm điểm) thì có. Đây là danh sách ngắn, cố định, mô tả “tốt” nghĩa là gì, kèm cách chấm điểm từng mục — biến một cảm giác mơ hồ thành các dòng cụ thể, kiểm tra được.

Dưới đây là một bảng tiêu chí dành riêng cho thiết kế, áp dụng được cho gần như mọi màn hình:

Độ trung thành với hệ thống thiết kế (system fidelity) — mọi màu sắc, kích thước, kiểu chữ, component đều bắt nguồn từ token và quy tắc của design system.
Tính nhất quán (coherence) — sản phẩm đọc như một tổng thể có chủ đích, không phải các mảnh ghép rời rạc từ template.
Độ chỉn chu (craft) — khoảng cách, các trạng thái (state), và những chi tiết nhỏ được làm đúng.
Tư duy trải nghiệm người dùng (UX judgment) — các trạng thái được xử lý đầy đủ, phân cấp thông tin rõ ràng, vùng chạm đủ lớn.
Khả năng tiếp cận (accessibility) — độ tương phản chữ đủ để đọc, không có chi tiết nào chỉ dựa vào màu sắc để truyền tải thông tin.

Điểm đáng chú ý ở đây, và tác giả nói rõ nó bắt nguồn từ chính các nghiên cứu nội bộ của Anthropic về việc giúp Claude thiết kế tốt hơn: hãy đặt trọng số vào những gì mô hình hay bỏ sót, và nhẹ tay với những gì nó đã làm tốt sẵn. Claude vốn đã mạnh về cấu trúc và làm cho mọi thứ chạy đúng về mặt kỹ thuật. Nó yếu hơn ở “gu thẩm mỹ”: sự nhất quán, tính nguyên bản, sự tiết chế, những chi tiết nhỏ tinh tế. Vì vậy hãy chấm nặng tay ở độ trung thành, tính nhất quán, độ chỉn chu và tư duy UX; còn “bố cục có ổn không” thì chấm nhẹ nhàng thôi. Cách đặt trọng số này chính là gu của bạn, được viết thành văn bản — đây là phần “phán đoán con người” mà vòng lặp thay bạn thực hiện.

Kết quả một lần chấm không nên là một đoạn văn khen ngợi chung chung. Nó phải là một bảng điểm (scorecard): từng dòng có điểm số, cái gì làm đúng, cái gì bị bỏ sót kèm cách sửa cụ thể, và một “brief tiếp theo” — danh sách sửa lỗi được viết lại thành chỉ dẫn cho lần dựng kế tiếp. Bảng điểm này mới là thứ bạn thực sự học được từ đó.

Chấm điểm kiểu “đối nghịch” và hội đồng giám khảo

Một người chấm bài dễ dãi, muốn tỏ ra hữu ích, sẽ có xu hướng làm tròn điểm lên. Hiệu quả thực sự đến từ một giám khảo mang tính đối nghịch (adversarial): nhiệm vụ của nó là tìm ra lập luận yếu nhất chống lại sản phẩm, chứ không phải để lấy lòng. Thành công của nó được đo bằng việc nó bắt được bao nhiêu lỗi, không phải bằng việc nó khiến bạn cảm thấy dễ chịu đến đâu.

Giám khảo cũng phải chấm mù (blind) — nghĩa là không bao giờ được xem điểm tự chấm của bên dựng sản phẩm. Nói với giám khảo “bên kia tự chấm 8 điểm” thì nó sẽ có xu hướng neo theo con số 8 đó. Chỉ đưa cho nó sản phẩm và bảng tiêu chí, nó sẽ tự hình thành con số của riêng mình. Chính cách chấm mù này đã phơi bày khoảng cách 23 điểm nói ở trên.

Bạn có thể đẩy xa hơn với một hội đồng giám khảo (critic panel). Thay vì một người chấm hết mọi thứ cùng lúc (làm mờ các góc nhìn và dễ bỏ sót), hãy chạy nhiều giám khảo độc lập, mỗi người phụ trách một góc nhìn riêng, mỗi người ở một ngữ cảnh mới hoàn toàn. Với thiết kế, một hội đồng bốn giám khảo mặc định khá hợp lý — ba người đi tìm “sàn” (điểm yếu) và một người đi tìm “trần” (tiềm năng chưa khai thác):

Độ chỉn chu, thương hiệu, độ trung thành (đối nghịch) — so sánh bản dựng với nguồn gốc, tìm lỗi hình ảnh trên mọi màn hình kể cả chế độ tối (dark mode), kiểm tra xem có “đúng chất thương hiệu” hay chỉ giống một template chung chung.
UX, khả năng tiếp cận, chuyển động, xác thực (đối nghịch) — đọc code để kiểm tra focus, thuộc tính aria, chế độ giảm chuyển động (reduced-motion); đo độ tương phản; xét khả năng dùng bàn phím; xác nhận mọi trạng thái đã thực sự được hiển thị.
Token, code, nội dung (đối nghịch) — đếm các giá trị viết cứng (hardcode) ở nơi lẽ ra phải dùng token, tìm code trùng lặp hoặc “chắp vá”, rà nội dung để phát hiện ký tự lạ, ký tự bị cấm.
Cơ hội, tham vọng (mang tính xây dựng, không đối nghịch) — người này nhìn theo hướng ngược lại: thay vì săn lỗi, nó hỏi sản phẩm đang “an toàn” ở đâu và phiên bản tốt nhất trông như thế nào; nó tuân thủ mọi quy tắc cứng của design system nhưng chỉ đề xuất mở rộng ở những chỗ hệ thống chưa có khuôn mẫu sẵn. Nhờ vị trí này, một màn hình sạch sẽ nhưng nhạt nhòa sẽ không còn được coi là xuất sắc.

Ba giám khảo đối nghịch là người quyết định điểm số cuối cùng. Giám khảo thứ tư không làm điểm cao lên — nó chỉ chỉ ra hướng đi cho lần xây dựng kế tiếp.

Làm thế nào để giúp Claude tiếp tục thiết kế tốt hơn? Đây là cách xây vòng lặp để nó tự tốt lên - 3

Lưu ý: Bảng bốn giám khảo này chỉ là điểm khởi đầu, không phải luật bất di bất dịch. Bạn hoàn toàn có thể thêm giám khảo về nội dung/văn phong, tách riêng khả năng tiếp cận thành một phần riêng, hay đổi trọng số cho phù hợp với sản phẩm của mình. Điều quan trọng là mỗi giám khảo độc lập, chấm mù, và phụ trách một góc nhìn riêng biệt — chứ không phải con số bốn.

Bốn quy tắc giữ cho điểm số đáng tin

Một con số chỉ có ý nghĩa nếu bạn tin được là nó đang leo thật qua từng vòng lặp, chứ không phải ảo giác. Đây là phần nhiều người bỏ qua, nhưng lại là thứ phân biệt một xu hướng tăng thật với một xu hướng chỉ để tự trấn an.

Chấm mù. Như đã nói ở trên — đây là quy tắc số một.
Đóng băng và hiệu chỉnh thước đo. Nếu mỗi lần bạn lại viết lại hướng dẫn cho giám khảo theo trí nhớ, thước đo sẽ đổi hình dạng giữa các vòng lặp và đường xu hướng sẽ nói dối. Hãy viết prompt cho giám khảo một lần, sau đó hiệu chỉnh: tự bạn chấm 2-3 màn hình thật rồi đưa cho giám khảo làm mốc tham chiếu, để cảm nhận “đây là 6 điểm, đây là 8 điểm” của nó khớp với bạn.
Chỉ theo dõi một con số chính thức mỗi vòng lặp. Đó là điểm nền (baseline) của hội đồng chấm mù. Đừng ghi điểm “sau khi đã sửa xong” làm điểm chính thức, vì con số đó thường là tự đánh giá — và tự đánh giá chính là thứ vừa được chứng minh là “nới tay” khoảng 20 điểm. Việc sửa lỗi là tiến độ, không phải điểm số.
Chỉ cho điểm 8+ nếu đã được xác minh thật. Một tiêu chí chỉ được điểm cao nếu đã thực sự kiểm tra: đã hiển thị ra màn hình, đã đo tương phản, đã thử bằng bàn phím. Đừng cho điểm chỉ vì đọc thấy trong code là “có vẻ đúng”. Mốc hiệu chỉnh: “trông ổn” là 6 điểm, không phải 9. Điểm 9 dành cho sản phẩm sống sót được qua một buổi phản biện của người có kinh nghiệm mà không cần sửa gì thêm.

Các mảnh ghép kỹ thuật, giải thích bằng ngôn ngữ đời thường

Đây là phần dễ khiến người làm thiết kế “rớt xe” nhất, vì toàn thuật ngữ kỹ thuật. Nhưng thực ra không phức tạp như nghe qua:

CLAUDE.md là một bản brief thường trực — file văn bản thuần trong dự án, được Claude đọc vào đầu mỗi phiên làm việc. Hãy tưởng tượng nó như tờ brief dán trên tường studio mà ai cũng đọc trước khi bắt đầu ngày làm việc. Vì nó được nạp lại mỗi lần, đây là nơi lưu các quy tắc lâu dài. Và giống hệt một tờ brief dán tường: nếu quá dài, người ta sẽ ngừng đọc nó — điều này sẽ quan trọng ở phần sau.
Skill là một quy trình đã lưu sẵn mà Claude chỉ lấy ra dùng khi công việc cần đến. Giống một tấm thẻ công thức nấu ăn trong ngăn kéo — bạn không đọc hết mọi công thức mỗi lần vào bếp, chỉ rút ra công thức cho món đang nấu. Nhờ vậy, “cách chạy một buổi review thiết kế” có thể nằm gọn trong một skill, dài và chi tiết, mà không tốn tài nguyên cho tới khi thực sự cần dùng. Tên kỹ thuật cho việc “chỉ tiết lộ chi tiết khi cần” là progressive disclosure — nói cách khác, ngăn kéo cứ đóng cho tới khi bạn mở nó ra.
Subagent là một trợ lý riêng biệt, có “bàn làm việc” và bộ nhớ ngắn hạn của riêng nó, được giao một việc cụ thể rồi báo cáo lại tóm tắt. Giống như cử một đồng nghiệp sang phòng khác để xem xét sản phẩm, đúng để họ không bị ảnh hưởng bởi cuộc trò chuyện đã tạo ra nó. Sự tách biệt này là thứ khiến subagent trở thành một giám khảo trung thực: nó có ngữ cảnh mới của riêng mình. Đây chính là cách bạn thực sự dựng nên hội đồng giám khảo — mỗi subagent phụ trách một góc nhìn.
Hook là một cơ chế kích hoạt tự động, gồm hai phần: sự kiện (khi nào) và hành động (làm gì). Ví dụ: “khi Claude hoàn thành một file, chạy kiểm thử”, hoặc “khi phiên làm việc bắt đầu, nạp quy tắc mới nhất”. Phiên bản đời thường là quy tắc lọc email: mỗi khi có email từ kế toán, tự động xếp vào thư mục Thuế. Bạn thiết lập một lần, nó chạy mãi, không cần hỏi lại. Khác biệt chính so với brief thường trực: brief là một “yêu cầu” mà Claude thường tuân theo, còn hook là một “sự đảm bảo” — đoạn code hệ thống luôn chạy dù Claude có định làm hay không. Nếu điều gì đó bắt buộc phải xảy ra, nó thuộc về một hook. Với vòng lặp này, một hook loại Stop (kích hoạt ngay khoảnh khắc Claude hoàn thành và trả quyền điều khiển lại cho bạn) sẽ tự động gọi hội đồng giám khảo, để buổi review chạy trước cả khi bạn kịp nhìn màn hình.
Memory (bộ nhớ) là cuốn sổ ghi lại bài học. Claude Code có thể tự viết ghi chú dựa trên những lần bạn sửa lỗi, và một giám khảo có thể giữ nhật ký riêng về những lỗi hay lặp lại. Hãy tưởng tượng nó như một trang wiki chung của team, ghi lại “những gì team đã học được một cách khó khăn”. Có một điểm bạn phải nắm rõ, vì đó là sự thật cốt lõi của toàn bộ chuyện này: mô hình không tự học từ các phiên làm việc của bạn. Nó bắt đầu mỗi phiên hoàn toàn mới, không nhớ gì về hôm qua. Thứ duy nhất còn lại là những gì đã được ghi vào các file, để rồi các file đó được nạp lại. Nói cách khác, “trí nhớ” là thứ bạn tạo ra bằng cách viết nó xuống, không phải điều mô hình tự làm.

Cách các mảnh ghép này ráp lại thành một vòng lặp

Xếp đúng thứ tự, bạn sẽ có một hệ thống tự vận hành:

Thiết kế. Claude dựng màn hình, từ file Figma, từ một bản brief, hay bất cứ gì bạn đưa vào.
Hiển thị và quan sát. Chụp lại mọi màn hình và mọi trạng thái, kể cả chế độ tối. Sau bất kỳ thay đổi nào, hiển thị lại các trạng thái bị ảnh hưởng và so sánh ảnh chụp từng byte một. Nếu hai màn hình lẽ ra phải khác nhau mà lại ra giống hệt nhau, nghĩa là có gì đó bị hỏng hoặc chưa từng được hiển thị ra. Sửa những lỗi rõ ràng này trước khi chấm điểm.
Chấm mù bằng hội đồng. Ngay khi sẵn sàng, các giám khảo chấm góc nhìn của mình theo bảng tiêu chí, chấm mù, trong ngữ cảnh riêng của từng người.
Sửa, rồi xác minh lại. Những lỗi rẻ tiền mà tác động lớn được gửi lại cho bên dựng như bản brief tiếp theo. Nó sửa lại, giám khảo kiểm tra lại.
Ghi lại vòng lặp. Lưu điểm nền chấm mù, điểm theo từng góc nhìn, và danh sách việc tồn đọng (backlog) cần làm tiếp, ưu tiên việc có tác động lớn nhất trước.
Học và ghi nhớ. Những lỗi lặp lại trở thành quy tắc, những lỗi mang tính máy móc trở thành cổng chặn (xem phần dưới), và những “điểm mù” mà giám khảo tự thừa nhận được ghi vào nhật ký.
Lần sau, đọc backlog trước. Xử lý những mục ưu tiên cao nhất trước khi làm việc mới. Điểm chấm mù phải leo lên.

Ví dụ thực tế từ tác giả: Cách kiểm tra so sánh ảnh chụp từng byte ở bước 2 giống hệt một bài kiểm thử tự động bị fail. Trong lần dùng thực tế, cách này bắt được một lỗi mà bên dựng đã lỡ đưa vào sản phẩm và tự soát lỗi (self-review) đã bỏ sót: một đoạn code dùng chung bị thiếu ở một file, khiến hai màn hình chia sẻ (share screens) bị hỏng mà không hề báo lỗi. Dấu hiệu duy nhất là hai màn hình đó hiển thị giống hệt màn hình gốc — tức là chẳng có gì mới được vẽ ra cả.

Làm sao để “nhớ” mà không phình to

Câu hỏi phổ biến nhất, và cũng là câu quyết định liệu cách làm này có sống sót qua tuần thứ hai hay không: file ghi nhớ có phình to và lộn xộn không?

Có, nếu bạn để nó như vậy. Và phình to không chỉ là vấn đề gọn gàng — nó là vấn đề chất lượng. Bản brief thường trực được nạp vào mọi phiên làm việc và chiếm một phần ngân sách xử lý có hạn; càng nhồi nhiều vào đó, Claude càng bám theo từng dòng kém tin cậy hơn. Một file quy tắc phình to sẽ khiến kết quả tệ đi — ngược hoàn toàn với mục đích ban đầu. Kỷ luật ở đây không phải là tùy chọn. Năm việc cần làm để giữ file gọn nhẹ:

Tách riêng nhật ký và quy tắc. Bản ghi dài về mọi lỗi từng gặp, cùng các phát hiện thô và “điểm mù” của giám khảo, nằm trong nhật ký (hoặc trong bảng điểm) — chỉ nạp khi cần. Chỉ những quy tắc đã được “thăng hạng” ngắn gọn mới nằm trong bản brief thường trực.
Chỉ thăng hạng khi lỗi lặp lại, không phải ngay từ lần đầu thấy. Một lỗi xảy ra một lần thì cứ để trong nhật ký. Một lỗi chỉ trở thành quy tắc lâu dài khi nó lặp lại, và khi đó hãy viết nó ở dạng tổng quát nhất có thể để loại bỏ cả một nhóm lỗi tương tự cùng lúc — ví dụ “chỉ dùng một màu nhấn duy nhất” sẽ loại bỏ mọi màu sai lệch trong tương lai, chứ không chỉ sửa cái nút sai màu lần này.
Nâng cấp các quy tắc máy móc thành “cổng chặn” (gate). Bất cứ điều gì một đoạn script có thể tự kiểm tra được (độ tương phản, kích thước vùng chạm, ký tự bị cấm, so sánh ảnh từng byte) nên trở thành kiểm tra tự động chạy trên bản dựng và có thể chặn việc coi là “xong”. Sau đó, xóa luôn quy tắc viết bằng văn xuôi tương ứng. Phiên bản sắc hơn: một lỗi máy móc cứ lặp lại mãi nên trở thành cổng chặn cứng, không phải một dòng trong backlog cứ kéo dài vô tận.
Đưa chi tiết đến đúng nơi, đúng lúc cần. Skill chỉ nạp khi cần dùng. Ghi chú riêng cho từng thư mục chỉ nạp khi Claude làm việc trong thư mục đó. Bản brief thường trực được giữ nhỏ gọn bằng cách đẩy mọi thứ khác ra ngoài.
Dọn dẹp định kỳ. Ghi ngày cho từng mục, giới hạn bản brief khoảng một trang, và mỗi tuần gộp các quy tắc trùng lặp, xóa những gì đã được thay bằng token, component, hoặc cổng chặn tự động.

Mẹo nhỏ: Một file quy tắc khỏe mạnh sẽ hội tụ dần, thậm chí co lại theo thời gian, vì bạn liên tục thay mười ghi chú cụ thể bằng một nguyên tắc tổng quát hơn, và chuyển các quy tắc máy móc thành cổng chặn tự động. Nếu file cứ phình to mãi, đó là dấu hiệu bạn đã ngừng dọn dẹp, chứ không phải bằng chứng cách làm này thất bại.

Vòng lặp chỉ tiến bộ nếu bạn tiếp tục mài giũa nó

Đây là phần dễ bị bỏ qua nhất, và bỏ qua nó chính là lý do phần lớn các thiết lập kiểu này dần “đứng hình”. Bản thân việc chạy vòng lặp không tự làm cho sản phẩm tốt hơn. Thứ khiến nó tốt hơn là bạn — người bắt được những gì vòng lặp còn bỏ sót và đưa nó ngược lại vào hệ thống.

Hội đồng chỉ chấm theo đúng bảng tiêu chí bạn đưa, nên nó chỉ bắt được những gì bảng tiêu chí đó đã biết cần tìm. Mọi bước tiến thực sự về chất lượng đều đến từ một khoảng trống mà nó bỏ lỡ: một màn hình nó cho qua nhưng bạn nhìn vào biết ngay là chưa ổn, một đề xuất đúng mà nó đưa ra, một lỗi lọt qua vì chưa có giám khảo nào phụ trách góc nhìn đó. Khoảng trống đó chính là tín hiệu. Khi thấy nó, hãy hành động: một lỗi lặp lại trở thành quy tắc mới, một lỗi máy móc trở thành cổng chặn, một “điểm mù” toàn diện trở thành một giám khảo mới, một tiêu chuẩn cứ đặt quá thấp trở thành một mốc chấm điểm sắc hơn.

Làm vậy, điểm số sẽ leo lên vì thước đo ngày càng sắc bén qua từng vòng lặp. Bỏ qua nó, cứ chạy y nguyên vòng lặp cũ mãi, thì nó sẽ chững lại ở đúng mức mà bảng tiêu chí đầu tiên tình cờ nắm bắt được. Bản thân mô hình không “thông minh hơn” giữa các lần chạy — chính bạn mới là người làm cho hệ thống thông minh hơn, mỗi khi biến một sai khác thành một quy tắc. Việc đó mới là “vòng lặp” thật sự, và nó là phần chỉ có người làm thiết kế mới làm được.

Bắt tay vào làm: hai mức độ triển khai

Mức 1: bản làm nhanh (một giám khảo, chat thường, làm ngay chiều nay)

Đây là phiên bản hai phút: một giám khảo mới, một lần chấm. Nó sẽ không chạy đủ cả hội đồng, cổng chặn hay bộ nhớ, nhưng bắt được phần lớn những gì tự soát lỗi hay bỏ sót. Về bản chất, đây là một góc nhìn của hội đồng, được rút gọn lại.

Dựng màn hình với Claude như bình thường.
Mở một đoạn chat hoàn toàn mới. Đoạn chat này chính là giám khảo của bạn. Việc bắt đầu mới toanh là mấu chốt — nó chưa hề chứng kiến quá trình dựng sản phẩm.
Đưa cho nó ba thứ: nguồn gốc (link Figma hoặc ảnh chụp thiết kế gốc), bản dựng (ảnh chụp hoặc link thật), và bảng tiêu chí bên dưới.
Yêu cầu nó chấm từng dòng, liệt kê cái làm đúng, và nêu tên từng lỗi kèm cách sửa cụ thể. Dặn nó gắn cờ những điểm khác biệt so với nguồn gốc mà thực ra là cải tiến, thay vì sửa chúng về như cũ.
Dán các chỗ cần sửa lại cho bên dựng. Lặp lại tới khi đạt mức bạn đặt ra.

Prompt gợi ý cho giám khảo:

Chấm mù: bạn không dựng sản phẩm này và chưa từng thấy điểm tự chấm của
bên dựng.
Chấm theo nguồn gốc, thang 1-10 cho mỗi dòng. "Trông ổn" là 6 điểm, không
phải 9. Một dòng chỉ được 8+ nếu bạn thực sự đã xác minh (đã hiển thị ra,
đã đo, đã thử), không tính điểm chỉ vì đọc thấy trong code.

1. Độ trung thành hệ thống - mọi màu sắc, kích thước, kiểu chữ, component
   khớp với token và quy tắc của design system.
2. Tính nhất quán - đọc như một sản phẩm có chủ đích, không phải template.
3. Độ chỉn chu - khoảng cách, các trạng thái, và chi tiết nhỏ đều đúng.
4. Tư duy UX - các trạng thái được xử lý, phân cấp rõ ràng, vùng chạm tối
   thiểu 44px.
5. Khả năng tiếp cận - độ tương phản chữ đạt 4.5:1, không có gì chỉ dựa
   vào màu sắc.

Với mỗi dòng: chấm điểm, nêu cái làm đúng, nêu cái bị bỏ sót kèm cách sửa
cụ thể. Gắn cờ mọi khác biệt so với nguồn gốc mà thực ra là cải tiến, và
đừng sửa những chỗ đó về như cũ. Không được coi là xong nếu có dòng nào
dưới 8 điểm hoặc độ tương phản không đạt.

Muốn có đủ ba góc nhìn của hội đồng nhưng không dùng Claude Code? Subagent thật chỉ tồn tại trong Claude Code, nên trong một đoạn chat thường thì không có gì để “tách” ra cả. Hãy tự chạy hội đồng bằng tay: mở ba đoạn chat mới riêng biệt, mỗi đoạn phụ trách một góc nhìn (độ chỉn chu/thương hiệu/độ trung thành; rồi UX/khả năng tiếp cận/chuyển động; rồi token/code/nội dung). Đưa mỗi đoạn cùng nguồn gốc và bản dựng nhưng chỉ giao đúng góc nhìn của nó, giữ tất cả ở chế độ chấm mù, rồi tự bạn tổng hợp ba điểm số lại. Vẫn là hội đồng đó, chỉ là do bạn điều phối thủ công.

Mức 2: vòng lặp đã “cài đặt” (Claude Code, tự chạy)

Khi phiên bản thủ công đã quen tay, hãy nối các mảnh ghép lại để nó chạy mà không cần bạn can thiệp:

Một bản brief thường trực (CLAUDE.md) chứa các quy tắc đã được thăng hạng.
Một skill review chứa bảng tiêu chí và các prompt giám khảo đã đóng khung, hiệu chỉnh sẵn, để thước đo không lạc trôi giữa các lần chạy kiểm tra.
Một hội đồng giám khảo gồm các subagent chấm mù trong ngữ cảnh riêng.
Một hook Stop tự động gọi giám khảo ngay khi bản dựng hoàn thành.
Các cổng chặn tự động cho các kiểm tra máy móc (độ tương phản, vùng chạm, ký tự bị cấm, so sánh ảnh từng byte) có thể chặn việc coi là “xong”.
Một nhật ký nơi các lỗi lặp lại và “điểm mù” của giám khảo tích lũy rồi được đưa ngược vào bản brief. Chỉ theo dõi một con số chính thức duy nhất — điểm nền chấm mù, qua từng vòng lặp.

Trong Claude Code, nơi subagent thật sự tồn tại, bạn có thể giao cho Claude cả vòng lặp trong một chỉ dẫn duy nhất, bao gồm cả hội đồng, cổng chặn và bước ghi nhớ. Nếu bạn quen thuộc với việc viết prompt hệ thống dạng này, đây là khung sườn:

xác định vai trò (chạy vòng lặp đánh giá mù, đối nghịch, không tự dựng sản phẩm);
bước chuẩn bị trước khi chấm (nạp design system, nạp brief và backlog, hiển thị mọi trạng thái và so sánh từng byte);
bước chấm bằng bốn giám khảo mù (ba đối nghịch theo ba góc nhìn ở trên, một mang tính xây dựng);
kỷ luật chấm điểm (dùng đúng prompt đã đóng băng, “trông ổn” = 6 điểm, chỉ 8+ khi đã xác minh, tổng hợp ba điểm đối nghịch thành một điểm nền chính thức);
cổng chặn cứng không thương lượng (tương phản đạt WCAG AA, vùng chạm ≥44px, không ký tự cấm, không có trạng thái nào lẽ ra khác nhau mà lại giống hệt);
và cuối cùng là bước áp dụng sửa lỗi, ghi log, thăng hạng quy tắc lặp lại, và tạo cổng chặn mới khi gặp một dạng lỗi hoàn toàn mới.

Một quy tắc đã thăng hạng, trên thực tế, chỉ là một dòng ngắn có ghi ngày trong bản brief — kiểu như: “Màu nhấn: chỉ dùng một màu nhấn duy nhất, các nút icon mặc định trung tính” hay “Giữ nguyên các cải tiến UX có chủ đích, đừng revert lại”.

Prompt gợi ý cho giám khảo:

# VAI TRÒ
Bạn thực hiện một vòng đánh giá thiết kế khách quan, không thiên vị đối với bản dựng. Bạn không phải là người xây dựng nó.

Hãy chấm điểm một cách trung thực, phát hiện những lỗi mà quá trình tự đánh giá bỏ sót, sửa chữa những lỗi nhỏ nhưng có tác động lớn, và kết thúc dự án với chất lượng tốt hơn so với lúc bạn nhận.

# TRƯỚC KHI CHẤM ĐIỂM
1. Tải nguồn dữ liệu gốc: hệ thống thiết kế (các token, kiểu chữ, quy tắc thành phần) và file Figma hoặc file tham khảo cho màn hình.

2. Tải các quy tắc hiện hành (CLAUDE.md) và danh sách công việc tồn đọng của bảng điểm mới nhất. Hãy ưu tiên xử lý các mục tồn đọng hàng đầu trước.

3. Hiển thị mọi màn hình và trạng thái, bao gồm cả chế độ tối. Sau bất kỳ thay đổi nào, hãy hiển thị lại các trạng thái bị ảnh hưởng và so sánh byte của ảnh chụp màn hình. Nếu hai trạng thái đáng lẽ phải khác nhau lại giống hệt nhau về byte, thì một trạng thái bị lỗi hoặc chưa được hiển thị.

Sửa chữa các lỗi rõ ràng trước khi chấm điểm.

# ĐÁNH GIÁ BẰNG HỘI ĐỒNG PHÊ BÌNH MÙ (3 phê bình đối kháng + 1 phê bình sáng tạo)
Tạo ra bốn tác nhân phê bình độc lập, mỗi tác nhân trong bối cảnh riêng biệt. Đánh giá chúng MÙ: không cho chúng điểm tự thân. Ba tác nhân đầu tiên mang tính đối kháng (tìm ra trường hợp yếu nhất, không thiên vị), trích dẫn bằng chứng (tệp:dòng hoặc màn hình cụ thể), và có các khía cạnh riêng biệt để không bị lẫn vào nhau:

- Phê bình A (kỹ thuật, thương hiệu, độ trung thực): so sánh kết quả hiển thị với mã nguồn, tìm kiếm các lỗi hình ảnh trên mọi màn hình, bao gồm cả chế độ tối.

- Phê bình B (UX, khả năng truy cập, chuyển động, xác minh): đo độ tương phản, kiểm tra các điểm chạm, lý giải về việc sử dụng bàn phím, xác nhận mọi trạng thái được hiển thị thực tế.

- Phê bình C (mã thông báo, mã, nội dung): đếm các giá trị được mã hóa cứng nơi tồn tại mã thông báo, tìm kiếm sự trùng lặp và các thủ thuật, tìm kiếm các ký tự và biểu tượng bị cấm trong bản sao.

- Phê bình D (cơ hội, sáng tạo, KHÔNG đối kháng): ba tác nhân kia tìm ra điểm yếu; tác nhân này tìm ra điểm mạnh. Tuân thủ mọi quy tắc thiết kế nghiêm ngặt, hệ thống này đặt câu hỏi về những gì công việc đang chấp nhận và những điểm nào mà một lựa chọn an toàn, phù hợp có thể đã tốt hơn. Nó chấm điểm mức độ hoàn thiện của thiết kế (0-10) và đề xuất 1-3 mẫu mạnh hơn được xây dựng chỉ từ các yếu tố cơ bản mà hệ thống đã có. Một màn hình sạch sẽ nhưng không nổi bật được chấm 5-6 điểm, chứ không phải 9. Nhà phê bình D không thay đổi điểm số mù; nhận xét và đề xuất của nó là hướng đi cho vòng lặp tiếp theo.

Ba nhà phê bình đối kháng mỗi người trả lời, theo từng khía cạnh: một số nguyên từ 0-10, các lỗi hàng đầu với các giải pháp khắc phục chính xác, và một "điểm mù" (những gì nó có thể đã bỏ sót).

# NGUYÊN TẮC CHẤM ĐIỂM

- Sử dụng các gợi ý tiêu chí đã được hiệu chỉnh (các điểm tham chiếu), để thước đo luôn giống nhau trong mỗi vòng lặp.

- "Trông ổn" được chấm 6 điểm, chứ không phải 9 điểm. Điểm 9 hoặc 10 là công việc vượt qua được sự phê bình của cấp trên mà không bị thay đổi.

- Một khía cạnh chỉ được chấm điểm 8+ NẾU thực sự được xác minh: hiển thị, đo lường, kiểm tra độ tương phản, kiểm tra bàn phím. Không bao giờ chấm điểm dựa trên việc đọc mã.

- Hợp nhất ba ý kiến phê bình thành MỘT tổng điểm có trọng số. Điểm chuẩn khách quan này là con số chính thức cho vòng lặp này. Không báo cáo số hậu tố làm điểm số; đó là "công việc đã hoàn thành", không phải là điểm số.

# CÁC TIÊU CHUẨN BẮT BUỘC (khối "đã hoàn thành", không thể thương lượng)

- Độ tương phản văn bản đáp ứng WCAG AA (4.5:1 cho văn bản chính, 3:1 cho văn bản lớn).

- Kích thước mục tiêu tương tác tối thiểu 44px.

- Không có ký tự bị cấm hoặc UI-as-glyph trong văn bản.

- Không có trạng thái giống hệt nhau về byte mà đáng lẽ phải khác nhau.

Nếu bất kỳ tiêu chuẩn nào không đạt, công việc chưa hoàn thành, bất kể điểm số là bao nhiêu.

# QUY TẮC THAM GIA

- Đánh dấu những sai lệch so với mã nguồn mà thực sự là những cải tiến. KHÔNG sửa lại những sai lệch đó; hãy đưa chúng ra để người khác xem xét.

- Bảo tồn những cải tiến UX có chủ đích. Không làm phẳng mã nguồn.

- Chấm điểm như một đối thủ. Đừng khen ngợi bất cứ điều gì một cách mặc định.

# SAU ĐÓ

- Áp dụng các biện pháp khắc phục hiệu quả cao, chi phí thấp mà hội đồng đã đề xuất; kiểm tra lại. - Ghi lại quá trình vào bảng điểm: điểm chuẩn ban đầu, bảng theo từng khía cạnh, những phát hiện thô và điểm mù của người phê bình, và danh sách công việc tồn đọng (ưu tiên những công việc có ảnh hưởng lớn nhất). Điểm chuẩn ban đầu phải được cải thiện liên tục.

- Đưa những sai sót lặp đi lặp lại vào các quy tắc thường trực như quy tắc CHUNG NHẤT có thể loại bỏ toàn bộ nhóm. Nâng cấp bất kỳ quy tắc máy móc nào thành một cổng hoặc quy tắc kiểm tra và xóa phiên bản văn xuôi, để bản tóm tắt luôn hoạt động được gọn nhẹ.

- Khi một loại lỗi mới xuất hiện, hãy thêm một điểm neo trong bảng đánh giá để nó không thể tái diễn.

Hai điều cần nói thẳng, để bạn không “thổi phồng” cách làm này với chính mình hay với khách hàng: Mô hình không âm thầm học từ bạn — mọi thứ “dính lại” đều là một file bạn đã viết ra và nó được nạp lại mỗi lần. Và một thiết lập “tự cải thiện mãi mãi, không cần động tay” chưa phải là một nút bấm có sẵn — bạn tự lắp ráp nó từ các mảnh ghép trên và thỉnh thoảng phải dọn dẹp. Việc dọn dẹp đó chính là phán đoán của con người — điều này giữ cho công việc vẫn thuộc về người làm thiết kế, không phải một cỗ máy.

Tóm gọn

Dùng Claude như một cái máy in kết quả một lần rồi sẽ chững lại. Một vòng lặp đánh giá biến nó thành một hệ thống biết thiết kế, tự chấm điểm, học hỏi, và cải thiện — với điều kiện bạn là người liên tục mài giũa bảng tiêu chí và bộ quy tắc phía sau nó. Đừng bao giờ để nó tự chấm bài của chính mình. Hãy bắt đầu bằng phiên bản thủ công bằng tay ngay chiều nay, rồi mới tính đến chuyện “cài đặt” để nó tự chạy khi mọi thứ đã quen tay.