Trước khi vẽ ô vuông đầu tiên lên diagram, câu hỏi quan trọng nhất không phải "kiến trúc nào đúng" mà là "bạn đã hỏi đủ câu hỏi chưa" — và đây chính là chỗ AI tạo ra giá trị lớn nhất, không phải lúc gõ code.
Vì Sao Cuộc Trò Chuyện Thiết Kế Quan Trọng Hơn Tài Liệu Thiết Kế
Bạn đã từng đọc một design doc dài mười trang, ký duyệt, rồi ba tuần sau phát hiện ra nó bỏ sót một ràng buộc sống còn chưa? Chuyện này xảy ra vì tài liệu thiết kế chỉ ghi lại kết quả của tư duy — nó không ghi lại quá trình. Bạn không thấy được những câu hỏi đã bị bỏ qua, những giả định chưa từng bị thách thức, những phương án bị loại bỏ mà không ai giải thích tại sao.
Đây là lý do vì sao, khi làm system design (thiết kế hệ thống) cùng AI, mục tiêu không phải là "yêu cầu AI viết một design doc hoàn chỉnh". Mục tiêu là biến AI thành một đối tác trò chuyện — một người vừa có kiến thức rộng về pattern, vừa không có cái tôi, vừa sẵn sàng bị bạn bẻ lại liên tục mà không giận. Cuộc trò chuyện đó, nếu được dẫn dắt đúng, sẽ sản sinh ra một design doc tốt hơn nhiều so với việc bạn ngồi một mình gõ ra, hoặc yêu cầu AI "viết giúp tôi" ngay từ đầu.
Có một khác biệt tinh tế nhưng cực kỳ quan trọng: khi bạn yêu cầu AI "thiết kế hệ thống X", nó sẽ nhảy thẳng đến giải pháp — thường là giải pháp phổ biến nhất trong dữ liệu huấn luyện, không phải giải pháp phù hợp nhất với ngữ cảnh của bạn. Nhưng khi bạn yêu cầu AI "hỏi tôi những gì cần biết trước khi thiết kế X", bạn đang đảo ngược vai trò — AI trở thành người phỏng vấn, còn bạn là nguồn tri thức về domain (miền nghiệp vụ). Kết quả cuối cùng chất lượng hơn hẳn, vì thiết kế được neo vào ràng buộc thật, không phải ràng buộc tưởng tượng.
Ví dụ prompt mở đầu một phiên thiết kế:
Tôi cần thiết kế hệ thống xử lý thanh toán định kỳ (recurring billing)
cho một SaaS B2B, khoảng 5,000 khách hàng, dự kiến tăng lên 50,000
trong 2 năm. Đừng đề xuất giải pháp ngay. Hãy đóng vai một staff
engineer đang phỏng vấn tôi để hiểu bài toán — hỏi tôi từng câu một,
tập trung vào các ràng buộc non-negotiable trước, sau đó mới tới
sở thích/tối ưu. Bắt đầu.
Cách viết prompt như trên buộc AI chậm lại, thay vì lao thẳng vào diagram. Bạn sẽ thấy nó hỏi những câu bạn chưa nghĩ tới: retry logic khi thẻ bị từ chối xử lý ra sao, múi giờ nào dùng để tính "ngày gia hạn", ai chịu trách nhiệm khi webhook từ payment gateway đến trễ.
Mẹo: Luôn mở đầu phiên thiết kế bằng câu "đừng đề xuất giải pháp, hãy hỏi tôi trước" — nếu không, AI sẽ mặc định nhảy vào chế độ trả lời thay vì chế độ khám phá.
Prompt AI Để Steelman Các Phương Án Khác Nhau
Một trong những sai lầm phổ biến nhất khi review thiết kế của con người: chúng ta có xu hướng strawman (đơn giản hóa quá mức để dễ bác bỏ) phương án mà mình không thích, và chỉ đào sâu phân tích phương án mình đã ngầm chọn từ đầu. AI cũng có nguy cơ này — nhưng bạn có thể ép nó làm ngược lại bằng kỹ thuật steelmanning (xây dựng phiên bản mạnh nhất, thuyết phục nhất cho một lập luận, kể cả lập luận bạn không đồng ý).
Thay vì hỏi "microservices hay monolith tốt hơn cho dự án này", hãy yêu cầu AI trình bày phiên bản mạnh nhất của CẢ HAI, với người ủng hộ giả định là một kỹ sư giỏi thực sự tin vào phương án đó — không phải một "yes-man" nói cho có.
Tôi đang cân nhắc giữa modular monolith và microservices cho hệ thống
order management, team 6 người, chưa có kinh nghiệm vận hành
Kubernetes. Hãy đóng hai vai:
Vai 1: Staff engineer cực kỳ ủng hộ modular monolith — đưa ra
lập luận mạnh nhất có thể, không nói giảm nói tránh nhược điểm
của microservices trong bối cảnh này.
Vai 2: Staff engineer cực kỳ ủng hộ microservices — cũng làm tương tự,
lập luận mạnh nhất, không strawman monolith.
Sau đó, với vai trò trung lập, chỉ ra: phương án nào thắng ở điều
kiện nào cụ thể của team tôi, và điều gì sẽ khiến kết luận đảo ngược.
Bạn sẽ nhận thấy: khi bị ép steelman, AI thường tự phát hiện ra rằng câu trả lời "đúng" phụ thuộc vào một vài biến số cụ thể — quy mô team, ngân sách vận hành, tốc độ release mong muốn — chứ không phải một chân lý tuyệt đối. Đó chính là insight (nhận thức) giá trị nhất của bài tập steelmanning: nó biến câu hỏi nhị phân thành câu hỏi về điều kiện.
Một biến thể khác cực kỳ hữu ích: yêu cầu AI đóng vai người sẽ phải bảo trì hệ thống này sau 2 năm, khi bạn đã rời team. Góc nhìn "người kế thừa" thường lật ra những trade-off (đánh đổi) về khả năng vận hành mà người thiết kế ban đầu (đang hào hứng với công nghệ mới) dễ bỏ qua.
Mẹo: Khi steelman, luôn chỉ định rõ persona (vai trò) là "kỹ sư giỏi thực sự tin vào phương án này" — nếu không AI có xu hướng ngầm làm yếu phương án nó "không thích" dựa trên độ phổ biến trong dữ liệu huấn luyện.
Khai Thác Những Yêu Cầu Chưa Nói Ra và Các Edge Case
Bug đắt giá nhất trong sự nghiệp của bạn, gần như chắc chắn, không đến từ logic sai — mà đến từ một yêu cầu chưa từng được viết ra, chưa từng được ai hỏi. "Đơn hàng có thể bị hủy sau khi đã ship chưa?" "Nếu hai người cùng edit một record cùng lúc thì sao?" "Múi giờ hiển thị cho user là theo user hay theo server?" Đây là những câu hỏi mà stakeholder thường không tự nghĩ ra, vì với họ nó "hiển nhiên" — cho đến khi nó không hiển nhiên với hai người theo hai cách khác nhau.
AI rất giỏi trong việc liệt kê các lớp edge case (trường hợp biên) mang tính hệ thống, vì nó đã "thấy" hàng nghìn hệ thống tương tự trong dữ liệu huấn luyện. Nhưng nó chỉ làm tốt việc này nếu bạn yêu cầu rõ ràng — nếu không, nó sẽ mặc định giả sử "happy path" (kịch bản thuận lợi, không có lỗi) là đủ.
Đây là mô tả tính năng của tôi: "Cho phép user đặt lịch nhắc nhở
(reminder) định kỳ — hàng ngày, hàng tuần, hoặc hàng tháng."
Hãy liệt kê tất cả câu hỏi làm rõ yêu cầu (clarifying questions)
mà một product manager giỏi PHẢI trả lời trước khi kỹ sư bắt đầu
thiết kế, chia theo nhóm:
1. Concurrency & race condition
2. Time zone & lịch (VD: reminder hàng tháng vào ngày 31)
3. Failure mode (điều gì xảy ra khi hệ thống down đúng giờ nhắc)
4. Data lifecycle (sửa/xóa reminder đang chờ chạy thì sao)
5. Scale (1 user có thể tạo bao nhiêu reminder, hệ thống chịu
được bao nhiêu reminder đồng thời)
Với mỗi câu hỏi, đề xuất luôn một câu trả lời mặc định hợp lý
(sensible default) nếu stakeholder không có ý kiến.
Ví dụ output thực tế bạn thường nhận được ở mục "Time zone & lịch": AI sẽ hỏi "reminder hàng tháng vào ngày 31 thì tháng 2 xử lý ra sao — dời sang ngày 1/3, hay ngày cuối tháng 2, hay bỏ qua tháng đó?" — một câu hỏi mà 9 trong 10 team bỏ sót cho đến khi user report bug thật.
Điều quan trọng: đừng dừng lại ở việc liệt kê câu hỏi. Hãy yêu cầu AI đề xuất default — vì trong thực tế, bạn không có thời gian hỏi stakeholder từng câu một, và một default hợp lý kèm ghi chú "giả định X, có thể sai, cần xác nhận" tốt hơn nhiều so với việc để trống.
Mẹo: Luôn yêu cầu AI nhóm câu hỏi theo chủ đề (concurrency, time zone, failure mode, scale...) thay vì liệt kê phẳng — cách nhóm này giúp bạn nhận ra ngay mảng nào bạn đang yếu, thường là concurrency và failure mode.
Khám Phá Trade-off Trước Khi Chốt Thiết Kế
System design về bản chất là môn học về trade-off — không có thiết kế nào "đúng tuyệt đối", chỉ có thiết kế phù hợp nhất với một tập ràng buộc cụ thể tại một thời điểm cụ thể. Vấn đề là: con người có xu hướng chốt trade-off quá sớm, thường dựa trên kinh nghiệm gần nhất (dự án trước dùng Kafka nên dự án này cũng Kafka), thay vì phân tích lại từ đầu.
AI có lợi thế ở đây vì nó không có "kinh nghiệm gần nhất" theo nghĩa cảm tính — nó có thể liệt kê một ma trận trade-off khách quan hơn, miễn là bạn cung cấp đủ ngữ cảnh về ràng buộc thật của bạn (đội ngũ, ngân sách, SLA).
Tôi cần chọn giữa: (a) đồng bộ dữ liệu qua polling định kỳ,
(b) qua message queue (RabbitMQ/SQS), (c) qua event streaming
(Kafka), cho bài toán đồng bộ inventory giữa hệ thống warehouse
và website, độ trễ chấp nhận được là 30 giây, throughput ước tính
200 sự kiện/giây lúc cao điểm, team có 4 backend engineer chưa
ai từng vận hành Kafka production.
Dựng bảng so sánh theo các tiêu chí: độ phức tạp vận hành, chi phí
hạ tầng, độ trễ thực tế đạt được, khả năng mở rộng 5x, rủi ro khi
team thiếu kinh nghiệm. Kết luận bằng khuyến nghị có điều kiện
(theo dạng "nếu X đúng thì chọn A, nếu Y đúng thì chọn B").
Điểm mấu chốt cần lưu ý: đừng để AI đưa ra một khuyến nghị "cứng" duy nhất mà không kèm điều kiện. Một thiết kế tốt luôn có dạng "nếu ràng buộc này giữ nguyên thì chọn A, nếu ràng buộc kia thay đổi thì cân nhắc B" — vì đây chính là tư duy mà bạn sẽ cần khi viết ADR (Architecture Decision Record — tài liệu ghi lại quyết định kiến trúc và bối cảnh dẫn đến nó) sau này.
Một bài tập nâng cao: yêu cầu AI định lượng hóa trade-off bằng con số ước lượng thô, dù không chính xác 100%, vì con số buộc mọi người tranh luận cụ thể hơn là mơ hồ. "Chi phí vận hành Kafka thêm khoảng bao nhiêu giờ/tháng cho một team chưa có kinh nghiệm?" — câu trả lời có thể sai lệch, nhưng nó tạo ra một điểm neo (anchor) để tranh luận, thay vì tranh luận cảm tính.
Mẹo: Luôn ép AI trả lời trade-off dưới dạng điều kiện ("nếu... thì...") thay vì khuyến nghị tuyệt đối — đây là format bạn sẽ tái sử dụng trực tiếp khi viết ADR.
Cấu Trúc Một Cuộc Trò Chuyện Thiết Kế Với AI
Một phiên thiết kế hiệu quả với AI không phải là một prompt dài duy nhất — nó là một chuỗi các bước có trình tự, mỗi bước phục vụ một mục đích khác nhau. Nếu bạn nhồi tất cả vào một prompt ("thiết kế cho tôi hệ thống X, xét các trade-off, edge case, và viết luôn code"), bạn sẽ nhận về một câu trả lời nông ở mọi khía cạnh, vì context window (cửa sổ ngữ cảnh) của model bị chia sẻ cho quá nhiều việc cùng lúc, và AI không có cơ hội "dừng lại suy nghĩ" giữa các giai đoạn.
Cấu trúc mà nhiều senior engineer áp dụng thành công, theo kinh nghiệm thực chiến với Claude Code, Cursor và ChatGPT, thường có 5 giai đoạn tuần tự:
- Discovery (khám phá) — AI hỏi bạn, không đề xuất gì. Mục tiêu: lộ ra ràng buộc thật.
- Framing (đóng khung bài toán) — Cùng AI viết lại bài toán thành 3-5 câu súc tích, xác nhận cả hai hiểu đúng như nhau.
- Option generation (sinh phương án) — Yêu cầu AI liệt kê tối thiểu 3 phương án khác biệt về bản chất, không phải 3 biến thể na ná nhau.
- Trade-off analysis (phân tích đánh đổi) — Steelman từng phương án, dựng bảng so sánh có điều kiện.
- Decision & documentation (quyết định & ghi lại) — Chốt phương án, viết ADR ngắn gọn ghi lại lý do và điều kiện có thể khiến quyết định đảo ngược.
Trực quan hóa 5 giai đoạn này giúp bạn nhớ rằng đây là một chuỗi có checkpoint, không phải một câu hỏi trả lời một lần:
flowchart LR
A["1. Discovery<br/>AI hỏi, bạn trả lời"] --> B["2. Framing<br/>Tóm tắt bài toán 3-5 câu"]
B --> C["3. Option generation<br/>Tối thiểu 3 phương án khác biệt"]
C --> D["4. Trade-off analysis<br/>Steelman + bảng so sánh có điều kiện"]
D --> E["5. Decision & documentation<br/>Chốt phương án, viết ADR"]
Chúng ta sẽ làm việc theo 5 giai đoạn cho bài toán thiết kế
"hệ thống notification đa kênh (email/SMS/push)" của tôi:
1) Discovery — bạn hỏi tôi
2) Framing — tóm tắt bài toán
3) Option generation — ít nhất 3 phương án khác biệt
4) Trade-off analysis
5) Decision & ADR
Đừng nhảy giai đoạn. Sau mỗi giai đoạn, hỏi tôi "tiếp tục chứ?"
trước khi qua giai đoạn kế. Bắt đầu giai đoạn 1.
Việc chia giai đoạn tường minh như trên có tác dụng phụ rất đáng giá: nó tạo checkpoint để bạn — con người — dừng lại và suy nghĩ, thay vì cuốn theo tốc độ trả lời của AI. Nhiều kỹ sư giỏi bị AI "cuốn" vào một thiết kế nghe rất thuyết phục chỉ vì nó được trình bày mạch lạc, trôi chảy — chính sự trôi chảy đó là thứ bạn cần cảnh giác, không phải thứ để tin tưởng.
Mẹo: Viết số thứ tự giai đoạn tường minh trong prompt và yêu cầu AI hỏi "tiếp tục chứ?" giữa các giai đoạn — kỹ thuật đơn giản này giảm đáng kể tình trạng bị AI "cuốn" qua bước phân tích trade-off quá nhanh.
Tránh Anchoring Vào Thiết Kế Đầu Tiên Của AI
Anchoring bias (thiên kiến neo) là hiện tượng tâm lý: quyết định đầu tiên bạn thấy sẽ trở thành điểm neo, khiến mọi phương án sau đó bị đánh giá tương đối với nó thay vì đánh giá độc lập. Với AI, hiện tượng này còn nghiêm trọng hơn con người, vì hai lý do: (1) AI trình bày phương án đầu tiên với sự tự tin ngôn ngữ giống hệt phương án thứ năm — không có tín hiệu "tôi không chắc lắm" như đồng nghiệp con người thường có; (2) chính bạn, sau khi đọc một thiết kế nghe hợp lý, sẽ vô thức bắt đầu tìm lý do ủng hộ nó thay vì phản biện nó.
Bạn từng trải qua cảm giác này chưa? Đọc xong đề xuất đầu tiên, thấy "nghe cũng hợp lý", rồi 30 phút sau mới nhận ra bạn đã bỏ qua ba phương án khác tốt hơn — chỉ vì phương án đầu tiên đã "chiếm chỗ" trong đầu bạn.
Ba kỹ thuật cụ thể để chống anchoring:
Thứ nhất, luôn yêu cầu tối thiểu 3 phương án cùng lúc, không hỏi từng cái một. Khi AI phải liệt kê 3 phương án trong cùng một câu trả lời, nó buộc phải phân biệt chúng rõ ràng, và bạn nhìn thấy sự đa dạng ngay từ đầu, không bị neo vào phương án số 1.
Thứ hai, chủ động yêu cầu AI công kích chính đề xuất của nó. Sau khi nhận một thiết kế, đừng hỏi "còn gì cần bổ sung", hãy hỏi thẳng: "giả sử tôi là một staff engineer khó tính, tìm 3 lý do thiết kế này sẽ thất bại trong production."
Bạn vừa đề xuất thiết kế X ở trên. Bây giờ hãy đổi vai: đóng vai
một staff engineer hoài nghi, nhiệm vụ duy nhất là tìm lỗ hổng
trong chính đề xuất đó. Không được nói giảm. Liệt kê:
- 3 tình huống cụ thể khiến thiết kế này thất bại hoặc kém hiệu quả
- Giả định ẩn nào thiết kế đang dựa vào mà chưa được xác nhận
- Nếu phải chọn 1 điều để thay đổi ngay bây giờ, đó là gì
Thứ ba, đặt câu hỏi ngược thời gian. Hỏi AI: "nếu 6 tháng nữa thiết kế này thất bại, nguyên nhân nhiều khả năng nhất là gì?" Kỹ thuật này, đôi khi gọi là pre-mortem (phân tích thất bại trước khi nó xảy ra), thường lôi ra được rủi ro mà phân tích trade-off thông thường bỏ sót, vì nó buộc AI (và bạn) tưởng tượng cụ thể một kịch bản thất bại thay vì liệt kê rủi ro trừu tượng.
Mẹo: Sau mỗi thiết kế AI đề xuất, luôn hỏi thêm một câu pre-mortem: "nếu thiết kế này thất bại sau 6 tháng, lý do nhiều khả năng nhất là gì" — câu hỏi này gần như luôn lôi ra ít nhất một rủi ro bạn chưa nghĩ tới.
Thực Hành: Chạy Một Phiên Khám Phá Yêu Cầu
Phần này mô phỏng một phiên thực chiến — bạn hãy làm theo từng bước với AI coding assistant bạn đang dùng (Claude Code, Cursor, hoặc ChatGPT đều được), cho một bài toán cụ thể: thiết kế tính năng "giỏ hàng dùng chung" (shared cart) cho một ứng dụng đặt đồ ăn theo nhóm.
Bước 1 — Mở phiên discovery, cấm AI đề xuất giải pháp.
Tôi cần thiết kế tính năng "giỏ hàng dùng chung": nhiều người trong
một nhóm cùng thêm món vào một giỏ hàng, sau đó một người thanh toán
chung. Đóng vai staff engineer phỏng vấn tôi. Hỏi từng câu một,
đừng đề xuất giải pháp. Ưu tiên hỏi về concurrency, quyền hạn, và
vòng đời dữ liệu trước.
Output thực tế bạn có thể nhận (rút gọn): "Câu hỏi 1: Khi hai người cùng thêm món cùng lúc, hệ thống cần đảm bảo thứ tự hiển thị nhất quán cho mọi thành viên, hay chỉ cần đảm bảo không mất dữ liệu? Câu hỏi 2: Ai có quyền xóa món người khác thêm — chỉ chủ giỏ hàng, hay bất kỳ ai? Câu hỏi 3: Giỏ hàng có 'hết hạn' không nếu không ai thanh toán trong X giờ?"
Bạn trả lời từng câu (ví dụ: "chỉ cần không mất dữ liệu, không cần thứ tự tuyệt đối"; "chỉ chủ nhóm được xóa món người khác"; "hết hạn sau 2 giờ không hoạt động").
Bước 2 — Yêu cầu AI tóm tắt lại bài toán (framing) để xác nhận hai bên hiểu giống nhau.
Dựa trên các câu trả lời ở trên, tóm tắt bài toán trong 4-5 câu,
liệt kê rõ các ràng buộc non-negotiable. Nếu có điểm nào tôi trả
lời mơ hồ, hỏi lại trước khi tóm tắt.
Bước 3 — Yêu cầu tối thiểu 3 phương án khác biệt về bản chất (chống anchoring theo kỹ thuật ở phần trước).
Đề xuất tối thiểu 3 phương án kỹ thuật khác biệt về bản chất cho
việc đồng bộ giỏ hàng real-time giữa các thành viên (không phải
3 biến thể na ná), ví dụ như: polling, WebSocket với optimistic
update, hoặc CRDT-based merge. Mỗi phương án tối đa 4 câu.
Bước 4 — Steelman + trade-off có điều kiện.
Với 3 phương án trên, dựng bảng trade-off theo: độ phức tạp code,
độ trễ cảm nhận bởi user, rủi ro conflict khi mất mạng tạm thời,
chi phí vận hành. Kết luận theo dạng điều kiện, không chọn 1 đáp
án tuyệt đối.
Bước 5 — Pre-mortem cho phương án bạn nghiêng về chọn.
Giả sử tôi chọn phương án WebSocket + optimistic update. 6 tháng
sau tính năng này gặp sự cố nghiêm trọng nhất trong production.
Nhiều khả năng nhất nguyên nhân là gì? Liệt kê 3 kịch bản cụ thể.
Bước 6 — Chốt bằng một ADR ngắn. Yêu cầu AI viết ADR 1 trang: ngữ cảnh, quyết định, lý do, hệ quả, và điều kiện khiến quyết định này cần được xem xét lại. Đây chính là tài liệu bạn đưa vào review với team — không phải toàn bộ cuộc trò chuyện, mà là bản chưng cất cuối cùng của nó.
Làm hết 6 bước này cho một tính năng cỡ vừa thường mất 20-30 phút — ít hơn nhiều so với một buổi họp thiết kế 1 giờ với 5 người, nhưng chất lượng đầu ra, nếu bạn dẫn dắt đúng, không hề thua kém.
Mẹo: Lưu lại toàn bộ transcript của phiên discovery (không chỉ ADR cuối) vào repo dạng ghi chú — 3 tháng sau khi có người hỏi "tại sao lại chọn thế này", bạn sẽ mừng vì có bằng chứng cho từng câu trả lời, không phải chỉ có kết luận trần trụi.
Những điểm chính
- Đừng để AI nhảy thẳng vào giải pháp — mở đầu bằng discovery, ép AI đóng vai người phỏng vấn để lộ ra ràng buộc thật của bài toán.
- Dùng kỹ thuật steelmanning để buộc AI trình bày phiên bản mạnh nhất của từng phương án, biến câu hỏi nhị phân ("A hay B") thành câu hỏi về điều kiện ("A thắng khi nào, B thắng khi nào").
- Chủ động yêu cầu AI liệt kê yêu cầu chưa nói ra và edge case theo nhóm chủ đề (concurrency, time zone, failure mode, scale), kèm default hợp lý cho mỗi câu hỏi.
- Luôn ép trade-off ở dạng điều kiện ("nếu X thì chọn A") thay vì khuyến nghị tuyệt đối — đây chính là format cần cho ADR sau này.
- Cấu trúc phiên thiết kế thành các giai đoạn tuần tự (discovery, framing, option generation, trade-off analysis, decision), có checkpoint dừng lại giữa mỗi giai đoạn để tránh bị AI "cuốn" đi quá nhanh.
- Chủ động chống anchoring bias bằng cách luôn yêu cầu tối thiểu 3 phương án cùng lúc, yêu cầu AI tự công kích đề xuất của chính nó, và dùng câu hỏi pre-mortem ("nếu thất bại sau 6 tháng, lý do là gì").
- Kết quả cuối của một phiên thiết kế tốt là một ADR ngắn gọn kèm transcript discovery được lưu lại — không phải toàn bộ cuộc trò chuyện, và cũng không phải một quyết định thiếu bối cảnh.