Xin chào tất cả mọi người! Chào mừng các bạn đến với chương trình đào tạo AIDF-NEXA Day 1. Hôm nay chúng ta sẽ cùng nhau tìm hiểu về NEXA Framework — một phương pháp phát triển phần mềm hỗ trợ bởi AI mà Fabbi đã xây dựng. Chúng ta sẽ đi từ lý thuyết cơ bản đến thực hành thực tế, cài đặt công cụ và khám phá dự án mẫu. Mục tiêu cuối ngày hôm nay: các bạn hiểu NEXA là gì, biết 5 giai đoạn phát triển, và tự chạy được Claude Code trong dự án. Hãy bắt đầu nào!

Đây là lịch trình cho buổi học hôm nay. Chúng ta có 2 giờ tổng cộng, chia làm 2 phần rõ ràng. Phần 1 từ 10 giờ đến 11 giờ là lý thuyết — chúng ta sẽ tìm hiểu NEXA là gì, 5 giai đoạn phát triển, và khái niệm SoT. Phần 2 từ 11 giờ 5 đến 12 giờ là thực hành — cài đặt Claude Code, clone dự án, và tự khám phá. Giữa 2 phần có 5 phút nghỉ giải lao. Nếu có câu hỏi trong quá trình học, cứ giơ tay — chúng ta sẽ giải đáp ngay hoặc để cuối buổi.

Bắt đầu Phần 1 — phần lý thuyết. Trong 1 giờ này, các bạn sẽ nắm được nền tảng tư duy của NEXA Framework. Đừng lo lắng nếu chưa hiểu hết ngay — chúng ta sẽ có bài tập thực hành để củng cố sau.

Trước khi bắt đầu, hãy để mọi người tự giới thiệu bản thân trong khoảng 1 phút mỗi người. Xin hãy chia sẻ: tên của bạn, bạn đang làm việc ở đâu, vai trò của bạn trong dự án, và kinh nghiệm với AI của bạn đến đâu. Điều này giúp tôi điều chỉnh nội dung phù hợp với trình độ của cả nhóm. Tôi sẽ bắt đầu trước: tôi là Lượng, trainer từ Fabbi, đã làm việc với Claude và AI-assisted development trong hơn 1 năm. Bây giờ mời bạn số 1 — Ishikawa-san.

Trước khi nói về NEXA, hãy nhìn toàn cảnh thị trường AI cho phát triển phần mềm. Hình bên phải cho thấy 4 nhóm chính: 1) AI Models (LLM) — GPT, Claude, Gemini, DeepSeek... đây là BỘ NÃO, nguồn kiến thức. Tất cả các tool khác đều phụ thuộc vào nhóm này. Không có LLM thì không có gì cả. 2) AI Assistants — ChatGPT, Perplexity, Google AI... là giao diện chat trực tiếp trên browser. Đơn giản nhất, ai cũng dùng được. Chỉ cần mở web và gõ câu hỏi. 3) AI Coding Tools — GitHub Copilot, Cursor, Windsurf, Cline, Antigravity... là WRAPPER — công cụ bọc LLM vào IDE. Tool khác nhau nhưng bộ não bên trong vẫn là cùng một LLM. Ví dụ: Cursor bên trong cũng gọi Claude hoặc GPT. 4) AI Development Frameworks — LangChain, CrewAI, AutoGen, và NEXA thuộc nhóm này. Khác biệt quan trọng nhất: không chỉ kết nối LLM vào IDE mà còn ÁP DỤNG QUY TẮC dự án và KIỂM TRA chất lượng output. Điểm mấu chốt: tool thay đổi liên tục — hôm nay Cursor, mai Windsurf — nhưng FRAMEWORK (cách tổ chức và kiểm soát AI) mới là giá trị lâu dài. Đó là lý do chúng ta học NEXA.

