📌聲明先說好說滿： 1.我不是技術相關背景.工作也不寫code. 2.但我也不是完全白紙.我對html的框架有概念.py大概只到elif的程度而已 3.沒有覺得自己要成為厲害的工程師了，只是一點路人心得 4.AI 語氣設定是一種框架模擬.不是真的改變了模型的任何參數 適合誰：非工程背景、想把想法做成可用工具的人。 ⭐⭐ 我的出發點只有一個——把想法做成能用的工具。 因此文中會有在技術人眼裡很淺、 甚至是「你連這個都不懂？」的基礎誤區。 這只是一篇心得，不是技術切磋文QQ⭐⭐ 在（上）說明了這次app.py的Vibe Coding架構 在（中）聊聊非技術背景的AI協作踩雷之旅 在（下） Vibe Coding 踩雷清單+解法 上的主題是開發動機、功能概要、工具選用、部署平台、檔案內容 這篇要來講我踩雷之旅 ⭐ 重要前提 這不是我第一次跟 GPT Vibe Coding。 第一次寫.NET + DB串回GPTs快速查閱資料用的(大概也是一個月?) 後來寫FastAPI + PostgreSQL + OpenAI API 但這個專案有點難，寫到後面有點疲乏，延期中但之後會撿回來寫 雖然內容不同，但與 GPT 溝通的模式類似， 建議開始前，先有心理準備： Vibe Coding 的成品，很難第一次就完美可用 目前 Vibe Coding 的發展， 可能還不足以讓非技術人員一次就流暢、零阻礙地上線成品。 對我來說，發想＋建造本身就是學習的一部分。

⭐ 碎碎念的心得 前一週的開發簡直像做夢—— 我只要出一張嘴，GPT 就能寫出我要的功能。 跟之前一堆 API 串接、pytest 鬼打牆的痛苦相比， 這次簡直是小菜一碟。 直到 debug 的大餐在「以為可以上線」的前一刻端上來。 GPT 最初的版本是 Streamlit 分成多個 Tab， 每個 Tab 寫各自的功能： Tab1：一套雷達圖 Tab2：另一套雷達圖...等 對我來說，這樣很直觀，檔案理解也很清楚。 但——這是個噩夢。 GPT 沒有告訴我， Streamlit 會在每次互動（像是切換 Tab）時整個腳本重新執行。 結果滑桿與雷達圖的即時更新功能， 每切一次 Tab 就被重跑覆蓋，資料完全留不住。 更糟的是，當初的實作邏輯是把功能定義分散在各個 Tab 下， 而不是集中在檔案前段統一管理。 這讓後續維護難度直接翻倍。 我用一週做完的工具，「看起來」沒問題， 但一旦進到實際使用的場景，馬上暴露出工具不及格的事實。 接下來幾乎所有時間， 我都在重構檔案、重新設計整體運作邏輯。 ⭐ 關於模型狀態與 Token 負載 這次協作期間，可能因為 GPT-5 要上線，4o 狀態偏不穩； 另外也可能是檔案過大（token 負載重）導致記憶不完整、遺漏上下文。 常出現 GPT 卡住、鬼打牆重複解釋同一段已討論過的內容。 解法： 不要猶豫，直接換 Session（開新聊天室）。 尤其是內容迭代頻繁時，務必確認 AI 沒用舊版本的邏輯給你解法。 ⭐ 最重要的事 AI 是 Code 寫手，不是專案主導者。 備註一定要寫好寫滿，即使你看不懂 code， 也要看得懂中文註解，並清楚知道： 這段 code 是做什麼功能的、它跟誰聯動 改動會影響哪些地方 如果只依賴 AI 來設計與主導，而不理解運作邏輯， 當出錯時你連「影響範圍」與「怎麼修」都說不出口。

例子： 「電視壞了，現在打不開，麻煩你來修」 「昨天晚上10 點轉台時有焦味，閃爍三下後整台關機」 這兩種描述，會得到完全不同的維修路徑與結果。 清楚描述錯誤狀況，才不會陷入「修了 A 壞了 B」的循環地獄。 備註寫滿的好處，是你會更理解自己在做什麼； 理解了，就能問出更好的問題。

⭐ 我的 GPT 協作策略 小範圍修改： 我會直接貼 code 給 GPT 看 簡單的改動自己在本地修改覆蓋 困難修改： 讓 GPT 輸出優化後的完整檔案文字 先提供原版，再告訴 GPT 我用覆蓋的方式在本端自己更新 大範圍邏輯變動： 開新聊天室，丟整個 app.py 要求 GPT 通讀全文、確認上下文邏輯，再給解方 停損點： 同一錯誤反覆修 2-3 次，就該停下來 代表 AI 的讀取與規劃能力被限制， 會在修 A → 壞 B、修 B → 壞 A 之間打轉 解法：換更高階模型 （我以前從 4o 跳 O3，現在應該是從 5 跳 5-Thinking）

這次做出來的小工具： 快速AI 語氣調整 生成器

下一篇會給完整踩雷清單＋對應方法