Cùng một công cụ AI, cùng một việc, hai người viết prompt khác nhau sẽ nhận về hai kết quả cách nhau rất xa. Bài này chỉ ra khoảng cách đó nằm ở đâu, qua một ví dụ cụ thể.

Prompt là đoạn văn bản bạn gõ cho AI. Chỉ có vậy.

Nhưng tôi để ý một chuyện: cùng một công việc, cùng một công cụ, có người nhận về thứ dùng được ngay, có người nhận về một đoạn văn nghe rất hay mà phải sửa lại gần hết. Và tệ hơn cả việc phải sửa, là có những chỗ sai mà đọc qua không nhận ra.

Khoảng cách đó không nằm ở AI. Nó nằm ở cách chúng ta đặt câu hỏi.

Tôi lấy một ví dụ, đầu vào là đoạn chat giữa PM và Pdm phía khách hàng về yêu cầu cho tính năng mới, viết prompt theo kiểu thông thường trước để mọi người thấy nó sai ở đâu, rồi sửa dần từng bước.

Cách nghĩ đúng ngay từ đầu

Anthropic, công ty làm ra Claude, có một cách ví von rất sát: hãy coi AI như một người mới vào công ty, rất thông minh nhưng chưa biết gì về công ty mình.

Bạn giao việc cho người mới đó thế nào thì viết prompt như vậy. Bạn sẽ không nói với người mới rằng “làm cái báo cáo giống hôm trước ấy”, vì họ không biết hôm trước là cái gì. AI cũng vậy. Nó không có mặt trong buổi họp của bạn, không đọc email của bạn, không biết khách hàng của bạn là ai.

Có một cách kiểm tra rất nhanh, cũng của Anthropic: đưa prompt của bạn cho một đồng nghiệp không nắm việc đó, nhờ họ làm theo. Nếu họ thấy khó hiểu thì AI cũng vậy.

Tình huống dùng xuyên suốt bài

Đây là đoạn chat giữa PM bên mình và PdM phía khách hàng (PdM là người phụ trách sản phẩm bên khách).

[08/18 09:12] Kimura (PdM khách)
Chào anh. Về màn hình danh sách khách hàng, chúng tôi muốn thêm chức năng
tìm kiếm và xuất file Excel. Bộ phận kinh doanh đang cần gấp.

[08/18 09:40] Hùng (PM bên mình)
Vâng anh. Anh cho tôi biết cần tìm kiếm theo những điều kiện nào ạ?

[08/18 10:05] Kimura (PdM khách)
Cơ bản là tên khách hàng, mã khách hàng, người phụ trách.
Các điều kiện khác thì linh hoạt là tốt nhất.

[08/18 10:30] Hùng (PM bên mình)
Về xuất Excel, anh cần những cột nào ạ?

[08/18 14:20] Kimura (PdM khách)
Giống như màn hình hiển thị là được. Bên công ty khác họ còn xuất được
cả biểu đồ nữa, nếu được thì tốt.

[08/19 11:15] Kimura (PdM khách)
À, bộ phận kinh doanh nói muốn lưu lại điều kiện tìm kiếm hay dùng.

[08/19 11:50] Hùng (PM bên mình)
Chúng tôi sẽ cố gắng đưa vào bản release tháng 8 ạ.

[08/20 09:05] Kimura (PdM khách)
Nhờ anh. À điều kiện tìm kiếm thì như đã trao đổi ở buổi họp hôm qua nhé.

[08/20 15:40] Hùng (PM bên mình)
Anh cho tôi hỏi thêm: dữ liệu khách hàng có chứa thông tin cá nhân,
vậy chức năng xuất file có cần giới hạn ai được xuất không ạ?

[08/21 10:10] Kimura (PdM khách)
Phần giới hạn thì tạm thời chưa cần. Ưu tiên tiến độ trước.

[08/21 16:25] Hùng (PM bên mình)
Vâng, chúng tôi hiểu rồi ạ.

[08/22 09:30] Kimura (PdM khách)
Số lượng dữ liệu khoảng 50 nghìn bản ghi. Xuất file nhanh là được.

[08/22 14:00] Kimura (PdM khách)
Ngoài ra bên kinh doanh muốn xuất được cả từ điện thoại.

Đọc qua thì thấy trao đổi khá suôn sẻ. Khách hợp tác, PM hỏi lại đầy đủ, không có gì căng thẳng.