NEXA viết tắt từ Next-generation EXecution AI — đọc là "ネクサ" (Nekusa). Điều quan trọng nhất cần nhớ: NEXA KHÔNG PHẢI là một AI model như GPT hay Claude. NEXA cũng KHÔNG PHẢI là plugin IDE như Copilot hay Cursor. Nó là một FRAMEWORK — một hệ thống quy tắc và quy trình. Các bạn đã dùng ChatGPT rồi đúng không? Khi bạn hỏi ChatGPT "tạo API cho màn hình login" — nó tạo được, nhưng tạo theo kiểu GENERIC. Nó không biết dự án bạn dùng database gì, template format Nhật Bản như thế nào, hay quy chuẩn riêng của công ty. Hãy tưởng tượng ChatGPT như một thầy giáo rất giỏi — biết mọi thứ trên thế giới. Nhưng thầy giáo đó chưa bao giờ đến công ty bạn, chưa bao giờ đọc tài liệu dự án, chưa bao giờ biết template riêng của Fabbi. NEXA giải quyết vấn đề này. NEXA là cơ chế đưa cho "thầy giáo" đó toàn bộ bản thiết kế dự án (BD/DD), template chuẩn, và quy tắc chất lượng — TRƯỚC KHI thầy bắt đầu làm. Rồi sau khi thầy làm xong, NEXA kiểm tra lại output xem có đúng bản thiết kế không. Đó là toàn bộ ý tưởng. Đơn giản vậy thôi.

Điểm quan trọng cần phân biệt: LLM (GPT, Claude...) là BỘ NÃO — nó có kiến thức từ toàn bộ internet. Còn Copilot, Cursor, Antigravity... là CÔNG CỤ — chúng chỉ là wrapper kết nối bộ não đó vào IDE của bạn. Vì vậy với nghiệp vụ phổ thông — CRUD, authentication, REST API — LLM làm rất tốt vì kiến thức đã có sẵn từ training data. NHƯNG khi gặp nghiệp vụ đặc thù — format SI Nhật Bản, template riêng công ty, business logic khách hàng — thì LLM bắt đầu "bịa" (hallucination) vì không có kiến thức về dự án cụ thể. Context window cũng có giới hạn nên AI không nhớ hết spec. NEXA khác: bắt buộc AI theo thiết kế của DỰ ÁN (BD/DD), và nghiệm thu output bằng chính thiết kế đó qua Quality Gate.

Trước khi đi vào chi tiết, hãy nhìn bức tranh tổng thể trước — kiến trúc NEXA cực kỳ đơn giản. Hãy nhớ duy nhất một điều: NEXA nằm GIỮA bạn và AI. Khi bạn dùng AI trực tiếp — ví dụ mở ChatGPT rồi gõ "tạo BD cho màn hình login" — bạn tự viết prompt, output mỗi lần mỗi khác, không ai review. Khi bạn dùng NEXA — bạn cũng gõ câu đó, nhưng NEXA sẽ biến câu đó thành prompt chuẩn, thêm context dự án, thêm template tiếng Nhật, rồi mới gửi cho AI. Kết quả: output đúng format, nhất quán, và được auto-review. Thực tế dự án MSR-002: review time giảm 60%, DD accuracy 86%, UT completeness 96.9% — đây là con số thực từ dự án thật. Hãy nghĩ NEXA như "phiên dịch viên" giữa bạn và AI — nó biết dự án của bạn, biết chuẩn Nhật Bản, và biết cách kiểm tra chất lượng.

Trước khi xem NEXA cụ thể, hãy so sánh 3 cách dùng AI mà các bạn có thể đã biết. Cách 1 — ChatGPT trực tiếp: bạn mở browser, gõ câu hỏi. AI trả lời chung chung, không biết dự án của bạn, không biết format Nhật Bản. Prompt chỉ đi qua 2 tầng: bạn → AI. Cách 2 — Vibecoding với Cursor hoặc Claude-Code: AI biết thêm code hiện tại trong project. Code output tốt hơn, nhưng vẫn không tạo tài liệu, không theo template công ty. Prompt đi qua 3 tầng. Cách 3 — NEXA: cùng câu hỏi đó, nhưng prompt đi qua 5 tầng. NEXA thêm template chuẩn, rules chất lượng, pattern library, rồi auto-review kết quả. Output ra cả tài liệu, code, và test cases. Điểm mấu chốt: cùng 1 câu hỏi, nhưng đi qua càng nhiều tầng thì chất lượng càng cao. NEXA thêm 2 tầng quan trọng mà Cursor/Claude-Code không có.

