Cách chúng tôi xây dựng lại quy trình sàng lọc hồ sơ ứng viên với AI-Native Workflow

Bài viết này nói về một thử nghiệm nhỏ: kết nối cơ sở dữ liệu tuyển dụng Notion của chúng tôi với Claude Code và chạy một quy trình làm việc động (dynamic workflow) triển khai hơn 100 AI agent song song để đọc hồ sơ, chấm điểm chúng theo một tiêu chí nhất quán, và đối chiếu chéo đánh giá của nhau — tạo ra một danh sách rút gọn đã được xếp hạng mà chúng tôi có thể hành động ngay lập tức.

Toàn bộ quá trình tốn 65 đô la và chạy trong khoảng 13 phút cho 115 ứng viên. Nhưng thú vị hơn cả chi phí là những câu hỏi về phương pháp mà nó đặt ra — khi nào nên dùng một đội quân agent thay vì một agent duy nhất, cách ngăn chặn tình trạng AI chấm điểm quá cao, và ý nghĩa của việc mã hóa "sự xuất sắc" thành thứ mà một máy thực sự có thể thực thi.

1. Quy Trình Làm Việc Động Là Gì

Hãy bắt đầu với khái niệm này, vì đây là nền tảng cho tất cả những gì tiếp theo.

Phần lớn việc sử dụng AI hiện nay theo mô hình hỏi-và-đáp: gửi một tin nhắn, nhận câu trả lời, rồi lặp lại. Cách này hoạt động tốt cho các nhiệm vụ đơn lẻ, nhưng sẽ trở nên bất tiện khi bạn cần làm điều tương tự với 115 đối tượng — bạn hoặc phải sao chép và dán 115 lần, hoặc yêu cầu một cuộc hội thoại duy nhất xử lý chúng theo trình tự, điều này càng về sau càng chậm và lộn xộn hơn.

Quy trình làm việc động là một mô hình khác: mã lệnh điều phối một đội quân AI agent. Các đặc điểm quyết định của nó là:

• Luồng điều khiển xác định (deterministic) + đánh giá của AI, được tách biệt rõ ràng. Vòng lặp, phân phối, tổng hợp, và thực thi hạn ngạch được xử lý bởi mã lệnh (có thể tái tạo, có thể kiểm chứng); đánh giá chủ quan (hồ sơ này có đủ mạnh không?) được giao cho các AI agent.
• Song song phân nhánh (fan-out). Một lệnh gọi parallel(...) duy nhất có thể khởi tạo hàng chục hoặc hàng trăm agent độc lập cùng lúc, mỗi agent xử lý phần việc riêng của mình mà không làm ảnh hưởng đến các agent khác.
• Pipeline nhiều giai đoạn. Đầu ra của một giai đoạn sẽ trở thành đầu vào cho giai đoạn tiếp theo. Mã lệnh xử lý việc lọc, xếp hạng, và loại bỏ trùng lặp giữa các giai đoạn.
• Đầu ra có cấu trúc. Mỗi agent trả về JSON tuân theo một schema — không phải văn bản chat tự do — để mã lệnh phía sau có thể sử dụng trực tiếp.

Một phép so sánh: một cuộc hội thoại đơn lẻ giống như tham khảo ý kiến của một chuyên gia trong một buổi chiều. Một quy trình làm việc động giống như thành lập một hội đồng đánh giá gồm 125 người, phát cho mỗi người một tiêu chí và một hồ sơ ứng viên, tiến hành tất cả các đánh giá song song, đối chiếu chéo các kết quả hàng đầu, và tổng hợp thành một danh sách xếp hạng — với logic thành lập, phân phối, và tổng hợp được tích hợp sẵn trong script.

Việc sàng lọc hồ sơ là một trường hợp phù hợp tự nhiên với mô hình này: khối lượng lớn, tiêu chí đồng nhất, đánh giá chủ quan, yêu cầu về sự công bằng.

Để có phần giới thiệu kỹ thuật sâu hơn: A harness for every task: dynamic workflows in Claude Code

2. Quy Trình Tuyển Dụng: Mục Tiêu và Thiết Kế

