Cách viết spec cho AI làm đúng ý: khung MONA dùng cho mọi dự án

Viết spec cho AI là ghi đề bài đủ rõ để máy biết phải làm gì, dữ liệu đi vào đâu và kết quả nào mới được tính là đúng. Một bản đặc tả phần mềm tốt còn cho người duyệt sẵn đáp án, nhờ vậy code AI viết sai sẽ bị bắt qua 2 lần duyệt trước khi chạm máy chủ. Tụi em dùng lối này trong mô hình phát triển phần mềm AI-Native đã áp qua hơn 14.000 dự án: người ra đề, kiểm soát, chịu trách nhiệm; AI làm phần tay chân. Đề phải đo được.

Spec là cái đề để AI biết làm gì và biết lúc nào làm đúng

Một chủ spa nói “làm giúp tôi chức năng đặt lịch cho dễ dùng”, người phụ trách lâu năm còn biết hỏi tiếp về ca làm, dịch vụ, thời lượng và trường hợp khách đổi hẹn. AI nhận nguyên câu đó sẽ tự lấp mọi chỗ trống bằng cách nó đoán. Mỗi lần sinh code, cách đoán lại lệch một chút. Đề mờ thì bài sai.

Spec là gì? Hiểu gọn, đó là tài liệu ghi hành vi phần mềm, dữ liệu đầu vào, dữ liệu trả ra, tình huống lỗi và tiêu chí nghiệm thu. Trong quy trình Spec-Driven Development, spec đứng trước code; code được sinh lại khi đề thay đổi. Từ 2016 đến hơn 14.000 dự án, tụi em thấy phần tốn tiền thường nằm ở câu “em tưởng anh muốn kiểu kia”, chứ bàn phím không phải phần khó.

Một spec có 2 người đọc. AI đọc để thực thi, còn anh chị đọc để kiểm xem yêu cầu kinh doanh đã được hiểu đúng chưa. Chốt cả 2 trước khi code chạy giúp dự án có một điểm đối chiếu rõ, thay cho hàng chục tin nhắn rời nằm trong nhiều nhóm chat.

Người đọc còn tự hiểu ý ngầm, AI thì phải ghi từng điều kiện

Con người nghe chữ “nhanh” rồi tự liên hệ với tốc độ của trang hiện tại. AI không biết mốc đó. Nó cũng không biết giao diện “đẹp” theo gu nào, khách “thân thiết” được tính từ bao nhiêu đơn, hay nút “dễ thấy” phải nằm ở đâu trên màn hình 375 px. Máy cần con số.

Tụi em hay tách mỗi yêu cầu thành 3 lớp: hành vi, dữ liệu, cách chấm. Câu nào chưa viết được lớp thứ 3 thì chưa giao AI. Đội chấm cùng yêu cầu 3 lượt trên một bộ dữ liệu trước khi cho AI-DLC chạy tiếp.

Nhìn tận tay: spec 10 dòng cho chức năng đặt lịch spa

Khối dưới đây là một ví dụ giả lập để anh chị copy rồi thay dữ liệu của dự án. Nó có đúng 10 dòng, đủ hành vi, đầu vào, đầu ra, cách báo lỗi và tiêu chí kiểm. Ngắn nhưng chặt.

1. Tính năng: khách đặt lịch dịch vụ spa trên website.
2. Đầu vào: chi nhánh, dịch vụ, ngày, giờ, họ tên, số điện thoại.
3. Chỉ hiện khung giờ còn trống theo lịch của chi nhánh đã chọn.
4. Mỗi lịch giữ đúng 1 khách trong ví dụ này, không nhận trùng giờ.
5. Khách được đặt trước tối đa 30 ngày.
6. Khi hợp lệ, hệ thống tạo mã hẹn và trả trang xác nhận.
7. Khi giờ vừa bị người khác lấy, giữ dữ liệu và yêu cầu chọn giờ khác.
8. Khi thiếu số điện thoại, đánh dấu đúng trường và không tạo lịch.
9. Nghiệm thu bằng 4 ca: thành công, thiếu dữ liệu, trùng giờ, quá 30 ngày.
10. Log phải ghi mã hẹn, thời điểm tạo và kết quả gửi thông báo.

Con số 30 ngày hay quy tắc 1 khách chỉ là dữ liệu mẫu, chủ dự án phải đổi theo nghiệp vụ thật trước khi dùng. Điểm đáng học là mỗi dòng đều kiểm được. Nếu AI tạo lịch dù thiếu số điện thoại, dòng 8 cho người duyệt căn cứ từ chối ngay; không cần tranh luận “em thấy vậy cũng được”.

