Specification Engineering: Kỹ năng mới sau Prompt Engineering

Trong hai năm qua, người dùng đã học cách nhận được kết quả tốt hơn từ các mô hình ngôn ngữ lớn (LLM) bằng cách viết prompt rõ ràng hơn: bổ sung ngữ cảnh, xác định vai trò, đưa ví dụ, chỉ định định dạng đầu ra và liên tục điều chỉnh. Những kỹ thuật này vẫn rất hữu ích. Tuy nhiên, khi AI đang dần chuyển từ chatbot sang coding agent, trợ lý nghiên cứu, công cụ hỗ trợ khoa học dữ liệu và các quy trình tự động hóa, prompt tốt thôi là chưa đủ.

Kỹ năng mới đang nổi lên là Specification Engineering, có thể hiểu là kỹ thuật xây dựng đặc tả cho AI. Đây là khả năng xác định rõ mục tiêu, các ràng buộc, đầu ra mong muốn, trường hợp ngoại lệ, phương thức kiểm thử, tiêu chí thành công và những tình huống có thể khiến hệ thống thất bại trong một tác vụ có sự hỗ trợ của AI. Nói đơn giản, Prompt Engineering là cách bạn đặt câu hỏi, còn Specification Engineering là cách bạn định nghĩa thế nào mới được xem là hoàn thành công việc một cách chính xác.

Vì sao Prompt Engineering không còn đủ?

Một prompt có thể tạo ra một câu trả lời trông rất thuyết phục. Nhưng một specification mới xác định được liệu câu trả lời đó có thực sự đạt yêu cầu hay không.

Sự khác biệt này ngày càng quan trọng bởi AI hiện đại không chỉ tạo ra các đoạn văn. Chúng có thể viết truy vấn SQL, chỉnh sửa mã nguồn, phân tích bảng tính, tạo JSON theo cấu trúc, xây dựng ứng dụng và thực hiện những chuỗi quyết định gồm nhiều bước. Trong những trường hợp như vậy, câu hỏi quan trọng không chỉ là "Mô hình có thể trả lời hay không?", mà còn phải là: kết quả có đáp ứng đúng yêu cầu không, có tuân thủ các ràng buộc không, có xử lý những trường hợp ngoại lệ không, có thể kiểm tra kết quả không, hệ thống khác có thể sử dụng đầu ra đó không và liệu AI có đang tối ưu nhầm mục tiêu hay không?

Câu hỏi cuối cùng đặc biệt quan trọng. Các nhà nghiên cứu về an toàn AI từ lâu đã nghiên cứu hiện tượng specification gaming, trong đó hệ thống AI hoàn thành đúng mục tiêu được viết ra nhưng lại bỏ qua kết quả thực sự mà con người mong muốn.

Đây cũng chính là vấn đề chúng ta đang gặp trong công việc hằng ngày với AI. Chẳng hạn, yêu cầu một coding agent "sửa lỗi" có thể khiến nó tạo ra một bản vá vượt qua bài kiểm thử mà người dùng nhìn thấy nhưng lại phá vỡ một giả định ẩn trong hệ thống. Yêu cầu AI "tóm tắt báo cáo" có thể tạo ra một bản tóm tắt mạch lạc nhưng bỏ qua đúng chỉ số mà ban lãnh đạo quan tâm nhất. Hay khi yêu cầu "làm sạch dữ liệu", AI có thể âm thầm loại bỏ những dòng dữ liệu đáng lẽ cần được giữ lại để điều tra.

Prompt đã làm đúng phần việc của nó. Nhưng specification mới là thứ thất bại.

Specification Engineering thực sự là gì?

Specification Engineering là quá trình biến một nhiệm vụ mơ hồ thành một tập hợp hướng dẫn có thể thực thi, kiểm thử và đánh giá.

Một prompt đơn giản có thể chỉ là:

"Hãy phân tích tập dữ liệu khách hàng rời bỏ và cho tôi biết những thông tin đáng chú ý."

Trong khi đó, một specification đầy đủ hơn sẽ yêu cầu:

"Hãy phân tích tập dữ liệu khách hàng rời bỏ này. Xác định các giá trị bị thiếu, tình trạng mất cân bằng giữa các lớp dữ liệu, nguy cơ rò rỉ dữ liệu và những đặc trưng có khả năng dự đoán cao nhất. Chia dữ liệu thành tập huấn luyện và kiểm thử trước khi thực hiện tiền xử lý. So sánh logistic regression, random forest và XGBoost. Báo cáo accuracy, precision, recall, F1, ROC-AUC, PR-AUC và ma trận nhầm lẫn. Không đưa ra kết luận về quan hệ nhân quả. Đưa ra ba đề xuất kinh doanh và chỉ liên hệ chúng với những mối tương quan quan sát được."