Vấn đề

Chúng tôi có một vấn đề cụ thể: hơn một trăm ứng viên đang nằm ở trạng thái "đánh giá ban đầu" trong cơ sở dữ liệu tuyển dụng Notion của chúng tôi, mà không có cách thực tế nào để xử lý thủ công mà không gặp phải sự trôi dạt tiêu chuẩn (standard drift) — mức tiêu chuẩn bạn áp dụng ở hồ sơ số 80 gần như không bao giờ giống với mức tiêu chuẩn ở hồ sơ số 5.

Tôi muốn kiểm chứng một ý tưởng cụ thể: liệu chúng ta có thể trừu tượng hóa "thế nào là xuất sắc trong thời đại AI agent" thành một tiêu chí mà máy có thể thực thi, con người có thể đọc hiểu, rồi cho tất cả 115 ứng viên trải qua cùng một mức chuẩn hóa đó không?

Mục tiêu rõ ràng không phải là để AI ra quyết định tuyển dụng. Mục tiêu là:

1. Cô đọng 115 ứng viên thành một danh sách rút gọn đã được xếp hạng, có lý giải rõ ràng để sự chú ý của con người dồn vào những người thực sự xứng đáng.
2. Làm cho các tiêu chí trở nên minh bạch và có thể lặp lại điều chỉnh — nếu đầu ra sai, bạn sửa một file Markdown, không phải sửa mã lệnh hay dựa vào cảm tính.

Ba quyết định thiết kế then chốt

Quyết định 1: Tiêu chí và mã lệnh hoàn toàn tách biệt

Các tiêu chí đánh giá nằm trong các file Markdown độc lập (criteria/), không được nhúng vào mã lệnh quy trình làm việc. Bất kỳ ai — kể cả đồng nghiệp không chuyên về kỹ thuật — cũng có thể thay đổi hành vi sàng lọc bằng cách chỉnh sửa các file này:

criteria/
├── 00-philosophy.md          Overall philosophy: what we're hiring for + the "raise the bar" rule
├── 01-pedigree.md            Strong academic / early foundation    (weight 20%)
├── 02-ai-agent-fluency.md    AI-native capability                  (weight 35%)
├── 03-grit-problem-solving.md  Problem-solving & overcoming difficulty  (weight 30%)
├── 04-talent-lens.md         Top-talent signal                     (weight 15%)
└── scoring.md                Scoring formula + grade bands + 5% quota rule

Bốn khía cạnh này là "chuẩn xuất sắc cho thời đại AI agent, phiên bản v0.1" của chúng tôi. Suy nghĩ đằng sau mỗi khía cạnh:

• Năng lực AI-native chiếm trọng số cao nhất (35%). Vào năm 2026, việc một người có thực sự sử dụng các công cụ agentic như Claude Code như một phần cốt lõi trong cách họ làm việc hay không là một yếu tố phân định năng suất lớn. Chúng tôi đặc biệt trừ điểm việc nhồi nhét từ khóa — chỉ ghi "Claude Code" mà không có bằng chứng dự án có thể kiểm chứng được coi là dấu hiệu yếu.
• Bằng chứng cụ thể về khả năng giải quyết vấn đề (30%). Chúng tôi tìm kiếm "vết sẹo": những thứ được xây dựng độc lập từ đầu, những câu chuyện về việc vượt qua các trở ngại thực sự — không phải các bản sao ở mức độ hướng dẫn (tutorial).
• Nền tảng vững chắc (20%). Nền tảng học thuật đóng vai trò như một chỉ số phụ cho tiềm năng thô — đó là một tín hiệu, không phải một yêu cầu bắt buộc. Một tấm bằng từ trường đại học chọn lọc đi kèm với sản phẩm đầu ra tầm thường sẽ bị trừ điểm; một người tự học không có bằng cấp danh tiếng nhưng có sản phẩm thực sự đã hoàn thành sẽ được cộng điểm.
• Dấu hiệu tài năng hàng đầu (15%). Khía cạnh này chủ ý mang tính chủ quan. Prompt hỏi rằng: liệu một nhóm như của Anthropic hay một nhà sáng lập như Musk có muốn liên hệ ngay lập tức không? Nó nắm bắt tính chủ động, khiếu thẩm mỹ, và tốc độ mà ba khía cạnh khác không thể hiện được.

