Lời nhắc xây dựng thực sự cần chứa những gì?
Bốn điều, và tôi nói vậy sau khi chứng kiến khoảng hai trăm lời nhắc như thế này biến thành các trang web hoàn chỉnh: đó là gì, dành cho ai, những yêu cầu bắt buộc, và — tùy chọn — một phong cách. Mọi thứ khác là nhiễu mà công cụ xây dựng sẽ tự điền bằng giá trị mặc định, nên kỹ năng thực sự không phải là viết nhiều hơn, mà là nhận ra mình thực sự có ý kiến về điều nào trong bốn điều này rồi chỉ nói điều đó thôi.
Bắt đầu với đó là gì, và giữ nó ở mức một danh mục, không phải một bản đặc tả. "Một trang đặt lịch cho phòng tập yoga" tốt hơn "một trang nơi mọi người xem giờ và nhấn nút để đặt chỗ và nhận xác nhận" mặc dù câu thứ hai chứa nhiều thông tin hơn. Danh mục kích hoạt các giá trị mặc định mà công cụ xây dựng đã có sẵn — lịch trình trông giống lịch trình, luồng đặt chỗ trông giống luồng đặt chỗ — trong khi mô tả buộc nó phải tái tạo lại danh mục từ đầu.
Tôi có cần nói rõ đối tượng là ai không?
Bạn không bắt buộc phải nói, nhưng đây là dòng mà mọi người thường bỏ qua trong khi không nên. "Dành cho học viên hiện tại của phòng tập" và "dành cho những người mới biết đến phòng tập lần đầu" tạo ra các trang web khác nhau ở hầu hết những điểm quan trọng — giọng điệu câu chữ, có nên có một hero marketing lớn hay bố cục đi thẳng vào lịch, giá cả có nằm ở phía trước (khách mới cần điều đó) hay được giấu đi (khách quen đã biết rồi). Một mệnh đề ở đây có thể giải quyết cả trăm điểm mơ hồ nhỏ mà một trang danh sách tính năng không bao giờ làm được. Nếu đối tượng thực sự là chung chung, hãy bỏ qua nó — đừng bịa ra một đối tượng chỉ để lấp đầy chỗ trống.
Tôi nên liệt kê bao nhiêu yêu cầu bắt buộc?
Hai hoặc ba. Bài kiểm tra tôi dùng: bạn có từ chối bản dựng đầu tiên nếu thiếu cái này không? "Lịch lớp học, thanh toán trực tuyến, tiểu sử giáo viên" vượt qua bài kiểm tra đó đối với một phòng tập yoga — thiếu lịch thì đó không phải là phiên bản nhỏ hơn của trang web, mà là một trang web khác. "Đăng ký nhận bản tin ở chân trang" hầu như không bao giờ vượt qua; đó là một tính năng có thì tốt, và các tính năng có thì tốt nên nằm trong cuộc trò chuyện tiếp theo sau khi bạn đã thấy kế hoạch, chứ không nên nhồi nhét vào lời nhắc ban đầu, nơi chúng cạnh tranh với những thứ thực sự quan trọng.
Đây thực sự là thành phần mà mọi người làm hỏng tệ nhất, theo cả hai hướng. Không có yêu cầu bắt buộc nào thì công cụ xây dựng phải đoán, đôi khi sai. Tám yêu cầu bắt buộc thì công cụ xây dựng coi cả tám đều quan trọng như nhau, và kết quả trả về đọc như một danh sách tính năng khoác áo trang web — không có thứ bậc, không có khoảng thở. Nếu phải phản đối việc bỏ qua một thành phần, thì đây chính là thành phần đó. Ngay cả một mệnh đề duy nhất về "hai điều khiến cái này là của riêng bạn" cũng tiết kiệm được gần như một vòng trao đổi mỗi lần, vì đó là mảnh thông tin duy nhất mà công cụ xây dựng không có cách nào suy luận được chỉ từ danh mục.
Tôi có nên chỉ định một phong cách không?
Chỉ khi bạn thực sự có một định hướng. Rất nhiều prompt tốt bỏ qua phần này hoàn toàn, và điều đó không sao cả — giám đốc thiết kế vẫn sẽ cam kết một định hướng nghệ thuật dù bạn có chỉ định hay không. Một cụm mô tả tâm trạng ngắn gọn ("ấm áp và vẽ tay," "lâm sàng và nhanh," "như thùng game arcade thập niên 90") chỉ đơn giản là hướng cam kết đó vào một nơi cụ thể thay vì để mặc cho mặc định của danh mục. Nếu bạn có phản ứng mạnh — bạn biết mình muốn nền màu kem và chữ serif ấm áp, hoặc bạn biết mình ghét góc bo tròn — hãy dùng đến câu đó. Nhân tiện, "sạch sẽ và hiện đại" không tính. Đó không phải là một tâm trạng, mà là sự vắng mặt của tâm trạng, và nó không định hướng gì cả trong khi vẫn tốn của bạn một chỗ trống.
Sao tôi không mô tả hết mọi thứ tôi đang nghĩ?
Vì công cụ dựng sẽ tuân theo. Đó mới là kiểu lỗi thực sự, và nó không giống những gì người ta thường nghĩ — không phải là quá nhiều thông tin làm công cụ dựng bối rối, mà là mỗi câu bạn viết đều được đọc như một chỉ thị, kể cả những câu còn nửa vời mà bạn sẵn sàng bỏ qua nếu đọc lại lần hai. Tôi đã từng thấy ai đó viết "có thể thêm một phần đánh giá của khách hàng, chưa chắc lắm" và nhận lại một phần đánh giá khách hàng với ba trích dẫn giữ chỗ, vì "có thể, chưa chắc lắm" là một câu rào đón đối với người đọc là con người nhưng lại là một yêu cầu tính năng đối với một hệ thống hiểu theo đúng nghĩa đen lời bạn nói.
Điều này sẽ không quan trọng nếu việc chỉ định thiếu là tốn kém, như với một đội ngũ phát triển con người, nơi sự mơ hồ khiến bạn mất hai tuần trước khi ai đó nhận ra thứ sai đã được xây. Ở đây thì không tốn kém như vậy. Công cụ dựng lên kế hoạch trước khi xây — bạn thấy một đề xuất cụ thể trước khi bất cứ thứ gì được đưa vào code — nên việc chỉ định thiếu chỉ tốn bạn một lần chỉnh sửa năm phút trong phần trò chuyện, trong khi chỉ định quá mức lại đưa hết những ý tưởng nửa vời yếu nhất của bạn lên ngay tại thời điểm bạn có ít thông tin nhất để biết cái nào đáng giữ lại. Mười từ yêu cầu thực sự tốt hơn hai trăm từ suy nghĩ tuôn trào, không phải vì nhiều thông tin hơn là xấu về bản chất, mà vì trong giao diện này cụ thể, mỗi từ thêm vào đều là một cam kết.
Còn có một cái giá âm thầm hơn: nó làm phẳng thứ bậc ưu tiên. Liệt kê mười hai tính năng với mức nhấn mạnh ngang nhau thì công cụ dựng không có tín hiệu nào để biết ba tính năng nào bạn thực sự quan tâm, vì vậy nó hoặc cho cả mười hai trọng lượng thị giác bằng nhau (lộn xộn) hoặc đoán mức ưu tiên (đôi khi sai, và giờ bạn đang gỡ lỗi một suy đoán thay vì nêu rõ ưu tiên). Ba điều bắt buộc phải có được nói thẳng ra sẽ bảo vệ thứ bậc đó. Mười hai điều nằm trong một đoạn văn thì xóa sạch nó.
Một prompt tốt thực sự trông như thế nào?
| Câu lệnh | Vì sao nó hiệu quả |
|---|---|
| "Một nhật ký tập luyện cho người leo núi — buổi tập, cấp độ, biểu đồ tiến bộ." | Cái gì cộng với ba điều bắt buộc phải có, tổng cộng mười từ yêu cầu. Không có ghi chú về đối tượng người dùng, vì "người leo núi ghi lại quá trình tập luyện của chính họ" đã rõ ràng từ danh mục — nó đúng đắn bỏ qua thành phần duy nhất không có tác dụng ở đây. |
| "Một trang landing cho podcast của tôi về nông nghiệp đô thị, ấm áp và mang phong cách biên tập, có danh sách tập và form đăng ký nhận tin." | Cái gì, đối tượng người dùng ngầm hiểu qua "podcast của tôi," tâm trạng, hai tính năng. Nó không nói trình phát nào sẽ nhúng các tập podcast hay hiển thị bao nhiêu tập mỗi trang — đó là câu hỏi cho vòng thứ hai, không phải câu hỏi cho prompt mở đầu. |
| "Một game khúc côn cầu trên bàn hai người chơi, vật lý thật, dùng chung một bàn phím." | Game làm rõ mẫu hình này: thể loại cộng với một ràng buộc duy nhất quyết định cách nó thực sự chơi ra sao. "Vật lý thật" và "dùng chung một bàn phím" không hẳn là tính năng mà là hai quyết định quyết định liệu nó có cảm giác giống game trong đầu bạn hay không. Màu bàn, hiệu ứng vệt bóng, giao diện điểm số — công cụ dựng đề xuất, bạn phản hồi. |
Điểm chung của cả ba không phải là sự ngắn gọn vì lợi ích riêng của nó, mà là mỗi từ đều có nhiệm vụ. Cắt "ấm áp và mang phong cách biên tập" khỏi prompt podcast và bạn có một trang podcast chung chung; cắt "nông nghiệp đô thị" và từ chỉ tâm trạng không còn gì để bám vào. Đó mới là phép thử thực sự cho một prompt được hình thành tốt — không phải số lượng từ. Tôi thà chọn một prompt 40 từ mà mỗi mệnh đề đều xứng đáng có mặt còn hơn một prompt 15 từ ngắn gọn vì cố tình mà lại âm thầm bỏ sót một điều bắt buộc.
Nếu tôi đã có màu thương hiệu hoặc ảnh thật thì sao?
Hãy đính kèm chúng. Đừng mô tả chúng. Tôi đã thấy người ta viết cả một đoạn văn cẩn thận cố định nghĩa bảng màu thương hiệu bằng ngôn ngữ gần-mã-hex — "một màu xanh lá rừng đậm, hơi trầm" — trong khi bộ hướng dẫn thương hiệu thật lại nằm sẵn trong một file PDF trên desktop suốt thời gian đó. Một màu được mô tả là một phỏng đoán mà công cụ dựng phải tái tạo lại; một màu được đính kèm thì chỉ đơn giản là đúng. Menu thật, ảnh thật, tài sản thương hiệu — các tính năng kiến thức và tham chiếu đưa thẳng chúng vào bản dựng, và sự thật luôn thắng những mô tả về sự thật.