Thực tế trong 13 tin nhắn này có hai vấn đề nghiêm trọng, và cách viết prompt thông thường sẽ không nhìn ra cái nào. Chúng ta sẽ quay lại ở phần cuối bài.

Thử cách viết thông thường trước

Phần lớn chúng ta sẽ dán đoạn chat trên rồi gõ:

Đọc đoạn chat này và viết yêu cầu cho đội phát triển.

Kết quả nhận về là một bản yêu cầu nghe rất hợp lý, đại khái như sau:

• Hệ thống cho phép tìm kiếm khách hàng theo nhiều điều kiện linh hoạt
• Hệ thống cho phép xuất file Excel bao gồm biểu đồ
• Hệ thống lưu lại điều kiện tìm kiếm thường dùng
• Hệ thống hỗ trợ xuất file từ điện thoại
• Tốc độ xuất file nhanh
• Dự kiến hoàn thành trong bản release tháng 9

Đọc thì mượt. Nhưng có bốn vấn đề:

Ba dòng trong đó khách chưa hề đồng ý. Xuất biểu đồ, lưu điều kiện tìm kiếm, dùng trên điện thoại, cả ba mới chỉ được nêu ra, chưa ai chốt.

“Linh hoạt” và “nhanh” thì không ai làm được. Đội phát triển không biết phải làm gì, và bên kiểm thử không có gì để đối chiếu xem đạt hay chưa đạt.

Dòng cuối là một cam kết tiến độ, mà AI vừa tự biến từ chữ “cố gắng” thành một mốc thời gian.

Toàn bộ phần về thông tin cá nhân biến mất.

Đây là kiểu sai đáng lo nhất khi dùng AI. Kết quả không sai lộ liễu, nó chỉ mượt và thiếu chính xác. Bạn đọc qua thấy ổn, gửi cho đội phát triển, hai tuần sau mới biết.

Giờ chúng ta sửa dần.

10 kỹ năng viết prompt

1. Nói rõ bạn muốn nhận về cái gì

Đây là kỹ năng quan trọng nhất, và cũng là kỹ năng bị bỏ qua nhiều nhất.

“Viết yêu cầu cho đội phát triển” là một câu mơ hồ. AI không biết bạn cần một bản yêu cầu, một danh sách câu hỏi, hay một bản đánh giá rủi ro. Nó sẽ đoán, và thường đoán ra thứ trung tính nhất.

Với tình huống trên, cái bạn thật sự cần là bốn thứ khác nhau:

Chia kết quả thành 4 nhóm, không được trộn lẫn:
A. Yêu cầu đã chốt được (đủ rõ để đội phát triển làm ngay)
B. Điểm còn mơ hồ, cần hỏi lại khách
C. Những câu PHÍA MÌNH đã nói mà khách có thể hiểu là cam kết
D. Những thứ chưa ai nhắc tới nhưng chắc chắn sẽ cần

Nhóm C là nhóm gần như không ai nghĩ tới. Trong đoạn chat có cả lời của mình, và lời của mình cũng cần được soi lại.

2. Dán dữ liệu lên trước, đặt yêu cầu xuống sau

Phản xạ tự nhiên là gõ yêu cầu trước rồi dán dữ liệu sau. Đó là thứ tự sai.

Tài liệu chính thức của Anthropic ghi rõ: với dữ liệu dài, đặt dữ liệu lên phía trên phần yêu cầu, chất lượng câu trả lời tăng tới 30%.

Thứ tự đúng:

[dữ liệu: đoạn chat, tài liệu, số liệu]
[bối cảnh]
[yêu cầu của bạn]
[câu chốt: "Hãy làm theo yêu cầu ở trên"]

Chỉ đổi thứ tự, không thêm chữ nào. Đây là kỹ năng dễ áp dụng nhất trong cả bài này.

3. Đóng khung dữ liệu bằng nhãn

Nếu bạn dán tất cả thành một khối liền, AI không phân biệt được đâu là dữ kiện, đâu là chỉ đạo của bạn. Khi không phân biệt được, nó bắt đầu tự bù thông tin cho hợp lý. Nói cách khác là bịa.

Cách sửa: bọc từng loại nội dung trong một cặp nhãn <tên_nhãn> và </tên_nhãn>. Đặt tên gì cũng được, miễn dễ hiểu.

<doan_chat>
[dán đoạn chat ở đây]
</doan_chat>