Hãy nhìn kỹ hơn prompt đi qua đâu ở mỗi cấp độ. Level 1 — ChatGPT: prompt đi thẳng từ bạn đến AI, không có gì ở giữa. AI nhận được câu hỏi thô, trả lời chung chung. Level 2 — Vibecoding: IDE như Cursor hoặc Claude-Code tự động đọc code trong project rồi gửi kèm prompt cho AI. AI hiểu code hơn, nên output code tốt hơn. Nhưng nó chỉ biết CODE — không biết template tài liệu, không biết chuẩn Nhật Bản. Level 3 — NEXA: thêm 2 tầng quan trọng. Tầng Meta-Layer chứa templates, rules, engines, patterns — biến prompt thô thành prompt chuẩn. Tầng Auto-Review kiểm tra output trước khi trả cho bạn. Kết quả: cùng 1 câu hỏi "tạo API cho login", NEXA trả ra cả tài liệu BD/DD, code đúng pattern, test cases, và tất cả đã qua review. Đó là sức mạnh của 5 tầng so với 2-3 tầng. Lưu ý: đây là 5 tầng xử lý PROMPT, khác với 6 tầng kiến trúc hệ thống ở Phụ lục E.

⚠️ Trainer: slide này dùng inline HTML — cần flag --html khi build (đã set trong build.sh). Bây giờ nhìn kỹ hơn vào bên trong NEXA — có 3 trụ cột chính. Trụ 1 là PHƯƠNG PHÁP — bao gồm templates chuẩn, quy trình V-Model của Nhật, và quy tắc SoT mà chúng ta vừa học. Đây là "luật chơi" để tài liệu luôn đồng nhất. Trụ 2 là CÔNG CỤ — các engine tự động hóa như auto-review tài liệu, tự tạo test case, tự sinh tài liệu. Thay vì bạn review bằng tay 2 ngày, engine làm trong 2 giờ. Trụ 3 là THÔNG MINH — hệ thống commands, skills, và agents. Ví dụ khi bạn gõ "/dd:generate", NEXA biết phải làm gì, gọi AI đúng cách, và kiểm tra kết quả. 3 trụ này kết hợp lại tạo nên giá trị cốt lõi của Fabbi — đây là thứ mà Copilot hay Cursor KHÔNG có. Hôm nay chỉ cần nhớ bức tranh tổng thể — từ Day 2 trở đi chúng ta sẽ đi sâu vào từng trụ cột.

Đây là 5 giai đoạn phát triển CƠ BẢN trong quy trình NEXA. Mỗi phần mềm đều phải đi qua 5 bước này, từ trái sang phải. RD — Định nghĩa yêu cầu: Xác định hệ thống cần làm gì. Không có NEXA thì mọi người tự tổng hợp yêu cầu bằng tay, dễ thiếu sót. Với NEXA, AI trích xuất yêu cầu từ tài liệu đầu vào và xuất ra file YAML có cấu trúc — không bỏ sót. BD — Thiết kế cơ bản: Thiết kế giao diện và API ở mức tổng quan. Không có NEXA thì mỗi người viết tài liệu một kiểu, format khác nhau, không ai review được. Với NEXA, template thống nhất, AI sinh bản nháp, con người chỉ cần review và chỉnh sửa. DD — Thiết kế chi tiết: Đi sâu vào từng màn hình, từng API. Không có NEXA thì hay copy-paste từ BD rồi sửa, dẫn đến mất đồng bộ. Với NEXA, DD được tự động triển khai từ BD và AI kiểm tra tính nhất quán giữa các tài liệu. CODE — Triển khai: React cho frontend, Spring Boot cho backend. Không có NEXA thì AI sinh code rồi developer phải review từng dòng. Với NEXA, code được sinh ra THEO DD, tự động kiểm tra có khớp với thiết kế hay không. TEST — Ở đây là Unit Test, không phải Integration Test hay System Test. Không có NEXA thì tester phải viết test cases bằng tay. Với NEXA, test cases được tự động sinh từ DD — đảm bảo test đúng cái đã thiết kế. Nhìn cột "Without NEXA" và "With NEXA" — sự khác biệt là RÕ RÀNG. NEXA không thay thế con người, mà giúp mỗi bước NHANH hơn, CHÍNH XÁC hơn, và NHẤT QUÁN hơn.

