使用 Amazon Q Developer 與 Claude Sonnet 4 進行 Vibe Coding (Part 1)

這篇文章記錄了我使用 Amazon Q Developer 搭配 Claude Sonnet 4 開發一個 jGnash 替代方案的經驗。這個專案是一個使用 Rust + Tauri + SvelteKit 技術棧的個人財務管理應用程式。

Vibe Coding 核心要素

什麼是 Vibe Coding？

Vibe Coding 是一種以直覺和節奏為導向的 AI 協作開發方法，強調開發者與 AI 之間的自然互動和快速迭代。它的核心理念是透過建立良好的「開發節奏」(Development Rhythm) 來提升創造力和效率。

五大核心要素

1. 直覺驅動 (Intuition-Driven)

跟隨直覺：相信第一直覺，快速提出想法和解決方案
減少過度分析：避免在初期階段過度思考，保持創造性流動
擁抱不確定性：接受模糊的需求，在實作過程中逐步明確

2. 快速迭代 (Rapid Iteration)

短循環反饋：平均 3-5 次對話解決問題
快速原型：優先建立可運行的最小版本
持續調整：根據反饋快速調整方向

3. 自然對話 (Natural Conversation)

口語化表達：使用自然語言描述問題，而非技術規格
上下文豐富：提供充分的背景資訊和情境
雙向交流：AI 不只是工具，更是協作夥伴

4. 流狀態維持 (Flow State Maintenance)

減少中斷：保持專注，避免頻繁切換任務
節奏感：建立穩定的工作節奏和互動模式
沉浸體驗：在問題解決過程中保持深度專注

5. 適應性學習 (Adaptive Learning)

從失敗中學習：將每次失敗視為有價值的學習機會
模式識別：識別成功和失敗的模式，建立經驗庫
持續優化：根據經驗不斷調整協作方式

Vibe Coding vs 傳統開發

特徵	傳統開發	Vibe Coding
規劃方式	詳細預先規劃	直覺驅動，邊做邊調整
問題解決	系統性分析	快速迭代嘗試
與 AI 互動	指令式查詢	自然對話協作
錯誤處理	避免錯誤	擁抱錯誤，快速學習
開發節奏	階段性里程碑	持續流動狀態

實踐 Vibe Coding 的關鍵

建立信任關係：與 AI 建立互信，相信其建議的價值
保持開放心態：願意嘗試新方法，不固守既有做法
培養直覺：透過大量實踐培養對技術方案的直覺判斷
記錄節奏：觀察和記錄自己的最佳工作節奏
持續反思：定期回顧和優化協作模式

專案概述

技術棧

Frontend: SvelteKit + TypeScript + Tailwind CSS v4 + shadcn-svelte
Backend: Rust + Tauri + ReDB
開發工具: VSCode/Codium + Amazon Q Extension + Claude Sonnet 4

專案目標

建立一個現代化的個人財務管理應用，作為 jGnash 的替代方案，具備帳戶管理、交易記錄、階層式帳戶結構等核心功能。

實際開發對話記錄

在這個專案中，我們進行了大量的技術討論和問題解決。以下是一些關鍵的對話片段和學習重點：

樹狀表格實作的演進過程

初始需求

"我想要在帳戶表格中顯示階層式的帳戶結構，類似檔案總管的樹狀顯示"

第一次嘗試的問題

TanStack Table 的 FlexRender 無法正確處理動態樹狀結構
深度計算在元件重新渲染時被重置
Svelte 5 的 $state 與複雜的巢狀元件不相容

實際對話片段

"TanStack Table's FlexRender doesn't work well with complex component rendering for tree structures - depth values get corrupted when using nested components"

解決方案演進

直接實作方案：放棄 DataTable，直接在 AccountTable 中實作樹狀邏輯
重構回 DataTable：使用 renderComponent helper 與專用的 AccountNameCell 元件
最終方案：在 DataTable 中使用 renderComponent 函數來渲染樹狀結構

資料刷新機制的改進

問題描述

"當更新資料後，頁面會閃爍，如何避免這個問題？"

解決方案演進

window.location.reload() - 有頁面閃爍問題
invalidateAll() - 在 Tauri 環境下無效
自訂事件系統 - 事件無法正確觸發
全域 store - 最終成功的解決方案

