Độ rõ ràng Prompt ảnh hưởng tới Kiến trúc, Mô hình Dữ liệu và Khả năng Bảo trì

Ý nghĩa của Độ Rõ ràng Prompt (và vì sao nó quan trọng)

"Độ rõ ràng prompt" nghĩa là diễn đạt điều bạn muốn theo cách để lại ít chỗ cho cách hiểu khác nhau. Trong sản phẩm, điều đó biểu hiện bằng các kết quả rõ ràng, người dùng, ràng buộc và thước đo thành công. Trong kỹ thuật, nó trở thành các yêu cầu rõ ràng: đầu vào, đầu ra, quy tắc dữ liệu, hành vi lỗi và kỳ vọng phi chức năng (hiệu năng, bảo mật, tuân thủ).

Chuỗi phản ứng: prompt → mã

Prompt không chỉ là văn bản bạn đưa cho AI hay đồng đội. Nó là hạt giống cho toàn bộ bản dựng:

• Prompt diễn đạt ý định (vấn đề ta giải quyết và lý do).
• Yêu cầu dịch ý định thành các phát biểu có thể kiểm thử.
• Quyết định thiết kế biến yêu cầu thành lựa chọn kiến trúc (dịch vụ, ranh giới, API, lưu trữ dữ liệu).
• Mã triển khai những lựa chọn đó—bao gồm cả các giả định được đưa ra dọc đường.

Khi prompt rõ ràng, các artefact phía sau thường đồng bộ hơn: ít tranh luận về “chúng ta định nghĩa gì,” ít thay đổi phút chót và ít bất ngờ ở các trường hợp biên.

Tại sao mơ hồ lại tốn kém

Prompt mơ hồ buộc con người (và AI) phải tự bù đắp bằng giả thiết—và các giả thiết đó hiếm khi trùng khớp giữa các vai trò. Một người tưởng “nhanh” là phản hồi dưới 1 giây; người khác nghĩ “đủ nhanh” cho báo cáo hàng tuần. Người A nghĩ “khách hàng” bao gồm người dùng thử; người B lại loại trừ họ.

Sự không khớp đó tạo ra làm lại: thiết kế bị sửa sau khi bắt đầu triển khai, mô hình dữ liệu cần di trú, API sinh ra thay đổi phá vỡ, và kiểm thử không bắt được tiêu chí chấp nhận thực tế.

Rõ ràng giúp, nhưng không phải phép màu

Prompt rõ ràng cải thiện đáng kể khả năng đạt được kiến trúc sạch, mô hình dữ liệu đúng và mã dễ bảo trì—nhưng không đảm bảo. Bạn vẫn cần rà soát, đánh đổi và lặp. Điểm khác biệt là độ rõ ràng làm cho các cuộc trao đổi đó trở nên cụ thể (và rẻ hơn) trước khi các giả định cứng lại thành nợ kỹ thuật.

Độ rõ ràng lan truyền đến chất lượng kiến trúc như thế nào

Khi prompt mơ hồ, nhóm (người hoặc AI) sẽ bù đắp bằng giả thiết. Những giả thiết đó cứng lại thành thành phần, ranh giới dịch vụ và luồng dữ liệu—thường là trước khi ai đó nhận ra một quyết định đã được đưa ra.

Prompt không rõ tạo ranh giới không phù hợp

Nếu prompt không nói rõ ai chịu trách nhiệm gì, kiến trúc có xu hướng trôi về “cái gì hoạt động ngay bây giờ.” Bạn sẽ thấy các dịch vụ ad-hoc được tạo để thỏa mãn một màn hình hoặc tích hợp gấp rút, mà không có mô hình trách nhiệm ổn định.

Ví dụ, một prompt như “thêm subscriptions” có thể âm thầm trộn billing, quyền lợi và trạng thái khách hàng vào một module bắt mọi thứ. Sau này, mọi tính năng mới đều chạm tới nó, và ranh giới ngừng phản ánh miền thực tế.

Các lựa chọn sớm rất tốn kém để tháo gỡ

