SDD-027 · Việc tắc và vòng review của người
Một phần của SDD-027.
15. Việc TẮC — dừng, ghi hồ sơ, chỉnh thuật toán, mở lại (SRC-636)
Chỉ đạo chủ dự án 2026-08-28: "có một số chỗ tạo nội dung, nhưng tạo đi tạo lại vẫn không ổn, thì cần tạm dừng, báo cáo vào đâu đó, để sau đó chỉnh lại thuật toán và logic, chứ không được phép tạo đi tạo lại quá nhiều lần".
Trần số lần thử (§13 chốt 4) mới chỉ biết nói không. Nó không nói vì sao tắc, không giao việc cho ai, và không có đường mở lại — nên một bài chạm trần là tắc vĩnh viễn trong im lặng. Bảng content_blocked_targets (migration 0167) biến "bị chặn" thành một việc có hồ sơ:
chạm trần 3 lượt
└─ chẩn đoán: gom chỗ chưa đạt LẶP LẠI qua mọi trial của mọi lượt
└─ ghi sổ việc tắc (status=open) + chặn mọi lượt mới cho bài đó
└─ người đọc sổ trên Coral, chỉnh prompt / rubric / đầu vào
└─ mở lại KÈM ghi chú đã chỉnh gì (status=released, released_at)
└─ số lần thử đếm LẠI TỪ released_atChẩn đoán là cột đáng giá nhất. Chuỗi problem được chuẩn hoá (thay mọi con số bằng N) trước khi đếm, nên "khai 4 hiểu lầm nhưng chỉ có 1 mcq" và "khai 5 hiểu lầm nhưng chỉ có 1 mcq" được gom là cùng một bệnh; không chuẩn hoá thì mỗi lượt ra một chuỗi khác và không gì "lặp lại" cả. Ba lượt cùng trượt một tiêu chí không phải chuyện xui — đó là bằng chứng lỗi hệ thống ở prompt, rubric hoặc đầu vào, và lượt thứ tư chỉ tốn tiền để nghe lại đúng câu ấy.
Mở lại bắt buộc kèm ghi chú đã chỉnh gì (≥10 ký tự, ghi vào resolution_note + audit log). Mở mà không đổi gì thì lượt sau tắc y hệt, và sổ này thành một nút "thử lại" trá hình. Trạng thái thứ ba wont_fix cho ca cố ý bỏ qua — vẫn phải ghi lý do.
16. Vòng review của người → nâng prompt/engine → sinh lại (SRC-637)
Chỉ đạo chủ dự án 2026-08-28: "cần có chỗ để con người (là tôi) vào review các prompt để tạo content và review chính các content nữa. Rồi sau đó, hệ thống sẽ rà soát lại các comment của tôi, để dùng các comment và feedback đó, để nâng cấp các prompt và engine, rồi sau đó tạo lại các content không ổn".
Đây là vòng thứ ba của hệ, và là vòng duy nhất có người trong đó:
| Vòng | Ai chấm | Chấm cái gì | Kết quả |
|---|---|---|---|
| 1 · rubric máy (§4) | máy | một bản thảo | điểm + danh sách chỗ chưa đạt |
| 2 · sổ việc tắc (§15) | máy | nhiều lượt của cùng một bài | chẩn đoán bệnh lặp lại |
| 3 · review của người | chủ dự án | prompt và content | feedback → nâng prompt/engine → sinh lại |
Hai thứ được review, hai thang khác nhau:
- Prompt (
lessonSpec.ts: system prompt, WRITING_RULES, khuôn JSON;parts.ts: prompt vá). Review ở đây trả lời "cái máy đang được dặn gì, và dặn thế đã đúng chưa". Mỗi comment gắn vào mộtprompt_versioncụ thể — comment về một prompt đã đổi thì không còn nghĩa gì. - Content (một bản thảo trong R2, hoặc bài đang sống trong
curriculum_*). Comment gắn vào đúng một phần (story · misconceptions · checks…) chứ không phải cả bài, vì đó cũng chính là đơn vị mà lượt vá có thể sửa (§11) — comment "bài này nhạt" không chuyển thành việc được, còn "câu chuyện không có ai bị vướng gì" thì chuyển thẳng thành một lượt vástorykèm lý do.
Đường đi của một comment:
người review (Coral) ─ comment + mức: khen / sửa được / phải làm lại
└─ content_feedback (scope: prompt | content, gắn part + prompt_version + rubric_version)
├─ đường NGẮN: comment về một phần cụ thể → nút "vá phần này" mang chính comment
│ làm `reasons` của lượt vá (§11). Sửa được ngay, không đợi ai.
└─ đường DÀI: gom nhiều comment → đề xuất sửa prompt/rubric
└─ máy đọc feedback đang mở + thống kê tiêu chí hay trượt → SOẠN ĐỀ XUẤT
└─ người duyệt đề xuất → sửa prompt, TĂNG PROMPT_VERSION
└─ những bài mang version cũ + có feedback "phải làm lại" vào hàng chờMáy đề xuất, người quyết. Cùng luật §1: không có đường nào để feedback tự sửa prompt. Prompt là thứ quyết định mọi nội dung sinh sau đó, nên một comment hiểu sai ý mà tự động vào prompt sẽ làm hỏng hàng loạt bài — đắt hơn nhiều so với việc người đọc một đề xuất.
Vì sao phải gắn version vào từng comment: feedback nói "câu chuyện toàn cảnh trường học, chán" chỉ đúng với prompt đã sinh ra nó. Sau khi prompt v3 thêm luật "đổi bối cảnh giữa các bài", chính comment ấy trở thành bằng chứng đã sửa xong, không phải việc còn tồn. Không gắn version thì sổ feedback chỉ dài ra mà không bao giờ đóng được dòng nào.
Sinh lại cái gì: chỉ những bài (a) có feedback mức phải làm lại còn mở, hoặc (b) sinh bằng prompt_version cũ hơn version hiện hành và từng bị chê. Không sinh lại toàn bộ kho mỗi lần đổi prompt — đó đúng là kiểu "chạy loạn tốn tiền" mà §13 dựng ra để chặn.