typescript

// 最終解決方案：全域刷新 store
export const refreshTrigger = writable(0);
export function triggerRefresh() {
  refreshTrigger.update((n) => n + 1);
}

開發歷程回顧

第一階段：專案初始化與 UI 框架選擇

主要成就

建立 SvelteKit 專案結構
從 PicoCSS 轉換到 Tailwind CSS v4
整合 shadcn-svelte 元件庫
實作基礎 layout 和 dark mode 支援

關鍵決策

從 PicoCSS 轉換到 Tailwind CSS v4 - 為了獲得更好的自訂能力和元件整合
使用 shadcn-svelte - 提供一致的 UI 元件系統
重寫 layout 架構 - 採用更清晰的結構和 menubar 導航

第二階段：後端架構設計與文檔

重要里程碑

建立 SRS (Software Requirements Specification)
建立 SDD (Software Design Document)
ReDB 取代 SQLite - 更好的 Rust 整合和效能
設計完整的後端 API 架構

學習重點

使用 Claude Sonnet 4 時，明確的需求描述能獲得更好的程式碼建議。在設計資料庫 schema 和 API 結構時，詳細的文檔規劃很重要。

第三階段：Tauri 整合與前端元件

技術選擇

整合 Tauri 後端
實作 Data Table 元件
新增 Transaction 表單和相關 UI 元件
整合更多 shadcn-svelte 元件

Amazon Q Developer 的價值

在這個階段，Amazon Q Developer 特別有助於：

快速生成 Rust 結構體和 trait 定義
提供 Tauri 命令的最佳實踐建議
協助前後端資料型別一致性

第四階段：核心功能實作

主要功能

基礎帳戶管理
- 帳戶列表顯示
- 階層式帳戶結構顯示
- 帳戶新增/編輯表單
- 帳戶類型選擇
UI 元件系統
- Data Table 元件與樹狀顯示
- 表單驗證 (Zod)
- 對話框元件
- 貨幣選擇元件
後端整合
- Tauri 命令系統
- ReDB 資料庫整合
- 環境變數管理
- 資料刷新機制

開發心得

漸進式開發：從基礎 UI 開始，逐步整合後端功能
元件化思維：建立可重用的 UI 元件，如帳戶選擇、貨幣選擇
型別安全：TypeScript + Zod 確保前後端資料一致性

第五階段：進階功能與優化

重要功能

樹狀結構顯示
- ✅ 實作帳戶階層顯示
- ✅ 深度計算和縮排顯示
- ⏳ 可展開/收合功能（規劃中）
資料庫整合與配置
- ✅ dotenvy 環境變數管理
- ✅ 資料庫檔案檢查邏輯
- ✅ 預設配置表設定
使用者體驗改進
- ✅ 側邊欄選單與路由匹配
- ⏳ 帳戶交易顯示（規劃中）
- ✅ 表單預設值優化

Amazon Q Developer 的輔助作用

程式碼生成

快速生成樣板程式碼
自動完成複雜的型別定義
提供符合專案風格的程式碼

重構建議

識別程式碼重複和改進機會
提供效能優化建議
協助維護程式碼一致性

除錯協助

快速定位問題根源
提供除錯策略建議
協助理解錯誤訊息

開發效率提升

開發效率分析

基於對話記錄的開發時程分析：

功能模組	複雜度	迭代次數	主要挑戰	實作狀態
基礎架構設置	低	1-2 次	套件整合	✅ 已完成
UI 元件庫整合	中	2-3 次	版本相容性	✅ 已完成
樹狀表格實作	高	3 次重構	TanStack Table 限制	✅ 已完成
基礎帳戶管理	中	2-3 次	表單驗證與資料綁定	✅ 已完成
資料刷新機制	中	4 種方案	Tauri 環境限制	✅ 已解決

觀察到的效益

簡單任務：AI 能在 1-2 次對話內完成基礎結構和樣板程式碼
中等複雜度：通常需要 2-4 次迭代，主要時間花在理解需求和調整細節
複雜邏輯：需要 3+ 次重大重構，但 AI 提供的方向性建議很有價值
學習新技術：AI 協助快速理解 Svelte 5 runes 等新語法
除錯效率：AI 能快速定位問題並提供多種解決方案

