Nhóm copy nguyên file README này về repo của mình, rồi điền bảng trên. Cột Phần việc đảm nhiệm ghi càng cụ thể càng tốt.

• Thời lượng: 47,5 giờ từ phát đề đến thuyết trình (ca 3A) — LAB 5 (phát đề + build) · LEC 6 (tiếp tục build theo ca) · LAB 6 (vòng thi)
• Nhóm: 3-4 người · thi theo phòng (E403 / E402), chia cụm rồi chung kết phòng — xem Thể thức thi
• Chia cụm theo bàn, không cần chung đề tài. Chủ đề tự chọn trong khuôn khổ đề bài
• Nhóm nhỏ thì chọn lát cắt nhỏ, và phải có khảo sát nỗi đau thật — đây là chỗ ăn điểm nặng nhất

Bắt đầu từ đâu?

1. Đọc 01-challenge-brief.md để hiểu khung chung và 5 tiêu chí, rồi tracks/README.md để chọn track và đề.
2. Mở 02-guide.md — hướng dẫn từng giai đoạn, đứng ở đâu đọc mục đó.
3. Viết spec theo 03-ai-spec-template.md — deliverable trung tâm của cả sự kiện.
4. Đọc 04-rubric.md ngay từ đầu — biết trước bài được chấm theo tiêu chí nào.

Lịch — 6 checkpoint (ca 3A · 47,5 giờ)

CP1 đến CP5 mỗi mốc 5 điểm. Nộp đúng hạn được đủ, nộp muộn là 0 điểm mốc đó — không bù được bằng mốc khác.

Làm bài lúc nào

Hai phòng cùng ca dùng chung lịch mốc. Năm link form phát đủ từ đầu — xong mốc nào nộp mốc đó, không phải chờ.

Giải thích từng mốc

CP1 · Chốt Canvas + repo

Để làm gì: chốt rõ làm cho ai và giải vấn đề gì trước khi bắt tay vào code. Bỏ qua bước này thì hay gặp cảnh làm xong mới nhận ra không ai cần đến.

Nộp:

• Canvas điền đủ 4 ô theo mẫu trong 01-challenge-brief.md
• Họ tên và mã học viên của đội trưởng
• Link repo GitHub đã để công khai
• Khai báo willing user — người sẵn sàng cho nhóm thử sản phẩm ở CP5. Cần ít nhất 2 người, khai từ đây

Khai willing user ngay từ CP1, đừng để đến CP5. Khối R6 ở CP5 yêu cầu có ít nhất 2 willing user đã khai ở mốc này. Đến lúc cần mới đi tìm người thì không kịp.

CP2 · Cho thấy luồng hoạt động

Để làm gì: nhìn được cả luồng từ đầu đến cuối — người dùng bấm gì trước, thấy gì sau, kết thúc ở đâu. Vẽ ra giấy thì phát hiện chỗ hổng trong mười phút; code xong mới thấy thì mất cả buổi sửa.

Nộp một trong ba thứ, thứ nào cũng được:

• Bản mock bấm được — Figma, trang tĩnh, Canva, bất cứ thứ gì click qua lại được
• Sơ đồ luồng vẽ tay hay vẽ máy, miễn thấy rõ các bước
• Video quay màn hình đi hết một lượt

Chưa cần AI chạy thật — cái đó để CP3. Mốc này để nhẹ, chỉ cần cho thấy nhóm đang đi hướng nào.

CP3 · Video thao tác + số đo

Để làm gì: biết sản phẩm của mình đang đúng đến đâu. Có con số thì mới biết nên sửa chỗ nào tiếp, và lúc pitch cũng có cái để nói thay vì nói suông.

Nộp hai thứ:

1 · Video thao tác — 30 giây, quay màn hình. Bấm thật trên sản phẩm, thấy AI trả kết quả thật. Không cần dựng, không cần lồng tiếng.

2 · Số đo — thử bao nhiêu lần, đúng được bao nhiêu.

Đây là con số cho biết sản phẩm tốt đến đâu. Cách làm:

1. Chuẩn bị một bộ câu thử  — ví dụ 20 câu hỏi người dùng hay hỏi
2. Cho sản phẩm chạy hết 20 câu đó
3. Đếm bao nhiêu câu ra kết quả đạt chuẩn nhóm tự đặt

Số xấu vẫn được đủ điểm — miễn là số thật. 13 trên 21 mà phân tích được vì sao 8 câu kia sai thì ăn điểm cao hơn "chạy tốt" không có gì chứng minh.

