ローカルのQwen3.6 35BでPI Coding Agentを使ってみたら、正直かなりヤバい

Reddit r/LocalLLaMA / 2026/4/23

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research

要点

  • 著者は、ローカルでQwen3.6 35B(a3b q4_k_xl)を使ってPI Coding Agentを実案件に適用したところ、想像以上にうまくいったと報告しています。
  • 大きな転機になったのは、「plan-first(先に計画)」用のスキルファイルを自作したことで、指示に沿って手順を踏み、脱線しにくい点が特に改善したと述べています。
  • そのスキルファイルは、コードベースを分析→1回で最大5つの重要な確認質問→TODO.mdを作成→ユーザー承認→承認後にタスク実行、という流れの構造化ワークフローを実装しています。
  • さらに、TODO.mdが承認される前にコードを書いたりファイルを作成したりコマンドを実行しない、などの明確なガードレールが含まれており、新たに発見された作業はTODO.mdに追記して承認を求める設計です。

実際のプロジェクトで、Qwen3.6 35b a3b q4_k_xl モデルの「PI Coding Agent」をいくつか回してみたのですが、正直ここまで上手く動くとは思っていませんでした。

決定的に良かったのは、私が作った「plan-first(計画優先)」スキルファイルです。これは本当に、あなたの言ったことをそのまま守って、軌道を外れずに、手順を追って全部実行してくれます。実運用のものに使ってみましたが、きちんと耐えてくれました。

誰か試してみたいなら、こちらがスキルファイルです:

--- name: plan-first description: どんなコーディングタスクでも使える、構造化された計画ワークフロー。新しい機能、バグ修正、リファクタ、実装依頼のたびに最初に使う。プロジェクトを分析し、最大5つの確認質問を行い、TODO.mdを作成し、ユーザーの承認を得たうえで、タスクを1つずつ実行する。計画が承認されるまでコードを書かない。 --- # Plan-First Workflow ## ルール - TODO.mdが承認されるまで、決してコードを書かない/ファイルを作成しない/コマンドを実行しない。 - 不足している情報を決めつけない。代わりに質問する。 - 手順を決して飛ばさない。フェーズの順番に従う。 - 計画から外れない。新しい作業が見つかった場合は、それをTODO.mdに追加し、承認を取ってから実行する。 --- ## フェーズ1 — プロジェクトの分析 何かを聞く前に、プロジェクトを黙って読みます。チェック: 1. ディレクトリ構造(上位2階層) 2. `package.json`、`pubspec.yaml`、`go.mod`、`requirements.txt`、`Cargo.toml`、`pom.xml`、または同等のもの 3. 既存の依存関係とそのバージョン 4. ビルドシステムとスクリプト(`Makefile`、`scripts/`、CI設定) 5. `README.md` または `README.*` 6. 既存の `TODO.md`、`TASKS.md`、`.todo`、または未解決の課題ファイル 分析結果を、質問に直接関係する場合を除いて出力しない。 --- ## フェーズ2 — 確認質問(1回だけ) 分析後、正しい実装を妨げるギャップを特定する。 - **1つのメッセージで最大5つまで**質問する。 - コードベースから推測できない、**致命的に重要な**ものだけ質問する。 - 質問に番号を振る。 - プロジェクトファイルからすでに分かることについては質問しない。 - 複数ラウンドに分けない。これが質問できる唯一のチャンス。 例の形式: ``` 計画を作成する前に、いくつか確認したいことがあります: 1. 新しいエンドポイントには認証が必要ですか? 2. 優先するデータベースはありますか(このプロジェクトにはSQLiteとPostgresの両方の設定があります)? 3. 既存のテストは更新すべきですか、それとも新しいテストだけ追加すべきですか? ``` 進める前にユーザーの回答を待つ。 --- ## フェーズ3 — TODO.mdを作成 分析とユーザーの回答をもとに、プロジェクトのルートに `TODO.md` ファイルを書き込みます。 ### TODO.mdの構造 ```markdown # TODO ## Goal 1文で、何を構築または修正するのかを説明する。 ## Tasks ### 1. <Phase Name> - [ ] <具体的で測定可能なアクション> - [ ] <具体的で測定可能なアクション> ### 2. <Phase Name> - [ ] <具体的で測定可能なアクション> - [ ] <具体的で測定可能なアクション> ## Notes ここに、制約・判断・既知のリスクを記録する。 ``` ### 要件 - タスクは **小さく、独立して検証可能**(論理的に1つの変更ごと)。 - タスクは **依存関係** に従って並べる(前提条件が先)。 - 各タスクは、完了/未完了のどちらかで確認できること。 - 「いろいろ直す」や「コードを改善する」など曖昧な項目は禁止。 ファイルを書いたら、ユーザーにファイルの全文を表示し、次を尋ねる: ``` TODO.mdを作成しました。この計画は正しいと思われますか? YESで開始するか、変更点を教えてください。 ``` --- ## フェーズ4 — リビジョンループ(必要なら) ユーザーが変更を求めた場合: 1. 意見の相違を解消するための、的を射た追加質問をする。 2. `TODO.md` を書き直す。 3. 更新された計画を表示して、もう一度承認を求める。 ユーザーが承認するまで繰り返す。 --- ## フェーズ5 — 計画の実行 承認後: 1. タスクを **順番に**、1つずつ実行する。 2. 各タスクを完了したら、`TODO.md` で完了として印を付ける: - `- [ ]` を `- [x]` にする 3. 実行する前に、どのタスクを開始するかを宣言する。 4. 現在のタスクが完了するまで、次のタスクを開始しない。 5. `TODO.md` に載っていない作業は一切しない。 未掲載のタスクが必要だと分かった場合: - 停止する。 - `## Discovered Tasks` セクションの下に `TODO.md` に追加する。 - ユーザーに、何が見つかったかと、なぜ必要なのかを伝える。 - 継続する前に承認を求める。 すべてのタスクが `[x]` でマークされたら、次を書く: ``` TODO.mdのすべてのタスクが完了しました。 ``` 

まだ試していないなら、ぜひ試す価値があります。ローカルモデルはかなり進化してきましたね。

submitted by /u/SoAp9035
[link] [comments]