Provaのスプリントは実際どのように見えるか:1週目のウォークスルー
Prova の sprint では path を選び、実際の artifact を作り、証拠を提出し、次に進める水準まで修正します。
短い答え
Prova の sprint は学習モジュールではありません。Operator、Leader、Builder の path はすべて、具体的な仕事を選び、artifact を作り、現実または現実に近い文脈で試し、証拠を提出してレビューで修正します。
Provaのスプリント1週目が実際にどのようなものか、ここに示します。マーケティング版ではなく、実際の版です。
一つの仕事を選びます。成果物を作ります。実際、または現実に近い状況で試します。提出します。誰かが定義された基準に対してそれをレビューし、合格か修正が必要かを伝えます。それがループ全体です。
録画された講義はありません。クイズもありません。1スプリント、1つの証拠です。
1日目:ワークフローの選択
最初にすることは何も構築することではありません。ワークフロー定義を書くことです。
これは一つの段落で三つの質問に答えることを意味します:現在手動で行っているタスクは何か?誰がそれをトリガーするか?良い成果物はどのように見えるか?
シンプルに聞こえます。そうではありません。多くの人が漠然としたアイデアを持って来ます——「コンテンツプロセスを自動化したい」——そして1日目の演習が具体的にさせます。「コンテンツブリーフを受け取り、私のブランドボイスで400語のブログ導入部を返すAIツールが欲しい」はワークフローです。「コンテンツを自動化する」はそうではありません。
具体性の要件により、準備ができていないプロジェクトがフィルタリングされます。一つの段落でタスクを説明できない場合、まだそのためのツールを構築する準備ができていません。
2〜3日目:プロンプトシステムの構築
ワークフローがスコーピングされたら、プロンプトシステムを書きます。
これは単一のプロンプトではありません。構造化された指示のセットです:役割と制約を定義するシステムプロンプト、変数入力を受け取るユーザープロンプトテンプレート、そして良い成果物がどのように見えるかを示す少なくとも一つの完成例。
このフェーズ中、Provaインターフェースは四つのコンポーネントを通じてガイドします:
- 役割定義。 AIはどの専門知識を演じているか?その役割の限界は何か?
- 入力スキーマ。 プロンプトはどの構造化された情報を受け取るか?(キーワード、オーディエンス、トーンシグナルなど)
- 出力フォーマット。 応答はどのように見えるべきか?ヘッダー、長さ、構造?
- 品質シグナル。 良い出力とは何が良い出力を受け入れられる出力と区別するか?
多くの人がこのフェーズで1日目のワークフロー定義を修正します。それは予想されます。プロンプトを書くことで、定義が延期した精度が強制されます。
4日目:実データでの実行
これが最も重要な日であり、一人で構築するときに人々がスキップする日です。
仮想のシナリオではなく、自分の作業からの三つの実際の例に対してプロンプトシステムを実行します。ツールがキャンペーンブリーフジェネレーターであれば、以前に書いた三つの実際のブリーフを入力し、AIが生成したものと自分が書いたものを比較します。
目的はツールが機能することを確認することではありません。どこで失敗するかを見つけることです。すべてのプロンプトシステムにはエッジケースでの失敗モードがあります。4日目はそれらを提出前に見つけます。
このステージでの一般的な失敗:出力は正しいが長すぎる;トーンは正しいが構造が間違っている;ツールは短文形式では機能するが長文形式では壊れる。これらは修正可能です。発見せずに提出すると、レビューサイクルが無駄になります。
5日目:提出の準備
提出物は磨かれたデッキではありません。三つの必須セクションを持つ構造化されたドキュメントです:
- プロンプトシステム。 実際のシステムプロンプト、ユーザープロンプトテンプレート、完成例。
- 三つの実際の出力。 4日目の実データに対するツール実行の結果。
- 自己評価。 一段落:このツールはどこで確実に機能し、どこで壊れるか?
自己評価セクションは意図的なものです。聞こえるよりも書くのが難しく、その段落の品質は、自分が構築したものを理解しているかどうかについてレビュアーに多くを伝えます。
提出後:レビュープロセスはどのように見えるか
レビューは48時間以内に返されます。レビュアーは五つの基準に対して提出物を採点します:ワークフローの明確さ、プロンプトアーキテクチャ、三つの実際の例での出力品質、失敗モードの認識、次のスプリントステージへの準備状況。
各基準は三つの評価のうちの一つを受けます:標準を満たす、修正が必要、まだ対処されていない。
合格はツールが述べた範囲の標準を満たすことを意味します。完璧という意味ではありません。構築し続けるのに十分なほど堅実であることを意味します。
修正は一つ以上の基準がスプリントが進む前に作業が必要であることを意味します。レビューには具体的なフィードバックが含まれます——「プロンプトを改善する」ではなく「システムプロンプトは許容可能な長さを定義していないため、三つの例にわたって出力長が一致しない」というようなものです。
修正の結果は失敗ではありません。レビューが仕事をしているということです。Provaを通じて見た最も強力なツールのいくつかは一つの修正サイクルを経ました。
これがコースとどう違うか
コースでは、理解したかどうかにかかわらず、モジュールを完了して次に進みます。Provaのスプリントでは、ツールが標準を満たすまで前進できません。それが構造的な違いです。
レビューはグレードではありません。品質ゲートです。成果物は合格するかしないかのどちらかです。
1週目の終わりに、動作するツールを持って帰ります——実際のワークフローで実際に使用できるもの——そしてそれが何をするか、どこで不足しているかの明確な記録。その記録が次のスプリントの出発点になります。
