Prova 衝刺實際是什麼樣子：第一週詳細解析

這是 Prova sprint 第一週的實際情況。不是市場推廣版本——是真實版本。

你選擇一項工作。你產出一個 artifact。你在真實或接近真實的情境中測試它。你提交結果。有人根據明確標準審核它，告訴你是否通過或需要修改。這就是整個循環。

沒有錄製的講座。沒有測驗。一個 sprint，一個證據點。

第 1 天：選擇 workflow

你首先做的不是構建任何東西。你寫一個 workflow 定義。

這意味著在一個段落中回答三個問題：你目前手動完成的任務是什麼？誰觸發它？好的輸出是什麼樣的？

聽起來很簡單。並不是。大多數人帶著模糊的想法來——「我想自動化我的內容流程」——第 1 天的練習迫使他們具體化。「我想要一個接受內容簡報並以我的品牌聲音返回 400 字博客介紹的 AI 工具」是一個 workflow。「自動化內容」不是。

具體性要求過濾掉了尚未準備好的項目。如果你不能在一個段落中描述這個任務，你還沒有準備好為它構建工具。

第 2–3 天：構建提示詞系統

確定 workflow 範圍後，你編寫提示詞系統。

這不是單個提示。這是一組結構化的指令：定義角色和約束的系統提示，接受可變輸入的用戶提示模板，以及至少一個展示好輸出的完成示例。

在此階段，Prova 界面引導你完成四個組件：

1. 角色定義。 AI 扮演什麼專業角色？該角色的限制是什麼？
2. 輸入模式。 提示接受什麼結構化資訊？（關鍵詞、受眾、語氣信號等）
3. 輸出格式。 響應應該是什麼樣子？標題、長度、結構？
4. 質素信號。 什麼使好的輸出不同於可接受的輸出？

大多數人在此階段修改他們的第 1 天 workflow 定義。這是預期的。編寫提示迫使定義所推遲的精確性。

第 4 天：在真實數據上運行

這是最重要的一天，也是人們在獨自構建時跳過的一天。

你針對自己工作中的三個真實示例運行提示詞系統——不是假設場景。如果你的工具是活動簡報生成器，你輸入之前寫過的三個真實簡報，並將 AI 生成的內容與你會寫的內容進行比較。

目的不是確認工具有效。而是找出它在哪裡失敗。每個提示詞系統都有邊緣情況下的失敗模式。第 4 天在提交前找到它們。

此階段常見失敗：輸出正確但太長；語氣正確但結構錯誤；工具對短文有效但對長文失效。這些都是可修復的。在沒有發現它們的情況下提交會浪費審核週期。

第 5 天：準備提交

提交物不是精心製作的演示文稿。它們是包含三個必要部分的結構化文檔：

1. 提示詞系統。 實際的系統提示、用戶提示模板和完成示例。
2. 三個真實輸出。 第 4 天在真實數據上運行工具的結果。
3. 自我評估。 一段話：這個工具在哪裡可靠地工作，在哪裡失敗？

自我評估部分是故意設計的。它比聽起來更難寫，那段話的質素告訴審核者很多關於你是否理解你所構建的東西。

提交後：審核流程是什麼樣的

審核在 48 小時內返回。審核者根據五個標準對提交物評分workflow 清晰度、提示架構、三個真實示例的輸出質素、失敗模式意識，以及進入下一個衝刺階段的準備情況。

每個標準獲得三種評級之一：達到標準、需要修改，或尚未解決。

通過意味著工具在其聲明範圍內達到標準。不意味著完美。意味著足夠扎實可以繼續構建。

修改意味著一個或多個標準在衝刺可以進展之前需要工作。審核包含具體反饋——不是「改進提示」，而是「系統提示沒有定義什麼算作可接受的長度，導致三個示例中輸出長度不一致」。

修改結果不是失敗。這是審核在做它的工作。我在 Prova 看到的一些最強的工具經歷了一個修改週期。

這與課程的不同之處

在課程中，無論你是否理解，你都完成模塊並繼續下一個。在 Prova 衝刺中，在工具達到標準之前你無法前進。這是結構上的區別。

審核不是成績。它是質素門。成果物要麼通過，要麼不通過。

你帶著一個可用的工具離開第一週——你實際上可以在真實 workflow 中使用的東西——以及一份清晰的記錄，說明它做什麼以及在哪裡不足。這份記錄成為下一個衝刺的起點。