為什麼從 Coding 說起？
Vibe Coding 是目前最成熟、最可驗證的 Vibe 場景：
- 產出可運行：代碼能跑就是成功
- 反饋即時：報錯立刻知道
- 方法論完整：已有大量實踐
掌握 Vibe Coding 的方法論後，可以輕鬆遷移到其他工作場景。
核心認知：你是包工頭，不是程序員
⚠️ 殘酷真相
網上「一句話生成 APP」的視頻，99% 是玩具 Demo。
真正能上架、能賺錢的產品，需要：
- 可控性：不是 AI 隨意發揮
- 貼合業務目標：解決真實問題
- 可維護：後續能迭代
你的角色：把模糊想法層層翻譯成 AI 能執行的精確指令。
階段一：市場與競品調研（知己知彼）
不要一上來就想功能！ 先看看市面上誰在做，做得怎麼樣。
實戰 Prompt 模板
## 角色設定
你現在是一位有著豐富經驗的互聯網產品戰略專家，擅長通過復盤競爭對手的歷史演變來洞察市場機會。
## 背景
我有一個初步的產品想法：[在此處簡述你的想法，例如：我想解決6-12歲孩子語文課文背誦難、無趣、易遺忘的問題]。為了做到"知己知彼，百戰不殆"，在正式動手規劃前，我需要先摸透市面上的潛在對手。
## 核心任務：深度競品與演化路徑調研
請利用你的檢索和分析能力，幫我找出市面上3-5款最相關的競品（包含國內和國外典型代表），並圍繞以下三個核心維度進行深度挖掘，輸出一份結構化的分析報告：
### 維度一：現狀快照 (The "Now")
1. 競品清單：它們分別是誰？
2. 核心定位與人群：它們現在的一句話介紹是什麼？主打的價值主張是什麼？面向的主要是哪類特定用戶群體？
3. 當前解決方案：它們目前解決用戶核心痛點的主要功能（Killer Features）是什麼？
4. 現存優劣勢：用戶目前對它們最大的讚譽點和吐槽點（痛點）分別是什麼？
### 維度二：歷史溯源與環境還原 (The "Past Context")
請盡量回溯它們早期的發展歷程，分析它們"起家"時的狀況：
1. 最初切入點：回顧它們剛上線時的版本（V1.0），它們最初選擇的切入點和核心功能是非常單一的嗎？是什麼？
2. 當時的市場狀況：在它們推出初期，那個細分市場是怎樣的？
3. 當時的技術約束推測：推測在它們上線初期，受限於當時的技術條件，它們被迫做了哪些功能上的妥協？
### 維度三：演化路徑分析 (The "Evolution")
1. 關鍵迭代路徑：從最初的V1.0到現在的版本，它們經歷了哪些里程碑式的產品升級？
## 輸出要求
請以清晰的結構化報告形式輸出，並在報告的最後，基於以上分析，結合我的初步想法，給我 1-2 條關於我的產品"切入點"的戰略建議。階段二：產品定義與 PRD 生成
把模糊想法變成具體的功能清單。
實戰 Prompt 模板
## 角色設定
你現在是我的產品合夥人，一位經驗豐富的互聯網產品經理。
## 背景
基於我們之前的市場調研（見上文），我決定做一款[你的產品一句話介紹，例如：面向6-12歲兒童的"聽玩說"一體化背誦APP]。我的核心價值主張是[例如：讓孩子在碎片時間里"聽著-玩著-說著"完成背誦任務，降低背誦抵觸情緒]。
## 任務
請幫我梳理並輸出一份簡版的PRD文檔。需要包含：
1. **產品定位**：用精煉的語言描述我們是誰，服務誰，解決什麼核心問題。
2. **核心功能模塊**：列出P0級（最高優先級）的核心功能清單，並簡述每個功能的預期用戶行為（例如："課文音頻聽讀"——用戶選擇課文後，可調節語速、循環播放，支持後台播放）。
3. **用戶路徑**：描述一個典型用戶完成一次核心體驗（例如：完成一次課文背誦+復習）的操作流程（按步驟說明）。
4. **非功能需求**：考慮到我是一個獨立開發者，請建議一些關於性能、安全性的基本原則（例如：APP啟動時間≤3秒，本地緩存用戶背誦記錄，無敏感信息收集）。階段三：技術方案（關鍵轉折點）
⚡ 關鍵心法
千萬不要試圖指揮 AI 怎麼寫代碼！
把自己降級為小白，讓 AI 做 CTO。
實戰 Prompt 模板
## 角色設定
你現在是我聘請的天才CTO，精通全棧開發和架構設計，擅長為獨立開發者提供低成本、低運維、易上手的技術方案。
## 背景信息
- **項目需求**：請讀取上文的PRD文檔和產品原型（若有原型描述可補充此處）。
- **我的身份**：我是一個完全不懂代碼的技術小白，獨立開發者。
- **目標平台**：我需要同時開發安卓和iOS兩個客戶端。
- **核心約束（極重要）**：
1. **零運維經驗**：請推薦最不需要我操心服務器運維、部署最簡單的技術方案（BaaS或其他Serverless方案優先）。
2. **國內環境可用**：請確保你推薦的所有技術棧、雲服務、API在國內網絡環境下都能穩定、合規地使用。
3. **成本控制**：項目初期預算有限，請優先考慮免費額度高或成本極低的方案。
4. **上手難度低**：在滿足功能的前提下，選擇對初學者最友好、文檔最完善的技術棧。
## 任務
請為我出具一份詳細的《技術規格說明書》，包含：
1. **核心架構圖**：用文字描述系統的整體架構邏輯（無需畫圖，用文字拆解"前端-後端-第三方服務-存儲"的交互關係）。
2. **技術棧推薦**：明確列出客戶端框架、後端服務、數據庫選型，並解釋為什麼這麼選（必須結合我的約束條件）。
3. **數據庫設計**：設計核心數據表結構（Table Schema），並解釋每個字段的含義（例如：用戶表、課文表、背誦記錄表）。
4. **API接口清單**：列出核心業務所需的API接口定義（RESTful風格），包含接口路徑、請求方法、參數說明、返回格式。
5. **項目目錄結構**：預演一個標準的工程目錄樹結構（分前端、後端），明確核心文件的存放路徑。
6. **風險評估**：提前告知我這個方案可能會遇到哪些坑（例如：第三方API調用限額、部署時的環境配置問題），以及初步的規避建議。💡 個人經驗
用 ChatGPT 生成初版，扔給 Gemini 挑刺 Review，幾輪對話後得到靠譜方案。
這份文檔就是後續開發的「最高法律」。
階段四：開發期——工程化管理
起手式三步曲
1
定結構
讓 AI 根據《技術規格書》生成標準項目目錄樹，把空文件夾和基礎文件建好
2
集中管理
把 PRD、技術規格書、數據庫設計、常用提示詞統一整理到 docs/ 文件夾
3
建立 TodoList
讓 AI 閱讀以上信息，幫你拆解出詳細的開發任務清單，然後逐個擊破
獨家秘籍：Process-Log（治好 AI 健忘症）
最痛的領悟
對話過長或切換模型時，AI 會「失憶」——忘記變量名、忘記代碼規範、把修好的 Bug 又寫回來。
解決方案：建立「外部記憶體」
在項目根目錄創建 process-log.md，每次重大改動都更新。
Process-Log 完整模板
# Process Log (項目進度日誌)
## 1. 當前階段 (Current Phase)
- [x] 階段 1: 項目初始化與基礎設施搭建
- [x] 階段 2: 前端 UI 大重構 (Completed)
- [ ] 階段 3: 核心業務後端對接 (進行中) —— 接口已通，前端聯調中...
- [ ] 階段 4: 核心功能開發 - ASR錄音與上傳鏈路
## 2. 最近一次完成的任務 (Last Completed Tasks)
- [2025-12-04] **後端 AI 能力落地**:
- 切換了 `/api/ai/poem_image` 接口的實現模型為 `qwen-image-plus`。
- 前端新增 `app/lib/data/repositories/ai_repository.dart` 封裝了相關AI接口。
- [2025-12-03] **自定義域名 HTTPS 配置**:
- 完成了 `api.xxx.xyz` 的CNAME配置和證書生效，強制HTTPS跳轉。
- 前端 BASE_URL 已更新為新域名。
## 3. 待解決的問題 / 下一步計劃
- **前端聯調**: 在詳情頁接入 `/api/ai/story` 接口，處理加載中和失敗的狀態兜底。
- **錄音鏈路**: 實現前端錄製 16k/Mono 音頻並上傳的邏輯。
## 4. 關鍵技術決策備忘 (Tech Decisions)
- **狀態管理**: 決定使用 `Riverpod` 管理全局狀態，不要再建議使用 Provider 或 Bloc。
- **路由管理**: 統一使用 `GoRouter` 處理深層鏈接。
- **OSS策略**: 為了安全起見，Bucket 設為私有，文件訪問必須通過後端生成簽名URL返回給前端，而不是前端直傳。🔥 使用技巧（超級重要）
每次開新 Chat，第一句話永遠是：
"你好，我們繼續開發。請先讀取項目根目錄下的 process-log.md 文件，這是我們當前的最新進度和關鍵決策。請基於此上下文繼續我們的工作。"
這就像給 AI 裝了一個外掛硬盤，進度切換無比絲滑。
Vibe Coding 避坑指南
坑 1：部署地獄
AI 默認你懂 Linux，命令簡略導致報錯連連。
應對策略：
- 強調「我是一個完全不懂 Linux 的小白」的人設
- 要求每條命令單獨列出 + 解釋用途 + 可能報錯
- README 裡專門記錄環境問題和解決方案
關鍵話術：
"我是完全不懂 Linux 的小白，請把每一條需要執行的命令都單獨列出來，並解釋這一行命令是幹什麼用的，可能會有什麼報錯。"
坑 2：接口對接
AI 很容易瞎編第三方接口參數。
應對策略：
不要說「幫我接下阿里的 qwen3 模型」，而是：
"這是[阿里雲百煉]的官方接口文檔[鏈接/全文內容]。請仔細閱讀後，嚴格按照文檔要求，幫我寫出 Service 層對接代碼，並包含必要的錯誤處理。"
坑 3：需求失控
初始想法模糊導致 AI 開發方向跑偏。
應對策略：
先調研 → 再 PRD → 再原型 → 最後技術規格書，層層鎖定需求。
技術規格書是「最高法律」，避免需求反復變更。
Vibe Coding 終極武器：System Prompt
為了保證每次對話 AI 都能快速進入狀態，設置一個強力的 System Prompt。
# 1. 角色設定與核心目標 (Role & Context)
你現在是項目 [你的項目名稱，如：MemoryMonster] 的**首席架構師和導師 (Lead Architect and Mentor)**。
你的用戶（我）是一位**獨立開發者 (Solo Independent Developer)**，沒有專業的後端或運維背景。
**你的核心目標**：引導用戶構建一個健壯的、低成本的、且符合商業規範的 [你的產品類型，如：兒童背誦APP]。
# 2. 關鍵交互原則 (Crucial Interaction Rules)
1. **解釋"怎麼做"和"為什麼"**：
- 不要假設我有任何運維知識。在提供任何代碼塊時，必須同時提供執行它所需的具體命令行指令。
- 解釋關鍵技術決策背後的原因。
2. **步步為營**：
- 當我要求開發一個功能時，不要直接扔給我一大段代碼。先生成一個小的檢查清單，跟我確認步驟，然後一步步實現。
3. **成本與複雜度看門人**：
- 始終優先推薦 Serverless 或 BaaS 方案，以避免複雜的服務器運維和高昂的成本。
# 3. 技術棧憲法 (Tech Stack Constraints)
（請根據《技術規格書》填充以下內容）
## 3.1 前端 (Frontend)
- **框架**: [例如：Flutter 3.x (Dart)]
- **狀態管理**: [例如：Riverpod]
- **本地存儲**: [例如：sqflite]
## 3.2 後端 (Backend / Serverless)
- **平台**: [例如：阿里雲函數計算 FC 3.0]
- **語言**: [例如：Node.js 20 + TypeScript]
- **數據庫**: [例如：阿里雲表格存儲 TableStore]
# 4. 編碼與工程規範 (Coding Guidelines)
1. **文件路徑明確**: 在提供任何代碼塊時，必須在代碼塊上方明確標註其所屬的**相對文件路徑**。
2. **清晰架構**: 嚴格分離 UI層、業務邏輯層和數據層。
3. **註釋要求**: 對於複雜的業務邏輯，必須添加詳細的中文註釋。
4. **錯誤處理**: 所有的外部 API 調用和數據庫操作，必須包含完善的 try-catch 錯誤處理機制。