Tại sao NEXA cần Quality Gate? Không phải vì lý thuyết quản lý dự án — mà vì một vấn đề CỤ THỂ. Hãy xem ví dụ: BD viết sai tên màn hình — ví dụ ghi "経費一覧" thay vì "経費精算一覧". Không có NEXA thì sao? DD copy tên sai đó sang. Code implement theo tên sai. Đến lúc test mới phát hiện — phải sửa lại từ DD trở đi. Chi phí ban đầu chỉ 1 đơn vị nếu phát hiện ở BD, nhưng lúc này đã thành 100 đơn vị trở lên. Với NEXA Quality Gate — mọi thứ khác hẳn: Từ RD sang BD: AI tự kiểm tra "BD đã cover hết yêu cầu từ RD chưa?" — không cần chờ ai review. Từ BD sang DD: NEXA kiểm tra SoT link — BD và DD có nhất quán không? Tên API, tên màn hình, kiểu dữ liệu có khớp không? Từ DD sang CODE: NEXA đo tỷ lệ code tuân thủ DD — không phải "cảm giác" mà là CON SỐ cụ thể. Từ CODE sang TEST: Test cases được sinh TỰ ĐỘNG từ DD — đảm bảo test đúng cái đã thiết kế, không thiếu, không thừa. Điểm mấu chốt: QG của NEXA KHÁC code review thông thường. Code review dựa vào mắt người — phụ thuộc kinh nghiệm, tâm trạng, thời gian. NEXA QG dựa vào SoT — kiểm tra theo QUY TẮC, tự động, nhất quán, không bỏ sót.

Vậy Quality Gate trong NEXA hoạt động như thế nào? Nhìn vào sơ đồ: giữa mỗi giai đoạn có một cổng kiểm soát — QG. Từ RD sang BD — Quality Gate kiểm tra xem BD đã cover hết yêu cầu từ RD chưa, SoT có đúng không. Từ BD sang DD — kiểm tra tính nhất quán API, mapping giữa màn hình và API có khớp không. Từ DD sang CODE — kiểm tra code có tuân thủ DD specification không, kiểu dữ liệu có khớp không. Từ CODE sang TEST — kiểm tra test coverage và tiêu chuẩn chất lượng. NEXA tự động hóa các kiểm tra này bằng agents chuyên dụng — docs-manager kiểm tra tài liệu, code-reviewer kiểm tra thiết kế, coder và tester kiểm tra code. Đây chính là hiện thực hóa nguyên tắc "Design by Contract" — thi công theo bản vẽ, nghiệm thu theo bản vẽ. Không có bản vẽ thì không nghiệm thu được.

SoT — Source of Truth — là khái niệm quan trọng nhất trong NEXA. Các bạn cần phân biệt rõ: SoT KHÁC với Output. Output là thứ AI hoặc con người tạo ra — nó có thể chưa đúng, chưa final, chưa được duyệt. SoT là thứ ĐÃ ĐƯỢC XÁC NHẬN, là "sự thật" chính thức duy nhất. Có một hệ phân cấp quan trọng: đứng đầu là 00_Input — đây là SoT của cả dự án, chứa thông tin trực tiếp từ khách hàng. Thông tin từ Client là truth cao nhất, không ai được phép "sáng tạo" khác đi. Tiếp đến, mỗi giai đoạn phát triển đều có SoT riêng nằm trong thư mục 90_Input. Khi 90_Input và 91_Output mâu thuẫn nhau — 90_Input luôn thắng. Có 4 quy tắc vàng: chỉ 1 bản chính thức, luôn dùng version mới nhất, copy chứ không link, và tuyệt đối không sửa file trong 90_Input. ⚠️ Anti-pattern thường gặp: BD đã update v3 nhưng 90_Input vẫn là v1 → DD sinh ra từ SoT cũ → mismatch. Đây là lỗi nguy hiểm nhất vì khó phát hiện — mọi thứ "trông có vẻ đúng" nhưng thực tế đã sai từ gốc.