實作範圍說明

本專案目前專注於核心帳戶管理功能的實作，完整的交易系統和進階功能將在後續版本中逐步實現。

注意事項

這些數據基於單一專案的對話記錄觀察，實際效益會因專案複雜度、開發者經驗和問題類型而有所不同。

最佳實踐總結

與 AI 協作的核心技巧

清晰的問題描述

實際案例對比：

text

❌ "樹狀表格有問題"
✅ "TanStack Table 的 FlexRender 與動態樹狀結構不相容，
    深度值在使用巢狀元件時被破壞，需要在 Svelte 5 runes
    模式下實作帳戶階層顯示"

成功描述的要素：

具體的觸發條件
明確的問題現象
清楚的期望結果

提供充足的上下文
- 包含相關的程式碼片段
- 說明專案架構和技術棧
- 描述預期行為和實際結果
接受迭代開發
關鍵心態：
- 將每次失敗視為學習機會
- 保持詳細的問題記錄和解決過程
- 不害怕推翻之前的實作重新開始

對話統計與反思

開發過程統計

總對話輪次：約 200+ 次交互
主要技術問題：5 個重大挑戰
程式碼重構次數：樹狀表格 3 次，資料刷新 4 次
解決時間：平均每個重大問題需要 3-5 次迭代

有效的對話模式

問題 → 嘗試 → 失敗 → 分析 → 改進 的循環
提供具體錯誤訊息和程式碼片段
說明預期行為與實際結果的差異
逐步縮小問題範圍

改進建議

時間管理：複雜問題預留更多迭代時間
文檔記錄：及時記錄失敗的解決方案，避免重複嘗試
技術選型：在專案初期更仔細評估第三方函式庫的適用性
測試策略：建立更完整的測試環境來驗證 AI 建議

Vibe Coding 回顧

Sprint 回顧概述

本次回顧針對使用 AI 協作開發的 Vibe Coding 經驗，採用標準 Scrum 回顧方法論進行分析和改進。

階段一：設定環境 (Set the Stage) 🎯

回顧目標：

反思 AI 協作開發的節奏和模式
識別 Vibe Coding 的成功因素和改進機會
建立可行動的改進計劃

階段二：收集數據 (Gather Data) 📊

What Went Well ✅

短循環迭代模式：平均 3-5 次對話解決重大問題
即時回饋機制：AI 協作在簡單任務上效率顯著（1-2 次對話完成）
溝通品質提升：學會精確描述問題，提供充分上下文
學習加速效應：新技術（Svelte 5 runes）的掌握速度明顯提升
適應性強：能夠從失敗中學習並調整方法

What Didn't Go Well ❌

複雜度預估不足：高複雜度任務（樹狀表格）需要 3+ 次重構
驗證流程不完善：AI 建議需要在實際環境中驗證，但缺乏系統化流程
標準化不足：缺乏基於任務複雜度的標準協作流程
時間估計模型：缺乏基於歷史經驗的時間預估
第三方工具評估：對第三方函式庫限制的評估不夠充分

What We Learned 💡

Vibe Coding 的核心：不僅是技術實作，更是協作節奏和溝通模式
迭代心態的重要性：接受失敗並從中學習是成功的關鍵
上下文的價值：精確的問題描述直接影響解決效率
適應性管理：根據任務複雜度調整協作模式的重要性
持續改進的價值：定期回顧和優化協作流程的必要性

階段三：產生洞察 (Generate Insights) 🔍

問題根因分析

複雜度預估問題：缺乏歷史數據和經驗積累，導致對高複雜度任務的時間估計不足
驗證流程缺失：過度依賴 AI 建議，缺乏系統化的驗證機制
標準化不足：沒有建立清晰的協作指引和最佳實踐

改進機會優先級

優先級	改進項目	影響程度	實施難度
高	複雜度預估不足	高	中
中	驗證流程不完善	中	低
低	標準化不足	低	高

階段四：決定行動項目 (Decide What to Do) ✅

立即行動項目 (Sprint 1-2)

建立複雜度評估模型
- 截止日期：2025-11-15
- 成功標準：建立任務複雜度與迭代次數的對應關係表
制定問題描述標準
- 截止日期：2025-11-20
- 成功標準：完成問題描述檢查清單和範例庫

