LLM を使った vibe coding は、私たちのソフトウェアの作り方を根本から変えました。秘訣は何か？ AI コーディングアシスタントに、明確で正確な言葉で話しかけることです。効果的なプロンプトの書き方を身につけるには練習が必要ですが、実戦で検証済みのプロンプト集を持っていれば、ワークフローを大きく加速できます。
すべての vibe coder が押さえておくべき 12 の核心プロンプトです。これらは単なるコピペ用テンプレートではありません。各プロンプトの背後にある構造と意図を理解すれば、どんな状況でも AI アシスタントとより効果的にコミュニケーションできるようになります。
第 1 部：計画とアーキテクチャ（プロンプト 1〜3）
1. PRD ジェネレーター：明確さから始める
最初の一行を書く前に、明確なプロダクト要件ドキュメントが必要です。このプロンプトは、すべての重要な要素について考えることを強制します：
使う場面： 新しいプロジェクトや重要な機能のいちばん最初の段階。
プロンプト：
我想构建【你的想法】。 在编写任何代码之前，创建一份 PRD，包含： 1. 问题陈述：这解决了什么问题？谁有这个问题？ 2. 用户故事：5-7 个故事，格式为"作为【用户】，我想要【行动】，以便【收益】" 3. 核心功能（仅 MVP）：v1 版本必须有什么？要狠心砍掉不必要的。 4. 不在范围内：什么功能留到 v2？ 5. 技术需求：技术栈、集成、数据模型、认证需求 6. 成功指标：我们如何知道它有效？ 7. 待解决问题：在构建之前需要决定什么？ 要具体，不要泛泛而谈。
なぜ効くのか： このプロンプトは、問題を理解しないまま直接コーディングに飛び込むという典型的なミスを防ぎます。「思い切って削れ」（要狠心砍掉）という指示は特に強力で、スコープを大幅に削ることを強いてくれます。これは素早くリリースするために不可欠です。
2. コードベース考古学者：作る前に理解する
コードベースを引き継いだ、あるいは数か月ぶりに自分のコードに戻ってきた？ このプロンプトはアーキテクチャを素早く理解するのに役立ちます。
使う場面： 新しいプロジェクトへの参加、チームのコードベースへの合流、あるいは既存コードに重要な機能を追加する前。
プロンプト：
分析这个代码库，告诉我： 1. 架构模式（MVC、Clean 等） 2. 数据流：用户输入 → API → 数据库 → UI 3. 关键文件：路由在哪？模型在哪？认证在哪？业务逻辑在哪？ 4. 关键依赖及其作用 5. 添加新功能时需要遵循的模式（从代码中展示示例） 6. 潜在问题（安全、性能、过时的模式） 7. 如果我想添加【功能】，我需要修改哪些文件？ 先完整阅读文件。不要假设。
なぜ効くのか： 「まずファイルを全部読め。推測するな」（先完整阅读文件。不要假设）という指示が決定的に重要です。AI がよくあるパターンに基づいて推測するのを防ぎ、実際のコードベース構造を分析するよう強制します。
3. 実装プランナー：コードを書く前に考える
混乱した、保守しにくいコードを防ぐうえで、これが最も重要なプロンプトかもしれません。
使う場面： PRD が承認された後、実装コードを書き始める前。
プロンプト：
我需要实现这个【PRD 或功能】。 在编写代码之前，创建一个实现计划： 阶段 1 - 分析： - 这会影响哪些现有代码？ - 需要哪些新文件？ - 任务之间的依赖关系？ 阶段 2 - 数据： - 数据库结构变更 - 新的 API 端点 - 验证规则 阶段 3 - 后端： - 业务逻辑 - 错误处理 - 边缘情况 阶段 4 - 前端： - 需要的组件 - 状态管理 - 用户反馈 阶段 5 - 集成： - 各部分如何连接 - 测试方法 - 回滚计划 对于每个阶段：复杂度（简单/中等/复杂）和具体文件。 不要编写代码。我需要先批准这个计划。
なぜ効くのか： 「コードを書くな」（不要编写代码）という指示は強力です。コードをコミットする前に、あなたと AI の両方に実装プロセス全体を考え抜くことを強制します。実装の途中でアーキテクチャの問題に気づくというよくある落とし穴を防いでくれます。
第 2 部：スコープ管理とデバッグ（プロンプト 4〜5）
4. スコープの番人：少なく作ってこそ速く出せる
機能の膨張はプロジェクトを台無しにします。このプロンプトは、容赦なくスコープを削り、より速くリリースするのに役立ちます。
使う場面： 機能を計画するとき、「あと一つだけ機能を」と思ったとき、あるいはスケジュールが遅れているとき。
プロンプト：
我正在构建【功能】。做我无情的范围守护者。 1. 最小可行版本：能提供价值的绝对最简单版本是什么？ 2. 暂不构建：锦上添花的功能、<5% 用户的边缘情况、过早优化 3. 完成定义：什么标准 = 可以发布？ 4. 时间陷阱：什么会比预期花费 10 倍时间？ 5. 唯一的事：如果我只能交付一个能力，应该是什么？ 要激进。我以后总能添加更多。
なぜ効くのか： 「アグレッシブに」（要激进）という指示は、AI をスコープに疑問を投げかける厳格なプロダクトマネージャーに変えます。「たった一つのこと」（唯一的事）という問いは特に強力で、核心となる価値提案を見極めることを強いてくれます。
5. デバッグ探偵：ループから抜け出す
同じ問題を何時間もデバッグしている？ このプロンプトは、新しい可能性を体系的に探ることでループから抜け出す助けになります。
使う場面： 複数の修正案を試してもどれも効かないとき、あるいはデバッグで堂々巡りしているとき。
プロンプト：
我陷入了调试循环。Bug 是：【描述它】 你已经尝试了很多不起作用的方法；先分析什么没有帮助。在建议修复之前： 1. 列出 5-7 个不同的新可能原因。考虑： - 数据问题，而不是代码？ - 环境/配置问题？ - 竞态条件/时序问题？ - 缓存问题？ - Bug 完全在其他地方？ 2. 按可能性排序 3. 对于前 2 个：添加诊断日志来证明/反驳每个。先不要修复。 4. 只有在我们确认原因后才修复。
なぜ効くのか： このプロンプトは「手当たり次第に修正を試す」やり方を防ぎます。修正の前に診断を強制することで時間を節約し、その場しのぎの対処ではなく根本原因の理解につながります。
第 3 部：コード品質と保守（プロンプト 6〜7）
6. 技術的負債の監査人：進めながら片付ける
技術的負債は音もなく積み上がります。このプロンプトは、片付け作業の特定と優先順位付けに役立ちます。
使う場面： 毎月のメンテナンススプリント、大規模なリファクタリングの前、あるいはコード品質が速度に影響しているとき。
プロンプト：
审计这个代码库的技术债务。给我一个可操作的优先级列表。 查找： 1. 应该提取的重复代码 2. 死代码（未使用的文件、函数、导出） 3. 过时的模式、废弃的 API 4. 缺失的错误处理 5. 安全隐患（硬编码密钥、SQL 拼接、缺失验证） 6. 性能问题（N+1 查询、缺失索引、不必要的重渲染） 7. 类型安全缺口（any 类型、缺失验证） 对于每个：文件/行号、问题是什么、风险（低/中/高）、建议修复。 按风险排序，最高的在前。
なぜ効くのか： リスクに基づく優先順位付けによって、重要なことに集中できます。高リスクの項目にはすぐ対処し、低リスクの片付けは後回しにできます。
7. コード統合者：コードベースを DRY に保つ
重複コードは保守の悪夢です。この 2 部構成のプロンプトは、重複コードの統合とデッドコードの削除に役立ちます。
使う場面： 複数の場所に似たコードがあると気づいたとき、あるいはリファクタリングスプリントの最中。
プロンプト：
我有需要整合的重复代码。 1. 找到所有实例。列出它们。 2. 每个之间有什么不同？这些差异重要吗？ 3. 创建一个处理所有情况的共享工具。灵活但不复杂。 4. 迁移计划：每个文件的前后对比 5. 风险评估：什么可能会出问题？ 逐步进行。一次一个模式。 同时查找并删除死代码。 寻找： 1. 未使用的导出（已导出但从未导入） 2. 注释掉的代码 3. 不可达代码（return 之后、不可能的条件） 4. package.json 中未使用的依赖 5. 孤立文件（没有被导入的地方） 6. 旧的功能标志（始终为 true/false） 对于每个：是什么、在哪里、如何确认未使用、安全删除吗？ 不要删除动态导入的代码。标记这些供手动审查。
なぜ効くのか： 段階的なアプローチは、すべてを壊すビッグバン型のリファクタリングを防ぎます。「動的にインポートされるコードを削除するな」（不要删除动态导入的代码）という警告は、よくあるミスを防いでくれます。
第 4 部：セキュリティとデプロイ（プロンプト 8〜9）
8. セキュリティ監査人：安全にリリースする
セキュリティの脆弱性は、プロダクトと評判を台無しにしかねません。このプロンプトは、本番環境に入る前に問題を見つけるのに役立ちます。
使う場面： 本番デプロイのたびに、認証／認可を追加した後、あるいは機微なデータを扱うとき。
プロンプト：
生产前安全审计。 检查： 1. 注入攻击：SQL 注入、命令注入、XSS 2. 认证：硬编码密钥、弱密码、缺失速率限制、不过期的会话 3. 授权：IDOR、缺失的认证检查、可绕过的角色检查 4. 数据暴露：日志中的敏感数据、向用户显示堆栈跟踪、PII 泄露 5. 配置：调试模式、宽松的 CORS、缺失的安全头 对于每个问题：严重性、文件/行号、如何利用、如何用代码修复。 要彻底。深度思考。
なぜ効くのか： 「どう悪用できるか」（如何利用）という要求は、AI に攻撃者のように考えることを強制し、理論上ではなく現実の脆弱性を見つけるのに役立ちます。
9. リリース前チェックリスト：自信を持ってデプロイする
本番環境へのデプロイは緊張するものです。このチェックリストは、重要な項目を見落としていないことを確認してくれます。
使う場面： 本番デプロイのたびに、特に初めてのデプロイのとき。
プロンプト：
部署到生产环境。运行上线前检查清单： 环境： - 密钥在环境变量中（不是硬编码）？ - dev/prod 有不同配置？ - .env.example 存在吗？ - 调试模式关闭了吗？ 安全： - 敏感路由有认证吗？ - 公共端点有速率限制吗？ - 到处都有输入验证吗？ - 强制 HTTPS 了吗？ - 设置了安全头吗？ 错误： - 有全局错误处理器吗？ - 向用户显示友好错误吗？ - 错误有上下文记录吗？ 数据库： - 迁移是最新的吗？ - 查询列上有索引吗？ - 有连接池吗？ 对于每个：✅ 良好、⚠️ 需要注意（修复什么）、或 ❌ 缺失（如何添加）。
なぜ効くのか： 信号機方式（✅⚠️❌）のおかげで、すぐに対応が必要なものと、すでに片付いているものが一目で分かります。
第 5 部：テストとデザインシステム（プロンプト 10〜11）
10. クリティカルパステスター：重要なものをテストする
すべてのコードにテストが必要なわけではありませんが、クリティカルパスには絶対に必要です。このプロンプトは、重要な部分を特定してテストするのに役立ちます。
使う場面： お金、データ、認証を扱う機能をリリースする前。
プロンプト：
为关键路径生成测试。 关键 = 如果损坏，会损失金钱、丢失数据、锁定用户或导致安全问题。 测试： 1. 认证流程： - 注册有效 → 用户创建 - 注册现有邮箱 → 错误 - 登录正确 → 会话 - 登录错误 → 拒绝，无信息泄露 - 未认证访问受保护路由 → 重定向 2. 数据变更（创建/更新/删除）： - 正常路径 - 无效数据被拒绝 - 不能变更他人数据 - 失败的变更 = 无部分状态 3. 支付（如适用）： - 正常路径 - Webhook 成功 - Webhook 失败 - 没有付费就没有付费功能 使用【你的框架：Jest/Vitest/Playwright】。AAA 模式。测试行为而不是实现。独立测试。 生成实际的测试文件。
なぜ効くのか： 「クリティカルパス」に集中することでテストの肥大化を防ぎます。「実装ではなく振る舞いをテストせよ」（测试行为而不是实现）という指示により、実装の詳細が変わってもテストの価値が保たれます。
11. デザインシステム抽出器：スケールしても一貫性を保つ
コードベースが成長するにつれ、デザインの不整合は倍々に増えていきます。このプロンプトは、デザインシステムの抽出と標準化に役立ちます。
使う場面： デザインの不整合に気づいたとき、リデザインの前、あるいはチームを拡大するとき。
プロンプト：
从这个代码库中提取设计系统。 查找并标准化： 1. 颜色：扫描 hex/rgb。分类（主色、次色、背景、文本、成功、错误）。创建 CSS 变量。 2. 排版：字体、大小、粗细。创建比例尺。 3. 间距：边距、内边距、间隙。创建一致的比例尺（4、8、16、24、32px）。 4. 组件：重复模式（按钮、卡片、输入）。创建基础 + 变体。 5. 阴影/边框：标准化为 2-3 个选项。 输出： 1. 设计令牌文件 2. 何时使用什么 3. 需要修复的不一致性 4. 迁移计划 要实用。我应该明天就能用。
なぜ効くのか： 「実用的に。明日から使えるものを」（要实用。我应该明天就能用）という指示が過剰設計を防ぎます。得られるのは理論上のものではなく、使えるデザインシステムです。
第 6 部：上級テクニック（プロンプト 12）
12. 深い思考の起動装置：必要なときに深い推論を
ときには AI にもっと頑張って考えてもらう必要があります。このシンプルな一言を加えるだけで、出力の品質が目に見えて向上します。
使う場面： 複雑な問題、セキュリティ監査、アーキテクチャの決定、あるいは最初の応答が浅く感じられたとき。
プロンプト：
深度思考。
なぜ効くのか： このメタプロンプトは、多くの LLM でより深い推論モードを起動します。より徹底した分析が必要なときは、他のプロンプトと組み合わせて使ってください。
総合的に活用する
この 12 のプロンプトが、vibe coding の完全なツールキットになります：
計画フェーズ： プロンプト 1〜3 でコーディング前に計画する
構築フェーズ： プロンプト 4〜5 でスコープを管理し、効果的にデバッグする
保守フェーズ： プロンプト 6〜7 で高いコード品質を維持する
リリースフェーズ： プロンプト 8〜9 で安全にデプロイする
拡張フェーズ： プロンプト 10〜11 でテストし、システム化する
どのフェーズでも： より深く考える必要があるときはプロンプト 12 を使う
最後のアドバイス
-
かっこ内をカスタマイズする：
【你的想法】（あなたのアイデア）、【功能】（機能）、【框架】（フレームワーク）を自分の具体的なコンテキストに置き換える -
プロンプトを組み合わせる： 複雑なワークフローでは複数のプロンプトを順番に使う
-
反復する： 最初の応答が完璧でなければ、より多くのコンテキストを添えてプロンプトを練り直す
-
自分のバリエーションを保存する： これらのプロンプトをカスタマイズしたら、自分のワークフローに最も合うバージョンを保存しておく
効果的な vibe coding の鍵は、良いプロンプトを持つことだけではなく、いつ、どう使うかを理解することです。この 12 個から始めて、自分のニーズに合わせて調整し、生産性が跳ね上がるのを見届けてください。
楽しい vibe coding を！
これらのプロンプトは、Cursor、GitHub Copilot などの AI コーディングアシスタントや、その他の LLM 駆動の開発ツール向けに設計されています。