Hình bên phải là cấu trúc thư mục thực tế của dự án MSR-002 — đây không phải lý thuyết mà là dự án các bạn sẽ thực hành. Điều 1 — Thư mục theo giai đoạn: Mỗi giai đoạn phát triển có thư mục riêng, đánh số từ 00 đến 18. 00_DocumentMap là GPS — bản đồ toàn bộ dự án. 00_Input là SoT gốc — thông tin từ Client, hợp đồng, yêu cầu ban đầu. Từ 01 đến 05 tương ứng với 5 giai đoạn RD, BD, DD, CODE, TEST mà ta vừa học. Các thư mục 06 trở đi là System Test, Deployment, Release, v.v. — quy trình đầy đủ của một dự án thực tế. Điều 2 — Cấu trúc 3 lớp: Bên trong MỖI giai đoạn đều có 3 thư mục con: 90_Input chứa SoT — tài liệu đã được xác nhận chính thức, đây là đầu vào chính thức. 91_Output chứa kết quả AI sinh ra — LƯU Ý: chưa phải SoT, cần review trước khi dùng. 92_Analysis chứa kết quả đánh giá và review. Điều 3 — AI Rule File: Mỗi coding agent đều có file cấu hình ở root dự án — CLAUDE.md (Claude Code), .cursorrules (Cursor), .windsurfrules (Windsurf), .github/copilot-instructions.md (Copilot). Khái niệm giống nhau: AI đọc file này ĐẦU TIÊN khi mở dự án để hiểu quy tắc code, scope, convention. Trong dự án này ta dùng CLAUDE.md vì sử dụng Claude Code. Nhìn ảnh bên phải — các bạn sẽ thấy thêm các thư mục như 15_品質管理, 16_構成管理, 17_変更管理 — đây là quản lý chất lượng, cấu hình, và thay đổi. NEXA không chỉ quản lý code mà quản lý TOÀN BỘ vòng đời dự án.

Được rồi, trước khi nghỉ giải lao, hãy kiểm tra nhanh xem chúng ta đã nắm được lý thuyết chưa. Câu 1: SoT nằm ở thư mục nào trong cấu trúc 3 lớp? — Đáp án là 90_Input, không phải 91_Output hay 92_Analysis. Câu 2: Đây là câu hỏi tình huống — khi BD mới được duyệt, bạn phải đồng bộ SoT trước rồi mới tạo lại DD. Không bao giờ sửa DD trực tiếp vì vi phạm SoT rule 4. Câu 3: Khi 91_Output và 90_Input khác nhau — 90_Input luôn đúng vì đó là SoT đã xác nhận. 91_Output chỉ là kết quả sinh ra, chưa chắc đã đúng. Nếu cả 3 câu đều đúng — tuyệt vời, các bạn đã sẵn sàng cho phần thực hành! Bây giờ nghỉ 5 phút.

Chào mừng trở lại sau giải lao! Bây giờ chúng ta chuyển sang phần thú vị hơn — thực hành. Trong 55 phút tới, các bạn sẽ tự tay cài đặt Claude Code, đăng nhập, clone dự án và khám phá cấu trúc thực tế. Hãy mở máy tính lên và chuẩn bị terminal — chúng ta làm từng bước một, không ai bị bỏ lại phía sau.

Claude Code là công cụ CLI — tức là bạn dùng nó trực tiếp trong terminal, không phải plugin trong VS Code. Đây là cách tiếp cận khác so với GitHub Copilot — Claude Code hiểu ngữ cảnh toàn bộ dự án, không chỉ file đang mở. Mỗi bạn sẽ nhận được một tài khoản từ Fabbi qua email — hãy kiểm tra hộp thư của bạn ngay bây giờ. Lưu ý quan trọng: không được dùng tài khoản Claude cá nhân của bạn cho việc này — dùng tài khoản Fabbi cấp để đảm bảo license đúng. Nếu chưa nhận được email, hãy báo tôi ngay để xử lý trước khi tiếp tục.

Bước đầu tiên là kiểm tra xem máy tính của bạn đã có đủ các công cụ cần thiết chưa. Hãy mở terminal lên và chạy từng lệnh một — tôi sẽ chờ mọi người làm xong. Chúng ta cần: Git 2.x trở lên, Node.js 20 trở lên, npm 10 trở lên, VS Code bất kỳ version nào, và Claude Code CLI. Nếu bạn thấy số version hợp lệ — tốt, tiếp tục. Nếu thấy lỗi "command not found" — hãy giơ tay để tôi hỗ trợ cài đặt. Đừng bỏ qua bước này vì nếu thiếu công cụ, các bước sau sẽ không chạy được.

