33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
|
# よくある詰まりポイント
|
|||
|
|
|
|||
|
|
## AIの出力がぶれる
|
|||
|
|
|
|||
|
|
仕様（project-brief）の曖昧な部分を埋める。
|
|||
|
|
特に「スコープ外」が定義されていないと、AIが勝手に機能を追加しやすい。
|
|||
|
|
|
|||
|
|
プロンプトの「変更してはいけない範囲」に明示的に書くと安定する。
|
|||
|
|
|
|||
|
|
## レビューAIごとに指摘が違う
|
|||
|
|
|
|||
|
|
`30_review.md` の構造化フォーマット（重大度・根拠・影響・修正案）を
|
|||
|
|
必ず使うことで、AIによるブレが小さくなる。
|
|||
|
|
|
|||
|
|
仕様外の提案は「Nice to have」として分けてもらうと判断しやすい。
|
|||
|
|
|
|||
|
|
## どのタスクから始めればいいかわからない
|
|||
|
|
|
|||
|
|
依存関係がないタスク（「依存」列が `-` のもの）から始める。
|
|||
|
|
迷ったらAIに「どれから始めるのが最も安全ですか」と聞いてよい。
|
|||
|
|
|
|||
|
|
## 途中でアイデアが変わった
|
|||
|
|
|
|||
|
|
`project-brief` を更新してから、影響するタスクを見直す。
|
|||
|
|
すでに実装済みのタスクを壊す変更は、新しいタスクとして分けて追加する。
|
|||
|
|
|
|||
|
|
## APIキーをどこに書けばいいかわからない
|
|||
|
|
|
|||
|
|
`.env.example` を参考に `.env` ファイルを作って、そこに書く。
|
|||
|
|
`.env` は `.gitignore` に含まれているので、GitHubに上げても漏れない。
|
|||
|
|
|
|||
|
|
コードの中には変数名だけ書く（例: `process.env.API_KEY`）。
|