Từ người dùng AI
đến người xây công cụ

Không thể nào một anh kế toán suốt ngày nợ với có lại tự nhiên dùng AI rồi code ra một hệ thống sáng tạo content marketing tự động.
Người làm được điều đó vốn đã có máu phát minh, có nghề marketing sẵn trong người. AI chỉ phóng to cái đã có.

NHƯNG ĐỌC NGƯỢC LẠI MỚI LÀ ĐIỀU QUAN TRỌNG

Cũng chính anh kế toán đó — người duy nhất trong công ty biết:

• mã tài khoản nào hay bị hạch toán nhầm vào đâu
• tháng nào chi phí bất thường và vì sao
• con số nào sếp sẽ hỏi trước khi sếp kịp hỏi

Không AI nào tự biết những thứ đó. Không người ngoài ngành nào build thay được.
Đó là mỏ vàng, và nó chỉ nằm trong địa hạt của anh ấy.

KẾT

Đừng đi tìm bài toán của người khác. Bài toán đáng giá nhất của bạn là bài toán bạn đang chán nhất vì tháng nào cũng phải làm.

Danh mục thật của mình — để thấy 80/20 trông như thế nào khi làm nhiều năm.

CHUYÊN MÔN LÕI — 80%

• Mô hình tài chính
• Kế hoạch kinh doanh
• Báo cáo quản trị
• Sơ đồ chiến lược
• Tool quản trị dự án
• Thiết kế hệ thống (COA, module của một hệ thống BI)
• Tự động hóa phân bổ chi phí lương
• Bài test cuối khóa tự trộn câu hỏi, tự động trả certificate

VÙNG PHỤ TRỢ — 20%

• Game the Jumper
• Tự học AI

ĐIỀU CẦN CHỈ RA

Không có cái nào trong danh sách lõi là "ứng dụng AI". Tất cả đều là BÀI TOÁN TÀI CHÍNH — AI chỉ là cách làm.
Và cả danh mục này là kết quả của một câu hỏi duy nhất lặp lại nhiều lần: việc này tháng nào cũng làm, đóng gói được không?

Muốn có thú thì kỹ năng phóng lao phải tốt.
Làm việc với AI giai đoạn đầu đòi hỏi năng lực đặt câu hỏi rất tốt — không biết xây prompt cho ra hồn thì kết quả chả tới đâu.

PHÓNG TRƯỢT THÌ CŨNG NHỊN.

Đây là câu đắt nhất của cả tư duy này. Vì nó mô tả đúng cái đã xảy ra với rất nhiều người:

• Hỏi một câu mơ hồ → nhận về thứ chung chung
• Kiểm tra lại mất nhiều thời gian hơn tự làm
• Vài lần như vậy → kết luận "AI không hợp với việc của tôi"
• Quay lại Excel

Không ai trong số họ thiếu công cụ. Tất cả đều đã trả tiền cho công cụ tốt.
Thiếu CÁCH ĐÓNG GÓI QUY TRÌNH.

VÀ ĐÂY LÀ CHỖ TƯ DUY CÔNG NGHIỆP GIẢI QUYẾT

Người săn giỏi vẫn có ngày trượt. Cỗ máy thì không phụ thuộc vào phong độ hôm nay của bạn.

Car sale simulator — công cụ cho tư vấn bán hàng tại showroom ô tô.

CHỨC NĂNG

Add các chương trình khuyến mãi đang chạy · show giá cuối cùng và ưu đãi quà tặng cho khách · cân đối hoa hồng của chính TVBH để quyết định có cạnh tranh giá hay không.

ĐỌC THEO BA TẦNG

Đầu vào — giá niêm yết, danh mục chương trình khuyến mãi, tỷ lệ hoa hồng theo mẫu xe
Logic — chồng các lớp ưu đãi theo thứ tự, tính giá cuối, tính phần hoa hồng còn lại sau khi trợ giá
Đầu ra — một bảng giá cho khách, và một con số cho TVBH: sau deal này tôi còn lại bao nhiêu

BA ĐẶC ĐIỂM CÔNG NGHIỆP THỂ HIỆN Ở ĐÂU

ID1 lặp lại — mỗi ngày mỗi khách, chạy lại được ngay, không ai phải mở Excel
ID2 mẫu số chung — mọi deal đều là một bài toán: giá gốc → các lớp ưu đãi → giá cuối
ID3 chia bước — đổi chính sách khuyến mãi thì sửa bảng chương trình, không đụng phần tính hoa hồng