Kiến trúc phụ thuộc vào đường đi. Khi bạn đã chọn ranh giới, bạn cũng đã chọn:

• nơi validation nằm
• nơi luật nghiệp vụ chạy
• cách dữ liệu được nhân bản hoặc chia sẻ

Nếu prompt ban đầu không làm rõ các ràng buộc (ví dụ: “phải hỗ trợ hoàn tiền”, “nhiều gói cho mỗi tài khoản”, “quy tắc proration”), bạn có thể xây mô hình đơn giản không co giãn được. Sửa sau này thường nghĩa là di trú, thay đổi hợp đồng và kiểm thử lại các tích hợp.

Rõ ràng giảm các phương án phân nhánh

Mỗi lần làm rõ gom lại một cây các thiết kế có thể. Điều đó tốt: ít đường “có thể” hơn nghĩa là ít kiến trúc vô tình hơn.

Một prompt chính xác không chỉ giúp triển khai dễ hơn—nó làm cho các đánh đổi hiển hiện. Khi yêu cầu rõ ràng, nhóm có thể chọn ranh giới một cách có chủ ý (và ghi lại lý do), thay vì thừa hưởng chúng từ diễn giải đầu tiên có thể biên dịch được.

Triệu chứng phổ biến của sự mơ hồ

Sự mơ hồ trong prompt thường xuất hiện nhanh:

• scope creep (“nhân tiện, có thể…?”)
• tích hợp mong manh (đối tác dựa vào hành vi không được ghi chép)
• logic bị trùng lặp (cùng quy tắc được triển khai ở nhiều nơi)
• quyền sở hữu mơ hồ (không ai biết quy tắc nằm ở đâu)

Prompt rõ ràng không bảo đảm kiến trúc hoàn hảo, nhưng tăng mạnh khả năng cấu trúc hệ thống phản ánh vấn đề thực tế—và duy trì được khi mở rộng.

Từ Prompt đến Ranh giới Hệ thống và Trách nhiệm

Prompt rõ ràng không chỉ giúp bạn “nhận câu trả lời” — nó buộc bạn phải tuyên bố hệ thống chịu trách nhiệm gì. Đó là khác biệt giữa kiến trúc sạch và một mớ tính năng không biết thuộc về đâu.

Mục tiêu và non-goals định nghĩa ranh giới dịch vụ

Nếu prompt của bạn nêu mục tiêu như “người dùng có thể xuất hóa đơn thành PDF trong 30 giây”, điều đó gợi ý ngay trách nhiệm riêng (tạo PDF, theo dõi job, lưu trữ, thông báo). Một non-goal như “không hợp tác thời gian thực trong v1” ngăn bạn vội thêm websockets, khoá chia sẻ và giải quyết xung đột.

Khi mục tiêu đo được và non-goals rõ ràng, bạn có thể vẽ đường sắc lẹm hơn:

• Cái gì phải đồng bộ (UI chờ) so với bất đồng bộ (worker nền)
• Dữ liệu nào phải nhất quán mạnh so với chấp nhận eventual
• Cái gì thuộc dịch vụ riêng so với module bên trong API

Ánh xạ actor và workflow tới các thành phần

Một prompt tốt xác định actor (khách hàng, admin, support, bộ lập lịch tự động) và các workflow cốt lõi họ kích hoạt. Những workflow đó ánh xạ rõ ràng tới các thành phần:

• UI: form, dashboard, upload/download, trạng thái
• API: validation, điều phối, thực thi chính sách, tổng hợp
• Worker: tác vụ chạy lâu, retry, xử lý hàng loạt
• Lưu trữ: bảng nguồn chân lý, lưu trữ file/object, audit log

Các mối quan tâm cắt ngang bạn nên nêu từ đầu

Prompt thường bỏ sót các yêu cầu “mọi nơi” chi phối kiến trúc: xác thực/ủy quyền, kiểm toán, giới hạn tần suất, idempotency, retry/timeouts, xử lý PII, và observability (logs/metrics/traces). Nếu không được chỉ định, chúng bị thực thi không đồng nhất.

Checklist nhanh: prompt của bạn đã đủ khía cạnh kiến trúc chưa?