Khối nhìn tận tay này đi xa hơn một câu lệnh vibe coding. Tụi em vẫn dùng AI để chạy nhanh, nhưng tốc độ chỉ bắt đầu sau lúc đáp án đã nằm trên giấy.

6 chỗ phải khóa trước khi đưa bản đặc tả cho AI

Một bản đặc tả phần mềm dài 20 trang vẫn hở nếu né đúng chỗ khó. Tụi em dùng 6 điểm dưới đây để rà trước cửa vào; thiếu 1 điểm thì quay lại hỏi, chưa cho máy code. Khóa đủ rồi chạy.

1. Mục tiêu: người dùng hoàn tất việc gì, trong tình huống nào?
2. Phạm vi: lần này làm gì và chủ động chưa làm gì?
3. Dữ liệu: trường nào bắt buộc, định dạng ra sao, lấy từ nguồn nào?
4. Luồng chính: từ thao tác đầu đến kết quả cuối đi qua những bước nào?
5. Luồng lỗi: dữ liệu rỗng, trùng, hết quyền hoặc dịch vụ ngoài ngừng trả lời thì xử lý ra sao?
6. Nghiệm thu: đưa bộ dữ liệu nào vào, mong chờ đúng kết quả gì?

Checklist 6 điểm này là bản rút gọn của cách tụi em dùng cho phần mềm viết theo yêu cầu. Dự án nhỏ vẫn cần đủ 6, chỉ khác độ dài. Đội 2 người làm một chức năng ngắn có thể gói trong 1 trang; hệ thống nhiều quyền và nhiều nguồn dữ liệu phải tách spec theo từng phần để người duyệt đọc nổi. Đủ 6 mới đi.

Viết từng câu để máy đo được, đừng giao nó chữ “đẹp”

Spec thường hỏng ở tính từ. “Đẹp”, “nhanh”, “linh hoạt”, “bảo mật cao” đều nghe xuôi tai, nhưng 4 chữ đó không cho AI một đáp án để dừng. Anh chị đổi mỗi tính từ thành một phép kiểm, bản spec lập tức bớt tranh cãi. Đo được mới duyệt.

Chỗ này cần người hiểu nghiệp vụ đứng ra quyết. AI viết được câu chữ, tự dựng danh sách ca thử, thậm chí gợi ý chỗ còn thiếu; quyền chọn mốc đúng vẫn thuộc về anh chị và dev senior. Với mỗi tiêu chí, tụi em đo 5 lần trên cùng môi trường và lặp 2 lần bằng tài khoản khác quyền trong dự án website tích hợp AI.

MONA chốt spec rồi cho code đi qua 2 cửa

Sau khi spec được duyệt, AI sinh code và tự rà vòng đầu. Cửa 1 bắt các lỗi máy nhìn ra nhanh: sai cú pháp, kiểm thử hỏng, lệch kiểu dữ liệu, thiếu nhánh lỗi. Cửa 2 do dev senior đọc nghiệp vụ, quyền truy cập, bảo mật và chuẩn vận hành trước khi code tới máy chủ. Người giữ cửa cuối.

Mọi code AI viết tại MONA đều đi qua 2 cửa đó. Đây là phần người đọc ít thấy, nhưng quyết định một bản demo chạy được có trở thành sản phẩm sống lâu hay không. Bài AI code review trình bày riêng checklist 8 điểm tụi em dùng ở cửa duyệt này.

Ngày 19/08/2026, tụi em dựng bản whitepaper 14 trang trong 1 buổi chiều bằng đúng lối làm trên: người viết spec cho từng trang, AI dựng, người bắt 3 lỗi bố cục rồi mới phát hành. Tốc độ đến từ việc đề rõ và vòng duyệt ngắn; AI không được tự quyết nội dung cần công bố.

Spec không nằm riêng ở đầu dự án, nó đi xuyên cả 4 trụ

Trong mô hình phát triển phần mềm AI-Native, spec là tài sản chạy xuyên 4 trụ. Kanban cho đầu việc chảy liên tục; SDD giữ đề bài; AI-DLC cho AI tham gia từng khâu; Agentic SDLC mở chế độ tự chạy cho MVP nhỏ. Một nguyên tắc giữ cả 4: người ra đề, kiểm soát, chịu trách nhiệm; AI làm tay chân. Ranh giới rất rõ.