ĐIỂM ĐẮT NHẤT

Nó không đưa ra quyết định thay TVBH. Nó cho TVBH thấy hậu quả của quyết định TRƯỚC KHI ký.

Bài toán ban đầu: gửi khách một bản vẽ thiết kế hệ thống. Làm xong, gửi đi, hết.
Khách sau lại vẽ lại từ đầu.

CHUYỂN SANG TƯ DUY CÔNG NGHIỆP

Thay vì gửi một bản vẽ, dựng một TOOL TẠO ĐƯỢC NHIỀU BẢN VẼ với độ phức tạp khác nhau, tái sử dụng cho mọi khách sau.

CẤU PHẦN — đúng 5 node
Nhập liệu → Chỉnh sửa → Hiển thị → Lưu kết quả → Xuất báo cáo

BƯỚC KHIẾN NÓ THÀNH CÔNG CỤ TÀI CHÍNH

Gắn thêm trường "Finance" cho mỗi node → thiết kế xong là RA ĐƯỢC BÁO GIÁ NGAY.
Trước: vẽ xong rồi ngồi tính giá riêng, mất thêm một buổi.
Sau: giá là hệ quả tự động của thiết kế.

ĐIỂM CẦN THẤY

Cỗ máy này không thay thế chuyên môn thiết kế. Nó phóng to chuyên môn đó lên — đúng nguyên lý đèn pin ở TD1.

Công cụ phân bổ chi phí lương — bài toán tài chính thuần, tháng nào cũng làm.

BA TẦNG

Đầu vào — bảng lương từ HR: mã nhân viên, bộ phận, các khoản
Logic — quy tắc phân bổ theo bộ phận / trung tâm chi phí / dự án; xử lý người làm nhiều bộ phận
Đầu ra — bảng phân bổ để hạch toán, và số liệu kế hoạch cho kỳ tới

VÌ SAO ĐÂY LÀ VÍ DỤ TỐT CỦA ID3 — CHIA BƯỚC

Nạp lương · Cấu hình quy tắc · Preview · Lên bút toán · Xuất dữ liệu.
Năm bước riêng biệt, sửa bước nào cũng không làm vỡ bước khác.
Đổi cơ cấu bộ phận tháng sau → sửa đúng bước "cấu hình", bốn bước còn lại giữ nguyên.

SO VỚI CÁCH LÀM CŨ

Excel với công thức chằng chịt: đổi một bộ phận là dò lại toàn file, và không ai ngoài người lập dám sửa.

ĐIỂM QUAN TRỌNG NHẤT

Bảng quy tắc phân bổ nằm TÁCH RỜI khỏi logic tính.
Đó là ranh giới giữa một tool dùng được tháng sau và một tool chỉ đúng với file tháng này.

SAAS strategy simulation — ví dụ về ranh giới giữa vừa đủ và thừa, trên chính tool của mình.

TÍNH NĂNG ĐÁNG GIÁ — đổi được quyết định

• Dependency — thấy được thay đổi ở đâu kéo theo gì, tránh quyết định cục bộ
• Key metrics — chỉ số nào đang thật sự dịch chuyển
• Financial model — hệ quả tài chính của kịch bản đang xét

TÍNH NĂNG DƯ THỪA — nhìn thì hay, không đổi quyết định nào

• List view
• Board view

Hai view này tốn công build, tốn công bảo trì, và người dùng thật chỉ mở đúng một cách xem.

BÀI HỌC RÚT RA

Không phải "nó xấu" nên bỏ. Là vì KHÔNG AI RA QUYẾT ĐỊNH KHÁC ĐI vì có thêm hai view đó.
Đây là bài kiểm tra cho mọi tính năng: bỏ nó đi thì có quyết định nào thay đổi không?
Không → nó là thừa, kể cả khi AI dựng nó trong hai phút.

Car sale simulator — giao diện tổng hợp (dành cho quản lý showroom).

Cùng một cỗ máy tính toán, nhưng giao diện này phục vụ người khác và câu hỏi khác:

• Toàn bộ deal đang chạy, mẫu xe nào đang bị cắt giá nhiều nhất
• Biên còn lại theo từng nhóm sản phẩm
• Chương trình khuyến mãi nào đang ăn vào lợi nhuận

VÌ SAO CHIẾU CẢ HAI GIAO DIỆN

Để thấy nguyên tắc: MỘT ENGINE, NHIỀU LĂNG KÍNH.
Không dựng hai công cụ. Dựng một lõi tính toán, rồi mở hai cửa sổ nhìn vào nó.