Bây giờ chúng ta cài đặt Claude Code CLI bằng npm — lệnh chỉ có một dòng rất đơn giản. Chạy lệnh và chờ khoảng 30 giây đến 1 phút tùy tốc độ mạng. Sau đó chạy `claude --version` để xác nhận. Nếu gặp lỗi "Permission denied" — thêm `sudo` vào trước lệnh, đây là vấn đề quyền hạn trên macOS/Linux. Nếu sau khi cài xong mà gõ `claude` thấy "command not found" — đừng lo, chỉ cần đóng terminal và mở lại là được. Tôi sẽ đi vòng quanh kiểm tra cho từng người — ai xong trước thì đợi các bạn khác nhé.

Sau khi cài xong, gõ `claude` để khởi động và thực hiện đăng nhập. Khi được hỏi phương thức đăng nhập, chọn "Log in with email" và nhập thông tin từ email Fabbi gửi cho bạn. Để kiểm tra đã đăng nhập thành công, gõ câu hỏi bất kỳ bằng tiếng Anh như "hello, who are you?" — nếu Claude trả lời thì thành công rồi! Lưu ý: email và password phân biệt chữ hoa chữ thường — copy paste từ email thay vì gõ tay nếu có thể. Nếu đang dùng VPN, hãy tắt đi vì đôi khi VPN gây lỗi kết nối. Sau khi test xong, gõ `/exit` để thoát.

Bây giờ chúng ta clone dự án mẫu nexa-sample-1 về máy. Đây là dự án thực hành mà chúng ta sẽ làm việc trong suốt khóa đào tạo. Nếu có kết nối internet tốt, dùng git clone từ GitHub. Nếu mạng chậm hoặc không có, tôi có bản copy trên USB — hãy lấy từ đó. Sau khi clone xong, mở VS Code bằng lệnh `code .` trong thư mục dự án. Kiểm tra thành công bằng cách xem có đủ các thư mục 00 đến 05 và file CLAUDE.md không. Nếu thấy đủ các thư mục này — chúc mừng, bạn đã sẵn sàng cho bước tiếp theo!

Đây là bước thú vị nhất — chạy Claude Code ngay trong dự án thực tế và xem nó hiểu dự án như thế nào. Khi bạn chạy `claude` trong thư mục dự án, Claude sẽ tự động đọc file CLAUDE.md và hiểu ngữ cảnh dự án. Thử hỏi Claude bằng tiếng Nhật hoặc tiếng Việt đều được — "mô tả tổng quan về dự án này" và xem Claude trả lời gì. Sau đó thử tìm kiếm tài liệu — yêu cầu Claude tìm BD của màn hình login và xem nó định hướng trong cấu trúc thư mục như thế nào. Đây chính là sức mạnh của NEXA: AI hiểu cả dự án, không chỉ một file — và nó tuân theo luật chơi trong CLAUDE.md.

Bây giờ là 10 phút tự khám phá — mỗi người tự tìm câu trả lời cho 6 câu hỏi này. Bạn có thể dùng VS Code để duyệt thư mục thủ công, hoặc hỏi Claude trực tiếp — cả hai cách đều hợp lệ. Thực ra, cách tốt nhất là thử cả hai: dùng VS Code để hiểu cấu trúc trực quan, rồi hỏi Claude để xem AI trả lời như thế nào. Câu 6 là bắt buộc phải hỏi Claude — đây là bài tập quan trọng nhất vì nó xây dựng thói quen "hỏi Claude trước khi tìm thủ công". So sánh câu trả lời của Claude với kết quả bạn tìm bằng VS Code — nếu khác nhau, tại sao? Sau 10 phút, chúng ta sẽ cùng nhau đối chiếu câu trả lời — ai tìm ra nhanh nhất thì chia sẻ cách làm của mình nhé. Bắt đầu!