Quyết định 2: Mã hóa "nâng cao tiêu chuẩn" thành một ràng buộc cứng, không phải một câu slogan

scoring.md bao gồm một quy tắc chắc chắn: các ứng viên đạt hạng cao nhất (S) phải chiếm ≤ 5% toàn bộ nhóm ứng viên. Sau khi hoàn tất tất cả việc chấm điểm, mã lệnh áp dụng một giới hạn toàn cục: dù nhiều ứng viên về mặt kỹ thuật đạt mức điểm S, chỉ 5% hàng đầu được cho phép vượt qua. Điều này trực tiếp chống lại một chế độ thất bại đã biết — việc chấm điểm bằng AI tự nhiên có xu hướng khoan dung. Không có ràng buộc cứng, nó sẽ chấm điểm một nửa nhóm ứng viên là "xuất sắc."

Quyết định 3: Thêm đánh giá phản biện để bắt các điểm số bị thổi phồng

Chỉ chấm điểm là chưa đủ. Một agent chấm điểm đơn lẻ có thể bị cuốn theo các từ khóa nghe có vẻ ấn tượng — "đã đăng trên tạp chí hàng đầu," "đã xây dựng framework của riêng tôi." Vì vậy, các ứng viên được xếp hạng cao nhất sẽ trải qua một lượt đánh giá thứ hai: một hội đồng gồm các agent "phản biện" (devil's advocate) với nhiệm vụ rõ ràng là lập luận chống lại việc "người này đáng được xếp hạng cao nhất" và hạ điểm ở bất cứ đâu mà bằng chứng không hoàn toàn thuyết phục.

Quy trình làm việc

Thiết lập 📋 Cơ sở dữ liệu tuyển dụng Notion — Kéo dữ liệu qua Notion CLI → một file dữ liệu có cấu trúc cho mỗi ứng viên

AI Giai đoạn 1: Chấm điểm (115 agent song song)

• Đọc 6 file MD tiêu chí + file dữ liệu của ứng viên đó
• Chủ động truy cập các liên kết GitHub / portfolio để xác minh bằng chứng
• Xuất ra JSON có cấu trúc: điểm số 4 khía cạnh + lý giải + điểm nổi bật + cờ cảnh báo rủi ro

Code Tổng hợp xác định

• Tính tổng điểm có trọng số
• Sắp xếp thứ hạng toàn cục, tính số vị trí hạn ngạch 5%
• Chọn các ứng viên hàng đầu vào hàng đợi đánh giá phản biện

AI Giai đoạn 2: Đánh giá phản biện (Agent song song)

• Nhân vật "phản biện" đánh giá từng ứng viên hàng đầu
• Lập luận chống lại việc xếp hạng cao nhất
• Hạ điểm ở nơi bằng chứng không đủ thuyết phục

Code Kết luận xác định

• Sắp xếp lại theo điểm số đã được điều chỉnh
• Thực thi giới hạn cứng 5%
• Gán các dải hạng cuối cùng: S / A / B / C / D

Đầu ra: Báo cáo xếp hạng Markdown có cấu trúc với điểm số, lý giải, và kết luận đánh giá phản biện cho từng ứng viên

Các giai đoạn màu xanh (chấm điểm / đánh giá) là AI. Các giai đoạn màu xám (tổng hợp / kết luận) là mã lệnh. Sự phân chia này là chủ ý: bất cứ điều gì có tính toán học — trọng số, xếp hạng, thực thi hạn ngạch — được giao cho mã lệnh để đảm bảo khả năng tái tạo; bất cứ điều gì cần đánh giá — người này có đủ mạnh không? — được giao cho AI.

3. Những Gì Chúng Tôi Thấy: Kết Quả và Nhận Định

Tất cả các ứng viên dưới đây đều đã được ẩn danh. Chúng tôi mô tả loại công việc, không phải tên hay thông tin nhận dạng.

Những gì chúng tôi đã chạy

Phân bố

Hạn ngạch 5% (5 vị trí) hoàn toàn không được sử dụng — không phải hạn ngạch chặn ai đó; mà chính ngưỡng điểm tuyệt đối đã làm điều đó. Không ai tự vượt qua sàn của dải A. Chúng tôi sẽ nói thêm lý do đây thực sự là một tín hiệu hữu ích ở phần dưới.

Nhóm đầu bảng xếp hạng trông như thế nào (đã ẩn danh)

Không có ngoại lệ, các ứng viên xếp hạng cao nhất đều là những người đã thực sự xây dựng agent — không phải những người chỉ nghe nói về AI:

• #1: Một học viên cao học đã xây dựng từ đầu một workbench đa agent theo kiểu Claude Code — bao gồm vòng lặp chính của agent, phân tích cú pháp gọi công cụ, nén ngữ cảnh, sinh sub-agent, và cổng an toàn. Tất cả là mã lệnh có thể kiểm chứng, không phải mô tả.
• #2: Một học viên cao học khác đã triển khai một hệ thống đa agent thực sự, có thể truy cập công khai (ứng dụng trong lĩnh vực chuyên biệt), với sản phẩm học thuật được xây dựng thêm bên trên.
• Xa hơn nữa: một người viết một engine điều phối agent bằng Go từ đầu; một người phát hành một agent viết mã nhẹ bằng cách nghiên cứu kiến trúc của Claude Code; một người tự xây dựng một game với một LLM cục bộ trong bảy ngày, sử dụng công cụ AI xuyên suốt.

Điểm chung của họ: các tín hiệu mạnh của họ hầu như không bao giờ xuất hiện trong phần nội dung hồ sơ — chúng nằm trong các repo GitHub và portfolio. Đây chính là lý do tại sao mỗi agent chấm điểm được chỉ dẫn phải chủ động truy cập các liên kết và xác minh bằng chứng thay vì chỉ đọc văn bản hồ sơ.

Ba nhận định

Nhận định 1: Đánh giá phản biện thực sự đã bắt được các điểm số bị thổi phồng

Ví dụ rõ ràng nhất là hai ứng viên hàng đầu. Sau giai đoạn chấm điểm, cả hai đều có tổng điểm có trọng số khoảng 82 điểm — đủ để lọt vào dải A và chạm ngưỡng S. Sau đánh giá phản biện, cả hai giảm xuống khoảng 75 điểm, với lý giải rất cụ thể:

"Đã xây dựng một workbench đa agent có thể kiểm chứng — năng lực AI-native là một tín hiệu vững chắc. Nhưng dự án chỉ mới khoảng 3 tuần tuổi, một người thực hiện duy nhất, 0 star, không có test. Về mặt khái niệm là tái triển khai, không phải giải quyết vấn đề một cách nguyên bản. Hầu như không có bằng chứng hỗ trợ nào ngoài dòng học vị: một ứng viên tiềm năng cao vững chắc, nhưng không xuất sắc."

"Một người xây dựng AI-native thực sự, có thể kiểm chứng. Nhưng bài đăng trên tạp chí hàng đầu được nêu chỉ xuất hiện trong ghi chú của nhà tuyển dụng, không có nguồn có thể kiểm chứng độc lập. Backend của hệ thống lõi là riêng tư; đóng góp cá nhân không thể xác nhận được. Sử dụng bằng cấp học thuật chưa được xác minh để vươn tới hạng cao nhất là hành vi thổi phồng điểm số dựa trên từ khóa."

Đây chính xác là điều thiết kế này nhằm đạt được: nó không loại bỏ những ứng viên này — nó điều chỉnh điểm số về mức mà bằng chứng thực sự có thể hỗ trợ. Một agent chấm điểm đơn lẻ có thể bị cuốn theo cảm xúc; một hội đồng agent riêng biệt với nhiệm vụ phản biện sẽ hạ điểm một cách đáng tin cậy.

Nhận định 2: S:0 / A:0 không phải là lỗi — đó là một tấm gương

Bản năng đầu tiên là hỏi liệu tiêu chuẩn có được đặt sai không. Nhưng nhìn vào nhóm ứng viên một cách trung thực:

• Một phần lớn ứng viên có hồ sơ rất sơ sài — các khía cạnh quan trọng (kinh nghiệm AI, công việc có thể kiểm chứng) hoàn toàn vắng bóng.
• Nhiều người ứng tuyển vào vai trò Agent Engineer có không hề có bằng chứng sử dụng công cụ agentic và không có liên kết GitHub.
• Nhóm ứng viên cũng chứa các email kinh doanh của nhà tuyển dụng và thông báo hệ thống LinkedIn — những thứ này được nhận diện chính xác là không liên quan và chấm điểm 0, điều này vô tình cho thấy cơ sở dữ liệu tuyển dụng của chúng tôi cần được dọn dẹp.

Nói cách khác, một tiêu chí nghiêm ngặt đã phân tách rõ ràng tín hiệu khỏi nhiễu. Những người xây dựng thực sự (top 6) và "những người tổng quát có thành tích" (nhóm giữa) cuối cùng nằm ở những vị trí rõ ràng khác biệt. Đó chính là điểm mấu chốt — chấp nhận bỏ sót một vài người thay vì thổi phồng điểm cho tất cả.

Điều này cũng đặt ra một câu hỏi mở đáng được thảo luận: liệu ngưỡng dải A hiện tại (78 điểm) có quá khắc nghiệt đối với các ứng viên là sinh viên có hồ sơ GitHub mạnh nhưng chưa có kinh nghiệm chuyên môn không? Thú vị là, chính các agent đánh giá phản biện đã mô tả hai ứng viên hàng đầu là "ứng viên tiềm năng cao" — nhưng điểm số có trọng số vẫn giữ họ ở dải B. Việc có nên nới ngưỡng đó cho các ứng viên tiềm năng cao ở giai đoạn đầu sự nghiệp hay không là một quyết định đánh giá tốt nhất nên được đưa ra sau khi chúng ta thấy được chất lượng phỏng vấn thực tế từ nhóm B. Tin tốt là: thay đổi đó chỉ là một con số trong một file Markdown. Không cần mã lệnh nào cả.

Nhận định 3: "Tiêu chí như mã lệnh" làm cho sự bất đồng trở nên hữu ích

Các cuộc thảo luận về tiêu chuẩn tuyển dụng thường mơ hồ — "chúng ta muốn người có động lực," "ai đó có thể tự tìm ra giải pháp." Vì tiêu chí này được viết ra với các trọng số và ví dụ tham chiếu cụ thể, cuộc thảo luận ngay lập tức trở nên cụ thể: "Năng lực AI nên là 35% hay 40%?" "Một người xây dựng nổi bật không có bằng cấp danh tiếng thực sự được lợi bao nhiêu?" "Hạn ngạch nên là 5% hay 8%?" — mỗi bất đồng tương ứng với một dòng cụ thể trong một file Markdown có thể được thay đổi, quản lý phiên bản, và tranh luận. Tiêu chuẩn trở thành một tài sản mà bạn duy trì, không phải một sự đồng thuận bạn phải lặp lại trong mỗi cuộc họp.

4. Chi Phí và ROI

Chi tiêu chính xác

Chúng tôi đã sử dụng Claude Opus 4.8 (hạng cao nhất). Chi tiết chính xác theo loại token:

Điều này quy ra khoảng $0.57 cho mỗi ứng viên.

Một phát hiện phản trực giác: cache write là mục chi lớn nhất

Giả định tự nhiên là vì 115 agent đều đọc cùng 6 file tiêu chí, việc cache prompt lẽ ra sẽ giúp ích rất nhiều. Nhưng không phải theo cách bạn nghĩ.

Cache prompt hoạt động dựa trên việc khớp tiền tố chính xác (exact prefix match), và mỗi session agent là độc lập. 125 agent nghĩa là 125 session độc lập — mỗi session có một mô tả nhiệm vụ khác nhau (dữ liệu ứng viên khác nhau) — vì vậy cache được viết bởi agent A không thể được agent B truy cập lại. Việc cache thực sự có giúp ích trong quá trình thực thi nhiều lượt của riêng mỗi agent (đọc tiêu chí → truy cập GitHub → truy cập portfolio → xuất kết quả, đọc lại nội dung trước đó ở mỗi lượt).

Điều này cho thấy một sự đánh đổi về kiến trúc: song song phân nhánh làm tăng gấp nhiều lần chi phí cache write (mỗi agent xây dựng cache riêng của mình), nhưng đổi lại bạn có được đánh giá độc lập, không bị nhiễm chéo, và loại bỏ được sự tích lũy ngữ cảnh theo cấp bậc hai của việc xử lý tuần tự. Đối với các nhiệm vụ nhạy cảm về chất lượng đánh giá, sự đánh đổi đó là đáng giá.

Cách nhìn nhận ROI

So sánh trực tiếp với đánh giá thủ công: một quản lý tuyển dụng đọc kỹ một hồ sơ, kiểm tra GitHub, và viết ghi chú — ước tính khiêm tốn là 5 đến 10 phút mỗi ứng viên. Với 115 ứng viên, đó là 10 đến 19 giờ làm việc tập trung, với tiêu chuẩn trôi dạt xuyên suốt.

Quy trình làm việc này đã mang lại:

Nhưng ROI quan trọng hơn là về sự chú ý: nó chuyển hướng sự tập trung của con người ra khỏi 83 ứng viên rõ ràng không phù hợp và hướng về 6 người xây dựng thực sự ở hàng đầu. Đó là điều có giá trị cao nhất mà sàng lọc ban đầu có thể mang lại.

Liệu có thể rẻ hơn không?

Có, nhưng có lẽ không cần thiết. Nếu điều này trở thành một hoạt động tần suất cao, khối lượng lớn (hàng trăm ứng viên mỗi ngày), việc tối ưu hóa thực tế sẽ là:

• Sử dụng Sonnet cho giai đoạn chấm điểm, chỉ dùng Opus cho đánh giá phản biện — có thể giảm 70 đến 80% chi phí với tổn hại chất lượng tối thiểu.
• Hoặc sử dụng một model rẻ hơn cho một lượt sàng lọc thô ban đầu, sau đó dùng Opus cho đánh giá chi tiết của nhóm hàng đầu.

Nhưng tuyển dụng có tần suất thấp, mức độ quan trọng cao, và khó đảo ngược. Với $65 để xử lý toàn bộ pipeline với khả năng kiểm chứng đầy đủ và tiêu chí có thể lặp lại điều chỉnh, kết luận rất rõ ràng: sử dụng model tốt nhất. Đừng đánh đổi chất lượng đánh giá để tiết kiệm chi phí không đáng kể.

Toàn cảnh lớn hơn

Điều thực sự thú vị về thử nghiệm này không phải là "AI có thể sàng lọc hồ sơ" — đó không phải là một ý tưởng mới. Mà là mô hình quy trình làm việc động — mã lệnh điều phối một đội quân AI agent — lần đầu tiên khiến một số loại công việc trở nên có cấu trúc, có thể tái tạo, và có thể lặp lại điều chỉnh.

Tuyển dụng chỉ là điểm khởi đầu. Cùng một mô hình — tiêu chí như các file có thể đọc được + đánh giá song song phân nhánh + đánh giá phản biện + tổng hợp xác định — có thể chuyển giao sang bất kỳ lĩnh vực nào cần đưa ra các đánh giá chủ quan nhất quán, khối lượng lớn: kiểm duyệt nội dung, review mã, phân loại phản hồi người dùng, phân tích cạnh tranh, thẩm định (due diligence).

Tiêu chí này là phiên bản v0.1. Nó không hoàn hảo. Nhưng bây giờ nó là một tài sản có quản lý phiên bản, có thể tranh luận, có thể cải thiện — không phải một sự đồng thuận ngầm chỉ tồn tại trong đầu ai đó. Sự thay đổi đó, hơn bất kỳ kết quả cụ thể nào, mới thực sự là điều mà thử nghiệm này muốn hướng tới.