UI/UX Ở ĐÂY KHÔNG PHẢI TRANG TRÍ

Cùng con số, người quản lý cần thấy tổng thể và xu hướng; TVBH cần thấy đúng một deal trước mặt.
Cho TVBH xem màn hình này thì họ không dùng — quá nhiều thứ không liên quan tới việc đang làm.

Đó là ý nghĩa thật của tiêu chí 3: giao diện đúng với NGƯỜI DÙNG và QUYẾT ĐỊNH của họ, không phải giao diện đẹp.

Car sale simulator — giao diện dành cho tư vấn bán hàng.

Một màn hình, một deal, ba con số:

• Giá cuối cho khách sau khi chồng các lớp ưu đãi
• Quà tặng kèm theo
• Hoa hồng còn lại của chính TVBH sau khi trợ giá

CHỖ ĐÁNG HỌC VỀ UI/UX

• Không có menu, không có báo cáo, không có biểu đồ
• Người dùng không cần được đào tạo mới dùng được
• Ra được câu trả lời trong lúc khách đang ngồi trước mặt — bối cảnh quyết định thiết kế

SO SÁNH VỚI GIAO DIỆN TỔNG HỢP

Cùng engine, khác lăng kính, vì khác người dùng và khác quyết định.

BÀI HỌC CHO HỌC VIÊN

Trước khi thiết kế giao diện, trả lời: AI ngồi trước màn hình này, ĐANG PHẢI QUYẾT ĐỊNH GÌ, TRONG BAO NHIÊU GIÂY?
Trả lời được câu đó thì giao diện gần như tự hiện ra. Không trả lời được thì mọi lựa chọn màu sắc đều là đoán.

Hotel P&L simulation — BẢN HARDCODE.

Công cụ mô phỏng P&L cho một dự án khách sạn. Chạy được. Trông ổn. Đưa cho khách xem thì thuyết phục.

VẤN ĐỀ NẰM Ở BÊN TRONG

Rất nhiều thông tin dự án bị fix cứng trong code: số phòng, giá phòng giả định, cơ cấu chi phí, các mốc thời gian.

HỆ QUẢ

• Dự án khác → phải sửa code, không sửa được dữ liệu
• Người không biết code → không dùng được, dù chỉ muốn đổi một con số
• Sửa một chỗ dễ làm vỡ chỗ khác vì số nằm rải rác nhiều nơi
• Sau ba tháng chính người viết cũng không nhớ con số đó nằm ở đâu

ĐÂY LÀ XE TRƯNG BÀY

Đẹp, đúng, chạy được — với đúng một dự án. Demo thì tốt, làm việc thật thì không.

ĐIỂM CẦN THẤY

Nó không sai về mặt tính toán. Sai ở CẤU TRÚC.
Và lỗi cấu trúc thì không lộ ra ở lần dùng đầu tiên — nó lộ ra ở lần thứ hai.

Hotel P&L simulation — BẢN CONFIGURE.

Cùng bài toán, cùng công thức, cùng kết quả. Khác duy nhất ở chỗ: mọi thông số dự án được đưa ra ngoài thành CẤU HÌNH.

CÁI ĐỔI

• Số phòng, giá phòng, cơ cấu chi phí, mốc thời gian → nằm ở phần nhập liệu
• Logic tính toán không biết gì về dự án cụ thể nào
• Dự án mới → nhập thông số mới, không sửa một dòng code

CÁI THU ĐƯỢC

• Một lần build, dùng cho mọi dự án khách sạn về sau
• Người không biết code vẫn chạy được
• So sánh nhiều kịch bản trong vài phút thay vì vài ngày
• Ba tháng sau mở lại vẫn hiểu, vì thông số nằm một chỗ

CHI PHÍ THÊM ĐỂ LÀM ĐÚNG TỪ ĐẦU: gần như bằng không, nếu nghĩ trước.
CHI PHÍ ĐỂ SỬA SAU: gần bằng làm lại từ đầu.

ĐÂY LÀ TOÀN BỘ TIÊU CHÍ 4

"Nghĩ trước" — hai chữ đó đáng giá đúng bằng khoảng cách giữa hai bản này.

Công cụ phân bổ lương — bản đang chạy thật.

Cùng bài toán với node ở TD2, nhưng ở đây nhìn dưới góc TIÊU CHÍ 4: vì sao nó còn sống sau nhiều tháng.

BỐN THỨ KHÔNG BỊ HARDCODE