Nếu đầu việc đang tắc vì phải chờ hết một đợt 2 tuần, xem cách Kanban khác Scrum. Nếu muốn AI chạy liền mạch sau khi đề đã khóa, đọc Agentic SDLC. Spec nằm trước cả 2 lựa chọn đó; thiếu nó, đội đang tăng tốc một chiếc xe chưa biết đích.

Tụi em khuyên đội chưa có thói quen duyệt yêu cầu đừng vội cho agent tự chạy. Hãy làm 1 tính năng, đi qua 6 lượt kiểm và giữ 2 lượt duyệt độc lập cho code AI sinh. Quy trình đứng vững rồi mới mở rộng sang bộ AI agent.

4 lỗi làm spec dài mà AI vẫn hiểu sai

Độ dài không cứu được một bản spec thiếu cấu trúc. Tụi em từng thấy tài liệu đầy mô tả giao diện nhưng không có 1 ca lỗi, hoặc liệt kê hàng chục màn hình mà chẳng ghi ai được quyền bấm nút nào. Hãy chạy 4 lần thử theo bảng, rồi thêm 3 lần với dữ liệu rỗng, sai và vượt quyền. Dài chưa chắc chặt.

Lỗi thứ 3 rất hay gặp khi dùng công cụ Spec-Driven Development. Công cụ càng giỏi mở rộng đề, phạm vi càng dễ phình nếu người viết quên câu “chưa làm”. Đừng mua thêm công cụ để chữa một bản spec hở.

Câu hỏi thường gặp về cách viết spec cho AI

Tụi em rút 4 câu dưới đây từ quy trình đã đi qua hơn 14.000 dự án và 2 lần duyệt cho mỗi thay đổi code AI. Trả lời thẳng.

Viết spec cho AI cần dài bao nhiêu?

Đủ để một người khác đọc rồi tạo cùng một hành vi. Tính năng đặt lịch mẫu dùng 10 dòng; hệ thống có nhiều quyền cần tách thành nhiều phần. Hãy kiểm bằng 6 điểm thay vì ép mọi spec vào một số trang cố định. Đủ mới chạy.

Ai chịu trách nhiệm viết bản đặc tả phần mềm?

Người hiểu nghiệp vụ và dev senior cùng chịu trách nhiệm. AI hỗ trợ đặt câu hỏi, chuẩn hóa cấu trúc và sinh ca thử; người duyệt mục tiêu, con số và ranh giới. Tại MONA, code còn qua 2 cửa trước khi tới máy chủ.

Có spec rồi thì AI tự viết hết phần mềm được không?

AI gánh phần thực thi lặp, còn người giữ kiến trúc, bảo mật và nghiệm thu. Với MVP nhỏ, AI agent viết theo yêu cầu chạy được nhiều chặng liên tiếp; hệ thống chạm tiền hoặc dữ liệu nhạy cảm cần thêm cửa kiểm.

Spec có thay đổi giữa dự án được không?

Được, và phải lưu thay đổi thành phiên bản rõ. Đổi spec trước giúp đội thấy phần code, kiểm thử và tài liệu nào bị ảnh hưởng. Cách này giữ 1 nguồn sự thật, thay cho sửa miệng ở nhiều nhóm chat.

Chốt 6 điểm trước khi cho AI viết dòng code đầu

Viết spec cho AI tốt bắt đầu từ một việc rất đời: nói rõ mình muốn gì và thế nào mới được tính là xong. Anh chị lấy 1 tính năng thật, đi qua 6 điểm, viết ít nhất 1 luồng đúng cùng 3 luồng lỗi, rồi giao AI thử. Qua 2 cửa duyệt mà số vòng sửa giảm, lúc đó mới nhân cách làm sang phần còn lại. Đừng chạy trước đề.

Tụi em đã giữ nguyên tắc người ra đề, kiểm soát và chịu trách nhiệm từ 2016, qua hơn 14.000 dự án; 85% khách tiếp tục đồng hành là bằng chứng cho giá trị của phần vận hành sau dòng code. Anh chị cần đội MONA rà bản đặc tả hoặc dựng phần mềm từ spec, gọi 1900 636 648. Tụi em sẽ bắt đầu từ đúng 6 điểm trong bài, trả lại phạm vi và cách nghiệm thu rõ trước khi bàn đến báo giá.