Chúc mừng các bạn đã hoàn thành Day 1! Hãy cùng nhìn lại những gì chúng ta đã làm được hôm nay. Từ lý thuyết: chúng ta hiểu NEXA không chỉ là tool viết code nhanh, mà là platform thực thi toàn bộ quy trình với 5 giai đoạn và khái niệm SoT. Từ thực hành: các bạn đã tự cài đặt Claude Code, đăng nhập, clone dự án và chạy Claude ngay trong ngữ cảnh thực tế. Đây là nền tảng quan trọng — mọi thứ ở Day 2, 3, 4 đều xây dựng trên những khái niệm này. Day 2 chúng ta sẽ đi sâu hơn vào SoT management, templates và workflow thực tế. Hẹn gặp lại! Bây giờ có ai có câu hỏi gì không?

Phần phụ lục này dành cho tham khảo — các bạn có thể xem lại sau buổi học. Bao gồm bảng thuật ngữ, hướng dẫn xử lý sự cố, checklist cho trainer, và câu chuyện về NEXA.

Đây là kiến trúc đầy đủ 6 tầng của NEXA v2 — chi tiết hơn bản tổng quan ở phần chính. Điểm mấu chốt: Fabbi sở hữu và kiểm soát hoàn toàn Layer 4 — NEXA Framework — đây là "bộ não" dạy AI cách làm việc theo chuẩn SI Nhật Bản.

Đây là bảng thuật ngữ để các bạn tra cứu khi cần. Trong quá trình làm việc với NEXA, các bạn sẽ gặp những từ này rất thường xuyên — hãy nhớ kỹ đặc biệt là SoT, RD, BD, DD vì chúng xuất hiện trong mọi lệnh và mọi tài liệu. Nếu quên nghĩa, quay lại slide này hoặc hỏi Claude: "SoT là gì trong NEXA?"

Slide này là hướng dẫn xử lý các sự cố thường gặp trong quá trình cài đặt. Nếu gặp vấn đề nào không có trong danh sách này, hãy báo ngay cho tôi — đừng mất quá 2 phút tự vật lộn một mình. Kinh nghiệm cho thấy 90% vấn đề cài đặt rơi vào một trong 6 trường hợp ở đây, nên hãy đọc kỹ trước. Lưu slide này lại để dùng khi cần sau buổi học.

Đây là checklist dành cho trainer — cần hoàn thành trước buổi học ít nhất 30 phút. Quan trọng nhất là kiểm tra license Claude Code và gửi email cho học viên — không có license thì không thể bắt đầu phần thực hành. Luôn có bản backup trên USB hoặc local share vì mạng internet trong phòng đào tạo đôi khi không ổn định. Test màn chiếu và kết nối API từ máy trainer trước giờ học để tránh mất thời gian xử lý sự cố khi đã bắt đầu.

Slide cuối cùng này kể câu chuyện về quá trình hình thành NEXA — từ ý tưởng đến thực tế. NEXA bắt đầu từ cuối 2024 với ý tưởng SoT và 9 nguyên tắc cơ bản. Đến 2025 H1 đã có 12 templates và DocumentMap. Đến giữa 2025, BD Review engine và TC Generation ra đời. Đầu 2026 mở rộng lên 28 commands và 40+ skills. Các con số metrics nói lên tất cả: DD coverage 86%, Unit Test 96.9%, Overall 89.6% — đây là kết quả thực tế từ dự án thực. NEXA phù hợp nhất với team nhỏ 3-7 người làm dự án enterprise — đây chính là "sweet spot" mà framework mạnh nhất. Câu chuyện này giúp bạn hiểu tại sao NEXA được thiết kế theo cách này — mỗi quyết định đều có lý do từ thực tế.

Cảm ơn tất cả các bạn đã tham gia buổi học Day 1 hôm nay! Hôm nay chúng ta đã đặt nền móng vững chắc — hiểu NEXA là gì, cài đặt được công cụ, và khám phá dự án thực tế. Trước Day 2, hãy thử tự mình hỏi Claude thêm vài câu về dự án để làm quen với cách tương tác. Nếu có vấn đề gì sau buổi học, liên hệ tôi qua luongkam@fabbi.io — tôi luôn sẵn sàng hỗ trợ. Hẹn gặp lại vào Day 2 — chúng ta sẽ đi sâu hơn vào SoT management và bắt đầu dùng templates thực sự!