• Danh mục bộ phận / trung tâm chi phí — nằm trong cấu hình
• Quy tắc phân bổ — một bảng riêng, sửa được mà không đụng logic
• Cấu trúc file lương đầu vào — khai báo cột, không giả định thứ tự cố định
• Kỳ tính — chọn, không viết cứng

PHÉP THỬ XE THẬT

• Tháng sau có bộ phận mới → thêm dòng vào bảng, không mở code ✓
• Đổi cách phân bổ → sửa quy tắc, phần tính không đụng tới ✓
• Người khác cầm chạy → chạy được, không cần hỏi ✓
• Chạy hai lần cùng dữ liệu → ra cùng kết quả ✓

BỐN DẤU TÍCH ĐÓ CHÍNH LÀ ĐỊNH NGHĨA CỦA "ĐANG DÙNG THẬT"

Và "đang dùng thật" nằm trong nhóm tiêu chí chiếm 30% điểm cuộc thi.

Cuộc thi bốn tuần không phải một bộ luật rời rạc. Nó là TD4 viết lại dưới dạng tiêu chí chấm.

TIÊU CHÍ CHẤM CHÍNH LÀ BA THỪA SỐ CỦA TD4

Tiết kiệm thời gian đo được (40%) → GIÁ TRỊ 1 LẦN DÙNG
Đang được dùng thật + có người khác dùng (chung một nhóm 30%) → SỐ LẦN DÙNG × SỐ NGƯỜI DÙNG
(20% còn lại: độ khó & sáng tạo · 10%: khả năng người khác áp dụng lại)

Độ khó & sáng tạo chỉ 20% — và đó là chủ ý.
Giải thưởng dành cho người GIẢI ĐƯỢC VIỆC THẬT, không dành cho người khoe được kỹ thuật.

ĐIỀU KIỆN DỰ THI CŨNG LÀ BA THỪA SỐ

• Nêu rõ trước đây mất bao lâu → giờ mất bao lâu (thừa số 1)
• Công cụ đang chạy thật, không phải ý tưởng trên giấy (thừa số 2)
• Ít nhất một người khác ngoài bạn đã dùng nó (thừa số 3)

VÌ THẾ

Ai chọn đúng bài toán bằng phép nhân sáng nay thì chiều nay build đúng hướng, và bốn tuần nữa nộp được bài.
Chọn sai bài toán thì build giỏi đến mấy tích vẫn nhỏ.

BCQT bản chỉ dùng được một lần.

Báo cáo quản trị đầy đủ, số đúng, trình bày ổn. Nhưng mọi thông tin đều hardcode: kỳ báo cáo, danh mục đơn vị, cơ cấu tài khoản đều nằm cứng bên trong.

CHẤM THEO BA THỪA SỐ

Giá trị 1 lần dùng: CAO — báo cáo dùng được thật
Số lần dùng/năm: 1 — tháng sau phải làm lại từ đầu
Số người dùng: 1 — chỉ người dựng ra nó mới sửa được

TÍCH = CAO × 1 × 1 = NHỎ

ĐIỂM ĐAU

Công sức bỏ ra để dựng bản này gần bằng công sức dựng bản dùng được 12 lần.
Chênh lệch không nằm ở khối lượng làm. Nằm ở QUYẾT ĐỊNH CẤU TRÚC ở phút đầu tiên.

Đây là lý do TD4 phải học TRƯỚC khi build, không phải sau.

Business plan tổng thể — Sale in / Sale out / Cash flow.

Giá trị 1 lần dùng: CAO — quyết định kế hoạch cả năm, ràng buộc dòng tiền và hạn mức tín dụng
Số lần dùng/năm: THẤP — 1 lần lập, 4 lần review theo quý
Số người dùng: THẤP — Ban giám đốc + CFO

Tích vẫn lớn vì thừa số đầu quá lớn: một quyết định đặt hàng sai kéo theo vốn lưu động chôn cả năm.
Đây là dạng "quyết định lớn, ít người, ít lần" — đối lập trực tiếp với ví dụ BCQT lặp hàng tháng.

BCQT dùng n lần — bản đóng gói.

Cùng một bài toán với node bên cạnh, khác nhau ở cấu trúc:

• Bảng mapping tách khỏi logic → thêm mã tài khoản mới thì sửa bảng, không sửa tool
• Nạp file kỳ mới → chạy lại trong vài giây, không dựng lại từ đầu
• Người khác cầm chạy được mà không cần hỏi mình