<boi_canh>
Hệ thống quản lý khách hàng. Màn hình danh sách hiện có 12 cột.
Dữ liệu có chứa thông tin cá nhân của khách hàng cuối.
Đội: 4 lập trình viên, 1 kiểm thử. Bản release gần nhất: tháng 9.
</boi_canh>

<yeu_cau>
[việc bạn muốn AI làm]
</yeu_cau>

Cách này nghe kỹ thuật nhưng thực chất chỉ là đóng gói cho gọn. Ai cũng làm được, và hiệu quả thấy ngay.

4. Cho AI biết ai là ai

Trong một đoạn chat nhiều người, không phải lời ai cũng có giá trị như nhau. Nếu không nói rõ, AI coi mọi câu ngang nhau, và ý kiến cá nhân của một người sẽ thành yêu cầu chính thức.

<vai_tro>
Kimura: PdM phía khách, CÓ quyền quyết định về chức năng và ưu tiên
Hùng: PM phía mình, mọi câu người này nói đều là cam kết của công ty,
      cần soi riêng thành một nhóm
</vai_tro>

Dòng thứ hai là chỗ ít người nghĩ tới: tự đưa mình vào diện bị kiểm tra. Đây lại là chỗ tìm ra rủi ro lớn nhất.

5. Nói cả điều không được làm

Liệt kê việc nên làm thì ai cũng nghĩ ra. Nhưng phần lớn lỗi của AI đến từ những việc bạn không ngờ nó sẽ tự làm. Nói trước, rất hiệu quả.

<khong_duoc>
- KHÔNG ghi số ngày hay man-month. Khối lượng chỉ ghi Cao / Trung bình / Thấp.
- KHÔNG suy đoán nội dung buổi họp không có trong đoạn chat.
  Nếu không có thì ghi "cần xác nhận lại".
- KHÔNG biến mong muốn ("nếu được thì tốt") thành yêu cầu chính thức.
- KHÔNG bỏ qua vấn đề bảo mật chỉ vì khách nói "tạm thời chưa cần".
- KHÔNG thêm bất cứ nội dung nào không có trong đoạn chat.
</khong_duoc>

Với ví dụ của chúng ta, năm dòng này một mình đã chặn được cả bốn lỗi ở bản thông thường phía trên.

6. Bắt trích dẫn, cách duy nhất để kiểm tra lại

Không có bước này, bạn không có cách nào biết dòng nào là của khách và dòng nào AI tự thêm.

