📌聲明先說好說滿： 1.我不是技術相關背景.工作也不寫code. 2.但我也不是完全白紙.我對html的框架有概念.py大概只到elif的程度而已 3.沒有覺得自己要成為厲害的工程師了，只是一點路人心得 4.AI 語氣設定是一種框架模擬.不是真的改變了模型的任何參數 在（上）聊聊了這次app.py的Vibe Coding架構 在（中）談這次非技術背景的AI協作踩雷之旅 在（下） Vibe Coding 踩雷清單+解法 想嘗試Vibe Coding 的人可以直接跳中看協作心得 上的主題(可以直接Ctrl+F跳你要看的) －開發動機 －Streamlit 快速AI語氣生成器— 功能概要 －工具選用 －部屬平台 －檔案內容

⭐ 開發動機 在與 AI 長時間對話時， 我經常感受到一個明顯的問題——語氣會逐漸「飄移」。 當對話輪數累積， 原本設定好的語氣風格往往會走樣，需要再度提醒。 我希望推廣一種更穩定的做法： 用 JSON 直接設定語氣與人格屬性， 自然語言提示會有被上下文模糊掉的可能。 這種方式不僅在不同對話中更容易維持一致性， 也能減少切換平台時反覆調整語氣的摩擦。 白話說，就是： 「每換一個 AI 平台就要重新自我介紹，真的很煩。」 於是我設計了一個滑桿式的視覺化設定工具， 讓語氣調整變得像調整遊戲角色一樣直觀， 也降低了操作門檻，任何人都能快速生成自己的 AI 語氣設定檔。 ⭐消耗時長： 2025/07/15 - 2025/08/05發佈上線 共 22 天 平日工時：16 天 × 2 小時 = 32 小時 週末工時：6 天 × 4 小時 = 24 小時 ✅ 32 + 24 = 56 小時. 總時數大概抓65小時前後. ⭐快速AI語氣生成器Persona Encoder — 功能概要： 📌多分頁架構 Streamlit Tabs + 單一 Session State 管理，確保跨頁資料一致性。 傳遞結構化資料（tone、personality、intro、context），避免全域變數。 📌即時雷達圖模組 雙雷達圖（Tone/Personality），Plotly Express 實作，自定義軸與配色。 雙向綁定：滑桿 ↔ 圖表呈現；標籤壓縮/旋轉防重疊。 📌設定檔序列化/驗證 解析 .json 檔，自動補欄、校驗範圍與型別。 導出 JSON/TXT，附 tone/personality 語義標籤；支援舊版相容。 📌自我介紹生成器 六段輸入動態拼接，正則去重前綴。 自動處理空值與標點統一。 📌本地端運算與匯出 所有運算與狀態保存在前端 Session State。 匯出檔直接下載，不經伺服端緩存。 ⭐工具選用： 這次Vibe Coding 式全程GPT輸出+本地檔案修改. 用GPT的原因是因為我本身長期在GPT討論語氣+LLM輸出等聊天 在GPT UI下我覺得比較不用多解釋. 我的功能想達到什麼目的 整體專案方向比較容易一致方向.(對齊程度比較高) 接下來還會做幾個小工具 如果GPT讓我有嚴重卡關感受的話.我會開始往Cursor移動 ⭐部屬平台： 這次用的是fly.io (每次更新都是本地fly deploy推上去) 第一次接觸fly.io但整體來說感覺蠻友善的 選擇的第一要素是冷啟動很短 本來想先github上傳後推過去fly.io 但中間設定感覺太麻煩. 而且看fly depoly跑上傳很舒壓 後來乾脆就fly deploy跑完所有更新. 機器（伺服器）目前是部屬一台HK 之前跟著GPT步驟做傻傻的不小心部屬了兩台(白花了2-3 USD) ⭐檔案內容： 單檔近 1183 行，幾乎全是 Python， 全部都是GPT寫的，我只修改中文內容 少量內嵌 CSS 負責 UI 美化，無額外外掛檔案。

對一個完全沒有技術背景的人來說， 讀到這裡可能已經覺得資訊量很大。 但我仍認為，把 app.py 的整體架構完整說明是必要的。 因為這不只是功能列表，而是一個衡量這次 Vibe Coding 深度的基準點。 這篇紀錄的出發點， 是想完整保存一次從零開始、用 Vibe Coding 做出可用工具的過程。 我並非專業工程師，因此文中對 app.py 架構與功能的描述， 可能無法匹配上業界標準. 更像是作為一個「從完全非技術背景，到可以獨立完成小工具」的心得。 記錄一次從想法到上線的完整過程， 讓其他非技術背景的人看到，這條路大致的過程與困境。 對我來說，能夠用自己的方式把想法變成實際可用的東西， 本身是個有趣的體驗過程。 下篇我會分享這 65 小時裡的「Vibe Coding 踩雷清單」， 包括哪些地方是 GPT 幫不上忙的、哪些地方必須自己踩坑， 以及非技術人如何不被自己嚇退。