Giá trị 1 lần dùng: trung bình · Số lần dùng/năm: 12+ · Số người dùng: nhiều (mỗi entity một người)
→ Tích lớn nhờ hai thừa số sau, không nhờ thừa số đầu.

Đây chính là câu hỏi của học viên: "mỗi lần review thay đổi số, tôi phải lặp lại thao tác này."
Bản dùng 1 lần trả lời được câu hỏi tháng này. Bản dùng n lần trả lời được câu hỏi của 12 tháng.

Dùng Claude Project + Instruction — nơi kiến thức được TÍCH LŨY thay vì gõ lại mỗi lần.

TẠO INSTRUCTION LẦN ĐẦU

Đừng ngồi viết từ đầu. Làm việc bình thường vài lần, mỗi lần phải nhắc lại điều gì thì ghi điều đó xuống.
Sau 3–5 lần, những dòng ghi lại đó chính là instruction.

INSTRUCTION CÓ NHỮNG GÌ

• Bạn là ai, làm ngành gì, dữ liệu của bạn trông thế nào
• Quy tắc nghiệp vụ cố định — thứ AI không thể tự biết
• Định dạng đầu ra bạn luôn muốn
• Những lỗi AI hay mắc với bạn và cách tránh
• Những gì TUYỆT ĐỐI không được suy đoán — thiếu thì báo thiếu

CẬP NHẬT

Mỗi lần phải sửa tay một kết quả, hỏi: điều này nên nằm trong instruction chứ?
Nếu có → thêm vào. Đó là lúc bạn đang xây cỗ máy thay vì đi săn.

VÌ SAO ĐÂY LÀ "AI TRAINING" CHỨ KHÔNG PHẢI "AI PROMPT"

Prompt hết tác dụng khi đóng chat. Instruction thì ở lại — và mỗi tháng nó lại tốt hơn tháng trước.

COA — hệ thống tài khoản, xương sống của toàn bộ hệ thống quản trị tài chính.

VÌ SAO COA LÀ VÍ DỤ MASTER DATA TỐT NHẤT

• Nó là quy tắc nghiệp vụ thuần túy — AI không thể tự suy ra
• Nó thay đổi theo thời gian nhưng chậm — đúng đặc điểm master data
• Mọi báo cáo đều phụ thuộc vào nó — sai một chỗ, sai tất cả

CÁI XẢY RA KHI KHÔNG TÁCH RIÊNG

Mã tài khoản nằm rải rác trong công thức, trong code, trong từng file báo cáo.
Tháng sau có mã mới → phải đi tìm và sửa nhiều chỗ, và chắc chắn sót một chỗ.

CÁI XẢY RA KHI TÁCH RIÊNG THÀNH REGISTRY

• Một nguồn sự thật duy nhất
• Thêm mã mới = thêm một dòng
• Công cụ tự phát hiện mã lạ và BÁO LỖI TO thay vì âm thầm bỏ qua

CÂU HỎI CHO HỌC VIÊN

Trong bài toán của bạn, đâu là COA? Cái gì là danh mục gốc mà mọi thứ khác phải chiếu vào?
Trả lời được câu này thì bạn đã có bước đầu tiên của thiết kế.

Tool phân bổ lương — đọc theo góc QUY TRÌNH HÓA: năm bước tách rời.

• 1. NẠP BẢNG LƯƠNG — đọc file từ HR, khai báo cột, kiểm tra thiếu đủ
• 2. CẤU HÌNH — quy tắc phân bổ theo bộ phận / trung tâm chi phí / dự án
• 3. PREVIEW — xem trước kết quả phân bổ TRƯỚC KHI ghi sổ
• 4. LÊN JE — sinh bút toán
• 5. XUẤT DATA — đưa sang phần mềm kế toán

VÌ SAO BƯỚC 3 QUAN TRỌNG NHẤT

Preview là chỗ con người kiểm tra. Bỏ bước này thì công cụ trở thành hộp đen — và hộp đen là thứ không ai dám dùng cho việc thật.
Đây chính là ranh giới "khai thác được sức mạnh mà không bị lệ thuộc" mà học viên hỏi trong khảo sát.

VÌ SAO PHẢI TÁCH THÀNH NĂM BƯỚC

Đổi quy tắc phân bổ → sửa bước 2, bốn bước còn lại không đụng tới.
Đổi định dạng file HR → sửa bước 1.
Nếu năm việc này gộp làm một, mỗi lần đổi bất cứ thứ gì đều phải kiểm lại toàn bộ.

MẪU ÁP DỤNG ĐƯỢC NGAY