• Mục tiêu rõ + non-goals rõ ràng
• Actor và workflow chính được liệt kê
• Quy mô/kỳ vọng độ trễ và kỳ vọng lỗi
• Quyền sở hữu dữ liệu (nguồn chân lý) và quy tắc lưu giữ
• Các mối quan tâm cắt ngang: auth, auditing, rate limits, retries
• Tiêu chí “xong” (acceptance criteria) cho mỗi workflow

Độ rõ ràng Prompt và Độ chính xác của Mô hình Dữ liệu

Mô hình dữ liệu thường sai ngay trước khi ai đó viết SQL—khi prompt dùng danh từ mơ hồ nghe có vẻ “rõ”. Những từ như customer, account, và user có thể mang nhiều nghĩa khác nhau, và mỗi cách hiểu tạo ra schema khác nhau.

Danh từ mơ hồ tạo schema lộn xộn như thế nào

Nếu prompt nói “lưu khách hàng và tài khoản của họ”, bạn sẽ nhanh chóng gặp câu hỏi mà prompt không trả lời:

• customer là cá nhân, công ty, hay cả hai?
• account là hồ sơ thanh toán, tài khoản đăng nhập, tài khoản ngân hàng, hay subscription?
• user có phải cùng với customer, hay là nhân viên quản lý khách hàng?

Không có định nghĩa, nhóm sẽ bù bằng các cột nullable, bảng chứa chung, và các trường quá tải như type, notes, hoặc metadata dần trở thành “chỗ ta để mọi thứ”.

Định nghĩa chính xác cải thiện khoá, quan hệ và ràng buộc

Prompt rõ ràng biến danh từ thành thực thể cụ thể với quy tắc. Ví dụ: “Một Customer là một tổ chức. Một User là tài khoản đăng nhập thuộc về một tổ chức. Một Account là tài khoản thanh toán cho từng tổ chức.” Bây giờ bạn có thể thiết kế tự tin:

• Khoá: customer_id vs user_id không thể hoán đổi
• Quan hệ: one-to-many vs many-to-many được xác định, không đoán mò
• Ràng buộc: tính duy nhất (email theo org), trường bắt buộc, trạng thái hợp lệ

Vòng đời dữ liệu tránh các bản ghi “bất tử”

Độ rõ ràng prompt cũng nên bao gồm vòng đời: bản ghi được tạo, cập nhật, vô hiệu hóa, xóa và lưu giữ như thế nào. “Xóa customer” có thể nghĩa xóa cứng, xóa mềm, hoặc lưu theo yêu cầu pháp lý với truy cập hạn chế. Nói trước điều này tránh khoá ngoại hỏng, dữ liệu mồ côi và báo cáo không nhất quán.

Tên nhất quán và tránh trường quá tải

Dùng tên nhất quán cho cùng một khái niệm trên bảng và API (ví dụ luôn customer_id, không đôi khi org_id). Ưu tiên mô hình hóa khái niệm khác biệt thay vì cột quá tải—tách billing_status khỏi account_status thay vì một status mơ hồ làm nhiều việc.

Cần chỉ rõ gì để có mô hình dữ liệu mạnh

Mô hình dữ liệu chỉ tốt bằng chi tiết bạn cung cấp ban đầu. Nếu prompt nói “lưu khách hàng và đơn hàng”, bạn có thể nhận schema phù hợp demo nhưng thất bại ở điều kiện thực tế như trùng lặp, nhập khẩu hay bản ghi thiếu.

Thực thể cốt lõi và định danh

Nêu tên thực thể rõ (ví dụ Customer, Order, Payment) và định nghĩa cách mỗi thực thể được định danh.

• Định danh chính: UUID, email, số tài khoản, hay khoá ghép?
• Định danh bên ngoài: Bản ghi có đồng bộ từ hệ thống khác không (ví dụ CRM ID)? Có thể có nhiều ID bên ngoài không?
• Quy tắc tính duy nhất: Email duy nhất toàn cục, theo tenant, hay không duy nhất?

Trạng thái, chuyển đổi và quy tắc vòng đời