CP4 · Chốt spec.md

Để làm gì: chốt "thế nào là đạt" trước khi biết kết quả. Đặt chuẩn sau khi đã thấy kết quả thì con số không nói lên điều gì — và người nghe cũng biết vậy.

Nộp:

• Link spec.md đã chốt — trong đó nhóm tự chốt "thế nào là đạt" cho sản phẩm mình
• Tự khai phần nào chưa làm xong

Sau 21:00 hôm đó không sửa chuẩn "đạt" được nữa.

Khai thiếu không bị trừ điểm. Giấu mới bị.

CP5 · Slide + video dự phòng

Để làm gì: đảm bảo buổi pitch chạy được dù mạng hỏng hay máy chết. Đây cũng là hạn nộp cuối — sau mốc này không nộp thêm gì.

Nộp:

• Slide 6 trang, xuất ra PDF theo 02-guide.md §5.1. Nộp PDF chứ không nộp link — link hay hỏng quyền đúng lúc cần
• Video demo dự phòng — quay sẵn phần demo. Nếu hôm pitch mạng chết thì BTC chiếu video này và không trừ điểm

CP3 và CP5 là hai video khác nhau: CP3 chứng minh sản phẩm chạy — quay ngắn, quay thô cũng được. CP5 là bản sao lưu để buổi pitch không chết vì mạng — quay đúng phần định demo trên sân khấu.

CP6 · Thuyết trình

Không nộp gì. Ngày này chỉ để trình bày.

Giám khảo có thể hỏi bất kỳ thành viên nào về phần có tên người đó trong bảng phân công.

Link nộp

Đội trưởng nộp form thay cả nhóm — một phiếu cho cả nhóm ở mỗi mốc, không phải mỗi thành viên tự nộp. 25 điểm nộp là điểm chung của nhóm: mọi thành viên cùng được hoặc cùng mất.

⚠️ Cả 5 mốc phải nộp bằng cùng một mã học viên của đội trưởng. BTC ghép 5 phiếu của nhóm lại với nhau dựa trên mã học viên người nộp. Mốc này người A nộp, mốc kia người B nộp thì hệ thống hiểu là hai nhóm khác nhau, và nhóm mất điểm ở những mốc lệch.

Chọn đội trưởng là người chắc chắn có mặt và theo được cả năm mốc. Nếu bất khả kháng phải đổi người nộp, báo coach ngay trong buổi.

Link được công bố tại khai mạc, ghim trên Discord và đăng trên VLearn — hai nơi, cùng một bộ link.

Thể thức thi

• 2 ca × 2 phòng = 4 cuộc thi độc lập, chấm và trao giải riêng từng phòng; mỗi phòng một tổ giám khảo. Không thi liên phòng, liên khoá.
• E403 (~230 người): 6 cụm thi, mỗi nhóm 6 phút ở vòng cụm → 6 đội vào chung kết phòng → Top 3.
• E402 (~120 người): 5 cụm thi, mỗi nhóm 7 phút ở vòng cụm → 5 đội vào chung kết phòng → Top 2.
• Giám khảo có thể hỏi bất kỳ thành viên — ai cũng phải hiểu bài (vibe-coding rule).
• Số nhóm mỗi cụm là ước tính; thể lệ chi tiết vòng cụm và chung kết công bố lúc khai mạc.

Vòng cụm — game đầu tư

Mỗi đội có 100 điểm vốn, đội trưởng đại diện xem và đầu tư. Đội nhận nhiều vốn nhất cụm đi tiếp vào chung kết phòng.

Hai luật: không được đầu tư vào đội mình · tổng phải đúng 100, thừa hoặc thiếu là phiếu không được tính.

Chia cho mấy đội là tuỳ — dồn hết vào một đội cũng được. Mẹo: trong lúc xem thì ghi số dự định ra giấy nháp, xem xong cả cụm mới cân đối lại rồi điền form.

Chung kết phòng

Sau khi chốt danh sách, các đội có 10–15 phút chuẩn bị. Thứ tự trình bày quay ngẫu nhiên tại chỗ.

Mỗi đội 10 phút: 7 phút trình bày + 3 phút hỏi đáp.

Cả phòng bình chọn — mỗi người đánh giá từng đội một cách độc lập, không giới hạn số đội được bầu.

Giải thưởng