Nhập → Cấu hình → Xem trước → Sinh kết quả → Xuất. Gần như mọi bài toán tài chính lặp lại đều vừa khuôn này.

Dành cho ai muốn đi sâu về giao diện. Vòng đầu cứ bỏ qua — không ảnh hưởng phần thi. Quay lại đây khi phần lõi đã chạy đúng và bạn muốn tool nhìn chuyên nghiệp hơn.

DESIGN INSTRUCTION — UI/UX Layer cho Single-File Tools
Companion của DESIGN_INSTRUCTION_reusable.md (v1.0 = kiến trúc dữ liệu; bản này = tầng giao diện & tương tác)
Version 1.0 — chắt lọc từ đối chiếu COA Registry v3.1 × Digital Twin Lab Publisher v4.3, 03/07/2026

• 0. QUYẾT ĐỊNH ĐẦU TIÊN: TOOL THUỘC CLASS NÀO?

Mọi lựa chọn UI/UX phía dưới bắt nguồn từ câu hỏi này. Trả lời trước khi viết dòng CSS đầu tiên.
WORKBENCHSHOWCASEBản chấtCông cụ thao tác dữ liệu, dùng lặp lại hàng ngàyDeliverable cho người khác xem/trải nghiệmVí dụCOA Registry, config editor, mixer, staff cost inputDashboard BCQT, proposal, simulator demo, training toolNgười dùngChính mình / power user, dùng 100+ lầnSếp, khách, học viên — dùng 1–5 lầnThemeLight, phẳng, không shadow/gradientMidnight Executive dark (gradient nền, card shadow, hero serif)Accent1 màu chủ đạo + ≤3 màu ngữ nghĩaPalette gold/teal/rose đầy đủDensityCao: font 13–13.5px, padding 5–12pxThoáng: font 14px+, padding 20–24px, radius 16–22pxƯu tiênTốc độ thao tác, state visibility, reversibilityẤn tượng đầu tiên, storytelling, brand
Bài học gốc: Publisher v4.3 là workbench nhưng mặc áo showcase → đẹp từng phần nhưng thao tác chậm, phải scroll, màu cạnh tranh nhau. COA Registry đúng class → "cảm giác tốt hơn" dù ít trang trí hơn. Sai class là sai từ gốc, không sửa được bằng polish.
Tool lai (simulator có cả nhập liệu nặng lẫn trình chiếu): tách 2 mode — edit mode theo chuẩn Workbench, present/preview mode theo Showcase.

• 1. LAYOUT KHUNG (áp cho Workbench)

┌─ TOP BAR (sticky) ──────────────────────────────────────────┐
│ Tên tool · ver-badge · release-stamp · context-badge │
│ status-pill · Undo(n) · actions · PRIMARY│
├─ TABS (đánh số theo workflow) ──────────────────────────────┤
│ 1. Editor │ 2. Preview │ 3. Versions │

├─ SHELL ─────────────────────────────────────────────────────┤

│ LEFT PANEL ║ RIGHT CONTENT │

│ (filter+detail) ║ (subnav đánh số → tree/table/matrix) │
│ ~380px ║ │
│ resizer ─╢ (kéo được, width persist localStorage) │
└─────────────────────────────────────────────────────────────┘

Top bar sticky chứa: định danh (tên + version + release stamp + đang mở công ty/context nào) bên trái; trạng thái + hành động bên phải. Nút primary duy nhất một cái, đặt cuối cùng bên phải.
Release stamp ghi rõ ngày giờ + tóm tắt scope của bản build (vd: Released 03/07/2026 12:10 · Filter: +Segment +Department). Chi phí 1 dòng, giá trị: không bao giờ nhầm version khi có nhiều file lưu rải rác.
Version badge phải sinh từ 1 biến duy nhất (const trong JS render ra mọi chỗ hiển thị). Bài học Publisher: pill ghi V4.1 trong khi file là v4.3 — drift do hardcode 2 chỗ.
Left panel = filter + detail (inspector) cố định. Chọn item ở content → detail hiện bên trái, không popup, không modal. Người dùng vừa thấy ngữ cảnh vừa sửa.
Resizer giữa 2 panel, width lưu vào state persist.

• 2. NAVIGATION ENCODE WORKFLOW