短期改進項目 (Sprint 3-6)

建立 AI 建議驗證框架
- 截止日期：2025-12-15
- 成功標準：自動化測試環境和驗證檢查清單
實作失敗案例資料庫
- 截止日期：2025-12-31
- 成功標準：系統化的失敗案例記錄和分享機制

長期改進項目 (Sprint 7-12)

建立效率指標追蹤系統
- 截止日期：2026-02-28
- 成功標準：即時協作效率和品質指標面板
定期回顧機制
- 頻率：每月一次
- 成功標準：持續優化的協作模式和流程改進

階段五：結束回顧 (Close the Retrospective) 🎆

回顧總結

這次回顧揭示了 AI 協作開發的巨大潛力，同時識別了關鍵的改進領域。成功的 Vibe Coding 需要：

建立正確的協作節奏和溝通模式
系統化的問題解決流程
持續改進的文化和機制

下次回顧安排

時間：2025-12-01
重點：檢視行動項目執行狀況和新的改進機會
參與者：開發團隊全員

附錄：本次迭代實際統計數據

Sprint 實際數據記錄 (2025-11-01)

以下是本次 Vibe Coding 開發的實際統計數據，供下次回顧時對比和改進參考。

任務實際執行結果

任務名稱	複雜度	實際迭代	主要挑戰	解決時間	成功因素
SvelteKit 專案初始化	低	1 次	無	30 分鐘	標準流程
PicoCSS → Tailwind CSS v4	中	2 次	版本相容性	2 小時	AI 建議明確
shadcn-svelte 整合	中	3 次	元件配置	3 小時	步驟式解決
Tauri 後端整合	中	2 次	命令系統設計	4 小時	文檔完整
ReDB 資料庫整合	中	2 次	異步操作	3 小時	範例參考
樹狀表格實作	高	4 次	TanStack Table 限制	8 小時	多次重構
帳戶管理 CRUD	中	3 次	表單驗證	5 小時	Zod 整合
資料刷新機制	中	4 次	Tauri 環境限制	6 小時	全域 store
環境變數管理	低	1 次	無	1 小時	dotenvy 套件
Dark Mode 支援	低	2 次	CSS 變數	2 小時	Tailwind 整合

對話模式分析

成功模式：

明確問題描述 + 具體錯誤訊息 = 1-2 次解決
提供完整上下文 + 相關程式碼 = 2-3 次解決
步驟式縮小問題範圍 = 提高效率 50%

失敗模式：

模糊問題描述 = 增加 2-3 次迭代
缺乏技術上下文 = 增加 1-2 次迭代
過度依賴 AI 建議 = 需要實際驗證

AI 協作效率指標

指標	數值	說明
平均解決時間	3.4 小時/任務	含實作和測試
一次成功率	20%	2/10 任務
二次成功率	50%	5/10 任務
三次成功率	70%	7/10 任務
四次成功率	100%	10/10 任務
重構次數	1.2 次/任務	主要集中在高複雜度

技術棧學習曲線

Svelte 5 + Runes (0 → 中等)

初期學習：3 小時
實際應用：5 小時
進階特性：8 小時

Tauri 2.0 (0 → 基礎)

API 理解：2 小時
命令系統：4 小時
狀態管理：6 小時

ReDB (新技術)

基礎操作：2 小時
異步模式：3 小時

問題解決時間分布

< 1 小時: 20% (簡單配置)
1-3 小時: 40% (一般功能)
3-6 小時: 30% (複雜整合)
> 6 小時: 10% (高難度問題)

下次回顧比較基準

效率指標目標：

一次成功率 > 30%
二次成功率 > 60%
平均解決時間 < 3 小時
重構次數 < 1.0 次/任務

測量方法：

記錄每個任務的實際迭代次數
追蹤問題描述品質與解決效率的關係
分析失敗案例的根本原因
評估 AI 建議的準確性和實用性

附錄：問題描述檢查清單與實例

問題描述品質檢查清單 v1.0

基於本次迭代的實際對話記錄，建立的問題描述標準和檢查清單。

核心檢查項目

✅ 必備要素 (Must Have)

