建造日誌
記錄一個文科背景的人，怎樣用 AI 一步一步開發出自己的東西。
編程的高牆終於倒下，我們可以實踐更多的想像，
先不要想之後會不會把我們抓回去，反正能跑多遠是多遠。
第一次制作產品經驗不足，沒有預計到原始資料來源的變更，加上之前很多疊加的功能沒有經過深入思考，格式的變化相當困難。
這次是一個很好的經驗，儘量保留現有邏輯，重構產品，要把問題及後續可能都想一想。
今天成功在下載按鍵中加入了數據統計功能。透過在 Google Sheets 內置的 Apps Script 部署 Web App，實現了從 WordPress 點擊到檔案下載之間的「中繼數據捕獲」。
這套系統解決了過去無法得知 Google Drive 檔案下載次數的問題。當讀者點擊按鈕時，腳本會先在試算表記錄時間與產品 ID，隨後透過 JavaScript 與 Meta Refresh 雙重機制，在 5 秒內將用戶平滑導向至真正的下載位址，並在導覽頁面加入「解除鎖定」的安全性貼心提示，優化用戶體驗。
今天成功在 WordPress 每個文章頁底導入了 wpDiscuz 留言板。解決了主題未自動觸發留言模板的問題，並透過後台 Forms 設定指派 post 類型正確顯示。
在防護策略上，暫時放棄了付費升級 reCAPTCHA v3 方案，轉而採用更輕量且隱私友好的 Antispam Bee 進行後台靜默攔截，確保讀者體驗不受驗證碼干擾，以後看情況要不要加上reCAPTCHA v2。
這幾天我讓五個 AI Agent 分頭推進 Yieldspot，每個 Agent 都有自己的進度文件，格式不一樣、內容還會重疊、衝突、遺漏，整合起來超頭痛！我發現幾個關鍵問題：授權碼居然有 YS- 和 DR- 兩個版本、收費狀態每個 Agent 理解都不一樣、進度完全分散在不同對話裡，完全沒有一個地方能看到全貌。
最後我決定：不再追著每個 Agent 跑，統一用兩份文件管理整個項目——wc（每週行動清單）和 il（想法記錄）。每週日晚固定整合一次，當週報存檔。
把 Yieldspot 的合規問題從頭整理了一遍。原來產品跟網誌不一樣，尤其有不同的地區的法規規定，需要小心處理。
最後選擇了參考業界的做法，加上「歷史統計」前置詞和免責聲明。
今天想到一個問題：如果越來越多人用 AI 找資料，而不是 Google，那文章的結構要不要改？
Google 看的是：權威性、關鍵字、反向連結。AI 看的是：概念清不清楚、有沒有具體數據、跨來源是否一致。
Yieldspot 要導入AI嗎
想了很久，AI終究只是一種工具。如果分析本身不具備足夠價值，單純導入AI又有何意義？
真正值得深思的是：當前模型能否有效解釋市場變化？若不夠，我們該如何提升其解釋力，而不是將所有答案拱手讓給AI。
Yieldspot 的三色訊號今天定版了。試過很多字眼，感覺「進場」這個詞本身仍有太多主動的意思在，選擇還是應該交回自己去做判斷。
最後選了：🟢 好時機 · 🟡 耐心等待 · 🔴 謹慎行動。簡單，有溫度。
✅ 完成