Đánh số tab theo vòng đời làm việc, không liệt kê danh từ chức năng: 1. Editor → 2. Preview → 3. Versions chứ không phải Editor / Preview / Versions / Config.
Nếu tool có mô hình dữ liệu nhiều khối, subnav đánh số theo khối và thêm 1 câu hint cố định giải thích mô hình: "Mô hình 3 khối: (1) COA cây tài khoản thuần · (2) Centers · (3) Mixer áp COA vào center". Người mở lần đầu hiểu kiến trúc chỉ bằng nhìn nav.
Tab dạng folder (bo góc trên, nối liền vào shell) cho Workbench; tab pill gradient cho Showcase.

• 3. STATE VISIBILITY & REVERSIBILITY — bắt buộc, không phải nice-to-have

Đây là yếu tố quyết định cảm giác "tool đáng tin". Checklist tối thiểu cho Workbench:

Undo stack (≥40 bước), nút hiện số lượng: ↩ Undo (7). Push snapshot trước mọi mutation. Disabled khi rỗng.
Status pill cố định 1 vị trí trên header, 3 trạng thái ok/warn/err, tự tắt sau 4s. Mọi hành động đều phản hồi qua đây — không alert() cho thông báo thường.
Snapshot version + hash + diff: chụp toàn bộ model, so sánh 2 version với 4 màu ngữ nghĩa (Thêm xanh / Xóa đỏ / Sửa vàng / Bật-Tắt xanh dương).
Destructive action: undo là tuyến phòng thủ 1; confirm() là tuyến 2 và phải giải thích hệ quả + phạm vi: "Xóa khỏi máy này? (File JSON đã export không bị ảnh hưởng)" — nói rõ cái gì mất, cái gì không.
Feedback theo loại tác vụ: thao tác tức thời → status pill; tác vụ async nhiều bước (API, publish, sync) → log console có timestamp trong panel riêng (pattern Publisher làm đúng). Không dùng pill cho async dài, không dùng log cho thao tác 1 chạm.

• 4. PROGRESSIVE DISCLOSURE & GIỮ NGỮ CẢNH

Action buttons trên row/node: ẩn mặc định, hiện khi hover hoặc selected (.nbtns{display:none} → :hover .nbtns{display:flex}). Danh sách sạch, thao tác vẫn 1 click.
Inactive ≠ filtered-out, hiển thị khác nhau:

Inactive (tắt bởi user): opacity .45 + gạch ngang label — vẫn thấy để bật lại, chỉ ở view chỉnh sửa gốc.
Bị filter loại: opacity .22 (dim, không remove khỏi DOM) — giữ nguyên hình dạng cây, người dùng không mất định vị. Ancestor của node match được giữ sáng để thấy đường dẫn.

Chips ngữ nghĩa thay vì cột: mã tài khoản = mono chip xám, forward-only = chip vàng warn, type = chip xanh dương. Nhỏ (9.5–10.5px), đặt inline cạnh label.

• 5. KỶ LUẬT COMPONENT

Button đúng 3 loại: default (viền, nền trắng) / primary (nền accent — mỗi màn hình tối đa 1) / danger (chữ đỏ viền đỏ nhạt). Thêm biến thể small nếu cần. Không sinh thêm màu button mới cho từng ngữ cảnh (bài học Publisher: 6 biến thể → mất hierarchy).
Segmented control đúng 1 kiểu trong toàn tool — cùng border, cùng active style. Publisher có 4 kiểu khác nhau trong 1 file, mỗi khu vực người dùng phải học lại.
Semantics tại điểm hành động: nút export/import phải nói rõ contract ngay trên nhãn + tooltip: 📤 Schema (cho hệ khác) — "file PHẲNG chỉ mapping active, KHÔNG import ngược được" vs 💾 Full model (backup) — "import lại được". Người dùng không phải nhớ tài liệu ngoài.
Toggle switch cho on/off trạng thái (không checkbox trần); hover-reveal cho hành động phụ.

• 6. TABLE & MATRIX (dữ liệu lớn)

Header sticky (position:sticky;top:0), row-header sticky trái cho matrix (left:0, z-index phân tầng, corner cell z cao nhất).
Cột phân tầng theo cấp (BU/Segment/Stream): 3 mức đậm nhạt của cùng 1 hue, kèm legend nhỏ — người đọc phân biệt cấp không cần đọc chữ.
Header xoay dọc (writing-mode:vertical-rl) khi cột hẹp; slider chỉnh độ rộng cột, giá trị persist.
Group row nền nhạt + đậm; row bị filter → opacity .25 giữ chỗ.

• 7. EMPTY STATE & ONBOARDING