Nhiều mô hình vỡ vì trạng thái không được chỉ rõ. Làm rõ:

• Trạng thái cho phép (Draft → Submitted → Paid → Refunded)
• Các chuyển đổi được phép và điều gì kích hoạt chúng
• Trạng thái có thể thay đổi không (Paid có thể hồi lại?) và cách bạn kiểm toán thay đổi

Xác thực, trường bắt buộc và định dạng

Nêu rõ cái nào phải có và cái nào có thể thiếu.

Ví dụ:

• Trường bắt buộc vs tuỳ chọn (ví dụ phone tuỳ chọn, địa chỉ thanh toán bắt buộc để xuất hóa đơn)
• Ràng buộc trường (độ dài min/max, ký tự cho phép)
• Thời điểm xác thực (khi tạo, khi cập nhật, hoặc tại bước workflow)

Thời gian, tiền tệ, locale và timezone

Chỉ rõ sớm để tránh mâu thuẫn ẩn.

• Lưu timestamp bằng UTC? Có lưu timezone gốc không?
• Tiền tệ theo ISO 4217 (USD/EUR) với đơn vị nhỏ? Quy tắc làm tròn?
• Format theo locale khác với lưu chuẩn?

Các trường hợp biên: trùng lặp, ghép, nhập khẩu, dữ liệu không đầy đủ

Hệ thống thực phải xử lý thực tế lộn xộn. Làm rõ cách xử lý:

• Phát hiện trùng lặp và quy tắc ghép (trường nào “thắng”, cái gì được giữ)
• Bản ghi nhập khẩu thiếu trường (chấp nhận như “incomplete”? )
• Cập nhật mâu thuẫn từ nhiều nguồn và yêu cầu audit

Hợp đồng API: Nơi độ rõ ràng mang lại lợi ích nhanh

Hợp đồng API là nơi dễ thấy lợi ích từ prompt rõ ràng: khi yêu cầu rõ, API khó dùng sai hơn, dễ version hơn và ít gây thay đổi phá vỡ.

Ngăn thay đổi phá vỡ bằng cách cụ thể

Prompt mơ hồ như “thêm endpoint để cập nhật orders” để lại chỗ cho diễn giải không tương thích (cập nhật một phần hay toàn phần, tên trường, giá trị mặc định, async hay sync). Yêu cầu hợp đồng rõ ép các quyết định sớm:

• Trường nào có thể ghi, bắt buộc, hay bất biến
• Cập nhật dùng PUT (thay thế) hay PATCH (cập nhật một phần)
• Quy tắc tương thích ngược (ví dụ “trường mới phải optional; không thay đổi ý nghĩa trường hiện có”)

Xử lý lỗi: biến chế độ thất bại thành một phần thiết kế

Định nghĩa các "lỗi tốt" trông như thế nào. Ít nhất, nêu:

• Mã trạng thái cho từng kịch bản (400 validation, 401/403 auth, 404 missing, 409 conflicts, 429 rate limit)
• Body lỗi nhất quán (mã máy, thông điệp con người, chi tiết per-field, correlation/request ID)
• Kỳ vọng retry: lỗi nào an toàn để retry, và khuyến nghị backoff

Phân trang, lọc, sắp xếp và idempotency

Mơ hồ ở đây tạo lỗi cho client và hiệu năng không đều. Nêu rõ quy tắc:

• Kiểu phân trang (cursor vs offset), giới hạn và đảm bảo thứ tự ổn định
• Bộ lọc hỗ trợ và kiểu của chúng (so khớp chính xác, khoảng, enum)
• Các trường được phép sắp xếp và sắp xếp mặc định
• Idempotency cho các thao tác ghi (khóa idempotency, cửa sổ dedupe, hành vi khi yêu cầu trùng)

Ghi tài liệu với ví dụ và ràng buộc

Bao gồm ví dụ request/response cụ thể và ràng buộc (độ dài min/max, giá trị cho phép, định dạng ngày). Một vài ví dụ thường ngăn nhiều hiểu lầm hơn một trang văn phong.

Khả năng bảo trì: Chi phí dài hạn của sự mơ hồ