Giải theo phòng — mỗi lớp 5 đội, hai lớp 10 đội:

Điểm thưởng cộng vào bài lab ngày 5 và ngày 6, cho mỗi thành viên:

Mỗi phòng E403 có 7 đội được cộng điểm, E402 có 6 đội — không chỉ riêng đội vô địch.

Dòng cuối chỉ có một đội mỗi phòng: xét điểm đầu tư cao nhất trước, bằng nhau thì lấy đội nộp phiếu sớm hơn theo dấu thời gian của form.

Giải theo track — 4 giải, chấm chung cả hai lớp:

• Track A · VLearn Tutor và Track D · Học tập thích ứng & tương tác: 2 giải, do team VLearn chọn.
• Track C · Lesson Studio: 2 giải, do team Studio chọn.

Hai team chấm ngay tại buổi trình bày. Một đội có thể vừa vào Top phòng vừa nhận giải track. Phần thưởng cụ thể sẽ được công bố sau.

Mỗi mốc cần show gì và được xác minh thế nào: xem bảng trong 04-rubric.md.

Nộp bài

Tạo repo mới — không fork repo đề bài

Nhóm tạo một repo hoàn toàn mới và trống. Không fork, không clone repo này rồi push lên.

Lý do: fork mang theo cả thư mục data/, mà repo nộp bài bắt buộc phải công khai — nghĩa là dữ liệu thật của khoá học sẽ lên mạng. Vi phạm thẳng điều 2 và điều 3 của quy định bảo mật bên dưới.

Nhóm chỉ cần lấy đúng một file từ repo này: 03-ai-spec-template.md, copy vào repo mình và đặt tên spec.md. Mọi thứ còn lại là tài liệu đọc, mở tại đây là đủ.

Cách đặt tên repo

K4-<mã lớp>-<phòng>-<tên nhóm>

Ba phần đầu bắt buộc đúng. Phòng là phòng nhóm đang ngồi thi.

Tên nhóm ở cuối đặt gì cũng được — viết liền, không dấu, không khoảng trắng.

Repo phải để công khai. Thử mở bằng cửa sổ ẩn danh — mở được thì mới đúng. Để riêng tư là giám khảo không chấm được bài.

Cấu trúc repo

Spec chốt tại hạn chốt spec (xem Lịch); bản hoàn chỉnh trước CP6.

repo/
├── README.md          ← copy file này, điền bảng thành viên ở đầu
├── spec.md            ← AI Spec theo 03-ai-spec-template.md
├── demo-slides.pdf    ← slide 6 trang theo 02-guide.md §5.1
├── codebase/          ← prototype (ghi rõ phần nào mock)
├── eval/              ← golden set + bảng kết quả các lượt chạy
├── validation/        ← nhật ký cho người ngoài dùng thử (R6 — không làm thì trần điểm 92)
└── reflection/        ← mỗi người 1 file

README.md của nhóm

Copy nguyên file README này về repo của mình, rồi điền bảng thành viên ở đầu file. Không cần viết thêm gì khác.

Mã học viên phải đúng — đây là căn cứ đối chiếu điểm.

Chấm điểm

Tổng 100 điểm = 25 điểm nộp checkpoint + 67 điểm chấm bài nộp + 8 điểm R6 (cho người ngoài dùng thử). Chi tiết từng ý điểm: 04-rubric.md.

25 điểm nộp — mỗi checkpoint 5 điểm (CP1-CP5): nộp đúng hạn → 5 điểm · nộp muộn → 0 điểm cho mốc đó. Đội trưởng nộp thay cả nhóm — đây là điểm chung của nhóm, không phải điểm cá nhân.

67 điểm chấm + 8 điểm R6 — trên file trong repo, mỗi con điểm trỏ về một chỗ:

Ba khối nặng nhất — R1, R2, R4 — đều nằm trong spec.md. Viết spec tử tế là ăn 45 trên 67 điểm.

R6 · Cho người ngoài dùng thử — 8 điểm

Không làm thì trần điểm là 92. Vì 25 + 67 = 92, cộng R6 mới đủ 100.

Làm ở CP5, lưu trong thư mục validation/.

Người dùng chê cũng được tính đủ điểm. Mục đích là xem giải pháp có ăn thua không — ra kết quả nào cũng ghi nhận, miễn là bằng chứng thật. Phát hiện sản phẩm chưa ổn rồi sửa còn dễ ăn điểm hơn, vì có chỗ cụ thể để nói.