Tool chưa có dữ liệu → welcome screen thay vì UI trống: (1) tạo mới + đặt tên, (2) nạp template ví dụ, (3) import file, (4) danh sách các workspace đã lưu local kèm nút mở/xóa.
Multi-workspace qua localStorage: key = prefix + slug, lưu kèm savedAt, nhớ workspace mở cuối (LS_LAST).

• 8. NHỮNG THỨ WORKBENCH PHẢI HỌC TỪ SHOWCASE (điểm Publisher làm đúng)

Theme bằng CSS variables ngay từ đầu — toàn bộ màu qua :root{--...}, kể cả khi chưa cần dark mode. Đổi theme = swap 1 class trên body.
Focus state cho mọi input: focus → border-color:accent + box-shadow ring 3px (COA v3.1 thiếu hoàn toàn — keyboard navigation kém).
Responsive breakpoint tối thiểu @900px: panel dọc hóa, splitter ẩn, grid về 1 cột. Không cần mobile-first, nhưng không được vỡ trên laptop nhỏ/máy chiếu.
Multi-lens view cho cùng 1 dataset: List / Board / Matrix / Mindmap + group-by động — một dữ liệu, nhiều góc nhìn, chọn lens theo câu hỏi đang trả lời.
Drag-drop zone cho file input (kèm click fallback + hiện file meta sau khi chọn).

• 9. TYPOGRAPHY & MÀU (chung 2 class)

Font: Noto Serif Display (heading/định danh) + Outfit (body/UI) + DM Mono (mã, số, path, hash). Subset bắt buộc vietnamese. Không dùng DM Serif Display (thiếu glyph Việt).
Mono dùng đúng chỗ: account code, slug, file path, hash, timestamp log — mắt phân biệt "dữ liệu định danh" khỏi "nhãn UI" tức thì.
Workbench palette mẫu (từ COA v3.1): ink #16201C · muted #6a746e · line #e3e8e4 · bg #f4f6f4 · accent #0B5D4B · neg #B3402E · warn #8a5a12/#fff9e8 · soft #eaf3ef.
Showcase palette: theo Midnight Executive hiện hành (gold #d4af6a / teal #4fd1c5 / rose #e08a9e trên nền #080b14→#121a2e).

• 10. CHECKLIST TRƯỚC KHI RELEASE

Đã chọn class (Workbench/Showcase) và theme đúng class?
Tab + subnav đánh số theo workflow? Có hint giải thích mô hình?
Undo hoạt động cho mọi mutation? Status pill phản hồi mọi action?
Version badge sinh từ 1 const duy nhất? Release stamp có ngày giờ + scope?
Destructive action giải thích hệ quả trong confirm?
Export buttons nói rõ contract (import ngược được hay không)?
Focus state cho input? Breakpoint @900px không vỡ?
Chỉ 1 nút primary/màn hình? Chỉ 1 kiểu segmented control?
Filter dim thay vì remove? Action buttons hover-reveal?
Empty state có welcome screen + template + import?

Nguồn đối chiếu: COA_Registry_v3_1.html (chuẩn Workbench) × digital-twin-lab-publisher-v4_3.html (chuẩn Showcase áp nhầm vào Workbench, nhưng đóng góp theme system, focus state, responsive, multi-lens workspace, operation log).

P&L forecast — ví dụ đúc khuôn trên một bài toán tài chính thật.

BỐN BƯỚC ĐÃ LÀM

• 1. Nạp báo cáo quản trị — dữ liệu thật, vài kỳ
• 2. AI học cấu trúc P&L — tầng doanh thu, giá vốn, chi phí, các mức biên
• 3. Phát triển thêm bottom-up metrics — không chỉ dự báo tổng, mà dựng từ các driver bên dưới lên
• 4. Chạy thử và hoàn thiện — đối chiếu với kỳ đã biết, sửa quy tắc cho tới khi khớp

BƯỚC 3 LÀ CHỖ CHUYÊN MÔN TÀI CHÍNH VÀO CUỘC

AI dự báo được xu hướng từ số quá khứ. Nhưng nó không biết doanh thu của bạn được dựng từ đâu:
số khách × giá trị đơn hàng, hay số xe × biên mỗi xe, hay số thuê bao × ARPU.
Chọn driver nào là NGHIỆP VỤ — và đó là tác vụ người phải giữ.

BƯỚC 4 LÀ CHỖ PHÂN BIỆT CÔNG CỤ VỚI ĐỒ CHƠI

Chạy ngược trên kỳ đã biết. Không khớp thì sửa QUY TẮC, không sửa kết quả cho đẹp.
Một mô hình dự báo không backtest được thì không dùng cho quyết định thật.