Prompt mơ hồ không chỉ tạo “câu trả lời sai”. Nó tạo ra các giả thiết ẩn—những quyết định nhỏ chưa được ghi chép lan ra khắp code, trường DB và phản hồi API. Kết quả là phần mềm chỉ chạy đúng trong những giả thiết mà người xây dựng đoán, và vỡ khi thực tế khác.

Giả thiết ẩn biến thành mã mong manh

Khi prompt để khoảng trống (ví dụ “hỗ trợ hoàn tiền” không có quy tắc), các nhóm bù bằng cách khác nhau ở các chỗ khác nhau: dịch vụ A coi hoàn tiền là đảo ngược giao dịch, dịch vụ B coi là giao dịch riêng, dịch vụ C cho phép hoàn tiền một phần không ràng buộc.

Prompt rõ ràng giảm đoán mò bằng cách nêu bất biến (“hoàn tiền được phép trong 30 ngày”, “cho phép hoàn tiền một phần”, “hàng số không được trả lại cho hàng kỹ thuật số”). Những phát biểu đó dẫn tới hành vi dự đoán được trên toàn hệ thống.

Rõ ràng làm mã và test đơn giản hơn

Hệ thống dễ bảo trì dễ suy luận hơn. Độ rõ ràng prompt hỗ trợ:

• Mã dễ đọc: ít nhánh phòng thủ hơn vì đầu vào và trạng thái được định nghĩa.
• Test đơn giản hơn: ca kiểm thử ánh xạ trực tiếp tới tiêu chí chấp nhận đã nêu thay vì truy theo “nếu”.
• Refactor an toàn hơn: nếu hành vi được chỉ rõ, bạn có thể thay đổi nội bộ tự tin và xác minh kết quả.

Nếu bạn dùng phát triển hỗ trợ AI, yêu cầu rõ ràng cũng giúp mô hình sinh ra triển khai nhất quán thay vì các mảnh khớp có vẻ hợp lý nhưng không ăn khớp.

Khả năng vận hành: logging và metric không phải chi tiết tùy chọn

Khả năng bảo trì bao gồm vận hành hệ thống. Prompt nên chỉ rõ kỳ vọng observability: gì phải log (và gì không), metric nào quan trọng (tỷ lệ lỗi, độ trễ, retry), và lỗi nên được báo như thế nào. Không có điều này, nhóm chỉ phát hiện vấn đề khi khách hàng phát hiện.

Các tín hiệu bảo trì để quan sát

Sự mơ hồ thường biểu hiện dưới dạng kết dính thấp và coupling cao: trách nhiệm không liên quan bị nhét chung, module “hỗ trợ” chạm tới mọi nơi, và hành vi thay đổi theo caller. Prompt rõ ràng khuyến khích thành phần có tính tập trung, giao diện hẹp và kết quả dự đoán được—làm cho thay đổi tương lai rẻ hơn. Để áp dụng thực tế, xem /blog/review-workflow-catch-gaps-before-building.

Ví dụ Trước và Sau của Prompt tốt hơn

Prompt mơ hồ không chỉ sinh ra văn bản mơ hồ—nó đẩy một thiết kế về mặc định “CRUD generic”. Một prompt rõ ràng khiến các quyết định phải sớm: ranh giới, quyền sở hữu dữ liệu và điều gì phải đúng trong DB.

Trước: prompt mơ hồ

“Thiết kế một hệ thống đơn giản để quản lý items. Người dùng có thể tạo, cập nhật và chia sẻ items. Nó nên nhanh và có thể scale, với một API sạch. Giữ lịch sử thay đổi.”

Những điều người xây (người hoặc AI) không thể suy ra đáng tin cậy:

• Item là gì (các trường, vòng đời, tính duy nhất)?
• “Chia sẻ” nghĩa là gì (link công khai vs người dùng cụ thể vs team)?
• “Lịch sử” là gì (snapshot đầy đủ vs diff, ai thay đổi gì, retention)?

Sau: prompt rõ ràng hơn với ràng buộc