Phiên bản thứ hai không chỉ đơn thuần là một prompt. Nó định nghĩa toàn bộ công việc.

Một specification tốt thường bao gồm 8 thành phần chính:

1. Mục tiêu: Mô hình cần đạt được điều gì?

2. Ngữ cảnh: AI cần biết những thông tin nào?

3. Đầu vào: Dữ liệu, tệp, công cụ hoặc giả định nào được phép sử dụng?

4. Định dạng đầu ra: Kết quả cuối cùng phải được trình bày như thế nào?

5. Ràng buộc: AI cần tránh những điều gì?

6. Tiêu chí đánh giá: Dựa vào đâu để xác định kết quả là chính xác?

7. Trường hợp ngoại lệ: Những tình huống nào có thể khiến hệ thống hoạt động sai?

8. Các bước xác minh: Những bài kiểm tra hoặc kiểm tra chéo nào phải được thực hiện?

Đó cũng là lý do Specification Engineering có nhiều điểm tương đồng với quản lý sản phẩm, kiểm thử phần mềm, xác thực dữ liệu và thiết kế nghiên cứu hơn là kỹ thuật viết prompt truyền thống.

Một nghiên cứu năm 2024 về Requirement-Oriented Prompt Engineering cho rằng nhiều chương trình đào tạo prompt hiện nay tập trung vào những kỹ thuật như nhập vai hoặc yêu cầu AI "suy nghĩ từng bước", trong khi việc sử dụng LLM cho những tác vụ phức tạp lại phụ thuộc nhiều hơn vào khả năng diễn đạt yêu cầu rõ ràng. Trong một nghiên cứu ngẫu nhiên với 30 người chưa có kinh nghiệm, nhóm được đào tạo theo phương pháp ROPE cải thiện khả năng viết yêu cầu thêm 20%, trong khi nhóm được đào tạo prompt engineering truyền thống chỉ cải thiện 1%. Các tác giả cũng nhận thấy mối liên hệ trực tiếp giữa chất lượng yêu cầu đầu vào và chất lượng đầu ra của LLM.

Xu hướng tương tự cũng xuất hiện trong những công cụ AI dành cho môi trường thực tế. Tính năng Structured Outputs của OpenAI cho phép nhà phát triển giới hạn phản hồi của mô hình để tuân thủ một JSON schema cụ thể, với khả năng tuân thủ schema nghiêm ngặt được thể hiện trong các bài đánh giá của OpenAI. Đây chính là Specification Engineering dưới dạng API: thay vì hy vọng mô hình trả về JSON hợp lệ, nhà phát triển định nghĩa trước cấu trúc mà kết quả bắt buộc phải tuân theo.

Model Spec của OpenAI và Constitution của Anthropic cũng thể hiện cùng một tư tưởng ở cấp độ hành vi của mô hình. OpenAI mô tả Model Spec là tài liệu quy định cách các mô hình của hãng nên hành xử trong ChatGPT và API, trong khi Constitutional AI của Anthropic sử dụng những nguyên tắc được viết rõ ràng để định hướng hành vi của mô hình.

Nói cách khác, chính ngành AI cũng đang dần chuyển từ prompt sang specification.

Từ Vibe Coding đến Spec-Driven Coding

Sự khác biệt này thể hiện rất rõ trong lĩnh vực lập trình với AI.

Cách tiếp cận theo Prompt Engineering có thể chỉ yêu cầu:

"Hãy xây dựng cho tôi một ứng dụng quản lý chi tiêu đơn giản."

Trong khi đó, cách tiếp cận theo Specification Engineering sẽ cụ thể hơn nhiều:

"Xây dựng ứng dụng quản lý chi tiêu bằng React với các chức năng thêm, chỉnh sửa, xóa, lọc theo danh mục, tính tổng chi tiêu hàng tháng và lưu dữ liệu bằng local storage. Kiểm tra để đảm bảo số tiền phải lớn hơn 0, ngày giao dịch là bắt buộc và người dùng phải chọn danh mục. Viết unit test cho chức năng thêm, xóa, lọc và tính tổng. Không sử dụng API trả phí bên ngoài. Trả về cấu trúc tệp trước, sau đó triển khai từng tệp."

