AI プログラミングでバランスをとるのが最も難しい 2 つの点は、速度と確実性です。
速度だけを追求すると、小さなタスクはすぐに完了しますが、モジュール間の変換が発生すると、要件が変更されやすく、実行中に境界が失われます。厳密さのみを追求し、完全な仕様、設計、レビュー資料がタスクごとに作成され、小さな修理であってもプロセスが遅くなります。
spec-superflow 2.0 が与えた答えは、リスクを伴うプロセスの変更を許容することです。
明確な境界を持つ小さなタスクが指示され、現在のセッションで継続的に開発、検証、提供されます。複雑なタスクは、提案、タスク、オンデマンド仕様を使用してターゲットをロックし、完全なスコープレビューと最終検証を経てドリフトがないことを確認して計画されます。
これは、OpenSpec の構造化された計画機能と、Superpowers のデバッグ、レビュー、および検証の規律を組み合わせたものです。最終的に得られるのは、2 セットのツールを単純につなぎ合わせたものではなく、実際のソフトウェア開発の複雑さをカバーできる AI エンジニアリング ワークフローです。
2 つのまったく異なるタイプの開発タスクをカバーする一連のワークフロー
spec-superflow 2.0 は、新しいタスクを 2 つのエントリにまとめます。
直接: 明確な小さなタスクを直接開発に取り込みます。
Direct は、次のような目標、境界、検証方法が明確な作業に適しています。
- ログイン時のログインタイムアウトを修正しました。
- 設定、ドキュメント、またはローカル インタラクションを調整します。
- パブリック プロトコルを変更せずに少数のファイルを変更します。
- 既知の根本原因と受け入れコマンドの欠陥が修正されました。
完全な計画アーティファクトの生成を強制したり、デフォルトでサブエージェントをディスパッチしたり、ワークツリーを作成したりすることはありません。 AI は現在のセッションに留まり、継続的にコードを理解し、実装を完了し、セルフチェックと最終検証を実行することで、コンテキストの引き継ぎと繰り返しの読み取りを削減できます。
Direct の価値は、「作成するドキュメントの量を減らす」ことではなく、単純なタスクをシンプルに保つことです。
計画済み: 複雑なタスクを承認された範囲から検証可能な配信に移行します
計画されたターゲットは、クロスモジュール、パブリック インターフェイス、ステート マシン、データ セマンティクス、複数人によるコラボレーションなどの複雑な変更です。
デフォルトでは、2 つのコア アーティファクトのみが必要です。
proposal.md: なぜ変更するのか、何を変更する必要があるのか、境界はどこにあるのか。tasks.md: 各ステップの実行方法と確認方法。
動作ベースラインを正確に定義する必要がある場合は、デルタ仕様を追加します。アーキテクチャ上の選択や長期的な制約がある場合は、設計を追加します。ワークピースはリスクに応じて決定されるため、テンプレートを修正してタスクをどんどん重くする必要はありません。
承認後は、常に同じ計画に基づいて実行が進められます。スコープが変更されると、システムはドリフトを明確に識別します。実装の完了後、レビューは Git 範囲全体をカバーし、最終検証で真の結果が記録されます。したがって、複雑なタスクは進行し続けることができ、数十回の対話後に新たな要件になることはありません。
OpenSpec は「何を行うか」に関するものであり、Superpowers は「それを確実に行う方法」に関するものです。
OpenSpec の最も価値のある点は、要件をチャット コンテンツからチェック可能なエンジニアリング オブジェクトに変換することです。
提案により、変更の動機と範囲が保存されます。デルタ仕様が使用されます ADDED、MODIFIED、REMOVED、RENAMED 行動の変化を表現する。要件とシナリオは、「これは機能するはずです」をテスト可能な制約に変えます。これにより、複雑なタスクにコードを入力する前に安定した境界が与えられます。
Superpowers の強みは実行規律にあります。実装する前にまず理解し、障害が発生した場合は根本原因を調査し、実際の変更をレビューし、完了前に検証を実行します。 「書いたらすぐに終了宣言する」というAIの問題点を簡単に解決します。
spec-superflow 2.0 は、この 2 つを閉ループに接続します。
- 直接またはリスクを伴う計画を選択します。
- Planned は構造化されたアーティファクトを使用してターゲットをロックし、Direct は明確なスコープを保持します。
- デフォルトでは、コンテキストの損失を減らすために、現在のセッションで継続的に実行されます。
- 失敗すると、根本原因のデバッグ ループに入り、修復後に元の実行チェーンに戻ります。
- 入り口に応じてレビュー強度をロードし、最終的に均一に検証します。
- 実際の検証に合格した場合にのみ、次のように記録できます。
verified。
特定のリスクが人間の判断によって許容される場合は、次のように記録することもできます。 accepted-riskただし、失敗の証拠は保持され、検証に合格したとしてもパッケージ化されません。機械は証拠を提供する責任を負い、人間が最終的な意思決定の権限を保持します。
複雑なタスクはなぜ容易に逸脱しないのか
多くの AI ワークフローの問題は、「計画があるかどうか」ではなく、計画、コーディング、レビュー、検証が同じことであるかどうかです。
spec-superflow 2.0 は、このリンクのいくつかの重要な制約を完了します。
計画に関する事実の情報源は 1 つだけです。 新しい計画タスクはスキーマ v2 実行プランによって実行され、複数のサマリーが相互に矛盾することを避けるために承認、スコープ、および実行モードが実行されます。
レビューでは完全な変更がカバーされています。 空の Git 範囲は拒否され、使用されません。 HEAD~1 複数のコミット変更を最後のコミットに切り取ります。レビュー証拠は、実際の変更範囲と一致している必要があります。
検証結果は最終状態にバインドされます。 検証を終了すると、結果に影響を与える入力指紋が記録されます。コードまたは環境が変更された場合、古い「パス」を再利用することはできません。
リカバリは正しいディレクトリとブランチに戻る必要があります。 デフォルトの分離方法は通常の機能ブランチです。ワークツリーは、複数の並列チェックアウトが明らかに必要な場合にのみ作成されます。リカバリ記録により、リポジトリ、ブランチ、パス、およびサブモジュールと失敗した再試行が正しい分離環境に保持されていることを検証します。
パスの境界を確認できます。 シンボリックリンク、インストール ターゲット、オーバーレイ、およびクロスプラットフォームのリアルパスは境界チェックされ、自動プロセスが予想されるディレクトリの外にファイルを書き込むのを防ぎます。
これらの能力は通常、対話の負担を増やすことはありませんが、複雑なタスクが制御不能になる可能性が最も高い場合に機能します。
9 スキルは能力のメニューであり、9 つの必要な段階ではありません。
| スキル | 効果 |
|---|---|
workflow-start |
タスクを開始または再開するには、「直接/計画」を選択します。 |
need-explorer |
要件があいまいな場合は、目標、境界、受け入れ基準を明確にする |
spec-writer |
提案書、タスク、オンデマンドの仕様/設計を生成します。 |
contract-builder |
古い変更の実行コントラクトと互換性があり、新しいタスクのデフォルト チェーンには入りません。 |
build-executor |
承認された範囲内での継続的な実装、自己テスト、検証 |
bug-investigator |
根本原因を調査して、ランダムなトライアル修復や無効なサイクルを回避します |
code-reviewer |
計画された変更またはリスクの高い変更の全面的なレビューを実施する |
spec-merger |
デルタ仕様を正式な仕様ベースラインにアトミックに同期します |
release-archivist |
最終検証を実行し、検証済みまたは許容されたリスクを記録します。 |
最も短い小さなタスクは次のとおりです。
workflow-start → build-executor → release-archivist
複雑なタスクは必要に応じて結合されます。
need-explorer? → spec-writer → workflow-start
→ build-executor → code-reviewer → spec-merger?
→ release-archivist
疑問符はオンデマンドで有効にすることを表します。すべてのタスクを完了する必要がある組立ラインではなく、組み合わせ可能な一連のエンジニアリング機能が得られます。
デフォルトは軽量ですが、高度な実行機能も保持しています
2.0 はデフォルトでネイティブ モードを使用し、現在のエージェントを現在のセッションに引き続き実装できます。通常のタスクを自動的にサブタスクに分割し、複数のエージェントにディスパッチし、「プロセスを完了する」ためにウェーブごとのレビューを待つ必要はありません。
複雑なタスクを並列化する必要がある場合でも、SDD、サブエージェント、およびウェーブごとのレビューを明示的に有効にすることができます。複数のチェックアウトを同時に維持する必要がある場合、ワークツリーを明示的に選択することもできます。違いは、これらの機能が開発ごとの固定コストになるのではなく、ミッションのニーズによってトリガーされるようになったことです。
通常のセッションは、SessionStart またはグローバル ルールによって完全なワークフローに挿入されません。必要な命令とステータスは、既存の変更または明示的な呼び出しがある場合にのみ読み取られます。
これにより、spec-superflow は、ファイルに対する小さな修正だけでなく、複雑なモジュール間、クロスサブミット、および長期サイクルの開発にも適しています。
変更されたプロセスの説明だけでなく、メジャー バージョンによって検証される
v1.2.0 から v2.0.0 へのアップグレードは、5 つのコミットと 115 のファイルに及びます。 Git shortstat は 3,374 行が追加され、3,291 行が削除されました。
ローカルのリリース候補が完成しました。
- 153 のテスト スイート、916 の自動テスト。
- Raw パッケージがインストールされ、スモーク テストが実行されます。
- CLI、スキル、テンプレート、インストーラー、ドキュメントの一貫性チェック。
- Linux、macOS、Windows のパス境界をカバーします。
このプロジェクトはランタイム依存関係をゼロに維持し、Node.js 20 以降で実行でき、Codex、Claude Code、Cursor、GitHub Copilot CLI、Gemini CLI、OpenCode、WorkBuddy、Trae などの 19 の AI プログラミング プラットフォームへのアクセスを提供します。
使用方法 1: 2.0 をインストールする
この記事の公開時点では、v2.0.0 タグはすでに新しい README を含む最新のコミットを指しています。 GitHub リリースと npm 2.0.0 はまだ Marketplace バージョンのアクセス制御を待っているため、最初に固定タグを使用して Codex CLI/アプリをインストールできます。
codex plugin marketplace add MageByte-Zero/spec-superflow --ref v2.0.0
codex plugin add spec-superflow@spec-superflow
他のプラットフォームでは、リポジトリのルート ディレクトリからインストーラを実行するか、 INSTALL.md プラットフォームに応じたコマンドです。
使用方法 2: Direct を使用して小さなタスクを完了する
境界が明確な小さなタスクの場合は、Direct を直接開始します。
mkdir -p changes/fix-login-timeout
ssf workflow start changes/fix-login-timeout \
--path direct \
--scope "修复登录超时，不改变认证协议"
実装が完了したら、実際の検証コマンドを使用してタスクを終了します。
ssf workflow complete changes/fix-login-timeout \
--verification-command "npm test"
検証が失敗した場合、ステータスは合格として書き込まれません。修復後、同じ変更を継続して実行し、再度検証を完了します。
活用方法3：Plannedを利用して複雑なタスクを進める
最初に複雑なタスクを作成する proposal.md そして tasks.md。公共の行動が関係する場合は仕様を補足し、アーキテクチャ上のトレードオフがある場合は設計を行います。ユーザーがスコープを確認した後に開始します。
ssf workflow start changes/add-session-refresh \
--path planned \
--confirm \
--reason "用户已批准 proposal.md 与 tasks.md"
実行中はいつでも確認および復元できます。
ssf resume changes/add-session-refresh
ssf checkpoint save changes/add-session-refresh
ssf validate changes/add-session-refresh
デルタ仕様が含まれる場合は納品前にご使用ください ssf sync アトミック同期の正式仕様。実装の完了、全範囲のレビュー、および終了してアーカイブする前の最終検証。
使用法 4: ブランチまたは明示的なワークツリーを選択する
通常の機能ブランチがデフォルトで作成されます。
ssf isolate changes/add-session-refresh
複数のチェックアウトを同時に維持する必要がある場合にのみ、ワークツリーを明示的に作成します。
ssf isolate changes/add-session-refresh --worktree
リカバリおよび完了操作では、レコード内のリポジトリ、ブランチ、およびパスがチェックされ、間違ったディレクトリで実行が継続されることが回避されます。
選択基準は 3 つの文に要約できます。目標と検証が明確な場合は、直接を使用します。スコープを最初に承認する必要がある場合は、計画を使用します。並列の利点または分離要件が明確な場合にのみ、サブエージェントとワークツリーを有効にする必要があります。
AI プログラミングを高速化し、最終結果に責任を持たせる
spec-superflow 2.0 の目標は明確です。小さなタスクはプロセスによって速度が低下することはなく、複雑なタスクは会話が長くなってもずれることはありません。
OpenSpec は持続的に維持される要件と仕様構造を提供し、Superpowers は根本原因のデバッグ、コード レビュー、完了前検証を提供し、spec-superflow はそれらを実際のプロジェクトでリスクを負って実行できる完全な閉ループに変えます。
Codex、Claude Code、Cursor、またはその他の AI エージェントを使用してプロジェクトを開発している場合は、小さな直接タスクから始めることができます。次回、モジュール間の変換に遭遇したときは、Planned を使用して、スコープのロック、実行の回復、完全なレビューによってもたらされる確実性を感じてください。
プロジェクトのアドレス: MageByte-Zero/spec-superflow。 Star へようこそ。試してフィードバックを送信してください。
公開アカウント「Ma Ge Tiao」もぜひフォローしてください。私は今後も、AI プログラミングのワークフロー、エージェント エンジニアリングの実践、大規模なモデルを検証可能なソフトウェア開発プロセスに実際に組み込む方法について共有していきます。
WeChat に私を追加して、独占的な技術グループに参加してください。読者の皆様もコメントをお待ちしております。気に入っていただけましたら、ブログと個人公開アカウント: Code Byte をフォローしてください。
