新しいプロジェクトで大量のエージェントが大量にトークンを消費する前に、昔ながらの木工の格言「2回測って1回切る!」を「ビーズをN回チェックし、1回実装する」に改訂する価値があります。Nは基本的に耐えられるだけの数です。 Opus 4.5で連続してこのプロンプトを回すほど、たとえ微妙な改善でもどんどん増えていくことに気づきました(以下のプロンプトは、私が最近の非常に長いワークフローについての投稿で紹介した別のプロンプトを使って初期のマークダウンプランをビーズに変換した後のみ使用します)。 「『AGENTS』をもう一度読み返して、まだ記憶に新しいままにして。一つ一つのビーズをすごく注意深く確認してください――本当に意味が通っていますか?最適でしょうか?ユーザーにとってシステムをより良く機能させるために何か変更できるでしょうか?もしそうなら、ビーズを修正してください。これらのことを導入する前に「計画空間」で運営する方がずっと簡単で速いのです! 物事を単純化しすぎないでください!機能や機能性を失わないでください! また、これらのビーズの一部として、包括的なユニットテストやe2eテストスクリプト、そして詳細なログ記録を含めて、実装後にすべてが完璧に動作していることを確実にしてください。ビーズの作成・修正、そして依存関係の追加には「bd」ツールだけを使うことを忘れないでください。ウルトラシンクを使え。」 実装を始める前に一度か二度しか使っていませんでしたが、最近6+回試してみたら、役立つ改良ができていました。 ビーズの段階的な改善が止まらなくなったら、新しいCCセッションを始めてみてはどうでしょうか。まずは以下から始めてみてはどうでしょうか。 「まず、すべてのAGENTS dot mdファイルとREADME dot mdファイルをすごく注意深く読んで、両方を全部理解してください!その後、コード調査エージェントモードを使って、コードや技術的アーキテクチャ、プロジェクトの目的を完全に理解しましょう。 ウルトラシンクを使え。」 そして、上記の同じプロンプトを、前置きで続けます。 「最近、割引プランのファイルを新しいビーズの束に変えたんだ。これらを『bd』と『bv』を使って非常に慎重にレビューし分析してほしい。」 マークダウン計画が複雑で複雑なほど、この手法はより重要になります。小さくて些細な計画と非常にシンプルなプロジェクトなら、これは明らかにやりすぎです。しかしその場合、各ラウンドでわずかな変化や変化はほとんど見られないので、いつやめるべきかはかなり明らかでしょう。 ただし、計画用トークンは実装用トークンよりもずっと少なく安価です。非常に大規模で複雑なマークダウンプランでも、いくつかの実質的なコードファイルよりも短く、ましてやプロジェクト全体よりも短くなります。 そして、モデルは非常に詳細で肉付けされた計画を推論する際、それでも自分たちのコンテキストウィンドウに簡単に収まるほど小さい計画を推論する際ははるかに賢いです(これが私が計画にこだわる最大の洞察であり、なぜ80%+の時間をその部分に費やしたのか)。 そして、私が強く推奨しているように、ウェブアプリのGPT Proと拡張推論(つまり、最終的にビーズに変えるマークダウンプランを作成・改善する)に頼れば、プロプランならほぼ食べ放題でビーズを楽しめるので、その点を最大限に活用してください! ウェブ上でProを扱う他のモデルは、コンテキストウィンドウに簡単に収まる入力を扱う場合に触れられません。本当にユニークな作品です。 ...