意外事件預測與模擬

校園常見意外事件  share

骨牌效應護欄倒成一片

快閃群眾失控

溝通

• 視覺優先：提供圖片快速建立情境
• 簡潔指令："Third person perspective" - 無需冗長解釋
• 具體反饋："Make stair easy to see" - 清晰、可執行
• 程式碼除錯：貼上確切有問題的程式碼段落

測試與驗證模式

• 注意到問題："but no working" → "still not"
• 要求驗證："check:: [特定功能]"
• 這顯示出系統性測試而非假設它能運作

運作良好的部分

1. 分層複雜度
   • 沒有一次要求所有東西
   • 每個新增功能單元測試
   • 降低除錯複雜度
2. 視覺溝通
   • 兩張不同圖片 = 兩個不同場景
   • 省去冗長描述
   • "Analyze it in the same style" = 高效的情境轉移
3. 必要時的具體性
   • "Npc walks narurally" - 簡短但意圖清晰
   • 快閃舞蹈場景有詳細要點因為複雜度需要
   • 在簡潔與細節間取得平衡
4. 對品質的堅持
• 不接受「無法運作」作為最終狀態
• 多次除錯嘗試
• 最終驗證特定功能

有效策略：

1. 從廣泛開始，然後縮小範圍
   • ✅ "Animate an accident" → "Make stairs visible"
   • ❌ 從這樣開始："建立一個 Three.js 模擬，包含 15 個 NPC、增強樓梯、氣球物理..."
2. 使用視覺參考
   • 一張圖片取代了約 500 字的描述
   • "Same style" 有效地轉移情境
3. 擴展前先測試
   • 在添加快閃舞蹈前先建立基礎
   • 早期發現問題（"but no working"）
4. 策略性簡潔
   • "tks" = 對話完成
   • 滿意時不做不必要的詳述
5. 除錯思維
   • 提供無法運作的確切程式碼
   • 在理解情境時使用 "Continue"
   • 具體的驗證請求