“Thiết kế REST API để quản lý các item generic với các quy tắc: item có title (bắt buộc, max 120), description (tuỳ chọn), status (draft|active|archived), tags (0–10). Mỗi item thuộc về đúng một owner (user). Chia sẻ là cấp quyền truy cập theo item cho người dùng cụ thể với vai trò viewer|editor; không có link công khai. Mỗi thay đổi phải có audit: lưu ai thay đổi gì và khi nào, và cho phép truy xuất 50 thay đổi gần nhất cho mỗi item. Phi chức năng: p95 độ trễ API < 200ms cho đọc; throughput ghi thấp. Cung cấp mô hình dữ liệu và endpoint; bao gồm các trường hợp lỗi và quyền hạn.”

Giờ đây kiến trúc và schema thay đổi ngay lập tức:

• Kiến trúc: thành phần Authorization riêng (kiểm tra vai trò) và luồng ghi Audit Log; không cần caching phức tạp nếu throughput ghi thấp.
• Schema: items, item_shares (many-to-many với vai trò), và item_audit_events (append-only). status thành enum, tags có thể sang bảng join để giới hạn 10 tag.

Bảng dịch nhanh

Mẫu Prompt thực tế để có thiết kế tốt hơn

Một prompt rõ ràng không cần dài—nó cần có cấu trúc. Mục tiêu là cung cấp đủ ngữ cảnh để các quyết định kiến trúc và mô hình dữ liệu trở nên hiển nhiên, không bị đoán mò.

Template copy/paste

1) Goal
- What are we building, and why now?
- Success looks like: <measurable outcome>

2) Users & roles
- Primary users:
- Admin/support roles:
- Permissions/entitlements assumptions:

3) Key flows (happy path + edge cases)
- Flow A:
- Flow B:
- What can go wrong (timeouts, missing data, retries, cancellations)?

4) Data (source of truth)
- Core entities (with examples):
- Relationships (1:N, N:N):
- Data lifecycle (create/update/delete/audit):
- Integrations/data imports (if any):

5) Constraints & preferences
- Must use / cannot use:
- Budget/time constraints:
- Deployment environment:

6) Non-functional requirements (NFRs)
- Performance: target latency/throughput, peak load assumptions
- Uptime: SLA/SLO, maintenance windows
- Privacy/security: PII fields, retention, encryption, access logs
- Compliance: (if relevant)

7) Risks & open questions
- Known unknowns:
- Decisions needed from stakeholders:

8) Acceptance criteria + Definition of Done
- AC: Given/When/Then statements
- DoD: tests, monitoring, docs, migrations, rollout plan

9) References
- Link existing internal pages: /docs/<...>, /pricing, /blog/<...>

Cách dùng hiệu quả

Điền các mục 1–4 trước. Nếu bạn không thể đặt tên các thực thể cốt lõi và nguồn chân lý, thiết kế thường trôi vào “cái API trả về,” dẫn đến di trú lộn xộn và quyền sở hữu không rõ.

Với NFRs, tránh từ mơ hồ (“nhanh”, “bảo mật”). Thay bằng số, ngưỡng và quy tắc xử lý dữ liệu. Một ước tính thô (ví dụ “p95 < 300ms cho read ở 200 RPS”) hữu dụng hơn im lặng.

Với tiêu chí chấp nhận, bao gồm ít nhất một trường hợp tiêu cực (ví dụ input không hợp lệ, từ chối quyền) và một trường hợp vận hành (ví dụ cách lỗi được hiển thị). Điều đó giữ thiết kế bám vào hành vi thực, không chỉ sơ đồ.

Dùng Koder.ai để Biến Prompt Rõ Thành Bản dựng Nhất quán

Độ rõ ràng prompt càng quan trọng hơn khi bạn xây với AI end-to-end—không chỉ sinh đoạn mã. Trong workflow vibe-coding (prompt dẫn dắt yêu cầu, thiết kế và triển khai), những mơ hồ nhỏ có thể lan vào lựa chọn schema, hợp đồng API và hành vi UI.

