
AI viết code đúng thứ bạn nói nhưng sai thứ bạn cần: bài học về tài liệu spec
Vũ Khôi
Tác giả tại Wotech Electronics Blog

AI viết code đúng thứ bạn nói, nhưng sai thứ bạn cần
Bạn nhờ AI viết một tính năng. Nó hỏi đúng hai câu rồi lao vào code. Hai ngày sau, bạn nhận về một phần mềm chạy rất mượt — đúng từng chữ bạn nói, nhưng sai hoàn toàn thứ bạn thực sự cần. Đây không phải lỗi của model. Lỗi nằm ở chỗ không ai đặt đủ câu hỏi trước khi bắt tay làm việc. Bài viết này giải thích vì sao tài liệu yêu cầu (spec) đang trở thành kỹ năng quan trọng nhất của thời đại giao việc cho AI.
Tình huống mà đội kỹ thuật nào dùng AI cũng từng gặp
Kịch bản diễn ra ngày càng phổ biến ở các doanh nghiệp Việt Nam: lập trình viên mở công cụ AI, gõ một câu đại loại "thêm chức năng xuất báo cáo cho khách hàng". AI trả lời nhanh gọn bằng đúng hai câu hỏi làm rõ, nhận được vài dòng phản hồi, rồi bắt đầu code.
Kết quả sau hai ngày: tính năng hoạt động. Code sạch, cú pháp chuẩn, thậm chí có cả test. Nhưng khi đưa cho bộ phận nghiệp vụ dùng thử, mọi người chưng hửng: thiếu trường dữ liệu quan trọng, luồng xử lý sai so với thực tế vận hành, và không ai nghĩ đến các trường hợp ngoại lệ mà nhân viên gặp hằng ngày.
AI đã xây đúng thứ bạn nói — nhưng đó không phải thứ bạn cần. Khoảng cách giữa "nói" và "cần" chính là khoảng chết của mọi dự án phần mềm, và giờ đây AI khiến khoảng cách này lộ ra nhanh hơn bao giờ hết.
AI không làm sai — nó làm đúng một yêu cầu sai
Điều đầu tiên cần thừa nhận: đây không phải lỗi của model. AI hoạt động theo nguyên tắc nhận chỉ dẫn và thực hiện. Nếu chỉ dẫn chỉ vỏn vẹn một câu kèm hai câu trả lời làm rõ, nó sẽ điền phần còn thiếu của yêu cầu bằng những giả định hợp lý nhất với nó — chứ không phải bằng thực tế nghiệp vụ của doanh nghiệp bạn.
Một kỹ sư giàu kinh nghiệm, khi nhận yêu cầu mơ hồ, sẽ phản xạ đặt ra hàng loạt câu hỏi: dữ liệu lấy từ đâu? Ai có quyền xem? Có cần lưu lịch sử không? Xử lý thế nào khi khách hàng chưa có giao dịch? AI không tự làm điều đó — nó được thiết kế để phục vụ theo chỉ dẫn, không phải để "chen ngang" chất vấn như một tư vấn viên thực thụ.
Nói cách khác: càng giao việc nhanh, càng phải chuẩn bị kỹ. Năng lực code của AI vượt xa năng lực "đọc suy nghĩ" của nó.
Spec là gì và vì sao nó trở lại thành "nhân vật chính"
Spec (viết tắt của specification — tài liệu đặc tả yêu cầu) là bản viết rõ ràng về những gì một tính năng phải làm, cho ai, trong điều kiện nào, và hoàn thành được xem là thế nào. Trước thời AI, các đội phát triển lớn vẫn luôn viết spec — nhưng nhiều đội nhỏ coi đó là thủ tục giấy tờ thừa thãi, chuyện trực tiếp "nói miệng" cho nhau nghe cho nhanh.
AI đổi căn bản phép tính này. Con người nghe yêu cầu bằng kinh nghiệm nghiệp vụ tích luỹ; AI nghe yêu cầu bằng đúng những gì được viết ra. Khi nguồn sự thật duy nhất giữa bạn và AI là văn bản, chất lượng văn bản quyết định chất lượng sản phẩm. Một spec tốt không giúp AI code nhanh hơn — nó giúp AI code đúng ngay từ lần đầu, và đó mới là thứ tiết kiệm thời gian thật sự, vì sửa một tính năng làm sai nền tảng tốn kém hơn nhiều lần viết lại từ đầu.
Ba thứ bắt buộc phải có trước khi giao việc cho AI
1. Checklist yêu cầu rõ ràng
Trước khi gõ prompt, hãy trả lời xong các câu hỏi nền tảng:
- Tính năng này giải quyết vấn đề gì, cho ai dùng? (người dùng cuối là nhân viên nội bộ, khách hàng, hay hệ thống khác)
- Luồng hoạt động chính diễn ra thế nào? Mô tả từng bước theo trình tự, từ dữ liệu vào đến kết quả ra
- Các trường hợp ngoại lệ và biên là gì? Dữ liệu rỗng, số âm, người dùng không có quyền, mạng chậm — chính những nhánh này khiến tính năng "đúng mọi thứ bạn nói" vẫn vô dụng
- Phạm vi: gì làm, gì không làm trong phiên bản này
2. Định nghĩa "hoàn thành" (Definition of Done)
Đây là khái niệm quen thuộc trong quy trình phát triển phần mềm chuyên nghiệp: cụ thể hoá tiêu chí một tính năng được coi là xong. Với AI, hãy viết thành danh sách kiểm chứng được — ví dụ: "khi người dùng nhấn xuất báo cáo, file tải về chứa đúng các cột X, Y, Z; thời gian xử lý không khiến người dùng phải chờ quá lâu; hiển thị thông báo thân thiện khi không có dữ liệu". Có Definition of Done, bạn và AI cùng nhìn về một đích, và việc review kết quả cũng trở nên khách quan thay vì cảm tính.
3. Ràng buộc (constraints) kỹ thuật và phi kỹ thuật
AI không biết doanh nghiệp bạn có những giới hạn riêng nếu bạn không nói:
- Công nghệ: ngôn ngữ, framework, phiên bản phải bám theo hệ thống hiện có
- An toàn thông tin: không ghi log mật khẩu, không lộ dữ liệu khách hàng, tuân thủ quy định nội bộ
- Tích hợp: phải tương thích với API, cơ sở dữ liệu, quy ước đặt tên sẵn có
- Hiệu năng và tài nguyên: chạy trên máy chủ nào, chịu khối lượng bao nhiêu
Quy trình hóa thay cho "gõ prompt rồi cầu may"
Tín hiệu đáng chú ý là cộng đồng kỹ thuật đang giải quyết bài toán này một cách hệ thống. Matt Pocock — tác giả khoá học Total TypeScript nổi tiếng — vừa đẩy lên GitHub một repo dành riêng cho vấn đề "AI code sai vì yêu cầu không rõ", hướng tới việc biến việc giao việc cho AI thành quy trình có bước chuẩn bị tài liệu nghiêm túc thay vì trò chơi may rủi.
Xu hướng này rất đáng doanh nghiệp Việt Nam chú ý: lợi thế cạnh tranh thời AI không nằm ở việc đội nào có công cụ mạnh hơn (công cụ ai cũng dùng được), mà nằm ở việc đội nào chuẩn bị đầu vào tốt hơn và kiểm soát chất lượng đầu ra chặt chẽ hơn.
Góc nhìn cho doanh nghiệp Việt Nam
- Đào tạo kỹ năng viết spec cho đội ngũ. Đây là kỹ năng đầu tư một lần, dùng được cho cả giao việc cho AI lẫn giao việc cho nhân viên mới, cho thuê ngoài, hay đối tác thuê phần mềm.
- Áp dụng nguyên tắc "dự án nội bộ như dự án thuê ngoài". Nếu bạn không thể giao việc cho một công ty khác chỉ bằng một câu, thì cũng đừng giao cho AI bằng một câu.
- Kiểm soát chặt các thay đổi lớn. AI tạo code rất nhanh, nên ranh giới phê duyệt con người cần rõ ràng hơn, không phải lỏng lẻo hơn.
- Đầu tư vào tầng vận hành, không chỉ tầng prompt. Phân quyền tài khoản database, tách môi trường, cổng duyệt thao tác, nhật ký kiểm toán — đây mới là hàng rào thật sự của doanh nghiệp.
Kết luận
AI là người thực hiện xuất sắc nhất mà kỹ thuật phần mềm từng có — nhưng nó chỉ giỏi đúng mức chất lượng của yêu cầu nhận được. Câu chuyện "AI hỏi hai câu rồi code ra sai thứ bạn cần" sẽ tiếp tục lặp lại ở mọi doanh nghiệp coi giao việc cho AI là phím tắt bỏ qua bước chuẩn bị. Hãy đảo ngược thứ tự: viết spec rõ trước, giao AI sau. Đó là khoản đầu tư nhỏ nhất để AI trở thành lợi thế thật sự thay vì cỗ máy sản xuất code phải sửa lại.
Nguồn: tổng hợp từ chia sẻ kỹ thuật trên Facebook, biên tập bởi Wotech Electronics.
Doanh nghiệp của bạn đang chuẩn bị ứng dụng AI vào quy trình phát triển phần mềm? Liên hệ Wotech để được tư vấn thiết lập quy trình, tiêu chuẩn tài liệu yêu cầu và hạ tầng kỹ thuật phù hợp.
Bài viết liên quan

