Buổi 2 — Kỹ nghệ yêu cầu và thiết kế hệ thống với AI
AI viết yêu cầu rất nhanh. Đưa cho nó một đoạn bối cảnh nghiệp vụ, chưa đầy một phút nó trả về hai chục user story kèm acceptance criteria.
Vậy tại sao các dự án vẫn phải sửa yêu cầu, hết lần này đến lần khác?
Buổi 2 trả lời câu đó, và câu trả lời làm đổi cách dùng công cụ: thứ giá trị nhất AI làm được trong kỹ nghệ yêu cầu không phải là trả lời — mà là hỏi.
Về bài viết này
Đây là ghi chép của tôi từ Ngày 2 khoá AI-Driven Software Development Life-Cycle, giảng viên TS. Bùi Thị Mai Anh, Trường Công nghệ Thông tin và Truyền thông (SOICT), Đại học Bách Khoa Hà Nội, tháng 7/2026. Khung tư duy và thiết kế workshop là của cô; phần tóm tắt và câu chữ ở đây là của tôi. Các prompt trích bên dưới lấy nguyên từ workbook của khoá học — chúng là của cô, không phải của tôi.
Bài này nối tiếp Buổi 1, nơi đã xác lập rằng ngữ cảnh chung — chứ không phải năng lực model — mới là nút thắt của một vòng đời có AI tham gia. Bài cũng có bản tiếng Anh.
Phần 1 — Kỹ nghệ yêu cầu với AI
Bắt nó hỏi, đừng bắt nó trả lời
Buổi học phát biểu thẳng: AI hỏi đúng thì hiệu quả hơn AI trả lời ngay.
Lý do nối thẳng về Buổi 1. Phần lớn yêu cầu bị thiếu đều bắt nguồn từ thiếu ngữ cảnh. Nếu bạn đòi user story khi ngữ cảnh chưa đủ, bạn sẽ nhận được những story trôi chảy, tự tin, format đẹp — dựng trên các giả định không ai nói ra. Và mỗi giả định đó về sau đều thành rework.
Có một ranh giới cứng mà buổi học nhắc đi nhắc lại:
AI đề xuất được business rule. Nó không xác nhận được. Quy tắc nghiệp vụ và quyết định cuối cùng thuộc về con người.
Sáu bước
Công việc yêu cầu với AI chia thành sáu hoạt động, mỗi hoạt động sinh ra một artifact làm đầu vào cho cái kế tiếp:
- Elicitation — AI giúp khai thác những gì thực sự có trong tài liệu hiện tại
- Clarification — AI sinh ra câu hỏi phơi bày những gì chưa có
- User stories — AI biến yêu cầu đã làm rõ thành story có cấu trúc; con người đánh giá
- Acceptance criteria — để AI, developer và tester cùng hiểu thế nào là xong
- Review — AI đọc lại toàn bộ package để tìm lỗ hổng, chỗ mơ hồ và mâu thuẫn
- Prioritization — AI đề xuất, con người quyết phạm vi
Chuỗi quan trọng hơn từng bước riêng lẻ. Làm rõ trước khi đặc tả là nước đi triệt tiêu rework về sau, vì một giả định chưa xác nhận mà bắt được ở bước 2 thì rẻ, còn cũng giả định đó phát hiện lúc kiểm thử thì không.
Phần 2 — Kiến trúc và thiết kế hệ thống với AI
Requirement package vẫn chưa nói cho bạn điều gì
Bước vào thiết kế, bạn cầm trong tay business problem, user story, acceptance criteria và một backlog đã ưu tiên. Bạn cần component, API, thiết kế dữ liệu, luồng tương tác và lựa chọn công nghệ. Không có gì trong requirement package quyết định được những thứ đó. Thứ quyết định chúng là:
- mục tiêu kinh doanh
- ràng buộc kỹ thuật
- các tiêu chuẩn chất lượng
Tư duy kiến trúc là ra quyết định, không phải vẽ hình
Định nghĩa của buổi học: tư duy kiến trúc là quá trình ra quyết định có hệ thống. Cách đóng khung đó quy định luôn cách dùng AI — không phải "sinh cho tôi một kiến trúc", mà "giúp tôi khám phá, đánh giá và quyết định".
Nên luồng thiết kế cố tình yêu cầu AI đưa ra ít nhất ba phương án thay vì một. Ví dụ trong bài: monolithic (đơn giản, triển khai nhanh, chi phí thấp, hợp đội nhỏ), modular (tách module rõ, dễ bảo trì, ít phức tạp hơn microservices, hợp quy mô trung bình), microservices (mở rộng tốt, triển khai độc lập, công nghệ đa dạng, hợp hệ thống lớn tăng trưởng cao).
Rồi đến câu chi phối toàn bộ bài tập:
Không có kiến trúc tốt nhất. Chỉ có kiến trúc phù hợp nhất với bài toán này.
Đó là lý do bước tiếp theo là phân tích trade-off tường minh, không phải bỏ phiếu.
Ranh giới của con người trong thiết kế
Cách chia lặp lại Buổi 1, nhưng sâu hơn một tầng:
| Hoạt động | AI | Con người |
|---|---|---|
| Thiết kế component | Đề xuất component, trách nhiệm, ranh giới; gợi ý tách/gộp | Quyết định ranh giới và trách nhiệm thực tế |
| Thiết kế tương tác | Đề xuất cách các component giao tiếp | Xác nhận phù hợp nghiệp vụ, chọn cơ chế giao tiếp, chịu trách nhiệm yêu cầu phi chức năng, xử lý lỗi và ranh giới giao dịch |
| Security & reliability | Phát hiện rủi ro, đề xuất biện pháp giảm thiểu | Chấp nhận hay từ chối rủi ro, chọn cách xử lý |
| Architecture review | Kiểm tra độ bao phủ và tính nhất quán | Ký duyệt trước khi bắt đầu phát triển |
Phần 3 — Context Engineering
Đây là ý mới thực sự của Buổi 2, và là lời giải mang tính vận hành cho bài toán context drift của Buổi 1.
Khi đã có đầy đủ requirement context cộng với ngữ cảnh hệ thống hiện tại — schema, API hiện có, kiến trúc hiện có — phản xạ ngây thơ là dán tất cả vào mọi prompt. Buổi học đặt tên cho nước đi tốt hơn: với mỗi tác vụ, chỉ truy xuất phần liên quan để dựng một task-specific context.
Workshop thẳng thắn về chỗ đơn giản hoá: trong doanh nghiệp thật, đây sẽ là một hệ thống tri thức dạng RAG tự động truy xuất. Trong phạm vi workshop, nhóm đưa cho AI toàn bộ context và yêu cầu nó tự chọn phần liên quan trước mỗi tác vụ — cách này xấp xỉ được, và tiện ở chỗ nó làm việc chọn lọc hiện ra để con người sửa.
Workshop: các bước thực hiện
Case study của Buổi 1 mới là phác thảo. Của Buổi 2 là một hệ thống đang chạy.
MedBook
MedBook là hệ thống đặt lịch khám đang vận hành: quản lý bệnh nhân, quản lý bác sĩ, đặt lịch, huỷ lịch, đổi lịch, quản lý lịch làm việc của bác sĩ, thông báo. Workbook đưa cho nhóm cả chi tiết hiện thực — sáu bảng PostgreSQL (patients, users, specializations, doctors, slots, appointments), bề mặt REST API (POST /appointments, GET /my-appointments, POST /appointments/:id/confirm, POST /appointments/:id/cancel, các endpoint quản lý slot), và một partial unique index tên one_active_appointment_per_slot bảo đảm mỗi slot chỉ có một lịch hẹn đang hoạt động.
Nhóm cũng nhận luôn bộ business rule, và chúng cụ thể đủ để ràng buộc thiết kế: chỉ đặt được slot ở trạng thái available (slot đã đặt trả về 409); đặt lịch thành công thì appointment thành booked và slot thành booked, huỷ thì slot trở lại available; bệnh nhân chỉ huỷ được lịch của mình còn nhân viên huỷ được của bất kỳ ai; chỉ nhân viên mới xác nhận (booked → confirmed); cancelled là trạng thái cuối; không mở lại slot đang còn lịch hẹn hoạt động; hệ thống có đúng hai vai trò — bệnh nhân và nhân viên — và bác sĩ là dữ liệu, không phải người dùng.
Yêu cầu thay đổi vẫn là cái của Buổi 1, nay sắc hơn: Dynamic Appointment Rescheduling & Waiting List Management. Khung giờ trống bị bỏ phí trong khi bệnh nhân vẫn đang chờ, vì nhân viên phải rà tay danh sách chờ, so từng bệnh nhân, gọi từng người, xử lý phản hồi, rồi cập nhật lịch.
Ràng buộc chi phối mọi thứ: bạn không thiết kế lại MedBook. Tái sử dụng module và API hiện có, giảm thiểu ảnh hưởng tới chức năng đang chạy, tránh thay đổi database không cần thiết, và giữ khả năng truy vết từ yêu cầu sang quyết định thiết kế.
Activity 1 — Khám phá yêu cầu với AI (35 phút)
AI đóng vai AI-Assisted Business Analyst. Nó được tóm tắt, phân tích, phát hiện lỗ hổng, đặt câu hỏi làm rõ, đề xuất user story và acceptance criteria, chỉ ra chỗ mơ hồ hay mâu thuẫn. Nó không chịu trách nhiệm cuối cùng cho bất kỳ quyết định nào.
Bước 0 — AI-Readiness Check. Trước khi prompt bất cứ thứ gì, hãy chấm xem bạn đang có gì. Mười một loại thông tin — mục tiêu nghiệp vụ, vấn đề cần giải, quy trình hiện tại, chức năng MedBook hiện có, API/service hiện có, các bên liên quan, quy tắc nghiệp vụ, quy tắc chọn bệnh nhân trong danh sách chờ, ràng buộc kỹ thuật, tiêu chí thành công, tình huống ngoại lệ — mỗi loại đánh dấu đã rõ / có một phần / chưa rõ. Rồi nêu ba thông tin thiếu quan trọng nhất và vì sao.
Bước này chính là toàn bộ Buổi 1 biến thành một checklist.
Bước 1 — Dựng Business Context. AI đóng vai senior BA và tạo ra Business Problem Canvas: vấn đề nghiệp vụ, pain point, mục tiêu, stakeholder, giá trị kỳ vọng, in scope, out of scope, ràng buộc, tiêu chí thành công. Prompt siết rất chặt — chỉ dùng thông tin có trong case study, không tự tạo business rule mới, và mọi nội dung chưa đủ căn cứ phải đánh dấu "cần xác nhận".
Human checkpoint: context đã phản ánh đúng bài toán chưa? AI bỏ sót gì? Giả định nào cần stakeholder xác nhận?
Prompt — Business Context
Bạn là một Senior Business Analyst.
Task Goal: hiểu bài toán nghiệp vụ của chức năng
Dynamic Appointment Rescheduling & Waiting List Management.
Trước khi đề xuất yêu cầu, hãy:
- Xây dựng Business Context từ hiện trạng hệ thống MedBook.
- Xác định các thông tin liên quan trực tiếp tới bài toán.
- Tóm tắt bài toán thành Business Problem Canvas.
Yêu cầu:
- Chỉ sử dụng thông tin có trong case study.
- Không tự tạo Business Rules mới.
- Những nội dung chưa đủ căn cứ phải được đánh dấu "Cần xác nhận".Bước 2 — Requirement Clarification. AI phân tích context để tìm information gap và đề xuất câu hỏi — bị cấm tường minh việc đề xuất giải pháp hay sinh user story. Với mỗi câu hỏi phải nêu rõ thiếu thông tin gì, vì sao quan trọng, và stakeholder nào nên trả lời. Đầu ra là Requirement Clarification Log có cột trạng thái (Answered / Open).
Các khía cạnh gợi ý để đào: quy tắc chọn bệnh nhân, quyền của từng actor, xử lý phản hồi của bệnh nhân, thời gian chờ phản hồi, trường hợp đồng hạng ưu tiên, nhiều khung giờ cùng khả dụng, xung đột lịch, thông báo, ngoại lệ, quyền riêng tư và bảo mật, tiêu chí thành công.
Prompt — Requirement Clarification
Bạn là một Senior Business Analyst.
Task Goal: làm rõ các yêu cầu còn thiếu của chức năng
Dynamic Appointment Rescheduling & Waiting List Management.
Trước khi xây dựng User Stories:
- Phân tích Business Context.
- Xác định các Information Gaps còn tồn tại.
- Đề xuất các câu hỏi cần làm rõ với stakeholder.
Không đề xuất giải pháp.
Không sinh User Stories.
Không giả định Business Rules chưa được xác nhận.
Đối với mỗi câu hỏi, hãy chỉ rõ:
- Thiếu thông tin gì.
- Vì sao thông tin này quan trọng.
- Stakeholder nào nên xác nhận.Bước 3 — User Stories. Nhóm theo actor, mỗi story một mục tiêu, phát triển và kiểm thử độc lập được, không chứa business rule chưa xác nhận, và mọi story dựa trên giả định đều phải được đánh dấu.
Prompt — User Stories
Bạn là Senior Business Analyst.
Dựa trên Business Problem Canvas và Requirement Clarification Log (đã được xác
nhận), hãy xây dựng các User Stories cho chức năng Dynamic Appointment
Rescheduling and Waiting List Management.
Yêu cầu:
- Nhóm theo actor: Patient, Doctor, Medical Staff, System Administrator.
- Mỗi User Story chỉ mô tả một mục tiêu chính.
- Không tự quyết các Business Rules chưa được xác nhận.
- Đánh dấu rõ User Story nào phụ thuộc vào Assumption hoặc Open Question.
- Ưu tiên các User Stories cần thiết để tạo Minimum Viable Product.Bước 4 — Acceptance Criteria. Chọn ba story quan trọng nhất và viết tiêu chí Given–When–Then bao phủ happy path, ít nhất một alternative flow, ít nhất một exception, cộng các tình huống cụ thể: bệnh nhân từ chối, bệnh nhân không phản hồi kịp, khung giờ không còn khả dụng. Chỗ nào chưa rõ thì gắn Open Question chứ không đoán.
Prompt — Acceptance Criteria
Bạn là Senior Business Analyst.
Dựa trên User Story và các Business Rules đã được xác nhận, hãy xây dựng
Acceptance Criteria theo định dạng Given - When - Then.
Yêu cầu:
- Bao phủ Happy Path.
- Có ít nhất 01 Alternative Flow.
- Có ít nhất 01 Exception.
- Bao gồm trường hợp bệnh nhân từ chối.
- Bao gồm trường hợp bệnh nhân không phản hồi trong thời gian quy định.
- Bao gồm trường hợp khung giờ khám không còn khả dụng.
- Chỉ sử dụng các Business Rules đã được xác nhận.
- Những nội dung chưa rõ phải được đánh dấu "Open Question", không tự suy diễn.Bước 5 — Requirement Review và Gap Analysis. AI đọc lại toàn bộ package với vai trò BA và architect, truy tìm yêu cầu thiếu, chỗ mơ hồ, mâu thuẫn, user story trùng lặp, giả định chưa xác nhận, edge case chưa xử lý, yêu cầu không khớp hệ thống hay API hiện có, thiếu yêu cầu phi chức năng, và rủi ro privacy/security/fairness. Nó không được phép sửa gì — chỉ nêu vấn đề, phân tích tác động, và chỉ ra cái gì cần xác nhận.
Prompt — Requirement Review
Bạn là Senior Business Analyst và Software Architect.
Hãy review toàn bộ Requirement Package và xác định các vấn đề có thể ảnh hưởng
đến quá trình thiết kế và phát triển hệ thống.
Kiểm tra các nội dung sau:
- Yêu cầu còn thiếu (Missing Requirements).
- Nội dung mơ hồ hoặc chưa rõ ràng (Ambiguous Requirements).
- Yêu cầu mâu thuẫn (Conflicting Requirements).
- User Stories trùng lặp hoặc chồng chéo.
- Assumptions và Open Questions chưa được xác nhận.
- Edge Cases chưa được xử lý.
- Yêu cầu chưa phù hợp với hệ thống hoặc API/Service hiện có.
- Thiếu yêu cầu phi chức năng (Performance, Security, Privacy, Reliability...).
- Rủi ro về Privacy, Security và Fairness.
- Những nội dung cần stakeholder đưa ra quyết định.
Không tự sửa Business Rules hoặc Requirement. Chỉ nêu vấn đề, phân tích tác động
và đề xuất các câu hỏi hoặc nội dung cần được xác nhận.Bước 6 — Prioritization. MoSCoW, AI đề xuất còn nhóm quyết. Các câu hỏi thảo luận mới là trọng tâm: AI và người chọn khác nhau ở đâu, vì sao? Quyết định ưu tiên nào phụ thuộc vào giá trị nghiệp vụ mà AI không nhìn thấy?
Prompt — Ưu tiên theo MoSCoW
Bạn là Senior Business Analyst.
Dựa trên Requirement Package, hãy đề xuất mức độ ưu tiên cho từng User Story
theo phương pháp MoSCoW.
Khi đánh giá, xem xét các yếu tố sau:
- Business Value.
- Mức độ cần thiết đối với luồng nghiệp vụ chính.
- Phụ thuộc giữa các User Stories.
- Rủi ro nếu không triển khai.
- Khả năng tận dụng API/Service hiện có.
- Độ phức tạp triển khai (ước tính).
Không đưa ra quyết định cuối cùng.
Hãy giải thích ngắn gọn lý do cho từng mức ưu tiên và nêu rõ những trường hợp
cần Human xem xét.Đầu ra được giữ dưới dạng markdown để cả người lẫn AI cùng dùng được: BusinessProblem.md, BusinessRules.md, UserStories.md, AcceptanceCriteria.md, RequirementReview.md, PrioritizedBacklog.md.
Activity 2 — Kiến trúc và thiết kế hệ thống với AI (40–45 phút)
Đầu vào: requirement package đã ưu tiên. Đầu ra: Architecture Blueprint.
Bước 1 — Impact Analysis. Dựng task-specific context, rồi xác định cái gì tái sử dụng được, cái gì phải mở rộng, cái gì thực sự mới, API và dữ liệu nào bị ảnh hưởng, luồng và integration point nào bị chạm, và rủi ro là gì. Đầu ra là Impact Analysis Matrix chấm từng user story theo loại thay đổi (Reuse / Extend / New / Replace) và mức tác động.
Prompt — Impact Analysis
Bạn là Software Architect đang phân tích tác động của một requirement change
trên hệ thống MedBook.
Trước tiên, từ Requirement Context và Current System Context, hãy lựa chọn và
tổng hợp các thông tin liên quan để xây dựng Task-specific Context cho nhiệm vụ
Impact Analysis, bao gồm:
- Prioritized User Stories liên quan.
- Acceptance Criteria liên quan.
- Business Rules ảnh hưởng đến thiết kế.
- Existing Modules và Services liên quan.
- Existing APIs liên quan.
- Database entities hoặc dữ liệu liên quan.
- Technical, Security và Privacy Constraints.
- Open Questions hoặc Assumptions cần lưu ý.
Sau đó, dựa trên Task-specific Context, hãy thực hiện Impact Analysis và xác định:
- Thành phần có thể tái sử dụng.
- Thành phần cần mở rộng hoặc thay đổi.
- Thành phần mới cần bổ sung.
- API cần thêm hoặc điều chỉnh.
- Dữ liệu cần bổ sung hoặc thay đổi.
- Luồng nghiệp vụ và integration point bị ảnh hưởng.
- Dependency giữa các thành phần.
- Rủi ro do thay đổi gây ra.
Không đề xuất thiết kế lại toàn bộ hệ thống.
Ưu tiên tái sử dụng các module, service, API và cấu trúc dữ liệu hiện có khi
phù hợp.
Không tự tạo Business Rules hoặc Requirement mới. Những nội dung chưa rõ phải
được đánh dấu "Cần xác nhận".Bước 2 — Architecture Exploration. Ít nhất ba phương án mở rộng — không phải thiết kế lại. Mỗi phương án phải tối đa hoá tái sử dụng, mô tả cách tích hợp với kiến trúc hiện tại, và nêu chiến lược xử lý concurrency, consistency và failure recovery, kèm ưu điểm, hạn chế, trade-off, rủi ro, và điều kiện để phương án đó là lựa chọn đúng.
Prompt — Architecture Exploration
Bạn là Software Architect chịu trách nhiệm mở rộng hệ thống MedBook để hỗ trợ
chức năng Dynamic Appointment Rescheduling and Waiting List Management.
Hệ thống MedBook đã có kiến trúc và các chức năng đang vận hành. Mục tiêu của
bạn không phải thiết kế lại toàn bộ hệ thống, mà là đề xuất các phương án mở
rộng (architecture evolution) với mức thay đổi tối thiểu.
Dựa trên Task-specific Context, Impact Analysis và Current System Context, hãy
đề xuất ít nhất 03 phương án kiến trúc khác nhau.
Với mỗi phương án, hãy:
- Tận dụng tối đa các component, service, API và database hiện có.
- Chỉ bổ sung hoặc thay đổi những thành phần thực sự cần thiết.
- Mô tả kiến trúc mức cao và các thành phần bị ảnh hưởng.
- Giải thích cách tích hợp với kiến trúc hiện tại.
- Mô tả chiến lược xử lý Concurrency, Consistency và Failure Recovery.
- Phân tích ưu điểm, hạn chế, trade-offs và rủi ro của từng phương án.
- Nêu điều kiện phù hợp để áp dụng từng phương án.
Trong quá trình đề xuất, hãy ưu tiên:
- Khả năng tái sử dụng các thành phần hiện có.
- Giảm thiểu ảnh hưởng đến các chức năng đang vận hành.
- Hạn chế thay đổi database và public APIs nếu không thực sự cần thiết.
- Duy trì tính tương thích ngược (backward compatibility).
- Đảm bảo hệ thống có thể mở rộng và dễ bảo trì trong tương lai.
Không lựa chọn phương án cuối cùng thay cho con người.Bước 3 — Đánh giá và quyết định. Chấm mỗi phương án 1–5 trên mười tiêu chí: phù hợp kiến trúc hiện tại, độ phức tạp triển khai, khả năng bảo trì, khả năng mở rộng, độ tin cậy, security & privacy, chi phí vận hành, khả năng rollback, phù hợp với năng lực đội, và thời gian triển khai.
Rồi đến nước đi tôi thích nhất trong cả workbook — một prompt phản biện thứ hai:
Đóng vai một Software Architecture Reviewer độc lập. Hãy phản biện kết quả đánh giá ở trên: chỉ ra các giả định chưa hợp lý, các rủi ro còn bỏ sót, những trường hợp mà phương án khác sẽ phù hợp hơn, và các câu hỏi architect nên xem xét trước khi quyết.
Bắt model cãi lại chính đề xuất của nó là cách rẻ và trực tiếp để chống lại việc AI sẵn sàng hợp lý hoá bất cứ thứ gì nó đưa ra đầu tiên.
Prompt — Đánh giá kiến trúc
Bạn là Software Architect của hệ thống MedBook.
Dựa trên Impact Analysis và 03 phương án kiến trúc đã đề xuất, hãy đánh giá từng
phương án theo các tiêu chí sau:
- Mức độ phù hợp với kiến trúc hiện tại
- Độ phức tạp triển khai
- Khả năng bảo trì
- Khả năng mở rộng
- Độ tin cậy (Reliability)
- Security & Privacy
- Chi phí vận hành
- Khả năng rollback
- Mức độ phù hợp với năng lực hiện tại của đội ngũ
- Thời gian triển khai
Đối với mỗi tiêu chí:
- Chấm điểm từ 1 (thấp) đến 5 (cao).
- Giải thích ngắn gọn lý do đánh giá.
- Chỉ ra các rủi ro hoặc giả định cần lưu ý.
Cuối cùng:
- Xếp hạng các phương án theo mức độ phù hợp.
- Phân tích các trade-offs của từng phương án.
- Chỉ ra những quyết định cần Software Architect xem xét thay vì để AI tự quyết.
- Nêu các thông tin còn thiếu để có thể đưa ra quyết định cuối cùng.Prompt — Phản biện
Đóng vai một Software Architecture Reviewer độc lập.
Hãy phản biện kết quả đánh giá ở trên bằng cách:
- Chỉ ra các giả định chưa hợp lý.
- Phát hiện các rủi ro còn bỏ sót.
- Nêu những trường hợp mà một phương án khác sẽ phù hợp hơn.
- Đề xuất các câu hỏi mà Software Architect nên xem xét trước khi đưa ra quyết
định cuối cùng.Bước 4 — Thiết kế component và trách nhiệm. Với mỗi component: vai trò (Reuse / Extend / New), trách nhiệm chính, business rule nào nó sở hữu, nó nói chuyện với ai, input và output. Rồi kiểm tra component nào đang ôm quá nhiều việc, kèm một quy tắc đáng học — mỗi business rule chỉ thuộc đúng một component. Sau đó là một lượt phản biện nữa, chấm theo SRP, cohesion, coupling, khả năng tái sử dụng, mở rộng và bảo trì.
Prompt — Thiết kế component
Bạn là Software Architect của hệ thống MedBook.
Dựa trên Architecture Decision, hãy thiết kế các component để hiện thực hóa chức
năng Dynamic Appointment Rescheduling and Waiting List Management.
Đối với mỗi component, hãy xác định:
- Vai trò (Reuse / Extend / New)
- Trách nhiệm chính (Responsibilities)
- Business Rules mà component chịu trách nhiệm
- Component hoặc Service tương tác
- Input
- Output
Đồng thời:
- Kiểm tra xem component nào đang đảm nhận quá nhiều trách nhiệm.
- Đề xuất tách hoặc gộp component nếu cần.
- Đảm bảo mỗi Business Rule chỉ thuộc về một component.
- Giải thích ngắn gọn lý do của các quyết định thiết kế.
Nếu cần làm rõ một component hoặc interface hiện có, hãy tham khảo Current
System Context.Prompt — Phản biện
Đóng vai Software Architecture Reviewer.
Đánh giá thiết kế component theo các tiêu chí sau:
- Single Responsibility Principle (SRP)
- Cohesion
- Coupling
- Khả năng tái sử dụng
- Khả năng mở rộng
- Khả năng bảo trì
Nếu phát hiện vấn đề:
- Chỉ rõ component chưa hợp lý.
- Giải thích nguyên nhân.
- Đề xuất phương án cải tiến.Bước 5 — Thiết kế API và tương tác. Xoay quanh một luồng cụ thể: một slot trở nên khả dụng, hệ thống chọn bệnh nhân phù hợp, gửi offer, và xử lý phản hồi. Bốn task — dựng business flow context (mục tiêu, trigger, actor, story, tiêu chí, rule, pre/postcondition, alternative và exception flow, câu hỏi mở); thiết kế luồng tương tác từng bước; định nghĩa API và event contract đánh dấu Existing / Modified / New với ưu tiên tái sử dụng; rồi phân tích hành vi runtime — timeout, retry policy, xử lý lỗi, kiểm soát đồng thời, idempotency, rollback và compensation.
Prompt — Thiết kế API & tương tác
Bạn là Solution Architect của hệ thống MedBook.
Dựa trên Requirement Context và Component Design, hãy thiết kế API và luồng
tương tác cho chức năng: khi một slot khám trở nên khả dụng, hệ thống lựa chọn
bệnh nhân phù hợp, gửi offer và xử lý phản hồi của bệnh nhân.
Task 1 - Build Business Flow Context
Từ Requirement Context, hãy truy xuất các thông tin liên quan đến luồng nghiệp
vụ trên. Xác định: Business Goal, Trigger, Actors, User Stories liên quan,
Acceptance Criteria, Business Rules, Preconditions, Postconditions, Alternative
Flows, Exception Conditions, Open Questions.
Nếu thiếu thông tin, ghi rõ "Cần xác nhận", không tự giả định.
Task 2 - Design Interaction Flow
Với mỗi bước, hãy xác định: Actor hoặc Component thực hiện, hành động, API hoặc
Event được sử dụng, Input, Output, trạng thái được tạo hoặc thay đổi.
Phân biệt rõ Main Flow, Alternative Flow và Exception Flow.
Task 3 - Design API and Event Contracts
Đối với mỗi API hoặc Event: Existing / Modified / New, Provider, Consumer,
Purpose, Request hoặc Event Payload, Response hoặc Output, Error Response.
Ưu tiên tái sử dụng API hiện có trước khi đề xuất API mới.
Task 4 - Analyze Runtime Behaviors
Đối với từng interaction quan trọng, hãy phân tích: Timeout, Retry Policy, Error
Handling, Concurrency Control, Idempotency, Rollback hoặc Compensation.
Nếu phát hiện rủi ro hoặc điểm nghẽn, hãy đề xuất cải tiến.Bước 6 — Thiết kế dữ liệu và trạng thái. Tái sử dụng hoặc mở rộng trước khi thêm mới. Task con thú vị nhất là quyết định offer rốt cuộc là cái gì: AppointmentOffer nên là một entity riêng, một phần mở rộng của entity sẵn có, hay chỉ là một trạng thái trên entity sẵn có? Rồi thiết kế máy trạng thái — trạng thái hiện tại, sự kiện kích hoạt, điều kiện, hành động, trạng thái kế tiếp, transition không hợp lệ, trạng thái cuối — bao phủ accepted, rejected, expired, cancelled, timeout, offer bị thay thế, slot đã được người khác xác nhận, và event bị gửi lặp.
Prompt — Thiết kế dữ liệu & trạng thái
Bạn là Data Architect của hệ thống MedBook.
Dựa trên Requirement Context, Current Data Model, Component Design và Interaction
Flow, hãy thiết kế phần mở rộng dữ liệu và trạng thái cần thiết cho chức năng
Dynamic Appointment Rescheduling and Waiting List Management.
Task 1 - Build Data Design Context
Truy xuất: Business Rules ảnh hưởng đến dữ liệu, Acceptance Criteria liên quan
đến trạng thái và lưu trữ, existing entities và attributes có thể tái sử dụng,
existing relationships, data constraints, audit/privacy/retention requirements,
và những thông tin còn thiếu cần xác nhận.
Không tự giả định khi thông tin chưa được cung cấp.
Task 2 - Identify Data Model Changes
Xác định: entity hiện có được tái sử dụng, entity cần mở rộng, entity mới, thuộc
tính mới, quan hệ mới hoặc cần thay đổi, constraint và uniqueness rule, dữ liệu
phục vụ concurrency, idempotency và audit.
Với mỗi thay đổi, mô tả: Change Type (Reuse / Extend / New), mục đích, thuộc
tính chính, trạng thái hoặc vòng đời, quan hệ với entity khác, component sở hữu,
các ràng buộc dữ liệu.
Không tạo entity mới nếu có thể mở rộng hoặc tái sử dụng entity hiện có một cách
hợp lý.
Task 3 - Design State Transition
Trước tiên, hãy xác định đối tượng phù hợp để quản lý vòng đời của một offer đặt
lịch. AppointmentOffer nên là một entity độc lập, một phần mở rộng của entity
hiện có, hay một trạng thái của entity hiện có?
Sau khi xác định, hãy thiết kế State Transition gồm: Current State, Triggering
Event, Transition Condition, Action hoặc dữ liệu được cập nhật, Next State,
Invalid Transition, Terminal State.
Phải xem xét: Accepted, Rejected, Expired, Cancelled, Timeout, offer được thay
thế, slot đã được bệnh nhân khác xác nhận, event bị gửi hoặc xử lý lặp lại.
Task 4 - Review Data Integrity and Lifecycle
Kiểm tra: có trùng lặp với dữ liệu hiện có không, có thiếu entity/thuộc tính/
quan hệ không, có trạng thái không thể đạt tới hoặc không thể thoát ra không, có
transition không hợp lệ chưa được kiểm soát không, có nguy cơ cập nhật đồng thời
hoặc mất dữ liệu không, có hỗ trợ idempotency và optimistic locking không, có đủ
timestamp và audit information không, có lưu dữ liệu nhạy cảm không cần thiết
không, có chính sách retention hoặc deletion phù hợp không.
Nếu phát hiện vấn đề, hãy đề xuất cải tiến và ghi rõ phần cần con người xác nhận.Bước 7 — Security và Reliability Review. Xét trên security & privacy, concurrency & data consistency, xử lý lỗi & phục hồi, và rủi ro nghiệp vụ. Để chặn model trả lời chung chung, ba tình huống là bắt buộc:
- Hai bệnh nhân chấp nhận cùng một slot gần như đồng thời
- Notification gửi thất bại nhưng offer vẫn đang đếm giờ
- Bệnh nhân chấp nhận offer sau khi offer đã hết hạn
Mỗi rủi ro nhận một mức tác động, một biện pháp giảm thiểu, và cờ đánh dấu có cần con người quyết hay không.
Prompt — Security & Reliability Review
Dựa trên Requirement Context và Design Context, hãy review thiết kế theo bốn
góc nhìn:
- Security & Privacy
- Concurrency & Data Consistency
- Failure Handling & Recovery
- Business Risks
Với mỗi rủi ro, hãy xác định:
- Mô tả rủi ro.
- Thành phần hoặc luồng bị ảnh hưởng.
- Mức độ ảnh hưởng (High / Medium / Low).
- Biện pháp giảm thiểu.
- Có cần Human quyết định hay không.
Không thay đổi Business Rules. Nếu thiếu thông tin, hãy ghi rõ Open Question.
Ba tình huống bắt buộc phải xem xét:
- Hai bệnh nhân chấp nhận cùng một slot gần như đồng thời.
- Notification gửi thất bại nhưng offer vẫn đang đếm thời gian.
- Bệnh nhân chấp nhận offer sau khi offer đã hết hạn.Bước 8 — Requirement Traceability Review. Mọi yêu cầu phải ánh xạ tới ít nhất một component, mọi acceptance criteria phải truy vết được về thiết kế, không business rule nào bị bỏ rơi, và không component nào tồn tại mà không có yêu cầu đứng sau. Cái kiểm tra cuối — component thừa — là thứ người ta hay bỏ qua, và đó là cách bắt được thiết kế vẽ vời.
Câu hỏi khép lại phần deliverable là câu sắc nhất workbook: nếu giao bộ tài liệu này cho một AI developer, nó đã đủ ngữ cảnh để phát triển chưa? Tóm tắt lại những gì đang có, và highlight những gì còn thiếu.
Prompt — Traceability Review
Bạn là Software Architecture Reviewer.
Dựa trên Requirement Context và Design Context, hãy đánh giá mức độ đáp ứng của
thiết kế đối với các yêu cầu ban đầu.
Đối với mỗi Requirement hoặc User Story, hãy xác định:
- Component chịu trách nhiệm.
- Requirement đã được đáp ứng hay chưa.
- Acceptance Criteria đã được hỗ trợ hay chưa.
- Business Rules có bị bỏ sót không.
- Có component nào không phục vụ requirement nào không.
Cuối cùng hãy liệt kê:
- Missing Requirements
- Missing Acceptance Criteria
- Missing Business Rules
- Unused Components
- Open Questions
- Improvement SuggestionsPhần 4 — Spec như một giao diện
Và đó là cách buổi học kết lại. Nối chuỗi artifact đó lại — từ yêu cầu sang kiến trúc — bạn có cái mà khoá học gọi là AI-Ready Specification: nền tảng để AI sinh code, sinh test và sinh tài liệu phát triển.
Spec không còn là tài liệu. Spec trở thành giao diện làm việc giữa con người và AI.
Đó là toàn bộ mạch của Buổi 1 và Buổi 2 gói trong một câu. Buổi 1 chẩn đoán việc mất ngữ cảnh giữa các phase. Câu trả lời của Buổi 2 không phải "prompt cho khéo hơn" — mà là biến ngữ cảnh thành một chuỗi artifact hạng nhất, có phiên bản, review được, để mọi phase và mọi trợ lý cùng đọc từ đó.
Tôi rút ra được gì
Clarification là prompt có đòn bẩy cao nhất bạn sẽ viết. Bảo AI sinh câu hỏi trước khi sinh story tốn thêm đúng một bước, và triệt tiêu cả một lớp rework sinh ra từ những output tự tin dựng trên giả định không ai nói ra.
Đòi ba phương án, rồi bắt nó tấn công chính câu trả lời của mình. Yêu cầu nhiều phương án giúp bạn không neo vào thiết kế đầu tiên; prompt phản biện giúp model không bảo vệ nó.
Context engineering là chọn lọc, không phải tích trữ. Có một kho tri thức lớn không đồng nghĩa với việc đổ nguyên nó vào mọi prompt. Kỹ năng nằm ở chỗ chọn đúng lát cắt cho từng tác vụ.
"Cần xác nhận" là một tính năng. Gần như mọi prompt trong workbook đều yêu cầu model đánh dấu nội dung chưa đủ căn cứ thay vì lấp vào. Chỉ một chỉ dẫn đó thôi đã biến việc bịa trong im lặng thành một mục checklist nhìn thấy được.