[ ] 具體問題現象：明確描述發生了什麼
[ ] 技術環境：說明使用的技術棧和版本
[ ] 預期結果：清楚表達想要達成的目標
[ ] 觸發條件：描述問題出現的具體情境

🔧 技術細節 (Should Have)

[ ] 錯誤訊息：提供完整的錯誤輸出
[ ] 相關程式碼：包含問題相關的程式碼片段
[ ] 嘗試過的方法：說明已經試過但失敗的解決方案
[ ] 限制條件：提及技術或環境限制

📋 上下文資訊 (Could Have)

[ ] 專案架構：簡述整體技術架構
[ ] 相依套件：列出相關的第三方套件
[ ] 時間壓力：說明是否有緊急性要求

實際案例分析

案例 1：樹狀表格問題

❌ 低品質描述

"樹狀表格有問題"

缺失：無具體現象、無技術細節、無預期結果結果：需要 3+ 次澄清對話

✅ 高品質描述

"TanStack Table 的 FlexRender 與動態樹狀結構不相容，
深度值在使用巢狀元件時被破壞，需要在 Svelte 5 runes
模式下實作帳戶階層顯示"

包含：具體問題 + 技術環境 + 預期結果結果：1-2 次對話找到解決方案

案例 2：資料刷新問題

❌ 低品質描述

"頁面不會更新"

缺失：無觸發條件、無技術環境結果：需要多次澄清

✅ 高品質描述

"當更新資料後，頁面會閃爍，如何避免這個問題？
使用 Tauri 環境，invalidateAll() 無效"

包含：具體現象 + 環境限制 + 嘗試過的方法結果：快速定位到 Tauri 特殊性

案例 3：套件整合問題

✅ 良好描述

"shadcn-svelte 元件在 SvelteKit + Tailwind CSS v4 環境下
樣式不生效，需要正確的配置方式"

包含：技術棧 + 具體問題 + 預期結果結果：2-3 次對話解決

品質評分標準

分數	等級	特徵	預期迭代次數
90-100	優秀	包含所有必備要素 + 大部分技術細節	1-2 次
70-89	良好	包含必備要素 + 部分技術細節	2-3 次
50-69	普通	包含部分必備要素	3-4 次
< 50	需改進	缺乏基本要素	4+ 次

常見問題模式

模糊描述模式

"不能用"、"有問題"、"不工作"
改進：具體描述現象和預期行為

缺乏上下文模式

只提問題，不說環境
改進：說明技術棧、版本、相關配置

過度簡化模式

省略重要的技術細節
改進：提供錯誤訊息、程式碼片段

假設過多模式

假設 AI 了解所有背景
改進：明確說明專案脈絡和限制

快速自檢方法

5W1H 檢查法

What: 發生了什麼問題？
Where: 在哪個技術環境下？
When: 什麼時候出現？
Why: 為什麼需要解決？
Who: 影響哪些使用者/功能？
How: 希望如何解決？

一句話測試

"如果我是新加入的開發者，看到這個描述能否立即理解問題並開始解決？"

下次回顧改進項目

[ ] 驗證檢查清單的實用性
[ ] 收集更多問題描述案例
[ ] 建立自動化品質評分工具
[ ] 分析問題類型與描述模式的關係
[ ] 優化檢查清單項目權重

注意

這次的內容是由 Claude Sonnet 4 產出 (除了這行).

Vibe Coding 核心要素 ​

什麼是 Vibe Coding？ ​

五大核心要素 ​

1. 直覺驅動 (Intuition-Driven) ​

2. 快速迭代 (Rapid Iteration) ​

3. 自然對話 (Natural Conversation) ​

4. 流狀態維持 (Flow State Maintenance) ​

5. 適應性學習 (Adaptive Learning) ​

Vibe Coding vs 傳統開發 ​

實踐 Vibe Coding 的關鍵 ​

專案概述 ​

技術棧 ​

專案目標 ​

實際開發對話記錄 ​

樹狀表格實作的演進過程 ​

初始需求 ​

第一次嘗試的問題 ​

實際對話片段 ​

解決方案演進 ​

資料刷新機制的改進 ​

問題描述 ​

解決方案演進 ​

開發歷程回顧 ​

第一階段：專案初始化與 UI 框架選擇 ​

主要成就 ​

關鍵決策 ​