25 tháng 10, 2026 · 6 phut doc
Cẩm nang Claude Code 40.000 sao của kỹ sư Việt tại Paris: khai thác trọn sức mạnh AI
Claude Code đã trở thành công cụ quen thuộc với nhiều lập trình viên, nhưng theo một chia sẻ đang lan truyền trong cộng đồng kỹ thuật Việt Nam: phần lớn người dùng mới khai thác một phần nhỏ sức mạnh…

25 tháng 10, 2026 · 8 phut doc
Cảnh báo bảo mật: tấn công dò mật khẩu được AI tăng tốc, doanh nghiệp phòng thủ thế nào
Một công cụ mang tên BruteForceAI vừa xuất hiện trên GitHub và nhanh chóng thu hút 1,6 nghìn sao theo chia sẻ trong cộng đồng an ninh mạng: chương trình Python kết hợp mô hình ngôn ngữ lớn (LLM) với …

25 tháng 10, 2026 · 8 phut doc
Repo 240 nghìn sao GitHub nhưng không phải model AI: ECC là gì?
Một repo vừa cán mốc 240 nghìn sao và 36 nghìn fork trên GitHub — con số mà phần lớn dự án mã nguồn mở chỉ mơ ước. Điều bất ngờ: nó không phải một model AI mới. Vậy chính xác nó là gì, và bài học nào…