Hướng dẫn Thiết kế Hệ thống EdTech cho AI Agent

Tài liệu này đóng vai trò là System Prompt / Guideline thiết kế kiến trúc dành cho các AI Agent khi tham gia phát triển hệ thống EdTech (đặc biệt là đi lên từ hệ thống Synvia). Mọi quyết định thiết kế Entity, Domain, và Flow phải đối chiếu với tài liệu này.

---

1. Triết lý Thiết kế Cốt lõi (Core Philosophy)

Dựa trên cuốn sách "Công nghệ Giáo dục — Cái Đúng, Cái Sai, và Cái Cần Làm", hệ thống EdTech phải tuân thủ 3 triết lý thiết kế tối cao:

1. Sư phạm trước, Công nghệ sau (Pedagogy-First): Không áp dụng công nghệ chỉ vì "có thể làm được". Mọi module AI phải giải quyết một lỗ hổng cụ thể (Knowledge, Skills, Motivation, Environment). 2. Thiết kế cho Nỗ lực (Desirable Difficulties): Không tối ưu hóa hệ thống để học sinh đạt được đáp án một cách "trơn tru" (Frictionless). Hệ thống TỐT là hệ thống tạo ra sự "khó khăn có chủ đích" để buộc não bộ phải tư duy (Generation, Retrieval). 3. AI tăng cường (Augmented Intelligence): AI không thay thế Giáo viên. AI làm phần thô (scalability, metrics, data), Giáo viên làm phần tinh (mentoring, empathy, hidden curriculum). Thiết kế phải giữ Teacher-in-the-loop hoặc Teacher-on-the-loop.

---

2. Thiết kế Kiến trúc Domains (System Domains)

Hệ thống EdTech (Synvia) được chia thành 4 Domains cốt lõi. Bất kỳ tính năng mới nào cũng phải thuộc về một trong các domain này:

Domain 1: Core_LMS_Domain (Quản lý và Nền tảng)

  • Chức năng: Quản lý Người dùng (HS, GV, Phụ huynh), Lớp học, Khóa học, Bài tập cơ bản.
  • Quy tắc Thiết kế:
  • Data Minimization (Chương 12): Entity User chỉ lưu những dữ liệu thực sự cần thiết cho việc học. Không thu thập các dữ liệu thừa.
  • Privacy by Design: Mặc định các thông tin cá nhân và lịch sử học tập chỉ chia sẻ giữa HS và GV trực tiếp. Cấm chia sẻ cho bên thứ ba hoặc public mà không có consent.
  • Equity (Công bằng): Các API thuộc domain này phải được thiết kế tối ưu dung lượng (Low-bandwidth) để HS ở môi trường mạng yếu vẫn truy cập được.

Domain 2: Assessment_Domain (Khảo thí & Đánh giá)

  • Chức năng: Giao bài, Thu bài, Chấm điểm, Đo lường sự tiến bộ.
  • Quy tắc Thiết kế:
  • Đo lường Transfer, không đo Engagement (Chương 8, 9, 17): Các schema trong Database không chỉ tập trung lưu time_spent hay clicks. Cần thiết kế schema để theo dõi Retention (độ nhớ sau X ngày) và Transfer (khả năng làm dạng bài tương tự nhưng ngữ cảnh khác).
  • Mastery Learning (Chương 4, 9): Hệ thống bài tập không phải dạng pass/fail 1 lần. Thiết kế database theo dạng Submission Attempts vô hạn cho đến khi đạt ngưỡng Mastery.
  • Stealth Assessment: Thiết kế các bài kiểm tra được nhúng ngầm vào quá trình học thay vì các bài thi lớn gây áp lực.

Domain 3: Tutoring_Domain (AI Gia sư & Scaffolding)

  • Chức năng: AI hỗ trợ học sinh khi làm bài, AI phân tích bài tập của học sinh.
  • Quy tắc Thiết kế:
  • Socratic Scaffolding (Chương 5, 10): Hệ thống không được có luồng (flow) Học sinh hỏi -> AI đưa đáp án. Flow chuẩn phải là Học sinh hỏi -> AI đưa Hint/Hỏi ngược -> Học sinh suy nghĩ -> AI xác nhận.
  • Glass Box AI (Chương 12): Mọi Model AI quyết định (vd: AI chấm điểm essay) phải lưu lại một trường ai_reasoning trong Database. Giáo viên có quyền xem và ghi đè (human_override) quyết định này.
  • Spaced Repetition (Chương 9): Tích hợp thuật toán lặp lại giãn cách (như FSRS). Domain này cần có tính năng lên lịch ôn tập cho học sinh dựa trên lịch sử quên.

Domain 4: Analytics_Domain (Phân tích & Metacognition)

  • Chức năng: Báo cáo, Dashboard cho Giáo viên, Học sinh, và Phụ huynh.
  • Quy tắc Thiết kế:
  • SRL Dashboard (Self-Regulated Learning) (Chương 10): Dashboard không chỉ hiển thị điểm. Phải hiển thị Calibration Error (Khoảng cách giữa độ tự tin của HS và kết quả thực tế).
  • No Surveillance (Chương 12): Không phát triển các tính năng phân tích cảm xúc (Emotion recognition) qua camera hoặc tracking keystroke quá đà để tránh hiệu ứng răn đe (Chilling effect). Cấm đưa các cảnh báo ảo (at-risk) mà không có lý giải cho Giáo viên.

---

3. Workflow để mở rộng tính năng mới

Khi AI Agent nhận một task thêm tính năng X vào hệ thống, hãy chạy qua checklist sau:

1. Xác định Gap (Chương 15): Tính năng X giải quyết Knowledge, Skills, Motivation hay Environment? Nếu là Motivation/Environment do yếu tố con người, cảnh báo người dùng. 2. Kiểm tra Desirable Difficulty: Tính năng X có làm mọi thứ "quá dễ" cho học sinh đến mức họ lười suy nghĩ không? Nếu có, thiết kế lại flow để thêm "Productive Friction". 3. Phân loại Stakeholder: Tính năng này phục vụ ai? (Tutor / Tool / Tutee). Đảm bảo Giáo viên luôn giữ quyền kiểm soát (Teacher-in-the-loop). 4. Data Audit: Tính năng X lưu những trường dữ liệu nào mới? Các trường này có thực sự cần thiết không? Có vi phạm quyền riêng tư không? 5. Chọn Tech Stack (UI): Dùng UI/UX tinh gọn, áp dụng Coherence Principle (Bỏ hình ảnh, âm thanh, gamification không phục vụ trực tiếp cho việc học). Dùng HTMX để render tối giản.