Koder.ai được thiết kế cho kiểu phát triển này: bạn có thể lặp trên prompt có cấu trúc trong chat, dùng Planning Mode để làm rõ giả thiết và câu hỏi mở trước khi mã sinh ra, rồi triển khai stack web/backend/mobile hoạt động (React cho web, Go + PostgreSQL cho backend, Flutter cho mobile). Các tính năng thực tế như snapshots và rollback giúp bạn thử nghiệm an toàn khi yêu cầu thay đổi, và xuất mã nguồn cho phép đội giữ quyền sở hữu và tránh hệ thống “hộp đen”.

Nếu bạn chia sẻ prompt với đồng đội, coi template prompt ở trên như spec sống (và version nó cùng app) sẽ sản sinh ranh giới sạch hơn và ít thay đổi phá vỡ vô tình.

Quy trình rà soát: Bắt khoảng trống trước khi xây

Một prompt rõ ràng không “xong” khi nó đọc dễ hiểu. Nó xong khi hai người khác nhau sẽ thiết kế hệ thống gần như giống nhau từ đó. Một quy trình rà soát nhẹ giúp bạn tìm mơ hồ sớm—trước khi nó thành churn kiến trúc, viết lại schema và thay đổi API phá vỡ.

Bước 1: Đọc lại (2 phút)

Nhờ một người (PM, kỹ sư, hoặc AI) phát lại prompt dưới dạng: mục tiêu, non-goals, inputs/outputs và ràng buộc. So sánh bản đọc lại đó với ý định của bạn. Bất kỳ sự không khớp nào là yêu cầu chưa rõ.

Bước 2: Buộc các câu hỏi thiếu lộ ra

Trước khi xây, liệt kê “những ẩn số làm thay đổi thiết kế.” Ví dụ:

• Ai là nguồn chân lý cho một trường (user vs system vs API ngoài)?
• Khi dữ liệu thiếu, trễ, trùng hay sai thì sao?
• Kỳ vọng hiệu năng/qui mô là gì (số thô)?

Ghi các câu hỏi đó vào prompt như phần “Open questions”.

Bước 3: Duy trì danh sách giả thiết—và chuyển đổi chúng

Giả thiết không sao, nếu chúng hiển thị. Với mỗi giả thiết, chọn một:

• Decision: làm rõ (ví dụ “Email là duy nhất theo user; thay đổi cần xác thực”).
• TODO: đánh dấu là follow-up có chủ sở hữu và thời hạn (ví dụ “TODO: xác nhận chính sách retention với Legal trước launch”).

Bước 4: Lặp từng bước nhỏ

Thay vì một prompt khổng lồ, làm 2–3 vòng ngắn: làm rõ ranh giới, rồi mô hình dữ liệu, rồi hợp đồng API. Mỗi lượt loại bớt mơ hồ, không thêm scope.

Checklist ký duyệt nhanh (PM + kỹ sư)

• Metrics thành công và tiêu chí chấp nhận đã viết
• Non-goals rõ
• Ranh giới hệ thống và trách nhiệm đã đặt tên
• Thực thể/trường chính và quyền sở hữu đã định nghĩa
• Trường hợp lỗi và biên đã mô tả
• Giả thiết chuyển thành quyết định hoặc TODO

Sai lầm phổ biến và cách khắc phục

Ngay cả đội mạnh cũng mất rõ ràng theo những cách nhỏ, lặp lại. Tin tốt là: hầu hết vấn đề dễ nhận ra và sửa trước khi viết mã.

Kẻ giết rõ ràng cần chú ý

Động từ mơ hồ che giấu quyết định thiết kế. Từ như “hỗ trợ”, “xử lý”, “tối ưu”, hay “làm cho dễ” không nói thành công trông như thế nào.

Actor không xác định tạo khoảng trống quyền sở hữu. “Hệ thống thông báo người dùng” mở câu hỏi: component nào, loại người dùng nào, qua kênh nào?

Thiếu ràng buộc dẫn đến kiến trúc ngẫu nhiên. Nếu không nêu qui mô, độ trễ, quy tắc riêng tư, yêu cầu audit hoặc ranh giới triển khai, hiện thực sẽ đoán—và bạn trả giá sau.