Phiên bản thứ hai giúp AI có ít không gian hơn để tự ý đưa ra những quyết định có thể gây ra vấn đề.

Điều này ngày càng quan trọng bởi các benchmark về kỹ thuật phần mềm đang chuyển sang đánh giá những vấn đề thực tế, bài kiểm thử và khả năng xác minh. Chẳng hạn, SWE-bench đánh giá khả năng xử lý các issue thực tế trên GitHub bằng cách chỉnh sửa codebase, thay vì chỉ tạo ra những đoạn mã độc lập. SWE-bench Verified của OpenAI được xây dựng như một tập con đã được con người xác minh nhằm đánh giá đáng tin cậy hơn khả năng giải quyết vấn đề phần mềm trong thực tế.

Tuy nhiên, ngay cả bài kiểm thử cũng không hoàn hảo. Một nghiên cứu về các bản vá do agent tạo ra trên SWE-bench Verified cho thấy ngay cả những bản vá vượt qua bài test vẫn có thể khác biệt đáng kể so với bản vá do con người viết, qua đó cho thấy những hạn chế trong phạm vi bao phủ của benchmark. Một nghiên cứu khác mang tên SWT-Bench nhận thấy các bài kiểm thử được tạo ra có thể đóng vai trò như một bộ lọc hiệu quả đối với các bản sửa lỗi được đề xuất, qua đó tăng gấp đôi độ chính xác của SWE-Agent.

Quy trình làm việc mới với AI

Quy trình làm việc với AI trong tương lai sẽ không còn đơn giản theo kiểu:

prompt → kết quả → sửa thủ công

Thay vào đó, nó sẽ giống:

specification → tạo kết quả → xác thực → chỉnh sửa → kiểm toán

Chẳng hạn, quy trình có thể gồm các bước: viết specification cho nhiệm vụ; yêu cầu AI xác định những yêu cầu còn thiếu; yêu cầu AI tạo giải pháp; chạy các bài kiểm thử hoặc kiểm tra; yêu cầu AI chỉ sửa những vấn đề được phát hiện qua các bước kiểm tra; cuối cùng ghi lại những giả định và hạn chế của kết quả.

Cách tiếp cận này đặc biệt quan trọng với các hệ thống agentic. Hướng dẫn thực tế về agent của OpenAI khuyến nghị chia những tài nguyên hoặc nhiệm vụ phức tạp thành các bước nhỏ, rõ ràng hơn và đảm bảo mỗi bước đều gắn với một hành động hoặc đầu ra cụ thể. Đây chính là Specification Engineering được áp dụng vào quy trình làm việc.

Nghiên cứu DORA của Google cũng củng cố xu hướng này. Báo cáo khảo sát gần 5.000 chuyên gia công nghệ và kết luận rằng AI hoạt động như một bộ khuếch đại đối với những điểm mạnh cũng như điểm yếu vốn có của tổ chức. Nền tảng tốt và quy trình chất lượng giúp doanh nghiệp tận dụng AI hiệu quả hơn. Ngược lại, những quy trình yếu cũng sẽ bị AI khuếch đại.

Đây là điều các doanh nghiệp cần đặc biệt lưu ý. AI không loại bỏ nhu cầu về kỷ luật kỹ thuật. Ngược lại, nó làm tăng giá trị của việc sở hữu một quy trình kỹ thuật tốt.

Prompt Engineering chưa biến mất. Nó đang trở thành một phần của một kỹ năng rộng lớn hơn.

Giai đoạn đầu của kỷ nguyên AI thưởng cho những người biết cách khiến chatbot đưa ra câu trả lời tốt hơn. Giai đoạn tiếp theo sẽ ưu ái những người có khả năng thiết kế các quy trình AI đáng tin cậy, với yêu cầu rõ ràng, đầu ra có cấu trúc, cơ chế đánh giá và những ranh giới được xác định cụ thể.

Kỹ năng quan trọng giờ đây không còn chỉ là đặt câu hỏi:

"Làm thế nào để khiến mô hình trả lời?"

Mà phải là:

"Làm thế nào để định nghĩa nhiệm vụ để mô hình, người dùng và người đánh giá cùng thống nhất thế nào là một câu trả lời chính xác?"

Đó chính là Specification Engineering. Khi các hệ thống AI ngày càng trở nên tự chủ, đây có thể trở thành một trong những kỹ năng kỹ thuật quan trọng nhất tiếp theo sau Prompt Engineering.