Sprint Prova Thực Sự Trông Như Thế Nào: Hướng Dẫn Tuần Đầu Tiên

Đây là những gì tuần đầu tiên của một sprint Prova thực sự trông như thế nào. Không phải phiên bản marketing — mà là phiên bản thực.

Bạn chọn một phần việc. Bạn tạo ra một artifact. Bạn kiểm tra nó trong tình huống thật hoặc đủ gần với thực tế. Bạn nộp kết quả. Ai đó review nó theo tiêu chí đã xác định và cho bạn biết nó có đạt hay cần chỉnh sửa. Đó là toàn bộ vòng lặp.

Không có bài giảng được ghi âm. Không có câu hỏi kiểm tra. Một sprint, một bằng chứng.

Ngày 1: Chọn workflow

Điều đầu tiên bạn làm không phải là xây dựng bất cứ thứ gì. Bạn viết định nghĩa workflow.

Điều đó có nghĩa là trả lời ba câu hỏi trong một đoạn văn: Bạn hiện đang làm gì thủ công? Ai kích hoạt nó? Một kết quả tốt trông như thế nào?

Nghe có vẻ đơn giản. Nhưng không phải vậy. Hầu hết mọi người đến với một ý tưởng mơ hồ — "Tôi muốn tự động hóa quy trình nội dung của mình" — và bài tập Ngày 1 buộc họ phải cụ thể. "Tôi muốn một công cụ AI nhận brief nội dung và trả về phần giới thiệu blog 400 từ theo giọng thương hiệu của tôi" là một workflow. "Tự động hóa nội dung" thì không phải.

Yêu cầu về sự cụ thể lọc ra các dự án chưa sẵn sàng. Nếu bạn không thể mô tả nhiệm vụ trong một đoạn văn, bạn chưa sẵn sàng để xây dựng công cụ cho nó.

Ngày 2–3: Xây dựng hệ thống prompt

Khi workflow đã được xác định phạm vi, bạn viết hệ thống prompt.

Đây không phải là một prompt đơn lẻ. Đây là một tập hợp hướng dẫn có cấu trúc: system prompt xác định vai trò và ràng buộc, user prompt template nhận đầu vào biến, và ít nhất một ví dụ đã hoàn thành cho thấy kết quả tốt trông như thế nào.

Trong giai đoạn này, giao diện Prova hướng dẫn bạn qua bốn thành phần:

1. Định nghĩa vai trò. AI đang đóng vai chuyên môn gì? Giới hạn của vai trò đó là gì?
2. Schema đầu vào. Prompt nhận thông tin có cấu trúc nào? (từ khóa, đối tượng, tín hiệu tone, v.v.)
3. Định dạng đầu ra. Phản hồi nên trông như thế nào? Tiêu đề, độ dài, cấu trúc?
4. Tín hiệu chất lượng. Điều gì phân biệt kết quả tốt với kết quả chấp nhận được?

Hầu hết mọi người sửa lại định nghĩa workflow Ngày 1 trong giai đoạn này. Điều đó được mong đợi. Việc viết prompt buộc phải có sự chính xác mà định nghĩa đã hoãn lại.

Ngày 4: Chạy trên dữ liệu thực

Đây là ngày quan trọng nhất, và là ngày mọi người bỏ qua khi họ tự xây dựng một mình.

Bạn chạy hệ thống prompt của mình trên ba ví dụ thực từ công việc của chính bạn — không phải các tình huống giả định. Nếu công cụ của bạn là trình tạo campaign brief, bạn nhập ba brief thực mà bạn đã viết trước đây và so sánh AI tạo ra so với những gì bạn đã viết.

Mục đích không phải là xác nhận công cụ hoạt động. Mà là tìm ra nơi nó thất bại. Mọi hệ thống prompt đều có các chế độ thất bại trên các trường hợp ngoại lệ. Ngày 4 tìm ra chúng trước khi nộp.

Các thất bại phổ biến ở giai đoạn này: kết quả đúng nhưng quá dài; tone đúng nhưng cấu trúc sai; công cụ hoạt động cho văn bản ngắn nhưng bị hỏng với văn bản dài. Những điều này có thể sửa được. Nộp bài mà không phát hiện ra chúng làm lãng phí chu kỳ review.

Ngày 5: Chuẩn bị bài nộp

Bài nộp không phải là bản trình bày được đánh bóng. Chúng là các tài liệu có cấu trúc với ba phần bắt buộc:

1. Hệ thống prompt. System prompt thực tế, user prompt template, và ví dụ đã hoàn thành.
2. Ba kết quả thực. Kết quả chạy công cụ trên dữ liệu thực từ Ngày 4.
3. Tự đánh giá. Một đoạn văn: công cụ này hoạt động đáng tin cậy ở đâu, và nó thất bại ở đâu?

Phần tự đánh giá là có chủ ý. Nó khó viết hơn nghe có vẻ, và chất lượng của đoạn văn đó nói với người review rất nhiều về việc bạn có hiểu những gì mình đã xây dựng không.

Sau khi nộp: quy trình review trông như thế nào

Review được trả lại trong vòng 48 giờ. Người review chấm điểm bài nộp theo năm tiêu chí: sự rõ ràng của workflow, kiến trúc prompt, chất lượng đầu ra trên ba ví dụ thực, nhận thức về chế độ thất bại, và sẵn sàng cho giai đoạn sprint tiếp theo.

Mỗi tiêu chí nhận một trong ba đánh giá: đạt tiêu chuẩn, cần chỉnh sửa, hoặc chưa được đề cập.

Đạt có nghĩa là công cụ đáp ứng tiêu chuẩn cho phạm vi đã nêu. Không có nghĩa là hoàn hảo. Có nghĩa là đủ vững chắc để xây dựng tiếp.

Chỉnh sửa có nghĩa là một hoặc nhiều tiêu chí cần cải thiện trước khi sprint có thể tiến triển. Review bao gồm phản hồi cụ thể — không phải "cải thiện prompt" mà là "system prompt không định nghĩa độ dài chấp nhận được là gì, gây ra độ dài đầu ra không nhất quán trên ba ví dụ."

Kết quả chỉnh sửa không phải là thất bại. Đó là review đang làm công việc của nó. Một số công cụ mạnh nhất tôi đã thấy qua Prova đã trải qua một chu kỳ chỉnh sửa.

Điểm khác biệt so với khóa học

Trong khóa học, bạn hoàn thành module và chuyển sang module tiếp theo bất kể bạn có hiểu hay không. Trong sprint Prova, bạn không thể tiến lên cho đến khi công cụ đạt tiêu chuẩn. Đó là sự khác biệt về cấu trúc.

Review không phải là điểm số. Đó là cổng chất lượng. Artifact hoặc đạt hoặc không đạt.

Bạn rời tuần một với một công cụ hoạt động được — thứ bạn thực sự có thể sử dụng trong workflow thực của mình — và một hồ sơ rõ ràng về những gì nó làm và nơi nó còn thiếu sót. Hồ sơ đó trở thành điểm khởi đầu cho sprint tiếp theo.