Bốn. Đó là con số gần đúng khi một bản build lần đầu vượt qua quá trình xác minh của chính nó và tạo ra thứ gì đó thực sự chạy được — một trang hoạt động, một endpoint hoạt động, một luồng đăng nhập cho phép ai đó đăng nhập thành công. Mười một là số prompt trung vị mà một bản build tích lũy được cho đến khi ai đó tuyên bố hoàn thành và triển khai nó. Sáu mươi tám phần trăm là tỷ lệ của mọi prompt được gửi sau phiên bản hoạt động đầu tiên đó không thay đổi bất kỳ điều gì mà người dùng có thể nhận thấy trong logic bên dưới. Và ba mươi là mốc mà hầu hết mọi người âm thầm dừng lại, không phải vì sản phẩm đã hoàn thiện, mà vì họ đã hết ý để nói về nó.
Bốn con số đó mô tả cùng một hình thái lặp đi lặp lại: các bản build trở nên có chức năng rất nhanh, sau đó dành phần lớn thời gian còn lại để được bàn luận thêm thay vì được xây dựng lại.
Bức tường không nằm ở nơi bạn nghĩ
Nếu bạn hỏi tôi trước khi tôi bắt đầu để ý xem người xây dựng thường bị kẹt ở đâu, tôi sẽ đoán là các tích hợp — nhà cung cấp thanh toán, callback xác thực, API SMS cần một sender ID đã được xác minh. Đó là những điểm ma sát có thật, nhưng chúng không phải là nơi số lượng prompt tăng vọt. Chúng thường chỉ tốn thêm một hoặc hai lượt rồi được giải quyết.
Bức tường xuất hiện muộn hơn, sau khi mọi thứ đã hoạt động. Một bản build đạt đến lần xác minh thành công đầu tiên — các trang render đúng, luồng chính chạy trọn vẹn, không có lỗi nào — và thay vì dừng lại, các prompt vẫn tiếp tục đến. "Làm header to hơn." "Thử một màu nhấn khác." "Có thể bo tròn nút một chút được không." "Thực ra quay lại phiên bản đầu tiên đi." Không cái nào trong số này chạm đến mô hình dữ liệu, route, hay kiểm tra quyền. Tất cả chỉ là bề mặt.
Tại sao "xong" lại không cảm thấy giống một điểm dừng
Một phần nguyên nhân đơn giản là cảm giác lặp lại từ bên trong ra sao. Khi một bản build bị lỗi, bạn biết chính xác cần yêu cầu gì — sửa lỗi, thêm trường bị thiếu, kết nối thứ chưa được kết nối. Khi nó đã hoạt động, mục tiêu biến mất. Không có thông báo lỗi nào cho bạn biết sắc xanh đó là sai. Giờ bạn đang đưa ra các quyết định về gu thẩm mỹ mà không có căn cứ thực tế nào, và các quyết định về gu thẩm mỹ thì có thể chỉnh sửa vô hạn theo cách mà lỗi thì không.
Phần khác là việc gửi prompt rẻ và tức thì, nên chi phí của việc "thử thêm một điều nữa" gần như bằng không ngay tại thời điểm đó, dù tổng cộng lại thì không hề bằng không. Một chục lượt chỉnh sửa thẩm mỹ, mỗi lượt vài phút, cộng lại là cả một buổi chiều thật sự, nhưng không có prompt đơn lẻ nào trong số đó cảm thấy đủ tốn kém để bỏ qua.
Những prompt muộn thực sự thay đổi điều gì
| Khoảng prompt | Mục tiêu thường gặp | Có thay đổi chức năng? |
|---|---|---|
| 1–4 | Các trang chính, mô hình dữ liệu, luồng chính | Có — đây là lúc sản phẩm được xây dựng |
| 5–7 | Trường hợp ngoại lệ, trạng thái lỗi, trường bị thiếu | Thường là có — những lỗ hổng thực sự được phát hiện khi sử dụng |
| 8–15 | Bố cục, nội dung văn bản, màu sắc, khoảng cách, giọng điệu | Hiếm khi |
| 16+ | Hoàn tác hoặc thử lại các lựa chọn thẩm mỹ trước đó | Gần như không bao giờ |
Hàng thứ ba đó mới là điều đáng để suy ngẫm. Không phải việc chăm chút thẩm mỹ là lãng phí — một sản phẩm trông chung chung sẽ kém hiệu quả hơn một sản phẩm được chăm chút kỹ, và bước hoàn thiện thiết kế thực sự quan trọng. Vấn đề là việc chăm chút hiếm khi cần đến tám đến mười lăm lượt prompt riêng biệt mới đúng ý, và lý do cần nhiều đến vậy thường là sự do dự, không phải sự lặp lại có chủ đích. Bạn không phải đang tiến gần hơn đến một câu trả lời tốt hơn sau prompt thứ mười một; bạn đang dao động giữa hai phương án bạn đã tạo ra từ trước prompt thứ chín.
Tôi từng chứng kiến ai đó bỏ ra bốn mươi phút để di chuyển một nút kêu gọi hành động qua ba vị trí khác nhau trên một trang đích, đến prompt thứ mười bốn thì quyết định vị trí đầu tiên là tốt nhất, và yêu cầu agent xây dựng đặt nó lại như cũ. Agent không làm sai điều gì trong bất kỳ lượt nào cả. Chỉ là cái nút đó chưa bao giờ cần đến mười bốn ý kiến khác nhau.
Khoảng cách giữa hai mươi và ba mươi thực sự nói lên điều gì
Đây là phần khiến tôi bất ngờ nhất: những bản build dừng lại quanh prompt thứ mười một và những bản build kéo dài quá ba mươi không có sự khác biệt đáng kể về chất lượng. Tôi đã tìm kiếm lợi ích thực sự — chắc hẳn lặp lại nhiều hơn sẽ mang lại sản phẩm hoàn thiện hơn — nhưng phần lớn không tìm thấy điều đó. Thay vào đó, tôi nhận ra rằng những người dừng sớm hơn thường đã đưa ra quyết định về gu thẩm mỹ một lần, ngay từ đầu, ngay trong prompt ("sạch sẽ, tối giản, một màu nhấn duy nhất, không dùng ảnh stock") thay vì khám phá dần gu thẩm mỹ của mình qua hai mươi vòng thử-sai sau đó.
Những bản build kéo dài nhất không phải là những bản tham vọng hơn. Đó là những bản mà prompt ban đầu để lại nhiều điều chưa được quyết định nhất — không có tông giọng, không có điểm tham chiếu, không nêu rõ đối tượng người dùng — nên mọi khoảng trống đều được lấp đầy từng chút một qua các prompt nhỏ thay vì được quyết định một lần, bằng văn bản, trước lần chạy đầu tiên.
Bài học thực tế rút ra
Nếu bạn đã đi được bốn hoặc năm prompt và mọi thứ chạy ổn, đó không phải là một điểm dừng kiểm tra — đó là phần lớn công việc thực sự đã hoàn thành. Những gì còn lại là có thật nhưng nhỏ: kiểm tra các trường hợp biên mà chưa ai nghĩ đến để mô tả, rà soát lại nội dung văn bản, và thực hiện một lượt chỉnh sửa có chủ đích về tông thẩm mỹ thay vì hàng chục lượt thử nghiệm. Và nếu bạn nhận thấy mình ở prompt thứ hai mươi vẫn đang chỉnh bo góc viền, đó không phải là dấu hiệu bản build chưa xong. Đó thường là dấu hiệu cho thấy prompt ban đầu lẽ ra nên nói rõ điều bạn muốn ngay từ đầu, và điều chỉnh đó nên nằm trong tin nhắn mở đầu của bản build tiếp theo, chứ không phải ở lượt thứ bốn mươi của bản build này.