Đừng quá chỉ định triển khai

Cạm bẫy thường là bắt công cụ và nội bộ (“Dùng microservices”, “Lưu vào MongoDB”, “Dùng event sourcing”) khi bạn thực sự muốn một kết quả (“triển khai độc lập”, “schema linh hoạt”, “audit trail”). Nói tại sao bạn muốn điều đó, rồi thêm yêu cầu đo được.

Ví dụ: thay vì “Dùng Kafka”, viết “Sự kiện phải bền trong 7 ngày và có thể replay để dựng lại projections.”

Tránh mâu thuẫn sớm

Mâu thuẫn thường xuất hiện dưới dạng “phải real-time” cộng “batch OK”, hoặc “không lưu PII” cộng “email người dùng và hiển thị profile”. Giải quyết bằng cách xếp thứ tự ưu tiên (must/should/could), và thêm tiêu chí chấp nhận không thể cùng lúc đúng.

Anti-patterns và cách sửa

• Anti-pattern: “Đơn giản hoá onboarding.” Sửa: “Người dùng mới hoàn thành onboarding trong <3 phút; tối đa 6 trường; hỗ trợ lưu và tiếp tục.”

• Anti-pattern: “Admins quản lý accounts.” Sửa: Định nghĩa hành động (suspend, reset MFA, change plan), quyền và logging kiểm toán.

• Anti-pattern: “Đảm bảo hiệu năng cao.” Sửa: “P95 API latency <300ms ở 200 RPS; degrade graceful khi rate-limited.”

• Anti-pattern: Thuật ngữ lẫn lộn (“customer,” “user,” “account”). Sửa: Thêm một glossary nhỏ và tuân thủ nó xuyên suốt.

Checklist và Bước tiếp theo

Prompt rõ ràng không chỉ giúp trợ lý "hiểu bạn". Nó giảm suy đoán, điều này thể hiện ngay bằng ranh giới hệ thống sạch hơn, ít bất ngờ mô hình dữ liệu và API dễ tiến hoá hơn. Sự mơ hồ, ngược lại, trở thành làm lại: di trú bạn không lường, endpoint không phù hợp workflow thực, và nhiệm vụ bảo trì cứ lặp lại.

Một trang checklist bạn có thể tái sử dụng

Dùng cái này trước khi yêu cầu kiến trúc, schema hoặc API:

• Mục tiêu: Kết quả người dùng mong muốn? “Xong” trông như thế nào?
• Phạm vi: Cái nào vào, cái nào ra, và cái gì để sau?
• Actor & entry points: Ai kích hoạt flow (user, admin, job hệ thống)?
• Workflow chính: 2–5 bước happy-path, plus các failure hàng đầu.
• Định nghĩa dữ liệu: Thực thể quan trọng, trường bắt buộc, ID và quan hệ.
• Ràng buộc: Mục tiêu hiệu năng, quy tắc riêng tư, retention, audit.
• Tích hợp: Hệ thống bên ngoài, sự kiện, hàng đợi, và ranh giới sở hữu.
• Kỳ vọng API: Inputs/outputs, hành vi lỗi, idempotency, phân trang.
• Tiêu chí chấp nhận: Các phát biểu có thể kiểm thử (bao gồm biên).
• Non-goals: Nêu rõ điều hệ thống không làm.
• Giả thiết: Những gì bạn tin nhưng chưa xác minh.
• Câu hỏi mở: Gì cần trả lời trước khi xây.

Bước tiếp theo

1. Chọn một tính năng thực bạn định làm trong tuần này.
2. Viết prompt theo checklist trên.
3. Sinh hai thiết kế: một từ prompt “cũ”, một từ prompt đã làm rõ.
4. So sánh kết quả theo ba ống kính: ranh giới hệ thống, mô hình dữ liệu, và hợp đồng API.
5. Giữ prompt đã làm rõ như một phần spec sống (nó trở thành tài liệu sống).

Nếu bạn muốn thêm mẫu thực hành, tham khảo /blog hoặc xem các hướng dẫn hỗ trợ trong /docs.