第二階段：後端架構設計與文檔 ​

重要里程碑 ​

學習重點 ​

第三階段：Tauri 整合與前端元件 ​

技術選擇 ​

Amazon Q Developer 的價值 ​

第四階段：核心功能實作 ​

主要功能 ​

開發心得 ​

第五階段：進階功能與優化 ​

重要功能 ​

Amazon Q Developer 的輔助作用 ​

程式碼生成 ​

重構建議 ​

除錯協助 ​

開發效率提升 ​

開發效率分析 ​

觀察到的效益 ​

最佳實踐總結 ​

與 AI 協作的核心技巧 ​

對話統計與反思 ​

開發過程統計 ​

有效的對話模式 ​

改進建議 ​

Vibe Coding 回顧 ​

Sprint 回顧概述 ​

階段一：設定環境 (Set the Stage) 🎯 ​

階段二：收集數據 (Gather Data) 📊 ​

What Went Well ✅ ​

What Didn't Go Well ❌ ​

What We Learned 💡 ​

階段三：產生洞察 (Generate Insights) 🔍 ​

問題根因分析 ​

改進機會優先級 ​

階段四：決定行動項目 (Decide What to Do) ✅ ​

立即行動項目 (Sprint 1-2) ​

短期改進項目 (Sprint 3-6) ​

長期改進項目 (Sprint 7-12) ​

階段五：結束回顧 (Close the Retrospective) 🎆 ​

回顧總結 ​

下次回顧安排 ​

附錄：本次迭代實際統計數據 ​

Sprint 實際數據記錄 (2025-11-01) ​

任務實際執行結果 ​

對話模式分析 ​

AI 協作效率指標 ​

技術棧學習曲線 ​

問題解決時間分布 ​

下次回顧比較基準 ​

附錄：問題描述檢查清單與實例 ​

問題描述品質檢查清單 v1.0 ​

核心檢查項目 ​

實際案例分析 ​

品質評分標準 ​

Vibe Coding 核心要素

什麼是 Vibe Coding？

五大核心要素

1. 直覺驅動 (Intuition-Driven)

2. 快速迭代 (Rapid Iteration)

3. 自然對話 (Natural Conversation)

4. 流狀態維持 (Flow State Maintenance)

5. 適應性學習 (Adaptive Learning)

Vibe Coding vs 傳統開發

實踐 Vibe Coding 的關鍵

專案概述

技術棧

專案目標

實際開發對話記錄

樹狀表格實作的演進過程

初始需求

第一次嘗試的問題

實際對話片段

解決方案演進

資料刷新機制的改進

問題描述

解決方案演進

開發歷程回顧

第一階段：專案初始化與 UI 框架選擇

主要成就

關鍵決策

第二階段：後端架構設計與文檔

重要里程碑

學習重點

第三階段：Tauri 整合與前端元件

技術選擇

Amazon Q Developer 的價值

第四階段：核心功能實作

主要功能

開發心得

第五階段：進階功能與優化

重要功能

Amazon Q Developer 的輔助作用

程式碼生成

重構建議

除錯協助

開發效率提升

開發效率分析

觀察到的效益

最佳實踐總結

與 AI 協作的核心技巧

對話統計與反思

開發過程統計

有效的對話模式

改進建議

Vibe Coding 回顧

Sprint 回顧概述

階段一：設定環境 (Set the Stage) 🎯

階段二：收集數據 (Gather Data) 📊

What Went Well ✅

What Didn't Go Well ❌

What We Learned 💡

階段三：產生洞察 (Generate Insights) 🔍

問題根因分析

改進機會優先級

階段四：決定行動項目 (Decide What to Do) ✅

立即行動項目 (Sprint 1-2)

短期改進項目 (Sprint 3-6)

長期改進項目 (Sprint 7-12)

階段五：結束回顧 (Close the Retrospective) 🎆

回顧總結

下次回顧安排

附錄：本次迭代實際統計數據

Sprint 實際數據記錄 (2025-11-01)

任務實際執行結果

對話模式分析

AI 協作效率指標

技術棧學習曲線

問題解決時間分布

下次回顧比較基準

附錄：問題描述檢查清單與實例

問題描述品質檢查清單 v1.0

核心檢查項目

實際案例分析

品質評分標準