Mỗi kết luận phải kèm câu trích nguyên văn từ đoạn chat và số tin nhắn
(ví dụ: căn cứ #5). Trích thì để nguyên, không tóm tắt lại.
Nếu không trích được thì ghi "cần xác nhận", không đưa vào nhóm A.

Còn một lợi ích nữa: bảng kết quả trở thành thứ có thể lần lại được. Sau này nếu hai bên có tranh luận về phạm vi công việc, bạn chỉ ra được ngay dòng nào bắt nguồn từ tin nhắn nào, ngày nào. Khách hàng Nhật rất coi trọng điều này.

7. Đưa danh sách kiểm tra cụ thể, đừng nói “kiểm tra giúp tôi”

Nói “kiểm tra xem có chỗ nào mơ hồ không” sẽ nhận về nhận xét chung chung. Đưa một danh sách cụ thể thì AI soi được từng chữ, và quan trọng hơn là nó gọi được tên vấn đề. Gọi được tên thì bạn mới giải thích cho khách được.

Dưới đây là 9 dấu hiệu của một câu nói chưa làm được. Danh sách này lấy từ một nghiên cứu về chất lượng yêu cầu phần mềm, mọi người có thể dán nguyên khối vào prompt.

<dau_hieu_mo_ho>
Quét từng câu, tìm 9 dấu hiệu sau:
1. Từ cảm tính: dễ dùng, thân thiện, hợp lý, phù hợp
2. Từ chỉ mức độ nhưng không có số: nhanh, đủ, nhiều, hầu hết
3. Từ để ngỏ: nếu có thể, khi cần thiết, ở mức thích hợp
4. Từ so sánh với tất cả: tốt nhất, linh hoạt nhất, tối đa có thể
5. Từ so sánh với một cái khác: nhanh hơn hệ thống cũ, giống bên công ty khác
6. Câu nói không được làm gì nhưng không nói rõ với ai:
   "người ngoài không được xem" (ai là người ngoài?)
7. Nói "cái đó", "phần kia" mà không rõ là cái nào
8. Câu chừa đường lùi: về cơ bản, thông thường, nói chung
9. Nhắc tới một thứ mà người đọc không có: theo quy định nội bộ,
   làm như cũ, như đã bàn hôm trước
</dau_hieu_mo_ho>

8. Vẽ sẵn khuôn kết quả

Nếu không nói rõ muốn nhận về dạng gì, bạn sẽ mất thêm 30 phút định dạng lại. Cứ vẽ sẵn cái bảng mình muốn.

<khuon_ket_qua>
## A. Yêu cầu đã chốt
| ID | Yêu cầu | Căn cứ # | Cách kiểm thử |

## B. Cần hỏi lại khách
| # | Trích nguyên văn | Dấu hiệu mơ hồ | Câu hỏi | Phương án mình đề xuất | Có chặn việc phát triển? |

## C. Cam kết từ phía mình
| # | Trích | Khách có thể hiểu là gì | Rủi ro | Cách làm rõ lại |

## D. Còn thiếu
| Điểm thiếu | Câu hỏi | Hậu quả nếu phát hiện muộn |
</khuon_ket_qua>

Hai chi tiết nhỏ nhưng hiệu quả cao:

Cột “Có chặn việc phát triển?” ở bảng B tách ngay câu phải hỏi hôm nay ra khỏi câu hỏi được sau. Không có cột này, bạn nhận về 15 câu hỏi dàn hàng ngang và không biết nên hỏi cái nào trước.

Nếu cần đưa vào Excel hoặc công cụ quản lý công việc, thêm một dòng: “Cuối cùng xuất lại bảng A dưới dạng CSV để import.”

9. Chia làm nhiều bước, đừng làm một lần

Ba việc dưới đây là ba kiểu suy nghĩ khác nhau. Gộp một lượt thì việc thứ hai và thứ ba luôn bị làm sơ sài.

Nghe như mất thời gian hơn, nhưng thực tế nhanh hơn, vì không phải làm lại từ đầu.

10. Bắt AI tự phản biện

Đừng dùng kết quả đầu tiên. Hai câu ngắn này thường lôi ra nhiều thứ nhất:

Đọc lại kết quả với vai PdM phía khách hàng. Chỗ nào anh thấy phía chúng tôi
đang né tránh, hoặc đang tự hiểu theo hướng có lợi cho mình?

Đọc lại với vai người kiểm tra bảo mật. Trong đoạn chat này, phía mình đã ngầm
đồng ý điều gì mà lẽ ra phải ghi nhận lại bằng văn bản?

Câu thứ hai là câu tìm ra vấn đề nghiêm trọng nhất trong ví dụ của chúng ta.

Kết quả sau khi áp dụng đủ 10 kỹ năng

Yêu cầu chốt được: 2 dòng

Hết. Sau 13 tin nhắn và 5 ngày trao đổi, chỉ chốt được 2 dòng.

Đây không phải kết quả tệ. Đây là kết quả đúng. Biết mình chỉ có 2 dòng vào ngày 22/07 tốt hơn nhiều so với tưởng mình có 6 dòng, rồi phát hiện ra sự thật vào cuối tháng 8.

Cần hỏi lại khách: 7 điểm

Mọi người để ý cách viết câu hỏi ở cột phải. Tất cả đều là câu hỏi đóng, và đều kèm sẵn phương án của mình. Đây là chi tiết nhỏ nhưng đổi lại rất nhiều:

“Anh muốn làm thế nào ạ?” thường được trả lời sau 5 ngày, hoặc không được trả lời.

“Chúng tôi dự kiến làm theo phương án X. Nếu không có vấn đề gì, chúng tôi sẽ tiến hành.” thường được trả lời trong 1 giờ.

Câu thứ hai dễ trả lời hơn nhiều. Và nếu khách im lặng, mình vẫn có cơ sở để tiến hành.

Hai chỗ chỉ prompt tốt mới nhìn ra

Chỗ thứ nhất: câu nói của chính chúng ta

#7 Hùng: “Chúng tôi sẽ cố gắng đưa vào bản release tháng 8 ạ.”

Ở thời điểm nói câu này, phạm vi công việc vẫn chưa được xác định. Còn 7 điểm mơ hồ, trong đó ba thứ có thể là hạng mục lớn: xuất biểu đồ, lưu điều kiện tìm kiếm, và dùng trên điện thoại.

Với người Việt, “chúng tôi sẽ cố gắng” nghĩa là “chúng tôi sẽ nỗ lực, chưa chắc chắn”. Với đối tác Nhật, câu này được ghi nhận gần như một lời hứa. Và câu #8 “Nhờ anh” chính là xác nhận đã tiếp nhận lời hứa đó.

Đây là khoảng cách trong cách hiểu, và nó gây thiệt hại thật.

Cách xử lý là không rút lời, nhưng gắn điều kiện rõ ràng bằng một tin nhắn mới:

“Về bản release tháng 9: chúng tôi có thể cam kết phần tìm kiếm và xuất Excel cơ bản. Các hạng mục xuất biểu đồ, lưu điều kiện tìm kiếm và hỗ trợ điện thoại cần xác nhận thêm, nên chưa đưa vào cam kết lần này.”

Nếu prompt của bạn không có nhóm C, phát hiện này không bao giờ xuất hiện.

Chỗ thứ hai: hỏi đúng, nhưng kết thúc sai

#9 Hùng: dữ liệu có thông tin cá nhân, chức năng xuất file có cần giới hạn ai được xuất không ạ?

#10 Kimura: “Phần giới hạn thì tạm thời chưa cần. Ưu tiên tiến độ trước.”

#11 Hùng: “Vâng, chúng tôi hiểu rồi ạ.”

Ba tin nhắn này trông vô hại nhất trong cả đoạn chat, nhưng lại là chỗ rủi ro cao nhất.

PM đã làm rất đúng ở #9. Nhận ra vấn đề và hỏi thẳng. Nhưng #11 làm mất hết giá trị của #9.

“Vâng, chúng tôi hiểu rồi ạ” nghe như một câu lịch sự thông thường. Vấn đề là nếu sau này xảy ra rò rỉ dữ liệu, câu này trở thành bằng chứng rằng bên phát triển đã biết rủi ro và không nói gì.

Và hãy hình dung cái sẽ được xây nếu làm đúng theo #10: một chức năng cho phép bất kỳ người dùng nào xuất toàn bộ 50.000 bản ghi có thông tin cá nhân ra file Excel, không giới hạn, không ghi lại. Phần lớn các vụ rò rỉ dữ liệu trên thực tế xảy ra đúng theo kịch bản này. Không phải bị tấn công, mà là một lần xuất file hợp lệ rồi file đi ra ngoài.

Ba việc nên làm trong tình huống như vậy:

Ghi nhận lại bằng văn bản, không tranh cãi. Đăng lên Slack một câu: “Về việc giới hạn người dùng khi xuất file: chúng tôi hiểu rằng lần này sẽ chưa triển khai theo chỉ đạo ưu tiên tiến độ. Vì dữ liệu có chứa thông tin cá nhân, chúng tôi xin ghi nhận đây là quyết định của phía quý công ty.” Cách này vừa bảo vệ được mình, vừa đúng văn hóa báo cáo của Nhật, minh bạch và không đẩy trách nhiệm cho ai.

Đề xuất mức tối thiểu thay vì bỏ hẳn. Chỉ cần ghi lại ai xuất file, lúc nào, bao nhiêu bản ghi. Chi phí rất thấp, không cần xin thêm ngân sách, nhưng nếu sau này có sự cố thì mọi thứ khác hoàn toàn.

Nhớ nguyên tắc này: khi phía khách gạt đi một yêu cầu về bảo mật hoặc dữ liệu cá nhân, đừng trả lời “chúng tôi hiểu rồi”. Hãy ghi nhận lại bằng văn bản.

Prompt hoàn chỉnh

Bản gộp cả 10 kỹ năng. Mọi người sao chép và thay nội dung trong ngoặc vuông.

Bạn là chuyên gia phân tích yêu cầu, có kinh nghiệm dự án với khách hàng Nhật.

<doan_chat>
[dán nguyên văn đoạn chat, giữ đủ ngày giờ và tên người gửi]
</doan_chat>

<vai_tro>
[Tên]: PdM phía khách, CÓ quyền quyết định về chức năng và ưu tiên
[Tên]: PM phía mình, mọi câu người này nói là cam kết của công ty, soi riêng
</vai_tro>

<boi_canh>
Hệ thống: [mô tả ngắn]
Đặc điểm dữ liệu: [có hoặc không chứa thông tin cá nhân]
Đội: [số người]. Bản release gần nhất: [thời điểm]
</boi_canh>

<dau_hieu_mo_ho>
Quét từng câu tìm 9 dấu hiệu: từ cảm tính / từ chỉ mức độ không có số /
từ để ngỏ / từ so sánh với tất cả / từ so sánh với cái khác /
câu nói không được làm gì nhưng không rõ với ai / nói "cái đó" không rõ là gì /
câu chừa đường lùi / nhắc tới thứ người đọc không có
</dau_hieu_mo_ho>

<yeu_cau>
Chia kết quả thành 4 nhóm:

A. Yêu cầu chốt được. Chỉ lấy từ câu rõ ràng của người có quyền quyết định.
   Viết theo mẫu: "Khi [điều kiện], hệ thống PHẢI [hành vi], [tiêu chí đo được]".
   Mỗi yêu cầu chỉ nói về MỘT việc. Nếu phải dùng chữ "và" để ghép hai việc
   thì tách thành hai yêu cầu.

B. Điểm mơ hồ. Gọi tên dấu hiệu theo <dau_hieu_mo_ho>, kèm câu hỏi đóng
   và phương án mình đề xuất sẵn.

C. Cam kết từ phía mình. Soi mọi câu của PM bên mình, chỉ ra câu nào khách
   có thể ghi nhận là lời hứa, và rủi ro tương ứng.

D. Còn thiếu. Những thứ chưa ai nhắc nhưng chắc chắn cần: ai được dùng chức năng,
   có ghi lại lịch sử không, xử lý khi lỗi, dữ liệu cũ, thiết bị hỗ trợ.
   Nêu riêng mọi yêu cầu bảo mật bị hạ ưu tiên trong đoạn chat.
</yeu_cau>

<khong_duoc>
- KHÔNG ghi số ngày hay man-month. Khối lượng chỉ ghi Cao / Trung bình / Thấp.
- KHÔNG suy đoán nội dung buổi họp không có trong đoạn chat.
- KHÔNG biến mong muốn thành yêu cầu chính thức.
- KHÔNG bỏ qua vấn đề bảo mật chỉ vì khách nói "tạm thời chưa cần".
- Mọi kết luận kèm trích nguyên văn và số tin nhắn. Không trích được thì ghi
  "cần xác nhận", không đưa vào nhóm A.
</khong_duoc>

<khuon_ket_qua>
A. | ID | Yêu cầu | Căn cứ # | Cách kiểm thử |
B. | # | Trích | Dấu hiệu | Câu hỏi | Đề xuất của mình | Chặn việc phát triển? |
C. | # | Trích | Khách có thể hiểu là gì | Rủi ro | Cách làm rõ lại |
D. | Điểm thiếu | Câu hỏi | Hậu quả nếu phát hiện muộn |
</khuon_ket_qua>

Hãy phân tích đoạn chat theo <yeu_cau>.

Danh sách kiểm tra 60 giây

Trước khi bấm gửi prompt, soát 7 ô này:

Những câu đừng viết trong prompt

Nếu chỉ nhớ được ba điều

Nói rõ mình muốn nhận về cái gì, chia thành mấy phần. Đây là kỹ năng đổi lại nhiều nhất so với công sức bỏ ra.

Bắt AI trích dẫn nguyên văn cho mọi kết luận. Không trích được thì đừng tin.

Nêu cả điều không được làm. Phần lớn lỗi nằm ở những việc mình không ngờ AI sẽ tự làm.

Và một câu để nhớ lâu hơn cả ba điều trên: AI không biết điều bạn không nói. Nó không đoán được bối cảnh trong đầu bạn, không biết ai là người quyết định, không biết con số nào là số bạn không được phép bịa. Tất cả những thứ đó, nếu quan trọng, thì phải viết ra.

Nguồn tham khảo: tài liệu Prompting best practices của Anthropic, khoá học thực hành Prompt Engineering Interactive Tutorial (miễn phí, 9 chương), tiêu chuẩn ISO/IEC/IEEE 29148 về đặc tính của một yêu cầu tốt, và nghiên cứu Requirements Smells của Femmer cùng cộng sự, nơi anh lấy danh sách 9 dấu hiệu câu nói mơ hồ.