Hai ví dụ thật từ kỳ trước:

Nhóm MeaterBeat phát hiện học viên non-IT lúng túng không biết bấm nút nào, AI trả lời chậm — tức là giải pháp chưa ổn. Họ thêm tooltip hướng dẫn, thêm loading spinner, và giải trình phần độ trễ không sửa được vì phụ thuộc API. Đủ điểm.

Nhóm VLearn Recall phát hiện đúng như giả định: người ta nhớ chủ đề nhưng không nhớ nằm ở slide hay bài giảng — tức là giải pháp đi đúng hướng. Họ giữ nguyên thiết kế source-first và bổ sung thêm câu thử. Cũng đủ điểm.

Phải có đủ bốn thứ:

Cuối bảng viết 4 dòng: chủ đề lặp nhiều nhất · sẽ sửa gì trước demo · giữ nguyên gì và vì sao · gì để dành sau.

Quote thế nào mới ăn điểm:

Bên trái là lời khen xã giao. Bên phải là lời người dùng nói lúc đang cố làm việc — nhìn vào biết ngay họ vướng ở đâu.

Muốn có quote như vậy: giao task rồi ngồi im xem họ làm, đừng hỏi "sản phẩm này hay không".

Ba điều nên biết trước khi làm:

• Điểm dựa trên chuỗi quyết định và bằng chứng, không dựa trên mức độ hoành tráng của sản phẩm.
• Kết quả đo ghi nhận trung thực — kể cả khi không đạt mục tiêu nhóm tự đặt — vẫn được tính đủ điểm. Số liệu bị chỉnh sửa hoặc che giấu sẽ không được tính.
• Reflection cá nhân chấm riêng theo rubric của khoá. Điểm vòng demo, chấm chéo trong cụm và thưởng thêm (nếu có) theo thể lệ công bố lúc khai mạc.

Luật chung

1. Prototype có 3 mức Sketch / Mock / Working — mức nào cũng bắt buộc ≥1 lời gọi AI chạy thật. Đây là thứ phải thấy được trong video thao tác ở CP3.
2. Vibe-coding rule: dùng AI để build thoải mái, nhưng không giải thích được phần có tên mình thì phần đó 0 điểm (giám khảo hỏi bất kỳ thành viên khi thuyết trình).
3. Quality bar chốt tại hạn chốt spec (21:00 17/9, tại CP4) và giữ nguyên sau đó.
4. Chỉ dùng dữ liệu trong data/ hoặc dữ liệu giả tự sinh — không dùng dữ liệu thật của người thật. Không commit API key.
5. Tuân thủ quy định bảo mật dữ liệu bên dưới — đây là điều kiện để được cấp data.

Bảo mật dữ liệu được cung cấp

Dữ liệu trong data/ là dữ liệu thật của khoá học (đã ẩn danh), cấp riêng cho hackathon này. Khi nhận data, nhóm cam kết:

1. Chỉ dùng trong phạm vi hackathon — cho việc tìm bằng chứng, xây golden set và build prototype. Không dùng cho mục đích khác.
2. Không chia sẻ ra ngoài khoá học — không đăng lên mạng xã hội, không gửi cho người ngoài, không đưa vào bất kỳ dataset hay repo công khai nào.
3. Không commit data pack vào repo nộp bài — repo nhóm chỉ chứa trích dẫn ngắn để minh hoạ (vài dòng); golden set trích từ data ghi rõ mã đoạn/mã hội thoại thay vì dán nguyên văn dài.
4. Cẩn trọng khi đưa data vào công cụ ngoài — chỉ đưa phần tối thiểu cần cho việc đang làm; lưu ý API/công cụ free tier có thể dùng dữ liệu để huấn luyện (xem 02-guide.md §3.4).
5. Không cố suy ngược danh tính từ dữ liệu đã ẩn danh (S####, T#####, D####, [HV], [học viên]). Riêng discord-pack/: người trong đó là bạn cùng khoá — tuyệt đối không đoán/hỏi "tin này của ai"; trích dẫn tối đa 2 câu mỗi ví dụ (xem data/discord-pack/README.md).
6. Sau sự kiện, xoá các bản sao data pack khỏi máy cá nhân và các công cụ đã upload nếu ban tổ chức yêu cầu.

Vi phạm được xử lý theo quy định của khoá và có thể ảnh hưởng trực tiếp đến điểm của nhóm.